# Business Rules Management Solutions: Added Value by Effective Means of Business Interoperability

Martijn Zoet, Johan Versendaal

► To cite this version:

Martijn Zoet, Johan Versendaal. Business Rules Management Solutions: Added Value by Effective Means of Business Interoperability. 5th International Working Conference on Enterprise Interoperability (IWEI), Mar 2013, Enschede, Netherlands. pp.145-157, 10.1007/978-3-642-36796-0_13 hal-01474207

HAL Id: hal-01474207

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

Submitted on 22 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>

Distributed under a Creative Commons Attribution 4.0 International License
**Business Rules Management Solutions:**
**Added Value by Effective Means of Business**
**Interoperability**

Martijn Zoet¹, Johan Versendaal¹

¹HU University of Applied Sciences, Utrecht, the Netherlands,
{martijn.zoet, johan.versendaal}@hu.nl

**Abstract.** Interoperability research, to date, primarily focuses on data, processes and technology and not explicitly on business rules. The core problem of interoperability from an organisation's perspective is the added value generated from collaborating with other parties. The added value from a data, process and technology perspective has been widely researched. Therefore it is the aim of this study to provide insights into the added value for organisations to collaborate when executing business rules management solutions. Explanations of possibilities, opportunities and challenges can help to increase the understanding of business rules interoperability value creation. Presented results provide a grounded basis from which empirical and practical investigation can be further explored.

**Keywords:** Business Rules Management, Interoperability, BRM, Business Interoperability

# 1 Introduction

Many business services nowadays heavily rely on business rules to express business entities, coordination, constraints and decisions [1-3]. A business rule is [4] “a statement that defines or constrains some aspect of the business intending to assert business structure or to control the behaviour of the business.” The field of business rules management knows various research streams. Examples are business rules authoring, business rules engines, application in expert systems, business rules architecture, business rules ontology’s, data mining and artificial intelligence [3]. However, the research topics within each stream are technology driven [5, 6]. Yet, it is not the technology and software applications that are of interest to an organisation; it is the value proposition they deliver. Nevertheless research focusing on improving business rules management practices and its value proposition is nascent [5, 7].

An important design factor to increase an organisation's value proposition in general is cooperation [8]. To achieve effective cooperation organisations have to resolve interoperability issues. In this study business interoperability is defined as [9] "the organisational and operational ability of an enterprise to cooperate with its business partners and to efficiently establish, conduct and develop IT-supported
business relationships with the objective to create value.” An example from the airline industry can demonstrate business interoperability of business rules expressing decisions. A global airline alliance has 10 members. Each member has different business rules to decide whether customers are allowed into their business lounge. Airline X states that a customer must have acquired the silver status while airline Y states that the customer must have acquired the gold status. When a customer of airline Y arrives at a lounge managed by airline X carrying the silver status he will not be allowed access. Airline Y will not pay Airline X to take care of the customer. Two events change the business rules with regards to lounge access. First an airline changes its business rules or secondly an additional airline is allowed into the alliance. If the business rules are hard coded or stored locally all systems at all airports have to be altered. When each member offers a decision service containing their specific business rules only the specific decision service has to be altered improving the business interoperability of the entire alliance.

However, current interoperability research primarily focuses on data, services, processes, business and interaction and not explicitly on business rules [10]. For each previously mentioned concept three categories of interoperability research can be distinguished: conceptual, technological and organisational [11]. Conceptual research focuses on barriers related to syntactic and semantics', technological research focuses on information system technology while organisational research focuses on responsibility, organisational structure and business value. All research streams have the same purpose: to develop knowledge and solutions to remove barriers and enable effective business interoperability [11]. Since interoperability research related to business rules is nascent research needs to focus on the inquiry of the phenomenon itself [12].

This article extends understanding of business rules interoperability by addressing the underlying value proposition for organisations. Based on previous research, we will consider a business rules management solution (hence BRMS) as consisting of eleven different service systems. With these premises, the specific research question addressed is: "What is the relation between forms of business interoperability and the organisation's business rules management service systems in the perspective of value propositions?" Answering this question will help organizations better understand the value proposition behind collaborating with organizations in order to deliver business rules.

