# Modeling the Organizational Regulatory Space: A Joint Design Approach

João Barata, Paulo Da Cunha

► To cite this version:

João Barata, Paulo Da Cunha. Modeling the Organizational Regulatory Space: A Joint Design Approach. 6th The Practice of Entrprise Modeling (PoEM), Nov 2013, Riga, Latvia. pp.206-220, 10.1007/978-3-642-41641-5_15 . hal-01474747

HAL Id: hal-01474747

https://inria.hal.science/hal-01474747

Submitted on 23 Feb 2017

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion 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.

<figure><img src="image_1.png" /></figure>
# Modeling the Organizational Regulatory Space: A Joint Design Approach

João Barata<fnref n="1" />,<fnref n="2" />, Paulo Rupino da Cunha<fnref n="2" />

**Abstract.** 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₂ 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.

**Key words:** Information system design; regulation; compliance; organizational regulatory space; O2 framework.

## 1 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 [1, 2]. 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 [2]. The regulatory space becomes unique for each organization.

<footnote n="1">¹ CTCV, Rua Coronel Veiga Simão, 3025-307 Coimbra, Portugal.</footnote>

<footnote n="2">² CISUC, Department of Informatics Engineering, University of Coimbra, Pólo II, 3030-290 Coimbra, Portugal</footnote>

<footnote>{barata, rupino}@dei.uc.pt</footnote>
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 [3, 4]. Business process management presents solutions that can guide the design of IS and organizational rules [5]. Nevertheless, we must take into consideration that not all the regulations are “process-friendly” (e.g. several financial regulations), and, even when they are, problems can still exist by adopting a process approach in regulatory contexts [6]. The list of problems increases if we consider the distinct vocabulary among the ORS experts [7]; 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 [8, 9] 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 [10], 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 [8, 9], 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 (IMS – integrating 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.

# 2 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 [1]. 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 [1], the “space” metaphor is in the scope of national regulation. According to [11], 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 [1] 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, [12] 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 [11]. 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.

## 2.2 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 [13]. Compliance is a well-known research subject in IS. The literature addresses topics such as the compliance of business processes and services [14–16], requirements engineering and conceptual modeling [17, 18], auditing IS compliance [19, 20], and the alignment between law and IT compliance [21]. However, the majority of studies focus on the perspective of modeling and checking compliance [10], 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 [22]. To design an IT artifact, we must be concerned with the context, the designers, users and beneficiaries of the IT, processes, and the information [13,
23]. These IS components may be represented as layers, that interact and influence each other and their environment [24, 25]. The identification of the layers can integrate multiple viewpoints, according to each system stakeholder and particular field of knowledge [26]. 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 [27]. As stated by [2, 20, 21], both the IS and regulatory compliance should be achieved by a holistic design.

## 3 Method

We used action research to guide our investigation, simultaneously aiming to improve scientific knowledge and assist a practical problem [28]. 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* [29]. To evaluate our research, we have relied on the principles proposed by [30]. Table 1 lists the action research cases and the main standards that influence their regulatory space.

<table><caption>**Table 1.** Action research cases.</caption><thead><tr><td>Case/Sector</td><td>Standards</td></tr></thead><tbody><tr><td>1: Ceramics</td><td>ISO9001, ISO14001, OHSAS18001, EMAS, SA8000</td></tr><tr><td>2: Agro-food</td><td>ISO22001, ISO/IEC17025, BRC, and IFS Food Safety</td></tr><tr><td>3: Technological Institute</td><td>ISO9001, ISO/IEC17025, OHSAS18001</td></tr></tbody></table>

An initial *diagnosis* was conducted simultaneously in all these organizations, to understand the communication and artifacts used [31], 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 [32]. 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.

## 4 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₂ framework [27]. 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.

## 4.1 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.

