Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

6.1 Introduction

Information, data and knowledge are fundamental concepts of our everyday activities. Social networks, smart portable devices, and intelligent cars, represent only a few instances of a pervasive, information-driven vision [1] for the next wave of the digital economy and better-aligned information systems. Digitization [2] encompasses the collaboration of human beings and autonomous objects beyond their local context using digital technologies. Digitization further increases the importance of information, data and knowledge as fundamental concepts of our everyday activities. By exchanging information human beings and intelligent objects are able to make decisions in a broader context and with higher quality. Major trends for digital enterprise transformation are investigated by Leimeister et al. [3]: (i) Digitization of products and services: products and services are enriched with value-added services or are completely digitized; (ii) Context-sensitive value creation: though popularity of mobile devices location contexts are used more frequently and enable on demand customized solutions; (iii) Consumerization of IT: One of the challenges is the safe integration of mobile devices into a managed enterprise architecture for both business and IT; (iv) Digitization of work: Today it is much easier to work together over large distances, which allows often an uncomplicated outsourcing of business tasks; and the (v) Digitization of business models: Businesses need to adapt and have to rethink their business models to develop innovative business models according to employees’ current skills and competencies.

The technological and business architectural impact of digitization has multiple aspects, which directly affect adaptable digital enterprise architectures and their supported systems. Smart companies are extending their capabilities continuously managing their changing Business Operating Model [4] by developing and maintaining Enterprise Architectures as the architectural part of a changing IT Governance [5]. Enterprise Architecture Management [6–8] and Services Computing [9, 10] is the approach of choice to organize, build, utilize, and distribute capabilities for digital enterprise architectures [11, 12]. They provide flexibility and agility in business and IT systems. The development of such applications integrates Web and REST Services, Cloud Computing and Big Data management, among other frameworks and methods for the architectural semantic support. Today’s information systems span a broad range of domains including: intelligent mobility systems and services, intelligent energy support systems, smart personal health-care systems and services, intelligent transportation and logistics services, smart environmental systems and services, intelligent systems and software engineering. One of the challenges is the safe integration of mobile devices into managed enterprise architecture of both business and IT. Today it is much easier to work together over large distances, which allows often an uncomplicated outsourcing of business tasks. Businesses need to adapt and have to rethink their business models to develop innovative business models according to employees’ current skills and competencies.

Digitization of products and services requires the close alignment of business models and digital technologies for creative digital strategies and solutions, as well as for their digital transformation. Unfortunately, the current state of art and practice of enterprise architecture lacks an integral understanding and support of collaborative decisions in the process of architectural adaptation and enterprise transformation. We have therefore to extend previous approaches of enterprise architecture to fit to the digitization of new products and services and by introducing suitable mechanisms for collaborative architectural engineering and decision support with adaptive case management for agile changing business models, information systems and their digital enterprise architecture.

We are investigating concepts and mechanisms for analyzing enterprise architectures to provide decision support for the architectural evolution and adaptation. We abstain from defining a heavyweight framework for EA management, but provide a platform laying a basis for manifold analysis techniques that can be combined as necessary. We regard this approach advantageous over the state-of-the-art with its abundance of “ingredients” that are often not adopted in the practice of EA management. Further, the analysis techniques allow a focus on key aspects of the ongoing transformation, like a cloud transformation, without losing the enterprise context, which is represented in different perspectives and stakeholder-specific viewpoints.

A new refocused decision-oriented approach for digital enterprise architectures should be both holistic and easily adaptable. Our aim is to support flexibility and agile transformations for both business domains and related enterprise systems through semiautomatic semantic-supported decisional processes, which are combined with analytics of real-time changing information environments. The present research is focused on decisional support for conceptual and architectural information, analytics-based methods, semantic representations and inference mechanisms, which are combined to enable stakeholder-centric decisional processes and transparency information for digital transformations.

Section 6.2 describes our fundamental orientation for digitized products and services. Section 6.3 focuses on our research platform for digital enterprise architecture, which was extended by concepts from adaptive case management, mechanisms for architectural adaptation and a specific model integration method. Section 6.4 presents our decision case management environment and links this in Sect. 6.5 with collaborative decision services and mechanisms. In Sect. 6.6 we present the decisional metamodel for digital enterprise architectures as a base for our decision analytics approach. Section 6.7 sketches the semantic support for architectural analytics by adding a suitable knowledge representation for both architectural concepts and decision metamodels. Finally, we summarize in Sect. 6.8 our findings and our future research plans.