The paper is organised as follows. First we describe the individual business services of a BRMS. Then we present the various forms of interoperability and stages of service design. After which we present our analysis of BRMS interoperability. We conclude with a discussion of these findings, focusing on the implications for practice and for the study of business rules based services.

## 2 Literature

A *business service* is defined as [9]: "a coherent piece of functionality that offers added value to the environment, independent of the way this functionality is realized."
To deliver a business service a value-coproduction of resources, skills, knowledge and competences has to be configured [9]. This configuration is called a *service system*. A BRMS is a co-production of various resources, skills, knowledge and competences [7, 13, 14]: i.e. a co-production of service systems. Nelson [7] proposed a very rudimentary service system for business rules containing three elements a service provider, a service client and a service target. A more detailed classification has been proposed Zoet and Versendaal [14]. This classification scheme, existing of eleven service systems, classifies the processes, guidance elements, actors, input and output per service system. A detailed explanation of the BRMS can be found in [14]. However to ground our method and research a summary is provided.

Deployed business rules are monitored for proper execution. The 1) monitoring service system collects information from executed business rules and generates alerts when specific events occur. This information in turn can be used to improve existing or design new rule models. Execution of business rules is guided by a separate service system: 2) the execution service system. It transforms a platform specific rule model into the value proposition it must deliver. A platform specific rule model can be source code, handbooks or procedures. The execution in turn can be automated or performed by humans. To execute a platform specific rule model it needs to be created. A platform specific rule model is created from a non-platform specific rule model by the 3) deployment service system. Before deploying business rule models they have to be checked for two error types 1) semantic / syntax errors and errors in its intended behaviour. The first type of errors are removed from the business model by the 4) verification service system; the latter by the 5) validation service system. The business rule model itself is created within the 6) design service system. In addition an 7) improvement system exists. The improvement system contains among others functionality to execute impact analysis. To design business rules models data sources need to be mined; the 8) mining service system contains, processes, techniques and tools to extract information from various data sources, human or automated. Before mining can commence in some cases explicit data sources need to 9) cleansed. The cleansing service system removes all additional information intervening with proper mining or design activities. Each previous mentioned service systems provide output to two management service systems: 10) the version service system and 11) the audit service system. Changes made to the data source, platform specific rule models, non-platform specific rule models and all other input and output are registered by the version service. All data collected about realising changes to specific input, output and other service system elements are registered by the audit service system. Examples of registered elements are: execution dates, rule model use, rule model editing, verification and validation. All service systems described in this paragraph need to be designed, developed and executed. Service design is the process of requirements analysis and service discovery. After requirements are analysed the service system needs to be configured. For this interaction, roles, functions, processes, knowledge and products need to be defined. After the service system is configured the service itself needs to be executed.

From literature four levels of collaboration can be recognized: 1) no collaboration, 2) bilateral collaboration, 3) multilateral collaboration and 4) extended collaboration
[15]. Two organisations within the same industry or value chain working together is defined as a bilateral collaboration. Multilateral collaborations have the same characteristics as bilateral collaborations with the slight difference that more than two parties are involved. Extended collaboration describes many-to-many and ‘n-tier’ relationships between organisations. Two examples are consultative bodies and network orchestrators. We assume that the type of collaboration (X) implies different design, development and execution of the BRMS (Y). Fig. 1 schematically illustrates these dependencies.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Schematic Overview researched relations between Concepts</figcaption></figure>

Nelson [7] classifies inter departmental collaboration for a specific BRMS along five dimensions organisation scope, ownership, structure, development responsibility and implementation responsibility. We adopt three dimensions in our analysis 1) ownership, 2) development responsibility and 3) implementation responsibility. However, to fit inter organisational collaboration they must be adapted. Ownership in our model is divided into two dimensions ownership of the input and output of a service system. Development responsibility is defined as the organisation that executes the service system process and implementation responsibility is defined as the organisation that implements the output of the service system. Organisation scope in our research is one of the variables of conceptual model namely: collaboration.
# 3 BRMS Analysis

