The term that I use for my new analysis of system and technical architecture dynamics is Technical Archimetrics. Prefacing Archimetrics with the word
technical is essential because this term is also used in the brick and mortar architectural profession. Not satisfied with simple descriptions of various
technical architectural states my intention is to quantify and qualify these changes with intuitive linear diagrams. Let us first look at what happens when the decision is made to move from a Monolith or ESB SOA Architecture to a Microservice Architecture. Microservice Architecture having many single purpose, decentralized, autonomous, replaceable, small, and simple microservices enables a higher change velocity as a function of time than a multipurpose, centralized, dependent, not easily refactored or replaced, large, and complex monolith.As change velocity increases, system production safety decreases and the probability of production errors or malfunctions also increase. Microservice Architecture only operates at a higher level of system production safety as a function of change velocity when DevOps, operations automation, CD, CI, CDeploy, Agile, and all the requisite changes have been made organization wide to make a Microservice Architecture a success. The fewer the components that a system has and the dependence of each component upon other components or what can be called a Controller Design Pattern where each component is subservient to a core or central logic layer the more monolith the system. Gradation in monolith characteristics - a continuum from non-monolith to absolute monolith is a more realistic measure of system centralization, inter-component dependency, and the flexibility or adaptability of a system to change - its resiliency and antifragility. The monolithic characteristics of a system are a function of the number of independent components that a system processes and their overall autonomy and independence.

Each microservice is synonymous with an individual. Both the microservice and an individual are unique self-contained and expressive units best integrated within an orchestrated horizontal interface. From the interactions of many individuals or microservices emerges a concerted set of behaviors that are deterministic or nondeterministic depending upon a multiplicity of environmental interactions. Orchestration is not autocratic rule, but an adaptable and suggestive set of goals and outcomes that individuals and microservices may resolve to during their interactions with their environments. Overt control is out. Cooperative group goal achievement is in. Orchestration can be achieved in a Microservice Architecture with a Microservice API Platform Management/Gateway (MAPI-PMG) comprised of an API Manager, API Gateway, Developer Portal, and Administrative Portal. The MAPI-PMG can effectively coordinate microservices into meaningful combined system behaviors. Like the laws of our human world that keep us from straying off onto pathways that may spawn emergent group and individual behaviors that could be self-destructive a MAPI-PMG keeps the microservices coordinated - orchestrated towards achieving behaviors consistent with the requirements of the application. Orchestration of micro units whether human or artificial like microservices must still adhere to some form of minimal process restraints or else anarchy is the unintended outcome. Granted, over blown processes, those that strap us and our systems down so tightly that nothing positive can be achieved are not desired. Light, loose, broad goals and outcomes can be best realized in
small groups that meet regularly without the need to maintain burdensome records or adhere to a ritualistic agenda. Cooperative, iterative, collaborative, openly progressive, and Agile process work environments that value the individual over the corporate entity are typically the most successful implementing a Microservice Architecture.