Dual Capability EAM for Agility in Business Capability Building : A Systems Theoretical View

This is a self-archived version of an original article. This version may differ from the original in pagination and typographic details. Author(s): Title: Year: Version: Copyright: Rights: Rights url: Please cite the original version: CC BY-NC-ND 4.0 https://creativecommons.org/licenses/by-nc-nd/4.0/ Dual Capability EAM for Agility in Business Capability Building : A Systems Theoretical View © 2021 SCITEPRESS Accepted version (Final draft) Poutanen, Jouko; Pulkkinen, Mirja Poutanen, J., & Pulkkinen, M. (2021). Dual Capability EAM for Agility in Business Capability Building : A Systems Theoretical View. In J. Filipe, M. Smialek, A. Brodsky, & S. Hammoudi (Eds.), ICEIS 2021 : Proceedings of the 23rd International Conference on Enterprise Information Systems. Volume 2 (pp. 726-734). SCITEPRESS Science And Technology Publications. https://doi.org/10.5220/0010455007260734 2021 Dual capability EAM for agility in business capability building: A systems theoretical view Jouko Poutanen, Mirja Pulkkinen a Faculty of Information Technology, University of Jyvaskyla, Finland [email protected], [email protected] Keywords: Enterprise Architecture Management; Complex Adaptive Systems; Business Agility, dual capability EAM Abstract: Through two cases of IT-enabled business capability building in large enterprises, this paper elucidates how the systems theory approach can explain the enterprise architecture management (EAM) challenge to support business agility. The observation in both of these cases is that a legacy EAM approach does not adapt to a business development scenario involving agility. This leads to a study of the nature of the challenges in EAM when enabling strategic business moves involving new technologies, at the business unit level. For the type of projects as in these cases, we do not find a fitting paradigm in the EAM literature. Suggested solutions are IT bimodality, or Two Speed IT. However, its combination with EAM is scarce in earlier research. To be able to provide guiding ideas for the further development of a dual capability EAM approach, with an evident need, we develop a systems theoretical starting point to examine the cases. Complex Adaptive System (CAS) characteristics appear to give the necessary explanations to build on. Supported by this theoretical development, the study results in principles of a dual capability EAM, for agile strategic business capability building involving enterprise re-structuring. 1. INTRODUCTION As enterprises see dazzling business opportunities with new technologies, they face governance challenges in the areas of e.g. risk and security management. IT Governance as the broadly accepted, value based approach (Op’t Land et al. 2008), with Enterprise Architecture Management (EAM) as a tool, points to the need to consider the value of any IT investment for the enterprise, as well as direct and monitor the planning and implementation of the induced business change. This requires a balanced development at the corporate level, as opposed to individual business units developing their specific solutions and running the risk of partial optimization, potentially even counterproductive to the corporate goals (Ahlemann et al. 2012, Peterson 2004). The EAM process, supporting the goal of circumspect decision making, joins the technological viewpoint to the business goals. If a novel IT solution needs integration to the existing architectures, engaging the corporate IT function is necessary, and their responsibility continues with the planning and executing of the operation, support and maintenance a https://orcid.org/0000-0002-5313-8666 of the new system. However, the corporate IT and EAM aiming at the alignment of business and IT developments with an architectural approach (Ahlemann et al. 2012) can be questioned as a “legacy” approach, with “bureaucratic” governance models hampering agile development both for the business and for IT (Drews et al. 2017). Therefore, EAM practices might need a revision for cases of agile IT-driven business unit level development, enabling the swift seizing of new digital business opportunities. In their covering review of organizational (business and IT) agility, Tallon et al. (2019) give a thorough understanding of the complexity of the problem. While capability building and the dynamic capabilities dominate as theoretical stance, with some, the question of architectural modularity (Tiwana and Konsynski 2010) and decision rights Tiwana and Kim (2015) point to similar observations as are triggering our interest in this study, especially the co-location of knowledge and the decision rights pointed out in Tiwana and Kim (2015). Research has evidenced the IT corporate functions transforming to Bi-modal or two-speed IT (Haffke et al. 2017; Horlach et al, 2016). In academia, the term ambidexterity has been coined for the dual IT function capability (Lee et al. 2015). An IT unit with this double approach serves the business not only with agile development, but also with new culturechanging approaches, as DevOps, further joined with the business developers to BizDevOps (Gruhn et al. 2015). The duality means also ensuring sustained support for balanced long-term planning and governance with risk management at various levels. A ‘fast IT’, however, is a solution only where the developments are conducted in-house, with the enterprise IT resources. In our case study, we observe the need for a business agility, where IT solutions new to both the business and the IT in the enterprises are a strategic choice as new business capability enablers. Both cases, however, see a corporate strategy requiring an assured and well managed EA as well. As not all of the development resource is coming from in-house, a re-organization of the IT function alone is not solving our case problem. The more pertinent question is, how to enable similar, agile strategic moves in future, as the present EAM approach, in these enterprises and in general, appears not to tackle the situation. The question for this study is: RQ How can EAM support business capability development in an agile manner, when it involves the building of a new system and a new unit, changing the enterprise structure? To understand the managerial challenge, on both the business and the IT side, and to propose a solution for these cases, we look at potential theoretical explanations. Already existing solutions are screened in a literature review for Enterprise Architecture Management and Bimodal or Two Speed IT. Dealing with a complex setting with business systems embedded in an environment of an enterprise as a system of systems, we propose a systems theoretic explanation for the situation at hand in Section 2, and discuss the EAM role. In section 3, we describe two cases of new technology induced business development, and present an analysis in Section 4. We reflect the analysis to EAM in section 5. As a result, we propose guidelines for a business agility enabling, dual capability EAM in Section 6. 1.1 Earlier Studies For the literature review, conducted in early 2019, we first checked both the IEEE Xplore portal and Google Scholar and used the search strings i)“’Bimodal IT’ AND ‘Enterprise Architecture Management’”, and ii)“’Two Speed IT’ AND ‘Enterprise Architecture Management’”. As IEEEXplore did not yield results, Google Scholar attains broader coverage for this rather novel area. A further gain is to find non-published scholarly work such as theses. The results with the two search strings respectively yielded eight and nine hits, and after deleting overlaps in the two sets, plus excluding work not written in English, the following items remain: • Three MSc Theses: (Boekholtz 2017; Schmid 2018; Natalucci & Manzotti 2016), the last one with a generic stance on digitalization. • A dissertation (Andersen 2016), focusing on the technology dimension of EA, • Four scholarly peer-reviewed articles (Drews et al. 2017; Fortmann et al. 2019; Keller et al. 2018; Legner et al. 2017). • Further three articles, published for another field of research, appeared to be not in the scope. The search was not limited with time of publication meaning that this topic only has emerged. Three empirical studies, (Drews et al. 2017; Keller et al. 2018; Legner et al. 2017) present elaborations of the problem area. However, first of them, as also the MSc theses, present digital-only business cases in the sector in the front-line of digitalization: banking and financial. Another paper (Fortmann et al. 2019) studies the developments over time within an IT unit in a digitalization case, and Keller et al. (2018) collect general practitioner knowledge from IT-departments. Our study, on its part, investigates two cases where a digital tool or a new service is only a part of the business portfolio in a non-digital business, and we go beyond the studies of the IT department/IT function. The technologies (AI and IoT) are novel to the enterprises, both profiling as latecomer digitalisers (Kohli et al. 2011). For both, the project means new business capability development. At the same time, due to the development project, our cases present enterprises with a challenge in the IT governance de-/centralization question (Peterson 2004), and also defining the role of their EAM team as part of the governance. The involvement of the IT function during development projects low, thus not suggesting that a dual capability or multimodal IT function would solve all of the problem. Further, the solutions are not built on systems already operated on, so DevOps, or BizDevOps although interesting approaches, are not a fitting paradigm. 2. KEY CONCEPTS 2.1 Enterprises as Systems of Systems Beyond the practical solutions, as introducing agility to the organization of the IT function (e.g. Haffke et al. 2017), and methods for agile development, also extended to EA (e.g. Drews et al. 2017), more fundamental questions of the problem field of EAM have been presented (Abraham et al. 2013; Buckl et al. 2009). To solve the problem of the controversial roles of EA or EA management: An enabler of agility on one hand, however, on the other, questioned as a ‘bureaucratic’ and therefore slow approach, we study the underlying controversy by examining the systems nature of enterprises. The cases we study show the need for an architectural governance to comply with the ITG and corporate governance, but on the other hand, also the urgency to rapidly respond to the business environment change involving technology. The latter is as compelling from the business side by corporate governance, to sustain and improve the value creation in the enterprise. Systems theories give a widely embraced even though not fully utilized theoretical scheme, underlying the EA field, as a recent review finds (Niemi et al. 2018). Figure 1 presents a simple sketch of the interacting systems in a system of systems, as an enterprise can be analytically seen. We lean on the main idea in the General Systems Theory (GST) and Living Systems Theory (LST), both proposing hierarchical levels of systems complexity (Abraham et al. 2013; Nurmi et al. 2018). Within the enterprise, comprising a large complex, adaptive system (CAS) (Janssen & Kuk 2016), there are both fully manageable, predictable technical sub-systems, some more complex socio-technical sub-systems, as well as adaptive sub-systems (where the decision freedom is given by the system-of-systems management system, controlling the systems/sub-systems within the enterprise). A CAS is capable of directing and redirecting their actions and resources at their disposal, according to the signals they perceive from their environment. The new business capability (that also can be perceived a new “socio-technical” system), forms a sub-sub-system under the auspices of a subCAS. Its ownership is normally with a business unit (the sub-CAS), the whole enterprise thus seen as a CAS-of-CASs. In a similar vein, Abraham et al. (2013) have introduced enterprises as “hierarchical, multilevel systems”, however, leaving the adaptiveness aspect for further study. Capability as an “ability to execute a defined and repeatable pattern of activities” to produce a targeted outcome in a given environment, has been found a practicable unit for analysing the business architecture as part of EA (Simon et al. 2014). A business capability entails the respective processes, entities, organizations, people, culture, and resources needed to successfully perform an activity for its targeted business outcome. A business capability can be dependent on IT (IT-enabled), or improved by IT (IT-enhanced). Figure 2: Enterprise as a collection of multiple, multi-level systems at different levels of complexity The concept of capability, however, highlights the need for an “ensemble of resources” for building a ‘socio-technical system’ from the ‘technical system’ with the business resources before it can perform. Where there are resources, there is also ownership, management and decision making power. The decision making levels (Pulkkinen 2006; Pulkkinen & Hirvonen 2005) as well as the systems theories analytically presenting them (Abraham et al. 2013); have been a subject of study in EAM. We see that an evolutive, explorative EAM that allows for piloting solutions at the business unit level (a.k.a EA segment, or domain; see Bruls et al. 2010; Pulkkinen 2006) is a question of an instance of systems evolution, inducing the re-structuring of the (sub-) systems within the enterprise. Importantly, the units of the enterprise use their domain knowledge (Tiwana and Kim 2015), both in capturing and interpreting signals urging for response from their environment in environmental scan (Tallon et al. 2019), introducing the selforganising trait of CAS. As essential is also the internal domain knowledge, also of the existing IT resources, managed with EA. This is needed for the planning and enacting the change in the systems to respond, even proactively, to the environment pressures, as the emergence trait in CAS: Adapting (sub)systems to the business environment changes. 2.2 Enterprise Architecture Management Reflecting on the theoretical frame in Figure 1, the role of EAM is to attain awareness, assurance and alignment, across all the systems, as well as the need for analytical tools and planning aid (Ahlemann et al. 2012, Doucet et al. 2009; Aier et al. 2009). This is needed for the IT (technical systems), together with the business management and governance (Ahlemann et al. 2012). The development of new capabilities requires awareness of the existing IT (and other) resources and architectures, as well as the alignment of goals and resources. Analysis of both business and IT architectures, and support for planning as the EA techniques does, can support agility in capability building and re-building (Pulkkinen & Hirvonen 2005). Methods for agile EA development (Boekholtz 2017, Bente et al. 2012) however, do not guide in developing a managerial system for oversight and control (EAM). The EAM as a tool of ITG for both exploitation and exploration should possess mechanisms that allow it to put resources in conducting the environmental scan and subsequently, to plan and implement change as needed, however, backed up with the corporate EA principles to ensure compliance, interoperability and balance. The EAM is to be equipped for firstly, enabling the architectural flexibility needed, secondly, the re-structuring of the systems, even reflecting to enterprise structures if needed after new system implementation. 3. CASE STUDY Our two cases faced a common problem, although fundamentally different: “Alpha” is a large public agency, “Beta” a private corporation. A strategic choice in both is, to develop a new business capability with a technology new to the enterprise, the corporate IT and the business units. The strategic intent entails a fast move. Alpha is building a virtual customer service assistant leveraging AI, and aims at a ‘first mover’ advantage with this technology. Beta implements a new business service concept applying IoT, to support the users of their physical technologyintensive product customers. Both organizations have a corporate IT department, with an associated EAM function to guide enterprise IT developments. In both cases alike, a business function specific goal, sensed at the level of the function management, triggers a new business capability development. The business function level technology scan (although not officially assigned to do this!) in both cases spotted new technology enablers (AI, IoT) on the market, not currently used in their organization. For a rapid strategic move, building a new IT capability within their corporate IT units required for AI/IoT would take too much time and is therefore rejected in both cases. The transforming of the IT unit to bimodality would not solve the problem. The EAM, on its part, is to ensure compliance and risk management as the new technological capability enablers are integrated into the enterprise IT architectures. Table 1 The data for the qualitative analysis Data sources available Case Alpha Case Beta Strategy and plans Yes Yes Organizational guidelines & standards (documents) 5 4 Project plan Yes Yes Number of design workshops (1-2 hours each) 21 18 Number of workshop participants from organization 5-6 2-11 Research method. The research data (see Table 1 above) used for the qualitative content analysis refers to the work documents, interviews and workshops during case projects. The first author was observing the cases during the project lifetime: Alpha 6 months, Beta 12 months. The workshop participants were business process owners, and members of LoBs, business development and IT departments. 4. CASE ANALYSIS As seen in Table 2, both cases examined involve the implementation of the organization strategy. However, the scanning and sensing that triggers the development comes from a lower echelon. The urgency element in both points to business agility. Initiative ownership: The lead in the explorative development is with the line of business (LoB). They have the required knowledge of the customer needs and a vision of the new service, i.e. the understanding what the technology can do for the business. The LoB is also responsible of the end result: In case Alpha, an improved customer service, and for Beta, a new revenue creating after-sales service. The LoB as a decision unit needs to have the necessary decision freedom for the evolution of the systems it has ownership on. Pointing to a business capability perspective, it was crucial to approach the development from the customer and process perspective, i.e. including all business capability elements, identifying new processes and roles, finally creating an emerging socio-technical system. Automated service requires a new level of understanding the customer needs. The AI components and content management require new tasks, skills and tooling. Especially, for the AI solution, managing the corpus and the ground truth training and testing were novel additions to Alpha capabilities. Role of EA: The value of quality EA artefacts is evident in providing the context and the new solution content, as well as understanding the effect on existing processes. In case Alpha, EA provided the necessary understanding of the context of the piloted solution and was the basis for the design of the to-be architecture. In case Beta, it provided the information Table 2 The Case Analysis: The Emerging of a New Capability as a Sub-Subsystem Case attribute Alpha Beta 1 Business driver Strategy deployment, customer service improvement Strategy deployment, growth generation 2 Capability developed New AI-based virtual assistant service channel for customers New business concept: After-sales product service with IoT support 3 Business goals Service quality improvement Cost savings First agency to deploy AI New revenue from novel service business Customer commitment to product 4 Key technological goal to develop enterprise IT AI adoption in a pilot service area for further deployment IoT platform deployment Sensor data analytics adoption 5 Initiative and project ownership Customer Service Development Unit – to be handed over to customer channel management Business Development Unit – to be handed over to a new unit 6 Novelty of the solution High (no prior AI implementations) High (no prior implementations or IoT / SDA) 7 Type of solution Pilot implementation Production quality Table 3 The role of EAM prior to the project Role of EAM Alpha Beta Focus of the EAM team Business systems, Administrative systems Administrative systems EAM role in the project Informed Consulted Perceived role of EAM Slow, no value Slow, limited value EAM role in postimplementation phase Standardization of the solution Created EA knowledge retention Standardization of the solution Created EA knowledge retention Case attribute Alpha Beta Business driver Strategy deployment, customer service improvement Strategy deployment, growth generation Capability developed New service channel for customer service New business concept (After-sales product support service) of the integration requirements and data models. In both cases, the solution architecture will evolve to be part of the new business and IT architectures. Role of EAM initially (depicted in Table 3) evolves to enabling the technology transfer to diffuse the solution in the organization, supporting to generalize it for other use cases. The legacy role of the EAM team, a ‘regulatory’ one as perceived in both cases in the beginning, is therefore challenged. EAM is extended to a supportive role for business and systems evolution. Traditionally, EAM in general has a role to control and ensure conformity with standards. For fast progress, sourcing must be extended beyond own resources. In the case of novel technology, an organization might not have the requisite IT knowledge, neither time to develop it. Sourcing management can be supported by EAM as well. Finally, incorporating the results and the new knowledge to the EA for further use is, however, essential. In agile business development situations, EA is a tool for an agile but balanced management, with sound but flexible, dual capability EAM. The EAM may have a consultative role during the development, or take on only afterwards. After the project, the EAM team retains architectural knowledge and manages the further deployment of the developed solutions. Both cases highlight the task of EAM to maintain and update the EA related information (as an example of “cartography”, [32]) for further developments. From a CAS point of view, the EAM supports the emergence of the novel socio-technical system, isolated for development time and afterwards being adjusted into the new EA baseline, and a new organization structure emerging with the development. We discuss this next. 5. DISCUSSION Enterprise Architecture and EA management relate to the systems nature of enterprises (Abraham et al. 2013). For EAM, earlier studies suggest explaining models (Abraham et al. 2013; Buckl et al. 2009) but focusing on the EAM itself, leaving the enterprise as a system of systems in the background. Theoretical explanations give an analytical tool to understand the problem field and further consequences: We looked at the research question: How can EAM support business capability development in an agile manner, when it involves the building of a new system and a new unit, changing the enterprise structure? The point of view of the EAM is an embedded governance system for the system of systems. Looking at the cases, we see that the incurring phenomena can be explained as a “systemic evolution” of the enterprise as a system of systems. Itself being a CAS (of CASs), the enterprise contains a number of sub-CASs. The focal point in our study are the business line management in charge of business performance on their own area, thus in charge of a sub-CAS. Within the decision freedom given in the enterprise strategy they develop the LoB strategically. Potential changes in the decision making structures, and the re-structuring of the units is a delicate matter, also in the case of the new capability building. As new managerial tasks and roles may open with the new business capability, and the re-organization of the units may be necessary, a negative development may follow in other parts. This calls for enabling the evolution and the birth of a new sub-CAS (a unit) on one hand (self-organising and emergence characteristic of CAS), and on the other hand, the revision of the enterprise structures and lines of decision making, as needed. IT developments normally are monitored by the EAM function to deploy the current enterprise strategy (from the point of view of the business), and to follow the set EA principles and standards (from the IT managerial viewpoint). The monitoring and control of compliance requires formal processes, takes time, and introduces rigidity to development projects. A pilot project means experimental learning, and the strategic choice in our cases was to leave the development into the hands of the LoBs (in both cases running a temporary project organization). In this situation, i.e. an organizational change (organizational re-design), an interim, developmenttime structure (Pulkkinen 2006) is keeping the project as a “development time EA segment” (or domain), managed by the temporary team that is developing the new capability. For development time, it is isolated from the rest of the enterprise structures and EA. The team engages both enterprise and outsourced capacities (provider experts). This enables the new capability building and testing prior to integrating it to the rest of the enterprise and its EA, as well as a managed transition to a new organizational structure. This provides a method to implement emergent behaviour of a CAS in a controlled manner. For the IT organization and EAM, in both cases, the solution of choice was not to establish a new “agile IT” unit, with, or without EAM, but to employ resources as needed, which resembles more the BizDevOps –type (Gruhn et al. 2015) of organizing in a temporary team. However, the DevOps mode was not a possibility, since there were no system operators to be involved, as the development was not on existing systems. The developers were to a large extent hired. The enterprise strategic management supports in both cases the agile piloting, justified by the import of knowledge (use of IT providers) to inject knowledge and to foster organizational learning and development, since the strategy sees for further deployment of the chosen technology. The organization and EA design created in the development domain can be captured as a new version of segment business architecture and, with the knowledge created in the pilot project, replicated as reference architecture to other segments of this enterprise for their capability development. As to the explaining theories, changes in the EA segment structures mean that the systems structure of the enterprise evolves. New technology is the core technical system, entailing a new socio-technical system to emerge, with among other things a new business process to be designed as the core of a new capability to be established. New EA segment structure means evolution of the sub-CASs within the enterprise. The starting point of an evolution step can be a sub-CAS (a business unit) perceiving itself urging signals from its environment, and – with the management system, i.e. the top echelon, allowing – can act upon them, finally leading to modifications, or “systemic evolution”, in the structure of sub-CASs within the enterprise. The signal triggering a new capability development arises from the business environment. For the enterprise governance, it may be not clear which LoBs are affected. For a given signal, the LoB whose domain knowledge understands the use case best, is also familiar with the specific requirements, such as legislation and industry standards. The selforganizing behaviour according to the theory on CAS is enabled by the flexible EAM, that considers both the potential in achieving goals (i.e. business performance) and the risks involved. In addition, when the LoB is allowed to innovate, new useful patterns might emerge, that are not part of the current EA (requisite variety), but can be potentially useful for further units in the enterprise. This is one of the known benefits of a managed EA, and the segmentation of EA as an aspect of it, allowing for agile piloting – a capacity of the EA with defined segments. 6. CONCLUSIONS Concluding from the observations and their analysis, an emergent model of a dual capability EAM for building new capabilities can be summarized as follows:  After consideration of business potential and risk, a temporary team is formed, led by the LoB that owns the case (as a self-organizing CAS)  Representatives from the affected LoBs (coevolution) are engaged in the team, and the requisite architectural and technical skills are ensured with a necessary level of outsourcing.  The context of the solution is studied, reflecting on the current EA, necessarily including the business architecture.  The scope of the pilot is reduced to cover only the novel elements, as a developmenttime EA segment. For technology development, a temporary development environment is created; Cloud and virtualization technologies are the agility enablers here.  During the experimentation phase, necessary changes to the business processes, ownerships (“decision unit”) and roles are designed and assigned, or at least drafted. This means a re-writing of parts of the business architecture, forming also the new or modified EA-segmenting structures: The new organization.  At the IT architecture level, the required systems integrations at all levels of systems and the constraints like standards to be applied are identified  Work and progress are measured with minimized management and EAM control.  The viability of the solution and the proposed value is evaluated during and at the end of the project.  If the outcome is positive and value-forbusiness can created, the solution will be consolidated, and it will be standardized with the help of the EAM team for replication in further segments with similar use cases. This brings in the more traditional EAM role to ensure coherency and consistency over the whole enterprise IT. IT is in both cases a trigger for the strategic development case, leading to changes in the business portfolios, business architecture structures, roles and responsibilities, and finally potentially the decision units, i.e. enterprise structure. Inducing this type of organizational change is difficult, and the temporarily isolated development time segment could give the enterprise change management the necessary space and time for adjustments. Thus the EAM allowing for the development-time segment enables a smooth transition, to the use of a new operational technical system, as well as an emerging operational sociotechnical system. Different from earlier cases we do not suggest a permanent “fast IT EAM” to enable emergent capability development. Potentially, with time, such team also runs into similar problems as pointed out with the bimodality of IT (Haffke et al. 2017). Instead, the existing EAM provisions EA information (baseline), and enables the work of the temporary team resourced with EA skills. The use of a temporary team forms the core of this dual EAM capability. After the project, the stabilization and standardisation of the solutions are given over to the EAM team. Both cases concerned building novel capabilities that have clear and limited integration points to the existing architecture. When upgrading existing systems, the effort could be more demanding, due to existing interconnections between system elements. The dependencies would limit the freedom. With only two cases in study, the generalizability of the result might be limited. On the other hand, the organizations were fundamentally different: Their ownership (public / private), the nature of their business (service / manufacturing). Also, the solutions used different technology (AI / IoT). In spite of these differences, the new technology project organization and extending the role of EAM to a dual capability approach in it were similar. Further study is needed, if e.g. the novel solution would be more interconnected within its context, and of course with further types of organizations. REFERENCES Abraham, R., Tribolet, J., Winter, R., Transformation of Multi-level Systems – Theoretical Grounding and Consequences for Enterprise Architecture Management, in: Proper, H., Aveiro, D., Gaaloul, K. (Eds.), Advances in Enterprise Engineering VII, Springer Berlin Heidelberg, 2013, pp. 73-87., http://dx.doi.org/10.1007/978-3-642-38117-1_6 Ahlemann, F., Stettiner, E., Messerschmidt, M., & Legner, C. (Eds.). (2012). Strategic en-terprise architecture management: challenges, best practices, and future developments. Springer Science & Business Media. Aier, S., Kurpjuweit, S., Saat, J., & Winter, R. (2009). Enterprise architecture design as an engineering discipline. AIS Transactions on Enterprise Systems, 1(1), 36-43. Andersen, P. (2016). Managing the IT Architecture: A Multiple Case Study (Doctoral dissertation, Aarhus University). Boekholtz, V. C. M. (2017). Improving Enterprise Architecture at Agile Working Financial Organisations (Master's thesis). Utrecht University the Netherlands Bente, S., Bombosch, U., & Langade, S. (2012). Collaborative enterprise architecture: enriching EA with lean, agile, and enterprise 2.0 practices. Newnes. Bruls, W. A., van Steenbergen, M., Foorthuis, R., Bos, R., & Brinkkemper, S. (2010). Domain architectures as an instrument to refine enterprise architecture. CAIS, 27, 27. Buckl, S., Matthes, F., & Schweda, C. M. (2009, October). A viable system perspective on enterprise architecture management. In 2009 IEEE International Conference on Systems, Man and Cybernetics (pp. 1483-1488). IEEE. Doucet, G., Gøtze, J., Saha, P., & Bernard, S. A. (2009). Coherency management: Using enterprise architecture for alignment, agility, and assurance. Journal of Enterprise Architecture, 4(2). Drews, P., Schirmer, I., Horlach, B., & Tekaat, C. (2017, October). Bimodal enterprise architecture management: The emergence of a New EAM function for a BizDevOps-based fast IT. In 2017 IEEE 21st International Enterprise Distributed Object Computing Workshop (EDOCW) (pp. 57-64). IEEE. Fortmann, L., Haffke, I., & Benlian, A. (2019). Navigating Through Digital Transformation Using Bimodal IT: How Changing IT Organizations Facilitates the Digital Transformation Journey at Deutsche Bahn Vertrieb GmbH. In Digitalization Cases (pp. 393-410). Springer, Cham. Eisenhardt, K. M., & Graebner, M. E. (2007). Theory building from cases: Opportunities and challenges. Academy of management journal, 50(1), 25-32. Gruhn, V., & Schäfer, C. (2015, September). BizDevOps: because DevOps is not the end of the story. In International Conference on Intelligent Software Methodologies, Tools, and Techniques (pp. 388-398). Springer, Cham. Haffke, I., Kalgovas, B., & Benlian, A. (2017). Options for Transforming the IT Function Using Bimodal IT. MIS Quarterly Executive, 16(2). Horlach, B., Drews, P., & Schirmer, I. (2016). Bimodal IT: Business-IT alignment in the age of digital transformation. Multikonferenz Wirtschaftsinformatik (MKWI), 1417-1428. Janssen, M., Kuk, G. (2006) A Complex Adaptive System Perspective of Enterprise Archi-tecture in Electronic Government, Proceedings of the 39th Hawaii International Conference on System Sciences. Keller, T., Baumgartner, T., & Brucker-Kley, E. (2018). Towards a multi-modal IT. e-Society 2018, 209. Kohli, R., & Johnson, S. (2011). Digital Transformation in Latecomer Industries: CIO and CEO Leadership Lessons from Encana Oil & Gas (USA) Inc. MIS Quarterly Executive, 10(4).