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. However, up to now, our assumptions regarding the usefulness of our approach 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, rstly 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.
Increasingly enterprises are faced with change due to challenges such as
acquisitions, mergers, technological innovation and the introduction of new business
processes. Enterprise Architecture (EA) is positioned as an instrument for
helping enterprises to cope with such a change [
However, while EA frameworks and languages aid rst in designing a change
and subsequently implementing it, the reasons behind the design (hereafter
referred to as design rationalization) are often left implicit. As a result, new designs
are constructed in an ad-hoc manner [
As a result, our earlier work [
However, up to now, the empirical evidence for the usefulness of EA
anamnesis is limited to a survey amongst EA practitioners [
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 requirements from practice to which our rationalization approach should respond. As such, the speci c 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 [
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 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 2.1
Research and Technology Organization Case Study
The research planning of the case study as well as this section structure are based
on guidelines for case study research [
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 nancial 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 nancial data. Last but not least, a training for the users of this new business process should be organized. 2.3
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. 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.
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, nance and human resources. These business processes were supported by the corresponding information systems.
In this part we describe brie y the new business process and information systems that were used in the next step of the transformation to support the Project Manager
Project Manager
HR Officer
HR Officer
Financial officer
Financial Officer Project Management Financial Management application components and services new business process.
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 estimation 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 signi cantly 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 bene ts, while the endogenous maybe associated with personal assignments, change of strategy etc. The role of the business process is to provide annual budget estimates, which should be validated and approved by the nance department.
IT Systems: Application A is the main nancial application of the organization. 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 nancial o cers.
Application B is the human resources management application. Tasks like resource allocation, start/end dated of work contracts, weekly calendar, di erent 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.
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.
Figure 3 depicts a nal iteration of the enterprise transformation. With this iteration stakeholders managed to addresses the above mentioned problem. Instead of using spreadsheets for entering the budget data, a new application interface was added in nancial application A. 2.4
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
Project Manager
HR Officer 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 in uenced their decision making: During the execution of the enterprise transformation another 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 Project Manager
Project Manager RTO had overlapping roles with departments of the other organization. Moreover new business models should be de ned 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 nancial departments and business processes would be merged, therefore the risk of wasting budget for signi cant 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 decision 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 nancial o cers 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 example: by using rationalization one explicates the negative observed impact of diverging spreadsheets as a result of the introduction of the new business process 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.
However, the domain of Enterprise Architecture still remains unexplored. In a
survey [
Challenge 1: One of the main goals of Enterprise architecture is the provision 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 di erent domains (Business, IT). As we previously saw in our case study, di erent factors in uence their decision making, which in turn a ect the quality of design decisions. 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 architecture is the capturing of this reasoning process. In doing so, stakeholders which analyze EA designs will be capable to better understand why speci c 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 e ectively the realization of new business processes. As we saw, during an enterprise transformation several design decisions are made, both in Business and IT sides. These design decisions rarely exist in isolation. Rather, design decisions are often cross cutting and intertwined. A rationale management system for enterprise architecture should be able to capture the di erent types of relationships among design decisions. For example, design decisions made on business levels can infer design decisions in IT level of the organization and vice-versa. On the other hand design decisions can be interrelated with a speci c EA Artifact or domain of the Enterprise. An RMS system should be able to distinguish between these di erent 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 speci cally, during the analysis of the enterprise design, stakeholders should be able to identify which design decisions constitute speci c 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 nancial application and we can check which decisions are related with this artifact.
Challenge 4: Sometimes design decisions can have unanticipated consequences in the artifact itself or in di erent artifacts in the enterprise architecture. As an example, consider the design decision for the spreadsheet template that had negative consequences in the use of a budget forecast business process. A rationale management system should also keep track of these incidents and how they were addressed by means of newer decisions. By doing so enterprise 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
In this section we de ne 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 di erent domains (civil, software architecture). These approaches have introduced di erent sets of domain speci c concepts. By answering this research question we aim to identify which concepts from existing frameworks can be used for the domain of enterprise architecture and what is actually missing to provide a holistic overview of design rationale in enterprise architecture. The identi cation of these concepts will provide a taxonomy of rationalization information for enterprise architecture and in turn the basis for the development of a design theory for the same purpose. The challenge, from a design theory point of view, is the identi cation 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 Architecture is challenging due to the implication of di erent stakeholders from di erent domains and due to factors that a ect 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 speci c decisions and recognize which factors actually in uenced this decision making process. By doing so, they can consult for their future evaluations by following/avoiding good/bad evaluations from past decisions making processes.
Question 3: How do we capture and represent di erent decision relationships in Enterprise Architecture?
The confrontation of this research question will provide a holistic overview and traceability of the enterprise architecture. The domain of enterprise architecture introduces several challenges since decisions from a speci c 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 speci c decision may introduce problematic situations in di erent domains of the enterprise. To cope with this research question we will investigate existing design rationale approaches from di erent domains and we will identify the speci cities imposed by the domain of enterprise architecture. 5
In this paper, based on a case study in a Luxembourgish research and Technology organization we identi ed 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 enterprise 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 modi cations.