Data gathering consisted of three phases. First the effect of the collaboration types on each business rules management service system has been evaluated by means of a workshop. Participants to the workshop were six business rules experts. During the second phase 12 projects have been surveyed to identify potential elements to which third parties could supply added value. During the last phase data sources such as press and analyst reports have been evaluated to indentify collaboration possibilities. The results are discussed in the remainder of this section. Per service system indentified additional variables and the characteristics of the dimensions are discussed.

## 3.1 Cleansing Service System and Mining Service System Interoperability

Explicit and tacit data sources are input for the business rules mining service system, cleansing service system, and design service system. Cleansing and mining are discussed in this section; the design service system in the next. The business interoperability question with regards to data sources is: can data from multiple organisations add additional value compared to data from a single organisation? Multiple organisations create and execute very similar or identical rule models. Examples of such rule models are medical treatment rules within the healthcare industry [16] and fraud detection rules used by banks and insurers [17]. Improvement of such rule sets is based on execution data of a single organisation. By means of collaboration larger and more accurate data sources can be created. Overall characteristics of the interoperability design issues for the cleansing and mining system are depicted in Table 1 and Table 2. Both tables show an additional variable influencing the development responsibility: privacy.

<table><caption>**Table 1.** Characteristics Dimensions Interoperability in relation to the Mining Service System</caption><thead><tr><th></th><th>Bilateral</th><th>Multilateral</th><th>Extended</th></tr></thead><tbody><tr><td>Ownership Input</td><td>Providing Org.</td><td>Providing Org.</td><td>Providing Org.</td></tr><tr><td>Ownership Output</td><td>Providing Org. /<br>Receiving Org.</td><td>Providing Org. /<br>Receiving Org.</td><td>Consortium</td></tr><tr><td>Development<br>Responsibility</td><td>Privacy:<br>Receiving Org.<br>Non-Privacy:<br>Receiving or<br>Providing Org.</td><td>Privacy:<br>Receiving Org.<br>Non-Privacy:<br>Receiving or<br>Providing Org.</td><td>Privacy:<br>Receiving Org.<br>Non-Privacy:<br>Receiving or<br>Providing Org.</td></tr><tr><td>Implementation<br>Responsibility</td><td>Receiving Org.</td><td>Receiving Org.</td><td>Receiving Org.</td></tr></tbody></table>

Privacy influences the question which organisation is responsible for cleansing? If the data source contains sensitive information cleansing should occur at the providing organisation in the case of bilateral or multilateral collaboration. Cleansing in this case can also mean sanitising or anonymizing data [17]. Extended collaboration implies the same question. However, when data is collected and integrated by an
independent consultative body this question may be easier to solve from a political viewpoint [18]. After the data source is created it can be used to mine rules. When an extended collaboration is realized the consultative body can mine the data sources after which the proposed business rules are shared with all partners e.g. the healthcare industry [16]. Other forms of collaboration have two choices 1) each party mines the data source itself or they appoint a partner to do so thus factually creating an extended collaboration.

<table><caption>**Table 2.** Characteristics Dimensions Interoperability in relation to the Cleansing Service System</caption><thead><tr><th></th><th>Bilateral</th><th>Multilateral</th><th>Extended</th></tr></thead><tbody><tr><td>Ownership Input</td><td>Providing Org.</td><td>Providing Org.</td><td>Providing Org.</td></tr><tr><td>Ownership Output</td><td>Providing Org. /<br>Receiving Org.</td><td>Providing Org. /<br>Receiving Org.</td><td>Consortium</td></tr><tr><td>Development</td><td>Privacy:<br>Receiving Org.</td><td>Privacy:<br>Receiving Org.</td><td>Privacy:<br>Receiving Org.</td></tr><tr><td>Responsibility</td><td>Non-Privacy:<br>Receiving or<br>Providing Org.</td><td>Non-Privacy:<br>Receiving or<br>Providing Org.</td><td>Non-Privacy:<br>Receiving or<br>Providing Org.</td></tr><tr><td>Implementation<br>Responsibility</td><td>Receiving Org.</td><td>Receiving Org.</td><td>Receiving Org.</td></tr></tbody></table>

## 3.2 Design Service System Interoperability

The design of a rule model is based on a specific data source or on proposed business rules model by the mining service system. An additional variable has been identified influencing the design service system: type of partners, see Table 3. A partner can be either a rule chain partner or a competitive/alliance partner. Competitive partners are defined as organizational entities from the same industry realizing an identical value proposition. A rule chain partner is an organizational entity that either formulates data sources or business rules that must be implemented by the organisation or an organizational entity that should implement business rules or data sources defined by the organisation. Interoperability between competitive / alliance partners deal with the same questions as the data source interoperability. Either organisations design rule model together or do so by providing input to a consultative body. Examples are organizations that together formulate business rules for risk management [3].

Interoperability between rule chain partners adds an extra dimension to designing the rule model. An example from the public sector will demonstrate this. The ministry of finance formulates tax laws that are analysed by the tax and customers administration to formulate business rules models. These business rules model are deployed into software and forms which are then sent to the citizens. In addition to the tax and customers administration multiple commercial and non-commercial organisations also formulate business rules based on the same tax laws. The same applies to other laws like for example the Sarbanes-Oxley Act (SOX) or the Fair and Accurate Credit Transaction Act (FACTA). All commercial organisations governed by specific laws are building rule models based on the text provided by the United
States Government. Expending on the question at the beginning of this paragraph: who should translate the tax laws, SOX and FACTA to business rules models? The government or the individual commercial and non-commercial organisations governed by the rules? To answers this question first the difference between internal business rules and external business rules has to be explained.

<table><caption>**Table 3.** Characteristics Dimensions Interoperability in relation to the Design Service System</caption><thead><tr><th></th><th>Bilateral</th><th>Multilateral</th><th>Extended</th></tr></thead><tbody><tr><td>Ownership Input</td><td>Rule-Chain:<br>1<sup>st</sup> order party<br>Non Rule-Chain:<br>Providing Org.</td><td>Rule-Chain:<br>1<sup>st</sup> order party<br>Non Rule-Chain:<br>Providing Org.</td><td>Rule-Chain:<br>1<sup>st</sup> order party<br>Non Rule-Chain:<br>Consortium</td></tr><tr><td>Ownership Output</td><td>Rule-Chain:<br>1<sup>st</sup> order party<br>Non Rule-Chain:<br>Providing Org./<br>Receiving Org.</td><td>Rule-Chain:<br>1<sup>st</sup> order party<br>Non Rule-Chain:<br>Individual Org./<br>Receiving Org.</td><td>Rule-Chain:<br>1<sup>st</sup> order party<br>Non Rule-Chain:<br>Consortium</td></tr><tr><td>Development<br>Responsibility</td><td>Rule-Chain:<br>1<sup>st</sup> order party<br>Non Rule-Chain:<br>Receiving Org.</td><td>Rule-Chain:<br>1<sup>st</sup> order party<br>Non Rule-Chain:<br>Receiving Org.</td><td>Rule-Chain:<br>1<sup>st</sup> order party<br>Non Rule-Chain:<br>Consortium</td></tr><tr><td>Implementation<br>Responsibility</td><td>Rule-Chain:<br>Receiving Org.<br>Non Rule-Chain:<br>Receiving Org.</td><td>Rule-Chain:<br>Receiving Org.<br>Non Rule-Chain:<br>Receiving Org.</td><td>Rule-Chain:<br>Receiving Org.<br>Non Rule-Chain:<br>Receiving Org.</td></tr></tbody></table>

