* 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 and business architect's perspective

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;

* Strategy of innovation (search for hypotheses by Lean Startup). Creation and delivery of features and testing of hypotheses about the demand for these features are as fast as possible;

* Integration strategy. It is necessary to develop an open, most scalable and versioned API;

* Adaptation strategy. Not a strategy using Agile to adapt to the market;

* Strategy of quick decisions. Consistent changes.

Difference between Architects and Architects (NEW)

In general, the architecture of a fairly large company is called Enterprise Architect. It describes all levels of detail and the entire scope of the company. For any IT architect, IT interacts with the rest of the company's business. For most companies, the business makes money, and IT provides this opportunity, and understanding how this happens and what needs to be changed the task of the corporate architect. To do this, the corporate architect works with two layers that make up the corporate architecture: business architecture and IT architecture. It is very important to understand that in most cases IT is the backing function of the company, and the architect describes the current business architecture of the company and adjusts the IT architecture so that the described business architecture functions as intended by its creators. The creators of the business architecture are the heads of departments, functional blocks and divisions. They are the ones who know exactly how their departments should work. At the same time, they, too, often do not take it out of their heads, but rely on existing processes, for example, the sales department relies on customer experience that they have received in other companies and to which they are accustomed, or as a result of negotiations. The already formed processes in the business architecture take advantage of the power of IT, but this does not mean that the corporate architect needs to make the IT architecture a mirror image of the business architecture. On the contrary, if several processes have similar requirements, then the IT architecture should unify this, if possible, provide flexibility and scalability in a short time in the wake of changes and growth of the process, as well as offer more efficient ways to solve problems.

Political architecture (or layer of stakeholders) is a layer of stakeholders, their interests and agreements between them. Using the imperial method, it was found that for an architect it is 50 % important to collect information, another 30 % to negotiate, and only 20 % to a choice of technical solutions. With the availability of information, negotiations are easy and their result can be easily recorded. When looking for data, you need to find various solutions. This is a separate skill – the squeak of alternative solutions on the required data, called divergent thinking. During negotiations, it is important to listen to other people, offer different options, focusing on (sell) the best solutions, and find compromises. On the basis of already available data from a large number of solutions, it is necessary to find the best solution, which usually does not cause difficulties for quiet specialists, since they are accustomed to convergent thinking. For the architect, the main contractor (the main stakeholder) is the owner of the product for whom the architecture is being made. There is only one exception if decisions are made by other stakeholders, and the product owner simply broadcasts these decisions. Other stakeholders: the customer (or owned the product, as its representative), developers (minimization of work, clear setting of tasks, Time2Market), service departments (implementation of their standards), service architect (guaranteed service operation), corporate architect (landscape maintenance). If there is no common language, then either the architect of this area, or the owner of this area, need to escalate. For example, if there is no common language with the service team, you can escalate either to the service owner or to the service architect. If the language is not found with the owner of the service, then it is escalated to the architect