6.2 Digitization of Products and Services

Digitized products and digitized services are both software-intensive and therefore malleable and usually service-oriented. They are able to increase their capabilities accessing cloud-services and change their behavior. Digitized products support the co-creation of value together with the customer and other stakeholders. Digitized products and services offer disruptive opportunities for new business solutions having new smart connected functionalities. At first, the high level of interest surprises, because the digital representation of information and performing digital calculation operations have been established for decades. The term digitization has its origin in [13] and is used for the digital representation of information, and processing since years [14].

There are definitions that consider digitization a primarily technical term [15]. Technologies often associated with digitization [16] are: cloud computing [17], big data [18, 19] advanced analytics, social software, and the Internet of Things [20]. The set of technologies increases. New technologies such as deep learning [21] are emerging that allow computing to be applied to activities that were considered as exclusive to human beings.

Therefore the question arises, what causes the present emphasis on digitization and what is different about digitization. Out thesis is, that digitization today embraces effects from both a product, and a value-creation perspective. Digitization can be described from both a product and a value-creation perspective: digitized products and the digitized value chains. Digitized products offer new capabilities to interact with their environment and the customer. They are also capable to collect data.

Classic industrial products are static [22]. You can change the production not or only to a limited extent. Digitization creates products containing software that can be upgraded via network connections. In addition, products over network connections can use external services. Software and especially services are also easier to update. New software functions can be added and additional services can be integrated. Therefore, the functionality of products is no longer static, but can be adapted to changing requirements and hidden customer needs. In particular, it is possible to create digitized products and services step-by-step or provide temporarily unlockable functionalities. So, customers whose requirements have risen can add functions without hardware modification.

Digitalization [2] allows products to capture their own state and submit this information into linked contexts. The provider can remotely determine whether the product is still functional and encourage, where appropriate, maintenance and repairs. This is the basis on which, instead of the physical product, the use of the product as a service changes the traditional offer. These services will be measured on their effectiveness and their practical usage. This will lay the foundation for usage-based billing models. In addition to the usage information also the condition of the product by the manufacturer can be queried.

In this context, concepts of preventive maintenance [23] can be developed. These have the objective of unscheduled stoppages whenever possible to avoid. Evaluation of status information and analysis of the history of use of the product can be predicted, when a malfunction of the product is likely. A maintenance or replacement of the product is performed before the respective date. In this context, the collected data can also be used to provide information for a repair on the spot, so that a high first time solution rate can be achieved. At the same time, storage can be improved in this way of spare parts.

The Internet of Things [24] enables the creation of products that are constantly in communication with the manufacturer. In this way, the manufacturer can win genuine information about the use of the product. The collection of information on the use of products is no longer dependent on the cooperation with the customer. In addition, it is possible to collect important information for up—and cross—selling in this way. By linking devices on networks, benefits are generated from two areas. Both the functionality increases and there are positive effects arising from the overarching data use. Furthermore, the production of more customer-oriented products [25] is possible.

Network effects [26] grow exponentially, because they are based on the number of participants and the number of possible connections. The possibility to connect devices of the network increases the possibilities of the individual device, because increasing the number of potential partners. This benefit increase is disproportionate higher as the number of devices, since the number of possible connections grows faster as the device number [27].

This increase of commercial value also happens through services provided by a lot of partners with complementary skills [22]. Software platforms that support the collection, analysis and exchange of data are rapidly growing. Winners in this environment will be companies, enable network effects to create value for customers. Network effects become apparent not only in functionality, but also in the scope of the data. These effects are called network intelligence [13]. By bringing together data from different network nodes, trends can be detected much earlier and more accurately.

By linking data from different sources [28], it is possible to establish correlations that would not have been possible with the data of a single device. This effect increases with the number of devices. By integrating external data sources, the extraction of relevant information can be improved also. Particularly the ability of big data and advanced analytics helps to process particularly semi- and unstructured data.

Characteristic is the involvement of individual product in an information system, which accelerates the learning and knowledge processes across all products [19]. In this way, a number of other beneficial effects can be achieved as network optimization, maintenance optimization, improved restore capabilities, and additional evidence against the consideration of individual systems.