Two main sources of business rules can be distinguished, namely internal business rules sources and external business rules sources [3]. This adheres to the principle within risk management where a distinction exists between operational risk and compliance [19]. External business rules are specified by external parties through the creation of regulations stating which rules an organization needs to comply to. Internal business rules are specified by the organization itself; they decide which rules they want to enforce [11]. With external business rules organizations have to prove, based on externally imposed criteria, that they have established a sufficient system to control the business rules. For internal business rules there are no externally applied criteria or need to prove sufficient control; in this case organizations can implement their own criteria and create a system for measuring this. Expanding on the difference in enforceability indicates a mismatch in the power/knowledge nexus [20]. In practice organisation will translate laws and regulations to business rules in one of two ways: or they transform the laws themselves or they will hire a vendor, system integrator or consultancy firm to translate for them. In all previous mentioned cases the organisation that performs the translation is not the organisation that enforces the regulation. The number of parties between the enforcer and/or creator of the law and the actual implementation by means of business rule models we define as *n-order compliant*, see Fig. 2. If government agency X states law Z and organisation Y hires a consultancy firm to translate and implement the law by means of business rules they are 3rd order compliant. If they translate and implement the law directly they are 2nd order compliant. Only one organisation has the power (/knowledge) to provide 1st order compliant.
order compliancy, the organisation that defines the regulation, government agency X. They can achieve this by translating the law into a business rule model and distribute this model to the organisations. The same situation can be recognized within individual organisations. One department specifies strategy or internal policies. A second department translates the strategy to operational business rules. In turn the operational business rules are distributed to the information technology department achieving 2^nd^ or 3^rd^ order compliancy.

<figure><img src="image_3.png" /><figcaption>Fig. 3. Schematic Overview N-Order Compliancy</figcaption></figure>

With respect to organisational collaboration in a rule chain the preferable solutions would be that 1st order compliancy is achieved. Thus that the regulatory body who defines the legislation also creates and distributes the business rule model. However, currently only one example of this is known to the authors the Australian Taxation Office [21]. In all other cases it is recommended to keep the n-order compliancy as low as possible.

## 3.3 Validation Service System Interoperability

Validation is the service system that explores errors in the intended behaviour of business rule models by means of test cases containing real life data. Likewise to design service system the partner type also influences validation, see Table 4. First order compliancy can still be achieved within the validation service system when the enforceable party is not responsible for the business rule model design however they need to validate the designed model and declare it compliant. The respondents and authors have no knowledge about a public body officially validating external rule models. Examples can be found within commercial rule chains. Authorised insurance brokers review, accept, administer, collect premiums and execute claim settlement for insurance agencies. They define rule models to support the previous mentioned tasks. Before deploying the actual rule models insurance organisations apply their test set to test if product business rules are properly deployed. If so, they consent on deploying the service to the live environment. In these cases an extended collaboration is
established with the authorised insurance broker as consultative body. Other examples can be found in the healthcare industry where various consultative bodies have test cases for diagnoses rules sets. Bilateral or multilateral collaborations between two organisations can also apply validation in the same manner. Another possibility is sharing test cases between collaboration partners instead of 'outsourcing' the validation process.

<table><caption>**Table 4.** Characteristics Dimensions Interoperability in relation to the Validation Service System</caption><thead><tr><th></th><th>Bilateral</th><th>Multilateral</th><th>Extended</th></tr></thead><tbody><tr><td>Ownership Input</td><td>Providing Org.</td><td>Providing Org.</td><td>Providing Org.</td></tr><tr><td>Ownership Output</td><td>Providing Org.</td><td>Providing Org.</td><td>Providing Org.</td></tr><tr><td>Development<br>Responsibility</td><td>Rule-Chain:<br>1<sup>st</sup> order party<br>Non Rule-Chain:<br>Receiving Org.</td><td>Rule-Chain:<br>1<sup>st</sup> order party<br>Non Rule-Chain:<br>Receiving Org.</td><td>Rule-Chain:<br>1<sup>st</sup> order party<br>Non Rule-Chain:<br>Consortium</td></tr><tr><td>Implementation<br>Responsibility</td><td>Rule-Chain:<br>Providing Org.<br>Non Rule-Chain:<br>Providing Org.</td><td>Rule-Chain:<br>Providing Org.<br>Non Rule-Chain:<br>Providing Org.</td><td>Rule-Chain:<br>Providing Org.<br>Non Rule-Chain:<br>Providing Org.</td></tr></tbody></table>

