Implementation of a Continuous Delivery Pipeline for Enterprise Architecture Model Evolution
Since it beginnings in the 1980’s, Enterprise Architecture (EA) has developed to an established discipline. The ISO 42010:2011 defines architecture as the “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”. The term Enterprise Architecture describes the architecture at the level of an entire organisation.
During the lifetime of an enterprise its EA is expected to change heavily and continuously due to many different sources for changes. As our research assumes a project-driven environment, we will refer to projects as the main source of changes.
Changes caused by projects can be contradictory in terms of added or removed components of the EA model or in terms of time. It can be the case that one project has an older state of the business-wide EA model than other projects have, thus working on outdated informations causing massive problems to merge the different EA model states. Therefore, the task of manual EA model evolution maintenance is very time consuming and error prone.
Hacks et. al. designed a concept of an automisation of the EA model evolution maintenance process in form of a Continuous Delivery Deployment Pipeline for Enterprise Architecture Model Evolution [Hac+19]. In this thesis the concept will be implemented and refined if necessary.
Background and Motivation
We differentiate between different states of an enterprise architecture:
as-is : The global, i.e. business wide EA at the current point in time.
to-be : The prescriptive EA at a certain point in time in the future.
will-be : The prognostic EA at a certain point in time in the future.
special : The special, i.e. project specific deviation of the EA in a certain project.
Obviously both to-be and will-be states do not necessarily have to be equivalent as certain project specific design decisions made in the past might affect the global EA in the future and thus the achieved EA in the future might diverge from the planned EA in the future.
In a usual environment a project gets a copy of the as-is EA model and during its runtime applies changes to its copy, e.g. by adding or removing components or transitions or even whole layers of the model. Thus, having n running projects might lead to n deviations of the as-is EA model at any point in time.
This leads to many questions regarding the merging of the different EA states such that the changes in the special EA models get adapted to the as-is EA model.
– When to merge a special EA model with the as-is EA model?
– How to merge both models, i.e. how to decide and who decides which elements of the special EA model will be adopted and which will not (the level of detail might vary between both models)?
– How to handle or solve merge conflicts?
– How to assess whether the applied changes in the special EA model have a good quality in terms of enterprise architecture management and the to-be EA model?
There are many problems with merging the EA models manually. The task is very time consuming and error prone since answers to the questions above are by far not trivial and therefore much communication with many different stakeholders is required. Additionally, assessing the quality of the model is even more time-consuming for the enterprise architects. An automation of this process will therefore have a huge impact on the EAM quality and to reach the EAM goals in general.
The five stages of the proposed pipeline can be compared to the stages of classic Continuous Deployment Pipelines.
Each stage is built up by different kind of activities. We differentiate between Transformations, which create a new artifact, Assessments, which assess an artifact and create a report as a result, and Quality Gates, which promote an artifact for the next stage in the pipeline based on the reports or analogous documents. Thus, each stage is successfully left when the Quality Gate approves the artifact to have met certain quality criteria. If the Quality Gate does not approve the artifact(s) the pipeline fails with a
message according to the reason of failure.
As we imply the pipeline to be within a continuous delivery environment we assume the global as well as special EA models to be under version control and saved in according repositories. We consider the pipeline to be triggered automatically after a change of a special EA has been commited to its repository.
In the first stage the pipeline first checks out both the global and the special EA model artifacts from the repositories they are kept in. Then it computes the difference set between both artifacts resulting in a third artifact we call ChangeSet. After removing possibly too detailed elements of the ChangeSet the Quality Gate of the first stage promotes the three artifacts if the previous activities processed successfully.
The second stage is analogous to the Unit Testing & Inspection stage of classic pipelines and assesses the syntactical quality of the artifacts. The pipeline applies various syntax and consistency checks as well as computes certain EAM key performance indicators (KPI) metrics. The Quality Gate promotes the artifacts if they meet the requested quality level.
Now the Integration and Integration Testing stage follows, in which the three artifacts are merged to the new global EA model candidate. If the new candidate meets certain quality criteria, the candidate is promoted by the Quality Gate to the next stage in which the stakeholds are notified about the new candidate. If each stakeholder approves the new global EA model candidate it is then deployed to the global EA model repository. Thus, the fourth stage is the single manual activity in the whole pipeline and the stakeholders are only notified about a new candidate if it meets a certain level of quality due to the
assessments done by the pipeline in the prvious stages.
In this thesis the concept presented above will be implemented and refined if necessary. We will use ArchiMate 3.0.1 as the architecture modelling language of our models [Arc]. ArchiMate models are defined in Extensible Markup Language (xml). Thus, we can easily map the different activities to the language we are going to use to calculate artifacts or assess them, allowing us to work directly on the models and in the modelling language. Transformation activities can be implemented by XSL Transformation (xslt) and
Assessment activities by XML Schema Definition validation (xsd). The Quality Gates are not directly bound to the modelling language as they use other documents such as approvals or reports as input.
The pipeline will be implemented in a prototype for a self-organizing continous delivery pipeline JARVIS, designed at the Reasearch Group of Software Construction at RWTH Aachen University [SLD18]. JARVIS provides a continuous deployment pipeline which is able to work with Business Process Model and Notation (BPMN) as a modelling language, which is the notation Hacks et. al. used to model the EA Model Maintenance pipeline [Hac+19].
To evaluate the quality of our EA Model evolution continuous delivery pipeline we will implement equivalence class tests by mapping certain EAM KPI metrics to the level of ArchiMate. Each equivalence class is built by the tuple of EAM KPI values and the expected behaviour of the pipeline based on the KPI values. Each KPI metric needs an interpretation whether the result is good, normal or bad. Based on the result we expect the pipeline to either succeed, succeed with a warning or fail.
The equivalence class tests might be extended by other categories such as consistency checks for the new EA model candidate. For example, as we do not expect non-connected components to be part of a high quality EA model the pipeline should also fail if the pipeline detects any non-connected component in the Unit Testing or Integration Testing stage.
[Arc] The Open Group: ArchiMate 3.0.1 Specification. 2017
[Hac+19] S. Hacks et al. Continuous Delivery Pipeline for EA model Evolution. Tech. rep. SWC RWTH Aachen, 2019
[SLD18] A. Steffens, H. Lichter, and J. S. Döring. Designing a Next-Generation Continuous Software Delivery System: Concepts and Architecture. Tech. rep. SWC RWTH Aachen, 2018