Central is the idea that the producer of goods creates value and the value is determined at the moment of exchange of goods. It was tried to transfer this idea on services. However, this led to a service definition, which considers services as a negation of physical goods [29]. Services are not material, but already the missing homogeneity can be challenged for industrial services. Services are also not divisible, i.e. they must be provided as a whole. Services are also not durable; they are not stored and are provided only at the moment of need.

Basis for the implementation of the co-creation [30] approach of service-dominant logic is the continuous connection of the products with the manufacturer. The manufacturer can win genuine information about the use of the product. Important information for the development of new products can be obtained in this way. The consumer converts dynamically to be co-producer [31]. Platforms are complementary products, which cooperate via standardized interfaces [32]. Since the development of new functionalities by different partners is distributed [33] platforms significantly speed-up the development time of new solutions.

6.3 Digital Enterprise Architecture

Enterprise Architecture Management (EAM) [6, 7, 9, 34] defines today with frameworks [35], languages [36], and standards [37, 38], tools and practical expertise a quite large set of different views and perspectives. EAM can be e.g. used to support and implement business processes as well as to reach business goals [39]. Benefits of EAM are influenced by different influence factors such as EAM knowledge, landscape complexity and Business IT alignment [40]. We argue in this paper that a new refocused digital enterprise architecture approach should support digitization of products and services, and should be both holistic [41, 42] and easily adaptable [43] to support the digital transformation with new business models and technologies like social software, big data, services and cloud computing, mobility platforms and systems, security systems, and semantics support. We are extending the first versions of ESARC–Enterprise Services Architecture Reference Cube [41, 42] (Fig. 6.1).

Fig. 6.1
figure 1

Enterprise services architecture reference cube [41–43]

Full size image

In this paper we extend our service-oriented enterprise architecture reference model for the context of managed adaptive cases and decisions [44, 45], which are supported by case services of a collaborative case framework [44] within an adaptive case management environment [46]. Additionally we have considerably extended our architectural metamodel integration approach [47] to support digital enterprise architectures for digital transformations [11] and the integration of Internet of Things [12, 24] architectures.

ESARC—Enterprise Services Architecture Reference Cube [41, 42] is an architectural reference model for an extended view on evolved digital enterprise architectures. ESARC is more specific than existing architectural standards of EAM—Enterprise Architecture Management [35, 36] and extends these architectural standards for digital enterprise architectures with services and cloud computing. ESARC provides a holistic classification model with eight integral architectural domains. These architectural domains cover specific architectural viewpoint descriptions [37, 38] in accordance to orthogonal dimensions of both architectural layers and architectural aspects [6, 34, 42]. ESARC abstracts from a concrete business scenario or technologies, but it is applicable for concrete architectural instantiations to support digital transformations. The Open Group Architecture Framework [35] provides the basic blueprint and structure for our extended service-oriented enterprise architecture domains of ESARC [41, 43] having: Architecture Governance, Architecture Management, Business and Information Architecture, Information Systems Architecture, Technology Architecture, Operation Architecture, and Cloud Services Architecture. ESARC provides a coherent aid for examination, comparison, classification, quality evaluation and optimization.

We developed an architectural evolution approach to integrate and adapt most valuable parts of existing EA frameworks and metamodels from theory and practice [47]. Additionally to handling architectural structures for dynamically extending core metamodels we see a chance to integrate decentralized mini-metamodels, models and data of architectural descriptions coming from small devices and new decentralized architectural elements, which traditionally are not covert by enterprise architecture environments. The focused model integration approach is based on special correlation matrixes to identify similarities between analyzed model elements from different provenience and integrate them according their most valuable contribution for an integrated model. According to [48] we are building the conceptualization of EA in 4 steps—from stakeholders’ needs, to the concerns of stakeholders, then the extraction of stakeholder relevant concepts, and last but not least the definition of relationships for new tailored architectural metamodels.

Our research consists of a metamodel-based model extraction and integration approach [47] for digital enterprise architecture viewpoints, models, standards, frameworks and tools to support digital transformations [11, 12]. Currently we are working on the idea of continuously integrating small EA descriptions for relevant objects of digital enterprise architecture. These EA-Mini-Descriptions consists of partial EA data and partial EA models and related metamodels. Our goal is to be able to support an integral architectural engineering and transformation process.

