Application Architecture Overview – the Context (Layered View)<\/h3>\n
An overview of an application can be modelled with Layered View<\/em>.<\/p>\n Note! Layering is the categorization of the elements, as there are exactly the same behavioral and structural elements on each layer. Layering doesn’t mean that the elements exist in specific layers – there is no such layers in practice in an organization.<\/p>\n The context of an application can be illustrated by utilizing the Layered View<\/em>. 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<\/em>, an example is shown below.<\/p>\n The main advantage of the Layered View<\/em> is to illustrate the overview in a single diagram. E.g. relevant elements of the business architecture such as the business service and the business process involved, and which application services are supporting the business process, which applications are providing those application services etc.\u00a0The Layered View<\/em> can be applied to fit for purpose, only relevant layers can be modelled depending on the case and what is appropriate. E.g.\u00a0the infrastructure on which the applications are running, can be modelled if relevant, or left out in the case of cloud-services for eample.<\/p>\n This informative view can be used for introducing interactions between applications: what information they switch and to which direction the information flows.<\/p>\n 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.<\/p>\n 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).<\/p>\n 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.<\/p>\n Note that application services (figure above) are the behavioral functionalities that are provided by the structural interfaces (figure below). In other words, application services are accessed via the application interfaces in practice. The application Interface (figure below) is more concrete, representing the actual interface in the form of a) user interface (GUI) or b) application-to-application interface (API)<\/p>\n 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.<\/p>\n 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\u00a0nevertheless.<\/p>\n 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<\/em>\u00a0(GUIs) or app2app interfaces<\/em>\u00a0(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.<\/p>\n GUI<\/strong> = Graphical User Interface<\/em>, API<\/strong> = Application Programming Interface<\/em>, 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<\/a>).<\/p>\n Several alternative approaches of modelling data switching between applications are shown in the examples (1 to 10) below.<\/p>\n This view mixes EA level and solution level approaches, as there 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..<\/p>\n Note! Application Service A-3 seems to be a type of user interface (GUI), whereas the other application services are type app2app interfaces (APIs).<\/p>\n Application Component Model 1-2-3 (CM 1-2-3 for short) is an application architecture modelling approach, which consists of diagrams of different abstraction levels as follows:.<\/p>\n The Application Component Model (CM) 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 that 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.<\/p>\n Component Model – 1 (CM-1) level illustrates interactions between the target application and adjacent applications. All the relevant application services (or application interfaces) are introduced. The 1-level diagram consists of enterprise architecture level components and their services, target application is in the middle.<\/p>\n Component Model – 2 (CM-2) level illustrates how the target application is decomposed into modules (or main components), and which module realizes which application services (or application interfaces). Note! External applications can be left out from this level, but their services (or interfaces) are shown. When more low-level elements are shown, then more high-level elements can \/ have to be left out – for the sake of simplicity: to keep the diagram readable.<\/p>\n Component Model – 3 (CM-3) level illustrates how the target application’s modules are composed from sub-components, and how they interact. CM-3 diagram can be modelled for each application component separately, as shown in the diagram below.<\/p>\n Application functional decomposition: what are the\u00a0functions the application contains, and which application services they provide.<\/p>\n 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).<\/p>\n 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.<\/p>\n 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<\/em> can be used for modelling e.g. cases such as AI and robotics.<\/p>\n 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\u00a0 sequence diagram.<\/p>\n Another version of the application sequence (figure below) that is using the flow -relation, which is more aligned with the ArchiMate philosophy for using flow -relation for information switching.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Same architecture description document can be utilized for different levels of architecture: 1) Enterprise Architecture, 2) Domain \/ Capability Architecture and 3) Solution Architecture (link<\/a>).<\/p>\n For more ArchiMate examples see:<\/p>\n Introduction Application Architecture (or Solution Architecture, SA) can be modelled with the same set of ArchiMate diagram types as other levels of architecture (Enterprise- and Domain levels). Application architecture can be modelled with a small subset of ArchiMate elements as follows: Application Component, Application Service and Application Interface.\u00a0Relationships between those elements can be modelled with […]<\/p>\n","protected":false},"author":1,"featured_media":1609,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,10],"tags":[33,128],"class_list":["post-1396","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-archimate","category-enterprise-architecture","tag-archimate","tag-component-model-1-2-3"],"yoast_head":"\n![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/10\/Layered-View-pattern.png\")
<\/a>Application Co-Operation View (Data flows)<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2016\/12\/Application-Co-operation-View.jpg\")
<\/a>Application And Data<\/h4>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/10\/Applications-And-Data-View-1024x341.jpg\")
<\/a>![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/10\/Applications-And-Data-View-2-1024x341.jpg\")
<\/a>Application Structure View<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2016\/12\/Application-Structure-View-1.jpg\")
<\/a>![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2016\/12\/Application-Structure-View-2-1024x357.jpg\")
<\/a>![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/10\/Application-Structure-View-3-1024x500.jpg\")
<\/a>![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/10\/Application-Structure-View-4-1024x405.jpg\")
<\/a>Application Integration View (Dynamic relationships)<\/h3>\n
\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2016\/12\/Application-Integration-View.jpg\")
<\/a>Application Architecture View<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/10\/Application-Architecture-1024x663.jpg\")
<\/a>Application Component Model 1-2-3 (CM 1-2-3)<\/h3>\n
\n
Application Component Model – 1 (CM-1)<\/h4>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/10\/Application-Component-Model-0-1024x639.jpg\")
<\/a>Application Component Model – 2 (CM-2)<\/h4>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2016\/12\/Application-Component-Model-1-1024x397.jpg\")
<\/a>Application Component Model – 3 (CM-3)<\/h4>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/10\/Application-Component-Model-2.png\")
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/10\/Application-Component-Model-2-Application-Component-A-2.png\")
Application Functions View<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2016\/12\/Application-Functions-View.jpg\")
<\/a>Application Process View<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2016\/12\/Application-Process-View-1024x498.jpg\")
<\/a>![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2016\/12\/Application-Process-View-nesting.jpg\")
<\/a>![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2016\/12\/Application-Process-View-internals.jpg\")
<\/a>Application Component Sequence Diagram View<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/10\/Application-Sequence-View.jpg\")
<\/a>![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/10\/Application-Sequence-View-1-1024x385.png\")
Application Deployment View<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2016\/12\/Infrastructure-View-2-1024x538.jpg\")
<\/a>Conclusions<\/h3>\n
\n\n
\n<\/h1>\n","protected":false},"excerpt":{"rendered":"