The secret ingredient of a good architect

    What you sow, you will reap.
    An oak will grow from an acorn,
    From a seed of a burdock - only a burdock
    Vocational education is
    the seeds that we sow ... The

    search for highly qualified specialists is one of the most difficult issues in a business related to software development. Despite all the difficulties of the global and domestic economies, qualified personnel are sorely lacking. The number of projects requiring high qualifications is growing much faster than specialists "mature" (developer - 2-3 years, lead 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 compounded by the fact that training a good developer is not an easy task; at best, only half of the IT students who are studying in the standard program and have no work experience are really able to perform real tasks after graduation. At the same time, these students, as a rule, begin to work in their specialty from the 2-3rd year, and it is difficult to understand: they know and are able to "thanks" or "contrary to". The ability to train an architect at a university is, in principle, doubtful, if not hysterical, laughing.

    Therefore, when in May 2012 I received an offer from Mail.Ru Technoparkto take part in the project of training architects at the university (even if it’s a big name like “Baumanka”), to put it mildly, I was puzzled and intrigued.

    As a result of the study of this topic, we got 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 at a university?
      The correct answer is “NO”
      . Can university education accelerate development as much as possible and improve the quality of architect training?
      Our answer is “YES”
    2. The rules for creating the course were formed:
      a) Ensure the basic selection and initial quality of the “material” (for more details, see here: Mail.Ru Technopark. Home );
      b) Maximize the "effectiveness" of the experience that the student receives outside of training. In a linear situation, first the experience “brings” the student to a leading developer, and then another experience allows him to “retrain” to the level of an architect. The exclusion of retraining allows you to shorten the path by 1.5-2 times; this requires the ability to analyze and systematize experience;
      c) Provide training practice to reinforce the knowledge base
    3. We identified ways to ensure quality:
      a) A solid foundation of knowledge so that experience does not pass by (820 hours + master classes in the same place);
      b) The best practices first-hand (all courses are designed and conducted with practitioners).

    Course "Business and Systems Analysis for Architects"

    As part of this course, we set the task to help students connect the “problem area” and “solution area”, that is, lay the knowledge that is subsequently very hard given to experienced programmers who grew up solely on the basis of technical skills. Subsequently, this knowledge can significantly improve the quality of the created solutions (red oval).

    The competencies associated with owning a “problem area” included:

    1. Business and systems analysis in product and service development. This lecture lays the foundation for understanding the context of various types of business, the basis of which is software development. Using the applied theory of systems and complexity, an idea of ​​the key problems and driving forces in the field of software development is introduced. The mechanistic concept of complex systems is being corrected, including such systems as a business, which is based on the creation of complex technological solutions.
      (+2 to the speed of development, +2 to the quality of decisions)
    2. Life-cycle technologies, their relationship with software architecture. This lesson examines an even wider context that affects the business and the technical solution created related to innovative processes and the evolution of technology. Explores the concept of disruptive and supporting technologies, the Gartner Hype Curve. 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 it.
      (+1 to the speed of development, +2 to the quality of decisions)
    3. Business model. Value stream. From the external forces and laws that determine the development of the industry as a whole, we move on to specific issues of achieving product and company success. We consider ways of communicating and understanding the company's business model.
      (+2 to the quality of decisions made)
      Based on the experience gained, the aspect of the value stream for the development service model will be added to the next course.
    4. Modeling use. Analysis of the problem. The role of the architect in working on system requirements. Identification of stakeholders for a product, project, and architecture. Work with stakeholders. User Modeling.
      (+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 the tool for working with the subject area of ​​its study, as well as using already gained experience and creating your own patterns (templates) of solutions.
      (+2 to development speed)

    The competencies related to owning the “solution area” included:

    1. Quality attributes. A kind of conceptual bridge between a quality product and software architecture features. In this module, we examine 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 decisions)
    2. Key concepts of software architecture. View points. To continue the study of the topic of complexity in the field of software development, within the framework of this lecture, a terminological basis, tools for ensuring the integrity of the created product / solution from the point of view of stakeholders are introduced.
      (+2 to the speed of development, +1 to the quality of decisions)
    3. Key concepts of software architecture. Prospects. This lecture reviews the development of architecture as a process and as a document.
      (+1 to the speed of development, +1 to the quality of decisions)
    4. The process of building architecture. This final lecture brings together and allows you to repeat all the key aspects of creating high-quality architecture, including the process of harmonizing and adopting architecture, the process of communicating architecture to non-technical specialists.
      (+2 to success)


    Practice was one of the most difficult aspects. To teach an architect using the examples of “Hello world” or another website of an online store, to put it mildly, is incorrect - this leads directly to the “cargo cult”. Creating a product within a relatively short course, on which you can feel the architecture and its interaction with the business context, is also not very realistic.
    The decision has ripened quickly. Just like doctors, before becoming surgeons, they start with an autopsy - so we decided that at first students would have to dissect an uniquely successful product and try to identify the relationships that allowed the product to take its place. Only unlike doctors, for a successful business and system analysis, it is completely optional to analyze a dead product, living ones are also suitable. :-)

    As part of the course, students in mini-groups are working on restoring the business context and its relationship with the architecture of the public product.

    In this semester, students selected the following products:

    • Search Mail.Ru
    • Twitter
    • Dropbox
    • Yandex.Direct
    • etc.

    Having received a block of theoretical material and fairly tormenting the teacher, the guys are working on a part of the puzzle and presenting 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 have an understanding of the characteristics of various markets and “anatomical atlases” of successful solutions.

    Summarizing the

    course "Business and system analysis for architects" allows you to:

    1. Improve the quality of architectural decisions made, link technical excellence with real user problems and business objectives
    2. To introduce the system into the experience gained in the framework of current and future work
    3. Get the skill of architecture analysis and communication of the analysis results to your colleagues
    4. Based on the experience gained in conducting the course next year, we plan to expand a part of the course that allows students to more efficiently complete homework related to understanding the needs of business and system users.

    Bezugly Dmitry

    Literature used in preparing the course:

    1. Alexander Osterwalder and Yves Pigne Building business models. Handbook of the strategist and innovator
    2. Dean Leffingwell, Don Widrig Principles of working with software requirements. Williams Unified Approach 2002 Ch 8-13
    3. Craig Larman, Application of UML 2.0 and Design Patterns (3rd Edition) Williams 2006.
    4. Clayton M. Christensen Innovator Dilemma. How new companies die because of new technologies2012
    5. Martin Fowler, David Rice, Matthew Fommel, Edward Hayet, Robert Me, Randy Stafford. Enterprise Application Templates
    6. Martin Fowler Analysis Patterns: Reusable Object Models
    7. Nick Rozanski, Eóin Woods, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd Edition) 2011
    9. L. Bass, P. Clements, R. Katzman Software Architecture in Practice (NFR)
    10. Martin Fowler UML. The basics. A quick reference to the standard object modeling language
    11. Alistair Coburn Modern methods for describing 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 Speaking
    14. Michael Rother, John Shook Learn to see business processes. Value Stream Mapping Practice

    Also popular now: