Component Model 1-2-3 (CM 1-2-3) is an application architecture modelling approach, in which a target application is depicted on different abstraction levels: 1) context-, 2) composition- and 3) component levels.
Component Model level 1 (CM-1):
- Context of a solution of a Business Architecture. Solution Architecture of a solution in context.
- Typically a single application, a building block of the entire business architecture of an enterprise.
- Represents the external contextual aspects of an application: users and interactions with adjacent applications.
- The target application is depicted as a black box, its external services, interfaces and interactions are relevant. Its internal structure is not interesting at this abstraction level.
Component Model level 2 (CM-2):
- Composition of the target application, the main components of within the system boundary.
- Represents the internal behavior and structure of the target application.
- The target application is depicted as a white box by illustrating how it is decomposed into main components (a.k.a. sub-systems or modules), what are their responsibilities, and what interfaces are provided and required. Interfaces can be user interfaces (GUIs) or application interfaces (APIs). The internal components are depicted as black boxes at this abstraction level.
- The technology choices per each component can also be shown, as the composition represents an executable and deployable unit.
Component Model level 3 (CM-3):
- Each (main) component can be depicted in detail whenever appropriate as white boxes.
- This abstraction level zooms into individual components by showing their internal behavior and structure.
- This level of diagram can be useful if the component is complex.
An application consists of components (modules), each of which consists of components.
Note! An application (a.k.a. system) refers to a component of the overall business architecture of the enterprise.
The component model approach is illustrated in the figure below. A target application (“Application A”) is depicted in different levels of the component model.
Component Model example diagrams of example target application named “Order Handling System” below.
CM-1 Context diagram example. Introducing external users, adjacent applications and interactions.
CM-2 Composition diagram example. Introducing internal sub-components (modules) such as interfaces (GUIs and APIs).
CM-3 Component diagram example.
Application Architecture
Application architecture describes the logical structure of an application. Application architecture introduces both the external and internal aspects as follows:
- Externals: who are the users and what information is switched with other applications?
- what are the internal parts based on which the application is composed?
Application architecture can be modelled with only a few elements of EDGY:
- Asset element and
- relationships Link and Flow.
This simplicity of the EDGY makes it productive, as the modellers can concentrate on the problem instead of notation. However, the EDGY is expressive enough, and it is easy to do and easy to use. Everyone can easily understand EDGY diagrams.
The asset element is a multipurpose element, which can be used for modelling any kind of structural asset of an enterprise, e.g.:
The EDGY elements can be added with labels that express additional information. Labels enrich the usage of elements by providing extra information or any kind of characteristics that are meaningful in the context. There are two kinds of labels: 1) tags and 2) metrics.
Relationships between architectural elements are typically either 1) structural or 2) dynamic by their nature. The link defines a structural association between two elements, and the flow defines dynamic influence or data flow between two elements.
The structural relationship between the elements can be modelled explicitly with the 1) link relationship or 2) by nesting the elements as shown below.
Structural relationship with explicit link relationship can introduce the characteristics of the association (e.g. “Is part of”).
Dynamic relationship typically introduces the data object that is switched between the elements.
Tag. Different types of elements can be distinguished with the tag element. This can be necessary when it is important to precisely express the characteristics of elements. The use of tags makes the diagrams easier to interpret as the types of assets are made visible with declarative text, instead of special symbols that require extra knowledge.
It suggested defining organisation context-specific asset types as tags, according to what is appropriate and fit for the case, and then providing those tags within re-usable legend elements as shown below. This encourages to consistent modelling style.
There is a common set of asset types concerning application architecture. The minimum viable set, the short list, consists of the most typical asset types: 1) application, 2) system software and 3) data.
Examples of tags are shown below.
Some other examples of tags are shown below.
Assets and tags simplify the architecture for both modellers and users. The diagrams are easy to create and easy to understand:
- there is only a single element, the asset, for depicting any kind of asset,
- tags can be used for adding explanatory information to assets when appropriate.
Metrics can be used for adding extra qualitative or quantitative definitions, or any kind of classifications such as risk assessment, priorities, criticalities etc.
Examples of metrics are shown below.
Application Integration patterns
Application interactions a.k.a. integrations between applications can be modelled with the flow -relation. The basic integrations illustrate what business data is transferred in which direction as shown below.
Extra semantics can be added into flow relationships e.g. by line color and width.
Extra semantics can be added to the line, such as protocols, mechanisms, volumes or frequencies.
Deployment Diagram
An example of technology architecture is shown below. This deployment diagram visualizes the run-time environment of a business application.
Examples & Patterns
Application architecture patterns introduced below illustrate the usage of these architectural elements.
Three-tier architecture. A classic example of introducing the application’s internal structure is the traditional three-tier architecture, which consists of the following tiers:
- presentation tier (a.k.a. user interface tier),
- business logic tier, and
- data tier.
These tiers altogether represent the separation of concerns, and the functional decomposition of an application into structural parts. Each tier has its specific responsibility, and the whole application is composed of these individual tiers and their functionalities. As these tiers are the structural parts of the application, they are included in the application by nesting. (Similarities to the Model-View-Controller pattern).
Layered Architecture is analogous to three-tiered architecture. The same basic structure is now defined with other names of the parts, e.g. tiers are called layers.
Notes:
- Additional information can be included in the asset elements – if that can be done without making the diagram too “busy”. It must be considered carefully how much information is enough, and how much is too much.
- Tags are not necessary when the diagram introduces only structural elements (components) of the same type, or the types of the elements are implicitly clear.
Assets can be used for representing e.g. application or technology a.k.a. system software as shown in the figure below. When an application includes system software elements, then tags can express their type (such as Front-end, Back-end, User interface, Business logic etc.).
Model-View-Controller (MVC) pattern is compatible with the three-tiered and layered architectures. The MVC divides the application into functional components, each of which has a specific role and is responsible for certain functionalities: presentation, business logic and data access.
Input-Process-Output. As architecture defines the structure of an application, then the application consists of structural elements – all of which are modelled with the asset element. The basic pattern of an application consists of the following elements: a) input data, b) processing unit (hiding the internal behavior as a black box), c) data storage and d) output data. This view introduces the basic concepts. The application is an active structure element, that performs certain behavior for processing the input and producing the output. The data objects (input and output) are passive structure elements.
Extract – Transform – Load (ETL) pattern represents how data is retrieved, processed and then loaded. ETL process consists of the following phases:
- extracting is data retrieving/fetching from the source (typically a data source, but can be e.g. cloud service, analytics tool etc.),
- transforming is processing (e.g. cleaning, enriching) the input data (source-, raw data) and
- loading phase is storing the transformed output data into the target storage (e.g. database, data warehouse, data lake).
The behavior of the application is modelled with the Process element, which represent any activity taken (by some structural element of the enterprise, such as organisation, application, component etc.). An alternative way of modelling the ETL is based on the asset elements only as shown below. The choice between asset and process depends on the context and what is appropriate and fits the case.
Nesting elements. Elements can be included in other elements. That can be done when there is a hierarchical structural dependency between the elements: an element belongs to another element. Or, there can be a behavioral dependency between the elements: an object performs an activity, e.g. an organisation performs a process.
This modelling style has advantages e.g. as follows:
- simplicity; the structural dependency hierarchies are illustrated without (link) relationship elements, and
- compact layout; The diagram can be modelled into a more compact form, as space is ‘economically’ saved by including elements with others.
Examples:
- Organisation makes products/services,
- Organisation has capabilities,
- Organisation performs processes,
- Organisation has applications,
- Capability consists of processes and assets (of diverse types, such as applications and data),
- An application consists of components,
Nesting elements of a capability: processes, applications, data and people included in the capability, which is a wrapper ‘container’ for things that belong together.
Another version is shown below.
Several tags and/or metrics are associated with an asset element. There can be cases where an asset element can be associated with several tags and/or metrics, which can be positioned one below the other (figure below). However, these needs are quite rare as the context typically explains the types. For example, an application architecture diagram titled “application architecture” implicitly implies that the asset elements are applications.
Principles
Principles. The asset elements can be resized based on the content such as text, tags or metrics. However, the size can comprehend the meaning of the importance: a bigger element can be considered more important than the others. The suggestion is: to keep the elements with the same importance at the same size.
Principles:
- Model only what is relevant (limit width and depth: scope and level of details).
- There are not too many elements in the same diagram (split, use abstraction levels).
- Only elements of the same abstraction level into the same diagram.
- The elements are of the same size.
- Elements are aligned.
- Connecting lines aligned, no crossing lines.
- Harmony, symmetry and balance of elements.
- Use colors with care: not too much.
- Less is more (minimalistic approach: as little as enough, not as much as possible).
- Simplicity (KISS = Keep It Simple, Stupid).
Business Architecture
In the Business Architecture of an enterprise, everything starts from the capabilities – according to the capability first principle.
Capabilities are the business components of a modular operational business of an enterprise.
- Use the Capability Map as a base map of the operational business of the enterprise
- Identify the capability (or capabilities) supported by the target application
Capabilities are the basic building blocks of an enterprise’s operational business.
All are components:
- Capabilities are components of the operational business of an enterprise
- The Business Components of a Composable Business
- Applications are components of Capabilities
- Applications are compositions of components.
Operational business consists of business components, the capabilities. Capabilities consist of application components. Application components (systems) consist of sub-components, such as modules or sub-systems. Each sub-component can consist of further components…
A common application architecture modelling approach:
- Start from the high-level big picture and then go into the details
- Focus on a single application
- Zoom into the details
Levels:
0 = Capability level of the operational business of the enterprise
1 = Context of a target application (external interactions)
2 = Composition of the application (internal structure)
3 = Component of the application (structure of a component)
Capability-based Design
The capability map represents the base map of the operational business of an enterprise. The capabilities are modular business components from which the operational business is composed. The capabilities are at the heart of the composable business.
“Composable business is a natural acceleration of the digital business that you live in every day. It allows us to deliver the resilience and agility that these interesting times demand.”
Daryl Plummer, Distinguished VP Analyst, Gartner.
Capability-based design starts from the capability map. Every change activity can be directed to a certain capability or capabilities. Capabilities are the core building blocks of the business architecture. All the other elements are composed into capabilities, such as people, processes, and assets (applications, data etc.).
The capabilities are enterprise-level components of the business:
- Operational units of the business
- Design and development units of the change activities
- Management units of the enterprise, both at the strategic business management level and the operational level.
References
[1] Intersection Group pages, https://intersection.group
[2] Enterprise Design with EDGY pages, https://enterprise.design/
[3] EDGY language foundations, book, 2023, (available as pdf), link
[4] EDGY 23 Language Foundations, Online course (4 weeks), Milan Guenther & Wolfgang Goebl, link
[5] Enterprise Design Patterns, Intersection Group book, 2020, (available as pdf), link
[6] EDGY 23 product release, launch on 29th March 2023, webinar recording, Milan Guenther & Wolfgang Goebl, link
EDGY tools
The Enterprise Design language, EDGY, from the Intersection Group, enables people to design well-designed outcomes for better enterprises!
EDGY diagrams can be created with several tools, such as:
- Draw.io (available as Confluence plugin, which enables lots of features for combining diagrams, text and tables)
- Miro
- QualiWare
- BlueDolphin
- PowerPoint (stencils)
More to come, e.g.:
- MS Visio
- Sparx EA
EDGY stencils (+ lots of information) can be found on the Intersection Group’s Enterprise Design with EDGY pages:
Enterprise Design with EDGY – for creating well-designed outcomes for better enterprises.
Check how C4 model kind of diagrams can be done with the EDGY:
Load EDGY and C4 model mapping pdf
— Eero Hosiaisluoma