Adaptation drives the survival [49–51] of digital enterprise architectures [47], platforms and application ecosystems. Adapting rapidly to new technology and market contexts improves the fitness of adaptive ecosystems. Volatile technologies and markets typically drive the evolution of ecosystems. We have additionally to consider internal factors. The alignment of Architecture-Governance [4, 5] shapes resiliency, scalability and composability of components and services for distributed information systems.

6.4 Decision Case Management

A Decision support system (DSS) is a system “[…] to help improve the effectiveness of managerial decision making in semi-structured tasks” [52, p. 255], and according to [53]. In particular knowledge intensive management activities, like EAM, can benefit from a DSS to improve architectural decision-making. In the following we explore how an EA cockpit [54] can be leveraged and extended to a DSS for EAM. A cockpit presents a facility or device via which multiple viewpoints on the system under consideration can be consulted simultaneously. Each stakeholder who takes place in a cockpit meeting can utilize a viewpoint that displays the relevant information. Thereby, the stakeholders can leverage views that fit the particular role like Application Architect, Business Process Owner or Infrastructure Architect [55]. The viewpoints applied simultaneously are linked to each other such that the impact of a change performed in one view can be visualized in other views as well. Figure 6.2 gives the idea of an example architectural cockpit.

Fig. 6.2
figure 2

Example: enterprise architecture cockpit [54, 56]

Full size image

Jugel et al. [56] present a collaborative approach for decision-making for EA management. They identify decision making in such complex environment as a knowledge-intensive process strongly depending on the participating stakeholders. Therefore, the collaborative approach presented is built based on the methods and techniques of adaptive case management (ACM).

Adaptive Case Management (ACM) [44, 45] offers a lightweight model to support knowledge-intensive processes, which are driven by user decision-making. Knowledge processes of usually high-skilled stakeholders, like enterprise architects, require process adaptations at run-time. ACM is not dictating a predefined course of action [57] and provides the necessary information and knowledge support to be able to solve a case. A case [45] is typically a collection of all relevant information into one place, which is handled by one or more knowledge workers during solving this case. The case is the jointly used focal point for assessing the situation, initiating activities and processes, implementing the work, and reflecting results based on a history record about what was really done. A case brings together all the necessary resources and also tracks everything that has happened into a record history, which can be mined to synthesize best practices, patterns of success, and used and extended instruments. Fundamental aspects and requirements for ACM, are mentioned in [57]:

  1. 1.

    The adaptation aspect of ACM consists of content, people, and reporting capabilities to be able to change the knowledge process at run-time by end-users. Additionally to the adaptation aspect a knowledge worker should be able to continuously improve his case templates.

  2. 2.

    The organization aspect groups policies, processes, and data. In ACM data is the dominant factor as opposed to the process-oriented view from BPM. Knowledge work requires the integration of data [50] into the execution process.

  3. 3.

    The case handling aspect is about collaboration, decision support, and integration of resources, events, and communication. Complex problems are typically solved collaboratively by involving individual stakeholders in respect of different necessary knowledge types and stakeholder concerns. Decision support requires transparency within a shared understanding of analyzed EA scenarios by named stakeholders.

Opposed to routine work, which can be supported by business process management because of its repeatable kind, knowledge work is typically unpredictable. Knowledge workers [58, 59] are acting under uncertainty. An unpredictable process [45] does not repeat in routine patterns and emerges as the work is done. The practice of preparing for many possible courses is called agility. Differentiating seven domains of predictability [45] case management can be focused on two main types:

  1. 1.

    Product Case Management: Supports design-time knowledge processes with a well-known set of actions, having much variation between individual cases. It is not possible to set out a single fixed process. Knowledge workers are actively involved in deciding the course of events for a case.

  2. 2.

    Adaptive Case Management: Knowledge workers are involved not only in the case, and picking predefined actions, but they are constantly adapting the process and striving for innovative approaches, and may want to share and discuss process plans.

The Case Management Modeling Notation (CMMN) [60] is a notation for ACM that describes mandatory and optional tasks (DiscretionaryItem), and thereby supports flexible processes. In line with Jugel et al. [61], we utilize the CMMN to describe a collaborative decision-making case for EAM, cf. Fig. 6.3.

Fig. 6.3
figure 3

CMMN model of collaborative decision making case [61]

Full size image

