João Barata
email: barata@dei.uc.pt

Paulo Rupino Da Cunha

Ctcv

Modeling the Organizational Regulatory Space: A Joint Design Approach

Keywords: Information system design, regulation, compliance, organizational regulatory space, O2 framework

We present an approach for the joint design of organizational regulatory spaces (ORS). The approach was validated through action research, integrating the components of context, people, process, information, and IT. The design of the ORS is usually performed by distinct teams, with unconnected viewpoints, using different vocabularies and tools. Similarly to information systems, there are business experts that define the regulatory goals and rules. The ORS modeling is problematic, and is fragmented. We have adopted the O 2 framework to provide a common level of abstraction for the design. The result is a comprehensive and layered map of the ORS. This approach has proved to offer an effective representation of the ORS for external auditors and business associations. Internally, we provide organizations with new ways to model, communicate, and improve the regulatory space.

Introduction

The organizational regulatory space (ORS) is a key element of contemporary societies, shaped by laws and standards, but also by internal policies, norms, contract agreements, and corporate procedures [START_REF] Hancher | Organizing regulatory space[END_REF][START_REF] Parker | Reinventing Regulation within the Corporation: Compliance-Oriented Regulatory Innovation[END_REF]. Organizational regulations may be enforced (e.g., in the case of legal requirements), or they may be voluntary, for instance when a standard is used to guide the management system or the product specification. Either way, in the majority of the cases, regulations are seen as a burden in organizations. A number of internal and external entities may influence the ORS, such as governments, private regulators, business associations, customers, or even organizational managers. The design of the ORS is then executed by distinct experts with financial, legal, technological, and managerial knowledge. However, more than a complex set of business rules, the ORS is a holistic conceptual space where people develop specific processes, interacting with each other and with the environment, exchanging information [START_REF] Parker | Reinventing Regulation within the Corporation: Compliance-Oriented Regulatory Innovation[END_REF]. The regulatory space becomes unique for each organization.

To separate the information system (IS) from the ORS is unfeasible. On one hand, the ORS is designed with regulatory information. On the other hand, the IS design must attend to the stakeholders viewpoints, the technology, and the nature of the strategic and operational activities involved [START_REF] Curtis | A field study of the software design process for large systems[END_REF][START_REF] Baxter | Socio-technical systems: From design methods to systems engineering[END_REF]. Business process management presents solutions that can guide the design of IS and organizational rules [START_REF] Zairi | Business process management: a boundaryless approach to modern competitiveness[END_REF]. Nevertheless, we must take into consideration that not all the regulations are "processfriendly" (e.g. several financial regulations), and, even when they are, problems can still exist by adopting a process approach in regulatory contexts [START_REF] Iden | Investigating process management in firms with quality systems: a multi-case study[END_REF]. The list of problems increases if we consider the distinct vocabulary among the ORS experts [START_REF] Abdullah | A Compliance Management Ontology: Developing Shared Understanding through Models[END_REF]; the diversity of the external legislation and standards, such as the Sarbanes-Oxley act, ISO management standards, codes of practice or business partners contracts; the need to translate the external requirements into internal procedures and practices; and the difficulty in integrating and evidencing regulatory compliance [START_REF] Abdullah | Information systems research: Aligning to industry challenges in management of regulatory compliance[END_REF][START_REF] Abdullah | Emerging Challenges in Information Systems Research for Regulatory Compliance Management[END_REF] in audits, and voluntary or statutory reporting. The design of the ORS is critical for organizations operating in distinct regulatory spaces around the globe, each one with a specific set of rules, norms, and cultural characteristics.

Although a number of studies address the problem of compliance modeling and checking [START_REF] Kharbili | Business process regulatory compliance management solution frameworks: A comparative evaluation[END_REF], we could not find a framework for cooperation in the initial phase of designing the goals, rules, and boundaries for the compliant behavior. Moreover, there is a gap concerning the compliance extraction and elicitation, and the holistic representation of regulatory space. To increase the chances of developing a joint design of the ORS, all the stakeholders must work together from the beginning. This paper address several IS and regulatory management problems identified by [START_REF] Abdullah | Information systems research: Aligning to industry challenges in management of regulatory compliance[END_REF][START_REF] Abdullah | Emerging Challenges in Information Systems Research for Regulatory Compliance Management[END_REF], namely, the lack of compliance culture; top level management support; perception of compliance as a value-add; communication among staff; compliance knowledge base; holistic practices; and IT support/tools.

We now invite the reader to imagine the chief executive officer (CEO), the integrated systems manager (IMSintegrating quality, environmental, health and safety), the chief financial officer (CFO), the legal adviser (LA), the marketing manager (MM), and the chief information officer (CIO) in the same room and at the same time designing the ORS. The remainder of this paper is organized as follows.

The next section provides the background of the research, followed by the method selection. Section 4 presents the results in three cases of action research to model the ORS. We conclude by summarizing findings, the study limitations, and future work.

Background

This section reviews key concepts of ORS, IS design and compliance.

2.1

The Modern Organizational Regulatory Space (ORS)

The term "regulatory space" was introduced by [START_REF] Hancher | Organizing regulatory space[END_REF]. The authors define regulation as a combination of public and private characteristics that involve dynamic relations between and within people and organizations, sharing a common space of specific regulatory issues. In [START_REF] Hancher | Organizing regulatory space[END_REF], the "space" metaphor is in the scope of national regulation.

According to [START_REF] Shearing | A Constitutive Conception of Regulation[END_REF], the regulatory space is a social space "in which different regulatory schemes operate simultaneously [… and] the state must compete for control of regulation with other regulatory entities". In this sense, private regulators, interest groups, and distinct business experts also influence the regulatory space. For this research, we have mobilized and restricted the concept of [START_REF] Hancher | Organizing regulatory space[END_REF] to an organizational level, representing the entire set of regulations, either imposed or voluntary, that an organization decides to implement. The ORS includes standards, that are voluntary regulations, increasingly adopted worldwide to implement management systems. The standards address quality (e.g. ISO 9001), environmental management (e.g. ISO 14001), health and safety regulations (e.g. OHSAS 18001), and corporate responsibility (e.g. SA 8000). They also cover specificities of sectors such as food (e.g. ISO 22000), laboratorial (ISO/IEC 17025), or aeronautical (e.g. AS 9100). When a company decides to follow or be certified by a specific standard, a set of internal procedures and practices must be developed. The compliance with legislation is also required by standards, such as the environmental, health and safety. When multiple standards exist, [START_REF] Jørgensen | Integrated management systemsthree different levels of integration[END_REF] outline three possible levels of integration: (1) "compatibility with cross-references between parallel systems"; (2) "coordination of business processes"; and (3) "an organizational culture of learning, continuous improvements of performance and stakeholder involvement related to internal and external challenges".

The regulatory space is a socio-technical space combining people, processes, and information [START_REF] Shearing | A Constitutive Conception of Regulation[END_REF]. An "outside-in" perspective is needed to define the organizational regulatory context of the business. Standards and laws, combined with contract agreements, policies and norms, are then translated in procedures that regulate the "within" behavior of people, processes and information. Finally, the regulatory space also demands an "inside-out" perspective, concerning customer relationship, legal and financial information, or statutory reporting.

IS Design and Compliance

The IS design has to tackle distinct interrelated components such as the information, IT, processes, and human aspects in organizational context [START_REF] Laudon | Management Information Systems: Managing the Digital Firm[END_REF]. Compliance is a well-known research subject in IS. The literature addresses topics such as the compliance of business processes and services [START_REF] Araujo | A method for validating the compliance of business processes to business rules[END_REF][START_REF] Sadiq | Managing Regulatory Compliance in Business Processes[END_REF][START_REF] Tran | Compliance in service-oriented architectures: A model-driven and view-based approach[END_REF], requirements engineering and conceptual modeling [START_REF] Ingolfo | Establishing regulatory compliance for software requirements[END_REF][START_REF] Ghanavati | Integrating business strategies with requirement models of legal compliance[END_REF], auditing IS compliance [START_REF] Sangkyun | Auditing methodology on legal compliance of enterprise information systems[END_REF][START_REF] Julisch | Compliance by design -Bridging the chasm between auditors and IT architects[END_REF], and the alignment between law and IT compliance [START_REF] Bonazzi | Compliance management is becoming a major issue in IS design[END_REF]. However, the majority of studies focus on the perspective of modeling and checking compliance [START_REF] Kharbili | Business process regulatory compliance management solution frameworks: A comparative evaluation[END_REF], lacking the human behavior in that regulatory space and the guidance to allow cooperation between different experts, not specific to a technology or IT architecture. The IS must consider not only the "formal" IT solutions that support the processes, such as an ERP or a business process management system (BPMS), but also the "informal" IT tools, such as spreadsheets and desktop databases that proliferate in the organizations [START_REF] Handel | Working around official applications[END_REF]. To design an IT artifact, we must be concerned with the context, the designers, users and beneficiaries of the IT, processes, and the information [START_REF] Laudon | Management Information Systems: Managing the Digital Firm[END_REF][START_REF] Zhang | IT Artifacts and The State of IS Research[END_REF]. These IS components may be represented as layers, that interact and influence each other and their environment [START_REF] Avison | A further exploration into information systems development: the evolution of Multiview2[END_REF][START_REF] Kautz | Persistent problems and practices in information systems development[END_REF]. The identification of the layers can integrate multiple viewpoints, according to each system stakeholder and particular field of knowledge [START_REF] Sommerville | Viewpoints: principles, problems and a practical approach to requirements engineering[END_REF]. There are similarities between the development methods of the IS and of specific systems that define the ORS, for instance, the ISO 9001 management system [START_REF] Barata | ISO2: A New Breath for the Joint Development of IS and ISO 9001 Management Systems[END_REF]. As stated by [START_REF] Parker | Reinventing Regulation within the Corporation: Compliance-Oriented Regulatory Innovation[END_REF][START_REF] Julisch | Compliance by design -Bridging the chasm between auditors and IT architects[END_REF][START_REF] Bonazzi | Compliance management is becoming a major issue in IS design[END_REF], both the IS and regulatory compliance should be achieved by an holistic design.

Method

We used action research to guide our investigation, simultaneously aiming to improve scientific knowledge and assist a practical problem [START_REF] Hult | Towards a definition of action research: a note and bibliography[END_REF]. As our purpose was not only to develop an ORS model and a design approach, but also to study the organizational changes, action research seemed the best approach. We have followed its canonical format, characterized by the five phases of Diagnosing, Action planning, Action taking, Evaluating, and Specifying learning [START_REF] Susman | An Assessment of the Scientific Merits of Action Research[END_REF]. To evaluate our research, we have relied on the principles proposed by [START_REF] Davison | Principles of canonical action research[END_REF]. Table 1 lists the action research cases and the main standards that influence their regulatory space. An initial diagnosis was conducted simultaneously in all these organizations, to understand the communication and artifacts used [START_REF] Perry | Coordinating joint design work: the role of communication and artefacts[END_REF], and to prepare the mindset for the following action research phases. The diagnosis also included a fourth company, in the aeronautical sector, certified by ISO9001, EN9100, and AS9100. This case is a work in progress that we identify by 4w, and exclusively report in section 4.1.

The initial data gathering techniques were the document collection, and semi structured interviews with the managers [START_REF] Myers | The qualitative interview in IS research: Examining the craft[END_REF]. The developed regulations comprise a number of policies, plans, and work instructions, be them internally decided or required by some standard, law, or customer contract. The cases 2 and 4w presented a higher complexity regarding laws and contractual agreements, when compared with cases 1 and 3.

ORS Modeling in Action

Section 4.1 describes the setting that we found in the four organizations. We specify which organizational management functions were most involved with regulations, their perspective of the ORS, and cooperation between functions. Then, we present our action planning, with the O 2 framework [START_REF] Barata | ISO2: A New Breath for the Joint Development of IS and ISO 9001 Management Systems[END_REF]. The subsequent sections summarize the action taking, evaluation, and lessons learned. The intervention in cases 1 to 3 occurred consecutively, each case benefiting from the previous findings.

Insights from Simultaneous Diagnosing

The four companies acknowledged the relevance of the regulatory space although they could not represent it clearly, as an holistic model. Citing the top manager of the company involved in case 2: "we need a map or we will get lost in a jungle of regulations […]". Each interviewee had its own partial perspective of the regulatory space. Although the four companies had different managers for different standards, they all had an integrated system manager (IMS) to coordinate the company certifications. According to the interviews, the IMS primary concerns were the standards requirements, and regulatory audits. The CFO was also head of human resources management in the four cases. All the LAs were external and concerned with the legal context. The LAs recognized they made preventive work, such as to notify the organization of the most relevant legislation, although the majority of their interventions were originated at the CEO request. The contractual agreements were central issues for the MM and the CEO. While the CFO was mostly concerned with financial regulations, the CIO was specially focused on IT to support compliance, and the regulations that affected IT.

The four companies use IT to support regulatory management, including the subscription of web portals for legal information, multiple disconnected spreadsheets of legal obligations, and content management systems for regulatory documents, such as laws, standards, contracts, and procedures. The IT support was insufficient for an effective regulatory management, because it consisted of mere lists of obligations. Worse, regulatory management was burdensome, with no added value for practice.

To identify key management players of the ORS, we asked the top and intermediate managers of the four organizations to classify from 1 (none) to 5 (very high) the regulatory cooperation. We have defined regulatory cooperation as the need to work with other management functions, their communication frequency, and/or dependence on the other functions to achieve regulatory compliance. The median values of those classifications are presented in table 2. These answers are only relevant to understand the setting of the selected cases. They suggest that all the interviewees need to communicate in the regulatory space. The CEO and CFO are core players of the space (both reported 5 in the need to cooperate with each other). Although some functions report lower levels of regulatory cooperation (e.g. the CIO and MM, with the value of 2), the purpose of our approach is that all may be involved in the ORS design. The LA does not appear to have a central role in the ORS. The reasons differ. For instance, in case 1 and 3, the legal regulations are less significant when compared with other regulation types. In all cases the LA communicates sporadically with the managers. The four CEOs reported that managing of the regulations, people, IT, and processes were independent and difficult to connect. For instance, a number of employees did not know all the essential legislation applicable to their work; internal procedures did not properly reference legislation; there was a lack of awareness on how each regulation was supported by IT; and it was difficult to link IT and organizational processes.

Subsequently we asked the managers to classify the most relevant types of regulations for their daily activities. The results are presented in table 3. The median of all the table values is 4 (high). The answers show that each manager has a distinct perspective of the regulatory space (e.g. contract agreements by MM; standards goals and rules by IMS). Concerning the CEOs and IMSs, they justify the high classification of the internal procedures (median of 4,5 and 5 respectively) with the "need to set the example" to others. This effect was not found in law, standards, and contract regulations. Is possible that when defining internal policies or converting a law to internal rules or goals (internalization), the compliance may be improved by "setting the example". Nevertheless, we must be conscious of the risk to "face temptation to be content with creating appearances that will promote confidence and to be less concerned with ensuring that this confidence is actually warranted" [START_REF] Shearing | A Constitutive Conception of Regulation[END_REF].

We found that the ORS is not designed by one person; it is a result of a social constructed negotiation [START_REF] Hancher | Organizing regulatory space[END_REF]. The experts have called for an approach to combine efforts in IS and regulatory management. The next section presents the approach for the joint design of the ORS.

Action Planning: The O 2 Framework

The O 2 framework was initially proposed by [START_REF] Barata | ISO2: A New Breath for the Joint Development of IS and ISO 9001 Management Systems[END_REF], for the joint design of IS and ISO 9001 management systems. The action planning phase of our research uses and extends the O 2 framework, presented in figure 1, and briefly described in this section. The O 2 framework provides a common level of abstraction to the design team. Distinct experts focus their analysis in the essential components of an IS, represented in figure 1. The regulatory goals and rules must be identified from the organizational context ("outside-in"), incorporated in daily practice by the IS ("within"), and then provide external evidence of compliance ("inside-out").

The framework was first created to complement the process approach in the joint design of the IS and an ISO 9001 management system. This need is consistent with previous studies, pointing to the insufficiency of a process approach in the ISO 9001 context [START_REF] Iden | Investigating process management in firms with quality systems: a multi-case study[END_REF]. The diagnosing phase presented in our research also points to a similar problem, when addressing the ORS design by a strict process perspective. As we recognize that the process approach is fundamental for the IS and for regulatory spaces, we suggest that should be complemented to achieve a holistic joint design.

In this mind set, a regulatory space is not a burden, is a space in which organizations must cooperate and learn to design with simplicity, according with multiple viewpoints and concerns [START_REF] Sommerville | Viewpoints: principles, problems and a practical approach to requirements engineering[END_REF]. The use of the O 2 framework bridges distinct paradigms of interrelations, such as the organization and the environment ("outsidein" and "inside-out" information flows), the processes and the structure (under the context layer), and the inner and outer worlds [START_REF] Van Fenema | Paradigm Shifts in Coordination Theory Introduction[END_REF]. However, the O 2 framework is only a graphical representation of the main IS components that must be considered in the ORS. There are three artifacts that we use for practice: the O 2 matrix; the O 2 artifact; and the O 2 map. The artifacts and an example of their implementation are offered in figure 2. An O 2 matrix is designed for each organizational process. The example of figure 2 is for D&Ddesign and development process. The designers fill the matrix cells with the IS requirements for that process. Then, we extract the O 2 artifacts, that are IT artifacts [START_REF] Zhang | IT Artifacts and The State of IS Research[END_REF], as illustrated in figure 2. The steps to identify the O 2 artifacts and create an O 2 map are [START_REF] Barata | ISO2: A New Breath for the Joint Development of IS and ISO 9001 Management Systems[END_REF]:

1. For each process, identify the requirements according with the components of process tasks, people, IT, and context needs (matrix lines). Consider the current and the planned. Take into account the dynamic of information flows, the "outsidein", "within", and "inside-out" perspective (matrix columns); 2. Group the requirements by colors (black represents a shared requirement), each color representing an O 2 artifact, which in turn are the development projects. It may be a new IT platform, a paper document, a part of an already existing system, such as an ERP, or any other means to allow the information (oxygen) flow, providing to end users (system cell) the vital process information (breathe); 3. Repeat 2 for every processes until an ecosystem of O 2 artifacts are designed; 4. Connect all the O 2 artifacts with the processes (breathing system): the O 2 map.

The O 2 framework was not initially developed for designing an ORS, so we have extended the steps of the design. After creating all the O 2 matrixes for the organizational processes, we must: 5. Identify the regulations and specify the goals and rules that must be accomplished by the organization;

6. Identify the requirements in the O 2 matrixes that are affected by the regulation ("outside-in"), help to comply with the regulation ("within") or are meant to provide evidence of compliance ("inside-out"). New matrix requirements may be discovered at this stage, to achieve compliance with regulations; 7. For each O 2 artifact, create a list of the applicable regulations and update the O 2 map, as illustrated in figure 3. The regulations are not directly connected with processes, as expressed in figure 3, but with the elements that the organization uses to manage regulations: the O 2 artifacts (IT artifacts in any form or medium). This is easier for designers that may not be so familiar with processes; for regulations that are not "process-friendly"; in organizations with deficient process approaches; and, hopefully, more effective for the IS development of the obtained IT artifacts. The O 2 artifacts can also be connected with each other, for instance, two artifacts that need to be integrated or share information.

Our decision to employ the O 2 framework as the action plan has occurred during the first action research cycle. Step 5 was simplified in our action research cases, because they already had a list of regulations, due to the multiple ISO certifications.

Step 6 is the most demanding if many regulations exist. The difficulty is that for each regulatory goal or rule, we must seek the requirements in all the matrix cells that are somehow related with the regulation (influenced by the regulation, processing the regulation or providing evidence of compliance). The first case started with a fuzzy idea of joint design, as we detail in the next section.

The First Action Research Cycle

Case 1 has occurred in a large ceramics company. It exports 73% of the production to all continents, and has frequent customer audits. Due to the ISO 14001 and OHSAS 18001 certification, the company has to comply with over 500 national and international laws, each with several requirements. For each one, the company needs to establish a monitor plan and compliance actions, if applicable. The regulatory space was difficult to manage. The organization maintained a spreadsheet to describe the obligations of each regulation. This was a cumbersome mission performed almost exclusively by the IMS manager. Additionally, the IMS reported that "It is a disappointment when we realize that there is an enormous effort of regulations management, but I am the only one that uses this spreadsheet. It is difficult to make it an effective tool for other departments. Regulations are not a shared issue."

We have started to explore possibilities for our action plan. Due to the ISO certifications, we have tried to follow a process approach to design the ORS, finding regulations for each process. Although a process was a familiar concept to the CIO, CEO, and IMS; the legal, marketing, and financial managers were not comfortable with the concept. The CFO, the MM, and the legal expert stated that contractual agreements and law -their main sources of regulation, were addressed to organizations and people, not internal processes or activities. We also found problems when the IMS and CIO recognized that the process map and procedures were not detailed enough to design the ORS. A BPMS system could help, but the processes were precisely a part of the communication problem, and the CEO did not plan new investments at that moment. We also couldn't consider to immediately migrate all the IT to a new paradigm or forgetting the shadow applications [START_REF] Handel | Working around official applications[END_REF], such as spreadsheets and desktop databases that seem to have an important role in the regulatory space. We were stuck with different viewpoints, and decided to adapt the O 2 framework.

First, the design team created the O 2 matrixes for all the organizational processes. They have selected the same processes defined for ISO 9001 certification. Then we have opted to continue steps 5 to 7 with a set of the most relevant regulations. As iterations evolve, there is a deeper understanding of the impact of a specific regulation in our context, processes, people, and IT. How that regulation affects us ("outsidein"), how we apply and monitor its compliance ("within"), and how we provide evidence of compliance in our "inside-out" activities.

This ORS design with near 100 regulations was completed and peer reviewed for 3 weeks, coinciding with an external audit from a major customer. The customer was interested in evaluating quality and social practices, such as people's work and compliance with laws. The IMS has decided to show the O 2 map to the customer. Interestingly, the O 2 map became the audit program. The customer decided to ask for each O 2 artifact, which, in some cases, was an IT application (e.g. survey platform for customers and personnel satisfaction), in other cases a documented procedure describing practices. The auditor made inquiries regarding each function expressed in the O 2 map to understand the correspondence with practice. The main conclusions were: ─ The O 2 map is a possible representation of the ORS; ─ The O 2 matrixes, artifacts, and map were easy to understand by internal workers, and external auditors/customers; ─ The ORS designed by the O 2 framework may be used for audit programs.

Creating matrixes for regulations, even if not very detailed in a first round, was a slow task. A part of the problem is that we did not have a software tool to support the ORS design. However, by creating the matrixes we improve regulatory awareness, progressively involved more people in regulations, and discovered their real impact in the organization. When compared with the previous spreadsheets, this type of modeling is far more complete and accurate, according with the team.

The Second Action Research Cycle

In this case we dealt with an agro-food company with five lines of sauces and olive production. They export to pizza restaurant chains and supermarkets around the globe. The customer and certification audits are regular, at four times on average each month. Product traceability, law, market regulations, standards checklists, and contractual agreements are critical for the agro-food sector. We found that the company did not have a process map, because the adopted food safety standards did not require or suggest a process approach. Due to this problem, they have decided to consider their five product lines as the processes concerns. The organization told us that each line was so important that represented their core processes. However, some regulations were not specific to product lines but to other processes, such as provisioning, sales or people training. For this reason, as regulations were evaluated, new processes were identified. In one of the meetings, the IMS presented a process map to the team. Although considering that process map a first draft, they found that the O 2 matrixes have facilitated the identification of their processes. This occurred because the regulations have pointed to other critical activities they performed, not yet systematically managed as processes, or even evaluated in terms of regulations.

The O 2 map was presented to the top manager, which had to prepare a meeting in the national association of their sector. The agenda included the discussion of a specific law that required changes. The O 2 map and a fragment of the matrixes were used at the association meeting to represent the impact of the law in their organization.

Until that moment, we did not have explored the possible use of the ORS to external communication, except with auditors. The conclusions of this cycle were: ─ The framework may be used for first steps of process identification and design; ─ According to the managers, the CEO was now more interested in the regulatory design, seeing more benefits from an holistic ORS; ─ The framework may be useful for external cooperation.

The Third Action Research Cycle

This cycle addressing ORS modeling is a sequent cycle of the research we present in [START_REF] Barata | ISO2: A New Breath for the Joint Development of IS and ISO 9001 Management Systems[END_REF]. The institute is a private, non-profit organization, with the mission to provide technical support to industry and to promote innovation. They have hundreds of interconnected internal procedures, required by their four certified laboratories. Since we already had developed the O 2 matrixes for each process, we decided to concentrate this case in the development of a software tool and in a prototype of a more advanced ORS map. The experience from cases 1 and 2 was also valuable for the development of the support tool, whose main screen is presented in figure 4. The interface allows saving the distinct viewpoints from designers, and also combining the viewpoints in a single joint matrix. There is a version control, and the functionality to manage action plans to accomplish requirements. Because each requirement is now in a separate cell, it is easier to link requirements with regulations (double-click).

Another aspect that we were interested was to provide different views of the O 2 map to different stakeholders. Although a representation such as the one in figure 3 can be used, a 3D model would be more appealing and intuitive. This is possible because all the O 2 framework components of context, people, processes, and IT, are connected directly (e.g. processes and IT) or indirectly (e.g. people and IT trough processes). The ORS map evolved to a layered presentation, illustrated in the figure 5. At this stage of the research, the tool does not create a 3D map as represented in the figure 5. We only illustrate how the representation can be achieved. The map provides a high level view when compared to BPMN models [START_REF] Businska | Enterprise Modeling for Respecting Regulations[END_REF], but this can be an advantage in early stages of the ORS design, and for communication of the ORS with external entities. An analogy between O 2 maps and satnav maps can be made, both having options to add or remove layers of information (e.g., with/without road names or buildings). We can select only one concern, such as an IT application, and see all other related concerns of distinct layers (the IT application links with context regulations, processes, people, and other IT). We may also separately obtain one or more layers (e.g. only the IT layer for potential application integrations). We intend to continue the research with this organization, simultaneously refining the tool and improving the steps 5 to 7 of the approach. The conclusions of this cycle were: ─ The framework may be used as a basis for creating 3D models of the ORS; ─ Those models can support and improve the communication of the ORS, within the organization and with external stakeholders. The existence of a structured approach can also improve the regulatory awareness among the designers.

Conclusions

From our research findings and over 15 years of consulting experience in IS, we found that organizations have difficulties in formal mapping between regulations, processes, people, and IT. Existing approaches for managing regulations do not holistically represent the regulatory space, simultaneously addressing the cooperation with internal and external entities. Even when a business rule engine exists, its use is mostly focused in the technological aspects, and it is difficult to be used as a working tool for all the business experts and external consultants. Our work combines regulatory and IS literature. The O 2 framework provides guidance for the regulatory analysis and elicitation. During the design, distinct experts negotiate and validate the goals and rules of the ORS. The framework creates a common level of abstraction for both business and IT to align their models and improve consistency [START_REF] Branco | A case study on consistency management of business and IT process models in banking[END_REF].

There are a number of benefits with this approach. The ORS design will identify the regulatory requirements, and there is an opportunity to reduce the "burden" of this task while improving communication in practice. With the O 2 map, the organization can provide evidence for auditors, and other external entities, such as associations and customers. The O 2 framework focuses the participants in all the dimensions of an IS, namely the (1) context, (2) people, (3) process, (4) information, and (5) IT [START_REF] Curtis | A field study of the software design process for large systems[END_REF][START_REF] Laudon | Management Information Systems: Managing the Digital Firm[END_REF][START_REF] Barata | ISO2: A New Breath for the Joint Development of IS and ISO 9001 Management Systems[END_REF]. A partnership is proposed from the beginning of design, as opposed to the traditional customer-supplier relation that sometimes happens [START_REF] Branco | A case study on consistency management of business and IT process models in banking[END_REF], for instance, between IT departments (supply solutions) and other management systems experts (define goals and rules). The approach is simple to use, and technology independent.

This research has limitations. The cases represent specific regulatory contexts, mostly influenced by ISO standards. The organizational managers (ORS designers) were indicated by each organization, but other functions could be also considered. The O 2 map is a simplification of the complex system it represents, and as all regulatory models, it faces inherent uncertainties [START_REF] Holmes | Regulatory models and the environment: practice, pitfalls, and prospects[END_REF]. Finally, in spite of the positive results for organizational communication, joint modeling, and audit, we do not yet have evidences of compliance improvement, such as reducing non-conformances.

Future research can address distinct regulatory settings, for example, in the financial or healthcare sectors, with different company sizes and structures. There is a need to examine the runtime of the ORS and compliance management after the modeling steps. The ORS model could also be tailored for inter-organizational studies in the same or between distinct regulatory spaces. The developers of modeling tools may be inspired by our approach to provide an increased support at early stages of the joint design, and the improvement presentation and navigation of regulatory models. We intend to create new graphical functionalities to the support application, namely (1) the drill-down of the map objects, for instance, detailing a specific process in subprocesses or an IT solution in its modules; and (2) a presentation of the map layers as X3D models, providing interactivity. There is a need to research how the O 2 artifacts, designed in natural language, may be converted or even incorporated in technological solutions. Lastly, the integration with enterprise architecture approaches and other frameworks that are suitable for the sequent steps of detailed modeling, coding, and implementation [START_REF] Kharbili | Business process regulatory compliance management solution frameworks: A comparative evaluation[END_REF][START_REF] Ingolfo | Establishing regulatory compliance for software requirements[END_REF].

Fig. 1 .

 1 Fig. 1. The O 2 framework [27].

Fig. 2 .

 2 Fig. 2. The O 2 matrix (top), the O 2 artifacts (bottom-left), and an O 2 map (bottom-right) [27].

Fig. 3 .

 3 Fig. 3. The extended O 2 map, representing the ORS.

Fig. 4 .

 4 Fig. 4. The O 2 matrix software tool.

Fig. 5 .

 5 Fig. 5. The O 2 map evolution: conceptually linking different concerns at distinct layers.

Table 1 .

 1 Action research cases.

	Case/Sector	Standards
	1: Ceramics	ISO9001, ISO14001, OHSAS18001, EMAS, SA8000
	2: Agro-food	ISO22001, ISO/IEC17025, BRC, and IFS Food Safety
	3: Technological Institute	ISO9001, ISO/IEC17025, OHSAS18001

Table 2 .

 2 Regulatory space cooperation: the manager's perspectives.

	With
		CEO	IMS	CIO	MM	LA	CFO
	Manager
	CEO		3	3	3	5	5
	IMS	5		4	4	2	3
	CIO	5	2		2	2	4
	MM	4	3	2		2	2
	LA	5	2	2	2		4
	CFO	5	2	3	2	3

Table 3 .

 3 Regulatory influence in each function, by type of regulation.

	Type Manager	Law	Standard	Contract	Internal Procedure
	CEO	4,5	4	4	4,5
	IMS	3	5	3	5
	CIO	2,5	3	3	4
	MM	2	2	5	4
	LA	5	3	4,5	3,5
	CFO	4,5	3	4	3,5


Florian Lautenbacher

Philipp Diefenthaler

Melanie Langermeier

Mariana Mykhashchuk

Bernhard Bauer

Planning Support for Enterprise Changes

Keywords: enterprise architecture management, transformation planning, transformation modeling, application architecture

de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Changing laws and regulations, a growing number of competitors, upcoming customer channels and, hence, an adapted business strategy require that enterprises need to react flexibly. Nowadays, an IT landscape that efficiently supports the business and can easily be adapted is a key element for the success of enterprises.

Enterprise architecture management (EAM) assists to develop the IT landscape so that it efficiently supports current and future business needs. Several EAM frameworks were standardized (e.g. The Open Group Architecture Framework (TOGAF) [START_REF]The Open Group: TOGAF Version 9.1. 1 edn. TOGAF series[END_REF] or the Zachman framework [START_REF] Zachman | A framework for information systems architecture[END_REF]) and are utilized and adapted in several companies.

Enterprise architecture (EA) models describe the enterprises in an abstract way and allow for a goal-oriented information systems development. They serve as information basis for discussing and deciding about transformations of the overall enterprise [START_REF] Rouse | A theory of enterprise transformation[END_REF]. Models of the EA provide a holistic view on an enterprise by aggregating information about the business strategy, business processes, the applications and interfaces, the data exchanged between the applications as well as the underlying infrastructure [START_REF] Lankhorst | Enterprise architecture at work: Modelling, communication and analysis[END_REF]. The relation of those elements provides enterprises with a clear picture of the current business support by IT systems.

Driven by the business strategy a desired target state can be modeled for the business, the application as well as the technological perspective. In order to close the gaps between the current and the target state, transformations from the current to the target architecture are planned by enterprise architects.

Many companies face an IT landscape which has grown over years and which comprises hundreds of systems using various technologies with complex dependencies between them. Considering all these dependencies when planning the enterprise transformations is a difficult task. Especially when focusing on the business, these dependencies are often neglected. These inherent dependencies are often revealed quite late, when implementing the transformation projects and then lead to changed project plans, higher costs and delayed deadlines.

The process of building a roadmap from a current state to a target state of an enterprise considering the EA dynamics is evaluated in the research area EA planning. Spewak [START_REF] Spewak | Enterprise architecture planning: Developing a blueprint for data, applications, and technology[END_REF] defines EA planning as "the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures". The main goal of EA planning is to enhance and maintain the mutual alignment of business and IT [START_REF] Luftman | Transforming the enterprise: The alignment of business and information technology strategies[END_REF]. The different approaches in this research area are heterogeneous and cover different topics [START_REF] Aier | Complexity levels of representing dynamics in ea planning[END_REF]: from methodologies for EA planning [START_REF] Aier | Towards a systematic approach for capturing dynamic transformation in enterprise models[END_REF][START_REF] Pulkkinen | Systemic management of architectural decisions in enterprise architecture planning. four dimensions and three abstraction levels[END_REF] to modeling the transformation [START_REF] Aier | Applying design research artifacts for building design research artifacts: A process model for enterprise architecture planning[END_REF][START_REF] Buckl | An information model for landscape management -discussing temporality aspects[END_REF][START_REF] Buckl | Complementing the open group architecture framework with best practice solution building blocks[END_REF], describing possible actions for transformations [START_REF] Buckl | An information model capturing the managed evolution of application landscapes[END_REF] or focusing on key performance indicators to compare the current and the target architecture [START_REF] Nissen | Agile it-anwendungslandschaften als strategische unternehmensressource[END_REF].

The contribution of this paper focuses on the creation of a transformation path from a current to a target architecture (using planning techniques from artificial intelligence, AI) and describes a solution how the enterprise architect is supported by proposed sequences of transformations, which can be performed in the enterprises' IT landscape. These sequences consider the dependencies between existing and planned IT applications (i.e. one provides an IT service that is used by others). Our solution proposes four phases to compute the proposed sequences and supports the enterprise architect during the creation of the transformation path.

The presented solution assumes that the current IT landscape as well as the target IT landscape have already been modeled and are available for the planner. Hence, the solution focuses on how to achieve the target rather than on what the target should look like. This allows the enterprise architect to stimulate alternative thinking of how the target can be reached. In this paper we describe the planning process with focus on the application architecture only, i.e. the IT applications and IT services used to exchange data. Other architecture layers (such as business or technology architecture, compare [START_REF]The Open Group: TOGAF Version 9[END_REF][START_REF] Hasselbring | Information system integration[END_REF]) are outside the focus of this paper.

Foundations

One of the first contributors in the field of EA planning are Spewak and Hill [START_REF] Spewak | Enterprise architecture planning: Developing a blueprint for data, applications, and technology[END_REF] that introduce an EA planning model (wedding cake model), which describes how the blueprints for the target state are developed from the analysis of the current state, and how the changes are structured in an implementation and migration plan. More recent research on EA planning addresses the different levels which have to be considered in the planning process and how decisions in different architectures, i.e. business, application, data and technology, may affect the others [START_REF] Pulkkinen | Systemic management of architectural decisions in enterprise architecture planning. four dimensions and three abstraction levels[END_REF]. Aier et al. [START_REF] Aier | Complexity levels of representing dynamics in ea planning[END_REF] derive an EA planning process from the work of Spewak and Hill [START_REF] Spewak | Enterprise architecture planning: Developing a blueprint for data, applications, and technology[END_REF], Niemann [START_REF] Niemann | From enterprise architecture to IT governance: Elements of effective IT management[END_REF] and Pulkkinen [START_REF] Pulkkinen | Systemic management of architectural decisions in enterprise architecture planning. four dimensions and three abstraction levels[END_REF]. The derived process consists of the steps: (1) define vision, (2) model current architecture, (3) model alternative target architectures, (4) analyze and evaluate target alternatives, [START_REF] Spewak | Enterprise architecture planning: Developing a blueprint for data, applications, and technology[END_REF] plan transformation from current to target and, before a new planning cycle is initiated, (6) implement transformation.

The current architecture describes the status quo and the target architecture describes a desired state in the medium-dated future (approximately 3 to 5 years). A vision or ideal architecture is a blueprint of a desired architecture which will possibly never be reached, but serves as guidance for defining a target architecture.

Changes in Application Landscapes

In the context of the transformations of application landscapes the entities that are changed consist at least of the applications and the services they provide and use (c.f. [START_REF] Winter | Essential layers, artifacts, and dependencies of enterprise architecture[END_REF] and [19]). Several sources in literature consider different types of changes in application landscape transformation. All of these sources distinguish between changes that create and delete entities ( [START_REF] Keller | IT-Unternehmensarchitektur: Von der Geschäftsstrategie zur optimalen IT-Unterstützung[END_REF], p.95; [START_REF] Hanschke | Strategisches Management der IT-Landschaft: Ein praktischer Leitfaden für das Enterprise Architecture Management[END_REF], p. 172; [START_REF] Sousa | An approach for creating and managing enterprise blueprints: A case for it blueprints[END_REF]; [START_REF] Simon | Application landscape transformation and the role of enterprise architecture frameworks[END_REF], p. 11; [START_REF] Postina | Evolutionsmanagement prozess-und serviceorientierter Unternehmensarchitekturen[END_REF], p. 59). Furthermore, an update of an entity is considered as a change in several sources ( [START_REF] Sousa | An approach for creating and managing enterprise blueprints: A case for it blueprints[END_REF]; [START_REF] Simon | Application landscape transformation and the role of enterprise architecture frameworks[END_REF], p. 11; [START_REF] Postina | Evolutionsmanagement prozess-und serviceorientierter Unternehmensarchitekturen[END_REF], p. 59). Sousa et al. [START_REF] Sousa | An approach for creating and managing enterprise blueprints: A case for it blueprints[END_REF] take additionally a read dependency for changes into account. This type of dependency is used to denote that an entity which creates and deletes certain entities needs another entity which it does not actively change by itself.

According to Aier and Gleichauf [START_REF] Aier | Application of enterprise models for engineering enterprise transformation[END_REF] the models of the current and target state can be linked through a transformation model which contains information about the successor relationships of entities. A successor relationship always links exactly one element in one state with an element in another state. It is possible that one element has zero or more than one outgoing or incoming successor relationship.

Graph Transformations for Planning Purposes

Several different approaches, techniques and representations to planning problems have been developed over the last decades in the research field of artificial intelligence planning and scheduling. These approaches range from state space model based planning to task networks, where tasks for reaching a goal are decomposed and sequenced. A state space based approach is preferable, because models of the current and target architecture are used in many EA approaches and are present in many tools used in practice.

Graph transformations for AI planning purposes solve a planning problem by applying graph transformations on a model until a solution for the planning problem is found. The result of such a planning process can be a sequence of actions changing a model into another model.

However, graph transformations have the disadvantage that they provide a huge state space regarding the states, which have to be examined when all states in the graph are computed, and as a consequence influence the computation time. With graph transformations a planning problem can be solved by searching for graph patterns in the state represented by a graph and applying graph transformations to the state [START_REF] Edelkamp | Graph transformation and ai planning[END_REF]. Graph transformations have the benefit that they have a sound theoretical foundation.

By reusing the knowledge from existing contributions in the field of enterprise architecture planning and the existing techniques from AI planning we can create a solution which supports the enterprise architect in gaining an overview on alternative transformation paths.

Solution for Transformation Planning

Our solution comprises the steps analyze models and plan transformation from current to target architecture of EA planning as defined by Aier et al. [START_REF] Aier | Complexity levels of representing dynamics in ea planning[END_REF].

The planning of the transformation takes place in four steps: (1) the connection of the architectures, (2) the segmentation analysis, (3) the creation of an action repository and (4) the creation of the transformation path. As prerequisite the current and target architecture have to be determined. The current architecture consists of the applications and their used and implemented services at present. In contrast, the target architecture contains all applications and their used and implemented services at future. As a result of the process a partial plan will be created, which describes how to reach the target. Figure 1 shows an overview of the concept which was modeled and tested.

Current'and'Target'

Architecture'

successor' Abstract' Ac3ons! Current! Target! Concrete! Ac.on!x!
Step!1:!Connec.ng! the!architectures!

Step!2:!Segmenta.on! Analysis!

Step!4:!Crea.ng!the! transforma.on!path!

IF'…'' THEN'…''

Step!3:!Crea.ng!the!ac.on!repository! The first step of our solution supports the linking of the current and target architecture and thereby the definition of the transformation model. With the segmentation analysis in the second step, we narrow the scope for the following transformation path creation. Independent of those steps is the creation of the action repository, where the abstract actions that are taken into account are modeled. Creating these abstract actions is done only once and can be applied on all variations of current and target architectures that satisfy the metamodel criteria specified in an abstract action. Metamodel entities must exist for the elements of the architecture models. Such metamodel entities represent the type of the element in order to apply the changes to a model. Furthermore, the metamodel restricts the relationships and attributes of the elements.

Segment' ! Transforma3on' Path' ! • Ac.on!1! • Ac.on!2! • …!
After finishing these three phases the creation of the transformation path can be started. Thereby, different possible plans, consisting of sequences of concrete actions, are generated. Alternatively the enterprise architect can create those paths interactively through selection of the next concrete action. Based on the preferred sequence of action a project proposal can be determined. In the following sections each of those phases will be described in more detail.

Connecting the architecture

The first step of the proposed solution supports the enterprise architect in connecting the current architecture with the target architecture. To enable the creation of a transformation path the target architecture has to be semantically connected with the current architecture in the sense of successor relationships. Similar to Aier and Gleichauf [START_REF] Aier | Application of enterprise models for engineering enterprise transformation[END_REF] we use successor relationships to link current elements to the appropriate target elements. A special unchanged successor relationship indicates those links, where the element of the current architecture exists unchanged in the target architecture. To support the enterprise architect in finding the successor relationships, we analyze the similarity of the elements in the current and target architecture. The automatic derivation of successor relationships for applications based on business support maps and suggestions for successor services is described by Diefenthaler and Bauer [START_REF] Diefenthaler | Gap analysis in enterprise architecture using semantic web technologies[END_REF]. However, this approach is limited to architectures, where applications are localized in the cells of a business support map.

To support the enterprise architect in finding the successor relationships independently from a localization, we analyze the similarity of the elements in current and target architecture.

The similarity of two elements c, t is defined as the total number of such shared relationships in relation to the overall number of relationships: Sim(c) t = #sharedRelationships(c, t) / #Relationships(c). A shared relationship between an element c in current and an element t in target exists, if there is a relationship (c, r, c ) in the current architecture and a relationship (t, r, t ) in the target architecture with c' as an element of the current architecture, which has the successor t' in the target architecture; r is an arbitrary architectural relationship. The similarity measure has a range from 0 to 1, whereas 0 means that there are no shared relationships and 1 means that all relationships are shared.

Before determining the shared relationships, unchanged elements have to be identified. The enterprise architect has to confirm each mapping, because nameequality does not always conclude an unchanged successor relationship. After that, there are already some successor relationships given. Based on those, the shared relationships and similarity measures can be calculated iteratively until no more suggestions can be found.

For the final decision about the successor relationships the enterprise architect should not only rely on this measure but also take the total number of relationships and the expert knowledge into account. Moreover, he has to specify, whether the relationship is an unchanged successor or not. Further measures can be determined depending on the context and enterprise specific details.

Segmentation Analysis

The segmentation analysis addresses the problem that enterprise architectures typically have a huge scope and include a lot of elements. To narrow the scope, a segmentation analysis can be done before determining the transformation path. According to Aier and Gleichauf [START_REF] Aier | Application of enterprise models for engineering enterprise transformation[END_REF] architectural elements can be grouped to segments, if they do not have relationships to other elements outside the group. As there are typically no isolated cells in enterprise architectures we do this segmentation by using different successor relationships. They enable the identification of parts in the architecture where changes occur but also where no changes occur.

A segment is defined as a set of interrelated elements in the current architecture with their successor elements in the target architecture including all implement-and use-relationships between those elements. To ensure the independence of the different segments in an enterprise architecture, each group of changed elements must be surrounded by a set of unchanged elements. Then these groups of changed elements are independent of each other in the context of planning, although the segments overlap at unchanged elements. An example for a segmentation is shown in Figure 2. The figure shows on the left side a current architecture and on the right side a target architecture. Both consist of interrelated changed and unchanged elements. Furthermore, the successor-relationships between the current and target architecture are modeled. Using the segmentation analysis two segments can be identified in this architecture. They overlap at one unchanged element. There is also one unchanged element which is neither in segment 1 nor in segment 2.

Creating an Action Repository

Before the transformation from the current to the target architecture can be planned, an action repository with abstract actions has to be modeled. An abstract action consists of two parts. One part specifies the preconditions an action to be applicable. The other part is the effect part, which specifies the changes to an architecture if an (abstract) action is applied to it. In a technical sense the abstract action matches via a graph pattern into the concrete model of the different states. Concrete actions relate to concrete entities and relationships in an architecture and concrete changes to the state of architecture. The application of a concrete action to an architecture, may enable the application of several other concrete actions.

Logical Ordering of Abstract Actions The abstract actions are modeled in a logical order, which means that it is only possible to apply the action if the preceding actions were already applied. For example, it is not possible to change the dependencies from a service to its successor service if it has not yet been built. Furthermore, it may be necessary to build the application first to allow the creation of a new service. After the dependencies of a service have been changed to a successor it is possible to shutdown the service. If all services of an application have been shutdown it is possible to shutdown the application. The logical ordering prevents the creation of loops in the transformation path, i.e. to shutdown and create the same application several times. It may be the case that it is not necessary to enact the develop application action. For example, if a segment contains a service, which has to be developed for an application that already exists, it is not necessary to develop that application again since it already exists in the current architecture. However, in this case the logical ordering would prevent the shutdown of the predecessor services, if present, until the new service is developed.

Creating the Transformation Path

With the action repository and a segment at hand it is possible to start the creation of a transformation path. It is also possible to start the creation without segments, but we advise to utilize the segmentation, because the number of possible transformation paths for an whole IT landscape is hard to grasp for a human.

We derive all applicable concrete actions for a segment by checking which preconditions of abstract actions match in a segment. This corresponds to a breadth search of applicable actions for a segment. If a concrete action is applied to a segment it changes the state of the segment. In contrast if we apply a depth search on a segment we receive a transformation path changing the segment in a sequence of concrete actions from the current to the target architecture. If no such transformation path exists the more exhaustive breadth search can be omitted and we are informed that no transformation path was found. We apply the breadth search on a segment recursively and we get the whole state space.

With the state space it is possible to determine all possible transformation paths of a segment. By selecting concrete actions we create the transformation path, change the segment and get each time a list of concrete actions which we now can apply. When the transformation path is complete, i.e. all necessary changes have been applied, no further actions are applicable and the transformation path is saved.

The selection process for choosing concrete actions can be enhanced by providing development costs for proposed applications and services, and maintenance costs for applications and services which are to be retired.

Use case and implementation details

In the past, IT applications were often developed to address the specific business needs that a part of the organization had at that moment. However, considering the whole enterprise it is not effective to store redundant data in several IT applications as this increases the risk of outdated and inconsistent data. This is the basis for the master data management (MDM) challenge [START_REF] Loshin | Master data management[END_REF]. In our use case we show a typical (and simplified) example for the introduction of master data management in the research department (R & D) of an organization. Figure 4 shows a part of the current architecture of the organization's IT landscape. There has already been placed a development master data management (DMDM) system in the organization which provides interfaces (MasterData v1 and v2 ) to other IT applications. However, not all existing systems use the master data provided by DMDM: the long lasting DevManager provides similar data that is still used by existing systems such as the product planning tool and the quality tests planning tool. Other IT applications such as the virtual quality test result database store the master data themselves and are not connected to DMDM. For the modification of products (from one test to another) there in the different IT application shall be united and all other tools will use the data provided by DMDM. There will be only one planning tool that includes planning for the product as well as the quality tests. All quality tests (including the results) will be managed by one quality test assistance and result management tool (cf. Figure 5).

Building the transformation path for the use case

In this section we describe the transformation path created by an enterprise architect. Action prioritization is based on the principle of subject-specific importance of corresponding applications and services, the principle of redundant applications avoidance as well as the principle of using new interfaces wherever possible.

Initially, the enterprise architect has done the mapping between applications in the current and the target architecture. This mapping showed which applications and services had successor relationships. Grouping applications from current architecture by their successors in the target, the enterprise architect was able to identify three groups of applications, which had to be consolidated. One group consisted of the Product planning tool and Quality tests planning tool, both of which had the successor Product and Quality test planning tool. Physical quality test assistance tool, Physical quality test result database and Virtual quality test result database have built the second group. The third group comprised of Product class A assistance database and Product class B assistance database.

After getting an overview on forthcoming changes, the enterprise architect had to decide in which order he would perform concrete actions. Due to the high operation costs for DevManager, the enterprise architect had decided to start with the shutdown of this application. However, it was not possible to perform this action immediately since DevManager provided the service QueryDev v1 to Product planning tool and Quality tests planning tool and was still in use. It was also impossible to stop using the service by these systems before their successor-application was developed. Taking this into account, the enterprise architect decided to develop the Product and quality test planning tool together with its service PlanningData v1 at first. Next steps comprised the removal of connections between service QueryDev v1 and applications Product planning tool and Quality tests planning tool. Not until then QueryDev v1 and DevManager could be shut down. After that, once connections of Product planning tool and Quality tests planning tool to another service MasterData v2 have been removed, the enterprise architect could shut down these applications. In this way, the enterprise architect created the transformation path for the first group of applications.

For the remaining applications the enterprise architect decided to proceed with the second group, whilst taking into account that isolated solutions were not desirable in the organization and quality test result management had a high strategic importance for the R & D department. In the end, the transformation path for applications of the third group was created.

An excerpt of the list of actions can be seen below.

Implementation details

For the implementation of our solution we use model query languages and GROOVE 1 . Models of the segment are transformed via a model-to-model transformation into GROOVE models. The current version of GROOVE allows to import and export Ecore 2 conform models, which can for example be UML models.

The current and target architecture have to be modeled using a formally defined metamodel. The connection of the architecture as well as the segmentation analysis, are done by using a model query language. We modeled the abstract actions, depicted in Figure 3, with GROOVE. Abstract actions change the lifecycle phases of applications and services or change the usage dependencies between those. Besides theses abstract actions, also abstract actions for debugging purposes were modeled to allow the detection of states which are incorrect from an expert viewpoint. For example it should not be possible that an application consumes a service it also provides.

