Keywords

1 Introduction

One of the challenges in the execution of business applications is the short term adaption to changing business conditions and the handling of exceptions to cover unforeseen situations. The complexity of formalizing and automating business use cases with variants of process designs makes them difficult to manage and maintain and call for complex integration efforts of different IT systems.

Adaptive Case Management (ACM) provides flexibility to knowledge-based processes where the task flow is not strictly defined and the execution of cases depends on the analysis of the data for each case and on the decisions taken by the business users (knowledge workers) according to their expertise in the business domain and the assessment of the current situation. ACM bases the business case execution on behavioral rules constraining the business user actions instead of predefining tasks in a flow [24]. Existing ACM proposals use the analysis of compliance rules during business case execution [22]. However, care has to be taken that these approaches do not require the interaction between business analysts and IT developers to formalize, manage and implement business application definitions through data, actions and rules. Therefore, the supporting systems usually depend on IT experts, such as database modelling, workflow and process definition systems, rule engines and content management systems that cannot be easily adapted by business users to business changes. Further, such implementations are not transparent to the business users as hiding the definitions in the IT layer of such applications.

In order to overcome such limitations we propose a novel approach by modelling cases in ACM (i) with business architecture methodology as described by the Open Group [17] in combination (ii) with a business domain-specific ontology which we introduced earlier [21] to describe the complete business case with terms and relations as known by business users from their daily work and (iii) the definition of business rules with natural business vocabulary as proposed by Ross [19]. The definitions look at value streams (VSs), a business architecture entity, which are composed from atomic business goals (value stream stages, VSSs) that provide some benefit or product to the customer served by the company. The accomplishment of each goal of a VS is achieved by the execution of actions. And the evaluation of behavioral business rules guide the business users to complete actions in compliance with the regulatory framework for a specific business domain. The actions and rules are formalized using the same underlying business ontology. This formalization together with the action implementation and the evaluation of rules enable the instant enactment of the VSs providing an agile business application environment, as business entities can be directly maintained by business users. The resulting ACM application focuses on business goals over a rigid process flow or other aspects such as IT considerations and guarantees compliance during case execution by guiding the business user with transparently formulated behavioral business rules using business domain-specific terminology. These rules are defined by business domain analysts and avoid any technical notations or other IT dependencies.

This methodology is implemented by the ACM platform Papyrus Converse [18]. The combination of (i) providing the complete information for the current business case with (ii) business rules supported by (iii) our earlier proposed User Trained Agent (UTA) which uses the experience gained from the previous executions, leads to an effective knowledge sharing between all users working on the same system [11]. They receive suggestions of “best next actions” stemming from similar situations which the UTA has learned earlier to complete their goals.

In order to proof the potential of this approach, we apply it to scenarios from the construction industry which lacks a standard for the definition of building processes because of the heterogeneity of this domain involving different parties from different trades and the challenges coming from the unique characteristics of each building. Furthermore, the processes are even susceptible to changes in each building phase (design, implementation, operation) which can be addressed by applying ACM for such applications.

The rest of the paper is organized as follows. The challenges that arise with existing ACM solutions are described in Sect. 2 using scenarios from the construction industry. A discussion about existing approaches in ACM together with the business architecture context are presented in Sect. 3. Our proposal to address these challenges with value streams is described in Sect. 4 and it is applied to the project management of the building construction industry in Sect. 5. Finally, some conclusions about our proposal together with future work are discussed in Sect. 6.

2 Challenges in Adaptive Case Management

In the ACM paradigm [16, 20], the flow of performed activities for each business case depends more on the case information and the business experience and knowledge of users than on conducting strict workflows. This is the case in multiple scenarios such as outsourcing of maintenance services or the management of building construction projects, where many heterogeneous parties are involved with their own procedures, resources, etc. The effort to model these cases with a stable process model is expensive as these models need to include multiple decision points which are difficult to maintain at the pace of daily business changes and can therefore easily become obsolete.

Previous approaches to automate ACM are based on the definition of business rules to analyze the compliance of business tasks with business requirements and support the decision making for each case [12, 21, 24]. However, supporting the user by integrating domain knowledge has not yet been sufficiently considered, which is an obstacle for business user’ acceptance. A more general approach is the Semantics of Business Vocabulary and Business Rules (SBVR) standard. It is an adopted standard of the Object Management Group (OMG) which enables the use of domain knowledge for the definition of rules. While this standard enables the definition of a vast amount of different rules, the automated verification of them, especially in a highly flexible context, remains a challenge [6]. It is important that the enactment of the ontology and business rules must not be hindered because their management requires the support of IT experts following an iterative standard software development lifecycle (design, develop, test, release). A business domain can have hundreds of compliance rules and the dependency from IT makes them expensive to maintain. Furthermore, the case implementation shall enable a direct view of the business domain and not a reflection of the underlying IT system. That is, when the IT model requires changes because of performance or scalability, the business process implementation can be impacted. Therefore, it is important to describe the actions executed by the business users with the language used in their daily business to ensure that there is a direct alignment between business description and its enactment.

In addition to that, the accomplishment of business rules should be observed during the whole case [19] and to make the business constraints transparent to business workers, it is important to describe which actions depend on which conditions by means of behavioral business rules which identify how the case should behave. The behavioral business rules also support the definition of business goals (e.g. KPIs) with quantitative and qualitative targets which is out of the scope of this work.

Therefore, in this work we propose applying a novel methodology for ACM to address these research challenges:

  • R1: Minimize the technical gap between the business knowledge and its formalization and enactment in an ACM system by applying business architecture principles based on the definition of an ontology which enables the definition of action and rules with business concepts.

  • R2: Trace the relationship between the action execution and business rules to define behavioral business rules.

3 ACM Enactment and Business Architecture Concepts

There are a number of papers dealing with the support of ACM and compliance rules. In previous work [22,23,24], Tran et al. propose driving the execution of cases based on the evaluation of business rules instead of a predefined business model. Gómez-López et al. [9] monitor the violation of business rules in process aware information systems to support proactive decision taking in next actions. Additionally, in the transport and logistics domain, the monitoring of the compliance of each transport case with agreed KPIs is evaluated to guide the action flow during the case execution [10, 14]. Such approaches usually address only the support of action sequences based on information models but do not propose how to close the gap between the business language and the cases enactment which requires support from IT teams.

In computational domains, Brandic et al. in [5, 8] propose mapping from business KPIs to low level metrics in order to support the monitoring and evaluation of these KPIs. However, these works are specific to computational services. And based on natural language process description, López et al. [13], propose a tool to formalize the natural language concepts as tasks with associated user roles and maintain their relationship through the process lifecycle. However, this proposal does not address the automation aspects, which still require IT efforts.

Therefore, as far as we know, there is no work related to support the complete lifecycle of business cases (i.e. modelling, execution, refining, etc.) avoiding the semantic gap between business and IT domains. In this work, we address this gap by taking advantage of existing business architecture concepts in order to align business concepts with the underlying formal model and its execution. Specifically, this work is based on the approach of VSs proposed by Open Group [17], derived from the proposal by Martin [15].

In business architecture, one of the main challenges is to match business capabilities with business goals in order to ensure business success [3, 4]. In this regard, the identification of strengths and weaknesses supports the strategies for company resource investments and recruitment. Different approaches to implement straight forward business cases have been proposed. In the ACORD framework [1], a proposal to define UML Classes for business concepts and tasks is described, which has been used to define reference system models in domains such as Insurance [2]. Although this framework can be used to implement the data model, it does not support the business actions or process automation, as the business rules have still to be defined and implemented by a separate system.

Open Group [17] proposes to focus on the provided value to customers or stakeholders, namely value streams, as a mechanism to organize the actions to take. We use the involved terminology for our proposal. In this proposal, the main concepts are defined in the following way and as depicted by Fig. 1.

Fig. 1.
figure 1

Modelling business architecture

Definition 1 (Value Streams).

Value streams (VSs) are defined as an end-to-end value for the customer, i.e. each single case of the value stream provides (or expects to provide) a benefit when finished. For example, in a building project, a value stream is the creation of a new architecture model which is ready to be delivered to external parties such as the plumbing company.

Definition 2 (Value Stream Stages).

A value stream is composed of goals or value stream stages (VSSs). These goals can be in principle independent but it is possible that behavioral rules establish dependencies between goals. For example, different checks can be evaluated without a specific order over a building model but the calculation of thermal properties only makes sense after confirming that there are no gaps in the building envelope. Therefore, a dependency between the goal “creating an envelope without gaps” and the goal “creating a thermal model of the building” exists.

Definition 3 (Rules).

The expected behavior to accomplish goals is expressed by means of behavioral business rules which constrain actions to be executed in the course of the work. These rules are evaluated to enable an action (e.g.: if a building model has not been considered finished, no checks can be performed) or to complete an action (e.g. if the building envelope has gaps, thermal calculations can be performed but these calculations should not be used for any purpose).