The Issue is the starting point of a collaborative decision-making case. This issue describes the problem space of the decision-making activity, which aligns with the perspective of Mayring [62]. We further assume that goals and success criterions, as required by Johnson and Ekstedt [63], have already been defined as part of strategic management activities. The issue is the reason why the EA has to be analyzed and decided upon. Based on this issue, involved stakeholders choose viewpoints that they need to analyze the issue.

The decision-making step is the central activity of the decision-making case presented in Fig. 6.3. This step can involve different optional activities in which different kinds of quantitative and qualitative analysis techniques [64] are applied to gain additional insights [60]:

  • Expert-based analysis techniques are dependent on expert knowledge and tacit information of the involved stakeholders. Jugel and Schweda [54] identify these techniques with interactive functions like “graphical highlighting and filtering”.

  • Rule-based analysis techniques correspond to algorithms that are used to indentify patterns in the EA. Hanschke provides so-called analysis patterns in [65], which are examples of rule-based analysis techniques.

  • Indicator-based analysis techniques are formal methods that compute indicators from properties of the EA. Matthes [66] present quantitative, metrics-driven EA analyses by quantitatively assessing architectural properties and therefore use an indicator-based analysis technique.

The stakeholders apply different of these techniques in the decision-making step and interpret the results of the techniques for additional insights [62]. While performing a decision-making step, stakeholders can choose analysis techniques, which are part of a catalog. The catalog is independent of a particular case. After choosing an analysis technique, it is performed. In case of rule-based and indicator-based analysis techniques, the techniques can be performed automatically using algorithms and aggregations. In case of an expert-based analysis technique, stakeholders must manually analyze the EA by using and interaction with the cockpit’s views.

The decision-making step is based on case data consisting of an EA model and additional insights elicited in previous steps. Consequently, the insights gained during each step contribute to the case file (CaseFile) of the decision-making case. Derived values, like the values of KPIs are thereby not considered additional information, but only a different way of representing and aggregating existing information. If stakeholders based on the values of a KPI decide on affected architecture elements, these decisions and considerations represent new information, which is added to the case file. In particular, the stakeholders’ interpretation can yield following additional elements for the case file (CaseFileItem):

  • An evaluation represents the stakeholder’s opinion on the analysis results.

  • A new issue refines the previously analyzed one based on the analysis.

  • A decision reflects a design alternative that is useful to resolve the issue.

During the decision-making, alternative designs can be identified [63]. In the final step of the decision-making process, not all previously evaluated designs will prevail. At the end of every decision-making step, the stakeholders have to decide, whether additional information is required or not—represented by to UserEventListeners in the CMMN diagram in Fig. 6.3. The case file of the decision-making case has to be structured appropriately to accommodate for the decision-making process.

The Object Management Group (OMG) has published the Case Management Model and Notation (CMMN) [60] as a first step to support modeling for case management scenariosmanagement scenarios. A case study of a TOGAF-style process [35] for EAM with CMMN was implemented in [67]. The upcoming standard Decision Model and Notation (DMN) of OMG [68] discern three usage models: for modeling human decision-making, for modeling requirements for automated decision-making, and for implementing automated decision-making. DMN bridges the gap between business decision designs and their implementation by providing a common notation for decision models. The purpose of DMN is to facilitate a decision model framework, which is easily usable for decision diagrams and as a base for optionally automating decisions. Decision-making support is addressed from basically two perspectives: normal BPMN business Process Models can be expanded by defining specific decision tasks, or decision logic can be used to support individual decisions, e.g. business rules, decision tables, or executable analytic models. DMN can additionally provide a third perspective to bridge between business process models and decision logic by introducing the Decision Requirements Diagram. Complementary to the DMN notation, which is used to model decisional relationships and concepts like Decision, Input Data, Business Logic, Application, Application Risk, etc. DMN introduces an expression language to represent decision tables, decision rules, and function invocations. Today we are exploring the suitable usage and close link of DNM for decisional support logic within our architectural engineering and analytics research.

6.5 Collaborative Decision Processes

Although concepts such as Business Process Management [69] introduced a customer-oriented perspective, it still contains many concepts following the ideas developed already in [70]. These are the division of larger tasks into defined, smaller tasks and the assignment of individual responsible to accomplish these tasks. Therefore it does not surprise, that a plenty of approaches such as [71], Swenson [44] tried to develop support for cooperation beyond strictly structured business processes as almost all WFMSs and most of the BPMSs, but also some groupware and case management systems. However these approaches become not as successful as expected.

