Enterprose Architect participates in the service development process at least in two stages – checking the developed conceptual architecture of the service and checking the compliance of the detailed architecture of the developed service with it and the standards for acceptance tests. In practice, he makes the conceptual architecture of the service himself and adds it to the service map himself, so he has the necessary experience and knowledge of all standards. In practice, Enterprose Architect assists the service architect in developing the detailed architecture of the service in its drafting and conceptual architecture in accordance with the vision of the service architect. In fact, the conceptual architecture is the architecture for integrating a service with other services to bring it into the service landscape, while the detailed architecture is the implementation of the service in accordance with the expectations of stakeholders (customers, controlling departments). It is the implementation that must comply with the restrictions imposed by Enterprise Architect on the implementation, for example, to unify technologies. If there is no collaboration, then Enterprise Architect becomes a regulatory body that blocks the deployment of the service with critical remarks or sets a technical debt with a deadline for elimination.

An enterprise architect, when developing a conceptual architecture, negotiates with the service architects with whom his service needs to integrate and finds compromise solutions, as well as other stakeholders, such as security personnel. Having agreed, he brings to a higher level of agreement, to confirm the consensus. An enterprise architect needs knowledge of services and standards, communication skills and knowledge of integration architect, such as an enterprise service bus and the ability to quickly create an architecture with insufficient information in a tightly constrained time frame.

A more lenient auditing-based standards review process can be applied, which can often be boiled down to checklists or automatic compliance checks. In practice, the service architect can go through such checklists under the guidance of Enterprise Architect for correct interpretation at the very beginning and then go through as necessary to correct compliance. Modern systems provide their setting in the form of configuration files, which allows automating the check against a list of such systems and their configuration files. Most of them work in asynchronous mode, that is, the states of the corresponding systems are asynchronously brought to the state described in these configuration files – IaaC. In most cases, the state to which the system is reduced can be obtained in a declarative form in either JSON or YML format. These formats are compatible and mutually convertible. There is an OPA (Open Policy Agent) project by the CNCF (Cloud Native Computing Foundation) consortium that allows you to create rules in a declarative form to check that they match JSON configurations. The check is carried out in a synchronous and asynchronous manner. For most systems, the application of changes is possible in the form of IaaC, that is, as sending new configuration files to the systems, on the basis of which the state of the systems is brought into conformity with them. In fact, the differences between them apply. This means that you do not need to check the current state of the system, but you can check the poisoned configuration files themselves. As a result, we have a configuration file for validating changes in a declarative format – GaaS (governance as a code). Let's look at a few layers to check: