services in case of failure and automating the rollback.
9. Evolving design. The system builds up processes in the form of services – overgrows them, and no change in its structure is required. Neal Ford and Rebeca Parsons in Microservices as an Evolving Architecture focus on continuous improvement.
Business architecture (Enterprise Architect) is the IT architecture of the entire company. She operates with abstractions and entities at the business level, these are strategies, business processes, services and the like. The systems and interconnections that support the work of a business are called the IT landscape, because it contains many systems that do not form a single whole, connected by business processes in which they participate and which are not limited to them. The business architect (Enterprise Architect) works at this level, adjusting the current landscape to the current needs of the business. Often, for traditional companies that did not develop in the high-tech sphere in the blue ocean, it is attracted when the IT landscape has developed and difficulties arise in its development and adaptation to changing conditions, a minimally capable product (MVP) is created in technological startups. The business architect of the corporate IT landscape should solve problems with a low rate of making changes (due to the impossibility of local testing, postponing distributed changes, breaking down after rolling distributed changes) – time to market, quick adaptation to user expectations – customer experience and cost – cost. The first is solved by the architect’s consistent efforts to restore order, reducing coherence and complexity, which simplifies and accelerates the process of making changes, and, like in any high-tech field, where the main cost is the man-hours of workers, reduces the cost. More and more often the requirements are not provided to the architect, he is connected at the very early stages of their formation, after his possibilities are very limited. To do this, he needs to actively participate in negotiations and meetings in order to adjust the requirements. Then form several possible solutions with different levels of complexity, from simple and fast but not effective ("solutions on the knee"), through the optimal, and to large-scale and flexible. Next, form an architectural committee on which to propose solutions for the selection and adjust the selection towards the optimal one.
Changing the existing architecture can be done in three ways: maintenance of the current, full replacement of the current, addition of the current. Replacing the current one requires a long and lengthy study of the functionality of the current system, then clarifying the functionality that is currently in demand and conducting a search for differences between the current functionality and the expected one, after which the cost and development time are calculated. During the presentation, in most cases, a refusal to develop the system will be received, since the customer does not need a technical update of the existing functionality, but he needs new and adjustment of the old one, and especially not for the time and money that was spent on creating the current system. With a consistent improvement of the system, fundamental changes to the system cannot be achieved, since the architecturally different functionality of one part contradicts the other and changes in the architectural style are not achieved by successive improvements of the parts due to the complex nature.
Strategy Enterpris Architect differently implements different company strategies:
1. growth (scaling) strategy, when the market is free – architecture unifies and debugs processes.
2. innovation strategy (search for hypotheses by Lean Startup). Creation and delivery of features and verification as fast as possible hypotheses about the demand for these features.
3. integration strategy. An open, most scalable and versioned API needs to be developed.
4. adaptation strategy. Not a strategy, using Agile Market Tuning.
5. quick decision strategy. Successive changes.
Often in small organizations, DevOps is the only person who understands the device at all levels, and as a system administrator, the infrastructure and installed applications, and as a programmer, a developed application software part, and as an automator, business development processes. The position of an architect in large companies implies familiarity with architecture management methodologies:
1. TOGAF (The Open Group Architecture Framework) with the Archimade program;
2. Zachman Framework;
3. DoDAF;
4. ARIS (Architecture of Integrated Information Systems) with ARIS Express.
For DevOps, the general concepts of the product creation process and its implementation are important, so let's take a general one from the popular ones. If a company has an implementation specialist, usually either Tex-Lead or Team-Lead, who sees in detail how his application will be arranged and created by his team, then he can play the role of Application Application. This is a common practice and a necessary condition, since the application is highly interconnected, and you need a person who knows in detail how it works and how changes in one part of it will affect the others. If such an examination cannot be found, the application must be divided into parts and fix the connection interfaces. To divide the project into parts, it is necessary to divide the team itself, developing it, into parts in accordance with Conway’s law ("Organizations designing systems are limited to a design that copies the communication structure in this organization"). With such an organization, when the application is still one, but divided into parts, Tex-Leid and Team-Lead, having an understanding in each part and can embrace the implementation of the entire application, can get expertise from the narrower members of their teams when their expertise is not enough . If we are talking about Software Architect or Technology Architect, then now unification takes this role, respectively, in the form of containers and virtual machines. If we are talking about an application system, then it is necessary to operate with a higher level of design, such as Information Architect (System Architect and Solution Architect), in which it is impossible to combine design and implementation, since it is necessary to design a group of systems that will be developed by different teams. If the relationship is simple, and this is solved by coordinating the leads of these departments and the architect is not required. An architect is needed when the whole system is being developed and it is necessary to replace the component in the current system with a component incompatible with the current system, when it is necessary to change the organization of the components, and the expertise of the implementation specialist is not enough, then you need to see the whole system, the formation of which the architect is engaged in. It is extremely important for him to understand the various programs, and how they can interact with each other, while deep expertise in all areas and the current situation in the teams is difficult to achieve, but there are leads for these teams. Once it was decided to make such large-scale changes and critical changes, the architect needs to work closely with business (stakeholders) so that the new system meets the expectations, and the transition is not so painful. Beginning in 1962, the Master Plan for Information System proposed defining the necessary infrastructure, analyzing the current one, identifying differences, drawing up a transition plan, and implementing the transition. Following the plan and its detailed description is a key requirement for a successful transition and achieving the final state of the system. Due to the heterogeneous nature of the implementation, in 1988 Stategic Information Planing divides the architecture into technological, system, functional, and data architecture. In 1992, layers appeared in EAP detailing: planning, a business layer, information (data, applications and technologies) and a layer of implementation and migration, which made it possible to speak their language with business and IT. Further, in 1995, to reduce the risks of changes and obsolescence of the requirements for the final system, TOGAF proposes to divide the whole process into parts ("cycles"), each of which will be presented by a separate implementation project for a separate manager and combined into a "project program" for which the authorized manager. The interactivity of the architectural cycle itself is close to the spiral approach in development and also requires the invariability of the result in the project. At the current iterative cycle, you cannot accept changes from interested