One has to meet a number of challenges when supporting EA management processes. The first challenge is the lack of a pre-defined workflow. Similar to adaptive case management [44, 45] the control-flow of EA management processes cannot be predefined in most situation. Instead the control-flow is defined “on-the-fly” during execution of the EA management process.

The second challenge is organizational integration [72]. Many early approaches addressing the support of EA management processes limited the participation of stakeholders. E.g. although classical groupware abstained from pre-defining a strict control flow, specific access rights to documents had been assigned. Thus the group of possible contributors had been limited. In this way an a priori-decision had been made deciding who may contribute and who may not. Some stakeholders were not able to contribute.

The third challenge is semantic integration [72]. Due to the involvement of a multitude of stakeholders, semantic frictions such as homonyms and synonyms create misunderstandings between the process participants. These semantic frictions may delay the EA management process or even worse, may cause deficient architectures.

Social software is based on four basic principles: social production [73], weak ties [74], collective decisions [75], and value co-creation [76]. Each of these principles support EA management processes by addressing one or more challenges, as addressed in Fig. 6.4.

Fig. 6.4
figure 4

Collaborative engineering and transformation [77]

Full size image

Social production [73] is the creation of artifacts without a top-down created plan but by combining the suggestions and decisions from independent contributors. By abstaining from Tayloristic top-down planning, new and innovative contributions outside the original scope can be identified and added. Due to these properties, social production matches the requirements of EA management processes. The control flow of EA management processes can be defined in an ad hoc manner. During execution of the EA process, architectural artifacts can be investigated in a cooperative way.

Collective decisions [75] provide a new way in EA management processes to make decisions. They provide statistically better results than experts, if the decision cannot be made using scientific means and the participants decide independently. Surowiecki describes in [78] the approach of the so-called the wisdom of crowds. He argues that a decision made by several persons often leads to better results, because each person has a specific knowledge. Value-co-production [78] is also supporting the definition and execution of EA management processes by integrating contributions from the business side. By abolishing the separation between artifact producer and consumer, a better adaptation to the individual requirements can be achieved. Furthermore value co-production enhances the organizational integration.

6.6 Decision Analytics

In this section we present a decisional metamodel based on the work of Jugel et al. [61] to support the decision-making case presented in the previous section. The metamodel focuses on the documentation of decision and rationalizing information and is a combination of several approaches that partly cover aspects of decision-making.

  • Plataniotis et al. [79] describe an approach called “EA Anamnesis” focusing on ex-post modeling EA decisions and decision-making strategies. However, they do not describe decision processes. Furthermore, they do not describe rationales.

  • ISO Standard 42010 [37] describes how the architecture of a system can be documented using architecture descriptions. The standard uses views, which are governed by viewpoints to address stakeholders’ concerns and their information demands.

  • Jugel and Schweda [54] introduce an annotation mechanism to add additional knowledge to an architecture description represented by an EA model. In addition, in [61] they refine the viewpoint concept of [37] by dividing it into Atomic Viewpoint and Viewpoint Composition to model coherent viewpoints that can be applied simultaneously in a cockpit to support stakeholders in decision-making.

  • Buckl et al. [64] provide a classification of analysis techniques that can be used to get insights into an EA. Stakeholders in decision-making use analysis techniques.

The Case Management Modeling Notation (CMMN) [60] is a notation for ACM to describe flexible processes including optional tasks. The notation provides us base concepts to model cases.

Figure 6.5 illustrates the decisional metamodel. The background colors of the concepts indicate their origin. Green colored concepts have their origin in ISO Standard 42010 [37], gray colored concepts in “EA Anamnesis” [79], blue colored concepts in CMMN [60], yellow colored concepts in [64] and red colored concepts in [54, 61]. The decisional metamodel focuses on the stakeholders using viewpoints to perform a Decision making Step that is in line with CMMN [60] a HumanTask. During this step, stakeholders have the ability to choose Analysis Techniques that are in line of CMMN [60] DiscretionaryItems. Additional information during a step is created and persisted as Annotations to the deci-sional views. Annotations as well as Views are in line with CMMN [60] CaseFileItems, because both represent relevant information within a case and are therefore part of a CaseFile. The annotation concept aligns with the one presented by Jugel et al. in [54] and reflects different EA issues (also the initial one of the decision case), Evaluations of the analyses’ results, and EA decisions. As the annotations can be based on the results of an analysis technique, also the applied techniques are part of the metamodel and are persisted in the CaseFile. Latter notion corresponds to the terminology of CMMN.

