📜 ⬆️ ⬇️

The secret ingredient is a good architect.

What goes around comes around
An oak grows from an acorn,
From burdock seed - only burdock
Professional education -
these are the seeds that we sow ...

The search for highly qualified specialists is one of the most difficult issues in the software development business. Despite all the difficulties of the global and domestic economy, there is a shortage of qualified personnel. The number of projects requiring high qualification is growing much faster than specialists are “maturing” (developer - 2-3 years, leading developer - plus 2 years, solution architect - plus 3-5 years ...).

As a result, it is difficult to find developers in the labor market, and it is almost impossible to find qualified architects. The problem is aggravated by the fact that training a good developer is not an easy task, at best only half of the students of IT specialties who study the standard program and have no work experience are really able to perform real tasks after they graduate. At the same time, these students, as a rule, begin to work in their specialty from 2-3 courses, and it is difficult to understand: they know and are able to “thanks” or “against”. The possibility of teaching an architect at a higher education institution is in principle in doubt, if not hysterical laughter.
')
Therefore, when in May 2012, I received an offer from Technopark Mail.Ru to take part in a project to train architects at a university (even if it was as famous as “Baumanka”), to say the least, I was puzzled and intrigued.

As a result of the study of this topic, we received very interesting results.
In order to solve this problem, we did the following:

  1. We got to the bottom of the problem:
    - Is it possible to prepare an architect in high school?
    The correct answer is “NO”
    - Can training at a university speed up development and improve the quality of an architect's training?
    Our answer is "YES"
  2. Formed the rules for creating a course:
    a) Provide basic selection and initial quality of the “material” (for more details, see here: Technopark Mail.Ru. Beginning );
    b) Maximize the "effectiveness" of the experience that a student receives outside of training. In a linear situation, first the experience “brings” the student to the lead developer, and then another experience allows to “retrain” to the level of the architect. The exception of retraining allows you to shorten the path by 1.5-2 times; this requires the ability to analyze and systematize the experience;
    c) Give training practice to consolidate the knowledge base.
  3. Determined quality assurance methods:
    a) A solid foundation of knowledge so that experience does not pass by (820 hours + master classes in the same place);
    b) First-hand best practices (all courses are designed and conducted with practitioners).


Course "Business and Systems Analysis for Architects"


Within the framework of this course, we set the task to help students connect the “problem domain” and the “solution domain”, that is, to lay down the knowledge that later will be very difficult for experienced programmers who have grown solely on the basis of technical skills. Subsequently, this knowledge can significantly improve the quality of the solutions created (red oval).



The competencies associated with owning a “problem domain” include:

  1. Business and system analysis in product and service development. This lecture lays the foundation for understanding the context of various types of businesses that are based on software development. With the use of applied system theory and complexity, an insight into the key issues and driving forces in software development is introduced. A mechanistic view of complex systems is being adjusted, including such systems as business, which is based on the creation of complex technological solutions.
    (+2 to the speed of development, +2 to the quality of the decisions made)
  2. Lifecycle technology is their relationship with software architecture. This lesson explores an even wider context that influences the business and the technical solution that is created, which is related to innovation processes and the evolution of technology. The concept of disruptive and supportive technologies, the Gartner Hype Curve, is considered. This knowledge makes it possible to consciously observe changes in the world of technology and the seeming chaos of the innovation process, to see the laws governing them.
    (+1 to the speed of development, +2 to the quality of the decisions made)
  3. Business model. Stream of value creation. From external forces and laws that determine the development of the industry as a whole, we turn to the specific issues of achieving success of the product and the company. We consider ways to communicate and understand the company's business model.
    (+2 to the quality of decisions)
    Based on the experience gained, the value stream will be added to the next course for the service development model.
  4. Modeling use. Problem analysis. The role of the architect in working on system requirements. Identifying stakeholders for product, project, and architecture. Work with stakeholders. Modeling users.
    (+1 to the speed of development, +3 to the quality of decisions)
  5. Conceptual model, introduction to analytical patterns. This module completes the first part of the course. It summarizes the mechanisms of object-oriented design and translates them into the plane of a tool for working with the subject area of ​​its study, as well as using already accumulated experience and creating your own patterns (templates) of solutions.
    (+2 to development speed)