<table><caption>**Table 2.** Regulatory space cooperation: the manager's perspectives.</caption><thead><tr><th>With<br>Manager</th><th>CEO</th><th>IMS</th><th>CIO</th><th>MM</th><th>LA</th><th>CFO</th></tr></thead><tbody><tr><th>CEO</th><td></td><td>3</td><td>3</td><td>3</td><td>5</td><td>5</td></tr><tr><th>IMS</th><td>5</td><td></td><td>4</td><td>4</td><td>2</td><td>3</td></tr><tr><th>CIO</th><td>5</td><td>2</td><td></td><td>2</td><td>2</td><td>4</td></tr><tr><th>MM</th><td>4</td><td>3</td><td>2</td><td></td><td>2</td><td>2</td></tr><tr><th>LA</th><td>5</td><td>2</td><td>2</td><td>2</td><td></td><td>4</td></tr><tr><th>CFO</th><td>5</td><td>2</td><td>3</td><td>2</td><td>3</td><td></td></tr></tbody></table>
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.

<table><caption>**Table 3.** Regulatory influence in each function, by type of regulation.</caption><thead><tr><th>Type<br>Manager</th><th>Law</th><th>Standard</th><th>Contract</th><th>Internal Procedure</th></tr></thead><tbody><tr><th>CEO</th><td>4,5</td><td>4</td><td>4</td><td>4,5</td></tr><tr><th>IMS</th><td>3</td><td>5</td><td>3</td><td>5</td></tr><tr><th>CIO</th><td>2,5</td><td>3</td><td>3</td><td>4</td></tr><tr><th>MM</th><td>2</td><td>2</td><td>5</td><td>4</td></tr><tr><th>LA</th><td>5</td><td>3</td><td>4,5</td><td>3,5</td></tr><tr><th>CFO</th><td>4,5</td><td>3</td><td>4</td><td>3,5</td></tr></tbody></table>

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” [11].

We found that the ORS is not designed by one person; it is a result of a social constructed negotiation [1]. 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.
## 4.2 Action Planning: The O₂ Framework

The O₂ framework was initially proposed by [27], for the joint design of IS and ISO 9001 management systems. The *action planning* phase of our research uses and extends the O₂ framework, presented in figure 1, and briefly described in this section.

<figure><img src="image_2.png" /><figcaption>Fig. 1. The O₂ framework [27].</figcaption></figure>

The O₂ 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 [6]. 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 [26]. The use of the O₂ framework bridges distinct paradigms of interrelations, such as the organization and the environment (“outside-in” and “inside-out” information flows), the processes and the structure (under the context layer), and the inner and outer worlds [33]. However, the O₂ 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₂ matrix; the O₂ artifact; and the O₂ map. The artifacts and an example of their implementation are offered in figure 2.
<figure><img src="image_3.png" /><figcaption>Fig. 2. The O₂ matrix (top), the O₂ artifacts (bottom-left), and an O₂ map (bottom-right) [27].</figcaption></figure>

An O₂ matrix is designed for each organizational process. The example of figure 2 is for D&D – design and development process. The designers fill the matrix cells with the IS requirements for that process. Then, we extract the O₂ artifacts, that are IT artifacts [23], as illustrated in figure 2. The steps to identify the O₂ artifacts and create an O₂ map are [27]:

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 “outside-in”, “within”, and “inside-out” perspective (matrix columns);

2. Group the requirements by colors (black represents a shared requirement), each color representing an O₂ 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₂ artifacts are designed;

4. Connect all the O₂ artifacts with the processes (*breathing system*): the O₂ map.

The O₂ framework was not initially developed for designing an ORS, so we have extended the steps of the design. After creating all the O₂ 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₂ 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₂ artifact, create a list of the applicable regulations and update the O₂ map, as illustrated in figure 3.

<figure><img src="image_4.png" /><figcaption>Fig. 3. The extended O₂ map, representing the ORS.</figcaption></figure>

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₂ 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₂ 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₂ 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.

## 4.3 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 [22], 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₂ framework.

