Timbus - Timeless Business

Blog Post: Context Modelling and ArchiMate

Details

Created on Wednesday, 06 February 2013 11:25

Last Updated on Tuesday, 21 October 2014 08:32

We live in an era of digital firms, where new businesses flourish due to the possibilities created by increasingly sophisticated technology, with business activities being fully supported by it. While technology creates new opportunities, it also raises new challenges and responsibilities. New legal requirements are faced by organizations, which involve accountability, non-repudiation, authenticity, integrity and confidentiality of their processes and supporting systems, bringing new demands to which organizations need to comply.

The digital preservation of business processes aims to be one answer to such demands. By preserving processes, it should be possible to perform their resurrection in the future and be able to use them as evidence in litigation cases. However, preserving processes is a challenge itself. As any other digital objects, digital business processes need to be preserved along with their context, which allows, on the one hand, the redeployment of the process and, on the other hand, the understanding of the purpose of the process. While redeploying the process requires a technological context, understanding the purpose of the process requires an organizational context.

In order to be able to capture the context of the process, first it is necessary to know what makes up the context, i.e., what are the necessary pieces of information that should be captured. This is done by analyzing the problem domain and obtaining requirements from the stakeholders interested in the preservation. From the analysis of the problem domain, it is possible to conclude that digital business processes will have context dependencies to the software directly providing support and to the hardware where the respective software is running. It is also possible to conclude that context dependencies to the actors and organizational roles and to the motivations behind the process are also important. Second, it is important to have a means for organizing and structuring that information, which will include the “things” that make up the context and the dependencies between those “things”.

The existence of dependencies across different layers of concern on an organizational setting is something that has been addressed by the field of Enterprise Architecture (EA). EA aims the alignment of the information systems with the business objectives, through the use of architecture models in order to promote self-awareness. For that purpose, the field has produced through the years a series of architecture frameworks and modelling notations for being able to model the dependencies at different levels of the organization. Hence, any changes on the organizational environment can be propagated throughout the organization and actions can be performed to ensure that changes are successfully accommodated by the information systems, so that the organization keeps operating according to its business objectives.

The ArchiMate EA modelling language is the culmination of years of work in a maturing field. It includes a minimum set of entities and relationships (i.e., the dependencies) required to capture all relevant aspects of an organization and its IT systems. The modelling language itself is organized in a framework that can be visualized as a three by three grid: the lines correspond to the different layers of an organization, i.e., business, application, and technology, and the columns correspond to different aspects pertaining to the layers, i.e., passive structure, active structure, and behaviour.  The figure below depicts the concepts belonging to the passive structure in green, the concepts belonging to the active structure in blue, and the behaviour concepts in yellow.

(From ArchiMate 2.0 Specification)

Concluding, ArchiMate seems like a logic choice for which to base a Context Model, since it captures a great deal of the entities needed for performing business process preservation. However, when analyzing the requirements from the stakeholders, it is noticeable that some of the context information required much more detailed modelling primitives that are not included in ArchiMate. Those modelling primitives can be either obtained by specialization the concepts contained in the language or by integrating other more specific models with the core Context Model, provided that mappings are created between the two. This process will be the subject of a future article on this blog!

Please register in order to comment