The competencies associated with owning a “solution area” include:

  1. Attributes of quality. A kind of conceptual bridge between the quality product and the characteristics of the software architecture. In this module, we consider the impact of non-functional requirements on software architecture, as well as software quality models and quality attribute scenarios.
    (+1 to the speed of development, +2 to the quality of the decisions made)
  2. Key concepts of software architecture. View points. In continuation of the study of the topic of complexity in the field of software development, this lecture introduces a terminological basis, tools for working and ensuring the integrity of the product / solution being created from the point of view of stakeholders.
    (+2 to the speed of development, +1 to the quality of the decisions made)
  3. Key concepts of software architecture. Perspectives. In this lecture, architecture is considered as a process and as a document.
    (+1 to the speed of development, +1 to the quality of the decisions made)
  4. The process of building architecture. This final lecture links together and allows you to repeat all the key aspects of creating a high-quality architecture, including the process of agreeing and adopting an architecture, the process of communicating the architecture to non-technical specialists.
    (+2 to success)




Practice

Practice was one of the most difficult aspects. Teaching an architect with examples from “Hello world” or another website of an online store is, to put it mildly, incorrect - this leads directly to a “cargo cult”. Creating a relatively small course in a product where you can feel the architecture and its interaction with the business context is also not very realistic.
The decision matured quickly. Just like doctors, before becoming surgeons, they start with an autopsy, and so we decided that at first the students would have to prepare a uniquely successful product and try to identify the relationships that allowed the product to take its place. But unlike doctors, for successful business and system analysis, it is not necessary to analyze a dead product, live ones are also suitable. :-)

As part of the course, students in mini-groups work to restore the business context and its relationship with the architecture of the public product.

This term, students selected the following products:



Having received a block of theoretical material and having tormented the teacher fairly, the guys work on a part of the puzzle and present it to their colleagues.

As a result, each mini-group will have a comprehensive understanding of a specific product, and the group as a whole will understand the characteristics of different markets and the “anatomical atlases” of successful solutions.

Summing up

The course "Business and Systems Analysis for Architects" allows you to:

  1. To improve the quality of the architectural decisions made, to link technical excellence with real user problems and business objectives
  2. Introduce the system to the experience gained in the framework of current and future work.
  3. Get the skill of analyzing the architecture and communication of analysis results to your colleagues
  4. Taking into account the experience gained in conducting the course in the coming year, we plan to expand part of the course, allowing students to more effectively perform homework related to understanding the needs of business and system users.


Bezugly Dmitry
cless75
http://www.facebook.com/dmitry.bezuglyy

The literature used in the preparation of the course:

  1. Alexander Ostervalder and Yves Pinye Building Business Models. Handbook strategist and innovator
  2. Dean Leffingwell, Don Widrig Principles of working with software requirements. Unified Approach Williams 2002 Ch 8-13
  3. Craig Larman, UML 2.0 Applications and Design Patterns (3rd Edition) Williams 2006.
  4. Clayton M. Christensen The Dilemma Innovator. How do new technologies perish due to new technologies2012
  5. Martin Fowler, David Rice, Matthew Fommel, Edward Hyatt, Robert Mee, Randy Stafford. Enterprise Application Templates
  6. Martin Fowler Analysis Patterns: Reusable Object Models
  7. Nick Rozanski, EĂłin Woods, Software Systems
  8. www.viewpoints-and-perspectives.info/
  9. L. Bass, P. Clements, R. Katzman Software Architecture in Practice (NFR)
  10. Martin Fowler UML. The basics. Quick Reference Guide to Standard Object Modeling Language
  11. Alistair Coburn Modern methods of describing the functional requirements for systems
  12. Alan Cooper Mental Hospital in the hands of patients
  13. Barbara Minto. Minto Pyramid Principle Golden Rules of Thinking, Business Writing and Oral Presentation
  14. Michael Rother, John Shook Learn to see business processes. The practice of building value stream maps

Source: https://habr.com/ru/post/181368/


All Articles