Reflections on Using an Architecture Model for Matching Existing Applications to a Radical Business Requirements Change: A Case Study

. In this practice paper, we report the outcomes of a case study in a new Dutch hospital, where enterprise architects are working toward a ‘lean’ and ‘sim-plified’ EA model to align existing IT systems to new requirements. The objec-tive of the case study was to examine if the developed EA model could support architects in selecting components of an existing IT infrastructure for re-use, with regard to radically new requirements. We have developed an EA model in close collaboration with enterprise architects. This study reflects on the use of this model in the hospital. The approach combines analysis of the content in the model, a study of documents in the organization, and communication with the architects. We signal that the existence of an integrated suite for an Electronic Health Record system largely determined how the model was used. Reflection disclosed that a lack of information on requirements and applications, as well as low adaptability of existing systems, negatively affected the flexibility of IT in the organization.


Introduction
Extant literature describes Enterprise Architecture (EA) as a promising approach to bridge the gap between Business and IT. In this paper we focus on aspects encountered in the practice of EA modeling. We explain the state-of-the-art concerning EA, at that time, by referring to a study from 2013 that gives an overview of the literature about EA in the period between 2003 and 2009 [1]. In the literature, frameworks of EA are essential in research. TOGAF has been a de facto guideline for practitioners. TOGAF is relevant for the case study, because it can be applied as a roadmap for the transformation of a Base Architecture (AS-IS) to a Target Architecture (TO-BE) as described in [2]. We refer to recent research, where new concerns for IT Flexibility on a strategical level have been described [3][4][5].
This case study introduces a new specialized Dutch hospital (H1) in 2012, planning 600 beds. The hospital required the design of an EA with emphasis on the IT perspectives (Application Architecture, Information Architecture, Technical Architecture). As a guiding principle, the management decided that H1 should reuse the existing IT systems of a nearby academic hospital (H2). The development of the EA would be done by an Enterprise architect and an IT project manager (henceforth called "the architects"). H1 differs from H2 because it specializes in pediatric oncology. Also, H1 aspires to realize a vision in which child and family are positioned in the center of the care processes. Consequently, IT systems needed to be re-evaluated based on this basic assumption.
The case can be characterized as an exception in healthcare in the Netherlands, i.e., the possibility to start a new hospital (from scratch) is rare. However, the hospital builds on the existing infrastructure of a nearby hospital. Therefore, it will not really be built from scratch. The in-use IT systems are not typically legacy systems but are state-ofthe-art systems currently (2018) in operation. The specific Dutch "Electronisch Patient Dossier" (Electronic Health Record System; EHR) solution is in use in more than half of all Dutch hospitals. The number of implementations of EHR-systems was growing in 2014, so EHR-systems can be expected to play a dominant role in the IT of other hospitals as well [6]. The new hospital will be the central node in a network of hospitals. They will be working with "shared care hospitals" in the Netherlands.
We followed the design science research method [7] in designing a model for the EA in close collaboration with the architects. In a first paper, we have presented the resulting model [8]. In the current paper, we reflect on the use of the model, and define the question for our research: Does the developed model support architects in selecting the suitable applications for re-use?
To answer this question, we analyzed the model and studied the decision-making process of the Board of Directors, informed by the internal advice reports and evaluations in the follow-up period. Hence, we reflect on the way the model is applied in practice.

Reflection on model in use
We evaluated two underlying purposes of the model. First, the model had to assist the architects with structuring all the information they collected concerning requirements and functionality of existing applications. Secondly, the model should give an overview of the relations between applications and requirements, in such a way that it helps architects decide on applications for re-use. Two sub research questions were formulated (SRQ1 and SRQ2): • SRQ1: Is the model suitable for structuring the information collected by the enterprise architects? • SRQ2: How does the model assist the architects with selecting applications for reuse?
We reflected on the model during development with the architects (development phase) and afterwards by studying documentation (reflection phase).

Development phase
In the development phase the architects determined new requirements of the organization and the relations of the requirements to the existing IT infrastructure (in H2) by consulting 12 focus groups, the vendors of software, and the IT department in the organization. Examples of focus groups consulted are: Care Unit, Radiology and Radiotherapy, Education, Lab, Enterprise Principles, LATER (concerning health and complications after therapy). Architects provided the mapping of requirements to applications, based on the information they collected in the organization.
The EA model has been developed in iterations. In every iteration the researcher proposed a model and the enterprise architects evaluated the proposal and accepted or changed the model. We registered all drafts and discussed every adaptation with the architects. During development, insertion of data (instance pairs) was a regular activity. Examples of changes were: Adding, deleting or editing concept types names or relations. After the final model had been decided upon, all data considered important by the architects had been successfully inserted into the model. Inserting the data in the model was performed as a check for completeness of the model, and for suitability for structuring information provided by the model.

Reflection phase
After the development phase, an in-depth analysis was performed in the form of frequency distributions and content analysis of relations between requirements and applications. The objective of the analysis was to answer SRQ2, how the model could assist the architects with the task of selecting applications for re-use. Also, we studied documentation, the reports of meetings of the steering group and architects, and reports of the 12 focus groups that formulated requirements. The results of the documentation study were discussed with the architects for answering SRQ2.

Description of the EA model
We selected the Ampersand business rules approach for modeling the EA because it can be applied to produce simplified models that have a mathematical foundation [9,10]. The conceptual model for the EA is flexible and is defined in a separate script; the business rules can be declaratively defined separately in relation algebra, in the same script.
Ampersand is based on relation algebra and defines business information in a meta model. The meta model consists of descriptions of CONCEPTS, RELATIONS, PROCESSES and RULES [8]. A model is defined within a CONTEXT. All information is formulated in text, in the language of the stakeholders. There are no constraints on language for names, as long as the names are 'text'. Names have been used as identifiers. In this paper it is sufficient for the reader to interpret the Ampersand concepts and relations as similar to the entity and relationship names in an ER (Entity-Relationship) model. The business rules in the model allow us to check the degree to which existing systems could fulfill new requirements. See page 5. An explicit goal in designing the model was to include only the concepts needed by the architects for the specific (and somewhat unusual) architecture job at hand. We recognized: strategic goals (named Enterprise Principles by the architects), healthcare and business processes, and the services that are expected from the organization for supporting the processes. The services in the model were primarily application services (information technology services). The model has similarities with TOGAF architecture models. However, it is a simplified model because TOGAF models consist of separate extended models for Business Architecture, Information Architecture and Technology Architecture. In Fig. 1 the concept types and named relations are shown. The model includes both applications and requirements in one view.

Details of Concepts.
In this section, all concepts in the Ampersand model are described.
ENTERPRISE_PRINCIPLE. An Enterprise principle is a principle that must be met according to the architects in the project (30 instances). Principles are derived from the healthcare vision of the hospital and can be compared to the strategic business goals of the hospital. Examples are "Intensive collaboration with medical staff and nursing care personnel and scientific research," "Child and family will influence the care process where ever possible," "Child and family will have the possibility to participate in education when in treatment." PROCESS. A Process is a primary process in the healthcare organization (11 instances). Examples are typical healthcare processes, such as Laboratory and Images, and Medication. DECISION. A Decision is an Action or Goal that is based on an Enterprise Principle (43). Examples of Decisions: Visits must be planned, Reports of Anesthesia and Surgery must be made. It seemed that Decisions are sort of a dead end in the model because only relations to Enterprise principles exist. SERVICE. A Service can be described as a composite service that delivers services for care processes in the healthcare organization (159 instances). Examples are the support for care processes, such as Diagnosis, but also Catering service or the Communication platform.
REQUIREMENT (OR QUESTION). Requirements are specific demands on an application or a combination of applications (132 instances). A large part of the Requirements have been marked Questions by the architects (75 of them). Some examples of Requirements (the remaining 57) are: "Formulate specific learning objective for every child", "Functionality of patient portal is available through a website, a column in the building with electronic card, and via an app", "The new and existing scheduling data from application X have to be transferred to another financial salary application", "E-consultation". Architects marked 75 requirements as "questions" that needed an answer before a requirement could be mapped to an application. That has resulted in two types of requirements, requirements and questions.
APPLICATION_EXISTING. This Ampersand concept concerns an application module or another component of the Information System (88 instances). An existing application is a software system that supports the care processes in the healthcare organization. A specific set of applications is the EHR, where all information about patients and treatment is stored and can be edited, or retrieved. The EHR System accounted for a significant part of the applications that were defined. In the model, the EHR-system consisted of 39 modules, a ratio of 44 percent of all defined applications.
PROJECT. A project stands for a main EA project in the healthcare organization (1 instance). The architects have not reached the stage of formulating Projects.

Relations and Rules.
Relations are sets of tuples, instances of two concepts. A total of 2756 instance pairs have been formulated. Some relations were filled with only one, fake pair (1 pair).
When analyzing the Rules, we can conclude there are two kinds of rules. Rules for achieving the goals of selecting applications and rules for consistency of data in the model. For instance, all must_fulfill instance pairs have a similar fulfills pair. In Table  1 the relations 1 can be overviewed.

Analysis of requirements and applications
The researchers have performed an analysis after collected data had been inserted into the final model by architects. It was part of the Reflection phase. For this phase, we concentrated on the must-fulfill-relation since the fulfills-relation is empty.
To deepen our understanding and insights, we counted the number of requirements coupled to application modules and vice versa. We aimed to find the mapping relation, as a 1:1, 1:many, or many:many relation. The type of relation enabled us to see whether it is feasible to map requirements unambiguously to applications. For instance if every requirement only concerned one application and vice versa (1:1 relation) then the requirements were unambiguously related to one application and vice versa. First, we have checked if every requirement had been linked to only one application. This relationship demonstrates traceability of every requirement to an application. We could further investigate the degree in which the application did support the requirement. See Fig. 2.
When categorizing the must-fulfill-relation, we find a many:many relation between requirements and applications. Questions of architects also concern many applications each. Combining results of all counted pairs leads to the conclusion, that the requirements and applications are not structured in the same way, and that requirements cannot be mapped unambiguously to a specific application.
In related research, a framework has been developed that describes how to detect Business-IT misalignment symptoms [11]. When analyzing the misalignment of the TO-BE and AS-IS architecture with that framework, important indications concern organization and responsibilities, such as "S.01Undefined organizational mission, strategy and goals", "S.02 Undefined business process goals, business process owners", "S.03 Lack of relation between process goals and organizational goals". These symptoms of misalignment have not been found in the case study EA model. However, other symptoms regarding misalignment of Business process tasks and Applications are present in the model. For instance, "S.06 Application does not support at least one Business process" is signaled in the form of missing fulfills-relation in the EA model.

Fig. 2. Number of Applications with each requirement, final model
Also, the indication "S.07 Business process task supported by more than one application" is signaled. The must-fulfill-relation shows S.07 in the case study. We conclude, based on this analysis, that the simplified EA model signals misalignment of business requirements and applications.

4
Using the model

The role the model played in the decision process
In the follow-up after the model had been completed with data, we could observe the role the model played in decision making. It was decided by the Board of Directors and architects, that in the startup period (planned in 2014) the components of the IT systems were considered sufficient, unless medical professionals objected to specific components or applications. For their evaluation of the existing IT systems, the scope of the requirements had been restricted. Requirements related to many strategic goals were declared outside of evaluation scope, only working processes would be considered. The evaluation report stated that the IT infrastructure had sufficient capabilities to support the short time requirements for opening of the new hospital. Citation from Evaluation end report May 2013: "The current, existing IT infrastructure is to a large extent sufficiently capable of supporting the working processes in the startup period. Some adaptations of application REQ6 Requirements and number of Applications X are necessary for the adequate support of specific healthcare processes. These adaptations have to be realized in the period preceding startup period." 2 The report describes in detail which adaptations in the IT infrastructure are a precondition for the new hospital. The bottom line is that standard working processes can be supported. Unfortunately, the model seems to have played only an indirect part in this decision, although the enterprise architects that made the model were on the selection committee.
However, healthcare processes that deviate from the work processes in other hospitals, such as prescriptions for medicine, preparation of medicine and registration of cytostatics for children were considered a risk.

