Combine ArchiMate & TOGAF Standards to Support Digital Change
Apr 13, 2018
In the first blog of this series, I explained how important it is to raise your digital change capability to become an adaptive enterprise. I also highlighted the role of effective communication, as well as approaches to categorize and visualize enterprise architecture descriptions based on the TOGAF and ArchiMate standards. In this series, I also included guidance on which approach to select for modeling Architecture and Solution Building Blocks (both are types of logical or physical components). To round out this series, I will end by discussing the connection to Deployed Solutions.
TOGAF describes the physical application component as “deployable component, e.g. a deployed instance of an ERP” (TOGAF 34.5). As explained earlier, the Architecture (ABBs) and Solution Building Blocks (SBBs) refer to types of objects. You can use this to distinguish physical application components into types as SBBs and instances as Deployed Solutions. The Deployed Solutions are interesting when documenting existing solutions, managing them (e.g. in an application portfolio) or reusing that information in architecture development. In terms of modeling them in ArchiMate, you can use the same concepts on solutions and deployed solutions levels to differentiate types and instances. Often, it is helpful to add a suffix to the name of the instances as a naming convention (e.g. “SAP ERP P123”). If you want to relate solution types and deployed solution instances, I recommend using the specialization relation in ArchiMate. That way you can describe something of the same kind, but with different parameters / configurations. The picture below shows how you can model the Enterprise Continuum in ArchiMate using the first approach described here.
The TOGAF Architecture Development Method (ADM) names dedicated phases for the development of business and technology architectures. For explanation purposes, the mapping shown above is based on the application layer, but you can transfer it to the business and technology layer, too.
Usually, the instances of technologies are not of interest to enterprise architecture development (e.g. Windows Version 20XX License Number ABCXYZ), so I don´t model them in this context. A candidate to model at this deployment level is a node composing the different technology solutions that should be implemented in a project or imports of existing servers from CMDBs. Since I used the internal ArchiMate active structure concept of application component for the physical application component, this approach uses the concepts of system software or (hardware) device to model the technology pendant. The function concept also exists at the technology layer, so this is a straightforward mapping.
The business layer can also be described with the same approach. The business architecture often contains business processes to describe the behavior assigned to departments (or roles), so I explicitly include them next to business functions for the business layer here. Small ArchiMate excursion: Both, business processes and the business functions describe internal business behavior. The difference is that the business process groups behavior according to a specific order of activities, while the business function groups behavior according to a set of characteristics (e.g. knowledge). As you know, the term “business function” is sometimes also used for department-like entities which represent active structure elements in the ArchiMate framework that is performing behavior (e.g. business processes). Being ArchiMate-strict, departments are usually modeled as business actors, which is then the pendant to the physical application, while functions / processes are the pendant to the logical / functional aspect.
What is the take away of this blog series? In the first blog I raised the need to become an adaptive enterprise in a faster-changing environment and explained how language plays a critical role in communication. Proper tool and methodology support are also important ingredients in digitizing your change capability! At the same time, the enterprise architecture function provides a holistic view on impacts for strategic transformations across initiatives. When talking about strategy and change projects, there is also a need to describe different types of architectures. You have seen how to classify architectures based on the TOGAF standard and how to visualize them by using ArchiMate standard. I will now take all that we’ve covered in this series to provide a practical example of the whole TOGAF Enterprise Continuum.
As you see, the foundation architectures are mainly modeled within the technology layer, while the other more specific architectures are usually modeled with the application and business layer. This makes sense since you mainly build your application architecture on a foundation / technology that you don´t develop yourself, but rather buy and configure (e.g. MS SQL). The example does also reflect that TOGAF and ArchiMate have the ability to describe business and IT for a better alignment to support strategic transformations.
I hope you enjoyed reading this series and found the application of the ArchiMate framework to the TOGAF Enterprise Continuum helpful. For more in-depth discussions, check out our training offers for ArchiMate, TOGAF and more. You can also learn how Enterprise Studio and Horizzon can support these standards. A webinar about this blog series can be watched at: https://publications.opengroup.org/webinars/togaf/d221