First, the design team created the O₂ 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 (“outside-in”), 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₂ map to the customer. Interestingly, the O₂ map became the audit program. The customer decided to ask for each O₂ 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₂ map to understand the correspondence with practice. The main conclusions were:

- The O₂ map is a possible representation of the ORS;

- The O₂ matrixes, artifacts, and map were easy to understand by internal workers, and external auditors/customers;

- The ORS designed by the O₂ 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.

4.4 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₂ 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₂ 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₂ 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.

4.5 The Third Action Research Cycle

This cycle addressing ORS modeling is a sequent cycle of the research we present in
[27]. 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₂ 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.
<figure><img src="image_5.png" /><figcaption>Fig. 4. The O₂ matrix software tool.</figcaption></figure>

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₂ 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₂ framework components of context, people, processes, and IT, are connected directly (e.g. processes and IT) or indirectly (e.g. people and IT through processes). The ORS map evolved to a layered presentation, illustrated in the figure 5.

<figure><img src="image_6.png" /><figcaption>Fig. 5. The O₂ map evolution: conceptually linking different concerns at distinct layers.</figcaption></figure>

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 [34], 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₂ 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.

# 5 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₂ 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 [35].

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₂ map, the organization can provide evidence for auditors, and other external entities, such as associations and customers. The O₂ framework focuses the participants in all the dimensions of an IS, namely the (1) context, (2) people, (3) process, (4) information, and (5) IT [3, 13, 27]. A partnership is proposed from the beginning of design, as opposed to the traditional customer-supplier relation that sometimes happens [35], 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₂ map is a simplification of the complex system it represents, and as all regulatory models, it faces inherent uncertainties [36]. 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 sub-processes 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₂ 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 [10, 17].

# 6 References

1. Hancher, L., Moran, M.: Organizing regulatory space. In: Hancher, L. and Moran, M. (eds.) Capitalism, Culture and Regulation. p. 299. Clarendon Press (1989).

2. Parker, C.: Reinventing Regulation within the Corporation: Compliance-Oriented Regulatory Innovation. Administration & Society. 32, 529–565 (2000).

3. Curtis, B., Krasner, H., Iscoe, N.: A field study of the software design process for large systems. Communications of the ACM. 31, 1268–1287 (1988).

4. Baxter, G., Sommerville, I.: Socio-technical systems: From design methods to systems engineering. Interacting with Computers. 23, 4–17 (2011).

5. Zairi, M.: Business process management: a boundaryless approach to modern competitiveness. Business Process Management Journal. 3, 64–80 (1997).

6. Iden, J.: Investigating process management in firms with quality systems: a multi-case study. Business Process Management Journal. 18, 104–121 (2012).

7. Abdullah, N.S., Sadiq, S., Indulska, M.: A Compliance Management Ontology: Developing Shared Understanding through Models. Proc. CAiSE (2012).

8. Abdullah, N.S., Sadiq, S., Indulska, M.: Information systems research: Aligning to industry challenges in management of regulatory compliance. Proc. PACIS (2010).

9. Abdullah, N.S., Sadiq, S., Indulska, M.: Emerging Challenges in Information Systems Research for Regulatory Compliance Management. Proc. CAiSE (2010).

10. Kharbili, M.: Business process regulatory compliance management solution frameworks: A comparative evaluation. Proc. APCCM (2012).

11. Shearing, C.: A Constitutive Conception of Regulation. In: Grabosky, P. and Braithwaite, J. (eds.) Business Regulation and Australia’s Future. pp. 67–79. A. Inst. Criminology (1993).

12. Jørgensen, T.H., Remmen, A., Mellado, M.D.: Integrated management systems – three different levels of integration. Journal of Cleaner Production. 14, 713–722 (2006).

13. Laudon, J., Laudon, K.: Management Information Systems: Managing the Digital Firm (10th Edition). Prentice Hall (2007).

