Digital technologies are main strategic drivers for digitalization and offer ubiquitous data availability, unlimited connectivity, and massive processing power for a fundamentally changing business. This leads to the development and application of intelligent digital systems. The current state of research and practice of architecting digital systems and services lacks a solid methodological foundation that fully accommodates all requirements linked to efficient and effective development of digital systems in organizations. Research presented in this paper addresses the question, how management of complexity in digital systems and architectures can be supported from a methodological perspective. In this context, the current focus is on a better understanding of the causes of increased complexity and requirements to methodological support. For this purpose, we take an enterprise architecture perspective, i.e. how the introduction of digital systems affects the complexity of EA. Two industrial case studies and a systematic literature analysis result in the proposal of an extended Digital Enterprise Architecture Cube as framework for future methodical support.
Digital transformation is the current dominant type of business transformation [
This leads to the development and application of intelligent digital systems (see
section 3). We see great future prospects for digital systems with artificial intelligence (AI)
[
Unfortunately, the current state of art in research and practice of architecting digital
systems and services lacks a solid methodological foundation as the established
methodical approaches do not fully accommodate requirements, e.g., caused by
product-IT integration [
In our work, we take an enterprise architecture (EA) perspective (see section 3), i.e. we do not consider single products, applications or business services but the overall change in business architecture, application architecture and technology architecture of an enterprise. As a first step for investigating the above research question, this paper focuses on a better understanding of the causes of increased complexity and requirements to methodological support. More concrete, our focus in this paper is to investigate how the introduction of digital systems affects the complexity of EA.
The rest of the paper is structured as follows. Section 2 introduces the research methods applied in the paper. Section 3 summarizes the background for our work from EA and digital systems, and discusses related work on architecture complexity. Section 4 presents two industrial case studies of digital system development. Section 5 investigates the effects on architecture complexity in the case studies, Section 6 presents the extended Digital Enterprise Architecture Cube as a result of the case study analysis. Section 7 summarizes our findings and discusses future work. 2
This paper is part of a research process aiming to provide methodological and tool
support for managing architecture complexity. It follows the five stages of Design Science
research [
The research method used for working on this research question is a combination of literature study and descriptive case study. Based on the research question, we analyzed the literature in these areas. The purpose of the analysis was to find work from enterprise architecture management or digital systems that explicitly addresses changes in architecture complexity when introducing artificial intelligence (see section 3.3).
As the literature analysis did not produce relevant papers, we identified industrial
cases of AI introduction into the EA and performed qualitative case studies in order to
obtain relevant and original data (see section 4). Qualitative case study is an approach
to research that facilitates exploration of a phenomenon within its context using a
variety of data sources. This ensures that the subject under consideration is explored from
a variety of perspectives which allows for multiple facets of the phenomenon to be
revealed and understood. Within the case studies, we used two different perspectives,
which at the same time represent sources of data: we analyzed the project
documentation and we investigated the enterprise architecture, business process and software
design models. Yin [
Based on the results of the case studies, we argue that additional perspectives and architecture views would be beneficial for managing architecture complexity. 3 3.1
The term enterprise architecture (EA) in general denotes the fundamental conception
or representation of an enterprise—as embodied in its main elements and
relationships—in an appropriate model. Enterprise architecture management (EAM) provides
an approach for a systematic development of an enterprise’s architecture in line with
its goals by performing planning, transforming, and monitoring functions. The reasons
for applying EAM are manifold, such as supporting the alignment of IT to business
goals or the reduction of complexity. In general, an EA captures and structures all
relevant components for describing an enterprise, including the processes used for
development of the EA as such [
Digital enterprise architecture [
From today’s view, probably no digital technology is more exciting than artificial
intelligence offering massive automation capabilities for intelligent digital systems and
services. Artificial intelligence (AI) [
Artificial intelligence receives a high degree of attention due to recent progress in
several areas such as image detection, translation and decision support [
Artificial intelligence is often characterized as impersonal: From this point of view,
intelligent systems operate completely automatically and independently of human
intervention. The public discourse on autonomous algorithms working on passively
collected data contributes to this view. However, this perspective of huge automation
obscures the extent to which human work necessarily forms the basis for modern AI
systems [
Combining product components of hardware and software with cloud-provided
intelligent services enable new ways of intelligent interaction with customers, as in [
As part of our research work, we performed a literature analysis that aimed at
identifying research work from enterprise architecture management or digital systems that
explicitly addresses changes in architecture complexity when introducing artificial
intelligence. In order to identify relevant work, we decided to perform a systematic literature
review (SLR) based on the procedure proposed by Kitchenham [
The literature source examined was Scopus, which includes most publications from the AIS electronic library (AISeL), IEEE Xplore and Springer. Publications with significant impact on research should reach one of these major outlets. Starting from the research question, we constructed a search query for Scopus by including different keyword combinations and synonyms. The final search queries are shown in Table 1.
The search results show that there is quite some work on “architecture complexity”
(query #1), but most of this work is focused on non-IT architectures (buildings,
facilities, models), hardware architectures (system-on-chip, FPGA etc.) or general software
architectures. However, there is not much work on architecture complexity of digital
systems, intelligent systems or artificial intelligence (queries #2 to #4). Most papers
found were on system-on-chip architectures or protein structures. The only relevant
paper [
The two case studies described in this section were selected from different research and development projects with industrial partners conducted at Rostock University during fall 2019 and spring 2020. The participating researchers made notes during meetings, collected documents and field notes when working with the companies. This material forms the basis for the case studies and is presented in a condensed way in this section. 4.1
Case study company A is a small payment service provider from Germany offering various IT-based services for handling payment transactions for small and mediumsized banks. The company was among the first in Germany to offer support for instant payment transactions (IPT). Today it normally takes one business day for a payment to reach the beneficiary, but instant payments realize this in close to real-time (i.e., within less than 10 seconds). This is independent of the underlying payment instrument used (credit transfer, direct debit or payment card) and clearing (bilateral interbank clearing or clearing via infrastructures) or settlement (e.g. with guarantees or in real time).
Instant payment solutions usually consist of the scheme layer (end-user solutions for the market), clearing layer (arrangements for clearing of transactions between payment service providers) and settlement layer (arrangements for settlement of transactions). Company A provides clearing layer and settlement layer functions in combination with value-added services, such as fraud detection, sanction screening and embargo checking. The case considered in this paper emerged when the company decided to explore possibilities of AI use in IPT handling
After a requirements analysis, the case study company performed a feasibility study
that investigated different AI approaches for detecting fraudulent transactions [
In the information architecture, focus was on identifying what information required for the fraud detection already is available (and what applications or services in the application architecture provide or consume this information) and, more important, what information is missing. Here, the required information for fraud detection is spread onto different data sources (payment monitoring system, core banking system, customer transaction history). With this distribution onto different data sources, an integrated data set has to be created to allow for a performant implementation of the AI solution. Integrating data “on the fly” would require too much time and disturb the other application using the same data.
In the application and technology architecture, the applications affected by a new AI solution, either because they have to provide data or because they receive the AI solution’s results, were identified. Furthermore, the technology currently used indicated constraints for the future AI solutions with respect to physical location of data storages and technical architecture of the services used.
Figure 1 shows an excerpt of the architecture model for case A with focus on investigation of suspicious transactions. 4.2
Case study Company B is content-marketing enterprise specialized in the creation and distribution of online-videos, and in using these videos for marketing purposes. This company aims at new business models exploiting the possibility to create interaction with the users and new innovative media formats. In particular, free online videos have a high reach in the advertising-relevant target group. Such videos contain several scenes and show mostly fashion-related content applicable for content-related advertising. For example. if a video shows a close-up of a male face wearing sunglasses, advertisements should be placed for these glasses. Knowing what kind of object is shown in the video therefore is crucial for the service. Traditionally, the objects in videos were identified by manual “tagging” of the videos. This approach is labor-intensive and difficult to scale up due to the need to hire and train the workforce. Automatic image detection technologies can enable more efficient and cost-effective operation.
The case study company started to develop an innovative technological approach by combining a technique from the symbolic and approximate sub-disciplines of AI research. The aim is to apply knowledge captured in an ontology to improve the process of object recognition in videos, which is based on an artificial neural network (ANN) and a deep-learning approach. The ontology is supposed to capture the relevant knowledge for the application field of discovering fashion items in videos. This knowledge includes, for example, a taxonomy of fashion items, environments suitable for specific fashion categories (mountain, skiing, outdoor), social contexts relevant for fashion categories (weddings, parties), and more. Furthermore, the ontology also is used to capture combinations of fashion items relevant for defined marketing purposes, like, for example, the fashion for a particular target group. For each concept in the ontology, there is a corresponding classification model in the deep learning part of the system. This part consists of the Deep Learning Management software component providing access to the ANN Database containing available models.
From an organizational perspective, both the maintenance of the ontology, the continued training of the deep learning module, the integration of the automatic tagging into existing processes and the development of new business services based on this platform had to accompany the implementation of the above AI solution. From a technical perspective, the key task was the integration with the existing marketing and content distribution engine, which also includes customer profiles, campaign management and advertisements. 5 5.1
Complexity has been subject of research since several decades. In information
systems research, many scholars consider research on system complexity as more
important than algorithmic or algebraic complexity. In his well-received discussion of
hierarchy, Simon defined 1962 a complex system as a system consisting of a large
number of parts that have many interactions [
For investigating changes in complexity caused by the introduction of AI in the cases studies, an operationalization of complexity is required. For this purpose, we consider existing operationalizations for project complexity and product complexity as in particular interesting. Project complexity addresses aspects of interaction of stakeholder and processes related to the business architecture and product complexity parts and variations of a product which is related to digital systems as “products” and their application architecture.
A review regarding the concept of project complexity performed by Baccarini [
Using the indicators proposed by Baccarini and Hobday (see section 5.1), we analysed the cases in section 4 regarding the changes implemented during the introduction of AI. The result is summarized in table 2.
Judging from the “increase” in most indicators presented in table 1 for both cases, we have reason to believe that there is confirmation for an increase in complexity. As this concerns the business and application architecture, we argue that this concerns the overall EA complexity. A possible explanation might be that both cases were finished not too long ago and that a consolidation of the enterprise architecture is required that integrates and optimizes inefficient components. This requires further investigation. Degree of customization Intensity of supplier involvement Business Pro- Increase: fraud detection processes affected cess with interface to IP trans
action handling Application Architecture Sub-systems Increase: AI sub-system, new and components data extraction and integration system No change regarding the established IT sub-systems No change (after finishing the AI project)
Increase: new processes for the new roles (see above) and their interface to existing sales and operations processes Increase: two AI sub-systems; new services for situation detection and contextualization No change regarding the established IT sub-systems Increase: supplier of ML component continues to render services 6
Enterprise Architecture Management (EAM) defines today with frameworks,
standards, tools and practical expertise a large set of different views and perspectives. We
argue that a new complexity-focused digital enterprise architecture approach should
better enable the digitalization of adaptive intelligent products and services. DEA –
Digital Enterprise Architecture Reference Cube (Fig. 2) is our current extended
architectural reference model from [
DEA - Digital Enterprise Architecture Reference Cube provides our comprehensive architectural reference model to integrate in a bottom-up manner dynamically composed micro-granular architectural services and their models for supporting intelligent digital services and products. We have extended our service-oriented enterprise architecture reference model for the evolving digital transformation context by micro-granular structures, like the Internet of Things, and Microservices. Further, we have associated multi-perspective architectural decision models, which are supported by viewpoints and functions of an architecture management cockpit.
Fig. 2. Digital Enterprise Architecture Reference Cube
Digital enterprise architecture should be both holistic and easily adaptable to support micro-granular structures like IoT and the digital transformation with new business models and technologies, like social software, big data, services computing with cloud computing, mobility platforms and systems, security systems, and semantics support.
DEA is more specific than existing architectural standards of EAM – Enterprise Architecture Management and extends these architectural standards for digital enterprise architectures with services and cloud computing. DEA provides a holistic classification model with ten integral architectural domains. These architectural domains cover specific architectural viewpoint descriptions in accordance to the orthogonal dimensions of both architectural layers and architectural aspects. DEA abstracts from a concrete business scenario or technologies, but it is applicable for concrete architectural instantiations to support digital transformations.
Metamodels and their architectural data are the core part of the digitization architecture. Architecture metamodels should support analytics-based architectural decision management and the strategic as well as IT/business alignment. Three quality perspectives are important for an adequate IT/business alignment and are differentiated as: (I) IT system qualities: performance, interoperability, availability, usability, accuracy, maintainability, and suitability; (II) business qualities: flexibility, efficiency, effectiveness, integration and coordination, decision support, control and follow up, and organizational culture; and finally (III) governance qualities: plan and organize, acquire and implement deliver and support, monitor and evaluate.
DEA abstracts from a particular business scenario or technology because it can be applied to concrete architecture instantiations to support digital transformations independently of different domains. The DEA reference cube covers the top of the Platform and Ecosystem Architecture. A digital platform is in our understanding a repository of business, data, and infrastructure services used to configure digital offerings from digital services rapidly. Digital Services and components are slices of code that perform a specific task. We position reusable digital services as parts of an ecosystem of services. A digital platform linearizes the complexity of cooperating services. It integrates core technology services to provide standardized access points and repositories for an intelligent service ecosystem of business services, data services, and infrastructure services. The value of a platform to users results from the number of platform and service users. A digital platform and an ecosystem should enable shared value creation for all stakeholders and facilitate the exchange of goods, services, and social currency. Platforms do not own or control their resources and are therefore well suited for scalability within the ecosystem. 7
Based on established definitions of complexity, in particular from project and product management, the paper investigated possible changes in complexity when AI functionality was added to business services and enterprise architecture. The investigated cases confirm our conjecture that the EA grows more complex. However, due to the very small number of cases, more work is needed in this area. So far, we consider our results only as a confirmation of the problem relevance.
One of the building blocks for methodical support to managing complexity is – to our opinion – the use of EAM and the differentiation into different perspectives as presented in section 6 when discussing the extended version of the Enterprise Architecture Reference Cube.
Future work will have to include the investigation of more cases to more clearly define requirements to the methodical support. Furthermore, the overall DSR process described in section 2 has to be continued by clarifying root causes and designing an initial method proposal.