The accomplishment of goals is achieved with the execution of business tasks. We model these tasks with actions, which are either of atomic nature, being finished in the same moment, or actions starting a task and, when completed, finishing the task with an end action, to support decision making, handling of business entities, etc. by the business user. Our work use these definitions to propose a methodology to enact cases, based on the ACM paradigm and using business language for the definition of value streams and their stages together with rules.

4 Modelling of Business Value Streams

Our proposal addresses the alignment of business goals and ACM implementations using the value stream approach and behavioral business rules as shown in Fig. 2.

Fig. 2.
figure 2

Business architecture abstraction

Business domain analysts describe VSs with their expected outcome and a trigger action which enacts the case. Both use the domain-specific business ontology in order to ensure uniqueness of terms and their alignment between all involved parties. The accomplishment of goals is performed by actions, which represent the business tasks supported by the ACM platform. These actions can be linked with organizational units, such as stakeholders, customers or domain-specific roles. The actions related to a value stream are constrained by behavioral business rules which are defined by the domain analysts which will commonly manage entities required by that value stream. Actions are executed by business users until all rules are satisfied and the goals of the value stream are reached.

4.1 Modelling the Ontology

Considering the terminology defined in the previous section, our methodology begins with the definition of value streams, actions and rules in natural business language to create the domain-specific ontology. With this set of entities, the business domain analyst describes a full business application which is depicted in the Fig. 3. The ontology is used together with a grammar to formalize the values stream. The business rules which constrain the accomplishment of a value stream stage, enable the execution of actions as declared by the rules. The implementation of these actions is based on the definition of action templates in the ACM platform.

Fig. 3.
figure 3

Formalization of business case

This formalization of the business application is systematically described with the following steps, as showed in Fig. 3:

  1. 1.

    A goal is accomplished as a result of the execution of actions. An action is described with a simple sentence which contain a subject and a predicate. The subject identifies the business user or assignment role responsible for the action (item (1) in Fig. 3).

  2. 2.

    The predicates are formed by a verb and an object. This object has to be mapped to a concept or property in the ontology. Likewise, the rules relate concepts to properties or to specific properties values. Either the action or rules objects are mapped to concepts, properties and status (item (2) in Fig. 3) in the business ontology. Status are defined with a property identifying the concept lifecycle.

  3. 3.

    The verb in the predicate describes the action that the platform executes. These actions can include basic CRUD actions (Create, Retrieve, Update or Delete) for concepts (e.g.: “Create” a Concept) or domain-specific actions (e.g. “Delivery” a Purchase). The business actions are directly executed as actions in the case (item (3) in Fig. 3).

  4. 4.

    The enactment of the actions described for the value stream stages are driven by the list of behavioral business rules. Therefore, we use the dependencies between rules and actions to pinpoint when these rules must be evaluated. This relationship is displayed in item (4) in Fig. 3.

4.2 Formalizing Actions and Rules

To formalize the action and rules, the domain ontology obtained (see item (2) in Fig. 3) is extended with a natural language grammar for the definition of rules and their relationship to actions. This grammar includes expressions such as mandatory terms (i.e.: must/exists), conjunctions and disjunctions (and/or) and navigation between concepts and properties (e.g.: Concept C has Property P) which enable to express a wide range of rules and actions using business language.

With the described methodology, business cases can be freely defined by business domain analysts in a formalized way. The implementation and automation of the business entities, i.e. (i) management of ontology, (ii) enactment of actions and (iii) evaluation of rules, can be achieved with common IT resources, whose detailed description is out of the scope of this paper. The management of the domain-specific ontology by business domain analysts can be addressed with ontology editors together with data mapping definitions to the underlying persistent data layer of information systems. After an initial business data definition they are considered as rather stable during the business lifecycle which allows business domain analysts to adapt the ontology to new business needs with no or drastically reduced support from IT developers. The rule evaluation can be performed with the monitoring of business events on system level, as have been addressed by ACM proposals stated in previous sections [22, 23].

We have implemented this methodology using the ISIS Papyrus ACM platform Papyrus Converse [18] to support business domain analysts with the definition of value streams, actions and rules including the maintenance of the domain-specific ontology (Papyrus Converse Composer). Business users manage business cases and their execution with the Papyrus Converse Player, a conversational user interface for intuitive, user guided business collaboration. In next section, we address the management of a building construction project as a running example of this methodology.

