It is necessary to separate two levels of separation: technological and domain. Technological features in the work are the same, since that services, that its components, if it is divided into component parts, are technologically launched and supported in the same way. But, unlike services, which must be minimally interconnected with other services and must provide a specific API and SLA, the components are tightly coupled. The reason for the separation into components is of a technological nature. For example, an online store contains services such as the online storefront itself, payment services, warehouse services, and the online storefront is a service on the CMS Joomla! and a database management system (DBMS) MySQL. Here, the division of the service into its component parts occurred due to different software products written in different programming languages. At the same time, for the customer this is a single service on CMS Joomla! performing a single function of providing an interface for ordering to users online, provided by the hosting as a single service (it will not work separately), can work as a catalog of goods without other services (payment, ordering)… From a technological point of view, the components are services:

* Singles are not functional;

* Strongly connected, as many requests are generated for each request to the CMS;

* Interaction interfaces are complex and varied – not even the API is used here, but the SQL interaction language;

* Strongly connected functionally through a complex technical API – only known to the user supported compatibility of some CMS versions with other DBMS versions.

Dividing a system into microservices begins with an analysis of their boundaries, an analysis of the benefits of separation and the added complexity of a distributed system. It is better to separate microservices when there is a combination of need:

* Technological necessity, for example, a large load that is difficult to withstand without separation, for example, scaling, another type of support (SLA);

* For business, the dedicated service is already a separate and little dependent function – further we will consider the DDD (model-driven design + ubiquitous language) approach to the implementation of microservices;

* Requires change of technology platform.

Microservice meets the following characteristics, according to M. Fowler (martinfowler.com). They can be summarized as:

* 1. Must be a component or service. Each microservice is a complete, full-fledged independent service from the point of view of the developer, system administrator and user. It should be able to be easily replaced with another, both in the developer's code, both in the process of work (should be), and presented to another or removed in the user interface. Failure to fulfill the conditions of interchangeability at different levels lead to one service divided into parts – a distributed monolith;

* 2. Organization of business opportunities;

* 3. Products are not projects;

* 4. Smart endpoints and silly connections. Does not require complex integration with debugged services (the integration of complex systems is handled by a service oriented SOA architecture);

* 5. Decentralized management. This refers to orchestration like Kubernetes, network management like Istio, delivery management like KNative;

* 6. Decentralized data management. Due to the self-sufficiency of the service and independence from others, it must have an independent state – a database, and so that the choice of a database management system is independent – there is its own;

* 7. Automated infrastructure. The process of deployment, scaling and rollbacks should be automated, which allows you to quickly automatically rollback, fix the isolation of the service in the code;

* 8. Provided for refusal to work. To visualize failures, you can look at Jaeger and Prometheus, to localize problems, services must be isolated, represent one single service, which allows you to isolate, limit the harmful effects on other services in case of failure and automate rollback;

* 9. Evolving design. The system grows outgrowths in the form of services – it becomes overgrown with them, while its structure does not need to be changed. Neal Ford and Rebeca Parsons in "Microservices as Evolving Architecture" focus on continuous improvement.

Business architecture (Enterprise Architect) is the IT architecture of the entire company. It 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 business are called the IT landscape because it contains many systems that do not form a single whole, connected by the business processes in which they participate and which are not limited by them. The Business Architect (Enterprose 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 taken shape and difficulties arise in its development and adaptation to changed conditions, a minimum capable product (MVP) is created in technology startups. The business architect of the corporate IT landscape must solve problems with a low rate of changes (due to the impossibility of local testing, postponing distributed changes, a breakdown claim after rolling distributed changes) – Time To Market, quick adaptations to user expectations – Customer Experience and cost – Cost… The first is tackled by the architect's sequential tidying activities, reducing cohesion and confusion, which simplifies and speeds up the process of making changes and, as in any knowledge-intensive field, where the main cost is the man-hours of workers, reduces the cost. More and more often, the architect is not provided with the requirements, he connects at the earliest stages of their formation, after his capabilities are severely limited. To do this, he needs to actively participate in negotiations and meetings in order to adjust the requirements. Further, to 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. Further, to form an architectural committee, at which to propose solutions for the choice and adjust the choice towards the optimal one.

Changing the existing architecture can be carried out in three ways: supporting the current one, completely replacing the current one, complementing the current one. Replacing the current one requires a long and lengthy study of the functionality of the current system, then finding out the functionality that is currently in demand and searching 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 will be received in the development of the system, since the customer does not need a technical update of the existing functionality, but he needs new ones and the correction of the old, and even more so not for the time and funds that were spent on creating the current system. With the consistent improvement of the system, fundamental changes to the system cannot be achieved, since the architecturally different functionality of one part contradicts others and changes in the architectural style are not achieved by successive improvements of the parts due to the complex nature.

The Enterpris Architect strategy implements different company strategies in different ways:

* Growth (scaling) strategy when the market is free – the architecture unifies and debugs processes;