### 3.4 Deployment, Execution and Monitoring Service System Interoperability

Within three projects information system deployment and maintenance to another organisational are outsourced to a third party, e.g. system integrator. Non-platform specific rule models are transformed to platform-specific rule models by the third party. The implementation and development responsibility in all collaboration forms lies with the receiving organisation (system integrator). Ownership of the input and output in most cases lies by the providing organisation.

<table><caption>**Table 5.** Characteristics Dimensions Interoperability in relation to the Deployment Service System</caption><thead><tr><th></th><th>Bilateral</th><th>Multilateral</th><th>Extended</th></tr></thead><tbody><tr><td>Ownership Input</td><td>Providing Org.</td><td>Providing Org.</td><td>Providing Org.</td></tr><tr><td>Ownership Output</td><td>Providing Org.</td><td>Providing Org.</td><td>Consortium</td></tr><tr><td>Development<br>Responsibility</td><td>Receiving Org.</td><td>Receiving Org.</td><td>Receiving Org.</td></tr><tr><td>Implementation<br>Responsibility</td><td>Receiving Org.</td><td>Receiving Org.</td><td>Receiving Org.</td></tr></tbody></table>

Execution service interoperability occurs when one or more organisation(s) offer(s) a value proposition realized by means of a platform specific rule model to one or more organisation(s). The airline alliance example described in the introduction section is an example of this type of collaboration, which can be classified as business rules as a service. Another example can be found in the healthcare sector where specific
hospital offer decisions service to multiple of its pears. No additional variables impacting the characteristics have been found, see Table. 6.

<table><caption>**Table 6.** Characteristics Dimensions Interoperability in relation to the Execution Service System</caption><thead><tr><th></th><th>Bilateral</th><th>Multilateral</th><th>Extended</th></tr></thead><tbody><tr><td>Ownership Input</td><td>Providing Org.</td><td>Providing Org.</td><td>Providing Org.</td></tr><tr><td>Ownership Output</td><td>Receiving Org.</td><td>Receiving Org.</td><td>Receiving Org.</td></tr><tr><td>Development</td><td>Providing Org.</td><td>Providing Org.</td><td>Providing Org.</td></tr><tr><td>Responsibility</td><td></td><td></td><td></td></tr><tr><td>Implementation</td><td>Receiving Org.</td><td>Receiving Org.</td><td>Receiving Org.</td></tr><tr><td>Responsibility</td><td></td><td></td><td></td></tr></tbody></table>

Monitoring service system collaboration mainly will occur in rule-value chains since most organisations will not provide monitoring services to competitors. A possible exception might be extended collaboration with a consultative body. However, the output of the monitoring service system: performance data can be input for the cleansing service system, mining service system or design service system collaboration. An example of rule-value chains within the insurance industry is that an inspector applies a rule model to determine if a vehicle is either repairable or total loss. Based on the result of the rule model the insurance companies start different processes. Although not a collaboration between two organizations; another pattern instantiation is identified in the business-to-consumer industry: telemedical care for patients [22]. The patient has physical equipment at home that contains the platform specific rule model. The execution of this model is monitored at the hospital or medical centre. All types of collaboration have the same dimensions characteristics, see Table 7.

<table><caption>**Table 7.** Characteristics Dimensions Interoperability in relation to the Monitoring Service System</caption><thead><tr><th></th><th>Bilateral</th><th>Multilateral</th><th>Extended</th></tr></thead><tbody><tr><td>Ownership Input</td><td>Providing Org.</td><td>Providing Org.</td><td>Providing Org.</td></tr><tr><td>Ownership Output</td><td>Receiving Org./<br>Providing Org.</td><td>Receiving Org./<br>Providing Org.</td><td>Consortium</td></tr><tr><td>Development</td><td>Receiving Org./<br>Providing Org.</td><td>Receiving Org./<br>Providing Org.</td><td>Receiving Org.</td></tr><tr><td>Responsibility</td><td></td><td></td><td>/ Providing Org.</td></tr><tr><td>Implementation</td><td>Receiving Org./<br>Providing Org.</td><td>Receiving Org./<br>Providing Org.</td><td>Receiving Org. /<br>Providing Org.</td></tr><tr><td>Responsibility</td><td></td><td></td><td></td></tr></tbody></table>

