Phase 1: System Structure#

Phase 1 defines the basic structure of the overall enterprise landscape: software components that communicate over defined interfaces.

Components and APIs belong to Systems, defining the fundamental building blocks a the system landscape. Systems in turn are structured hierarchical into Systems and Sub-Systems.

System and SystemInstance#

A System and its contents is the foundational building block of an enterprise IT landscape. The same abstract System may be running any number of times and in multiple different contexts. Each separate instance is described by the SystemInstance resource

Any number of Systems can be combined in a hierarchy, to model complex systems composed from numerous (sub-)systems. The sub-systems are linked through the use of the Parent relation.

For comparison, consider this somewhat more complex complete system of a CQRS-Application

On one side the view of the connected system instances:

The instances detail the actual communication relationships between the components. They form the complete system landscape, as it is assembled when the individual systems are instantiated. And each API must have exactly one component that provides it and zero or more components that consume it. The only exceptions are abstract systems, that form a black box: they only document the APIs that they provide, not their internal makeup.

The other view is the list of systems.

They define the building blocks from which the system landscape is assembled.

Component and ComponentInstance#

A Component resource represents any form of executable logic, regardless of the format (e.g. interpreted script, binary executable, container, etc.). It communicates with other components via interfaces represented via API resources. The APIs exposed by a component belong to the same system as the component. APIs consumed by an component may either be in the same system or a separate one.

It is important to understand, that Component documents intent, not configuration! Consider a commonly used software like the NGinX network proxy. Depending on configuration it may be used a authentication proxy, load balancer, cache or to as a web server, serving static files, and many more use-cases. Each use of the same basic software needs to be modelled as a separate component, potentially in it own (Sub-)System.

Tracking the exact configuration, that is required to enabled the desired behavior, is out-of-scope for EmELand. EmELand does not attempt to replace configuration management or deployment tools like helm in its values.yamlfile or the Open Component Model (OCM), but rather to aggregate part of their information.

Optional Components#

There are no optional components within a given system. To be valid, all Componentsof a Systemhave to be instantiated in a SystemInstance.

But the rule set by the model does not force all subsystems to be instantiated for a given system. Thus parts of the overall complex system become optional.

API and ApiInstance#

An API represents a potential communication channel. Multiple technical elements may be part of the same API (i.e. a Kubernetes Service, Kubernetes Ingress resource, a load-balancer, a firewall rule.) The details depend on the mapping and implementation. A potential example is sketched below:

Rules#

1. Every ComponentInstance SHOULD have a context defined.
2. A System MUST be versioned. If a given System has multiple current versions, a SystemInstance MUST indicate which version of the system it belongs to. An SystemInstance MAY belong to multiple version of the same System, if this is supported by the mapping and the implementation.
3. An API SHOULD be versioned.
4. An Component SHOULD be versioned
5. A System with a Parent relationship set to another System does not require to be instantiated when the parent System is instantiated.

Background#

The EmELand model is based on ideas from the C4 architecture model: a system having (software) components and interacting via APIs with the outside world. For more information on C4 see its definition on c4mode.com. For more tools able to process C4 model information, check out c4model.info.

As EmELand is aimed to support managing complex IT landscapes, not develop software or software architectures, only the two top most layers are mapped into EmELand to describe the structure of the IT landscape.

System Context#

The top level diagram of the C4 model ist the System Context. It documents how users with the elements of the system to generate value.

Containers#

“Containers” in the C4 model are not the same as OCI containers, but rather self-contained elements of code that can be executed to provide a given function. It not only allows the naming of software artifacts that are utilized to provide a certain functionality, but also which of these containers communicate with each other.

Why not the rest?#

The C4 model has two further layers: Components and Code.

You may choose to use these other layers of the C4 model. But they are not as relevant for the enterprise landscape. You may also have a different method of designing and modelling software architecture.

Much more relevant is the fact that you may not have this information, if you are using proprietary software. A software vendor may even try to keep you from discovering the C4 containers, e.g. in hardware appliances. But in order to ensure control over the communication intersection of your overall landscape, you must force vendors to give you this information.

Using the information#

Generate the Communication Intersection#

The information described in the resources of phase 1 allows the easy generation of a list of APIs, and thus communication relationships, which connect the components in two sets of contexts. This is the basis for a number of thread modelling and compliance applications.

Identity#

By auto-discovering the running instances and mapping them to the abstract definitions an identity can be assigned, which in turn allows the direct addressing of the instance, when analyzing deviations between plan and reality.

Areas of further Research#

Parent Relation for SystemInstance#

Currently only the abstract System is part of a hierarchy, due to the parent relation. The SystemInstance does not, and relies on the structure of the parent.

Should use-cases be found, which require a parent field in the SystemInstance resource it may be added.

Following the design goal of minimal required structure it is currently left out on purpose.