Follow up evaluation by a working group of medical professionals
The steering group decided in April 2013 to start a new project for the period May-August 2013, to examine possibilities for developing an integrated (new) system for prescriptions of medicine, preparation of medicine and registration of cytostatics for children in the new hospital. A working group investigated requirements and applications for the prescription process. From the documentation, the assumptions of the project participants became apparent. The working group set out with the following assignment 3 : 1. Describe the processes of working with protocols; 2. Define essential components in the current IT infrastructure that have to be included in the new IT systems; 3. Define criteria for scenarios; 4. Work out scenarios in detail to combine the functionality of different existing applications; 5. Evaluate the scenarios; 6. Advice the steering group of the most suitable combination of applications.
The working group reported a scenario that combined three existing applications, including applications that were not used in the existing IT architecture. We can read in the report of the follow-up project 3 that a mismatch was found in the existing application landscape to support care processes for prescription of medicine. The medical professionals observed the same misalignment as was disclosed by the EA model.
Since the enterprise architects were part of the steering group, we assume the model played a role in the decision-making process, because we know that the model did provide an overview for the involved architects, though possibly an indirect one.

5
Conclusion and discussion

Research questions revisited
We answer the sub research questions in this paragraph. For SRQ1, we conclude that the model served the purpose of structuring information sufficiently, based on the test of inserting information in the model and discussions with architects. See 2.1.
The mapping of new requirements to existing application proved a challenge. The architects concluded that the mapping of requirements to applications could not be performed unambiguously, such that applications or modules could be selected for re-use. However, the model did provide the possibility for indicating that an application fulfilled the new requirements. See 3.2.
Therefore, for SRQ2, we conclude that the information that was collected by the architects was incomplete for selecting applications for re-use with the model.

Reflection and discussion
We observed that a large number of applications are part of a EHR-suite, or other integrated/interwoven application systems. Consequently, it was difficult to map requirements separately to each application module in the EA model. We found numerous questions of architects about functionality, hence an indication that the documentation of functionality for specific hospitals is insufficiently accessible (if at all). As a further consequence, one cannot see how new requirements compare with the old ones.
Our study does confirm the findings in the study [12], that a radical renovation of existing EA has to overcome the traditional structure of working and supporting IT. Our study adds new information by showing in some detail how the current IT architecture made up of integrated applications has obstructed innovation. It describes how lack of transparency and a modular structure that does not offer required flexibility, can obstruct innovation.
Our findings suggest that the core assumptions of architects: 1. insight in a finegrained functionality in the applications, 2. flexibility of functionality for re-use and 3. transparency of the IT infrastructure, have been disproved.
It is too early to say that similar projects in other hospitals might lead to similar impasses because of similarity like IT systems. More research of EA in changing environments (of various kinds) is needed to extend the knowledge domain of EA to include adaptability, especially of the Application Architecture.

Recommendations & Future Research
We suggest that elaborate and costly efforts like the one in our case (business requirements, 12 focus groups, model), should lead to actual and explicit use of the model in the decision process (Return on Modelling Effort). Fortunately, it does seem to have been used indirectly, through the involvement of the architects in the decision process and steering group.
In a new study, we will perform a follow-up on this research by investigating how a separation of the data structure from the application layer can add to IT Flexibility. This research is likely to result in an expansion of the model of the EA model.

Limitations of validity of the research
This case study demonstrates clearly how architects struggle with many unknowns in the situation of modeling the EA for selecting applications for re-use. Since the case describes the situation of an organization startup, this could (partly) have caused some of the unknowns. However, the value of this case study lies in calling into question the core assumptions of architects and EA frameworks, such as the possibility of adapting existing IT systems and having complete access to information about IT systems and integrated application suites. If these core assumptions are not confirmed then IT Flexibility cannot be achieved by applying this EA model.