5 Applying ACM Enhanced with Business Architecture Concepts to the Construction Industry Information Modelling

Construction industry projects involve a number of different companies and trades acting in several roles, such as architects, building project managers or plumbing workers. Building Information Modeling (BIM) [7] proposes an open, vendor-independent environment to bring together architects, planners, BIM managers and many other disciplines, allowing them to work on a common data model. However, standardization in terms of interfaces and interoperability is weak and incomplete, leaving gaps and ambiguities when passing data from one knowledge worker to the next, leading to efficiency problems, constructions delays and budget problems.

To achieve higher efficiency and quality, the workflow of knowledge workers in the field of architecture, planning and building services shall be optimized by making the information, which is transferred between the domains accessible in a dynamic, case-based process management with ACM. This will improve the overall interoperability and reduce the information loss at the interfaces. ACM empowers the design process to detect model problems and give feedback to knowledge workers from a previous stage; support by machine learning methods helps guiding the knowledge workers from previously observed situations, but also supports fixing model problems and assists the knowledge workers with feasible recommendations for improvements. In this evaluation, we focus on the business cases involved in the calculation of energy consumption during all building phases. These cases include the reviewing of the architecture model quality (to avoid problems in the building envelope) or processing the building physics (material thermal transmittance) in order to obtain the heating load for the building.

5.1 Building Construction Project Modelling

Based on the methodology described, we describe one of the use cases of BIM projects, “Approve an architectural model”. Architectural models with a minimum quality are required for later stages, such as defining thermal properties or calculating energy consumption. Following the procedure described in previous section, the business modelling starts with the definition of the goals and related actions for this VS with natural language. This VS handles the iterative refining of an architecture model and includes actions such as the committing a new architecture models to the platform or the reviewing of the model quality by the project manager (BIM manager). Figure 4 depicts a simplified description of all the entities involved. First, this VS is composed of three goals, Commit Model, Check Model and Approve Model (item (1) in Fig. 4). These goals are accomplished through related actions (item (3) in Fig. 4). The execution of these actions depends on business rules, such as “To check model, the model must be committed” (item (4) in Fig. 4). And the formalization of such actions and rules requires the definition on a business ontology including all the concepts (names) and relationships (verbs) addressed in natural language (e.g.: models, check results, etc. as depicted in item (2) in Fig. 4).

Fig. 4.
figure 4

Definition of value stream “Approve an architectural model”

5.2 BIM Scenario Architecture

The resulting architecture of the ACM platform for the BIM domain is depicted in the Fig. 5. It is composed by (a) a component to enact business actions based on the monitoring and evaluation of rules and (b) the BIM ontology which is mapped to an underlying data model. New actions specific for the BIM domain are implemented in order to communicate with external tools, such as building model checkers or calculators for thermal properties. The supported data includes also file types, such as BIM standard formats, Industry Foundation Class (IFC) and BIM Collaboration Format (BCF).

Fig. 5.
figure 5

ACM platform architecture

6 Conclusions

Applying the presented methodology to the building construction domain using Papyrus Converse allowed our project partners from the construction industry to describe the business cases with a language that is natural to them (architects, building physicists, etc.). The initial definition of the domain-specific ontology turned out to require quite some coordination efforts between all stakeholders to describe “how we work”, in order to reflect a unique description of used terms and how they are related. Despite these efforts, the definition of values streams, ontology, actions and rules to enact the business cases proofed to empower business domain analysts without IT involvement. Only the mapping of ontology entities to an underlying data model and the definition of actions calling external BIM tools like ArchiCAD, Revit, energy simulation, etc. requires a certain support from IT which is covered by the initial system setup and does not call for continuous adaptations when business needs change. Thus, it facilitates a work environment with considerably reduced IT efforts as business users are able to adapt the system according to changes resulting from daily business needs without the hurdles imposed by rigid business processes definitions or new IT developments. As the case definition is aligned to the business objectives, actions can be clearly related to relevant KPIs, focused on business capabilities and linked with organizational units. The uncoupling of the domain-specific business ontology (business information model) from IT implementation avoids dependencies from IT requirements such as performance or scalability.

As the presented methodology is completely agnostic to any business domain it can be easily applied to new scenarios such as insurance applications or maintenance services. Further work is planned for these domains, together with the enrichment of the Papyrus Converse user interfaces for a seamless and even more natural communication with users supported by techniques such as speech recognition and language machine learning to take advantage of the defined business language.