Capability-driven development (CDD) is an emerging research field aimed at aligning information technology (IT) to business evolution. From a methodological perspective a designer using CDD is faced with the challenge of reasoning about phenomena present in the business domain, capturing user requirements and developing an IT solution that reflects these phenomena and meets user expectation. Central to this process is the methodology meta-model, which is intended to define both the key concepts on which the designer has to focus and the process to be followed. The purpose of this paper is to report on an investigation on the utility of a specific meta-model in terms of these two aspects. This investigation was carried out through a use case that involved capability modelling on the same application, by different designers. Each approach was documented using design rationale techniques. The two efforts were then analysed and observations about the capability driven design activities were defined. The output of this work has provided feedback to enhancing the capability meta-model and consequently the capability driven design activities in a number of important ways.
The concept of compliance capability denotes that the execution of certain business processes complies with a set of regulations. Compliance is historically viewed as a burden, although, as compliance has become a capability pursued by their external environment, there are indications that businesses have started to see the regulations as an opportunity to improve their business processes and operations. In a recent study [1] of a large sample of European companies, compliance was reported as being one of the main initiatives, and equal to Big Data and ITIL, as being a target for implementation during 2014. In the same survey, compliance in the United Kingdom is regarded as a top priority alongside those of mobility and Cloud Computing. There are indications [2] that up to 80% of companies expect to reap business benefits from improving their compliance regimens.
It is reported that the cost or impact of regulation is not determined solely by the regulation itself [3]. It is mediated by the capability of business owners to manage regulation. The capability to manage regulation does not appear to be homogeneous across all businesses. This could be because of differences in a business owner’s awareness of regulation [4], different attitudes towards regulation [5] or a business owner’s capacity to discover, interpret and adapt to regulation [6]. Further research has revealed that business owners may have some discretion as to adapt to or comply with regulation depending on business resources and market contexts [7, 8] and they also have variation in motivation to comply and adapt [9].
In order to create and maintain a capability in compliance, companies should have a solid methodology against which their business processes will ensure that enterprise actors conform to a set of standards and that their information system will assist in process enactment. In this regard methods and tools that fall in the domain of Business Informatics have a key role to play in procedurally and technologically supporting the effort of compliance management. The work reported in this paper is motivated by a desire to define a meta-model that could act as both the kernel of a compliance development methodology and as the means to developing a repository for supporting such a methodology. The meta-model should facilitate business analysts to extract compliance rules from compliance documents and enables compliance enforcement in all the phases of business process lifecycle in a consistent fashion independently from the modelling approach adopted to describe business processes. The designing of the compliance metamodel was carried out in a systematic process whereby the reasoning for the various design decisions were captured on the basis of the reasoning cycle model [10], a process which itself was supported by the Compendium tool [11, 12].
The paper presents in section 2 an overview of existing related work. Section 3 introduces the procedure of designing the compliance meta-model. Section 4 presents an example of applying the meta-model in healthcare regulations domain, while conclusions and future work reside in section 5. 2
To deal with the problem of regulatory compliance, there is a need for formal models of law that can be formally analysed through various forms of reasoning to help requirements engineers find compliant solutions. Modelling approaches intended for law, have been studied for decades generally grounded on expressive, often modal, logics [13-18]. Other approaches, grounded in Natural Language Processing and Information Retrieval, support different forms of analysis such as determining case similarity and relevance [19]. Because of the lack of semantic and conceptual analysis of compliance requirements in those approaches, it is proposed to use conceptual models of law that sit somewhere between logical and natural language models with respect to complexity.
There are several approaches presenting conceptual meta-models or ontologies for compliance management. With the increase in attention paid to the role of compliance within business processes, several works have been produced in the area of compliance management, attempting to address the current needs of organizations. Notably, the COSO framework [12] offered the internalization of abstract compliance requirements into a set of organization-specific concrete norms. COSO [12] is a useful approach because it helped the organizations to identify in which objectives from a regulation have to comply with and then specify formal compliance rules in order to use them from process verification. Other initiatives, such as COBIT [20] and OCEG’s GRC [21] provide a governance model with control objectives for particular domains to help organizations to refine concrete controls. However, similarly these models do not provide explicit guidance addressing how compliance concepts and their interrelationships are defined and integrated.
On the specification of compliance requirements [22] proposes an approach for modelling control objectives within business process structures. Their work is one of the few works that actually introduce a basic model to capture compliance requirements.
Similarly, a number of approaches and technologies have been developed, proposing a separate business process modelling and compliance requirements modelling phases, which is followed by a model checking based approach for compliance verification [23, 24].
The COMPAS meta-model instead [25-27], did not aim at over-engineering the compliance problem and instead focused on compliance awareness, that is, on the design for, monitoring, and reporting on compliance. In the COMPAS meta-model the domain of business process is well analysed and interrelated to the compliance domain. In the COMPAS meta-model there is a lack in the descriptive characteristics of compliance source.
The majority of the literature relates compliance to business processes which is an interesting aspect of approaching because a change in regulations and laws affects directly part or the whole of a business process. To date the compliance checking domain was considered as an extension to specific business process modelling approaches. This paper introduces an approach of analysing thoroughly just the compliance domain in order to facilitate the procedure of extracting rules from legal documents and the necessary components that are needed for the description of the notion of compliance, independent of any practiced business processes. 3
Regulatory compliance can take on different definitions according to the industry in which you are applying the policies. Since compliance means incorporating standards that conform to specific requirements, regulatory compliance is the regulations a company must follow to meet specific requirements[19].
When you apply regulatory compliance to IT, the regulations apply to two different aspects of company operations which include the internal requirements for IT and compliance standards that are set forth by external entities. Both types of regulatory compliance affect IT company operations and can potentially restrict what a company can and cannot do[28].
The intention of the designed compliance meta-model was to be able to facilitate all phases of compliance management, starting from regulation document analysis, moving to the identification of important features and ultimately the construction of compliance rules that may be automatically enforced to the BP lifecycle irrespective of the particular application domain.
In order to justify robustly the decisions made during the designing of the compliance meta-model, the design rational meta-process was used [10] supported by the Compendium tool [11, 12]. The reasoning cycle consists of four phases: Goal: Declaration of a problem. Hypothesis: Problem analysis. Justification: Evaluation of the hypotheses by setting arguments for and against them.
Design Action: Make design decisions according to the prevailing hypotheses. The top level of the decision tree constructed to design the compliance meta-model is depicted in Fig. 1. The ultimate design goal, e.g. the design of the meta-model, is depicted at the top of the figure. Other goals leading to the achievement of the ultimate design goal are also included in the decision tree, signifying also the order of decisions required to achieve the goal. For example, to design the meta-model, the following decisions were considered: (a) deciding which of the entities already proposed in other meta-models, might be adopted; (b) identify compliance source specialization; (c) decide on a way to segregate legal documents; and (d) examine BP components as compliance rule targets.
According to the meta-process adopted, each goal depicted in the decision tree is investigated by evaluating specific hypotheses (pros and cons are identified) and a corresponding decision is reached (see Fig. 1). The reasoning for reaching decisions on the identification of which existing entities are necessary to be included in the compliance meta-model is presented in Fig. 2. The question mark node depicts the goal, while yellow idea nodes depict hypotheses examined by the authors. Pros and cons aspects of adopting a hypothesis are linked to it, indicated by green (positive) and red (negative) nodes, while neutral arguments are also represented indicated by light blue nodes. The decision made for each hypothesis is also linked to it, represented by a handshake node.
As depicted in Fig. 2 (upper part), one of the hypotheses explored was whether or not to focus on components describing legal documents. Existing meta-models on compliance provide an entity named compliance source for this purpose, not further analysed or specialized. Should we adopt this decision as well? Positive, negative and neutral arguments on this are identified in the diagram that captures the reasoning process. When evaluating this hypothesis, we decided to adopt the notion of compliance source entity [26] to describe legal documents, but to also provide for specializations of it, since a) our meta-model does not only focus on compliance enforcement and b) most researchers are agreeing about the different types of compliance documents (see corresponding handshake node). Furthermore, we decided to focus on compliance document segregation to help business analysts to easily identify compliance rules. Based on this decision, two corresponding sub-goals were identified: a) to identify specializations of compliance source entity and b) to identify a way of segregating legal documents.
Identifying specializations of the compliance source entity is very important because, since in the efforts of describing and analysing the notion of compliance is important to refer to the specific types of a legal document. In order to categorize the types of a legal document it is necessary to recur to the literature for further information.
It occurs from the literature that the source of a legal document is either an enforcement of law by the State or a Union (e.g. European Union) or a conclusion to an agreement between two independent parties (e.g. two organizations). The conclusion of this hypothesis is the specialization of the compliance source entity to internal and external and then to define the components of these two based on the declared types of legal documents.
The aforementioned design rational and the corresponding part of the designed metamodel are presented in Fig. 3. This part of the meta-model targets at depicting compliance as a concept, thus it is referred to as the teleology part. For the identification of how to segregate a legal document, the proposed hypothesis is to study a set of legal documents in order to understand their structures. By working on this hypothesis, the arising arguments are that every one of these legal documents has a structure of chapters, sections and subsections semantically divided. Also, in every section or subsection there is a declared set of rules. Based on these remarks, we suggest the introduction of an entity named compliance essential to describe compliance documents components, in an effort to help the business analyst to identify compliance rules. Thus, compliance essential and source entities are mandatory and are thus related through a corresponding aggregation relationship. Though, what is the contribution of the essential entity in the meta-model? Is it easy to identify which part of a compliance document consist an essential? As we reflected on this, it was realized that in order to describe thoroughly the notion of compliance rule, it was necessary to define compliance essential entity in a more specific way, having in mind the way business analysts think when trying to extract compliance rules out of compliance sources. At first, the business analyst might think about identifying the goal of each fragment of compliance documents, to categorize and classify rules corresponding to it. Furthermore, the type of concerns mentioned in the document fragment is considered (e.g. rules about security, privacy, segregation of duties etc.). Another consideration is to identify in which domain the rules will apply. This kind of description completes the definition of compliance essential. In the compliance meta-model the compliance essential has a tertiary relationship with both application domain and compliance type entities. The aforementioned design rationale and the corresponding part of the designed meta-model are presented in Fig. 4. This part of the meta-model provides a way to decompose the notion of compliance sources to simpler entities helping business analysts to extract compliance rules, thus it is referred to as the methodology part. Next issue to be resolved is the representation of compliance rule entity, already incorporated in all existing approaches. Whether there is a need to extend it was the focus of our investigation. The proposed hypothesis is to study the structure of rules in legal documents. It was decided to categorize the notion of rule to complex and simple rules. Consequently the compliance rule entity is either complex rule composed by simple ones or just a simple rule. To describe rules we decided to add two attributes in compliance rule entity. The first attribute is the text description of the rule, containing the corresponding text extracted by the compliance essential and the second one is a logical expression attribute, descripting the rule in a form that may be executable. To describe rules as logical expression we decided to adopt MTL format presented in [26], which enable the description of rules based on a set of patterns. Since simple rules are extracted from compliance essentials, they are described in a similar fashion. Thus, each of them is related to a single compliance type and application domain. The aforementioned design rational and the corresponding part of the designed meta-model are presented in Fig. 5. The last decision to be explored related to the linkage of compliance rules with business process. Existing approaches have already studied this issue in the context of a specific process modelling approach. In order to be independent of specific BP models, the basic components of BPs are identified as the target of compliance rules. These components remain the same independently of the modelling approach adopted to represent BPs (e.g. active-driven, data-driven, etc. From this point of view, we understand which components of a process may be affected by each rule. A rule by its definition is a description of constraints involving roles, data, activities and events. Thereafter it is essential to link the entity of compliance rule with a rule target consisting of the entities of agent, activity, data and event. The aforementioned design rational and the corresponding part of the designed meta-model are presented in Fig. 6. By defining the entities of compliance rule and rule target we approached a way of extracting the rules and we defined the business components that a rule can affect. Thus this part of the meta-model, along with rule description, consist the applicability part.
The whole meta-model is presented in Fig. 7. As we already discussed the metamodel was divided in three sections, highlighting its scope.
Considering the scope of the presented meta-model, it instantiated using examples of different regulation applied in diverse domains, to test in a preliminary level its applicability and potential. The meta-model was tested using examples from the shipping, healthcare and internal IT support domains using various standards and regulations[2931].
Through the instantiations, it was observed that all of the designed entities were used and had served and represented their predefined functionality. The proposed metamodel, though generic, provided the necessary entities to fully describe examples from diverse domains. It was also noticed that the conceptual sections of the meta-model were helpful in the description of each instance separately. Moreover, each entity was perceived in the same way in every instantiation, indicating the clarity of its definition and typology. Moreover the methodology section of the meta-model has proven very helpful in extrapolating rules from compliance documents. Through the identification of application domain and compliance type of concern, the compliance officer is able to extrapolate and categorize rules from every legal document. An observation related to compliance enforcement was that the MTL expressions had a strong relation and pairing to the rule target entity. This pairing is translating to a solid and powerful connection between the content of a rule and their affecting components. The perception of what it is or not a complex rule and what are its components was straight forward. The same opinion is prevailing as far as the interpretation of rule target entity is concerned.
The example presented in the following refers to the healthcare regulation published by the state of Massachusetts[29] . The section selected for discussion in the paper, help us illustrate all the main features of the meta-model, constituting the reason for its selection. It is Section 12L of the regulation, which refers to the constraints of an abortion, concerning an existence of pregnancy for less than 24 weeks.
The description of Healthcare regulation as an instantiation of compliance source and Section 12L as a compliance essential is depicted in Fig. 8. The text of Section 12L is included as a property of the compliance essential instance. The corresponding goal, e.g. to declare the constraints of an action, is also identified. The concern type (e.g. authori zation) and application domain (e.g. Healthcare) were easily identified. The fact that the whole section targeted the same concern and had a unique goal led us to treat is as a discrete compliance essential.
Based on this compliance essential, the business analyst may deduct a single complex rule, as described in. It may be analysed into 2 discrete single rules. Fig. 9 included both the text description of rules and corresponding MTL expressions. MTL expressions represent an executable form of the rule that may be enforced automatically. Keywords used to describe expressions are analytically presented in [20] . As an example, we discuss the MTL expression corresponding to simple rules SR1a. The LeadsTo keyword indicates order constraints between activities and events. In this case, the “Performance_of_Abortion” activity is performed, only when the event “Pregnancy ExistsMax 24weeks” is true.
The activity is performedBy the “Physician” agent. The ExistsMax keyword indicates timing constraint. This compliance essential instance is having several constraints declared, which are described as a complex rule as shown in Fig. 9.
The activity affected in this case is the performance of abortion by the physician which is triggered by two separate but interdependent events: • •
Existence of pregnancy for less than 24 weeks
Judgment of abortion as necessary
The corresponding part of the meta-model instantiation depicting single rules and their targets in terms of business process description is presented in Fig. 1010.
Compliance is a business capability, gaining momentum, as it is recognized as a driving force towards business efficiency. Most existing approaches treat compliance as a set of constraints enforced to business process and focus on modelling them as parts or extensions of business process models. In this paper, we presented a conceptual meta-model targeting compliance management, which serves both compliance rule extraction from compliance documents and enables compliance enforcement independently from the modelling approach adopted to describe business processes. Since design decisions resulting in the construction of the meta-model were captured and documented using the design rationale approach, it is easier to test them and perform justified modification in meta-model when needed.
In order to enhance the usability of the meta-model we intent to extent our research into the following two areas as part of our future work: a) automate the extraction of rules from compliance essentials and b) perform an ontological analysis.
It would be of great importance to study further the approaches dealing with the automated or semi-automated extraction of rules via textual recognition and analysis. The attainment of matching semantic and textual recognition and extraction of rules from legal documents will improve the procedure of compliance enforcement in general. In particular as far as the proposed meta-model is concerned, it will enhance the notion of compliance rule and its relation to rule target entity. It will confer to the meta-model the dynamic of representing rules both semantically and lexically with certainty that the content of legal document has properly been attributed.
The ontological analysis requires a mapping of the ontological concepts to its corresponding meta-model concepts. The purpose of this is to identify the degree of completeness of the notation. The ontology of the compliance meta-model can be written in various formats and be used for automated reasoning in the compliance domain and the enforcement of compliance rules. It will also be useful as a common format that will allow the exchange of knowledge across applications/ platforms targeting compliance and business process modelling and business process execution. The next step after building up the ontology, it will be to test it with different case studies from the medical and shipping industry domain, in order to confirm and further determine and define the usefulness of our meta-model. 6 11. 12. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29.