Regarding the audit service system and version service system no advantages can be distinguished regarding bilateral and multilateral collaborations. In extended collaboration consultative bodies and individual organisations need to determine how to manage local and network versions of the various business rules concepts. However, one can argue this can be considered overhead instead of added value.
## 4 Discussion

The analysis of our initial model revealed two additional variables 1) type of partners and 2) privacy. The latter indicates that sanitising and/or anonymizing should be taken into account when sharing input data among organisations. Research addressing sanitising and/or anonymizing data already has been conducted in various fields. Solutions can be adopted and adapted from these fields.

Our research revealed rule value chains and more specific the n-order compliance concept. N-order compliance raises questions in terms of organisational, social, cultural, political and economical effects and consequences [23]. Research indicates that 3^rd^ and 4^th^ order compliancy is a common grade of compliance. Are both levels the optimal form of interoperability from a political or economic viewpoint? From a political viewpoint most countries distinguish between policy makers (ministries) and a central government responsible for translating and executing policies. What effects would 1^st^ order compliancy have on the political relationship? From an economic viewpoint an interesting question is: which savings can be achieved when realising 1^st^ order compliance? Although limited, research on economic assessment of business interoperability shows improvements in throughput, cycle time and reduction of transaction cost [23]. How do these concepts relate to the various forms of n-order compliance?

Analysing the four dimensions for underlying trends reveals that both development and implementation responsibility vary per individual service system per organisation. The ownership of the input for a specific service system in all cases, except for the design service system, is at the providing organisation. This comes as no surprise. For organisations to derive value from the collaborated service systems the information needs to be contextualized for their specific information they own. This can only be achieved by contextualizing the input. The ownership of the output of the individual service systems follows the conceptual lifecycle of the four high-level business rules subjects 1) data, 2) non-platform specific rule model, 3) platform specific rule model and 4) value proposition [14]. Neglecting the design service system from a rule-chain perspective the input ownership changes at each of the four lifecycle points. When the output is data, the ownership is shared. The providing party has ownership of the non-platform specific and platform-specific rule models, while the value proposition ownership is at the receiving party. The reason the rule chain perspective deviates from the pattern is because 1^st^ order compliance is considered to be preferable. To realize 1^st^ order compliance the ownership of the output lies at the organisation that has the knowledge and power to do so.

## 5 Conclusion

Business rules are a key denominator for an organizations success. Likewise the ability to collaborate is important. Therefore we set out to answer the research
question: "What is the relation between forms of business interoperability and the
organisation's business rules management service systems in the perspective of value
proposition?" In order to answer this question we first identified the different types
of interorganisational collaboration. After which the collaboration types have been
combined with the eleven service systems of a BRMS. Explanatory research further
operationalized the relation: we used data collected from a workshop and secondary
data sources such as press reports, analyst reports and business rules management
project documentation.

The aim of this study was to provide insights into different forms of interoperability that are related to an organisation’s BRMS. The results have limitations. Insights are derived from a limited set of data and the existing knowledge base in the area of business rules management. Building on the results from this explorative research further research should be performed. Main subject of future work will be the further validation of the identified interoperability possibilities in order to assess the practical relevance besides establishing its theoretical foundation. Another direction for future work is creating business, technical and process building blocks to realize interoperability.

References

[1] Shao, J., Pound, C.J.: Extracting business rules from information systems. BT Technology Journal. 179-186 (1999)

[2] Bajec, M., Krisper, M.: A methodology and tool support for managing business rules in organisations. Information Systems. 30, 423-443 (2005)

[3] Zoet, M., Welke, R., Versendaal, J., Ravesteyn, P., Aligning risk management and compliance considerations with business process development, in: T. Di Noia, Buccafarri (Eds.) EC-Web 2009, Springer-Verlag, 2009.

