![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/AM-Cookbook-1.png\")
<\/a>\n\n\n\n
Check the ArchiMate User Community for more information: link<\/span><\/a><\/p>\n\n\n\n This document covers ArchiMate\u00ae -patterns and examples, those of which can be used as ‘recipes’ and inspiration sources when modelling concepts and solutions related to the development work of an organization. ArchiMate\u00ae is a registered trademark of The Open Group<\/p>\n\n\n\n Almost all the business relevant behavioral and structural elements of an organization can be modelled with the ArchiMate\u00ae. ArchiMate\u00ae is a comprehensive and powerful notation, with a wide range of elements and relationships. However, only a subset of ArchiMate-elements and only a small set of diagram types are enough for most of the modelling purposes (80% of the cases). This document introduces the most useful diagram types and related ArchiMate-elements. This subset of ArchiMate-elements is grouped into the layers of ArchiMate\u00ae Framework (figure below).<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 1: ArchiMate\u00ae Framework.<\/p>\n\n\n\n The diagrams in this document are modelled according to ArchiMate\u00ae specification [1]. More ArchiMate -examples can be found from the blog [2]. This document is updated continuously, more interesting topics are to be added, and existing content is to be updated according to new information. This document (this link and the pdf<\/a>) can be freely used and shared. <\/p>\n\n\n\n [1] ArchiMate\u00ae 3.2<\/em>, Open Group, 2022. https:\/\/pubs.opengroup.org\/architecture\/archimate32-doc\/<\/a>. <\/p>\n\n\n\n [2] Enterprise Architecture at Work<\/em>, 4th<\/sup> Edition, Marc Lankhorst et al., Springer, 2017.<\/p>\n\n\n\n [3] Mastering ArchiMate<\/em>, Edition III, Gerben Wierda, 2017.<\/p>\n\n\n\n [4] Lean Enterprise Architecture Method For Value Chain Based Development In Public Sector<\/em>, Hosiaisluoma et al, 2018. https:\/\/www.hosiaisluoma.fi\/blog\/lean-enterprise-architecture-method-for-value-chain-based-development-in-public-sector\/<\/a><\/p>\n\n\n\n [5] ArchiMate Examples<\/em> blog, Eero Hosiaisluoma. https:\/\/www.hosiaisluoma.fi\/blog\/archimate-examples\/<\/a><\/p>\n\n\n\n [6] \u201cHolistic Enterprise Development<\/em>\u201d blog, Eero Hosiaisluoma https:\/\/www.hosiaisluoma.fi\/blog\/<\/a><\/p>\n\n\n\n [7] Value analysis with Value Stream and Capability modeling<\/em>, Christine Dessus, 2019 https:\/\/www.slideshare.net\/chdessus\/value-analysis-with-value-stream-and-capability-modeling<\/a><\/p>\n\n\n\n A Motivation View<\/em> (a.k.a. Goals View<\/em>) can be used to depict why demand is meaningful: WHY this change is needed. With the Motivation View<\/em> it is possible to model crucial drivers and root causes behind the demand, actual goals and related outcomes, as well as concrete requirements for further development. The Motivation View<\/em> answers the questions to WHOM, WHY and WHAT. Whenever appropriate, a Value can be associated with the Motivation View<\/em>, if it is important to illustrate the concrete benefits of the demand (development target).<\/p>\n\n\n\n This diagram type is modelled with ArchiMate\u00ae Motivation- and Strategy -elements.<\/p>\n\n\n\n The Motivation View<\/em> can be applied to many kinds of purposes, such as to depict a strategy of the whole organization or to define the business case or requirements of a single development target.<\/p>\n\n\n\n ArchiMate\u00ae Motivation- and Strategy -elements are quite self-descriptive when illustrated within the titled groups (as shown in the figure above). Diverse stakeholder groups (managers, process- and software developers etc.) can read the Motivation<\/em> View<\/em> without deep knowledge of ArchiMate\u00ae. As a result of this, the Motivation<\/em> View<\/em> is a very multipurpose diagram type. It would be important and valuable to create a Motivation<\/em> View<\/em> for each and every demand for change – before any (\u201cbuild or buy\u201d) actions are to be taken.<\/p>\n\n\n\n Risk and Security View. Mapping of Risk and Security Concepts to the ArchiMate\u00ae. Security and data protection matters are part of risk management. This modelling approach covers them both.<\/p>\n\n\n\n This diagram type is modelled with ArchiMate\u00ae Motivation -elements.<\/p>\n\n\n\n References:<\/p>\n\n\n\n A Business Model Canvas (BMC) <\/em>-diagram can be used for modelling a business model or a business case.<\/p>\n\n\n\n This diagram type is modelled primarily with ArchiMate\u00ae Business Layer -elements together with certain Motivation- and Strategy -elements.<\/p>\n\n\n\n A development target can be analyzed and depicted with the SWOT View -diagram. (SWOT stands for Strengths, Weaknesses, Opportunities and Threats.)<\/p>\n\n\n\n This diagram type is modelled with ArchiMate\u00ae Assessments -elements.<\/p>\n\n\n\n A Value Stream<\/strong> diagram defines e.g. how value is created for the customers according to the Business Model. In addition, value stream modelling can be used to depict how the business capabilities are connected to the value stream. This makes it visible what is the role and meaning of each capability (and related resources), and what is the actual value-add of each capability in the overall end2end value creation stream (process). As such, the value stream description (with capability connections) visualizes both the beneficial and unproductive capabilities, when measured with pure value-creation factors. How an organization creates value for the customers, and with what capabilities.<\/p>\n\n\n\n A value stream focuses us to \u201cstart talking business value instead of architecture\u201d. Architecture, in turn, defines the behavior and structure behind each capability.<\/p>\n<\/blockquote>\n\n\n\n This diagram type is modelled with ArchiMate\u00ae Strategy -elements. The Value Stream -element is introduced in the ArchiMate\u00ae 3.1 version link<\/a>.<\/p>\n\n\n\n The Value Stream (figure above) represents the Business Model <\/strong>(added with value elements), whereas the Business Process (figure below) represents the Operating Model<\/strong> (the implementation of the Value Stream). In that case, the value stream and process describe the same \u201cthing\u201d, but in different abstraction levels.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 9: Relation of a Value Stream and a Business Process.<\/p>\n\n\n\n \u201cA Business Model<\/strong> should also provide a very high-level view of the key parameters that together combine to produce the value proposition. An Operating Model<\/strong> explains the configuration of the enterprise resources considered optimal by the leadership team for the realization of the business model. In other words, how will the business model be realized by some suitable combination of People, Process, and Technology (PPT)\u201d. [Ed Walters, Modeling the Business Model Canvas with the ArchiMate\u00ae Specification<\/em>, Document No.: W195, Published by The Open Group, May 2019.]<\/p>\n\n\n\n The topic of value stream analysis is covered in more detail by Christine Dessus in \u201cValue analysis with Value Stream and Capability modeling\u201d (see [8] ).<\/p>\n\n\n\n <\/p>\n\n\n\n For the successful and efficient operational development of an organization, it is crucial that the strategy and strategic goals can be connected to the Business Model, to the Capability Model, to the Operating Model, and preferably to all the development targets.<\/p>\n\n\n\n The strategy can be modelled with ArchiMate\u00ae Strategy -elements: Course of Action, Capability and Resource. With these elements, the organization can be analyzed and depicted according to Resource-Based View (RBV)<\/em> -approach.<\/p>\n\n\n\n Figure 10: Strategy – Pattern.<\/p>\n\n\n\n A Capability Map View, the Capability Model<\/strong>, is valuable to identify the following:<\/p>\n\n\n\n For capability assessment and identification, the following can be considered:<\/p>\n\n\n\n For more details see Business Capability<\/a>. <\/p>\n\n\n\n A Capability Map View is modelled with ArchiMate Capability -elements. Capability Groups can be modelled with either Capability- or Group-elements.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 12: Strategy & Capability Planning View – Example (ref. \u201cStrategy to Capability\u201d Value Stream).<\/p>\n\n\n\n The Strategy View & Capability Planning View <\/em>is modelled with ArchiMate Motivation- and Strategy-elements (figure above). This view and these elements can be used for Capability-Based Planning (CBP<\/em>) purposes.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 13: Strategy To Capability View – Example.<\/p>\n\n\n\n Another example of how Capability-Based Planning (CBP<\/em>) can be supported by modelling. Capabilities can be identified based on the strategic course of actions, which can be derived from strategic goals and -outcomes.<\/p>\n\n\n\n For the sake of enabling strategy execution in practice, the strategy statements should be expressed as imperatives, actionable clearly stated clauses. These imperative actions can be modelled with ArchiMate Course of Action -elements. A suggested form is used imperatively as follows: \u201cFocus on Customer Experience\u201d, \u201cAutomatize Biz Processes\u201d, \u201cEstablish Demand Management virtual team\u201d etc.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 14: Capability Planning View.<\/p>\n\n\n\n This view can be used for designing the actual architectural building blocks to realize a capability. The Grouping -element can be used for aggregating the elements into a logical entity.<\/p>\n\n\n\n See Capability-Based development<\/a> for more details.<\/p>\n\n\n\n This view can be used for modelling the implementation plan of a strategy or capability etc.<\/p>\n\n\n\n An implementation roadmap can be added with the core enterprise architecture elements (such as application services) that are to be implemented in certain phases as illustrated in the figure below.<\/p>\n\n\n This version (figure above) can be used for grouping the changes into the implementation phases.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 17: Layered View (Overview) – Basic Design Pattern.<\/p>\n\n\n\n The Layered View<\/em> combines ArchiMate-elements from different ArchiMate-layers as follows: Business-, Application- and Technology Layers.<\/p>\n\n\n\n The Layered View<\/em> enables the development target to be analyzed and depicted as a layered \u201cstack\u201d as follows: first the business aspects on the top, then application aspects in the next layer, and finally the technology aspects on the bottom. This approach makes the overall big picture visible with all the necessary relationships between all the behavioral and structural elements, which are meaningful in the context of the development target in hand.<\/p>\n\n\n\n The layers are connected with the services (of different kinds), so in that sense, the Layered View<\/em> is enabling the Service-Driven Approach (SDA)<\/em> to analyze and depict a development target. This diagram type is one of the most useful and informative, because that makes it possible to visualize all the important relationships from bottom-up and top-down between all the necessary elements on each layer (biz, app, tech).<\/p>\n\n\n\n This diagram type can be modelled with any elements of the ArchiMate layers.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 18: Layered View Example – business and application layers.<\/p>\n\n\n\n This example diagram of the Layered View<\/em> connects business and application layers via the application services.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 19: Layered View, Business Layer – Design Pattern. Note: business interfaces as \u201cchannels\u201d.<\/p>\n\n\n\n The Layered View<\/em> can be applied to what is appropriate for the purpose. For example, layers can be left out and depict the development target from a certain viewpoint, e.g. from the business point of view like in the figure above. However, the layered approach is always based on the top-down order of the elements: customers on the top, then the business services and so on.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 20: Customer Service Journey – Design Pattern.<\/p>\n\n\n\n The Layered View<\/em> can also be taken from the customer viewpoint. Customer-centric diagrams can be modelled as Customer Service Journey<\/em> or Service Blueprint<\/em> diagrams. These diagram types combine the customer- and organization viewpoints together. These are the \u201coutside-in\u201d and \u201cinside-out\u201d approaches.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 21: Customer Service Journey – Example.<\/p>\n\n\n\n The Customer Service Journey<\/em> is a specialization of the Layered View<\/em>, which combines business- and application layer elements.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 22: Extended Swimline View – Example.<\/p>\n\n\n\n This version represents the business roles as \u201cswimlanes\u201d, analogous to process modeling in BPMN.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 23: Service Design View – Design Pattern.<\/p>\n\n\n\n This version (above) of the Layered View<\/em> using \u201cswimline style\u201d, is focused on customer role. This view can be used for service design purposes, for integrating \u201coutside-in\u201d and \u201cinside-out\u201d approaches into one view. The customer journey path is represented as a top layer, whereas the intra-organizational layers are represented next to the customer \u201cswimline\u201d. The bottom layers consist of applications and application services (which makes this view much more informative than a pure process diagram that can be modelled with the BPMN). As such this is a comprehensive view of a development target, a customer journey, a service (area) overview, process area, operational view of a value stream etc.<\/p>\n\n\n\n In this example above, Business process steps are performed by distinct business roles. Practically, business roles A, B and C are assigned to business process elements with ArchiMate Assignment-relationship type. Business role -elements are visualized as large objects that represent the \u201cswimlanes\u201d, and then the business process -elements are \u201cnested\u201d into those business roles. This modelling style saves space and minimizes crossing lines.<\/p>\n\n\n\n This version of the Layered View <\/em>combines business layer elements and application layer elements. This cross-layer view can be used for modelling high-level process flow, to which application services and\/or applications are linked to. With this view, a business process can be illustrated at a high level with ArchiMate \u2013 without the need for BPMN modelling. In addition, this view enables connecting process steps to actual application services used.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 24: Service Design View – Design Pattern.<\/p>\n\n\n\n This version splits the customer journey with phases (Pre-service period, Service period and Post-service period) is added into the customer role, and channels added in between customer and personnel roles.<\/p>\n\n\n\n Business Process -elements are nested into Business Role -elements, which means that Business Roles are assigned to Business Processes (in the model repository). Hence, there are relations between these elements, even though they are not visible. This layout of the element saves space in the diagram. The value of this view is that we can use ArchiMate and its relations when visualizing a \u201cswimlines of roles with connected application services and applications.<\/p>\n\n\n\n The service layer can be divided into distinct business services, if that is the case. Whether there is a certain specific business service that is to be designed, or there are several business services with specific channels that are serving the customer role. However, the focus is on the customer service path \u2013 or the customer journey, the customer perspective. As such, this approach is focusing on the outside-in approach, by linking the inside-out behavior and structure to customer-facing process steps.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 25: Service Blueprint – Example.<\/p>\n\n\n\n This version reflects the Service Design tool Service Blueprint, which is based on a layered approach that consists of a) customer-facing and b) intra-organizational parts. The Service Blueprint can be easily modelled with the ArchiMate elements as shown above. This diagram can be used as a bridging tool (missing link) between the Service Design and Enterprise Architecture Management (EAM) practices.<\/p>\n\n\n <\/p>\n\n\n\n Figure 26: Service Blueprint as a Layered View.<\/p>\n\n\n\n There are three variants of the Interaction View<\/em> diagram type as follows:<\/p>\n\n\n\n The Interaction View<\/em> (also known as Co-operation View <\/em>or Integration View<\/em>) can be used for modelling relationships between the actors, processes or applications. The main advantage of this diagram type is to visualize the direction of switching information, and to illustrate the amount of the interacting elements. This diagram type has been found very informative and the easiest way to visualize the complexity of the development target.<\/p>\n\n\n\n This diagram type is to be used for modelling WHAT information flows in WHICH direction, from WHERE to WHERE. This diagram type is not applied for modelling the \u201cdynamics\u201d of the information switching: which element starts the interaction or what interfaces are used.<\/p>\n\n\n\n The ArchiMate Flow-relationship type is used here to model the information flow between the elements. The \u201cinformation\u201d can also be modelled as ArchiMate Business Objects or Data Objects.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 27: Actor Interaction (Co-operation) View – Design Pattern.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 28: Process Interaction (Co-operation) View – Design Pattern.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 29: Application Interaction (Co-operation) View – Design Pattern.<\/p>\n\n\n\n This version of this diagram type is used for modelling application integrations at a high level: what data flows from which application to which application, in which direction. For more detailed level integration modelling these diagrams can be added with e.g. application interfaces or -services, and Trigger-relationships (see appendix 2).<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 30: Process View – Example.<\/p>\n\n\n\n Process View is modelled with ArchiMate Business Layer -elements as follows: Business Process), Business Actor), Business Role, Business Object and Business Event. Relationship types are Trigger and Access.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 31: Business Function View \u2013 A process may span multiple business functions.<\/p>\n\n\n\n \u201cA business function represents a collection of business behavior based on a chosen set of criteria (typically required business resources and\/or competencies), closely aligned to an organization, but not necessarily explicitly governed by the organization.\u201d [1]<\/p>\n\n\n\n A business function view can be used when it is necessary to model high-level business behavior, which groups more detailed behavior (such as processes). A business function is a behavioral element, which is performed by a structural element, typically by an organizational unit (e.g. department or group). A business function is a meaningful behavior for the organization. Business functions can be used for dividing the business into parts, each of which has certain logical cohesion based on the business services they provide.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 32: Business Process Map with Function-Based Decomposition.<\/p>\n\n\n\n A business process map can be defined based on functional decomposition (figure above). Note! Business units are shown here just to illustrate the typical mapping between business functions and business actors. Business actors may not necessarily be shown in actual business process maps.<\/p>\n\n\n\n Examples of business functions are e.g. as follows: Finance and Accounting, Human Resources (HR), Procurement (Buying\/Purchasing), Legal, Customer Service, Property Management. A business function is close to business capability, but they define business behavior in different abstraction levels: a business function represents business behavior in the operating model level, whereas a business capability represents business behavior on the business model level.<\/p>\n\n\n\n For more detailed discussion covering the relation of business processes and business functions, see Gerben Wierda\u2019s book Mastering ArchiMate III <\/em>[3].<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 33: Conceptual Data Model View – Example.<\/p>\n\n\n\n The Conceptual Data Model View<\/em> can be used for modelling the concepts and their relations of the development target.<\/p>\n\n\n\n This diagram type is modelled with ArchiMate Business Object -element and Association, Composition, Aggregation and Specialization relationship types. Some tools allow cardinality indicators (such as \u201cone\u201d, \u201cmany\u201d, \u201c0..n\u201d) to be modelled on both ends of the association relations between the elements.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 34: Data Model View – Example.<\/p>\n\n\n\n The Data Model View<\/em> can be used for modelling the detailed, logical application-level information and their relations of the development target.<\/p>\n\n\n\n This diagram type is modelled with ArchiMate Data Object -element and Association, Composition, Aggregation and Specialization relationship types. Some tools allow cardinality indicators (such as \u201cone\u201d, \u201cmany\u201d, \u201c0..n\u201d) to be modelled on both ends of the association relations between the elements.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 35: Technology Platform View – Design pattern.<\/p>\n\n\n\n The Technology Platform View<\/em> (Infrastructure View) can be used e.g. for modelling the underlying infrastructure and deployment of an application (software, servers, clustering, communication networks, load balancing etc.).<\/p>\n\n\n\n This diagram type is modelled with ArchiMate Technology layer elements such as Node, Technology Service, Artifact, Device, System Software, Technology Interface and Communication Network.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 36: Technology Platform – Example.<\/p>\n\n\n\n The Solution Architecture defines the behavior and structure of a single solution, which is a part of the Enterprise Architecture (EA). A solution is a logically and physically independent, autonomous building block of the organization-wide EA. In the EA, a solution is a \u201cblack box\u201d: its interfaces and services are interesting, but its internal structure is irrelevant. As such, a solution is the smallest meaningful unit of EA. A solution can also be comprised as a \u201csystem\u201d, whereas EA is a \u201csystem of systems\u201d. Systemic thinking takes the holistic view by identifying and considering all the aspects of business, application and technology.<\/p>\n\n\n\n Solution Architecture, instead, covers the application as a \u201cwhite box\u201d: its internal structure and interfaces with adjacent applications are interesting. The solution architecture comprehends the internal structure of an application: the modularization (sub-components and their services\/interfaces and dependencies). In addition, the solution architecture typically takes the technology aspect into account – in the form of a \u201ctechnology platform\u201d.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 37: Application View – Design Pattern (Basic Model).<\/p>\n\n\n\n Solution Architecture modelling can be done with the elements of ArchiMate Business, Application and Technology layers. The logical view of the structure of a solution is modelled with ArchiMate Application layer elements such as Application Component, Application Service, Application Interface, Application Process and Application Function.<\/p>\n\n\n\n The logical structure of a solution is modelled with ArchiMate Application Component -elements. The internal behavior of an application is modelled with the Application Process and Application Function -elements. Provided services and interfaces (to adjacent solutions) of an application are modelled with Application Service and Application Interface -elements. The Application Interface -element is used for modelling the user interfaces (GUIs) and app2app interfaces (APIs).<\/p>\n\n\n\n According to ArchiMate derivation rules (introduced in the ArchiMate specification), the basic application design pattern can be depicted as shown below.<\/p>\n\n\n\nArchiMate\u00ae Cookbook<\/h1>\n\n\n\n
<\/a><\/a>1. Introduction<\/h1>\n\n\n\n
<\/a><\/a>1.1 Purpose And Scope<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Nayttokuva-2024-09-28-kello-19.35.39-300x192.png\")
<\/figure>\n\n\n\n<\/a>1.2 References<\/h2>\n\n\n\n
<\/a>2. ArchiMate Diagram Types<\/h1>\n\n\n\n
<\/a>2.1 Motivation View (Goals View)<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Goals-View-pattern-2.png\")
<\/a>2.1.1 Motivation View – Example<\/h3>\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Goals-View-example.png\")
<\/a>2.1.2 Risk Analysis View<\/h3>\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Risk-and-Security-View-Pattern.png\")
\n
<\/a>2.2 Business Model View<\/h2>\n\n\n\n
<\/a>2.2.1 Business Model Canvas (BMC)<\/h3>\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/BMC-Pattern.png\")
<\/a>2.2.2 SWOT Analysis View<\/h3>\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/SWOT-Pattern.png\")
<\/a>2.2.3 Value Stream View<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Value-Stream-View-pattern-1.png\")
\n
2.2.3.1 Value Stream – Example<\/h4>\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Idea-to-Production-Value-Chain-Example-View.png\")
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Value-Stream-and-Business-Process-1.png\")
<\/figure>\n\n\n\n<\/a>2.2.4 Strategy & Capability View<\/h3>\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Strategy-View-pattern-2.png\")
<\/figure>\n<\/div>\n\n\n\n
\n
\n
2.2.4.1 Capability Map View<\/h4>\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Capability-Map-View.svg\")
<\/a>2.2.4.2 Strategy & Capability Planning View<\/h4>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Strategy-Capability-Planning-View-1.png\")
<\/figure>\n\n\n\n<\/a>2.2.4.3 Strategy To Capability View<\/h4>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Strategy-To-Capability-View.png\")
<\/figure>\n\n\n\n2.2.4.4 Capability Planning View<\/h4>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Capability-Planning-View-1.png\")
<\/figure>\n\n\n\n<\/a>2.2.5 Implementation Roadmap View<\/h3>\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Implementation-Roadmap-View-1.png\")
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Implementation-Roadmap-View-2.png\")
<\/a>2.3 Layered View<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Layered-View.png\")
<\/figure>\n\n\n\n<\/a>2.3.1 Layered View – Business- and Application Layers Example<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Layered-View-example.png\")
<\/figure>\n\n\n\n<\/a>2.3.2 Layered View – Business Layer<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Business-Channels-View-2.png\")
<\/figure>\n\n\n\n<\/a>2.3.3 Layered View – Customer Service Journey<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Customer-Service-Journey-Pattern.png\")
<\/figure>\n\n\n\n2.3.3.1 Layered View – Customer Journey View – Example<\/h4>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Customer-Journey-View-example.png\")
<\/figure>\n\n\n\n<\/a>2.3.4 Layered View – Swimline Process View<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2016\/12\/Business-Process-Swimline-View-pattern-2.0-1.png\")
<\/figure>\n\n\n\n<\/a>2.3.4 Layered View – Service Design View<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2016\/12\/Business-Process-Swimline-View-pattern-2.0-services-2.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Service-Design-View-pattern-2.png\")
<\/figure>\n\n\n\n<\/a>2.3.5 Layered View – Service Blueprint – Example<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2016\/12\/Service-Blueprint-View-1-services-flows-1024x997.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Business-Process-Swimline-View-pattern-2.0-information-flow.png\")
<\/figure>\n<\/div>\n\n\n<\/a><\/a><\/a>2.4 Interaction View (Co-operation View)<\/h2>\n\n\n\n
\n
<\/a>2.4.1 Actor Interaction (Co-operation) View<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Actor-Interaction-Co-operation-View-Pattern.png\")
<\/figure>\n\n\n\n<\/a>2.4.2 Process Interaction (Co-operation) View<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Process-Interaction-Co-operation-View-Pattern.png\")
<\/figure>\n\n\n\n<\/a>2.4.3 Application Interaction (Co-operation) View<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Application-Interaction-Co-operation-View-Pattern.png\")
<\/figure>\n\n\n\n<\/a>2.5 Process View<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Process-View-Example.png\")
<\/figure>\n\n\n\n<\/a>2.5.1 Business Process Functional Decomposition View<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Business-Process-Functional-Decomposition-View.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Business-Process-Map-with-Function-Based-Decomposition-1.png\")
<\/figure>\n\n\n\n<\/a>2.6 Conceptual Data Model View<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Conceptual-Data-Model-View-Example.png\")
<\/figure>\n\n\n\n<\/a><\/a>2.7 Data Model View<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Data-Model-View-Example.png\")
<\/figure>\n\n\n\n<\/a>2.8 Technology Platform View (Infrastructure View)<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Technology-Platform-View-Pattern.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Technology-Platform-Example.png\")
<\/figure>\n\n\n\n<\/a><\/a>2.9 Application Structure View (Solution Architecture)<\/h2>\n\n\n\n
<\/a>2.9.1 Application Design Pattern (Basic Model)<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2019\/07\/Application-View-Pattern-Basic.png\")
<\/figure>\n\n\n\n