//Artefact:SoftwareBundle/com/sphenon/products/EMOS (5.1) - Working/Architecture

Architecture of an EM/OS Software Production Project
In section Architecture a brief introduction in the elements of a EM/OS software production project was provided. The following diagram shows in more detail the flow of information and artefacts processed by EM/OS.
The two key pillars of this approach are the cleanly organised input information on the one hand side - the lorescroll - as well as the automated production of software, based on this information, on the other.
Elements and Components
  • The lorescroll most prominently contains all information that desribes the relevant parts of your business as well as the properties of your intended software solution.
    The business facts comprise the managed data and how it flows and is to be processed, along with constraints, states, and rules that have to be observed.
    The system properties desribe it's overall externally visible organisation, the various interactions with it, and the selection and configuration of the desired internal architecture.
  • By means of a socalled codingcookbook the domain oriented lorescroll is augmented with the necessary technical knowledge.
    This knowledge comprises architecture blueprints, which describe possible ways of constructing the software (like monolith vs. microservice), coding templates containing the essential knowhow of translating the requirements into source code, and assembly templates that contain the knowledge of how to put the various possible automatically produced artefacts together to get a complete functioning software solution.
  • EM/OS then uses all this information to produce parts and blueprints. The former (parts) are various small artefacts from which the solution can be assembled, while the latter (blueprints) describe precisely how this assembly takes place.
  • The differentiation between parts and blueprints provides the Operational Solution with an additional amount of strong flexibility, so that these at deploy or even at runtime can adopt to your Environment, like e.g. different user interfaces or different databases.
    Finally, Visual Styling information is specified completely independent from your logic and applied in a last step to provide for the desired graphical finish.
Roles
Architecture of an EM/OS Software Solution
The production of Software with EM/OS is based on a variety of input information and can be configured to a large degree. This includes the choosen target architecture, i.e. the selection of produced components as well as the templates of these components themselves.
For this reason, there is no such thing as "The" EM/OS Software Solution Architecture. Nevertheless, the produced systems typically show a potentially high degree of adaptability, which is based on advanced architectural principles, which can be fairly good illustrated given a fully operational full stack component (do not confuse this with a monolith - this may apply to microservices as well, if they provide the respective service layers).
Architecture of the EM/OS engine
EM/OS Components
Roughly speaking, EM/OS consists of two augmenting subsystems, which can be used seperated as well as combined:
  • Application Provisioning System (EM/OS APS)

  • Application Operating System (EM/OS AOS)

Purpose of the APS is the transformation of the models into a form of code, which allows to instantly operate the respective business solution. This includes, among other things, the automatic creation of an amount of optimised program code.
Purpose of the AOS is to run the solution, typically based on material provided by the APS. This includes, among other things, the provision of a variety of infrastructure services, as well as the aggregation of the solution code according to construction plans and adopted to the environment in which the solution runs.
The complete solution, i.e. the AOS in conjunction with the prepared solution code, is called EM/OS Runtime.
Abstraction Levels and Modelling Jobs
While Customers or Business Analysts usually operate with high level modelling constructs, which are sufficient to describe the desired business properties of the solution (Canvases, Definitions, Classes, Processes, possibly Stereotypes), the job of the EM/OS Solution Architect requires more detailed as well as more technical knowledge.
To fine tune the systems to precisely meet the expectations of the customer, the EM/OS Solution Architect specifies business details and technical aspects (State Machines, Properties, Technical Models, Construction Plans, Target Language Code).
Like many sophisticated modern software solutions, the inner workings of EM/OS are complex. A long list of measurements has been taken to manage that complexity, effectively. Yet, to find the optimal solution for a requirement, which might consist of just some proper setting or a few modifications in the model, one needs a good general idea of the interdependencies in the EM/OS system.
The purpose of this guide is to provide this necessary information, organised around recurring requirements topics.