Fig. 6.5
figure 5

Collaborative EA decision making metamodel

Full size image

For the utilized viewpoints, we distinguish between Atomic Viewpoints and Viewpoint Compositions [61]. Whereas an Atomic Viewpoint is a single Viewpoint in line with ISO Standard 42010 [37], a Viewpoint Composition forms a composite structure and consists of coherent Atomic Viewpoints or other Viewpoint Compositions needed by Stakeholders to satisfy their information demands elicited by their Concerns. Viewpoint Compositions are assembled to address a specific decision-making case from multiple perspectives. A cockpit, as presented in the previous chapter, is a viewpoint composition.

In addition, Annotations are the triggers for the next Decision Making Step. One or more Stakeholders are responsible for a step and perform them. Within Decision Making Step stakeholders can choose between different Analysis Techniques to get additional information needed to satisfy their information demands. Analysis Techniques are based on Annotations as well on the EA model. Annotations describe additional information related to EA Artifacts. EA Issues and EA Decisions, as already present in the model of Plataniotis et al. [79], represent additional knowledge and are therefore specializations of Annotation. As described in [79], EA Decisions can be decomposed, translated and substituted into other EA Decisions. Modeling alternatives is also possible. According to our decision-making case, we added Evaluation as a third sub-concept of Annotation.

6.7 Semantic Support for Architectural Analytics

Semantic technologies [80] in general and ontologies in particular provide support for architectural analytics in many ways. The general features of ontologies address some of the aforementioned challenges and requirements for architectural analytics. Namely, the provision of domain specific knowledge and vocabulary allows the creation of stakeholder specific views (cf. Sect. 6.6), ontology alignment and mapping are common mechanisms of semantic integration (cf. Sect. 6.5), inference on ontologies can identify patterns in the domain knowledge (cf. Sect. 6.4) and can make implicit knowledge explicit by adding new facts to the knowledgebase.

Thus, many approaches have been made to represent enterprise models or enterprise architecture respectively by creating ontologies for this domain. The most popular examples are probably Uschold et al.’s “The Enterprise Ontology” [80] and Dietz’s DEMO approach [8]. Further publications in the area are [81–83]. The Enterprise Architecture Ontology for Services Computing from [83] extends the ESARC metamodel from [41] with e semantic representation for enterprise architectures. Ontologies in enterprise modeling and architecture are useful, as shown by Sandkuhl et al. [84].

The most widely used definition of ontologies in computer science characterizes ontologies as “formal, explicit specification of a shared conceptualization” [85]. Here, “conceptualization” means creating an abstract model of real world phenomena by identifying relevant concepts of them. “Explicit” refers to a clear definition of concepts, concept types, and the constraints on their use. “Formal” means that an ontology is machine readable, and “shared” reflects the intention that the ontology should be a consensus, accepted within the communities.

Literature defines several functionalities and features of ontologies that support enterprise architecture analytics. Uschold and Gruninger [86] names three uses of ontologies: (1) Communication, (2) Interoperability, and (3) Systems engineering. Since ontologies are shared conceptualizations in communities they provide a base for human communication. Being a normative, assuring consistency, and avoiding ambiguity they foster knowledge exchange in collaborative decision scenarios, as they are present in enterprise architecture analytics scenarios. Furthermore, they provide networks of relationships that relate the knowledge regarding different concerns of stakeholders and they provide a semantic integration of this knowledge on the level of human communication. Interoperability or integration by ontologies provides the same features on the level of externalized knowledge in information systems. Thus a better information quality can be achieved for decision situations. At last, the use of ontologies for systems engineering assures reuse of existing knowledge and better interoperability of information systems. Bürger and Simperl additionally name in [87] specifically (4) Computational Inference and (5) Knowledge Reuse and Organization as contributions of ontology use. Computational inference allows for deriving implicit facts and logical inconsistencies. Having concepts and rules systematically formalized, reuse of models and model-party in different domains becomes possible.