14. Araujo, B., Schmitz, E., Correa, A., Alencar, A.: A method for validating the compliance of business processes to business rules. Proc. ACM Symposium on Applied Computing (2010).
15.Sadiq, S., Governatori, G.: Managing Regulatory Compliance in Business Processes. In: Vom Brocke, J. and Rosemann, M. (eds.) Handbook of Business Process Management 2. pp. 157–173. Springer (2010).

16.Tran, H., Zdun, U., Holmes, T., Oberortner, E., Mulo, E., Dustdar, S.: Compliance in service-oriented architectures: A model-driven and view-based approach. Information and Software Technology. 54, 531–552 (2012).

17.Ingolfo, S., Siena, A., Mylopoulos, J.: Establishing regulatory compliance for software requirements. Proc. Conceptual Modeling–ER (2011).

18.Sepideh Ghanavati, Amyot, D., Peyton, L., Siena, A., Perini, A., Susi, A.: Integrating business strategies with requirement models of legal compliance. International Journal of Electronic Business. 8, 260–280 (2010).

19.Sangkyun, K.: Auditing methodology on legal compliance of enterprise information systems. International Journal of Technology Management. 54, 270–287 (2011).

20.Julisch, K., Suter, C., Woitalla, T., Zimmermann, O.: Compliance by design – Bridging the chasm between auditors and IT architects. Computers & Security. 30, 410–426 (2011).

21.Bonazzi, R., Hussami, L., Pigneur, Y.: Compliance management is becoming a major issue in IS design. In: D’Atri, A. and Saccà, D. (eds.) Information Systems: People, Organizations, Institutions, and Technologies. pp. 391–398. Springer (2010).

22.Handel, M.J., Poltrock, S.: Working around official applications. Proc. CSCW (2011).

23.Zhang, P., Scialdone, M., Ku, M.-C.: IT Artifacts and The State of IS Research. Proc. ICIS (2011).

24.Avison, D., Wood-Harper, A.T., Vidgen, R.T., Wood, J.R.G.: A further exploration into information systems development: the evolution of Multiview2. Information Technology People. 11, 124–139 (1998).

25.Kautz, K., Madsen, S., Nørbjerg, J.: Persistent problems and practices in information systems development. Information Systems Journal. 17, 217–239 (2007).

26.Sommerville, I., Sawyer, P.: Viewpoints: principles, problems and a practical approach to requirements engineering. Annals of Software Engineering. 3, 101–130 (1997).

27.Barata, J., Cunha, P.R.: ISO2: A New Breath for the Joint Development of IS and ISO 9001 Management Systems. Proc. ISD (2013).

28.Hult, M., Lennung, S.-Å.: Towards a definition of action research: a note and bibliography. Journal of Management Studies. 17, 241–250 (1980).

29.Susman, G.I., Evered, R.D.: An Assessment of the Scientific Merits of Action Research. Administrative Science Quarterly. 23, 582–603 (1978).

30.Davison, R., Martinsons, M.G., Kock, N.: Principles of canonical action research. Information Systems Journal. 14, 65–86 (2004).

31.Perry, M., Sanderson, D.: Coordinating joint design work: the role of communication and artefacts. Design Studies. 19, 273–288 (1998).

32.Myers, M.D., Newman, M.: The qualitative interview in IS research: Examining the craft. Information and Organization. 17, 2–26 (2007).

33.Van Fenema, P., Pentland, B., Kumar, K.: Paradigm Shifts in Coordination Theory Introduction. Academy of Management Annual Meeting (2004).

34.Businska, L., Kirikova, M., Penicina, L., Buksa, I., Rudzajs, P.: Enterprise Modeling for Respecting Regulations. Proc. PoEM (2012).

35.Branco, M.C., Xiong, Y., Czarnecki, K., Küster, J., Völzer, H.: A case study on consistency management of business and IT process models in banking. Software & Systems Modeling. (in press) (2013).

36.Holmes, K.J., Graham, J.A., McKone, T., Whipple, C.: Regulatory models and the environment: practice, pitfalls, and prospects. Risk analysis. 29, 159–70 (2009).