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


Architecture of an EM/OS Software Production Project
The previous section Working/Functioning provided a brief introduction into the elements of a EM/OS software production project.
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.
The following diagram shows in more detail the flow of information and artefacts processed by EM/OS.
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.

As described, EM/OS splits up the information needed to define a software system into two parts: the domain related knowledge, and the technology related knowledge. Then, EM/OS combines this knowledge to automatically produce software from it.
Corresponding to these two kinds of information different kinds of knowhow and contributions is required by people working with EM/OS, which can be described by the following roles:
  • A Domain Expert is in possession of business knowledge concerning the economical, organisational, regulatory aspects of a trade and understands the needs of a company with regard to respective supporting software systems. A good fit for that role is a Business Analyst.

    A Domain Expert provides this knowledge whenever the IT system is to be (re-)designed or adopted to changing needs. In an agile setup, the Domain Expert will cooperate closely with the Product Owner, it is well possible to work in both roles.

  • IT Experts contribute knowledge of respectively relevant technologies. Depending on the given needs, Architects, Frontend and Backend Developers, DevOps and Administrators are able to work successfully in this role.

    IT Experts are not required during normal production of a software system, but only if new technologies are to be integrated into the EM/OS ecosystem, we call this technology assimilation.

  • EM/OS Experts understand the functioning of EM/OS and support both Domain Experts and IT Experts.