Antunes et al. describe in [88, 89] specifically the use of ontologies in enterprise architecture analysis:

  • Improved extensibility and expressiveness of the enterprise architecture through ontology based integration of domain-specific meta-models.

  • Improved enforcement of meta-model coherence by defining constraints of concept use.

  • Improved meta-model conformance verification by the use of reasoners that can identify logical inconsistencies in enterprise architecture models.

  • Improved analysis for decision making through the use of inference and query mechanisms.

These features can be derived from the general features of ontologies. Subsuming the discussion, the benefits of ontologies for enterprise architecture analytics are twofold. First, they provide means for a better communication in the collaborative decision scenarios of enterprise architecture analytics. Second, they support rule-based analysis techniques by computational inference and a potentially broad information base through interoperability.

Antunes et al. propose in [81] a general four-step process of enterprise architecture analysis using ontologies:

  1. 1.

    Identify stakeholders and analysis needs: After identifying the stakeholders, their information needs are gathered in the form of questions and the expected type of answer (e.g. a list of processes or actors). Afterwards, the analysis of questions identifies relevant concepts and instances.

  2. 2.

    Review enterprise architecture models: A comparison between concepts needed for analysis and those in the enterprise architecture model is performed. If there is a gap, hence the model does no cover the stakeholders needs, new concepts have to be added by ontology engineering or by integration of domain specific ontologies.

  3. 3.

    Instantiate model: A model instance for a specific scenario is created.

  4. 4.

    Perform analysis: Computational inference mechanisms are used to answer the questions. In the concrete approach by Antunes et al. Description Logic (DL) queries are used. However, depending on the used tools other ontology query languages can be used.

Antunes et al. provide in [89] an investigation regarding the possibilities of supporting analysis types [4, 5] using DL. Reasoning tasks of DL are:

  • Subsumption: Organizing concepts in taxonomy. Hence, finding the most specific super class for a given class.

  • Instance checking: Verifying if an instance is a member of a specific class or represents a specific concept respectively.

  • Relation checking: Verifying whether two instances are related to each other in a certain way.

  • Concept consistency: Verifying that there is no contradiction in concept definitions or concept definition chains.

  • Knowledgebase consistency: Verifying that there is no contradiction in the model instance.

Taking general ontology engineering approaches, such as Ontology 101 by Noy and McGuiness [90] into account, step 2 also includes the integration or definition of semantic rules that allow deriving implicit facts within the model instance. Thus, queries performed in step 4 may also refer to facts that have been added to the model instance by computational inference. Antunes et al. show the practical applicability of their approach in [89] by the analysis of an ArchiMate [36] model using the Domain Independent Ontology (DIO, representing a conceptualization of the ArchiMate [36] meta-model) and an integration of Domains Specific Ontologies (DSO, representing concepts used by specific stakeholders).

Besides these general steps for ontology based enterprise architecture analysis, it remains unclear where the use of this approach is appropriate and where not. Two dimensions have to be considered answering this question. First, a classification of possible analysis tasks is needed. Different approaches can be used here; analysis patterns by Hanschke [65], and analysis dimensions by Buckl et al. [64] are prominent examples. Second, a classification of reasoning tasks that can be performed in ontologies is needed. Assuming commonly used OWL ontologies, the reasoning tasks supported by Description Logic (DL) cover the reasoning potential.

6.8 Conclusions and Future Work

In this paper we have identified the need for an integral understanding and support of collaborative decisions in the process of architectural adaptation and enterprise transformation. According to our research approach we have leveraged a new model of extended digital enterprise architecture, which is well suited for adaptive models and transformation mechanisms. We have extended the previous more static defined basic enterprise reference architecture by new metamodel elements for supporting cooperative decisions using mechanisms from adaptive case management. Related to our second research question we have presented our approach for collaborative processes in architectural engineering and transformation endeavors. We have combined architectural engineering and transformation processes with elements from adaptive case management. We have adapted typical architectural engineering processes with elements from social production, collective decision-making, value co-production, and week ties. Adaptive case management offers a lightweight model for knowledge-intensive processes. We have merged them with user decision-making processes within cooperative distributed environments for enterprise architecture management. We have introduced suitable individual decision support models and embedded them into cooperative analysis and engineering environments.

We are currently working on extended decision support mechanisms for an architectural cockpit for digital enterprise architectures and related engineering processes. Future work will extend both mechanisms for adaptation and flexible integration of digital enterprise architectures as well as will extend decisional processes by extensions of rationales and explanations.