A segment serves as a starting state for GROOVE. It consists of the applications and services from the current and target architecture, the successor relationships between them, the implementation relationships between applications and services of the current and target architecture and, moreover, the usage dependencies of the current architecture. Upon this state concrete actions can be applied in GROOVE via graph pattern matching and graph transformation.

To be able to have a criterion when the transformation path is ready we define an action, which has no effect on the state. This action consists of the usage dependencies of the target architecture, all applications and services which have to be shutdown are in the corresponding lifecycle, and all applications and services which have to be built are in the lifecycle phase live. With this action and the initial state at hand it is possible for GROOVE to compute a transformation path. Furthermore, it is possible to create a transformation path in interaction between an enterprise architect and GROOVE, by selecting concrete actions and computing the resulting states.

Evaluation

The evaluation for the use case was conducted by an enterprise architect and a knowledge engineer. The knowledge engineer is the creator of the action repository, who models the actions according to certain requirements. The enterprise architect is the creator of the current and target architecture and has functional knowledge about the concrete changes.

Conducting the Evaluation The goal of the evaluation was to determine the differences between the expectations of the enterprise architect and actual 1 GRaphs for Object-Oriented VErification (GROOVE) http://groove.cs.utwente.nl/ 2 http://www.eclipse.org/modeling/emf/?project=emf information provided by GROOVE. Therefore we first checked if the desired transformation path from the enterprise architect could be reproduced using the interactive alternative of our solution. Second, we verified the functional correctness of the transformation path, if it was created by GROOVE without interaction.

For the first case the knowledge engineer explained the procedure and the tool setting to the enterprise architect. Then the enterprise architect was asked to explain the concrete changes of her transformation path. The knowledge engineer performed each action in GROOVE until the transformation path was finished.

In the second case the transformation path, created by GROOVE, was extracted to a text file and relevant parts for the enterprise architect were kept in it. This means that it contained actions like Create Application: Product and Quality test planning tool and their ordering in the transformation path. The enterprise architect used prints of the current and target architecture with their successor relationships between the applications and services to keep track of the actions applied by the proposed transformation path.

Results of the Evaluation It was possible to reproduce the transformation path of the enterprise architect in GROOVE. The knowledge engineer had to execute additional actions, because not every step of the path was exactly one step in the tool. For example, the change of a dependency is considered by the enterprise architect as one step, but in GROOVE this change was modeled as two steps (one delete and one create). Furthermore, the corresponding action for shutting down applications is modeled in a way that it shuts down all possible applications in one step. The enterprise architect considered the shutdown of the applications Product planning tool and Quality tests planning tool as two steps.

The enterprise architect confirmed the transformation path created from GROOVE as valid. However, other transformation paths were considered as more optimal from the viewpoint of the enterprise architect. Furthermore, it was necessary to explain to the enterprise architect that not every step in her path was exactly one step in GROOVE's path.

One insight of the evaluation was that it was possible to give a hint to the enterprise architect that one service was no longer in use and can be shutdown. Additional actions will be modeled that were considered as useful during the evaluation. Moreover, the enterprise architect asked for the possibility to specify priorities for the development and shutdown of applications. For example, it should be possible to prefer applications with a high strategic importance for development and to prefer applications to shutdown with high maintenance cost. Additionally, the possibility to take resource constraints, like available budget and staff, into account was uttered.

Related Work

We summarize three publications related to our solution in the following:

Postina [START_REF] Postina | Evolutionsmanagement prozess-und serviceorientierter Unternehmensarchitekturen[END_REF] presents a method to manage service and process oriented enterprise architectures. He uses a case based reasoning approach and a case repository to provide information for the evolution of the enterprise architecture. The target state can be reached from the current state through several evolutionary steps. A case is defined by the type of an evolutionary step (create, update, delete), the element and type involved, e.g. organizational unit billing, and the viewpoints attached to it. The cases help to provide views for future evolutionary steps with the same combination of element type and evolutionary step type. However, the creation of different transformation paths is not considered, which a benefit of our approach is.

Postina and Gringel [START_REF] Gringel | I-pattern for gap analysis[END_REF] present a prototypical tool for creating a target architecture by selecting gaps between an ideal and current application landscape. The target landscape is interactively designed by an enterprise architect and the tool. The term ideal landscape is tightly coupled to the Quasar Enterprise approach which considers domains, ideal interfaces, ideal components and ideal operations for interfaces. Based on the structural differences between the current and ideal landscape the tool can identify the gaps and provides an action list to close the gaps. The modeling of an ideal landscape is a prerequisite in order to create the target architecture and the resulting action list, which consists of actions to close the gaps. In contrast, our approach provides actions for sequencing changes within the transformation path and needs no ideal landscape, which makes it less approach-dependent. Furthermore, our actions are defined on an abstract level and thus allow determining the different dependencies between the necessary changes.

Sousa et al. [START_REF] Sousa | An approach for creating and managing enterprise blueprints: A case for it blueprints[END_REF] describe an approach to reconstruct enterprise architecture models from existing project information and the artifacts influenced by them. Furthermore, the Blueprint Management System (BMS) is introduced which allows to detect the temporal dependencies of projects on certain artifacts and can generate different viewpoints. Time is explicitly taken into account by providing a timeline bar in the BMS, which enables the user to browse through the different points in time. The tool is capable of providing different states as each project has a list of artifacts it creates and deletes. This implies that projects are already on the run and the information is derived afterwards. However, our solution can interactively create the transformation path including alternative paths and then allows the creation of proposals for projects, their change activities and the possible synchronization between them.

Conclusion and Future Work

In this paper we proposed a solution of how to close the gap between a current and a target architecture. We identify the successor relationships between those architectural states and determined transformation paths in terms of sequences of concrete actions. Thereby the dependencies between the architectural elements are considered. If necessary the architecture can be divided into smaller segments. For the analysis we use model query languages, for the definition of abstract actions and the creation of the transformation path we use graph transformation.

The solution is designed to support the enterprise architect in the task to find a way how to reach a defined target, starting with the current architecture. It enables the consideration of the complex dependencies between the architectural elements and thus reduces changes in project plans later on because of overlooked dependencies. The outcome of our solution, the transformation path, can be used to define the projects which will implement the changes.

The next step is to extend our solution to all architectural layers in enterprise architecture and start a broader field study. Future work will comprise a refinement analysis and actions to enable a more abstract target architecture as a starting point. Furthermore, providing support for the consideration of resource constraints and value-based weighting of the transformation steps is part of our future research. The presented solution provides a stable basis for these further extensions.

Fig. 1 .

 1 Fig. 1. The proposed solution with its four phases.

Fig. 2 .

 2 Fig. 2. Segmentation of the connected current and target architecture for narrowing the scope.

Fig. 3 .

 3 Fig. 3. The logical ordering of abstract actions

Fig. 4 .Fig. 5 .

 45 Fig. 4. Master data management: current architecture

  1. Develop application Product and Quality test planning tool 2. Develop service PlanningData v1 of application Product and Quality test planning tool 3. Remove connection between application Product planning tool and service QueryDev v1 4. Remove connection between application Quality tests planning tool and service QueryDev v1 5. Shut down service QueryDev v1 6. Shut down application DevManager 7. Remove connection between application Product planning tool and service Mas-terData v2 8. Remove connection between application Quality tests planning tool and service MasterData v2 9. Shut down application Product planning tool 10. Shut down application Quality tests planning tool