Application Architecture (or Solution Architecture) can be modelled with precisely the same set of ArchiMate diagram types as other levels of architecture (Enterprise- and Domain levels). However, what is specific to Application Architecture compared to other levels of architecture, is that we’d like to understand and model the internal structure of an application as follows: 1) what are the main components of the application, how it is modularized, 2) how those application modules (sub-components) interact, and what is their role and purpose.
Application architecture can be depicted with small subset of ArchiMate elements: Application Component, Application Service and Application Interface. Relationships between those elements can be modelled with ArchiMate few relationships as follows: structural relationships (Composition, Assignment, Realization), dependency relationships (Serving, Access) and dynamic relationships (Triggering, Flow).
Application Architecture (or the Solution Architecture) can consists of several distinct diagrams, some of which are introduced here. A Layered View can be used as an overview context diagram of the target application. The other diagram types can vary depending on the case, some examples are shown below.
Application Architecture Overview – the Context (Layered View)
The context of an application can be illustrated by utilizing the Layered View. This granularity of building blocks can be shared between the architecture levels from Enterprise Architecture to Application Architecture (Solution Architecture). There can be many variations of the Layered View, an example is shown below.
The main advantage of the Layered View is to illustrate the usage of applications in business processes and business services they provide. Again, the Layered View provides a way to model the infrastructure on which the applications are running. The Layered View can be applied to fit for purpose, only relevant layers can be modelled depending on the case and what is appropriate. BTW, it is always good practice to name relations by labels, for example “serving”, “realizing” etc.
WHY This Application is needed?
The most important thing related to each and every development target is to analyse WHY it is needed. This applies to every building block in an enterprise architecture. When designing a new application or defining changes to an existing application, it is valuable to analyse why-questions such as: which stakeholders are interested on new features or changes, what are the drivers for change, what are the goals etc., and finally: what requirements can be defined for change. These can be modelled with a Goals View by using ArchiMate Motivation -elements.
With the Goals View it is possible to analyse to WHOM and WHY an application is needed, and what is the business relevancy. How the application supports the business (processes) and how the application interacts with other applications can be modelled with other diagrams such as Layered View, Application Co-operation View for example. Those diagram types answer to question WHAT. For more detailed business analysis, specialized diagram types can be used such as Business Model Canvas (BMC) or SWOT.
Application Co-Operation View (Data flows)
This informative view can be used for introducing interactions between applications: what information they switch and to which direction the information flows.
Application And Data
This view introduces the data objects accessed by the applications. Now exactly the same data objects are explicitly modelled as shown as labels of the data flows in the diagram above.
Another variation how applications access the data objects shown below. This view visualizes the ownership of the data objects. When using nesting (placing element inside another element), the “write access” relationship is hided (but still exists in the repository).
Application Structure View
This view is useful in designing or understanding the main structure of an application and its sub-components and the associated data. This diagram can be used e.g. to break down the structure of the application system under construction, to illustrate modularization /decomposition: what are the sub-systems / sub-components what are the application services (or application interfaces) they provide.
Note that application services (figure above) are the behavioral functionalities that are provided by the structural interfaces (figure below). Application Interface is more concrete, representing the actual interface in the form of a) user interface (GUI) or b) application-to-application interface (API)
This view below connects the application services with application interfaces. As application services are provided via application interfaces, this view can illustrate which application services are exposed with which application interfaces.
This variation below is using nesting when showing which application services are provided by which application interfaces. Note that using nesting (element inside another element) is not visualizing the relationship between elements explicitly, but the relationship (assignment in this case) is existing in the repository nevertheless.
Application services and application interfaces are the “different sides of the same coin”: a) behavioral services and b) structural interfaces. Both of them can be used for modelling interactions. Which one to use depends on the case and purpose. Application interfaces depict concrete user interfaces (GUIs) or app2app interfaces (APIs) with operations. As such, application interfaces can be used for modelling actual dynamics between applications, or between users and applications. Application services instead, can be used for modelling functional dependencies and interactions. Next chapter introduces different modelling options to depict interactions between applications.
GUI = Graphical User Interface, API = Application Programming Interface, both interfaces of an application. The former provides application services to the users, whereas the latter provides application services to another applications. According to ArchiMate specification: “An application interface represents a point of access where application services are made available to a user, another application component, or a node” (link).
Application Integration View (Dynamic relationships)
Several alternative approaches of modelling data switching between applications are shown in the examples (1 to 10) below.
- “Application A” owns a data object “A-1”, which is requested by “Application B”.
- Data flows from “Application A” to “Application B”.
- “Application A” realizes a service “A-1” that is used by “Application B”.
- Practically, “Application B” requests the Application Interface “A-1” and gets response…
Application Architecture View
This view mixes EA level and solution level approaches, as there are are both applications and application modules (sub-components) in the same view. This is not suggested, as this mixes components from different “levels”. However, this can be used to put all-in-one diagram to avoid several different views, if the development target is not so complex..
Note! Application Service A-3 seems to be a type of user interface (GUI), whereas the other application services are type app2app interfaces (APIs).
Application Component Model (0-n)
Application Component Model 0-n is an application architecture modelling approach, which consists of diagrams of different abstraction levels as follows:.
- At 0-level the diagram describes how the application interacts with its environment, what are the interactions with adjacent applications and users. The target application is depicted as a black-box.
- At 1-level the target application is decomposed into modules, and what application services (or application interfaces) those modules provide and require. The target application is depicted as a white-box.
- At 2-level the modules are decomposed into sub-components.
The Application Component Model diagrams below consist of application components and application services. Alternatively, application interfaces can be used instead of application services depending on the case. As always, it is important to utilize such a modelling style what is appropriate for the purpose, and model only those elements that are informative enough and provide certain added value. It is up to modeler, whether he or she likes to emphasize the functional aspects, or to be more concrete, and model e.g. the actual interfaces with exact naming.
Application Component Model – 0
Component Model – 0 level illustrates interactions between target application and adjacent applications. All the relevant application services (or application interfaces) are introduced. The 0-level the diagram consists of enterprise architecture level components and their services, target application is in the middle.
Application Component Model – 1
Component Model – 1 level illustrates how the target application is decomposed into modules (or main components), and which module realizes which application services (or application intefaces).
Application Component Model – 2
Component Model – 2 level illustrates how target application’s modules are composed from sub-components, and how they interact.
Application Functions View
Application functional decomposition: what are the functions the application contains, and which application services they provide.
Application Process View
This view illustrates the role of an Application Process (a.k.a. automatized process), that is performed by an Application Component. An Application Processes can receive and throw Application Events (as typical e.g. in Event-Driven Architecture, where small application or microservices switch information with events).
The Application Process can be nested in Application Component to save space in the diagram and to illustrate which Application Components is responsible of the concerned Application Process.
An Application Process can consist of phases or process steps, that is analogous to Business Processes. The main difference between Business- and Application Process is that the former is more abstract and can consist of manual steps performd by business actors, whereas the latter is automatized and performed by an application. This Application Process View can be used for modelling e.g. cases such as AI and robotics.
Application Component Sequence Diagram View
Dynamic relations “Trigger” and “Flow” can be used for modelling dynamics between application components. The layout of this view can be positioned analogously to the UML sequence diagram.
Application Deployment View
This view can be used for modelling the deployment of the application. E.g. clustering, servers and system softwares (such as operating system, application server etc.) can modelled if necessary.
Application architecture can be modelled with the same ArchiMate elements and relationships as other levels of architecture (Enterprise- and Domain levels). Ideally the very same modelling tool (an EAM tool) and same modelling method can be used for all the architecture levels. However, there are some specific diagram types for application internal architecture modelling.
An example how to model application internal structure is the “Component Model 0-n”. This approach provides certain levels (from 0 to n) on which an application architecture can be modelled. For example, the “Component Model – 0” level describes how the application interacts with its environment, the “Component Model – 1” level describes what are the main components (modules) of the application. Next Component Model levels 2 to n can be used for to describe the structure of the main components more detailed if necessary.
Same architecture description document can be utilized for different levels of architecture: 1) Enterprise Architecture, 2) Domain / Capability Architecture and 3) Solution Architecture (link).