Architecture
ISO / IEC / IEEE 42010 defines architecture as the Basic concepts and properties of a system in the environment embodied in its elements, relationships and specific principles of its design and development. There are quite a few varieties of it, but we will single out the main ones according to the level of abstraction: application architecture (Application Architecture), software architecture (Software Architecture), application architecture Solution Architecture and business architecture (Enterprise architecture). The application architect develops the application architecture (design patterns, task allocation) and often combines his role with the role of Team-Lead and the leading developer of critical components. Software Architect does the same thing as the build architect, but works with several teams, adding the unification of the technologies they use. Often this position is in demand in outsourcing, where there are many projects and it is possible to take the load off Team-Lead so that they communicate more with customers and the team. This position is characterized by the requirements for a vacancy in knowledge of the programming language and the main stack used on projects. In such a situation, the architect is limited in choosing technologies and hiring new employees. Since its appearance in 1959, the architect has been engaged in the decomposition of the system, the distribution of parts by developers, and was responsible for the subsequent integration of the developed components into the initially required system. Now the situation is simplified with the advent of micro-services.
The corporate architect designs the relationships between the systems using the enterprise data integration bus, and the application architect designs the systems themselves, decomposing them into applications. The boundaries between applications are determined by the boundaries of use: development, deployment, provision to the supplier. Previously, applications were also united by technological platforms and technologies, but with the advent of containerization, the situation may contain components created on different platforms, languages and stacks, enclosed in containers. Also, the formation of borders based on rolling out the application has lost its relevance due to the fact that the components (container) are rolled out and are already being tested in the environment of other components. Ideally, a group of micro services is grouped by the function of the business and the team developing it, but often common components participate in business processes, which blurs the boundaries of applications. This specificity led to the emergence of a separate specialization – Cloud Solution Architect.
Based on the level of architecture that is supposed to be designed, it is possible to turn from an abstract question – how to become an architect – into a set of requirements necessary for solving the task: from purely technical to organizational. So a software architect can delegate all organizational activities to Team Lead and focus purely on the technical description of the program structure, and often he is a pure techie and part-time Tex-Lead, but he can not delegate the technical one. In contrast, a corporate architect may not be a technical specialist, for example, a director, conducting communication to organize communications of automated systems and meet these systems with the needs of customers. Based on this, one can guess that the question – how do they become architects – can be answered that architects before Solution Architect are evolutionary in technical branch, and corporate, either in technical branch, or managerial, including business analytics. At the same time, you can become an architect at any number of years.
