=Paper=
{{Paper
|id=Vol-1182/paper3
|storemode=property
|title=Challenges of Capturing Design Rationales in Enterprise Architecture: A case study
|pdfUrl=https://ceur-ws.org/Vol-1182/paper3.pdf
|volume=Vol-1182
}}
==Challenges of Capturing Design Rationales in Enterprise Architecture: A case study==
https://ceur-ws.org/Vol-1182/paper3.pdf
Challenges of Capturing Design Rationales in
Enterprise Architecture: A case study
Georgios Plataniotis1,2,4 , Sybren de Kinderen3,4 , and Henderik A. Proper1,2,4
1
Public Research Centre Henri Tudor, Luxembourg, Luxembourg
2
Radboud University Nijmegen, Nijmegen, the Netherlands
3
University of Luxembourg, Luxembourg
4
EE-Team, Luxembourg, Luxembourg??
{georgios.plataniotis,erik.proper}@tudor.lu,sybren.dekinderen@uni.lu
Abstract. In earlier work we introduced an approach that aims in the
understanding of the reasoning that lies behind Enterprise Architecture
(EA) designs. This EA rationalization approach helps uncover design
constraints, follow good practices while avoid bad ones, and more. How-
ever, up to now, our assumptions regarding the usefulness of our ap-
proach were largely theory based.
In this paper, we use a real life case study in a Luxembourgish Research
and Technology Organization (RTO) to identify from a practical point of
view why EA rationalization is useful. Using a business process on budget
forecasting as a focal point, firstly we analyze what has been designed.
Thereafter, we analyze the reasoning behind these designs, and show
how this reasoning is not expressed with current EA design techniques.
Finally, we derive a set of challenges that an EA rationalization approach
should face up to.
Keywords: Enterprise Architecture, Design Rationale, Design Decisions, Case
Study
1 Introduction
Increasingly enterprises are faced with change due to challenges such as acqui-
sitions, mergers, technological innovation and the introduction of new business
processes. Enterprise Architecture (EA) is positioned as an instrument for help-
ing enterprises to cope with such a change [1, 2]. EA provides a toolset for analyz-
ing the wide enterprise impact of a change, considering an enterprise holistically.
As such, EA interrelates different perspectives on an enterprise [1]: strategic mo-
tivations, business processes, IT applications, to name a few. In so doing, EA
instrument can be employed to, for example, reason about the impact-of-change
??
The Enterprise Engineering Team (EE-Team) is a collaboration between Public Re-
search Centre Henri Tudor, Radboud University Nijmegen and HAN University of
Applied Sciences (www.ee-team.eu)
2 Georgios Plataniotis, Sybren de Kinderen, and Henderik A. Proper
of an IT application landscape [3], the enterprise wide impact of changing access
control concerns [4] and more.
However, while EA frameworks and languages aid first in designing a change
and subsequently implementing it, the reasons behind the design (hereafter re-
ferred to as design rationalization) are often left implicit. As a result, new designs
are constructed in an ad-hoc manner [5], without taking into consideration con-
straints implied by past design decisions. Furthermore a survey amongst EA
practitioners [6] suggests the relevance of design rationalization in motivating
design decisions and for architectural maintenance. However, the same survey
shows that practitioners often forego a structured approach for architectural ra-
tionalization. They largely capture design reasoning in an ad hoc manner, not
structurally paying attention to rationalization concepts such as design alterna-
tives, design criteria, and more.
As a result, our earlier work [7] introduces the EA anamnesis approach for
rationalizing EA designs. EA anamnesis captures the decision making process
behind an EA design, specifying design alternatives, design criteria, involved
stakeholders, and more. Furthermore, EA anamnesis allows for capturing the
observed impact of a design some time after the design decisions have been
taken. As a result, we claim that EA anamnesis not only helps in uncovering
the reasoning behind a design (by examining its decision making process), but
also in analyzing the impacts of a design by comparing the initially taken design
decisions to the impact that these decisions have.
However, up to now, the empirical evidence for the usefulness of EA anam-
nesis is limited to a survey amongst EA practitioners [6]. Although this survey
provides first indications on the usefulness of EA rationalization, however it pro-
vides no in depth insight. For example: the survey elicits that a majority of the
target population considers rationalization concepts such as “motivation”, and
“observed impact” as useful, but it does not provide any indication of why these
are considered useful. Furthermore, as stated, the survey indicates that practi-
tioners rationalize EA in an ad hoc way, without though stating what it is that
they do not capture.
In this paper, we discuss a case study in a Luxembourgish Research and
Technology Organization (RTO) for a more in depth analysis of the practical
usefulness of EA rationalization. Furthermore, we identify rationalization re-
quirements from practice to which our rationalization approach should respond.
As such, the specific contribution is twofold: (1) to provide in depth evidence
from a real life case study on the usefulness of EA rationalization, (2) to identify
objectives from practice with which EA anamnesis, our rationalization approach,
should comply.
Note that while the EA language ArchiMate 2.0 [8] has a motivational layer,
it lacks concepts important for rationalization such as considered alternatives,
decision criteria et cetera. As such, ArchiMate 2.0 is not a suitable language for
architectural rationalization
This paper is structured as follows: Section 2 discusses the case study setup
and the actual case study description. Section 3 discusses the challenges and
Challenges of Capturing Design Rationales in EA: A case study 3
the objectives for the development of rationale man agent system for enterprise
architecture and Section 4 presents a set of concrete research questions which
aim to address the mentioned objectives. Finally Section 5 concludes.
2 Research and Technology Organization Case Study
2.1 Case study setup
The research planning of the case study as well as this section structure are based
on guidelines for case study research [9]. The main objectives of this case is to
identify the main challenges for the development of rationale management system
for Enterprise Architecture. In order to identify these objectives we conducted
interviews with the involved stakeholders both from the business as well as the IT
domain of the organization. The purpose of these interviews was to understand
how they addressed the enterprise architecture challenges from their own domain
of responsibility, what were the most important design decisions for them and
how they documented these design decisions. Moreover, stakeholders provided
us with the documentation of the project. We analyzed this documentation, we
extracted design decisions, and finally compared them with those that emerged
from the interviews.
2.2 Budget forecasting at a Research and Technology Organization
This case study was conducted in a research and technology organization (RTO)
in Luxembourg, describes the introduction of a new budget management business
process and presents how this process was supported by information systems in
the context of an enterprise architecture transformation.
During the last couple of years, the Luxembourgish government introduced
more strict rules on the budget spending of academic and research institutions.
This policy had to be incorporated by the academic-research institutions of the
country, meaning that the institutions should be able to establish long term
financial projection plans. This would give to institutions a better awareness
regarding the availability of resources and in turn the planning of future projects
and personnel.
The RTO where the case study was conducted, did not have an established
business process for budget estimation. Stakeholders from the management side
of the RTO had to design this new business process. Their initial objectives were
that this business process should provide a clear view on human resources and
projects coverage, an input for the future hiring plan, comparison between the
forecasted and valuable budget, and in general robustness of the organization’s
financial data. Last but not least, a training for the users of this new business
process should be organized.
2.3 Enterprise Transformation
In this section we describe the main artifacts that support the realization of the
new business goal. For our description we are based on ArchiMate EA models.
4 Georgios Plataniotis, Sybren de Kinderen, and Henderik A. Proper
In the context of this paper though we describe how this business process is
supported by IT artifacts, we do not present details on how this business process
is executed.
The as-is architecture
Figure 1 presents the enterprise architecture before the incorporation of the new
budget forecast business process. The RTO had already implemented business
processes that supported business stakeholders with the management of projects,
finance and human resources. These business processes were supported by the
corresponding information systems.
In this part we describe briefly the new business process and information
systems that were used in the next step of the transformation to support the
Legend Roles and Actors
Actor Project Project HR HR Financial Financial
Manager Manager Officer Officer officer Officer
Business
service
Internal business services
Project Human Financial
Project management Resources management
Management service Service service
Business
Process step
Business processes
Business
Collaboration Project Management Human Resources Financial Management
Management
Business
Interaction
Application services
Business
Object
Project Human Resources Financial
Management Application Service Application
Application Application Service Service
service
application components and services
App C - App B - App A -
Project Human Financial
Management Resources Application
application Application
Fig. 1. The as-is architecture
Challenges of Capturing Design Rationales in EA: A case study 5
new business process.
Budget forecast business process: Here we describe the main charac-
teristics of the budget forecast business process. The main objectives of this
business process are the estimation and the planning of resources to ensure the
planning activities, the assessment of the need for additional resources, the esti-
mation of the associated budgets and the checking of the forecast in relation to
the available budget in the RTO.
The budget forecast business process takes into account the major changes in
exogenous or endogenous factors that significantly discredits the original budget
estimate. In the case of the RTO these exogenous factors are the main external
factor like refusal/acceptance of projects in calls and non-contracted benefits,
while the endogenous maybe associated with personal assignments, change of
strategy etc. The role of the business process is to provide annual budget esti-
mates, which should be validated and approved by the finance department.
IT Systems: Application A is the main financial application of the organi-
zation. Main functionalities of this application is management of procurements,
traveling costs, personal costs, overhead costs calculation, salaries payment and
project dashboard. The access to this application in controlled and only allowed
to financial officers.
Application B is the human resources management application. Tasks like
resource allocation, start/end dated of work contracts, weekly calendar, different
types of leaves (sickness, vacation etcetera) are executed by this application.
Application C is the project management application of the organization.
The actual hours assigned per project in the organization are maintained in this
application.
To be architecture - First iteration
Figure 2 depicts the EA model after the establishment of the budget forecast
business process. From this model we can conclude that the business process was
supported by the interaction and collaboration amongst Applications A, B, C
and a spreadsheet application. However, due to some anomalies in the insertion
of budget data through spreadsheets, stakeholders had to do some additional
changes in the EA design.
To-be architecture - Second iteration
Figure 3 depicts a final iteration of the enterprise transformation. With this iter-
ation stakeholders managed to addresses the above mentioned problem. Instead
of using spreadsheets for entering the budget data, a new application interface
was added in financial application A.
2.4 Rationale behind the models
In the previous section we described what was done in the enterprise architecture
design in order to support the addition of the new budget forecast business
6 Georgios Plataniotis, Sybren de Kinderen, and Henderik A. Proper
Legend Roles and Actors
Actor Project Project HR HR Financial Financial
Manager Manager Officer Officer officer Officer
Business
service
Internal business services
Project Project Human Financial Budget
Management management Resources management forecast
service Service service service
Business
Process step Business processes
Financial Management
Business
Collaboration Project Management Human Resources Budget
Management Forecast
Business
Process
Business
Interaction
Application services
Business
Object
Project Human Resources Budget Forecast Financial
Management Application Service Application Service Application
Application Service Service
Application
service
application components and services
App C - App B - budget App A -
Project Human forecast Financial
Management Resources Application Application
application Application Interaction
budget
Spreadsheet Budget input
forecast
application template
application
collaboration
Fig. 2. To be architecture - First iteration
process. However, the reasons behind the realization of this designs are not
captured by the EA models. As we mentioned before, ArchiMate motivational
extension provides some reasoning behind the models, but mostly regarding the
goal modeling domain. It can describe what were the drivers or requirements
for an architectural change, but not the actual reasoning in terms of design
decisions behind the model. Based on the case study we could potentially ask
these questions:
Why these three IT systems were selected for the realization of the business
process? Were there any other alternatives? What was the observed impact of
these decisions in the enterprise architecture?
By interviewing the stakeholders we understood the context which influenced
their decision making: During the execution of the enterprise transformation an-
other high level decision from the Luxembourgish government had to be applied
in the organization. The government decided that the RTO had to be merged
with another national research and technology institution. This implied the need
for serious changes in the organizational structure since some departments of the
Challenges of Capturing Design Rationales in EA: A case study 7
Roles and Actors
Project Project HR HR Financial Financial
Manager Manager Officer Officer Officer Officer
Internal business services
Project Human Financial Budget
Management Resources Management Forecast
Service Service Service Service
Business processes
Financial Management
Project Management Human Resources
Budget
Management
Forecast
Business
Process
Application services
Project Human Resources Budget Forecast Financial
Management Application Service Application Service Application
Application Service Service
application components and services
Budget
Forecast App A - Budget Input
App C - App B - Financial
Application
Project Human Application
Interaction
Management Resources
application Application
Budget
Forecast
Application
Collaboration
Fig. 3. To be architecture - Second iteration
RTO had overlapping roles with departments of the other organization. More-
over new business models should be defined based on the exchange of research
expertise of research groups.
The upcoming merge of the organization posed some serious design challenges
on the involved stakeholders of the budget estimation business process. On the
one hand they had ambitious design goals considering the realization of this
business need, while on the other hand they had to compromise because of the
merge. It was not clear how the financial departments and business processes
would be merged, therefore the risk of wasting budget for significant business
and IT development was high.
Despite the fact that the initial plan of the stakeholders was the acquisition
of a new COTS application, budget and time restrictions led stakeholders to the
decision of the upgrade and collaboration of the in house applications. Several
issues occurred after the execution of these decisions. As an example, the deci-
8 Georgios Plataniotis, Sybren de Kinderen, and Henderik A. Proper
sion for a spreadsheet template that would facilitate users to enter budget data
was problematic. What occurred was that each department start modifying the
template and the order of data. The financial officers that had to collect and
process this data started having problems during the execution of the budget
forecast business process.
Without rationalization the above reasons behind the architecture designs
in Figs 1-3 remain implicit. Yet clearly such rationalization is useful. For ex-
ample: by using rationalization one explicates the negative observed impact of
diverging spreadsheets as a result of the introduction of the new business pro-
cess As a result this negative observed impact can be anticipated on for future
similar decisions. In the next section we present the objectives of an enterprise
architecture rationale management system.
3 Objectives of an enterprise architecture rationale
management system
As already discussed, design rationale is a well established domain and a plethora
of approaches have been developed in the area of Software Architecture. How-
ever, the domain of Enterprise Architecture still remains unexplored. In a sur-
vey [6] that was conducted among 65 enterprise architecture practitioners, it
was indicated that rarely they document their design decisions in a standard-
ized way. Instead of a standardized method they capture rationale information
by using word processors and other unstructured methodologies. Possibly this
lack of a standardized way of documenting and using rationale information in en-
terprise architecture discourages practitioners from capturing this information.
Motivated by the case study we discuss what are the challenges and potential
objectives of an design rationale approach for Enterprise Architecture.
Challenge 1: One of the main goals of Enterprise architecture is the provi-
sion of reasoning of design decisions. However, the capturing of reasoning during
an enterprise architecture design process is challenging due to the fact that the
design decisions have to satisfy the requirements of stakeholders from different
domains (Business, IT). As we previously saw in our case study, different factors
influence their decision making, which in turn affect the quality of design de-
cisions. Situations like time stress, budget restrictions or the conformance with
organizational principles are common in enterprise architecture and change the
way that stakeholders make design decisions. The objective for enterprise archi-
tecture is the capturing of this reasoning process. In doing so, stakeholders which
analyze EA designs will be capable to better understand why specific decisions
were made and under which decision making context.
Challenge 2: Another important aspect of design rationale approaches is
the business/IT alignment. This means that the IT artifacts should support effec-
tively the realization of new business processes. As we saw, during an enterprise
transformation several design decisions are made, both in Business and IT sides.
Challenges of Capturing Design Rationales in EA: A case study 9
These design decisions rarely exist in isolation. Rather, design decisions are of-
ten cross cutting and intertwined. A rationale management system for enterprise
architecture should be able to capture the different types of relationships among
design decisions. For example, design decisions made on business levels can in-
fer design decisions in IT level of the organization and vice-versa. On the other
hand design decisions can be interrelated with a specific EA Artifact or domain
of the Enterprise. An RMS system should be able to distinguish between these
different relationships of design decisions. In this way it would better express
the traceability and dependencies of design decisions in enterprise architecture.
Challenge 3: Another important objective is the traceability between the
enterprise architecture design and design decisions. More specifically, during the
analysis of the enterprise design, stakeholders should be able to identify which
design decisions constitute specific EA artifacts and how the design decisions of
these artifacts are related with other design decisions in the architecture. For
example, we can start tracing from the addition of the new application interface
of the financial application and we can check which decisions are related with
this artifact.
Challenge 4: Sometimes design decisions can have unanticipated conse-
quences in the artifact itself or in different artifacts in the enterprise architec-
ture. As an example, consider the design decision for the spreadsheet template
that had negative consequences in the use of a budget forecast business pro-
cess. A rationale management system should also keep track of these incidents
and how they were addressed by means of newer decisions. By doing so enter-
prise architects who want to analyze and have a holistic view of the architecture
can identify existing vulnerabilities in the enterprise which can be prevented by
remaking the same design decision in future architectural transformations.
4 Research Questions
In this section we define a set of concrete research questions. We argue that these
research questions can address the above-mentioned objectives and in turn the
challenges for a rationale management system for enterprise architecture.
Question 1: Which are the essential decision details concepts that rationalize
design decisions in Enterprise Architectures?
There is a plethora of approaches for the rationalization of different domains
(civil, software architecture). These approaches have introduced different sets of
domain specific concepts. By answering this research question we aim to identify
which concepts from existing frameworks can be used for the domain of enter-
prise architecture and what is actually missing to provide a holistic overview of
design rationale in enterprise architecture. The identification of these concepts
will provide a taxonomy of rationalization information for enterprise architec-
ture and in turn the basis for the development of a design theory for the same
10 Georgios Plataniotis, Sybren de Kinderen, and Henderik A. Proper
purpose. The challenge, from a design theory point of view, is the identification
of possible relationships among these concepts which in turn will enhance the
utility of the design theory.
Question 2: How do we make explicit the underlying decision making process
that was executed during the EA design?
As it was also stated, the decision making environment in Enterprise Ar-
chitecture is challenging due to the implication of different stakeholders from
different domains and due to factors that affect the decision making process.
We argue that the capturing and representation of this underlying information
can assist stakeholders during the inspection of the as-is architecture to analyze
the evaluation process for specific decisions and recognize which factors actually
influenced this decision making process. By doing so, they can consult for their
future evaluations by following/avoiding good/bad evaluations from past deci-
sions making processes.
Question 3: How do we capture and represent different decision relation-
ships in Enterprise Architecture?
The confrontation of this research question will provide a holistic overview
and traceability of the enterprise architecture. The domain of enterprise architec-
ture introduces several challenges since decisions from a specific domain (IT) can
be related with decisions of the same or another domain (Business). The same
applies also for the outcomes of EA decisions since the application of a specific
decision may introduce problematic situations in different domains of the en-
terprise. To cope with this research question we will investigate existing design
rationale approaches from different domains and we will identify the specificities
imposed by the domain of enterprise architecture.
5 Conclusions and future work
In this paper, based on a case study in a Luxembourgish research and Tech-
nology organization we identified the importance of capturing design rationale
information. Moreover, motivated by this case study we discussed what were the
objectives for the development of a rationale management system for an enter-
prise architecture and we provided a list of concrete research questions which
can be used for the development of such a framework.
For future research, we aim to apply the EA Anamnesis approach to the
RTO case study and evaluate its capability to capture the underlying design
rationale knowledge in the context of an enterprise transformation. Based on
the derived objectives and research questions, we aim to further improve our
existing approach by means of metamodel modifications.
References
1. Lankhorst, M., et al.: Enterprise Architecture at Work: Modelling, Communication
and Analysis. 3rd edn. Springer Publishing Company, Incorporated (2012)
Challenges of Capturing Design Rationales in EA: A case study 11
2. Op ’t Land, M., Proper, H., Waage, M., Cloo, J., Steghuis, C.: Enterprise Ar-
chitecture – Creating Value by Informed Governance. Springer, Berlin, Germany
(2008)
3. Lagerström, R., Johnson, P., Höök, D.: Architecture analysis of enterprise systems
modifiability–models, analysis, and validation. Journal of Systems and Software 83
(2010) 1387–1403
4. Feltus, C., Dubois, E., Proper, E., Band, I., Petit, M.: Enhancing the archimate
standard with a responsibility modeling language for access rights management. In:
Proceedings of the Fifth International Conference on Security of Information and
Networks. SIN ’12, New York, NY, USA, ACM (2012) 12–19
5. Tang, A., Jin, Y., Han, J.: A rationale-based architecture model for design trace-
ability and reasoning. Journal of Systems and Software 80 (2007) 918 – 934
6. Plataniotis, G., de Kinderen, S., van der Linden, D., Greefhorst, D., Proper, H.A.:
An empirical evaluation of design decision concepts in enterprise architecture. In:
Proceedings of the 6th IFIP WG 8.1 working conference on the Practice of Enterprise
Modeling (PoEM 2013). (2013)
7. Plataniotis, G., de Kinderen, S., Proper, H.A.: Ea anamnesis: An approach for deci-
sion making analysis in enterprise architecture. International Journal of Information
System Modeling and Design (IJISMD) (2014)
8. The Open Group: ArchiMate 2.0 Specification. Van Haren Publishing (2012)
9. Runeson, P., Hst, M.: Guidelines for conducting and reporting case study research
in software engineering. Empirical Software Engineering 14 (2009) 131–164