[4] Morgan, T.: Business rules and information systems: aligning IT with business goals. Addison-Wesley, London (2002).

[5] Arnott, D., Pervan, G.: A critical analysis of decision support systems research. Journal of Information Technology. 20, 67-87 (2005)

[6] Rosca, D., Wild, C.: Towards a flexible deployment of business rules. Expert Systems with Applications. 23, 385-394 (2002)

[7] Nelson, M.L., Peterson, J., Rariden, R.L., Sen, R.: Transitioning to a business rule management service model: Case studies from the property and casualty insurance industry. Information & Management. 47, 30-41 (2010)

[8] Hammer, M., Champy, J.: Reengineering the Corporation: A Manifesto for Business Revolution. HarperBusiness, New York (2003).

[9] Lankhorst, M., Janssen, W., Proper, H., Steen, M., Introducing Agile Service Development, in: M. Lankhorst (Ed.) Agile Service Development, Springer-Verlag, Berlin, 2012.

[10] Molina, A., Panetto, H., Chen, D., Whitman, L., Chapurlat, V., Vernadat, F.: Enterprise Integration and Networking: Challenges and Trends. Studies in Informatics and Control. Informatics and Control Publications. 16, 353-368 (2007)
[11] Chen, D., Vallespir, B., Daclin, N., An Approach for Enterprise Interoperability Measurement., in: S. Ebersold, A. Front, P. Lopistéguy, S. Nurcan, X. Franch, E. Hunt, R. Coletta (Eds.) International Workshop on Model Driven Information Systems Engineering: Enterprise, User and System Models, CEUR Workshop Proceedings, Montpellier, France, 2008, pp. 1-12.

[12] Edmondson, A., McManus, S.: Methodological Fit in Management Field Research. Academy of Management Review. 32, 1155-1179 (2007)

[13] Nelson, M.L., Rariden, R.L., Sen, R., A Lifecycle Approach towards Business Rules Management, in: 41st Hawaii International Conference on System Sciences, Hawaii, 2008, pp. 113-123.

[14] Zoet, M., Versendaal, J.: Business Rules Based Perspective on Services: A Mixed Method Analysis. Manuscript submitted for publication. (2012)

[15] Plomp, M., Batenburg, R.: Measuring Chain Digitisation Maturity: An assessment of Dutch Retail Branches. Supply Chain Management. 15, 227-237 (2010)

[16] Ferlie, E., McGivern, G., FitzGerald, L.: A new mode of organizing in healthcare? Governmentality and managed networks in cancers service in England. Social Science & Medicine. 74, 340-347 (2012)

[17] Chiu, C., Tsai, C., A Web Services-Based Collaborative Scheme for Credit Card Fraud Detection, in: Proceedings of the 2004 IEEE International Conference on e-Technology, e-Commerce and e-Service, IEEE, 2004, pp. 177-181.

[18] Monsieur, G., De Rore, L., Snoeck, M., Lemahieu, W., Handling Atomic Business Services, in: 15th CONFERENCE ON PATTERN LANGUAGES OF PROGRAMS, Plop Conference, 2008, pp. 1-12.

[19] Zoet, M., Versendaal, J., Ravesteyn, P., Welke, R., Alignment of Business Process Management and Business Rules, in: European Conference on Information Systems (ECIS), ECIS 2011 Proceedings, 2011.

[20] Foucault, M.: Security, territoty, population - lectures at the college of france 1977 - 87. Picador, New York (2007).

[21] Office, A.T., Legal Database Australian Taxation Office, in, http://law.ato.gov.au/atolaw/index.htm, 2012.

[22] Fifer, S., Everett, W., Adams, M., Vincequere, J., Critical Care, Critical Choices: The Case for Tele-ICUs in Intensive Care, in: N. King, G. Coffmann, J. Handt, D. Melissinos (Eds.), New England Healthcare Institute, 2010.

[23] Legner, C., Lebreton, B.: Business Interoperability Research: Present Achievements and Upcoming Challenges. Electronic Markets. 17, 176-186 (2007)