Business Information Technology

An Enterprise Architecture Framework for

Digital Transformation

Master Thesis
Validation case: The European IT division initiative for Data and Analytics at Apollo
Verdestein B.V.

Daniel F. Rozo

Supervisors:
DR. IR. M.J. VAN SINDEREN
Faculty of Electrical Engineering, Mathematics and Computer Science
Department of Services, Cyber security & Safety
University of Twente

DR. A.I. ALDEA

Faculty of Behavioural Management & Social sciences
Department of Industrial Engineering and Business Information Systems
University of Twente

DR. J. L. MOREIRA
Faculty of Electrical Engineering, Mathematics and Computer Science
Department of Services, Cyber security & Safety
University of Twente

R. Jeurink
Head of IT Europe
Apollo Vredestein B.V.

J. Lopes
Manager Service Delivery
Apollo Vredestein B.V.
Daniel Felipe Rozo Carreño

Student number: s2099802

E-mail: d.f.rozocarreno@student.utwente.nl
Master Thesis: An Enterprise Architecture Framework for Digital Transformation
Master of Business Information Technology: IT Management & Enterprise Architecture
Date: August, 2020

Supervisors

Dr. Ir. M.J. Van Sinderen – University of Twente

Dr. A.I. Aldea – University of Twente
Dr. J.L. Moreira – University of Twente
R. Jeurink – Apollo Vredestein B.V.
J. Lopes – Apollo Vredestein B.V.

University of Twente

Business Information Technology

Faculty of Electrical Engineering, Mathematics and Computer Science
Drienerlolaan 5
7522NB Enschede, The Netherlands
Abstract
The Digital Transformation era has unlocked unique opportunities for organizations to disrupt
and innovate with new products and services by leveraging novel emerging technologies such as
mobile computing, big data analytics, cloud computing, and the internet of things. The range of
possibilities provided by Digital Transformations comes at the expense of constant change across
multiple levels of the enterprise including organizational structures, operational processes,
business strategies, and even corporate culture. In addition, highly competitive market conditions
introduced by the new digital era have forced organizations to react quicker than ever before,
pressuring organizations to employ faster learning cycles that translate into shorter time-to-
market strategies. Lastly, Digital Transformations revolutionize the way in which IT and
business units collaborate where extremely cohesive teams are expected to continuously innovate
and deliver solutions that result in enhanced customer journeys and experiences driven by new
corporate cultures.

Facing the challenges brought by the new digital era not only requires the adoption of emerging
technologies, but committing to best practices that allow organizations to execute successful
Digital Transformations. Conventionally, Enterprise Architecture has proven to be the discipline
that best provides a basis for highly integrated environments, that are responsive to change and
supportive in the delivery of the business strategy. However, organizations that have allocated
resources and great efforts to become truly digital, criticize the Enterprise Architecture practice
as it fails to grasp the fundamental concepts from the nature of Digital Transformations.
Certainly, such discontent has drawn attention to perform this research. In response to these
adversities, organizations must tackle these challenges systematically by embracing new or
enhanced approaches that enable them to stay ahead of the competition while keeping up the
pace of the new digital generation.

The main objective of this research is to design, validate, and evaluate an Enterprise Architecture
framework that stimulates business agility, simplifies architecture development, and promotes
collaboration across business and IT units in order to lead organizations to successful Digital
Transformations. To structure the research a Desing Science Research Methodology (DSRM) is
applied. Based on the results from performing a Systematic Literature Review in preparation for
this thesis and the examination of a case study of a well-known multinational company, the
Enterprise Architecture Framework for Digital Transformation is assembled and validated in the
context of the Data and Analytics initiative at Apollo Vredestein B.V. Furthermore, three expert
interviews carried out as part of the evaluation process corroborated that the effects produced by
the artifact satisfy the main research objective of this thesis. At the same time, a series of
improvements are suggested for the presented framework. Lastly, conclusions are drawn,
limitations are outlined and future research directions are provided.
i
Acknowledgements
“What seems to us as bitter trials are often blessings in disguise.” - Oscar Wilde

Deciding to leave my own country and start a new life in the Netherlands has been and will
always be one of the toughest challenges in my life. In the past two years, I have faced numerous
professional challenges and personal adversities that taught me the true value of patience,
perseverance, and determination. This thesis marks the last milestone of a successful two-year
journey to finally obtain a Master’s degree in Business Information Technology at the University
of Twente. I could not feel more grateful to life for the opportunity of accomplishing my goals
once more and giving me the strength to keep going after my dreams.

I would like to express my gratitude to Robert Jeurnik and Jorge Lopes from Apollo Vredestein
B.V. for their support, vote of confidence, and trusting me with this ambitious and visionary
project. Although the Covid-19 pandemic crisis did not allow us to work closer together, I
certainly enjoyed my time being part of this great company. I would also like to thank Shailender
Gupta from Apollo Tyres, India, for his professional contribution and valuable insights in the
area of Enterprise Reporting and Analytics. To the rest of the Europe IT team of Apollo
Vredestein B.V. thank you, I wish you all the best of luck in future endeavors.

I would like to thank my supervisors Dr. Ir. Marten Van Sinderen, Dr. João Moreira, and Dr.
Adina Aldea for their indications which were decisive for me to finish this report. The new ways
of working due to the Covid-19 outbreak were not an impediment for them to provide me with
crucial and accurate directions at every step of the way. To you, I express my most sincere
gratitude and appreciation for guiding me through this research project and devoting your careers
to indoctrinate the Business and IT professionals of the future.

My most sincere appreciation to Ann-Cathrin Iseke, thank you for believing in me and providing
me comfort when I needed it the most. Thank you for your kindness and companionship, you’ve
certainly become a very special person to me and I wish you success and the best of luck in all
your professional endeavors.

Last but not least, I would have not achieved anything in life if it wasn’t for the teachings and
support of my family. To my brother Andrés, my mother Stella and my father German, not a
single day goes by without feeling grateful for every lesson you have taught me, you are an
inspiration in everything I do. Starting a new life far away from home has been arduous,
complicated, and frustrating at times. Despite all of these adversities I always remember where I
come from and most importantly, that I can always count on you for the big and also for the
unfortunate moments. Thank you for everything you have done for me, this dissertation is
dedicated to you.
ii
Table of Contents
ABSTRACT .........................................................................................................................................................................................I

ACKNOWLEDGEMENTS ................................................................................................................................................................. II

TABLE OF CONTENTS....................................................................................................................................................................III

LIST OF FIGURES............................................................................................................................................................................ VI

LIST OF TABLES............................................................................................................................................................................ VII

ABBREVIATIONS ......................................................................................................................................................................... VIII

1. INTRODUCTION ...............................................................................................................................................................1
1.1 PROBLEM STATEMENT ....................................................................................................................................................................... 1
1.2 RESEARCH CONTEXT AND MOTIVATION ......................................................................................................................................... 2
1.3 RESEARCH OBJECTIVES ...................................................................................................................................................................... 4
1.4 RESEARCH METHODOLOGY AND THESIS STRUCTURE .................................................................................................................. 6
1.5 SYSTEMATIC LITERATURE REVIEW METHODOLOGY .................................................................................................................... 8
1.6 PRACTICAL AND SCIENTIFIC RELEVANCE ....................................................................................................................................... 9
1.6.1 Practical relevance ............................................................................................................................................................. 9
1.6.2 Scientific relevance........................................................................................................................................................... 10
2 PROBLEM INVESTIGATION ....................................................................................................................................... 11
2.1 BASIC DEFINITIONS AND KEY CONCEPTS .....................................................................................................................................11
2.1.1 Enterprise Architecture and Digital Transformation ........................................................................................ 11
2.1.2 Enterprise Architecture in practice ........................................................................................................................... 13
2.1.3 The Open Group Enterprise Architecture Framework ....................................................................................... 14
2.1.4 EA Modelling Support Tools and Notation ............................................................................................................. 17
2.1.4.1 The ArchiMate Language .......................................................................................................................................................... 17
2.2 SYSTEMATIC LITERATURE REVIEW................................................................................................................................................18
2.2.1 Enterprise Architecture Foundations for Digital Transformation ................................................................ 19
2.2.1.1 Customer journey, experience and value creation streams .................................................................................... 20
2.2.1.2 Architecture agility and evolution ....................................................................................................................................... 20
2.2.1.3 Architecture modularity ........................................................................................................................................................... 21
2.2.1.4 Sociocultural alignment of the enterprise........................................................................................................................ 22
2.2.2 Enterprise Architecture practices for Digital Transformation ....................................................................... 23
2.2.2.1 Architecture frameworks ......................................................................................................................................................... 23
The Open Group Agile Architecture Framework™........................................................................................................................... 23
Adaptive Integrated Digital Architecture Framework ................................................................................................................... 30
The Lightweight Enterprise Architecture Framework .................................................................................................................. 32
2.2.2.2 Architecture methods ................................................................................................................................................................ 34
2.2.2.3 EA and industries undergoing Digital Transformations ........................................................................................... 39
2.2.3 Comparative Analysis of EA Frameworks for DT ................................................................................................. 40
2.3 CASE STUDY: EA FOR DIGITAL TRANSFORMATION AT INTEL® ...............................................................................................42
2.3.1 Business Problem .............................................................................................................................................................. 42
2.3.2 Enterprise Architecture Solution ................................................................................................................................ 43
2.3.2.1 EA Operating Model for DT ..................................................................................................................................................... 43
2.3.2.2 EA in Practice for Digital Transformation ........................................................................................................................ 44
2.3.3 Organizational Impact and Results ........................................................................................................................... 46
iii
3 DESIGN ANALYSIS ........................................................................................................................................................ 47
OBJECTIVES OF THE EA METHODOLOGY FOR DT ....................................................................................................................................47
3.1 Design an interdisciplinary organization ..................................................................................................................... 47
3.2 Promote modularization and decoupled building blocks ....................................................................................... 47
3.3 Simplify the Enterprise Architecture cycle ................................................................................................................... 47
3.4 Convey business agility through architecture design ............................................................................................... 48
4 ARTIFACT DESIGN........................................................................................................................................................ 49
ENTERPRISE ARCHITECTURE FRAMEWORK FOR DIGITAL TRANSFORMATION ..................................................................................49
4.1 Framework essentials ........................................................................................................................................................... 50
4.2 Roles, skills and responsibilities ........................................................................................................................................ 50
4.3 Architecture development cycle ........................................................................................................................................ 51
4.3.1 Architecture context .......................................................................................................................................................................... 54
4.3.2 Enterprise-level phases ................................................................................................................................................................... 54
4.3.2.1 Architecture vision ............................................................................................................................................................... 54
4.3.2.2 Architecture action plan..................................................................................................................................................... 55
4.3.3 Project-level phases ........................................................................................................................................................................... 56
4.3.3.1 Architecture outline ............................................................................................................................................................. 56
4.3.3.2 Conceptual architecture ..................................................................................................................................................... 56
4.3.3.3 Logical architecture .............................................................................................................................................................. 57
4.3.3.4 Physical architecture ........................................................................................................................................................... 58
4.3.3.5 Architecture governance ................................................................................................................................................... 59
4.4 Comparison between LEAF and EA4DT ......................................................................................................................... 59
5 ARTIFACT IMPLEMENTATION AND VALIDATION ............................................................................................ 61
5.1 INTRODUCTION TO THE CASE ..........................................................................................................................................................61
5.2 IMPLEMENTATION OF THE ARTIFACT ............................................................................................................................................63
5.2.1 Architecture Context ........................................................................................................................................................ 63
5.2.1.1 Initiative scope .............................................................................................................................................................................. 63
5.2.1.2 Data and Analytics strategy and principles ..................................................................................................................... 63
5.2.1.3 Business goals, objectives and requirements ................................................................................................................. 64
5.2.2 Architecture Vision ........................................................................................................................................................... 64
5.2.2.1 Architecture principles.............................................................................................................................................................. 65
5.2.2.2 Enterprise Architecture operating model ........................................................................................................................ 67
5.2.2.3 Enterprise capabilities with D&A value stream cross-mapping ........................................................................... 67
5.2.2.4 Baseline architecture.................................................................................................................................................................. 70
5.2.2.5 Target architecture...................................................................................................................................................................... 70
5.2.2.6 Cross-functional organization................................................................................................................................................ 73
5.2.3 Architecture Action Plan ................................................................................................................................................ 74
5.2.3.1 High-level action plan ................................................................................................................................................................ 74
5.2.3.2 Architecture constraints and guardrails ........................................................................................................................... 76
5.2.4 Architecture Outline ........................................................................................................................................................ 77
5.2.4.1 Project requirements ................................................................................................................................................................. 77
5.2.4.2 Selected project scope ............................................................................................................................................................... 78
5.2.5 Conceptual Architecture ................................................................................................................................................ 78
5.2.5.1 Business analytics development service .......................................................................................................................... 78
5.2.5.2 Business Analytics Reports Access ...................................................................................................................................... 80
5.2.5.3 Self-service Business Reporting ............................................................................................................................................ 80
5.2.6 Logical Architecture ........................................................................................................................................................ 82

iv
 Application and Technology Design .............................................................................................................................................................. 82
5.2.7 Physical Architecture ...................................................................................................................................................... 83
Technology Solutions Model ............................................................................................................................................................................. 83
5.2.8 Architecture Governance ............................................................................................................................................... 85
5.2.8.1 Modifications at the Enterprise-level ................................................................................................................................. 85
5.2.8.2 Modifications at the Project-level ........................................................................................................................................ 85
5.3 ARTIFACT EVALUATION....................................................................................................................................................................87
Expert opinion evaluation model ................................................................................................................................................. 87
5.3.1 Problem relevance ............................................................................................................................................................................. 87
5.3.2 Practical and Implementation relevance................................................................................................................................. 89
5.3.3 Interviews with practitioners ....................................................................................................................................................... 89
5.3.3.1 Interviewee 1........................................................................................................................................................................... 89
5.3.3.2 Interviewee 2........................................................................................................................................................................... 91
5.3.3.3 Interviewee 3........................................................................................................................................................................... 92

6. CONCLUSIONS ................................................................................................................................................................ 94
6.1 RESEARCH OBJECTIVES REVISITED .................................................................................................................................................94
6.2 CONTRIBUTION ..................................................................................................................................................................................99
6.3 LIMITATIONS................................................................................................................................................................................... 100
6.4 FUTURE RESEARCH ........................................................................................................................................................................ 100
REFERENCES .......................................................................................................................................................................... 102

v
List of Figures
FIGURE 1. ORGANIZATIONS WITH SUCCESSFUL DT DEPLOY MORE TECHNOLOGIES (MCKINSEY & COMPANY, 2018)...................... 3
FIGURE 2. DSRM BY PEFFERS ET AL. (2007) ................................................................................................................................................ 7
FIGURE 3. GAß ET AL. (2015) 4-PHASE SLR FOR IS FIELD ......................................................................................................................... 8
FIGURE 4. DIGITAL TRANSFORMATION CONCEPTS IN THE CONTEXT OF EA .............................................................................................13
FIGURE 5. TOGAF 9.2 STANDARD OVERVIEW (THE OPEN GROUP, 2018) ............................................................................................14
FIGURE 6. TOGAF STANDARD ADM CYCLE (THE OPEN GROUP, 2018)................................................................................................15
FIGURE 7. ARCHIMATE META-MODEL SELECTED ELEMENTS (THE OPEN GROUP, 2019B) ................................................................17
FIGURE 8. STUDY SELECTION PROCESS AND RESULTS ..................................................................................................................................19
FIGURE 9. O-AAF BIG PICTURE (THE OPEN GROUP, 2019) ....................................................................................................................24
FIGURE 10. ARCHITECTING THE DIGITAL ENTERPRISE (THE OPEN GROUP, 2019) .............................................................................27
FIGURE 11. AGILE TRANSFORMATION PROPOSITION (THE OPEN GROUP, 2019) .................................................................................27
FIGURE 12. CUSTOMER JOURNEY SERVICE BLUEPRINTING (THE OPEN GROUP, 2019) .......................................................................29
FIGURE 13. MONOLITHIC TO MODULAR JOURNEY (THE OPEN GROUP, 2019).......................................................................................30
FIGURE 14. STRATEGIC ARCHITECTURE OVERVIEW AIDAF AND RELATED MODELS (MASUDA & VISWANATHAN, 2019)............31
FIGURE 15. AIDAF PROPOSED MODEL WITH TOGAF (MASUDA & VISWANATHAN, 2019) ..............................................................32
FIGURE 16. TOGAF ADM FOR LEAF............................................................................................................................................................33
FIGURE 17. DITP METHOD PROPOSED BY WIßOTZKI & SANDKUHL (2017) .........................................................................................35
FIGURE 18. VALUE PERSPECTIVE OF SERVICE-DOMINANT LOGIC (ZIMMERMANN, ET AL. 2018)......................................................36
FIGURE 19. BUILDING BLOCKS OF THE TWO – SPEED ARCHITECTURE BOSSERT (2016) .....................................................................37
FIGURE 20. TRADITIONAL IT, DIGITAL IT AND BUSINESS BIMODAL ALIGNMENT (HORLACH, DREWS & SCHIRMER, 2016) .........38
FIGURE 21. EA OPERATIONAL MODEL AT INTEL SINGH (2019) ...............................................................................................................43
FIGURE 22. EA DEVELOPMENT PROCESS DEVELOPED AT INTEL SINGH (2019) ....................................................................................46
FIGURE 23. BUSINESS RESULTS FROM ADOPTING NEW EA APPROACH FOR DT ......................................................................................46
FIGURE 24. ARTIFACT OBJECTIVES MAPPED TO MAIN RESEARCH OBJECTIVES.........................................................................................48
FIGURE 25. ENTERPRISE ARCHITECTURE FOR DIGITAL TRANSFORMATION ...........................................................................................51
FIGURE 26. EA4DT ARCHITECTURE DEVELOPMENT CYCLE .....................................................................................................................52
FIGURE 27. AVBV STRATEGY FOR DATA AND ANALYTICS INITIATIVE .....................................................................................................63
FIGURE 28. GOALS, OBJECTIVES AND REQUIREMENTS FROM D&A INITIATIVE .......................................................................................65
FIGURE 29. EA OPERATING MODEL FOR D&A .............................................................................................................................................67
FIGURE 30. DATA AND ANALYTICS CAPABILITIES WITH VALUE STREAMS MAPPING ..............................................................................69
FIGURE 31. BASELINE ARCHITECTURE FROM REPORTING SERVICES AVBV (CONFIDENTIAL) ............................................................70
FIGURE 32. TARGET ARCHITECTURE FROM DATA AND ANALYTICS AVBV..............................................................................................72
FIGURE 33. BUSINESS AND IT CROSS-REFERENCE TEAMS FOR D&A PROGRAM......................................................................................73
FIGURE 34. ROLES AND TEAMS STRUCTURE FOR D&A OPERATION ..........................................................................................................74
FIGURE 35. DEFINED PROJECTS AND EXPECTED DELIVERABLES FOR D&A PROGRAM ...........................................................................76
FIGURE 36. BUSINESS ANALYTICS DEVELOPMENT SERVICE COLLABORATION VIEW ...............................................................................79
FIGURE 37. BUSINESS ANALYTICS REPORTS ACCESS AND SELF-SERVICE BUSINESS REPORTING SERVICES COLLABORATION VIEW 81
FIGURE 38. LOGICAL APPLICATION AND TECHNOLOGY COMPONENTS VIEW ............................................................................................82
FIGURE 39. TECHNOLOGY COMPONENTS CONFIGURATION VIEW FOR D&A ............................................................................................84
FIGURE 40. MODIFIED TARGET ARCHITECTURE DESIGN FOR D&A INITIATIVE......................................................................................86

vi
List of Tables
TABLE 1. THESIS DOCUMENT STRUCTURE........................................................................................................................................................ 7
TABLE 2. ADM ITERATION CYCLES, STAGES AND DESCRIPTIONS (HARRISON, 2018) ..........................................................................16
TABLE 3. SELECTED ARCHIMATE RELATIONSHIP TYPES WITH DESCRIPTION AND NOTATION (THE OPEN GROUP, 2019B) .........18
TABLE 4. ELEMENTS FROM EA RELATED TO DT INITIATIVES BASED ON GOERZIG & BAUERNHANSL (2017).................................19
TABLE 5. OAAF CONSIDERATIONS FOR CONTINUOUS ARCHITECTURAL REFACTORING .........................................................................25
TABLE 6. VIEWPOINTS FROM LIGHTWEIGHT ENTERPRISE ARCHITECTURE FRAMEWORK (NANDICO, 2016) .................................33
TABLE 7. EA FRAMEWORKS COMPARATIVE ANALYSIS .................................................................................................................................41
TABLE 8. SYSTEMS CLASSIFICATION FOR DIGITAL TRANSFORMATION .....................................................................................................45
TABLE 9. EA4DT ROLES, SKILLS AND RESPONSIBILITIES ...........................................................................................................................53
TABLE 10. INPUT AND OUTPUT ARCHITECTURE DELIVERABLES FOR THE ARCHITECTURE VISION PHASE .........................................55
TABLE 11. INPUT AND OUTPUT ARCHITECTURE DELIVERABLES FOR THE ARCHITECTURE ACTION PLAN PHASE ..............................56
TABLE 12. INPUT AND OUTPUT ARCHITECTURE DELIVERABLES FOR THE ARCHITECTURE OUTLINE PHASE ......................................56
TABLE 13. INPUT AND OUTPUT ARCHITECTURE DELIVERABLES FOR THE CONCEPTUAL ARCHITECTURE PHASE ..............................57
TABLE 14. INPUT AND OUTPUT ARCHITECTURE DELIVERABLES FOR THE LOGICAL ARCHITECTURE PHASE .......................................58
TABLE 15. INPUT AND OUTPUT ARCHITECTURE DELIVERABLES FOR THE PHYSICAL ARCHITECTURE PHASE .....................................59
TABLE 16. INPUT AND OUTPUT ARCHITECTURE DELIVERABLES FOR THE ARCHITECTURE GOVERNANCE PHASE..............................59
TABLE 17. COMPARISON BETWEEN LEAF (NANDICO, 2016) AND EA4DT..........................................................................................60
TABLE 18. EA4DT BUSINESS PRINCIPLE .......................................................................................................................................................65
TABLE 19. EA4DT TECHNOLOGY PRINCIPLE ................................................................................................................................................65
TABLE 20. EA4DT DATA PRINCIPLE ..............................................................................................................................................................66
TABLE 21. EA4DT APPLICATION PRINCIPLE ................................................................................................................................................66
TABLE 22. DATA AND ANALYTICS CAPABILITIES DEFINITIONS AND REFERENCES ..................................................................................68
TABLE 23. CONSTRAINS DEFINITION AND CLASSIFICATION FOR ARCHITECTURE PROGRAM .................................................................76
TABLE 24. BUSINESS ANALYTICS DEVELOPMENT SERVICE DEFINITION ....................................................................................................78
TABLE 25. BUSINESS ANALYTICS REPORTS ACCESS SERVICE DEFINITION ................................................................................................80
TABLE 26. SELF-SERVICE BUSINESS REPORTING SERVICE DEFINITION .....................................................................................................81
TABLE 27. APPLICATION COMPONENTS CLASSIFICATION............................................................................................................................83
TABLE 28. PROBLEM RELEVANCE QUESTIONS FOR EXPERT EVALUATION INTERVIEWS .........................................................................88

vii
Abbreviations
ADM Architecture Development Method
AIDAF Adaptive Integrated Digital Architecture Framework
API Application Programming Interface
AVBV Apollo Vredestein B.V.
BMM Business Model Management
B&IT` Business and Information Technologies
CC Cluster Categories
CI/CD Continuous Integration and Continuous Delivery
COTS Commercial off-the-Shelf
CM Capability Management
DEA Digital Enterprise Architecture
DITP Digital Innovation and Transformation Process
DSRM Design Science Research Methodology
DT Digital Transformation
EA Enterprise Architecture
EA4DT Enterprise Architecture Framework for Digital Transformation
EAM Enterprise Architecture Management
EE Enterprise Engineering
GDTC The Global Digital Transformation Communication
GPS Global Position System
IaaS Infrastructure as a Service
IAF Integrated Architecture Framework
ICT Information and Communication Technologies
IoT Internet of Things
IS Information systems
ISO International Organization for Standardization
LEAF The Lightweight Enterprise Architecture Framework
MDM Master Data Management
MVA Minimum Viable Architecture
OAAF The Open Group Agile Architecture Framework™
PaaS Platform as a Service
RDBMS Relational Database Management System
SaaS Software as a Service
SCM Social Collaboration Model
SBCE Set-Based Concurrent Engineering
SDLC System Development Life Cycle
SITAM Stuttgart IT Architecture for Manufacturing
SLR Systematic Literature Review
viii
SME Small and Medium
SOA Service Oriented Architecture
SoS Systems of Systems
STRMM Strategic Risk Mitigation Model for Digital Transformation
T&O Technology and Operations
TOGAF The Open Group Architecture Framework

ix
 Introduction | CHAPTER 1

1. Introduction
1.1 Problem Statement

Apart from empowering people to collaborate and experiment with new emerging technologies,
Digital Transformations require companies to change at multiple levels including organizational
structures, operational processes, business strategies, and even corporate culture. Highly
competitive market conditions introduced by the new digital era have forced organizations to
react quicker than ever before. Today’s ruthless business environments pressure organizations to
employ faster learning cycles that translate into shorter time-to-market strategies. In the banking
industry, for instance, new “born digital” start-ups have disrupted the market with the up-and-
coming “Fintech” revolution. As a result, banks and financial institutions that have operated for
decades are now expected to respond to dynamic market demands with outstanding business
agility. Furthermore, Digital Transformations revolutionize the way in which IT and business
units collaborate. Highly cohesive teams are expected to constantly innovate and deliver
solutions that result in enhanced customer journeys and experiences driven by new corporate
cultures.

Facing the challenges brought by the new digital era not only requires the adoption of emerging
technologies i.e. mobile computing, big data analytics, cloud computing and the internet of
things, but committing to best practices that allow organizations to execute successful Digital
Transformations. Conventionally, Enterprise Architecture has proven to be the discipline that
best provides a basis for highly integrated environments, that are responsive to change and
supportive in the delivery of the business strategy. However, organizations that have allocated
resources and great efforts to become truly digital, criticize the Enterprise Architecture practice
as it fails to grasp the fundamental concepts from the nature of Digital Transformations.
Certainly, such discontent has drawn attention to perform this research.

To begin with, architecting the digital enterprise goes hand in hand with architecting the agile
transformation. Despite the fact that agile thinking has become a core element, part of the
development cycle of well-known Enterprise Architecture approaches, these methods do not
succeed to help organizations become more agile. Secondly, extrapolation of the earliest
software development processes has influenced many of the best practices of today, and
Enterprise Architecture is no exception. As experienced with the waterfall model, Enterprise
Architecture approaches are perceived as “Big designs up-front”, creating a sense of reluctance
in organizations to commit to years-long architecture plans and efforts. Consequently, this
situation calls out for a simplification of Enterprise Architecture development in preparation to
confront Digital Transformations. Ultimately, no margin to experiment and discover alternative
organizational structures between business and IT units indicates the absence of adopting fast-
1
 Introduction | CHAPTER 1

learning cycles in Enterprise Architecture methods. The latter corroborates the need to constantly
re-architect business and IT elements to cope effectively with agile and flexible ways to work.
In response to these adversities, organizations must tackle these challenges systematically by
embracing new or enhanced approaches that enable them to stay ahead of the competition while
keeping up the pace of the new digital generation. Hence, this situation has motivated this
research to introduce an Enterprise Architecture framework to assist organizations in their
journey to deploy successful Digital Transformation initiatives.

1.2 Research Context and Motivation

The new digital era has unlocked new opportunities for organizations to transform and innovate
with new products and services. A survey performed by McKinsey & Company (2018) revealed
that eight out of ten companies have committed resources and efforts to Digital Transformation
initiatives in the past five years. However, success rates from these efforts are considerably low,
resulting in less than 30 percent of successful cases. Particularly, organizations that experienced
successful transformations highlighted the importance of adopting best practices involving
leadership, capability management, upgrading tools, and communication. Results from the latter
study, depicted by Figure 1, also indicated a tendency from organizations with successful
transformations to deploy more technologies than others do. So-called emerging technologies or
SMACIT (social, mobile, analytics, cloud, and internet of things) technologies serve as a vehicle
towards successful Digital Transformations for those companies who are willing to embrace new
organizational structures and processes that empower people to collaboratively experiment with
technologies and deliver integrated products and services to customers (Sebastian et al. 2017).
As a result, these substantial changes call out for management practices to govern these complex
transformations (Matt, Hess & Benlian, 2015), in which practices such as Enterprise Architecture
can be understood as the new prosecutors of the new IT function, moving away from the
traditional role of a service provider to those of a consultant, enabler and innovator (Legner et al.
2017).

For many years the Enterprise Architecture discipline provided guidance in the form of a well-
established governance instrument to consistently align business and IT with strategies and goals
to ensure adaptability, consistency, compliance, and efficiency (Zimmermann et al. 2015).
Multiple communities of practitioners, research institutes as well as consultancy firms and
private corporations have reinforced its importance as a recognized practice employed across
several business domains and industries. This corroborates the fact that the Enterprise
Architecture discipline has played an important role in the last decades by providing a well-
founded practice that enabled organizations to shift into highly integrated environments that
effectively deliver key business strategies (Harrison, 2018). However, in today’s fast-paced
marketplace and highly dynamic business environments even large corporations such as Intel®,
which have had an Enterprise Architecture mindset for years, struggled to keep their architecture

2
 Introduction | CHAPTER 1

products and solutions simple and in line with the company’s Digital Transformation strategies
(Singh, 2019). The increasing complexity from the Enterprise Architecture practice prevents
simple projects to adopt practical solutions and quick adaptions to change (Nandico, 2016).

Figure 1. Organizations with successful DT deploy more technologies (McKinsey & Company, 2018)

At the same time, Digital Transformations encourage risk-taking, foster innovation, and develop
collaborative work environments (Kane et al. 2015). This leads companies to embrace the
philosophy of “learn fast, fail fast” allowing organizations to speed-up their learning cycles and
become truly agile instead of falling into the trap of committing to years-long Enterprise
Architecture plans with big designs up-front (The Open Group, 2019). For this reason, the
Enterprise Architecture practices need to examine carefully the concept of business agility or
enterprise agility for that matter, as successful development and integration of Digital
Transformation through digital businesses require a high degree of agility in enterprises
(Wißotzki & Sandkuhl, 2017).

Ultimately, the Digital Transformation has presented Enterprise Architecture and its community
of practitioners new opportunities to evolve and deliver organizations solutions that transcend the
traditional IT-business alignment, to a state where IT is pervasively embedded into every level of
the organization and be an integral part of the business strategy (Sia, Soh & Weill, 2016). The
Enterprise Architect prepared to guide companies towards successful Digital Transformations
embraces new or enhanced practices supported by modern business models that enable
organizations to stay ahead of the competition while keeping up the pace of the new digital

3
 Introduction | CHAPTER 1

generation. In short, regardless of the difficulties and pitfalls perceived form practice, this thesis
is motivated to investigate how Enterprise Architecture can assist organizations to embark on
successful Digital Transformations and hence, contribute with useful insights to both the
research and practitioner communities.

1.3 Research Objectives

As previously described in the introduction section, the high-level aim for this research is to
provide an Enterprise Architecture framework that incorporates the fundamental concepts from
the nature of Digital Transformation. In general, the concepts comprise business agility, team
collaboration across business and IT units, and simplification of architecture development.
Therefore, the main goal formulated as the main research question is:

How to lead organizations towards successful Digital Transformations by means of an

Enterprise Architecture framework that stimulates business agility, simplifies architecture
development, and promotes collaboration across business and IT units?

Furthermore, the main research question is further decomposed into the following
objectives/sub-research questions:

Research Objective 1 (RO1): Contrast the structure of the Enterprise Architecture practice with
the anatomy of Digital Transformations. To do so, definitions of these two main constructs are
provided from the body of knowledge assembled by performing the SLR later discussed in
section 2.2. Subsequently, the concepts are related to the sole purpose of understanding the
extent to which Enterprise Architecture reacts to Digital Transformations according to literature.
Thus, gaps to be addressed by the Enterprise Architecture discipline are identified and
constituents to tackle Digital Transformations are established. As a result, the following
knowledge questions are formulated:

a. What is Enterprise Architecture?

b. What is Digital Transformation?
c. What is the relation between the concepts of Enterprise Architecture and Digital
Transformation?
d. What constituents from Digital Transformation initiatives are not contemplated by the
Enterprise Architecture practice?

Research Objective 2 (RO2): Identify the state-of-the-art regarding Enterprise Architecture

practice to support the realization of Digital Transformation initiatives. This objective aims at
collecting existing Enterprise Architecture approaches that address the challenges of Digital
Transformations. Frameworks, methods, and techniques analyzed and discussed as part of this

4
 Introduction | CHAPTER 1

objective serve as key components of the artifact to be derived in the following stages of this
thesis. Therefore, the following knowledge question is formulated:

a. What Enterprise Architecture frameworks, methodologies, and techniques are available

that best provide a basis for Digital Transformation?

Research Objective 3 (RO3): Elaborate on how the Enterprise Architecture practice is delivered
in organizations that have embarked on Digital Transformation initiatives. The development of
EA in organizations to embark on successful Digital Transformations is an area of special
interest in this thesis. Therefore, this objective aims at analyzing the approaches taken by
organizations from different industries to embark on successful Digital Transformation
initiatives. It does also extract the problem, solution, and impact on the business through the
examination of a case study of a particular organization. This research objective, therefore, poses
the following research questions:

a. How are organizations from multiple industries relying on Enterprise Architecture to

deliver Digital Transformations into the organization?
b. What are the business problems, impact, and solutions from adopting an Enterprise
Architecture approach for Digital Transformation in the case of a particular organization?

Research Objective 4 (RO4): Design an Enterprise Architecture framework for Digital

Transformation. In line with the DSRM adopted by this thesis, the objectives to be attained by
the artifact are derived. In addition, the results of the SLR and the examined case study serve the
purpose of assembling the Enterprise Architecture Framework for Digital Transformation in
response to the main research question. The constituent building blocks, associated methodology,
and incorporated architecture techniques and patters are further explained and documented.

a. What are the objectives to be attained by the Enterprise Architecture framework for
successful Digital Transformations?
b. What are the foundations or building blocks of the Enterprise Architecture framework for
Digital Transformation?
c. How does the suggested framework stimulate business agility, simplifies architecture
development, and promotes collaboration across business and IT units of the enterprise?

Research Objective 5 (RO5): Demonstrate and evaluate the Enterprise Architecture framework
for Digital Transformation in an organizational context. The artifact is validated with a Technical
Action Research methodology in the context of a real-world Digital Transformation initiative.
Moreover, semi-structured interviews are conducted to evaluate the relevance of the artifact
around the problem context. Expert feedback and improvement opportunities are documented for
future research and DSRM cycle iterations.

5
 Introduction | CHAPTER 1

a. Demonstrate through experimentation the applicability of the Enterprise Architecture

framework in a Digital Transformation project for an organization.
b. Carry out expert opinion interviews to evaluate how the artifact supports a successful
Digital Transformation initiative in the organization.

1.4 Research Methodology and Thesis Structure

This research adheres to the Design Science Research Methodology (DSRM) for research in the
Information System (IS) field as defined by Peffers et al. (2007). Figure 2 depicts the general
process prescribed by the method to present and evaluate a design science research in IS. In line
with the intentions of this research, the process is composed of the following six steps:

1. Problem identification and motivation: The main problem is identified and the
motivation to develop the research is justified. A SLR is performed at this stage, focused
not just to aggregate all the existing content for the research question and objectives, but
to support the development of evidence-based guidelines for practitioners (Kitchenham et
al. 2009).

2. Define the objectives for a solution: The main research objectives are defined in order
to provide an artifact that treats the problem identified in the first phase. This refers to the
definition of requirements and expectations to be met by the artifact to be assembled.

3. Design and development: The activity includes the development of the Enterprise
Architecture framework reference for successful Digital Transformations. Findings from
the SLR as well as the analysis of a case study contribute to the formation of
requirements to be considered in the artefact design.

4. Demonstration and Evaluation: A Digital Transformation initiative for Data and

Analytics at Apollo Vredestein B.V. sets a practical environment on which the
framework is applied. Under those circumstances a Technical Action Research
methodology is employed. As part of the evaluation section, semi-structured interviews
are carried out through an expert opinion process to evaluate the designed artifact.

5. Communication: This thesis report serves as a vehicle of communication of the

conclusions from designing, demonstrating and evaluating the proposed framework in a
real-world scenario.

6
 Introduction | CHAPTER 1

Figure 2. DSRM by Peffers et al. (2007)

After describing the main research methodology adopted for this thesis, the structure of the
document is delineated in Table 1.
Table 1. Thesis document structure

Thesis section DSRM Phase Research Method Research Questions

1. Introduction Problem identification - -

and motivation

2.1 Basic Definitions Problem identification Systematic Literature RO 1.a, 1.b, 1.c
and Key Concepts and motivation Review

2.2 Systematic Problem identification RO 1.d, 2.a, 3.a

Literature Review and motivation

2.3 EA for DT at Problem identification Case study RO 3.b

Intel® and motivation examination

3. Design Analysis Define the objectives SLR and Case study RO 4.a
for a solution results

4. Artifact Design Design and RO 4.b, 4.c

development

5. Framework Demonstration and Technical Action RO 5.a, 5.b

Implementation and evaluation Research
Validation Expert opinion
interviews

6. Conclusions Communication - All research

questions revisited
7
 Introduction | CHAPTER 1

1.5 Systematic Literature Review Methodology

The Systematic Literature Review (SLR) performed is based on the methodology provided by
Gaß et al. (2015) for literature reviews in the information systems (IS) field. The four-phase
method was applied to distinguish between the body of knowledge relevant for the systematic
review and the rest of the literature that is not aligned to the purpose of this research. Figure 3
depicts the process adopted for this literature review. The SLR method is composed of a database
search, initial screening, clustering, and in-depth analysis.

Figure 3. Gaß et al. (2015) 4-phase SLR for IS field

In the first phase, the scholarly literature search performed in this research aims to retrieve the
most credible academic peer review content from well-known sources of scientific knowledge.
Databases and search engines for scientific literature used in this research include Scopus,
SpringerLink, ScienceDirect, and IEEExplore. As part of the literature, recognized publications
from large communities of practitioners in the field of Enterprise Architecture were included in
this literature study. Thus, this research considers The Open Group standards related to
Enterprise Architecture as relevant sources of knowledge aligned to the interests and objectives
of this project. MIS Quarterly Executive, as a further reliable source of practice-based research
with the largest number of publications in the last years in the context of Digital Transformation,
contributes to the body of knowledge of this systematic literature review.

The term “Enterprise Architecture” was naturally included in the search criteria, as it represents
one of the core concepts of this research. The logical operator AND was used to relate EA with
the concepts: “Digital Business Transformation”, “Digital Transformation”, “Digitalization” or
“Digitization”. As there is not a unique definition and interpretation of the previously mentioned
concepts across all literature and their relation to the EA practice, the logical operator OR was
incorporated. The concepts of “Cloud Computing” and “Data Analytics” were also included in
the search query as these technologies are subject to interest in this particular research. Further,
the concepts of “organization”, “organisation”, “business” or “businesses” aim at retrieving the
body of knowledge in the setting of public or private organizations. In some databases the term

8
 Introduction | CHAPTER 1

“manufacturing” was used to: first, enrich the search criteria due to the lack of functionalities of
specific search engines and secondly, to address the last research question regarding the specific
industry where digital enterprise transformation initiatives are undertaken.

The process of screening set the conditions for inclusion and exclusion criteria from results
retrieved on the selected research databases. Therefore, conditions required the documents to
include the keywords listed above in the abstract section. The inclusion criteria for this literature
review consisted of open-access documents or access granted through the use of the University of
Twente credentials, documents written in the English language from the Computer Science,
Business and Information Technologies subject areas published not before the year 2015. A
reason to delimit the search to include studies published after the year 2015 is due to the fact that
the term Digital Transformation has significantly skyrocketed from the beginning of 2015
according to Google Trends. The exclusion criteria considered for this study comprised the
manual removal of duplicates found across all research databases, magazines, notes and
documents that had no relation to the presented research questions.

The process continued by sorting the results by relevance, according to the proximity between
the keywords and each abstract section and keyword parameters. Further, an abstract review of
the remaining results was performed, where a selection of the most relevant literature was made
considering the given research questions. Subsequently, Clusters are defined to categorize the
literature into thematic areas or constructs. These were identified by looking back at each of the
research questions and their main purpose when scanning the selected literature. The clustering
process assisted in filtering out literature that had no association with the proposed research
questions. Results from the undertaken systematic process are detailed in section 2.2.

1.6 Practical and Scientific Relevance

The research is relevant from two perspectives:

1.6.1 Practical relevance

Industry-leading research and surveys have shown that organizations that have adopted best
practices to embark on Digital Transformation initiatives are more likely to succeed than those
who did not (McKinsey & Company, 2018). The Enterprise Architecture framework and
development method, as presented in this research, assists organizations to adopt the
fundamental concepts of design and development of architecture in the context of a Digital
Transformation. In other words, the presented study is relevant to the practical level as it
compiles the constituents from Digital Transformations and translates it into a methodology for
Enterprise Architecture development in organizations.

9
 Introduction | CHAPTER 1

1.6.2 Scientific relevance

Throughout the last decade, several IS disciplines have evolved to provide faster, more effective,
and comprehensive solutions to organizations. For instance, Agile and DevOps practices are
introduced as vital methodologies to be implemented by IT for continuous software development
and delivery. However, there has not been much progress in the field of Enterprise Architecture
in the context of Digital Transformation. This research analyzes, compiles, and integrates
methodologies from selected publications and proposes an Enterprise Architecture approach to
Digital Transformation and validates its use on a concrete real-world case.

10
 Problem Investigation | CHAPTER 2

2 Problem Investigation
This section presents the relevant theoretical foundations of this research. Basic concept
definitions and associations between core constructs are provided, as well as the state-of-the-art
approaches, proposed by both the research and practitioner communities, for the development of
Enterprise Architecture for Digital Transformation. This section focuses on addressing the first
three objectives of this thesis.

2.1 Basic Definitions and Key Concepts

To provide a fundamental view around the concepts of Digital Transformation and Enterprise
architecture, definitions are given and relationships between these concepts are established.
Thus, the following subsections tackle research objectives 1.a, 1.b, and 1.c.

2.1.1 Enterprise Architecture and Digital Transformation

In the field of Business and Information Technologies, many concepts have been adopted to
address and describe particular aspects of the Digital Transformation phenomenon including
“Digitalization”, “Digitization” and “Digital Business Transformation”. Consequently, in the
context of this research and with the sole purpose to avoid ambiguities the previous terms are
defined and related to the Enterprise Architecture discipline. In order to provide a middle ground
basis for key subject matters discussed in this research, the following section provides basic
concept definitions regarding Enterprise Architecture and Digital Transformation. The concepts
are delimited within the scope of the Business and Information Technology subject area.

Enterprise is defined as the collection of organizations that have common goals, covering all its
missions and functions. On the other hand, architecture is defined as “the fundamental
organization of a system embodied in its components, their relationships to each other, and to
the environment, and the principles guiding its design and evolution” (ISO, 2011). Both concepts
are merged to form Enterprise Architecture, considered as the organizing logic of business,
information systems, and technology in order to review, maintain and control the whole
operation of an enterprise (Őri and Szabó, 2018). Consequently, in the context of Enterprise
Architecture, the term enterprise “can be used to denote both an entire enterprise, encompassing
all its information systems, and a specific domain across multiple functional groups” (Harrison,
2018). The main intention of an Enterprise Architecture is to determine how an organization can
realize and achieve its current and future goals and objectives by aligning enterprise business
functions with Information and Communication Technologies (ICT).

On the other hand, according to Gartner, Inc. (2020c), “Digital transformation can refer to
anything from IT modernization (for example, Cloud Computing), to digital optimization, to the
invention of new digital business models.” i.e. an operation or exercise to leverage new digital
11
 Problem Investigation | CHAPTER 2

technologies that enable major business improvements and influence all aspects of customers’
life (Reis et al. 2018). Whereas a Digital Business Transformation defined by Gartner, Inc.
(2020d) is known as “the process of exploiting digital technologies and supporting capabilities
to create a robust new digital business model”. Hence, stipulating a method of using
technologies to structure changes and modifications of business processes, culture, and strategies
of an organization to meet customer requirements and dynamic market demands. Further,
Gartner, Inc. (2020e) defines Digitalization as “the use of digital technologies to change a
business model and provide new revenue and value-producing opportunities; it is the process of
moving to a digital business”. In practice, digitalization is how digital technologies allow
computing to be implemented into daily activities that traditionally were considered to be
performed by human beings (Zimmermann et al. 2018). Finally, digitization is the conversion of
any analog resources to digital form (Legner et al. 2017) e.g. converting a specification from a
specific business practice from paper to a digital document.

As depicted in Figure 4, the conceptual model illustrates the scope of the terminology previously
defined in the context of an organization and its reach in relation to EA. From a bottom-up
perspective, digitization can be implemented in the enterprise at the most basic level, where
activities such as the digitization of information, provide the enterprise new ways to access and
share data across all business units. EA provides a clear set of work to map these technological
mechanisms in response to business needs. Digitalization initiatives are focused on delivering
projects and employ technology to automate, optimize or modernize the business operations and
processes of the enterprise.

Architecture and solution building blocks guarantee the logical integration of these complex
relationships to deliver enhanced or new service capabilities. A vague distinction however
between the Digital Business Transformation and Digital Transformation prevails since both
terms relate to disruptive changes of new business models. Therefore, both concepts include the
integration of digitalization projects to transform the business and its own strategy.
Consequently, in the scope of EA, both concepts portray the extension and effective reach of the
enterprise through digital capabilities. Essentially, since both Digital Business Transformation
and Digital Transformation initiatives span over entire organizations and enterprises, these terms
will be treated simply as Digital Transformation henceforth.

12
 Problem Investigation | CHAPTER 2

Figure 4. Digital transformation concepts in the context of EA

2.1.2 Enterprise Architecture in practice

Enterprise Architecture can be delivered in practice in multiple ways. Research and practitioner
communities have introduced several frameworks, methodologies, reference models, among
others, to help organizations achieve the right balance between business transformation and
continuous operational efficiency. The main benefits of delivering EA in practice include better
planning and improved decision-making processes based on well-structured and informed
designs (The Open Group, 2018). The concept of frameworks built around Enterprise
Architecture best practices set the foundational structures needed to develop architectures for
organizations across multiple industries and domains.

Many organizations worldwide have committed to Enterprise Architecture best practices by

adopting the most recognized frameworks such as TOGAF, FEAF, DoDAF, MODAF and
Zachman. A framework describes a method for designing a target state of the enterprise in terms
of a set of building blocks and for showing how these building blocks fit together (Harrison,
2018). In addition, it provides a common vocabulary, a set of tools and a list of recommended
standards that can be used to deliver the building blocks. A framework allows an organization to
simplify and speed-up architecture development, guarantee the materialization of a complete
solution and effectively address the concerns of the main stakeholders of the enterprise
(Lankhorst et al. 2009).

The increasing popularity over an entire decade and the great support from the EA practitioner
community, holding a total of 266 architecture forum members (The Open Group, 2020), point
out to The Open Group Architecture Framework (TOGAF) as an approved standard for
developing EA in organizations, generic and not tied to a specific industry. In line with the
intentions of this thesis, TOGAF is considered a critical practical element for the materialization
of Enterprise Architecture and therefore a crucial tool for more effective and efficient Digital
Transformation and IT operations (The Open Group, 2018). Moreover, the great majority of the
frameworks for Digital Transformation retrieved from performing the SLR, described in the
13
 Problem Investigation | CHAPTER 2

following section are based on TOGAF, leaving no choice but to consider it a foundation of the
intended artifact presented in this study.

2.1.3 The Open Group Enterprise Architecture Framework

The Open Group has developed throughout the years a well-established Enterprise Architecture
framework known as The Open Group Architecture Framework. TOGAF has been developed
through the collaborative efforts of the whole EA community (Harrison, 2018). As a best
practice, the framework plays an important role in the organizations, reducing risks by
standardizing the architecture development process. TOGAF serves the organizations as a
generic architecture framework, employed as a best practice to portray the current needs and
future needs of the business. The framework standard in its version 9.2 as depicted in Figure 5
reflects the architecture capability of an enterprise and is composed of the TOGAF Capability
Framework, the TOGAF ADM and Content Framework, and the TOGAF Enterprise Continuum
and Tools. Therefore, an organization that has the ability to effectively undertake the activities of
an Enterprise Architecture practice consequently has an Enterprise Architecture Capability
(Harrison, 2018). Moreover, the standard covers the development of four architecture domains
composed of the Business Architecture, Data Architecture, Application Architecture, and
Technology Architecture.

Figure 5. TOGAF 9.2 standard overview (The Open Group, 2018)

14
 Problem Investigation | CHAPTER 2

The suggested step-by-step cycle to develop EA, considered the core of TOGAF, is known as the
Architecture Development Method (ADM). The ADM provides a tested, repeatable process for
developing architectures that allow organizations to transform their enterprises in a controlled
manner in response to business goals and needs (Harrison, 2018). Figure 6 illustrates the ADM
cycle and its constituent phases. The cycle reflects the importance of competition that allows an
architect to move from one stage to the next one. Moreover, a notion of interaction is expressed
through the method, i.e. returning to a particular stage would require a competition of its
subsequent phases.

Figure 6. TOGAF Standard ADM cycle (The Open Group, 2018)

A brief description of all the phases of the ADM cycle is provided in Table 2. Each of the phases
provides a set of activities with the intention to develop the appropriate architectural content. For
example in the business architecture phase, the reference models and tools are selected, both
baseline and target architectures are developed, a gap analysis is performed, candidate roadmaps
are defined, impacts across the architectural landscape are resolved, a review with stakeholders is
conducted and the creation of deliverables is undertaken. Similarly, as part of the Requirements
Management function, every ADM stage is based on and validates business requirements.

The ADM cycle of TOGAF is designed as a generic method to meet most of the organizational
requirements and copes with variable vertical sectors and industry types. Due to this wide range
of applicability, The Open Group recommends to tailor or customize the method so that the
organizations’ specific needs can be satisfied. In addition to this, the cycle does not prescribe a
specific order, it goes according to the priorities and principles of the organization to make use of
the phases of the ADM cycle to achieve the desired business goals. Several publications
including Harrison (2018), Lankhorst et al. (2009) and The Open Group (2018) further detail the
TOGAF framework and its associated elements.
15
 Problem Investigation | CHAPTER 2

Table 2. ADM iteration cycles, stages and descriptions (Harrison, 2018)

Iteration Cycles ADM Stage Description

Architecture Preliminary Includes the preparation activities and initiation

context Phase activities to create the Architecture capability.
Architecture principles are defined in this stage.

Architecture Sets the scope, constraints, and expectations for a

Vision TOGAF project. Stakeholders are identified and the
business context is validated.

Architecture Business Describes the fundamental organization embodied in the

delivery Architecture business process and people to support the agreed
architecture vision.

Information Documents the major types of information and

Systems application systems that enable the business architecture
Architecture and consequently the architecture vision.

Technology It contains the embodied software and hardware that

Architecture support previous architecture stages. Represents the
fundamental organization of IT systems for the entire
enterprise.

Transition Opportunities Describes the process of grouping projects into work

planning and solutions packages for the delivery of target architectures defined
across the previous phases.

Migration A migration plan is detailed describing how to move

Planning from the baseline to target architectures.

Architecture Implementation Provides oversight for the implementation of the

governance Governance architecture i.e. ensures that the implementation is
compliant to the architecture.

Architecture Established the required procedures for managing

Change change to the new architecture. Monitors that the
Management architecture responds to the needs of the enterprise.

16
 Problem Investigation | CHAPTER 2

2.1.4 EA Modelling Support Tools and Notation

The intended Enterprise Architecture framework for Digital Transformation delivered as part of
this thesis presents multiple architecture models across multiple views of the enterprise.
Therefore, the ArchiMate® Enterprise Architecture standard (The Open Group, 2019b) is used
as the modelling language that provides a unified specification of architectural domain elements
depicted throughout the Implementation and Validation section of this document.

2.1.4.1 The ArchiMate Language

The ArchiMate Enterprise Architecture standard serves organizations with a visual language for
describing, analyzing, and communicating concerns and solutions to the stakeholders involved in
the Enterprise Architecture. Furthermore, it provides a complete set of entities and relationships
for the proper representation of architecture models. An essential goal of ArchiMate is to deliver
means for integration so that models can be created that depict high-level structures within
domains and the relationship between domains (Lankhorst et al. 2009). In the context of
Enterprise Architecture in practice, domains refer to the architecture domains of TOGAF later
introduced in section 2: Problem Investigation section. In line with the principle of “Keep it
simple”, this research appropriates the meta-model simplification of ArchiMate 3.1 adopted at
Intel to develop Enterprise Architecture models and views (BizzDesign, 2018). The simplified
version is limited to use 30 out of the 74 elements of the original meta-model and 8 out of the 14
relationship types defined in ArchiMate 3.0. Figure 7 depicts the elements chosen elements.

Figure 7. ArchiMate Meta-model selected elements (The Open Group, 2019b)

Table 3 summarizes the relationships defined by the ArchiMate 3.0 specification to be

incorporated into the simplified-meta model.

17
 Problem Investigation | CHAPTER 2

Table 3. Selected ArchiMate relationship types with description and notation (The Open Group, 2019b)

Relationship Type Description Notation

Specialization It represents that an element within the model is a
particular kind of another.
Realization Represents than an element assist in the
materialization of a more abstract entity.
Aggregation The element represents that an element combines
one or more other elements.
Serving Represents that an specific element supplies its
functionality to another element
Association Represents a generic relation between two elements
that cannot be cover with other types
Assignment The relationship embodies the assigment of
responsibility, performance of behaviour, storage or
execution.
Composition Represents the existence of dependency between
one or more elements i.e. one element consists of
one or more other concepts.
Flow Used to model the simple flow between one
element to another element e.g. information good or
money.

2.2 Systematic Literature Review

The initial literature search yielded a total of 309 articles. After applying the exclusion and
inclusion criteria a total of 215 results were retrieved. Further reading and detailed inspection of
the papers as well as the removal of duplicates from papers found at more than one database led
up to a total of 26 articles, where 4 additional references were added as a backward reference
search process. The final number of literature and studies selected for this research resulted in a
total of 30 papers respectively. Figure 8 summarizes the process of retrieved and selected papers
at each stage of the systematic literature review, where n denotes the total amount of articles at
each stage.

Results from classifying the body of knowledge are further documented in the Research Topics:
Examining Enterprise Architecture for Digital Transformation report in preparation for this
thesis. Therefore, the following section assembles the theoretical foundation needed to design the
Enterprise Architecture Framework for successful Digital Transformation.

18
 Problem Investigation | CHAPTER 2

Figure 8. Study selection process and results

2.2.1 Enterprise Architecture Foundations for Digital Transformation

The foundations discussed in this section represent the pillars that must be contemplated in the
EA practice to cope with the nature and constituents from Digital Transformation initiatives
discussed in the introduction. As a result, this section tackles research objective 1.d.

Four major elements are found to be inherent to Digital Transformation projects in contrast to the
EA discipline. Table 4 lists such elements as a way to differentiate both positions and reflect how
EA can benefit from addressing new challenges posed by Digital Transformation. Based on these
elements, further insights are provided according to findings extracted from the literature.

Table 4. Elements from EA related to DT initiatives based on Goerzig & Bauernhansl (2017)

Element/item Enterprise Architecture Digital Transformation

Development Waterfall Agile

approach

Subject Transactional stable Customer-oriented/Fast

systems changing service systems

Value stream IS for stable value chains Ecosystems and sensitive

value creation

Driver IT-focus Business-focus

19
 Problem Investigation | CHAPTER 2

2.2.1.1 Customer journey, experience and value creation streams

The concept of customer journey i.e. a customer’s continuous engagement with an organization’s
products and services constitutes a crucial facet in the nature of Digital Transformations.
Therefore companies pursuing customer engagement strategies with digital transformation are
intended to capture customer loyalty and trust by providing superior, innovative, personalized
and integrated customer experiences (Sebastian et al. 2017). Additionally, the new era of digital
technologies enables greater involvement and engagement between customers and organizations
than ever before (Babar & Yu, 2019). Customer experience and project-to-product shifts are the
major drivers for companies to embark on a digital transformation initiative. Architecture
building blocks placed into adaptive operation models that comply with both digital and agile
transformations will translate into successful customer journeys (The Open Group, 2019).

Traditional EA methodologies focus on Information Systems for stable value chains and
customer needs, whereas digital transformation works with ecosystems and context-sensitive
value creation (Őri & Szabó 2018). Organizations developing Digital Transformation initiatives
should not only be prepared to embrace continuous changes in business processes, information
systems, and technology domains but also be aware of the value creation streams embedded into
those domains to successfully materialize improved customer journeys and experiences. These
particular elements essential into DT projects now have to be tackled by new enterprise
architecture practitioners. New technologies and digital transformations can assist in setting the
basis of what customers need. Customer experience starts with companies who discover their
customer needs instead of asking for them directly (The Open Group, 2019). Analysis of
customer journey and job-to-be-done are approaches on which companies are relying on,
therefore creating opportunities for improvement in the current EA practice where such
perspectives are not entirely handled. A successful rollout of a Digital Transformation strategy
essentially comes to the alignment of its four different dimensions: use of technologies, changes
in value creation, structural changes and financial aspects (Matt, Hess & Benlian, 2015).
Enterprise Architecture must lie in the middle of the DT phenomena, managing dynamic
organizations with multiple needs moving at different speeds.

2.2.1.2 Architecture agility and evolution

Current EA mechanisms are built to map complex structures in organizations that are perceived
to be moving at the same speed. Current architecture approaches must integrate designs built for
today’s digital enterprise, in such ways that established organizations are able to leverage their
existing and legacy foundations including but not limited to IT architecture (Bossert, 2016). In
contrast to software development, EA is based on waterfall mechanisms whereas digital
transformation relies on an agile approach. Moreover, lifecycle phases adopted by EA include
development-maintenance-documentation, where agile adopts development-usage-maintenance-
documentation (Őri & Szabó 2018).

20
 Problem Investigation | CHAPTER 2

The high-level speed of organizations must be a result of how its internal agile teams work
autonomously, not at the expense of effective alignment with the strategy and shared purpose of
the enterprise (The Open Group, 2019). Rigidities raised by creating dependencies across teams
negatively affect operational excellence. Proposals and modifications to current EA approaches
consider architecting effective adaptive operating models. Consequently, extensions of such
models must support guided and incremental change across multiple dimensions of evolutionary
architectures (Ford, 2017). Emerging technologies implemented as part of Digital
Transformation initiatives reduce significantly product development lifecycles and increase
product release cadence, expecting that enterprises rely on adaptable and rapidly configurable
business processes and companying IT systems in order to deliver appropriate products and
services with significant agility (Babar & Yu, 2019).

Enterprise Architecture and their practitioners have been criticized for “Big Design Up-front”,
where conventional approaches impose rules and guidelines preventing simple projects to adopt
practical solutions and quick adaptations to change (Nandico, 2016). Shorter time to market and
higher quality of products and services are outcomes from promoting faster learning cycles in a
digital and agile transformation of the enterprise. These are characteristics meant to be integrated
under a new EA practice for DT. Agility can also be seen in the integration of technology and
operations (T&O) analysts to form T&O teams, who rationalize with business counterparts to
sort out technology platforms as part of digital standardization strategies, hence setting the
foundations for EA development (Sia, Soh & Weill, 2016). Architecture change and evolution
should be managed but also monitored. Proper evolution of the enterprise and its artifacts need to
be supported by observe-and-response mechanisms placed at different levels of the architecture
e.g. business and technology layers. These so-called sense-and-response loops provide the
foundations for which the enterprise continuously adapts and improves (Babar & Yu, 2015;
2019). For instance, joint forces from human and machine collaboration are to be modeled and
mapped throughout business and technology domains to determine causes and justify the need
for change.

2.2.1.3 Architecture modularity

Easy ways to adopt architectures are also one of the main requirements from DT initiatives to
Enterprise Architecture approaches. Current EA practices prescribe methods that impose cycles
that should be followed from start to finish. To effectively cope with the agile and constantly
evolving enterprise, EA practices should be modular instead of integrated. Extensive and
complex integrated architectures create rigidities across domains. “Modularity is about
decomposing a system into parts that are loosely-coupled” (The Open Group, 2019), where the
system is any type of entity from a human or social to technical. Different segments of the
architecture move at different speeds e.g. customer-oriented architecture and transactional
architecture for the operational backbone (Bossert, 2016). Thus, IT architecture domains, for
instance, provide independent mechanisms with collective units to seamlessly improve customer
21
 Problem Investigation | CHAPTER 2

experiences. Modular architectures that follow service-oriented concepts facilitate

interoperability, sharing of data as well as its management (Helfert, Melo & Pourzolfaghar,
2018).

Enterprise Architecture approaches should comply with mechanisms of modularity brought by

business units that work at different paces. In response to modularity, EA must integrate different
governance and organizational structure of bimodal IT teams (Horlach, Drews & Schirmer,
2016). Digital Transformation projects require agile ways to innovate and respond to dynamic
customer demands. Therefore EA techniques must deal with them at different levels including
processes, applications, and infrastructure. In a way, EA development should align with some of
the software architecture techniques that foster quicker, efficient and innovative ways of
transforming organizations. Starting with agile (Fowler & Highsmith, 2001), followed by
services-oriented concepts, interoperability, continuous delivery, and continuous integration, EA
can significantly help organizations to respond quicker than traditional methods and approaches.

Out of the boundaries of software architecture and its contributions, in order to materialize DT
projects, EA approaches must think modular, cross-functional and distributed business processes
that allow integration into ecosystems (Goerzig & Bauernhansl, 2017). These particular
ecosystems are self-contained and self-adjusting systems that when grouped they create value.
Materializing Digital Transformations through modularized architectures will bring flexible,
adaptable and agile enterprises resilient to change while retaining value delivered to customers.

2.2.1.4 Sociocultural alignment of the enterprise

In order to cope with agile and flexible ways to work, organizations undertaking Digital
Transformations projects are required to consider changes in roles and responsibilities across
multiple business units. These changes must be delivered consistently while considering
systematic changes in processes, technology, and data. Understanding such associations is a
challenge while factoring complexities of EA design, where aspects such as culture and social
alignment should be also a priority (Babar & Yu, 2019). This requirement goes beyond
traditional organization structure and mapping established in current EA practices by imposing
new ways to collaborate among actors, minimizing inter-team dependencies and inter-silo
coordination (The Open Group, 2019). Examples of results from successful alignments of social,
technological, cultural and process perspectives are DevOps and Agile oriented teams.

“Changing the organizational structure is not enough. It is key to change the culture, the ways of
working, and the management system” (The Open Group, 2019). Digital transformations
transcend conventional architectural principles, striving organizations into new ways of
operating and most importantly, collaborating. EA approaches should absorb new DT-driven
culture across the entire enterprise and outline its relationships across actors, technology, data,
and underlying business processes. Data-driven decision making, data-sharing, peer trust, team
autonomy, and agile development are examples of how organizations foster DT cultures in
22
 Problem Investigation | CHAPTER 2

organizations and EA must be able to relate, structure and integrate these elements in the best
possible way.

2.2.2 Enterprise Architecture practices for Digital Transformation

Enterprise Architecture practices are defined through a great variety of tools, techniques,
methods and frameworks. This section examines the state-of-the-art regarding EA approaches in
the context of Digital Transformations. Hence, these subsections address research objective 2.a.

2.2.2.1 Architecture frameworks

The Open Group Agile Architecture Framework™

Though recently launched, The Open Group has published the Open Group Agile Architecture
Framework™ or OAAF (The Open Group, 2019), oriented to cover both the Digital and Agile
transformation of the enterprise. OAAF provides the essential core concepts of agile architecture,
playbooks as guidelines to solve agile architecture problems, patterns that describe types of
solutions that can be applied to a variety of problems and finally methods, developed to solve
problems using hands-on experiences. As this represents a first version of the framework, The
Open Group refers to the specification as a “Snapshot” instead of an approved standard. Topics
and key concepts covered by this snapshot version of the framework include: continuous
architecture in an Agile world, designing business models, discovering and analyzing customer
insights, architecting digital platforms, architecting an adaptive operating model, architecting the
enterprise’s Digital Transformation, defining a Minimum Viable Architecture (MVA) and
finally, leveraging event-driven architecture to design modular systems and modernize legacy
systems.

The framework highlights the importance of how the Digital Enterprise is complemented by the
Agile Enterprise and vice versa. Companies walking the trail of Digital Transformation face
great challenges of adopting digital models from using legacy systems while committing
resources and efforts to become an effective and agile enterprise. The modular framework is
meant to assist architects to shape Digital Transformations by including systems thinking view of
architecture formulation (combining both emerging and intentional design), modularity and
loosely-coupling to foster agility, dictionaries to bridge concepts of each discipline and an
outside-in framework that starts from clients’ pains and expected gains. As depicted in Figure 9,
the dual transformation of the enterprise is motivated by two major components: customer
experiences that influence Digital Transformation and project-to-product shift which embodies
Agile Transformation.

The OAAF framework relies on bringing together each domain of the enterprise with its own
body of knowledge to deliver high-quality products and services to customers. As an illustration,
marketing brings new disciplines such as design thinking, IT provides flexible and adaptive
23
 Problem Investigation | CHAPTER 2

technologies by adopting Agile ways of working, and business operations are looking to leverage
automation provided by software platforms in order to develop operational excellence. Therefore
OAAF recognizes the value of each concept brought by each discipline including domain-driven
and event-driven design, job-to-be-done, design thinking, etc. Additional modeling concepts
such as capability modeling help to guide the modular decomposition of the enterprise and its
systems.

Figure 9. O-AAF Big Picture (The Open Group, 2019)

In contrast to other EA frameworks who require big design upfront, the OAAF is designed as a
“plug and play” framework where organizations identify the elements required to be changed
using OAAF the agile architecture foundations and proceed to the framework’s playbook to
enable the change. Further, the framework does not prescribe a process or a strict order;
architects can refer to playbooks as the tools and start steering the organization to real digital
transformations. Despite the recognition granted to the development of TOGAF by the
community of practitioners, the OAAF is proof that existing frameworks and methodologies are
not enough for organizations to walk the difficult trail towards successful Digital
Transformations. A brief discussion of the main fundamental concepts and guidelines provided
by OAAF are presented below. The fundamentals concepts outline the building blocks of the
framework, whereas the guidelines offer solutions to solve different agile architecture problems.

OAAF Fundamental and Building Blocks

Continuous Architectural Refactoring

An important aspect of developing architecture is considering its “evolvability” i.e. the ability for
the architecture to be changed or evolve over time. The architectural refactoring needs to be
guided and incremental (Ford, 2017). In the TOGAF standard, for instance, the concept of
architecture evolution is related to Change Management. However, the concept goes beyond the
adoption of a monitoring process for managing architectural changes based on individual
requirements. The increasingly fast pace of the technological industry, the adoption of Agile
24
 Problem Investigation | CHAPTER 2

approaches at scale, the failure of expensive high-profile long-running projects have made
organizations built-in “ease-of-change”. Evolutionary architectures are the ones that have no
end-state (Ford, 2017). The framework presents three enablers or considerations for planning for
successful continuous architectural refactoring as described in Table 5:

Table 5. OAAF considerations for continuous architectural refactoring

Enabler/Consideration Objective

Understanding and Aims at understanding the conditions under which the organization
Guiding the Architecture operates and influences the architecture evolution, and placing the
necessary structures that will allow the architecture to evolve
within those constraints. Three key components of the enabler are:
1. Constraints: Forces that influence architecture evolution
e.g. financial, cultural, technical, regulatory, political, time-
based.
2. Fitness functions (Ford, 2017): Allow architects to ensure
that systems’ characteristics remain constant over time.
Represent a physical tangible manifestation of constraints
and architecture goals.
3. Guardrails: Are conceived as lightweight governance
structures preventing people to get off track based on what
the organization is expected to do.

Creating the Right Reinforces the concept of empowering teams to iteratively make
Technical Environment architectural changes by embracing the practices of continuous
integration and continuous delivery (CI/CD), and
componentization. The latter leads to the development of loosely-
coupled architectures to support the organizational evolution on an
ongoing basis. CI/CD, on the other hand, prevents the formation of
“long-running” branches by integrating developers' work into
unified build processes and allows developers to make architectural
changes with the confidence of not breaking any functionality that
directly impact business users.

25
 Problem Investigation | CHAPTER 2

Enabler/Consideration Objective

Creating the Right Non- Poses the importance of developing an architecture roadmap, as
Technical Environment architecture refactoring needs to be guided and incremental. A
roadmap should meet the following key criteria to achieve
continuous architecture refactoring:
- Vision: A target end state is established as a way to assess
individual changes.
- Step-wise: intermediary steps need to be included between
“as-is” and “to-be” states.
- Flexible: Target and intermediary states may evolve as the
understanding of the architecture and its constraints evolve.
- Open: The architectural roadmap is available to the whole
team and everyone must feel empowered to comment on it.

Architecting the Digital Enterprise

As illustrated in Figure 10, the core of the enterprise, the new digital age requires organizations
to shift from outputs to outcomes-driven architectures. An interesting point of view, from a car
manufacturing company, is the way they look at the product based on how the customer uses it
rather than how it is created/delivered. In addition, modularization design stimulates the
composition of systems in parts that are loosely-coupled. This brings many benefits: first, it
enables parallel working in order to shorten capability or product development lead times,
second, reduced impact introduced by changes in segments of the system, therefore, making it
resilient to change, and third, failures in part of the system are less likely to propagate to the
entire system. These constituents for architecting the Digital Enterprise are supported by the Set-
based Concurrent Engineering (SBCE) method coined by Ward & Sobek (2014) in contrast to
the Big Design up front styles.

Enclosing the model in Figure 10, key areas of development are identified. The business model
is critical to elaborate on the innovative value proposition to be delivered by digital
services/products. Moreover, strategic marketing enables the enterprise to discover what the
customer wants and how the competition (if any) provides it. Customer insights provide key
inputs to help define an innovative value proposition, whereas customer journeys help teams and
management “walk in the shoes” of their customers. The digital platform acts as an enabler that
scales and grows rapidly and efficiently, providing business models high levels of automation
and self-service capabilities. Ultimately, the adaptive operating model takes advantage of
modularity and composability to gracefully adapt to changing customer experience requirements.
Tools such as service blueprinting help to bridge customer journeys with required and to-be-
developed capabilities.

26
 Problem Investigation | CHAPTER 2

Figure 10. Architecting the digital Enterprise (The Open Group, 2019)

Architecting the Agile Transformation

The OAAF constantly reminds us that architecting the digital enterprise goes hand-in-hand with
architecting the agile transformation. This building block refers to the importance for the
organization to cover three major areas: first, adopting a new way of working, second, deploying
new management systems and third, changing the organizational structure. This new way of
working encourages rapid iteration and experimentation which promotes continuous learning,
fact-based decision making, cohesive cross-functional teams coached by leaders and lastly,
performance orientation by peer pressure. In essence, the organizational structure is flattened
where the management system cascades goals at all levels of the organization and promotes
constructive dialog. The framework highlights the importance of the inclusion of the enterprise
culture as an additional dimension towards the agile transformation. Figure 11 depicts the model
of how the agile transformation can be assessed, where changes to a dimension will require the
deployment of new elements on another.

Figure 11. Agile transformation proposition (The Open Group, 2019)

27
 Problem Investigation | CHAPTER 2

OAAF Playbooks and Guidelines

Minimum Viable Architecture

The concept is mainly based on the term Minimum Viable Product (MVP) coined by Ries (2011)
defines as: “that version of the product that enables a full turn of the Build-Measure-Learn loop
with a minimum amount of effort and the least amount of development time”. The purpose of
MVP is to assess whether or not a product meets customer expectations, minimizing the time and
investment required to experimentally verify the product. Its adoption has become increasingly
popular where agilists have coined the term Minimum Viable Architecture (MVA).

Rather than embracing the concept as a good enough architecture by opposition to big-up-front
designs, or the minimum architecture work required to create an MVP, the OAAF associates
MVA to the minimum definition of the intended architectural vision entirely based on the
heuristics for structuring architecture decisions. The heuristics include: focusing on focusing on
decisions that require architectural thinking, delay architecture decision supported by Set-Based
Concurrent Engineering (SBCE) to optimize when architecture decisions are made, the inclusion
of evolvability as a key non-functional requirement, and adoption of “sacrificial architectures”
(Fowler, 2014) as part of experimenting with MVP.

Adaptive Operating Model

The rise of the complexity of the digital enterprise requires going beyond process architectures
toward rethinking operating models. Designing operating models starts from a clear formulation
of the enterprise value proposition according to specific variables e.g. value delivery chains,
organization structure, location, information exchange, suppliers and management system.
OAAF characterizes the adaptive operating model by a flatter and modular organization, with a
loosely-coupled information system and autonomous accountable teams driven by an agile
culture.

The modular nature allows the operating model for a “plug-and-play” reconfiguration in
response to evolving customer feedback. Later on, analysis of customer journeys can be
performed at every stage of particular processes, identifying channels that support the
interactions with the user as well as the required or missing set of capabilities. Figure 12
illustrates an example of service blueprinting as a tool to analyze customer journeys.

28
 Problem Investigation | CHAPTER 2

Figure 12. Customer Journey service blueprinting (The Open Group, 2019)

Agile Governance
The TOGAF Standard defines governance as: “the ability to engage the involvement and support
of all parties with an interest in or responsibility to the endeavor with the objective of ensuring
that the corporate interests are served, and the objectives achieved”. Governance is
conventionally required to reconcile what can be described as conflicts of interest, agreements,
responsibilities and keep updated involved stakeholders on the contracts that have been made. In
Agile, governance is a balancing act between accountability to a contract and the autonomy of
teams to ensure that goals/objectives are achieved. An Agile governance structure must adhere to
known bodies of regulation i.e. Corporate and IT governance while developing the Enterprise
Architecture aligned with the goals and objectives of the organization. Policy-making groups still
exist, but architecture models are not imposed or defined by them. It should be an outcome as a
result of the collaboration from IT and business units. Co-creation is an important feature of agile
governance delivered through cooperation teams such as centers of enablement or innovation
hackathons.

Legacy Integration and Modernization

Legacy systems are still growing in size and complexity for many of the organizations
embarking on Digital Transformation initiatives. The need to connect new digital capabilities
and modernize legacy applications is achievable by a progressive journey from monolithic to
modular architectures. In other words, the objective of this guideline is to provide a roadmap to
help progressively architect the overall system into a loosely-coupled one. Figure 13 illustrates
this journey. The steps toward modularization are briefly described as follows:

1. Build RESTFul API domain extensions to the legacy systems. The use of mediation
technologies is required to translate the legacy data types into API data types.

29
 Problem Investigation | CHAPTER 2

2. Segregation of both the Front-end and Back-end development by jointly defining APIs
that cater the need from both sides.

3. Begin modularizing the monolith by formalizing boundaries between sub-domains.

4. Increase modularization by creating microservices aligned with the context of the

boundaries, with the help of Domain-Driven Design (Evans, 2003). Shift toward event-
orientation by implementing Event Sourcing patterns.

5. Shift from ACID to BASE (Basically Available, Soft State, Eventual consistency).

Figure 13. Monolithic to modular journey (The Open Group, 2019)

Adaptive Integrated Digital Architecture Framework

As proposed by Masuda & Viswanathan (2019); Masuda et al. (2017), the Adaptive Integrated
Digital Architecture Framework (AIDAF) supports and promotes IT strategies toward Digital IT.
Technologies leveraged by this framework are Cloud Computing, mobile IT and Big data.
Additional concepts include an architecture assessment model, a global
communication/knowledge management model and a risk management model integrated into
AIDAF. Additionally, it complies with agility elements brought by new Digital IT application
systems while coping with each phase defined in System Development Life Cycle (SDLC). An
overview of the strategic architecture framework is shown in Figure 14, where the main
components of AIDAF and related models are placed across two separate dimensions; the
elements of agility published by Gill (2014) composed by speed, responsiveness, feasibility,
leanness, and learning in the vertical axis and the phases of SDLC in the horizontal axis.
30
 Problem Investigation | CHAPTER 2

Figure 14. Strategic architecture overview AIDAF and related models (Masuda & Viswanathan, 2019)

The elements and related models of the AIDAF framework are composed into:

1. Adaptive Integrated Digital Architecture Framework—AIDAF: Represents the overall

architecture structure of an adaptive framework to promote digital transformation through
the adoption of technologies such as Cloud Computing and mobile IT. The model
integrates both EA frameworks such as TOGAF and the Adaptive EA cycle model as
illustrated in Figure 15.

2. Assessment meta-model in Architecture Board: Embodies the board for architecture

review regarding solution architectures of the new digital IT projects on the basis of
defined evaluation criteria. The assessment model assists in reviewing requirements in
shorter times to respond to concerns and business requirements with a lean structure of
architecture deliverables such as roadmaps, as-is (i.e. current) and target architectures.

3. GDTC model for global communication on enterprise portal: The Global Digital
Transformation Communication (GDTC) model consists of the effective knowledge
management process on digital architectures reviewed by the architecture board as part of
AIDAF. It provides the mechanisms for which architecture artifacts are shared involving
architecture guidelines on a learning basis.

4. Social Collaboration Model for Architecture Review in Architecture Board (SCM):

Enacts as the collaboration and communication mechanisms offered to the architecture
board performed on the enterprise portal and social networking services of the
organization. SCM aims at achieving great collaboration between the Architecture Board,
top management and PMO members.

31
 Problem Investigation | CHAPTER 2

5. Strategic Risk Mitigation Model for Digital Transformation (STRMM): Represents the
risk mitigation model toward digital transformation. Risks are mapped based on the
actions performed by the Architecture board review, where proper mitigation strategies
are suggested.

Figure 15. AIDAF proposed model with TOGAF (Masuda & Viswanathan, 2019)

Essentially, the EA framework depicts in Figure 15 the integration of an EA Adaptive cycle

(lower section) with TOGAF or any other simple EA framework (upper section) for different
business unit divisions. The Adaptive cycle provides initiation documents, including conceptual
architecture designs, for new cloud/mobile IT-related projects that are constantly elaborated on a
short-time basis. TOGAF and other simple EA framework based on business or operational units
are able to respond to different policies and strategies from a mid to long term perspective.
Therefore the upper-level of the framework allows the selection of an EA framework in line with
the characteristics of each business division operational process and future architecture.

The Lightweight Enterprise Architecture Framework

Nandico (2016) proposes a lightweight Enterprise Architecture framework for organizations

confronted with Digital Transformation scenarios with an agile development approach. As
illustrated in Figure 16, the framework itself is based on TOGAF, adopts definitions of its
content meta-model and follows the Architecture Development Method (ADM). Service-oriented
architecture building blocks set the foundations of this approach, focusing on self-contained
pieces of work with specific business purposes as atomic elements for any architecture. Further,
the framework is intended to be used as minimalistic as possible, where core viewpoints and vital
pieces of information are collected, structured and maintained by the architecture team.

32
 Problem Investigation | CHAPTER 2

Figure 16. TOGAF ADM for LEAF

LEAF is characterized for structuring its deliverables from two different, yet aligned
perspectives: the enterprise level and the project level. The enterprise-level aims at providing
high-level representation of business domains and logical components to be placed in pursuit of
the target architecture and how this latter gets implemented addressing properly the stakeholders
concerns. On the other side, the project level results in a more detailed blueprint of individual
defined projects that enable a digital transformation program. Table 6 provides a brief
description of the viewpoints in the LEAF approach for Digital Transformation initiatives.

Table 6. Viewpoints from Lightweight Enterprise Architecture Framework (Nandico, 2016)

Viewpoint Description

Architecture Vision Compiles Business Domains models (abstract areas of

knowledge, rules, policies, views, etc.) from top-level value
chains. Further statements per domain are described and a view of
high-level logical components is produced based on business
requirements, objectives, and goals.

Describes the measures (e.g. business and technological

Architecture Action Plan capabilities), required to get the target architecture implemented.
Outlines the set of work required to develop and deploy the
architecture required to deliver a DT program.

33
 Problem Investigation | CHAPTER 2

Viewpoint Description

Ensures that individual projects of the DT program contribute to

Architecture Outline the action plan and to the realization of the architecture vision.
Projects are placed into the domain models and requirements
aligned with stakeholders.

New business services are determined at the right granularity

Conceptual View from required business capabilities in the architecture context.
Business services are mapped and related to defined business
domains.

Application services derived from business services are structured

Logical View into logical application components i.e. ideal to-be applications,
differentiated by business domain. Associated technology to be
applied goes according to architectural knowledge.

The usage of Commercial-off-the-shelf software or Cloud

Physical View solutions is evaluated to cover logical components and their
respective services. Gap analysis is performed to check the
coverage of provided information systems and fulfilled
requirements.

Deviations are drawn from checking the actual project

Architecture Governance architecture against the architecture outline. Mitigation actions
should be undertaken to alleviate deviations from the architecture
vision and architecture action plan.

2.2.2.2 Architecture methods

In contrast to Enterprise Architecture frameworks for Digital Transformation, methods found in

the literature address a specific set of concerns across several domains of the enterprise. A set of
simplified reference architectures, models, processes, analysis techniques, top management
questionnaires, etc., integrate the body of knowledge as additional mechanisms to enhance
current architecture approaches.

It has been clear that data-driven approaches are essential to enhance existing business processes,
achieve operational excellence and improve customer intimacy (Gartner, Inc. 2017). Thus, the
overall performance of the organization increases when decisions are made supported by existing
data and information. As seen in Dremel et al. (2017), an organization can benefit from creating
separate business units to handle innovation projects for Digital Transformation. Thus, a clear

34
 Problem Investigation | CHAPTER 2

need to restructure organizational business units was performed by creating a so-called

“Innovation Hub” to leverage Big Data Analytics. Consequently, interdisciplinary collaboration
was exploited between the IT, the Innovation Hub, and the sales and marketing departments.
Capability Management (CM) should be integrated as part of the core process to create cross-
functional teams to develop successful data-driven strategies within organizations.

An aggregation of approaches called “Digital Innovation and Transformation Process (DITP)” is

proposed by Wißotzki & Sandkuhl (2017). As depicted in Figure 17, the method begins at
“Specifying a Concept” with a clear business purpose. The “Find Digital Potentials” phase
follows with a digital analysis of relevant digital approaches that could be relevant for the
business concept e.g. research of digital trends in different sources such as the Gartner Hype
Cycle (Gartner, Inc. 2019). Then, the “Design New Business Model” stage presents the
elaboration of a well-structured business model based on each architect's personal preference tool
selection offered in the area of Business Model Management (BMM). Later on at the phase
“Record your Capabilities”, the organization must identify the required capabilities by the
current and future enterprise to deliver its intended business model. To do so, guidelines for
Capability Management (CM) in order to collect, model and carry out gap analysis are required.
For the last two phases “Engineer the Architecture” and “Transform Your Company”, the
process relies on Enterprise Architecture Management (EAM) to draft a model that includes the
required architecture objects and their dependencies to deliver the intended business model. In
addition, the transformation part rolls out from a pilot project to the actual implementation of the
project as an operationalized business model based on EA.

Figure 17. DITP method proposed by Wißotzki & Sandkuhl (2017)

35
 Problem Investigation | CHAPTER 2

Similar to the BMM segment view introduced above, an integrated architectural value
perspective combined with a service-oriented view is presented by Zimmermann et al. (2018).
Figure 18 provides a general structure of digital strategy as the value-oriented framing for digital
transformation. Value-oriented modeling supported by both business model canvas (Osterwalder
& Pigneur, 2010) and value proposition canvas (Osterwalder et al. 2014) is mapped to the digital
business operating model (Ross, Weill & Robertson, 2006). Thus, the business process
standardization and integrations are identified in order to materialize new digital services and
products to be delivered to customers. Value elements and results from the business model
canvas are mapped into the architecture value models of EA. Semantically associated products
and digital services are structured within services and product composition models following
composite patterns (Gamma et al. 1993). Additionally, well-formulated Digital Transformation
strategies set stronger foundations for better Enterprise Architecture development. Guidelines for
top management as the one presented by Hess et al. (2016) contribute to the success of new
digital business models. Strategic questions from this method are grouped into the dimensions
proposed by (Matt, Hess & Benlian, 2015) to evaluate all relevant aspects from a Digital
Transformation.

Figure 18. Value Perspective of Service-Dominant Logic (Zimmermann, et al. 2018)

Studies reviewed in this research highlighted the importance of agility and multi-level speeds
across the architecture to successfully deliver Digital Transformation initiatives (Bossert, 2016;
Horlach, Drews & Schirmer, 2016). Companies that are born digital do not face any challenges
of adopting technology compared to longtime established organizations, who have struggled with
legacy systems for many years. Furthermore, moving an entire company at the pace of a digital-
born company is unlikely to happen. Bossert (2016) has proposed a “Two-speed Architecture”
lined-up with the bimodal concept defined by Gartner, Inc. (2020f) as “the practice of managing
two separate but coherent styles of work: one focused on predictability; the other on
36
 Problem Investigation | CHAPTER 2

exploration”. The approach essentially establishes the separation of an organization’s elements

into those that require quick changes in response to dynamic customer experiences (fasts speed
architecture) and those who represent the integrity of transactions e.g. operational support and
legacy systems (transactional architecture). Though it focuses on the IT domain, the approach
deals with the rigidities of the stable transaction architecture as well as the fast release cycle
essential to cope with customer-facing environments.

Figure 19 depicts the reference architecture and building blocks of the two-speed architecture,
where technologies and software deployed on the upper level of the diagram are focused on
customer experience and interaction channels whereas the lower part contains slower cycle
release technologies e.g. stable high-quality master data management platforms. At the fast speed
architecture front, the method relies on microservices architecture to foster innovation and agility
of deployed digital services.

Horlach, Drews & Schirmer (2016) relate to the previous approach with an alignment model
between traditional IT, digital IT and business as shown in Figure 20. Agile and customer-facing
systems access on a frequent basis customer data managed by systems supported by traditional
IT. Decentralization of Digital IT can lead to conform to non-IT business units and achieve a
greater level of alignment. So-called “bimodal IT” leverages emerging tools and platforms for
agile customer front-end systems while supporting traditional mission-critical backend systems.

Figure 19. Building blocks of the Two – speed architecture Bossert (2016)

37
 Problem Investigation | CHAPTER 2

Examples of such emerging technologies include modular infrastructure and cloud service
solutions. Besides, concepts of this approach can be applied to the field of business intelligence,
where traditional IT is concerned around profound business objectives and security, where
Digital IT focuses on further BI activities such as predictive and prescriptive analytics.

Figure 20. Traditional IT, digital IT and business bimodal alignment (Horlach, Drews & Schirmer, 2016)

Due to its popularity, TOGAF and ADM both set the foundations of various methods and
techniques briefly discussed in this section. However, modifications are made to these
methodologies to fit the nature of Digital Transformation projects by structuring relevant
building blocks in response to the elements discussed at the introduction of this section
(Enterprise Architecture building blocks for Digital Transformation).

Molnár & Őri (2018) introduce the concept of hypergraph based formalism for EA
representation. The approach based on TOGAF’s meta-models elaborates on the use of
hypergraphs to use formal mathematical analytical methods for discovering misalignments
among IT strategies, information systems, and information architecture. Hence, it provides a
method to check and control inconsistencies across several structures of the architecture, setting
the right course for the organization to embark on Digital Transformation journeys. Additional
studies have also focused on performing assessments on the current state of alignment between
the business and IT by revisiting governance strategies as an effective tool for coordinating and
achieving digital transformation (Őri & Szabó, 2018). Thus, in the latter study an Enterprise
Architecture Management model, based on TOGAF and ADM, is introduced to discover and
analyze misalignment symptoms connected to DT initiatives based on the concepts of both EA
and Enterprise Engineering (EE). Similarly, TOGAF with ADM is once more adopted by other
methods such as the one introduced by Hafasi & Assar (2016) to customize the framework into
four focus areas: unified data views, stakeholder management, EA vision, and EA repository. In
short, each of these core subjects provides problem-solving tools to steer into Digital
Transformation projects.

A different approach towards Digital Transformation is introduced by Bondar et al. (2017),

where the Zachman EA framework (Zachman, 1987) is accommodated for architecting Systems
of Systems (SoS) for emergent behaviors. The collective behavior of simpler parts of a system is
38
 Problem Investigation | CHAPTER 2

conceptualized as emergent behavior, which arises from the cumulative actions and interactions
of the constituents of an SoS (Bondar et al. 2017). The classification schema provided by
Zachman is integrated with the layered SoS architecture of Hsu et al. (2009) to describe and
organize primitive architecture information of complex entities. Essentially, the architecture of
SoS can leverage the mechanisms to effectively manage, recognize and exploit emergence
behaviors in organizations. Thus, the approach handles evolving structures through the
architecture of SoS creating a strong input for Digital Transformation endeavors.

2.2.2.3 EA and industries undergoing Digital Transformations

The reviewed literature for this research pointed to several industries including the public sector,
manufacturing, financial sector, logistics, and healthcare who rely on EA mechanisms to support
Digital Transformation in organizations. Though not all the cases integrate standardized EA
mechanisms, methodologies or approaches, they still provide relevant architecture deliverables
critical for industries to embark on Digital Transformation as part of their digital business
strategy. In this subsection, research objective 3.a is discussed.

Temel & Ayaz (2019) used architecture design for improving product and energy efficiency in a
tire manufacturing plant. Kassner et al. (2016) presented the SITAM reference architecture that
enables the realization of the data-driven factory alongside the exploitation of big-industrial data
across the entire product life cycle. Moreover, Dremel et al. (2017) restructured the organization
and underlying business processes to establish a mature Data Analytics strategy for digital
transformation in the automotive industry. Extension of EA meta-models is introduced by
Schirmer et al. (2016) that contribute to IoT based projects performed at the Port of Hamburg.
Thus, interrelationships among projects were understood, improving decision making processes
for the future development and roll-out of IoT at the port authority.

In the banking industry, Sia, Soh & Weill (2016) highlighted the importance of mapping the
digital capabilities across several structures including processes, people and technology.
Enterprise Architecture is vital for setting up the foundations of the operational back-end of the
financial institution, yet equally important for standardizing technologies in preparation of new
digital transformation across the entire organization. Furthermore, Enterprise Architecture
requires agile mechanisms to cope with the new digital era in the Healthcare industry as per
Masuda & Viswanathan (2019). AIDAF acts as a complement to current methodologies such as
TOGAF’s ADM and even going further integrating DT risk mitigation management, social
collaboration models and global communication structures implemented in a pharmaceutical
company. Finally, Helfert, Melo & Pourzolfaghar (2018) present an EA reference model for
designing and transforming smart services that address concerns regarding different aspects of
the smart city e.g. noise monitoring service. Hence, EA can assist in simplifying the complexities
brought by Smart Cities innovation projects promoted by municipalities in the public sector
industry.
39
 Problem Investigation | CHAPTER 2

2.2.3 Comparative Analysis of EA Frameworks for DT

As a result of investigating the state-of-the-art regarding EA frameworks for Digital
Transformations, Table 7 compares the main three approaches discussed in section 2.2. First, the
three EA approaches are applicable enterprise wide, i.e. the frameworks are intended to cover all
domains of the enterprise. Moreover, one of these approaches is designed specifically to develop
a Digital Transformation under certain emerging technologies, i.e. Cloud and Mobile IT in the
case of AIDAF. Secondly, two out of the three methodologies are based on TOGAF, specifically
by adopting the ADM as the core of the EA development. Consequently, the execution method
of these approaches is cycled-based, while the OOAF is introduced as a “plug and play” method,
meaning it does not prescribe a beginning nor the end of an iterative process. Key concepts of the
Agile architecture fundamentals in OOAF provide the basis to address the enterprise-specific
needs.

On the other hand, there is no evidence of real-world implementations of the LEAF case
according to the literature. However, the AIDAF framework was successfully transferred as part
of the EA program at a pharmaceutical company. In the case of the OAAF, some of the
architecture foundations and guidelines are suggested as successful practices retrieved from
organizations’ experiences. Regarding architecture agility, both AIDAF and LEAF incorporate
as part of their customized frameworks, a simplified version of ADM. In AIDAF, the Adaptive
EA cycle makes the provision of the initiation documents, including architectural designs, for
new cloud /mobile-IT related projects that are continuously drawn up on a short-term basis
(Masuda & Viswanathan, 2019). The LEAF framework uses TOGAF and its content metamodel,
limiting it only to the phases relevant to undertake the Digital Transformation program. As per
OAAF, architecture agility is handled by managing the three transformation dimensions
presented in section 2.2.

Ultimately, architecture change is perceived differently in all three frameworks. LEAF imposes
the architectural governance as the mechanisms to manage and compile deviations of the
architecture outline. On the contrary, AIDAF manages change through the System Development
Life Cycle (SDLC) of the framework. The principles and concepts to address architecture change
in OAAF are under the continuous architectural refactoring concept. From a maturity
perspective, AIDAF is built upon results from previous studies performed by the authors of the
framework in addition to the transference of the framework in a real-world case scenario. On the
other hand, LEAF is introduced as a result of experience, delivered as a tool for enterprise
architects from a practitioner in a highly-recognized IT consultancy firm (Capgemini). The Open
Group has recently published the draft version of the OAAF framework (July 2019), with no
real-world implementation cases at the moment this thesis was written. Additional classification
concepts are borrowed from the EAF2 method (Franke et al. 2009), for categorizing EA
frameworks.

40
 Problem Investigation | CHAPTER 2

Table 7. EA frameworks comparative analysis

Dimension/criteria OAAF AIDAF LEAF

Enterprise reach All domains All domains All domains

Technology-based No Cloud/Mobile IT No

TOGAF based No Yes Yes (version 9.1)

Execution method Ready-to-use set Adaptive cycle Cycle based on

of guidelines attached to TOGAF TOGAF ADM
ADM or other

Real-world Limited Yes No

implementation

Architecture agility Agile Adaptive EA short- Simplified

transformation term cycle lightweight ADM
dimensions cycle

Architecture change Continuous Managed through Architecture

architecture AIDAF SDLC governance
refactoring

Level of maturity Low Medium Medium

Maintenance Not included Included Included

Process
Architecture Governance

Included Included Included

Guidelines/Principles

Building Blocks Limited Limited Included

Patterns Included Not included Included

Roles/skills Limited Included Included

Maturity Model Included Not included Not included

41
 Problem Investigation | CHAPTER 2

2.3 Case Study: EA for Digital Transformation at Intel®

In the whitepaper presented by Singh (2019), Intel provides an overview of their Enterprise
Architecture efforts to provide a framework for Digital Transformation, helping them essentially
to “bring order to chaos”. In essence, this subsection addresses research objective 3.b.

Enterprise Architecture is defined at Intel as applying technology advancements across the entire
architecture ecosystem to radically change the way the company operates, competes and grows
across businesses and geographies. On the other hand, a DT for Intel refers to the use of
technology that generates, stores and processes data to achieve a fundamental change to an
organization’s day-to-day business.

2.3.1 Business Problem

The company recognizes the need to adapt to necessary transformations and technology
disruptions not only to survive but to thrive. In today’s highly competitive and fast-paced
marketplace, the continuous success of Intel hinges on quickly adapting to market disruptions
and opportunities through innovation and Digital Transformation. Despite the fact that the
company had included EA as part of its enterprise capabilities, business challenges and
associated negative effects came to light, forcing the company to embrace a new EA approach.
Obstacles faced by the organization and their negative effects included:

- Inconsistent approach to EA from several IT organizations. This created an imbalance of

EA resources and skill sets across Intel IT.
- Business and IT strategies were not aligned due to weak integration between IT and
business units (BUs). IT was perceived as an order taker and PC supply organization
rather than a business partner.
- Business and IT units worked in silos, with little or no partnership.
- Intensive labor required to analyze the impact of any change, or identify areas of
improvement much needed for DT.
- Slow-moving pace to keep up with change required at Intel business and technology
landscapes.
- The architecture was created and managed in silos along with lacked consistency and
cohesiveness of end-to-end integration between architecture domains i.e. business, data,
applications, and technology (BDAT).
- Difficult track of the technology debt or technical gaps due to lack of visibility into EA
building blocks. Cases to which Intel refers to the concept of technical debt are:
- Redundant applications that enable similar business processes and functions.
- Duplicate IT services for infrastructure, platforms, database solutions and more.
- Solutions that are not consuming reusable assets.

42
 Problem Investigation | CHAPTER 2

- Reducing/avoiding/de-commissioning custom-coded solutions and integrations

that implement non-differentiating capabilities.

2.3.2 Enterprise Architecture Solution

On their journey towards a successful Digital Transformation, Intel decided to reformulate the
approach to EA. Essential parts of the solution include the participation of people, establishment
of new processes and technology, alongside the incorporation of a new EA operating model. In
addition to this, Intel took advantage of TOGAF as a means to materialize their EA goals. This
section briefly describes two of the main parts of the solution exploited by Intel for enabling
business transformations.

2.3.2.1 EA Operating Model for DT

After researching commonly used EA operating models, Intel decided to pursue a Federated
model given the size of the company. This model deployed a centralized architecture group
under the CTO and architects in other value streams and solution groups. The new EA
organizational structure is depicted in Figure 21. For the organization, value stream groups are
generally verticals such as finance, marketing, supply chain, and human resources, whereas
solution groups are horizontal units specialized by domains e.g. information security, platforms,
infrastructure, and Enterprise Architecture. New entities were created as part of the new
operating model to support EA efforts.

Figure 21. EA operational model at Intel Singh (2019)

EA Center of Excellence (CoE): Supports directly Intel’s overall Digital Transformation and
defines practices and principles for delivering uniform, cohesive and consistent architecture
blueprints for all BDAT domains. Furthermore, the CoE promotes innovation, simplifies and
modernizes architecture deliverables, reduces technical debt and enforces the reusability of IT
assets.

Technical Workgroups (TWG): Work cohesively to develop and deliver EA standards. TWGs act
as mediators to deliver the strategic vision for EA across the BDAT domains. These groups are
43
 Problem Investigation | CHAPTER 2

in charge of maintaining the IT asset inventory and repository. These include services/APIs,
applications, infrastructure components, business processes, data models, policies, run/build
analyses, and capabilities.

EA community of Practice (EA CoP): Responsible for delivering a uniform, cohesive and
consistent reference EA that is aligned with EA principles, guidelines and policies. This group
discusses and shares best-known methods, practices, and learnings. The EA CoP through
learning continuously and sharing wins by socialization, functions as a fast track to deliver
architecture blueprints and remove any existing barriers.

EA Compliance and Governance: Acts as an EA governance process to ensure that solutions

comply with EA policies, principles, guidelines and standards, driven by committees. These
work in tandem with other entities e.g. for understanding the EA principles and keeping solutions
compliant, while the CoE is responsible for an overall EA compliance health check.

2.3.2.2 EA in Practice for Digital Transformation

A second major component of the EA solution deployed at Intel includes the use of the TOGAF
Architecture Development Method as the basis of a high-level, eight-step process that enables
the organization to achieve EA objectives. Figure 22 illustrates the cycle by following the
industry-standard EA framework. The activities that comprise the method are:

1. Moved by a business outcome statement (BOS), reference architectures are associated

with each of the digital business transformation outcomes of the organization and as a
result, strategy development is enabled. The digital business transformation outcomes
included: productive workforce, engaged customers, reimagined and optimized decision
making and operations and new products and services.

2. A course of action maps the strategies to capabilities and capabilities to business

processes. The process addresses the identification of gaps in value streams that execute
the strategy and accommodate business architecture elements to alleviate the gaps if
necessary.

3. The portfolio management approach provides insights into the organizations’ current
solution offerings. Capabilities are then mapped to solutions offerings, enabling the
company to run a gap analysis to address the new business requirements. Plans and
efforts are built based on the results of such analysis so that goals can be met.

4. Management and source of the required internal or external resources are performed so
that plans can be executed. This step is essential for executing the plans defined in the
previous phase.
44
 Problem Investigation | CHAPTER 2

5. Support continuous delivery as the foundation of architectural refactoring. The EA tool

supplies complete insight into the artifacts of the digital ecosystem of Intel (reuse, build
or buy). Faster decisions can be made based on an instant impact analysis of the
architecture.

6. Services are built and managed to provide support to solutions, leveraged by close
communication between Agile teams.

7. Systems of record are defined for business process rules, data bindings, and data
transformations with full visibility into the BDAT architecture domains of the EA.
Integrated business and data architectures are delivered through application architecture.
Intel uses the definitions of Gartner listed in Table 8, to differentiate enterprise systems
on their Enterprise Architecture approach for Digital Transformation.

Table 8. Systems classification for Digital Transformation

System Type Description

System of record Defined as an established legacy application or homegrown
system in support of core transaction processing that manages the
organization critical master and transactional data. The change
rate of these systems is low.
System of differentiation Represent application components that commission unique
company processes or industry-specific capabilities. The change
rate of these systems is moderate.
System of innovation Portray new systems that address new business requirements and
opportunities. Rate of change is high.

8. Governance is implemented for all the BDAT domains. The facilitated risk or compliance
issues can be identified from storing integrated IT data artifacts into a common
architecture repository. For instance, applications containing sensitive data are not
allowed to be hosted in a demilitarized network zone or cannot store information without
unencrypted server environments.

45
 Problem Investigation | CHAPTER 2

Figure 22. EA development process developed at Intel Singh (2019)

2.3.3 Organizational Impact and Results

Changing the EA approach towards Digital Transformation allowed Intel to achieve significant
progress and results. This mainly reflects the ability of the company to properly handle industry
disruptions and react to change in an agile way. The new EA model delivered Intel great
business value through architecture simplification, modernization, and automation. A summary
of the benefits and business value brought by the new EA program are listed in Figure 23:

Figure 23. Business results from adopting new EA approach for DT

46
 Design Analysis | CHAPTER 3

3 Design Analysis
After investigating the core concepts, state-of-the-art, and impact in practice in relation to the
research problem, this section infers the objectives of the intended solution. Aligned to the stages
of the DSRM of section 1.4, this section addresses research objective 4.a. In essence, the artifact
objectives serve two purposes, first, to align requirements with solutions as part of the proposed
building blocks of the EA methodology for DT, and second, to use them as evaluation criteria
during the validation step of this research.

Objectives of the EA methodology for DT

Findings from the SLR, specifically the ones addressing RO1, assembled the Digital
Transformation constituents to be addressed by the Enterprise Architecture practice. These
elements represent the foundations and catalysts for DT, incorporated as part of the solution
artifact presented in this thesis. In addition, the investigated frameworks and methods, analysed
as part of the RO2, revealed a set of guidelines and directions, critical for the implementation of
EA in response to DT programs. Moreover, the case study discussed in section 2.3 related to
RO3, provided useful lessons and valuable insights that contribute to a better definition of the
solution artifact. Figure 24, illustrates how the objectives to be achieved by the artifact, defined
in section 4: Artifact Design, relate to the main research question introduced by the thesis.
Consequently, the main objectives to be fulfilled by the EA framework for DT include:

3.1 Design an interdisciplinary organization

An organization that aligns business and IT into collaborative units is delivered from the analysis
performed within a focus area of the reference model. The methodology presents an
organizational structure that characterizes a flexible way to work and collaborate, minimizing
inter-team dependencies. The new proposed interdisciplinary teams have clearly defined roles
and responsibilities. The new organizational structure is aligned with the architecture principles
and organizational culture promoted by the DT project.

3.2 Promote modularization and decoupled building blocks

The reference methodology conveys architecture modularity through the decomposition of social
and technological elements. By adopting atomic building blocks such as services as part of the
architecture development process, the artifact encourages the establishment of well-defined
business boundaries, maximizes the reuse of IT assets, and limits the impact of change to other
domains of the architecture.

3.3 Simplify the Enterprise Architecture cycle

The presented method avoids at all costs complexities brought by big designs up-front and
simplifies the architecture development process in order to deliver a Digital Transformation
47
 Design Analysis | CHAPTER 3

program more agile to the organization. Consequently, a minimum set of essential deliverables
are documented as part of each of the stages or phases of the methodology. In addition, the
artifact compiles methods, reference architectures, and models that ease the architecture
development needed for DT across all domains i.e. business, application, technology, and data.
Moreover, the artifact utilizes a simplified meta-model version of the ArchiMate language to
reduce the complexity of architecture views part development cycle as concluded in the Intel
case.

3.4 Convey business agility through architecture design

This thesis embraces the concept of architecture agility as the way in which enterprise agility is
conveyed through architecture design. Through the implementation of the artifact, architecture
models and social structures definitions are able to portray how business agility is materialized
for the organization. These models include methods such as designing bimodal IT or two-speed
architectures and structuring cross-functional teams that enable faster business services and
operations of the envisioned Digital Transformation initiative. Furthermore, the proposed
framework allows the definition of lightweight mechanisms or governance controls to reconcile
architecture governance with the autonomy of architecture teams in charge of contributing to an
overall architecture vision.

Figure 24. Artifact objectives mapped to main research objectives

48
 Artifact Design | CHAPTER 4

4 Artifact Design
This section presents the Enterprise Architecture framework for Digital Transformation, as well
as the foundations of the artifact, the architecture development cycle, activities, and intended
deliverables required to convey successful Digital Transformations into organizations. In
addition, the artifact compiles methodologies and practices, discussed in the literature study as
part of the Enterprise Architecture development process. Ultimately, the session addresses
research questions 4.b and 4.c.

Enterprise Architecture Framework for Digital Transformation

The framework reference, depicted in Figure 25, presents the building blocks and constituents to
be considered for the development of Enterprise Architecture for Digital Transformation
initiatives. From a top-down perspective, the drivers discussed in section 2.2.1 mark the
conditions under which the goals of the artifact are defined. The goals to be attained by the
Enterprise Architecture Framework for Digital Transformation (EA4DT) were described in more
detail in section 3. Furthermore, the requirements represent the basic needs and properties of the
framework to be materialized by architecture deliverables and guidelines, incorporated in the
architecture development cycle of EF4DT later discussed in section 4.3.

The EA4DT is greatly influenced by so-called “architecture catalysts'' or principles to stimulate

the development of modular, agile, and evolutionary architectures, considered as critical in the
context of Digital Transformation. The latter property refers to the concept of “evolvability”
coined by OOAF i.e. the ability of the architecture to be changed or evolved over time (The
Open Group, 2019). Therefore, the framework strives towards identifying the constraints and
architectural guardrails under which the Digital Transformation program will operate.

On the other hand, agility in EA4DT is conveyed through architectural design associated with
the technological and social elements of the enterprise. As a result, the framework incorporates
the principles of bimodal architectures and cross-functional organizations, as well as minimizing
substantially the documentation of architecture deliverables in order to shorten and accelerate
architecture learning cycles. In addition, EA4DT sees no use of elaborated design before the
implementation of a business initiative, therefore initial phases of the frameworks are meant to
be flexible and coarse with the sole purpose to effectively convey business agility into the
organization. Ultimately, the framework is guided by modular design thinking and driven by the
definition of decoupled and reusable components. The concept of building blocks is defined as
potentially reusable components to be combined with other building blocks to deliver
architecture and solutions (Harrison, 2018). As a result, the EA4DT employs the concept of
services as the core building blocks for the development of architectural solutions.

49
 Artifact Design | CHAPTER 4

In-line with the Franke et al. (2009), the following sections describe essential concepts
incorporated as part of the artifact i.e. principles and guidelines, the architecture development
process, and finally, roles and responsibilities needed to effectively govern and manage EA4DT.
As the proposed framework is delivered as a customization of ADM, additional conformance
aspects required to be described from the artifact are assumed equally applicable to the TOGAF
framework and not included in this document.

4.1 Framework essentials

Break the Digital Transformation vision into manageable parts: A Digital Transformation
initiative as depicted in Figure 25 comprises multiple levels of extent in relation to the EA
practice. In order to simplify the EA development and management while effectively delivering
the DT initiative, EA4DT proposes enterprise-level and project-level scope phases. At the
enterprise-level, the architecture vision and a coarse and flexible plan of action are defined,
whereas at the project-level individual decisions and solutions are proposed at a granular extent.

Use services as architecture building blocks: Towards the development of flexible, loosely
coupled, and highly resilient systems in-line with well-defined business functionalities, EA4DT
adopts services as the foundational building blocks for architecture design. Consequently,
changes or modifications in one service of the architecture only have limited impact on other
services, and failures are easier to isolate, making the overall system more resilient (The Open
Group, 2019).

Deliver a minimal set of essential architecture deliverables: The framework is intended to

deliver only the essential set of documents and models required at each stage of the development
cycle. This principle follows the maxim of LEAF to be “as minimalistic as possible” (Nandico,
2016). Additional deliverables should only be documented to cover specific stakeholders’
concerns. In EA4DT, viewpoints are considered core deliverables to depict conceptual, logical,
and physical service-oriented architectural decisions throughout the entire development cycle.

Design with clear business orientation: Every design and architecture decision must be made
having a clear intended business value and purpose. Thus, the framework must delineate the
value stream process to be offered by the Digital Transformation initiative and the possessed and
required capabilities of the enterprise. As a result, the customer journey is bridged with the
required capabilities. To do this, the methodology borrows the service blueprint design from
OAAF and employs elements from the motivational layer of ArchiMate.

4.2 Roles, skills and responsibilities

Aligned to Franke et al. (2009), an important aspect to describe from EA frameworks is the main
roles and responsibilities to be assigned throughout the entire architecture development process.
As listed in Table 9, the proposed roles for EA4DT are stated alongside the main set of
50
 Artifact Design | CHAPTER 4

responsibilities and specific skills required. Moreover, the stages of the designed artifact are
related to the roles so that clear boundaries and authority domains are delimited. This section
relies on the definitions and associations defined by the Enterprise Architecture role and skills
category section of TOGAF (The Open Group, 2018).

Figure 25. Enterprise Architecture for Digital Transformation

4.3 Architecture development cycle

The EA4DT incorporates a repeatable process illustrated in Figure 26 that addresses the goals
and objectives of the Digital Transformation initiative. First, the cycle is enclosed by the
architecture catalysts previously introduced so that all activities, deliverables, and guidelines are
aligned to the constituents for EA development in order to deliver a successful Digital
Transformation initiative. Once again, the EA4DT architecture development process is founded
on the ADM cycle and impersonates the architecture development structure of LEAF. In the
following sections, the phases of the Enterprise Architecture Framework for Digital
Transformation are introduced alongside each phase's associated activities and expected
architecture deliverables inputs and outputs.
51
 Artifact Design | CHAPTER 4

Figure 26. EA4DT Architecture Development Cycle

52
 Artifact Design | CHAPTER 4

Table 9. EA4DT Roles, skills and responsibilities

Architecture Role Overall responsibilities Relevant skills EA4DT phases

Enterprise architect - Clarifies and agrees on architecture context - Service design and modelling - Architecture context
with stakeholders and manages changes - Architecture principles design - Architecture vision
- Defines principles and guidelines for - Architecture views and - Architecture action plan
architecture development viewpoints design - Architecture governance
- Delivers high-level architecture roadmaps - Change management

Project architect - Formalize the architecture outline - Change management - Architecture outline
- Manage change at project-level - Project management - Conceptual, logical and
- Maintain conceptual, logical and physical - Benefit analysis physical architecture
architecture deliverables - Architecture governance

Business architect - Determine business services required to realize - Business modelling - Conceptual architecture
business capabilities - Service design - Logical architecture
- Associate business objects as input/output of - Architecture views and - Physical architecture
each business service/function viewpoints design
Project Domain Architects

Data architect - Identify associated data entities to business - Data modelling

objects flowing through IS services - Architecture views and
- Contribute to model logical service components viewpoints design
- Promotes data stewardship and governance

Application architect - Extract the required information system - Service design

services from defined business services. - Systems behaviour
- Model logical application components in - Architecture views and
accordance to the business structure viewpoints design

Technology architect - Define technologies and platform services in - Service design

support of application components - Systems integration
- Determine COTS, cloud platforms or reuse - Architecture views and
exiting components to deploy solutions viewpoints design
53
 Artifact Design | CHAPTER 4

4.3.1 Architecture context

Digital Transformations are at all times business-driven, business-oriented, and business-centric
perspective initiatives (Matt et al. 2015). Therefore, delineating a business strategic map that
triggers the architecture development cycle of EA4DT is a critical prerequisite to conduct a
successful program. The power of a Digital Transformation lies in its scope and objectives (Kane
et al. 2015). As a result, the architecture context preparation phase is proposed by the
framework. The architecture context compiles the business mission, vision, objectives, strategy,
and constraints that provide the business rationale for the Digital Transformation endeavor
(Nandico, 2016). In EA4DT, the Preliminary phase of ADM is embedded into the activities and
considerations performed as part of the architecture context and architecture vision.

The architecture context is, in essence, the input for the architecture vision to trigger the
architecture development cycle in EA4DT. In a more evolved business-value design world, this
research has pointed out some methodologies that define innovative digital offerings to
customers such as design thinking and job-to-be-done, These concepts are meant to be used for
architectural design throughout the development cycle to avoid any kind of misalignment.
Among other expected materials to be received and processed by the enterprise architect to start
the architecture vision are the organization value chain and business models on a page for Digital
Transformation e.g. business model canvas (Osterwalder & Pigneur, 2010) and the value
proposition canvas (Osterwalder et al. 2014). After grasping the business idea and motivation for
the Digital Transformation program the next stage begins.

4.3.2 Enterprise-level phases

4.3.2.1 Architecture vision

The architecture vision phase compiles all the required set of business tactics that will guide the
intended projects for the Digital Transformation program. In addition, the enterprise architect
provides a clear organization structure upon which the initiative is delimited. In contrast to ADM
and in line to LEAF, the architecture vision is perceived as assigned architecture work that
responds to the business request for Digital Transformation.

Main activities
- Map enterprise capabilities with value streams: Existing and required capabilities are
mapped to value streams according to the business goals and objectives defined in the
architecture context. EA4DT uses the TOGAF approach to deliver the enterprise
capability model in combination with the service blueprint from OOAF The value stream
and capability elements from ArchiMate serve the Enterprise Architect to produce the
model.

54
 Artifact Design | CHAPTER 4

- Define architecture principles: Derive the architecture principles from the architecture
context. TOGAF defines a template to define architecture principles (The Open Group,
2018).
- Define EA operating model: Depending on the organization size and scope of the
initiative an EA operating model is defined and structured. The operating model can be
centralized, distributed, or federated as described in the EA at Intel case (Singh, 2019).
- Outline target and baseline architectures: A high-level baseline and target architecture
models are outlined. As the model is strongly supported on a service-oriented design, the
architecture models must depict services realized across all domains of the architecture.
The layered viewpoint of ArchiMate provides a valid overview structure to portray
existing services in the baseline architecture and desired ones in the target architecture.
- Structure cross-functional organization: According target architecture, cross-functional
teams are arranged. The organization view will reflect how the services are meant to be
operationalized and maintained. OAAF provides a first approach to structuring cross-
functional teams. An ArchiMate model of the organizational is provided here.

Table 10. Input and output architecture deliverables for the Architecture Vision phase

Input documentation/deliverables Output documentation/deliverables

- Business mission, vision, and - EA operating model
goals - Enterprise capabilities value
- Business strategy models for streams cross model
DT initiative - Architecture principles
- Target architecture model
- Baseline architecture model
- Structure cross-functional
organization

4.3.2.2 Architecture action plan

In this phase, the necessary program of works to realize the architecture vision is defined. From a
TOGAF perspective, the Opportunities and Solutions and the Migration Planning phases of
ADM (phases E and F) are assembled into a coarse and flexible plan of action in EA4DT, seen
as the subsequent phase of the Architecture Vision (phase A) of ADM. The architecture plan of
action is not an elaborate plan, however, it serves as valuable input for the portfolio and roadmap
to be further detailed by project managers to address other concerns e.g. availability and
knowledge of resources and investment plans.

Main activities
- Outline a high-level action plan: Defines an overall plan by means of transition
architectures or parallel projects within a timeline to implement the envisioned
architecture for DT.
55
 Artifact Design | CHAPTER 4

- Determine constraints and guardrails: Identify the forces and conditions that influence
the architecture evolution. Based on this, lightweight mechanisms are proposed to
prevent projects from getting off track as proposed in OAAF.

Table 11. Input and output architecture deliverables for the Architecture action plan phase

Input documentation/deliverables Output documentation/deliverables

- Architecture context - Architecture coarse plan of action
- Architecture vision - Project constraints and guardrails

4.3.3 Project-level phases

4.3.3.1 Architecture outline

The architecture outline for each project defines its contribution to the architecture vision and
architecture action plan. As a result, assembling individual projects in EA4DT for the Digital
Transformation program shall result in the realization of the business vision. The project
architect in collaboration with the enterprise architect, determine the each project requirements in
line with the architecture action plan. In conformity with TOGAF’s architecture vision, the
architecture outline in EA4DT also defines what is to be included, and what is excluded from the
scope of the individual project.

Main activities
- Specify project requirements: Both the enterprise architect and the project architect
specify the requirements to be fulfilled by a particular project based on the architecture
action plan..
- Define project scope: The extent of the project is determined in collaboration between the
project architect and the enterprise architect.
- Register project outline: An agreement in form of the architecture deliverable is signed
off by the architects and the related stakeholders involved in the project.

Table 12. Input and output architecture deliverables for the Architecture outline phase

Input documentation/deliverables Output documentation/deliverables

- Architecture action plan - Architecture outline
- Project proposal - Project update in domain
model

4.3.3.2 Conceptual architecture

A strong foundation of this phase is the development of a conceptual architecture framed by
service-oriented design and implementation. In EA4DT, this stage represents the identification of
business activities compacted into a service to be delivered by the project. In order to outline a
56
 Artifact Design | CHAPTER 4

consistent architecture, baseline services are also recognized so that a gap analysis can be
performed based on the business objectives to be attained, always keeping in mind the
architecture principles from the Digital Transformation initiative.

Main activities
- Define business services: Based on the project’s requirements the required business
services are encapsulated at a granular level based on the target architecture. According
to Nandico (2016) “business services are atomic elements of business behaviour,
characterized by one goal or purpose, one activity and one role executing this activity”.
Business objects are represented as input and outputs form using a business service.
- Portray business service collaboration: For the individual project, business services are
mapped to depict their dependencies across business objects. The business, application
and technology service elements from ArchiMate are meant to be utilized to produce the
viewpoint.
- Derive required information services: Information systems services are defined in the
scope of the project in line with the business services identified.
- Derive required platform services: Platform services are defined in the scope of the
project in line with the business services and technology expectations from the Digital
Transformation.

Table 13. Input and output architecture deliverables for the Conceptual architecture phase

Input documentation/deliverables Output documentation/deliverables

- Architecture context - Service gap analysis
- Architecture vision - Business service collaboration
- Architecture outline view
- IS services catalog
- Technology services catalog

4.3.3.3 Logical architecture

Based on the identified business services and the derived application and technology services
from the conceptual architecture phase a logical organization of application components is
carried-out. In addition, the data architect of the project must address concerns regarding data
management and data migration to meet requirements and constraints of the target architecture of
the project. The Data Architect acts as a data steward aligned to interoperability principles and
governance standards such as the European Interoperability Framework to facilitate the
deployment and operation of complex digital environments, a critical aspect in making a digital
transformation possible (European Commission, 2015). Moreover, Domain Driven Design
supports the modernization of legacy systems in progressive journeys from monolithic to
modular architectures that serve Data Architects to deliver highly interoperable and independent
systems.
57
 Artifact Design | CHAPTER 4

The logical architecture represents a customization of the Information systems architecture phase
of ADM focused on the scope of the project established during the architecture outline phase.
However, depending on the complexity of the requirements and the scope of the project further
activities and models must be delivered to address the stakeholders concerns.

Main activities
- Model applications components: Logical application components are modeled based on
the business and information systems services in scope of the project. Further architecture
decisions are made in order to modularize and reduce dependencies across application
components. The application architect can rely on two-speed architecture design (Bossert,
2016) to model fast-changing elements alongside slower-release, transactional and stable
architectures intended to coexist in a short-term Digital Transformation program. The
Application elements from the ArchiMate standard provide the necessary elements to
produce the logical architecture model for the project.
- Model technology components: Logical technology components are modeled to support
the specified application components. Required platforms and technologies are specified
as part of the mapping process. The simplified meta-model ArchiMate language provides
the essential technology elements to outline the model.
- Application classification: In line with the interest of the DT initiative, a clear distinction
is made between systems of record, systems of differentiation and systems of innovation.

Table 14. Input and output architecture deliverables for the Logical architecture phase

Input documentation/deliverables Output documentation/deliverables

- Business service collaboration - Application and technology
view component views
- IS services catalog - Data/application classification
- Technology services catalog

4.3.3.4 Physical architecture

The main goal for the physical architecture is to deliver a physical technological solution for the
project. The technology architect assesses solution deployments considering the architecture
principles for Digital Transformation. Moreover, the evaluation process leads to the use of new
technologies and infrastructure services i.e. cloud computing or COTS to achieve the desired
requirements for the project as well as selecting existing platforms.

Main activities
- Derive technology solutions: Considering the logical architecture for application and
technology services, the technology architect evaluates alternative solutions. As part of
the process, the architect must choose to reuse IT assets before buy, and buy before
building solutions from scratch (Singh, 2019).
58
 Artifact Design | CHAPTER 4

- Design physical architecture: Selected solutions from the physical architecture must be
modeled and associated to reflect the required interactions for the implementation.

Table 15. Input and output architecture deliverables for the Physical architecture phase

Input documentation/deliverables Output documentation/deliverables

- Logical components architecture - Physical architecture solution
(Application and Technology) components
- Design physical architecture

4.3.3.5 Architecture governance

The Architecture Change Management and Implementation Governance phases are simplified
into the phase of Architecture Governance in EA4DT. Contracts defined for every project
alongside the governance operating model established early in the development cycle, provide
the necessary mechanisms to keep the realization of the project under an acceptable level of
control. In addition, architecture reviews between the enterprise and project architect ensure
proper change management and propagation into the DT program.

Main activities
- Review project architecture: In a collaborative action, the domain architects, the project
architect and the enterprise architect assess the conceptual, logical and physical
architecture and inspect if the requirements of the architecture outline are met.
- Propagate changes: Depending on the complexity of required changes and their nature,
the change management process is triggered. This specific process follows the principles
of the TOGAF standard for Enterprise Architecture Change Management process (The
Open Group, 2018).

Table 16. Input and output architecture deliverables for the Architecture governance phase

Input documentation/deliverables Output documentation/deliverables

- Project outline - Architecture vision or project
- Project’s Conceptual, logical amendments
and physical architectures

4.4 Comparison between LEAF and EA4DT

After having described the foundations, the roles, skills, responsibilities, and the architecture
development cycle of EAFD, Table 17 makes a clear distinction between the presented
framework and LEAF by listing the main differences of both EA approaches for Digital
Transformation. The EA4DT incorporates in its development cycle key concepts found to be
relevant in the process of architecting the digital enterprise in order to potentialize the
architecture catalysts earlier described. Moreover, the artifact provided by this research relies on
59
 Artifact Design | CHAPTER 4

the capabilities of the ArchiMate 3.1 standard to describe, communicate, and analyze different
concerns of EA in the context of Digital Transformation. Ultimately, while both approaches
share terminologies and a structure for architecture development, the EA4DT complements and
reinforces LEAF with fundamental methods and guidelines retrieved from the literature in
support of the core objectives of this research i.e. stimulate business agility, simplify architecture
development and promote collaboration between IT and business units.

Table 17. Comparison between LEAF (Nandico, 2016) and EA4DT

Concept LEAF EA4DT

Modelling language Non-proprietary (generic) ArchiMate 3.1 (simplified)

EA operating model Not included Architecture vision: EA operating

model

Architecture evolution Architecture governance Architecture action plan:

Constraints and guardrails

Architecture modularity Service-oriented approach

Content meta-model TOGAF-based

Architecture agility Agile for architecture Architecture vision:

development principles Cross-functional teams
Physical Architecture: Two-
speed architecture/bimodal IT

Business value design Architecture vision: Architecture vision: Capabilities-

Enterprise value chain value streams map

Sociocultural alignment Not included Conceptual vision: Cross-

functional teams

Additional Architecture Integrated Architecture OAAF (The Open Group, 2019)

references and support Framework (Van't Wout Two-speed IT: Bossert (2016)
et al. 2010) Bi-modal IT: Horlach, Drews &
Schirmer (2016), Intel EA case
(Singh, 2019)
SITAM (Kassner et al. 2016)

60
 Artifact Implementation and Validation | CHAPTER 5

5 Artifact Implementation and Validation

In this section the Technical action research and the expert opinion validation and evaluation
mechanisms are carried out within an organization undergoing a Digital Transformation
initiative. As a result, this segment addresses research objectives 5.a and 5.b.

5.1 Introduction to the case

Apollo Tyres Ltd is the world's biggest tyre manufacturers, with annual consolidated revenues of
US$2.28 billion (March 2018), with 69% of its revenues from India, 26% from Europe and 5%
from other geographies. The company has a manufacturing presence in India and Europe with
approximately 5K retail dealers in India and 5,8K dealer outlets in Europe. In 2009, Apollo
Tyres acquired the Dutch tire manufacturer Vredestein Banden B.V., hence, renaming the brand
as Apollo Vredestein B.V. Later in 2013, the research and development (R&D) operations for
Europe were established in Enschede (Netherlands), where the Vredestein global brand plant and
distribution center is located. As of today, the European region is composed of 12 subsidiaries
with the European headquarters office located in Amsterdam (Netherlands). Apollo Vredestein
B.V. (AVBV) basically offers a twofold brand portfolio for the European market; the premium
Vredestein tires brand, and the mass brand Apollo Tyres line. AVBV produces tires for different
customer segments including passenger car, agricultural, and bicycle tires. The plant located in
Enschede produces around 6,4M car tires and 543K agricultural tires per year. A considerable
well-established partner ecosystem allows AVBV a frequent supply of tires to some recognized
automobile and tractor manufacturers across the world such as Audi, Mercedes-Benz, Volvo, and
John Deere.

AVBV and its products have been recognized for their quality in the industry for many years.
From the IT perspective, AVBV has deployed multiple systems throughout the years to address a
particular set of concerns raised by the business. However, high demands to rapidly materialize
new business requirements and the increasing complexity of IT are now forcing the company to
embark on well-recognized best practices and methodologies to line-up business strategy with IT
solutions. In response to these concerns, the Enterprise Architecture (EA) program initiative was
recently launched. The program is focused on the first stage to map business, application, and
technology elements to structure the first architecture version of the organization. Desired
architecture state will be further developed based on the vision and business strategy defined by
top-level management and executives at AVBV.

In the meantime, the European IT division is visualizing a new data and analytics (D&A)
strategy with the assistance of the recently structured Enterprise Architecture program. Some
time ago, AVBV assembled the Reporting Service Team (RST) for the purpose of promoting the
development of business intelligence, delivering basic descriptive analytics to multiple Business
61
 Artifact Implementation and Validation | CHAPTER 5

Units (BU) of the organization. Still, new upcoming requirements and expectations from the
business demand these team functions to be further developed. As a Digital Transformation
initiative, the project is intended to deliver a data and analytics plan of action in-line with the
interests of senior-level management. This research project is delimited by the application and
validation of the Enterprise Architecture Framework for Digital Transformation for the D&A
initiative. The main difficulties from the existing reporting services provided inside the
organization include:

 Limited staff and infrastructure resources: Local resources scarce for the
experimentation and deployment of new data and analytics capabilities. The current team
is limited to support and develop descriptive reports to the organization.

 Lack of business and IT collaboration: Both BUs and IT do not collaborate for the
definition of business reports. This behavior has created siloed teams that have a direct
impact on reports interpretation and data literacy.

 Lack of data and analytics vision and strategy: The RST operates as a conventional
IT-oriented division. There is little sense of data and analytics innovation and evolution,
considering the great amount of business know-how the team possess.

The envisioned D&A program, intended to support critical BUs for the European division, bring
the following opportunities to AVBV:

 Explore new data and analytics technologies: Cloud computing provides the
opportunity for organizations to experiment with new technologies at a low cost.
Therefore, AVBV sees the benefits of using the public cloud as a vehicle for innovation
to materialize the D&A vision.

 Develop a data-driven culture at AVBV: Data must be considered a valuable asset as it

contributes to the growth of the organization. Therefore, the D&A program provides the
starting point to see its value and contribution at every level of the business.

 Enhance decision-making processes: Reliable insights based on high-quality data are

translated into better decision-making processes for AVBV senior management.

As time was a constraint at the moment this research was performed, the validation of the project
does not include the iteration of the EA4DT cycle for all the proposed projects defined during the
Architecture Plan of Action phase. Instead, the validation of the Project-level phases within
EA4DT contemplates a single project and its development until the Architecture Governance
phase of the cycle
62
 Artifact Implementation and Validation | CHAPTER 5

5.2 Implementation of the Artifact

The application of the EA4DT to the D&A initiative at AVBV is documented in this section.
Therefore, the research question 5.a is addressed in this part of the document.

5.2.1 Architecture Context

After introducing the Digital Transformation initiative at AVBV for Data and Analytics, the
Architecture Context compiles the business rationale that motivates the development of the
Enterprise Architecture Framework for Digital Transformation. Here the goals, objectives, and
scope are described, followed by the three-segment strategies defined by the organization to
undertake the Digital Transformation.

5.2.1.1 Initiative scope

The D&A program contemplates the Financing, Supply Chain, and Sales departments of AVBV.
Consequently, no other business units are considered to be part of this initiative. In addition, the
program is intended to enhance the current descriptive reporting capabilities and offer new
predictive data and analytics services for the exclusive use of the European division. As a short-
term project, the D&A initiative does not incorporate the collection, storage, and analysis of
unstructured data sources provided by on-going implementations associated with IoT or Big Data
solutions. The D&A project, however, sets the foundations for the integration of future D&A
capabilities that demand reliable infrastructure and secure platforms to support data lakes, real-
time streams data ingestion, real-time streams analytics, and big data processing.

5.2.1.2 Data and Analytics strategy and principles

The D&A strategy defines three main areas that are meant to guide the initiative. As listed in
Figure 27, the focus areas of the strategy include data-driven culture at AVBV, data management
and governance, and robust, flexible, and secure infrastructure.

Figure 27. AVBV strategy for Data and Analytics initiative

63
 Artifact Implementation and Validation | CHAPTER 5

As the initiative aims at providing enhanced internal services, AVBV includes a people, process,
and technology perspective to ensure a complete view over the elements the organization
requires for the D&A project to be delivered.

5.2.1.3 Business goals, objectives and requirements

Figure 28 depicts a compact view of the business goals, objectives and requirements to be
achieved with the Data and Analytics project.

Improve line-of-business D&A adoption

The increasing need to empower employees and business units is vital to cope with the
difficulties of having limited resources and infrastructure for delivering effective reporting
services. By leveraging self-service data consumption, users across the organization are self-
sufficient and licensed to elaborate reports according to their particular needs without the
intervention of IT. On the other hand, effectively embracing a managed D&A solution can be
achieved by diminishing shadow analytics, providing users real-time processed information that
prevents them from creating ineffective data and analytics siloes.

Improve BUs decision-making

AVBV desires that BUs impacted by the D&A initiative, improve their decision-making
processes based on reliable and valuable information. These can be achieved by pursuing the
enrichment of data as an augmentation mechanism that assists the BUs in making more informed
decisions. Moreover, improving data quality and accuracy, on the other hand, aims at identifying
the validity and correctness of business information produced within AVBV to be used as an
input for data and analytics. The latter is achieved by implementing a solution to manage master
data of the organization.

Improve reporting services and operations

The third goal of the D&A initiative is to improve reporting services and operations. Therefore
the business requires the reporting services unit to deploy cross-functional teams for enhanced
Business and IT collaboration and thus, reducing the times to produce reports based on new
specifications. Moreover, enhanced streamline data technologies for data ingestion, integration,
processing and delivery are leveraged to rapidly transform raw data into significant business
reports.

5.2.2 Architecture Vision

Once the main strategy and objectives of the Data and Analytics initiative are assembled, the
architecture work begins. The main deliverables from this phase include the architecture
principles, the enterprise capabilities with D&A value stream cross-mapping, the EA operating
model, and both the baseline and target architecture models of the business domain. In the case
of the D&A project, the models include the Reporting Services unit of AVBV.
64
 Artifact Implementation and Validation | CHAPTER 5

Figure 28. Goals, objectives and requirements from D&A initiative

5.2.2.1 Architecture principles

The following principles relate to the rules and guidelines that influence the decisions for
architecture design and development in the context of the D&A program across business, data,
technology, and applications.

 Business principle
Table 18. EA4DT business principle

Name Enterprise data literacy

Statement Information becomes a second language at every level of the organization.

Business units understand the support of data and analytics to their work and IT
professionals understand what their work represents to the business context.

Rationale Data literacy provides a solid foundation for enhanced decision-making across all
units of the enterprise.

Implications Business and IT teams must collaborate at all phases of the initiative. Cross-
functional teams cooperate in the design, implementation, and maintenance of
the D&A program.

 Technology principle
Table 19. EA4DT technology principle

Name Low-cost flexible and secure technologies

Statement Upfront investments to support the initiative must be low with flexible and
secure technologies and infrastructure used to experiment and deliver faster data
and analytics services to the business departments.

65
 Artifact Implementation and Validation | CHAPTER 5

Rationale Controlled financial spending is critical for the initiative based on the use of low-
cost flexible and secure technologies. Therefore, the principle stimulates the use
of technologies that allow experimentation and deployment of data and analytics
solutions while complying with security standards of AVBV.

Implications Technologies and infrastructure selected for the deployment of analytics solutions
must not require up-front licensing investment and annual support fees. In
contrast, platforms and technologies are preferably selected on a service-based
model.

 Data principle
Table 20. EA4DT data principle

Name Data is a valuable asset

Statement Created, shared and used data at all levels of the organization is indispensable
and managed accordingly.

Rationale Data is considered a key corporate resource. Positive outcomes for the business
are the result of using high quality and reliable data at the right moment.
Therefore, AVBV must carefully manage and use data.

Implications Proper governance mechanisms must be put in place to prevent, detect and take
action to ensure data quality and consistency. Systems of record and reference
are properly aligned to the Master Data Management (MDM) strategy of the
company.

 Application principle
Table 21. EA4DT application principle

Name Technology independence

Statement Applications employed as part of the initiative are not bound to any specific
technology and therefore can operate in a variety of platforms and infrastructure.

Rationale Independence of applications from specific technologies facilitates the

development, upgrade, and migration of the application components required for
the D&A initiative.

Implications The applications are deployed under wide-open standards and allow portability
between different platforms and IT infrastructures.

66
 Artifact Implementation and Validation | CHAPTER 5

5.2.2.2 Enterprise Architecture operating model

Given the size of the organization and the scope of the initiative, a centralized EA model is
chosen for the D&A program to be delivered at AVBV. The EA operating model presented in
Figure 29 depicts the EA team under the Head of IT Europe. Consequently, the lead enterprise
architect, the project architect, and each of the domain architects (data, business, application, and
technology) report directly to this organization. For the purpose of executing architecture
governance, the Enterprise Architect and project architect collaborate to review changes and
potential deviations from each of the projects defined in the Architecture plan phase of EA4DT.
Ultimately, each business unit manager i.e. the head of Sales, the head of Supply Chain, and the
head of Finance work hand in hand with domain architects to develop architecture work and
essential deliverables according to each individual project.

Figure 29. EA Operating model for D&A

5.2.2.3 Enterprise capabilities with D&A value stream cross-mapping

Enhanced business decisions are made based on the execution of the Data and Analytics
continuum value stream detailed in Figure 30. The sequence incorporates the key set of activities
to deliver analytics from end-to-end of the enterprise. Each of the stages of the data and analytics
continuum map the required and missing capabilities that create an overall result for each of the
stakeholders of the initiative. As a first step, data acquisition (data capture) represents the
collection of data at the source i.e. systems of record or systems of reference. Next, the
organization of data in a centralized repository is performed with the prior employment of data
profiling, cleansing, integration, and transformation capabilities. Master Data Management and
data enrichment create superior value in the analytics continuum as they provide the ability to
ensure data uniformity, stewardship, and semantic consistency as well as data augmentation.

67
 Artifact Implementation and Validation | CHAPTER 5

Later, data is analyzed by leveraging data preparation, predictive analytics techniques, and data
mining. At the end of the value stream, data is delivered and effectively distributed to all the
relevant stakeholders. Table 22 lists capabilities as defined by the DAMA guide to Data
Management Body of Knowledge DAMA-DMBOK Guide (Mosley et al. 2009) and other
relevant sources.
Table 22. Data and analytics capabilities definitions and references

Capability Source Definition

Data DAMA- Embodies the process of standardization and mapping

Transformation DMBOK Guide of data entities to corresponding target representation
(Mosley et al. upon identification of data errors.
2009)
Data Integration The data management function for consolidation data
from multiple sources and ensuring consistency across
controlled redundant data with a “golden version”.

Data Profiling Provides the capability to perform statistical analysis

and assessment of the quality of data values. It also
involves the exploration of relationships that exist
across value collections and data sets.

Data Cleansing Focuses on activities that correct and enhance values of

(Quality) data elements. Correction activities are pushed to
source systems whenever possible.

Master Data MDM is the process of defining how master data is

Management created, integrated and used throughout the enterprise.
(MDM) Master data is an authoritative, most accurate data
available about key business entities.

Predictive Is the capability to perform what-if analysis that allows

Analytics an organization and its users to create and test models
based on actual data, and then project future results.

Data Mining Refers to a technique in the area of data analytics. It

mainly focuses on revealing patterns in data using
various algorithms.

Descriptive Gartner, Inc. Represents the manual examination of data or content

Analytics (2020) characterized by traditional BI and visualization
techniques e.g. pie, bar charts, line graphs, tables or
generated narratives.

68
 Artifact Implementation and Validation | CHAPTER 5

Capability Source Definition

Data Visualization Gartner, Inc. A way to represent information graphically,

(2020b) highlighting patterns and trends in data, helping the
user to achieve quick insights.

Data Delivery Gartner, Inc. Refers to the optimal point of impact to where data is
(2017b) delivered, whether to support human activities,
embedded analysis into business processes or support
predictive analytic activities.

Data Migration IBM (2019) The process of transferring data from one computing or
storage environment to another.

Data Enrichment Allen & Cervo The process of enhancing existing information by
(2015) adding missing or incomplete data. Typically, data
enrichment is achieved by integrating external data
sources.

Figure 30. Data and Analytics capabilities with value streams mapping

69
 Artifact Implementation and Validation | CHAPTER 5

5.2.2.4 Baseline architecture

CONFIDENTIAL (AVBV internal use only)
Figure 31. Baseline architecture from Reporting Services AVBV (Confidential)

5.2.2.5 Target architecture

The envisioned architecture illustrated in Figure 32 introduces several modifications across the
business, application, and technology domains aligned with each of the stages of the analytics
continuum value stream. As a result, proper collection, cleansing, profiling, preparation, and
delivery of data is handled and the identified missing capabilities are now embodied. From a
bottom-up perspective, the target architecture will continue to retrieve structured data from the
original source databases by reusing the business logic contained within the ETL data integration
component. However, to ensure data quality and consistency of key master records e.g.
Customer, Product, Supplier, Material, and Account, heavily utilized by D&A services, a master
data repository and integration layer environment is blended. The MDM component acts as an
authoritative data governance mechanism to control master records across all data sources.

The layer on top of the AVBV infrastructure leverages a critical set of technological components
in response to the missing enterprise capabilities for advanced and predictive analytics. In line
with the architecture principles, the technology architect has seen an opportunity to employ
Cloud Computing as the backbone of the new analytics platform deployment and a solid
foundation for future implementations to support Big Data analytics for unstructured data. The
latter would also allow AVBV to deploy resilient distributed architectures. Furthermore, the
Cloud infrastructure allows the deployment of the columnar-store OLAP database, ideal for
hosting the data warehouse repository (DWH instance). Data migration to the new environment
from the local infrastructure will be required. A front-end application (BI server) supports online
access and business logic required to build and publish the dashboards containing the relevant
information to each report. For predictive analytics to be effectively conveyed, a runtime
environment that supports statistical computing and data mining (Advanced Analytics server) are
also merged into the solution architecture. Thus, models for regression (linear or nonlinear),
classification, association, or clustering can be implemented depending on the prediction
concerns applicable to each business unit. To enable online web access to the predictive analytics
results hosted in the Advanced analytics server (Data mining DB), a web application must be
deployed.

To increase the value of D&A services, data enrichment is leveraged by provisioning an

additional Data Preparation server where external APIs are consumed. Useful services for data
enrichment in the context of AVBV might include, for example, real-time weather and traffic
conditions to be used by predictive models for order shipment and stock provisioning. Prior to
merging data with the analytics repository, a preparation process is triggered to ensure only the
required values and metadata are included in the prediction datasets. For security and
70
 Artifact Implementation and Validation | CHAPTER 5

performance purposes the Data mining DB and the DWH instance are hosted in different
computing environments. Hence, computing resources are not shared and intrusive processes are
avoided. Moreover, secure network connectivity between local and cloud infrastructure is
addressed by using Virtual Private Networks (VPN) with the use of server-side or client-side
encryption mechanisms.

At the top layers including the Application and Business architecture domains, the self-service
reporting client will continue to provide self-service reporting functionalities for well -defined
operational and strategic business planning processes. Moreover, the application services for
predictive analytics reports supply the critical functionalities to a new business analytics
planning process. The last-mentioned brings together BU teams and IT by means of the assisted
decision-making collaboration. Ultimately, the Web IDE application component (Integrated
Delivery Environments) realizes predictive analytics development services to the organization.
As a result, continuous business analytics development processes are performed by joint
collaboration between three newly created roles: Data scientists, Business and Information
Analysts. Data scientists employ data mining algorithms on extracted datasets to produce
predictive analytics reports, whereas Information and Business Analysts personify a mixed role
of business and IT skills to constantly improve descriptive and predictive business analytics.
Further descriptions for each of the elements of the Target Architecture are detailed in the
Conceptual Architecture phase.

71
 Artifact Implementation and Validation | CHAPTER 5

Confidential AVBV
technology elements
Confidential AVBV technology
elements

Figure 32. Target architecture from Data and Analytics AVBV

72
 Artifact Implementation and Validation | CHAPTER 5

5.2.2.6 Cross-functional organization

An essential part of architecting the digital enterprise lies in decomposing the organization and
outline boundaries that minimize inter-team dependencies (The Open Group, 2019). Figure 33
depicts the cross-reference between business and IT units required to deliver the Data and
Analytics project. Therefore, teams are built by assigning a responsible for each intersection
point specialized in a particular business-oriented purpose e.g. sales, supply chain, or finance. As
a result of this proximity between IT and business experts, business requirements are delivered
faster and efficiently. The Master Data Management team does not follow this pattern as their
responsibilities include the management of business data entities across the entire enterprise.

Figure 33. Business and IT cross-reference teams for D&A program

The organizational structure view provided in Figure 34 illustrates the teams and roles associated
with each business unit for the D&A program.

 Business analyst: Responsible for ensuring that business reports, including descriptive or
predictive, are built according to use-case requirements. Provides extended business
knowledge to assist in the development of descriptive and predictive business reports.

 Information analyst: Ensures data is structured and available for distribution and access
across the repositories created for descriptive reports. Supports new requirements for the
creation or modification of descriptive business reports.

 Data integration specialist: Provides technical integration support to existing or new

sources of information across all layers of the technology architecture.
73
 Artifact Implementation and Validation | CHAPTER 5

 Data scientist: In charge of implementing prediction algorithms or advanced analytics

techniques to deliver predictive business reports based on business requirements.

 Data architect: Manages and provides access to master data repositories for analytics
purposes. The data architect belongs to a Data Management Service organization, in the
case of AVBV, the Center of Excellence (CoE).

Figure 34. Roles and teams structure for D&A operation

5.2.3 Architecture Action Plan

The architecture action plan for AVBV presents the necessary individual projects to realize the
Architecture Vision introduced in the previous section. The derived work packages were
extracted by analyzing the Target Architecture blueprint and the D&A strategy provided in the
Architecture context section. It is important to highlight that the development and
implementation of all the projects are required for the successful delivery of the D&A initiative
for the European division of AVBV.

5.2.3.1 High-level action plan

The action plan for the Data and Analytics program for AVBV is composed of four major
individual work packages or projects. The execution of these individual projects contributes to
the realization of the Architecture Vision. Figure 35 provides a concise view of the project
structure of the D&A initiative.

74
 Artifact Implementation and Validation | CHAPTER 5

 Master Data Management: Consists of all the activities related to the integration of
systems of records or reference to the Master Data repository. Furthermore, it exposes the
required services for the delivery of Master Data consumed by the D&A environment. At
the moment this thesis is written, the Center of Excellence (CoE) team has already begun
with the design and implementation of the MDM solution for AVBV globally.

 Provision Data and Analytics Services: It involves the deployment of the new
platforms that supply the required set of functionalities for both descriptive and predictive
analytics. This involves the conceptual design and logical association between the
application and technological components that materialize the desired business services
of the target architecture. Furthermore, the project outlines the optimal solutions for
deployment based on the initiative’s architecture principles defined. The project must be
developed without compromising the ongoing reporting services operations at AVBV.

 Data Analytics Design and Implementation: In here, the actual implementation of

advanced analytics solutions takes place to provide enhanced descriptive and predictive
reports for business units. According to the individual requirements for each department,
predictive techniques are implemented such as data mining algorithms or statistical
models with the support of programming languages (Python or R). Separated access to
high-quality refined datasets from the descriptive data analytics repository (data
warehouse) is utilized for the implementations. This particular project will require further
analysis and design from a Data Architecture perspective with defined business
requirements and expectations for delivered predictive analytics results.

 Information security: In line with the business and architecture principles and overall
D&A strategy, the information security project includes all the activities related to
implementing the required mechanisms to provide security at all levels of the
architecture. Since the D&A program has a strong foundation on the use of data, the work
package must secure data in all its states i.e. data at rest, data in motion, and data in use.
Ultimately, the Infrastructure and Cloud team must review and make certain that all
implemented solutions are compliant to corporate and external regulations.

75
 Artifact Implementation and Validation | CHAPTER 5

Figure 35. Defined projects and expected deliverables for D&A program

5.2.3.2 Architecture constraints and guardrails

To facilitate architecture evolution the following set of constraints and guardrails are described
for the D&A initiative. Constraints classified in Table 23 describe both the technical and
business limitations that influence the ability for the architecture to change over time.

Table 23. Constrains definition and classification for architecture program

Constrain Description Type

Transactional systems Transactional databases and core data sources will remain Technical
remain On-premise deployed locally under the domain of AVBV infrastructure.

Low impact platform As IT resources are scarce, software solutions and service Business
migration platforms must be chosen on a cost-effective basis with little
or no impact on migration activities from current
implementations.

IT resources are AVBV’s main business is to produce and sell tires not Business
justified on business implementing IT, therefore any additional resources must be
outcomes justified by tracing back its contribution to the organization.

On the other hand, proposed architecture guardrails are meant to be lightweight mechanisms
enforced by an oversight team for the project, in the case of the D&A program, the Architecture
Governance review board composed by the Lead Enterprise Architect and the Project Architect.
Therefore the principal architecture guardrails for the project are:

 Employ reference architectures: Project teams are expected to employ reference

architectures as part of the development of the logical and technological architecture
models. Best practices can involve practitioner-based or literature-based reference
architecture models. As part of the D&A project the SITAM reference architecture

76
 Artifact Implementation and Validation | CHAPTER 5

(Kassner et al. 2016) retrieved from literature is considered as a point of reference for the
technological foundations of both logical and physical architectures.

 CoE team support: AVBV’s corporate Center of Excellence (CoE) must assist
architecture teams with additional best practice and industry recommendations. Any
decision that deviates from the desired architecture state must be discussed with the CoE
and therefore justified with evidence on the architecture reviews.

5.2.4 Architecture Outline

The Architecture Action Plan introduced in the previous section presented four main projects
required to be executed in order to realize the Data and Analytics vision. For validation purposes,
this research project only examines one of the suggested projects for the remaining phases of the
EA4DT development cycle. Based on the short-term results it provides and its relatively low
dependency to other projects, the Provision Data and Analytics Services project is selected as the
candidate to further elaborate on the architecture outline and its associated conceptual, logical,
and technical architectures.

5.2.4.1 Project requirements

To effectively validate the contribution of the Provision Analytics Services project to the
architecture vision and consequently to the business requirements, the following project
requirements are defined into a granular level.

 Deploy descriptive analytics access service: The project must ensure the deployment of
the new descriptive analytics portal for internal use of the BUs part of the D&A initiative.
Functionalities of the service exceed current capabilities offered by Athena.

 Deploy prescriptive analytics access service: The project delivers a service for
managers form the Finance, Sales, and Supply Chain departments to consume predictive
analytics reports based on specific business requirements.

 Enable self-service reporting data access service: Each of the BU is granted access to
the particular data structure or data mart for the development of self-service business
reports. The service does not involve access to data sources that process results for
predictive analytics.

 Provision predictive analytics development service: An application service is enabled

for the implementation of business analytics for predictive purposes. The service is
intended to serve only the business analytics development process introduced by the
target architecture.

77
 Artifact Implementation and Validation | CHAPTER 5

5.2.4.2 Selected project scope

The Provision Data and Analytics Services project is outlined by the deployment of required
components and platforms in a cloud environment that enable access and consumption of
descriptive and predictive analytics reports. Moreover, the project includes the definition and
design of development services for predictive analytics implementations. Associated activities to
its future implementation involve the migration of automated processes (ETL jobs) and databases
(current data warehouse) to the selected cloud platforms.

The project does not include the design of predictive models according to individual business
requirements. For this specific concern, the Predictive Analytics Implementation project must be
executed. The definition of integration mechanisms for master data consumption must be
delivered as part of the Master Data Management project. Ultimately, the project does not
evaluate detailed network and security mechanisms for local to cloud data center
interconnectivity as it falls into the Security and Compliance project.

5.2.5 Conceptual Architecture

Based on the requirements and the scope established at the Architecture Outline for the Provision
Data and Analytics Services, the Conceptual Architecture phase gets kicked-off. In this phase,
the exposed business services are described and associated with key business objects, processes,
and roles. As a result, assembled business activities and teams portray a cross-functional
collaboration required to deliver and maintain the business service within AVBV. Later on,
information and technology services in support of business services are listed and described.

5.2.5.1 Business analytics development service

The first of the three business services for the Provision Data and Analytics Services project
addresses the development of business analytics reports for the Business Units involved in the
D&A initiative. Table 24 describes the main characteristics of the business service. Furthermore,
Figure 36 portrays the business services and its associated elements.

Table 24. Business analytics development service definition

Characteristic Description

Business The service aims at providing an internal business function to deliver

objective analytics reports based on detailed business specifications or requirements.

Business The business analytics development process compiles the set of activities
process required to collect, develop, and deploy the reports accordingly.

78
 Artifact Implementation and Validation | CHAPTER 5

Characteristic Description

Business roles Data Scientist, Information Analyst, Business Analyst (roles descriptions
provided in section Architecture vision: Cross-functional organization)

Business objects Analytics Business Report: Represents the expected outcome from
executing the business analytics development business process.

Analytics Report Specification: Embodies the business requirements or

specifications required to begin the business analytics development
process.

Information The Analytics Development service enables a collaborative advanced

Systems service analytics environment in support of business roles in charge of delivering
predictive reports implementations.

Technology Predictive Analytics Processing: Represents the exposed technology

services function for processing the implemented algorithm or technique to obtain
predictive results to present in a report.

Analytics Development Environment Access: Enables access to a

collaborative platform for the implementation and development of
advanced analytics.

Analytics Data Enrichment: Allows the business to gain more insights by

adding value to data through the use of third-party authorized data provider
services.

Figure 36. Business analytics development service collaboration view

79
 Artifact Implementation and Validation | CHAPTER 5

5.2.5.2 Business Analytics Reports Access

The second business service is centered on enabling access to business analytics reports to
entitled business units. Table 25 describes the main characteristics of the business service.
Furthermore, Figure 37 portrays the business services and its associated elements.

Table 25. Business analytics reports access service definition

Characteristic Description

Business objective The services essentially provide access to business actors to business
analytics reports fabricated and maintained by the Business Analytics
service.

Business process No business services realize this business service. However, it serves the
Operational and Strategic planning business process of authorized BUs.

Business roles SC/Finance/Sales Manager: Represent the main users of the business
service demanding continuous access to published predictive and
descriptive business analytics reports.

Business object Analytics Business Report: Represents the business object provided by the
business service and used throughout the Operational and strategic planning
process.

Information Predictive Analytics Reports Access: Provides the application user interface
Systems service to access predictive analytics reports.

Descriptive Analytics Reports Access: Provides the application user

interface to access descriptive analytics reports.

Technology Reports Web Portal Access: Exposes the technology functionality that
services allows the web portal to be deployed through a web interface. The platform
provides a single pane of glass for both predictive and descriptive business
report access.

5.2.5.3 Self-service Business Reporting

The third business service is associated with providing business reports access through a self-
service reporting model. Table 26 describes the main characteristics of the business service.
Furthermore, Figure 37 portrays the business services and its associated elements.

80
 Artifact Implementation and Validation | CHAPTER 5

Table 26. Self-service business reporting service definition

Characteristic Description

Business The business service stimulates data democratization. Processed business

objective datasets are exposed to the business units for self-service reporting
purposes.

Business process Analytics Business Report: Represents the business object provided by the
business service and used throughout the Operational and strategic planning
process.

Business roles SC/Finance/Sales Manager: Represent the main users of the service
demanding continuous access to business datasets through self-service
reporting mechanisms.

Information Analysts: Assist business users in the elaboration of self-service

reports and strengthen data literacy across AVBV.

Business object Analytics Business Report: Represents the business object provided by the
business service and used throughout the Operational and strategic planning
process.

Information Self-service data access: Connect processed data marts with business users
Systems service that require self-service reporting capabilities.

Technology Data Marts Data Access: Provides the technology platform to access
services specific segments of data according to business profiles.

Figure 37. Business analytics reports access and self-service business reporting services collaboration view

81
 Artifact Implementation and Validation | CHAPTER 5

5.2.6 Logical Architecture

Once the conceptual architecture phase is completed, the logical architecture defines the
underlying information systems and technology in support of the application services to be
consumed by the business. A critical part of the logical architecture involves structuring the
technical elements into a two-speed IT configuration to allow the evolution of fast-paced
services critical for the D&A initiative while supporting traditional mission-critical back-end
systems. The following activities further describe the deliverables of the logical architecture
phase.

Application and Technology Design

According to Figure 38, the information systems or applications to be deployed to support the
D&A analytics are essentially split into two fronts: the fast speed and the transactional
architecture. In the fast-speed front, applications can change at a considerably higher rate than
the transactional ones, i.e. they can be modified faster and even replaced if needed in order to
comply with business services defined in the conceptual architecture. On the other hand, the
transactional segment includes information systems that are more reliable and deliver the highest
quality.

Figure 38. Logical application and technology components view

As listed in Table 27, each system is classified into a system of record, a system of
differentiation, and a system of innovation simplifying the process of modeling application and
associated components. Ultimately, generic technological components are associated with the
application elements in order to extend the reach of the viewpoint and address stakeholder’s
concerns from the technical perspective.
82
 Artifact Implementation and Validation | CHAPTER 5

Table 27. Application components classification

Application Description Classification

Business Analytics Front-end application where users access to both System of

Reports Web Portal descriptive and predictive reports produced by the differentiation
analytics development service

Self-service Reporting client tool employed by users to produce System of

Reporting customized reports from defined data marts differentiation

Development Web Web development environment where predictive System of

Portal/Web IDE analytic results are executed and subsequently innovation
published to the Business Analytics Reports Web
Portal

Enterprise Data Consolidated enterprise repository where multiple System of

Warehouse sources of structured information are integrated for differentiation
analysis purposes.

External Data Represents an interface to trusted external data System of

Services services to be integrated with internally generated data innovation
and provide richer reports (both descriptive and
predictive)

Master Data Embodies the application repository that contains System of record
Management master business entities to be delivered to the D&A
data warehouse.

ETL/ELT The intermediary system that extracts, transforms and System of record
loads transactional data from multiple sources into a
denormalized data model in the data warehouse.

5.2.7 Physical Architecture

After defining the application and technical elements, the Physical Architecture is presented. In
line with the interest of senior management as described in the Architecture Context phase, the
physical architecture leverages emerging technologies i.e. cloud computing for deploying the
required infrastructure and platform services to be supported by the D&A initiative at AVBV

Technology Solutions Model

The diagram presented in Figure 39, represents the physical technological configuration to
comply with the requirements of the D&A initiative. The architecture model in this phase is
divided into two main segments: Azure Infrastructure Services and the local AVBV
infrastructure. An additional layer is presented for external data services integrations. The
purpose of the latter is to leverage external data services provided through secure APIs to

83
 Artifact Implementation and Validation | CHAPTER 5

consume data from external providers and enrich the defined data models for both descriptive
and prescriptive analytics. Regarding the local AVBV infrastructure physical technology
components, transactional data (OLTP) databases will remain on-premises as they represent the
data repositories of the most critical systems in support of the operations of the plant in
Enschede. Moreover, the Master Data Governance solution to be deployed as part of the MDM
project will also remain in AVBV’s local infrastructure due to hard dependencies to other local
systems and applications.

On the other hand, the Azure Infrastructure services comprise all the platforms required to
support the integration, transformation, ingestion and delivery of data. The components include
the Azure Data Factory service, Microsoft SQL Server RDBMS for data preparation and data
consolidation (data warehouse), SQL R services, ultimately, the power BI console service. All
the services will be hosted in Microsoft’s public cloud in the first iteration of the methodology,
as a way to experiment and define the right technologies as the architecture continues to evolve.
The connection between the local infrastructure of ABVB and Azure must be delivered by using
Expressroute as a mechanism to guarantee both reliable and stable connections between the
platform deployed on-premises and the ones deployed as cloud services. The selection of Azure
as the initial cloud service provider was greatly influenced by senior management and their
interests of leveraging their existing investment with the company for other technology projects.

Confidential Confidential AVBV

AVBV technology elements
technology
elements

Figure 39. Technology components configuration view for D&A

84
 Artifact Implementation and Validation | CHAPTER 5

5.2.8 Architecture Governance

As part of the EA4DT development cycle, the architecture governance phase compiles identified
changes from the conceptual, logical, and physical architecture to be propagated across to the
architecture vision documentation. For the Provision Data and Analytics Services project,
alterations or modifications to the envisioned target architecture are justified, documented, and
propagated.

5.2.8.1 Modifications at the Enterprise-level

After having analyzed the proposed conceptual, logical and physical architectures and review the
requirements defined for the Provision Data and Analytics Services project in the architecture
outline phase, there is only one identified fundamental change from the technology perspective
to be propagated into the target architecture. The nature of the change does not require an entire
redefinition of business and application services across the entire architecture. Therefore, only
the physical architecture introduced a modification and the target architecture model is updated.

Figure 40 depicts the new target architecture at the Enterprise-level that portrays the introduced
technical alteration. At the technical level, the current implementation of the ETL component
deployed on a legacy technology within AVBV local infrastructure is highly customized and not
capable to be reused and connected to the MDM project. Therefore, the decision led to the entire
replacement of such a component into a cloud service that enables compatibility with the Master
Data Governance and ensures portability with technology independence in line with the
architecture principles earlier defined for the D&A initiative. As a result, the integration
component between both transactional and master data to be transformed and delivered into a
data warehouse will be undertaken by a cloud service platform. Ultimately, by experimenting
with these technologies additional changes may arise for the entire architecture model, however,
as the scope of this validation does not include the actual implementation of these cloud
platforms services, these alterations are not yet identified and reported for the Provision Data and
Analytics Services project part of the Data and Analytics program.

5.2.8.2 Modifications at the Project-level

The conceived architecture models for the conceptual, logical, and physical phases portray a
granular view of the envisioned target architecture with their respective definitions and
relationships to other architectural components. However, part of accelerating the learning cycles
in EA4DT means testing and experimenting with the defined set of technologies to effectively
assess the business value. Therefore post-designing architectural activities include the
implementation, through small experiments, of the selected technology components followed by
feedback sessions for architecture redesign based on the experiment results. Aligned to the scope
of this thesis project, no experimentation was performed and therefore no modifications at the
project level were defined. If any, changes at the project-level do not pose any amendments to
the architecture vision in EA4DT.
85
 Artifact Implementation and Validation | CHAPTER 5

Confidential AVBV Confidential

technology elements AVBV
technology
elements

Figure 40. Modified Target Architecture design for D&A initiative

86
 Artifact Implementation and Validation | CHAPTER 5

5.3 Artifact evaluation

In the second stage of the validation, results from applying the EA4DT into the Data and
Analytics project were evaluated by two business architects part of the IT European division and
one IT architect from the corporate division of AVBV. A round of expert opinion semi-
structured interviews was performed preceded by the presentation of the methodology and the
results obtained throughout the entire architecture development cycle. This subsection of the
validation phase addresses the research objective 5.b.

Expert opinion evaluation model

The approach carried out for the evaluation of the EA4DT consists of three interviews with
employees of AVBV that aim to validate if the designed artifact satisfies and addresses the main
research question considering the results provided by the Technical Action Research case. This
research method for validation is known as expert opinion for design science research (Wieringa,
2014). Based on their experience in the field of Enterprise Architecture, a solid comprehension
of the presented artifact, and the results provided by implementing the methodology to the Data
and Analytics initiative, positive and negative opinions are documented.

The validation method serves as a vehicle to filter out poor design choices made by the main
researcher of this thesis and suggests the incorporation of potential new elements into the
artifact. Interviews were conducted in 20 to 30 minutes one to one sessions, where multiple open
questions were posed regarding two major areas, the problem relevance, and the practical and
implementation relevance. In line with Hevner et al. (2004), the proposed areas take into
consideration the utility, quality, and efficacy of the artifact in relation to the main objective of
this research. Once again, before performing the interviews, participants were already
familiarized with the artifact and the results from the first validation phase, i.e. implementing the
artifact into the D&A initiative.

5.3.1 Problem relevance

The problem relevance questions aim at evaluating with experts three major objectives around
the principal research question introduced by this thesis in the context of a Digital
Transformation project. These objectives include stimulating business agility, simplifying the
architecture development process, and promoting collaboration across business and IT social
structures. Furthermore, these main objectives are linked with their associated artifact objective,
presented in section 3: Design Analysis, with the sole purpose of tracing back artifact objectives
to the main research objective. Table 28 classifies the problem each of the problem relevance
questions according to their research concept and artifact objective.

87
 Artifact Implementation and Validation | CHAPTER 5

Table 28. Problem relevance questions for expert evaluation interviews

Objective: Stimulation of business agility

Artifact objectives Question

1. Design Do you consider that designing a cross-functional organization

interdisciplinary (architecture vision) portrayed how agility can be transferred to the
organization business? Why?

2. Convey business agility Do you consider that designing two-speed and bimodal IT
through architecture architecture patterns (logical architecture) portrayed how agility can
design be transferred to the business? Why?

Do you consider the artifact embraces faster learning cycles through

3. Simplify the
the delivery of simple enough architecture models in contrast to
architecture development
other big designs upfront EA approaches? Why?
cycle

Objective: Promote collaboration across business and IT social structures

Artifact objectives Question

1. Design Do you consider that the alignment of social structures employed

interdisciplinary within EA4DT (architecture vision) enables greater collaboration
organization between business and IT for the D&A initiative? Why?

Objective: Simplification of the architecture development process

Artifact objectives Question

1. Promote Does the EA4DT incorporates the essential set of deliverables to

modularization and simplify the architecture development process for a Digital
decoupled building blocks Transformation initiative? If not, which do you consider are
missing?
2. Simplify the
architecture development Do you consider the simplified version of the ArchiMate metamodel
cycle for EA4DT serves the purpose of keeping architecture products
simple throughout the entire architecture development cycle? If not,
what concepts should be included?

Does the utilization of services as decoupled building blocks

promote modularization within EA4DT, therefore simplifying the
architecture development process? Why?

88
 Artifact Implementation and Validation | CHAPTER 5

5.3.2 Practical and Implementation relevance

The practical and implementation relevance questions aim at registering the expert’s predictions
for the implementation and adoption of the framework among the IT division of AVBV. The
proposed relevance questions include:

a) Do you consider that the method can be applied to other Digital Transformation
initiatives inside and outside of AVBV (e.g. smart manufacturing)?

b) How do you classify the complexity of using and applying the EA4DT to any other
Digital Transformation endeavour (very simple, simple, intermediate, complex, or very
complex)? Why?

c) Do you consider the designed artifact only to be applicable to a specific set of emerging
digital technologies (e.g. Big data analytics and IoT)?

5.3.3 Interviews with practitioners

The following subsections compile the most relevant pieces of information extracted through the
individual sessions performed with three interviewees from AVBV. The results are included for
both the problem and the practical and implementation relevance areas of concern.

5.3.3.1 Interviewee 1

Date July 2nd, 2020

Role IT supervisor with more than 10 years of experience in the area of Business and IT
architecture. Works alongside a team of specialists in AVBV in Europe including
application development, architecture, end-user devices, and infrastructure management
and security. Focused on transforming the business with new emerging digital
technologies and help AVBV embark on a successful journey towards Digital
Transformation.

Problem relevance
The inclusion and design of cross-functional teams are essential for providing faster and highly
cohesive delivery environments in response to the challenges brought by highly dynamic
business requirements. Although cross-functional teams were evaluated sometime in the past at
AVBV, they were not defined based on particular business purposes in contrast to what has been
shown in the D&A initiative project. Moreover, the two-speed architecture models from the
Logical architecture phase in EA4DT are considered pertinent for portraying business agility
through architectural design in contrast to traditional approaches used within AVBV that
represented entire IT architectures models as a “single package”. These experiences resulted in
many delays for any particular project, and the way the EA4DT addresses it may result in

89
 Artifact Implementation and Validation | CHAPTER 5

segmented but faster project fulfilment. In the context of the D&A initiative, this addresses the
concern from senior management to provide different reports across multiple levels of the
organization. Finally, simplification brought by the artifact will allow faster learning cycles with
quicker stakeholder feedback iterations. The segmentation into smaller projects proposed by the
artifact will allow the team to avoid working on big-bang projects and focus more on short-term
tangible results.
In relation to the second research objective, the presented cross-functional organization (part of
the architecture vision in EA4DT) creates a social structure in AVBV that lessens team isolation
and enables closer cooperation between business and IT social structures of the enterprise. The
presented models, however, did not reflect the way in which roles with the same skill sets, e.g.
Information analysts from the Supply Chain and the Sales department cooperated as they may
need to address business requirements that overlap between two internal departments from
AVBV. This calls for additional views or architecture designs to address these particular
concerns.

The validated framework in the context of the Digital Transformation initiative at AVBV, from a
simplification of the architecture development process perspective, includes what needs to be
considered essential for architecture development. The simplified conceptual, logical, and
physical architecture models are crucial when explaining senior management, for instance, what
is the budget is spent on. The suggested deliverables facilitate the understanding of what has to
be implemented by the current IT staff of the organization. Moreover, the use of modular and
decoupled building blocks such as services elements utilized by the framework will allow AVBV
to detect flaws and reduce impacts from modifying architecture structures at later stages of the
cycle. In line with the strategic vision of the D&A initiative for AVBV, the suggested services
would require a more granular definition and segregation considering the short-term
requirements and desired state of the company in the long run (predictive analytics services).

Practical and Implementation relevance

The framework could be employed for other project endeavors, prescribing the essential building
blocks alongside a methodology that provides guidance for other organizations to embark on
successful Digital Transformation journeys. The strength of the framework lies in the concept of
experimentation as a way to deliver incremental business value to the organization, coping with
highly volatile business requirements. In addition, the framework could be embraced as a highly
relevant tool for organizations with a smaller size and budget compared to AVBV, where
simplicity is a must as they continue to move towards larger-scale implementations.

Regarding the utilization of the artifact with other emerging digital technologies, the framework
is rather best practice-based than a technology-bounded approach, which makes it flexible to be
used for any other digital strategies e.g. industry 4.0. Ultimately, the EA4DT level of complexity
is in between simple and complex based on a variety of concerns around implementation,
90
 Artifact Implementation and Validation | CHAPTER 5

usability, and adoption from the IT team. The artifact also needs to include focus areas that
tackle other critical issues from Digital Transformation projects such as risk management and
cost/benefit analysis.

5.3.3.2 Interviewee 2

Date July 3rd, 2020

Role Information Technology professional with more than 15 years of experience in the field
of infrastructure and network engineering. Supports the delivery of IT projects to multiple
service units across the organization. Has a strong orientation for assembling
interdisciplinary teams and bringing IT and business units even closer to deliver
upcoming projects for AVBV.

Problem relevance
In the context of the D&A initiative, the presented structure of a cross-functional organization
alleviates long-standing issues associated with the lack of communication and alignment
between the Reporting Services Team and the dependent business teams i.e. the Sales, Supply
Chain and Finance units. The adoption of both fast and slow cycle IT architectures embodied
through architecture designs will definitely allow the organization to embrace quick wins when
implementing the technology services. In addition, the methodology introduces a promising
approach to simplify architecture deliverables, however, from the perspective of the company,
current staff employees will push back the new methodology as it does not align with the
traditional way of working, ergo complicating the transition towards new ways of working.

On the other hand, promoting collaboration across business and IT social structures can be
perceived as a very loose terminology given the code environment of AVBV. The methodology
only covers a superficial aspect of what building an interdisciplinary organization represents for
the business i.e. collaboration tooling, digital cooperation across multiple projects or initiatives,
enterprise-wide cross-functional teams design, certainly this aspect of the methodology has to be
extended to effectively promote collaboration across business and IT.

Regarding the simplification of the architecture development process, the presented artifact is
fairly complete and can be at the core of a much larger framework to be adopted globally at
AVBV. From an external point of view, there are still some focus areas to be considered
including Governance, Enterprise Portfolio Management, and Service Management on a global
scale if this was not the case of a Digital Transformation for AVBV. The framework strongly
focuses on the delivery of something new into the architecture space that can be applied in the
case of greenfield or startups companies. Moreover, the usage of small containers and services
leveraged by the framework has its merits but it can at to some extent become complex. There
needs to be a governance mechanism to provide effective oversight and up to date status of all

91
 Artifact Implementation and Validation | CHAPTER 5

the proposed services, both conceptually and logically, for the D&A initiative as it continues to
grow and evolve.

Practical and Implementation relevance

The artifact is flexible enough to be implemented in organizations that seek EA capabilities for
the design and development of other digital endeavor footprints such as smart manufacturing by
mapping the needs of the business to the focus areas introduced by the methodology.
Furthermore, EA4DT can be very difficult to implement at an organization such as AVBV due to
its strong traditional mentality of avoiding change at every single level (cultural, social, and
technological), which is completely opposite to what has been introduced by this research
project. Finally, the presented solution can be implemented as part of any other digital endeavor,
where any internal or external offering from the organization has been transformed into a digital
product exposed through the consumption of services.

5.3.3.3 Interviewee 3

Date July 9th, 2020

Role Technology architect with over 20 years of experience in the areas of business analytics
and enterprise applications in the manufacturing, media analytics, consumer goods, and
IT industries. In charge of guiding the organization to successful Digital Transformation
implementations for Industrial Internet of Things (IIoT) by leveraging digital emerging
technologies such as Machine Learning, and Artificial Intelligence.

Problem relevance
In the context of the D&A initiative as presented by the EA4DT, the cross-functional
organization creates synergies between Technology and Business. It also creates strong
integration for the flow of information between various business units. In the absence of a cross-
functional organization, technology may implement what might seem unnecessary for business,
thereby discarding the project implemented or delaying the use of technology due to changes
demanded later on by the organization. Designing a cross-functional organization ensures that
everyone is in agreement with what is being done while implementing company-wide
architectures (EA) or Digital Transformation, thus conveying agility to the business.
Furthermore, timely communication is the key to any successful project. The alignment of social
structures as portrayed by the artifact enable stakeholders to stay updated on the project progress.
In relation to simplicity, the project-level phases in EA4DT ease the development of EA for the
D&A program, however, the enterprise-level phases can become complex for EAM when
managing multiple projects for large-scale DT initiatives. The Architecture Action Plan and
Architecture outline phases must further be complemented with methods and practices from
Portfolio and Project Management disciplines.

92
 Artifact Implementation and Validation | CHAPTER 5

On the other hand, the two-speed and bimodal architecture patterns influence business agility
depending on the maturity level of the transactional and stable slower-cycle speed systems of the
organization. Regardless of the IT logical structure, there will always be dependencies between
the two segments of the architecture, thus delaying the implementation of customer-facing
applications and systems of innovation for the Digital Transformation project. For instance, data
creation, modification, and usage is an essential part of the overall architecture that breaks the
barriers of the bimodal pattern. Therefore a clearer strategy to decommission legacy systems of
record to introduce MDM for data governance is an important concept to be considered as part of
the logical architecture phase. Lastly, faster learning cycles to be attained by the EA4DT will
depend on the scope of the Digital Transformation initiative and the size of the organization that
is going after it. For example, banking systems focus on big designs as reliability and security of
data are important while many startups, including high growth companies like Netflix and Uber,
experiment a lot with technology and stay agile with architecture. In the case of a Digital
Transformation for a company, it is always good to look at the complete design of EA, to ensure
all parts are well integrated.

Practical and Implementation relevance

The proposed artifact is generic and flexible for its utilization for other Digital Transformation
endeavors according to the expert judgment. In addition, the EA4DT is definitely a cleaner and
simpler way of delivering Digital Transformation compared to other traditional approaches based
on the experience in the field and undergoing initiatives being developed at AVBV. As a final
remark, the highlight of the EA4DT according to the interviewee was the incorporation of
decoupled services as building blocks for architecture development as they portray the strongest
components of any modern and scalable architecture. From a technical perspective, they enable
controlled upgrades, patch management, testing, and integration. The new norm of decoupled
blocks is absolutely service-oriented, where each decoupled block may have further decoupled
services running as microservices, thereby making management of software components
extremely easy for a large enterprise.

93
 Conclusions | CHAPTER 6

6. Conclusions
This research introduces the Enterprise Architecture Framework defined by fundamental
building blocks of architecture agility, modularity, and evolvability with a core methodology that
guides organizations embark on Digital Transformation endeavors. After validating and
implementing the proposed framework in the context of the Data and Analytics initiative at
Apollo Vredestein B.V., the usefulness of the artifact was evaluated and demonstrated. This
section presents the limitations of this research, as well as its contribution and future work to be
undertaken.

6.1 Research objectives revisited

As stated in section 1.3: Research Objectives, the main research question for this thesis is:

How to lead organizations towards successful Digital Transformations by means of an

Enterprise Architecture framework that stimulates business agility, simplifies architecture
development, and promotes collaboration across business and IT units?

Based on the main research question multiple research objectives were established. The
following subsections revisit and summarize the findings for each research objective in order to
answer the main research question.

6.1.1 Research Objective 1 (RO1): Contrast the structure of the Enterprise Architecture
practice with the anatomy of Digital Transformations.

This research has studied the nature of the Enterprise Architecture practice in relation to the
phenomenon of Digital Transformation. Based on the definition of Gartner, Inc. (2020c) and
Reis et al. (2018) a Digital Transformation is an exercise of digital optimization and IT
modernization to leverage new emerging digital technologies to enable major business
improvements and influence all aspects of customers’ life. On the other hand, Enterprise
Architecture refers to the organizing logic of internal and external social and technical elements
in order to maintain and review the whole operation of an enterprise. The relationship between
Enterprise Architecture and Digital Transformation lies in the integration of digitalization
projects through the design, exploration, and implementation of emerging technologies such as
IoT, Big Data Analytics, Cloud Computing that materialize valuable digital capabilities for an
organization.

After examining extensively the body of knowledge compiled in section 2.2: Systematic
Literature Review, elements were found to be inherent in Digital Transformations in contrast to
the Enterprise Architecture discipline. These elements include agile architecture delivery, highly
dynamic customer-oriented service alignment, value streams design, and ultimately, complete
94
 Conclusions | CHAPTER 6

business instead of IT focus. The categorization and analysis of these elements resulted in the
definition of five essential core components to be contemplated by current EA practice in
relation to Digital Transformation endeavors. The core components include the social alignment
of the enterprise, customer experience, and value creation streams, architecture agility,
architecture evolution, and architecture modularity. As a result, these components represent the
building blocks of the designed artifact introduced in this thesis.

6.1.2 Research Objective 2 (RO2): Identify the state-of-the-art regarding Enterprise

Architecture practice to support the realization of Digital Transformation initiatives.

The state-of-the-art with regard to Enterprise Architecture approaches that best provide a basis
for Digital Transformations compiled a set of frameworks, tools, methodologies, and techniques
explored in section 2.2.2: Enterprise Architecture practices for Digital Transformation. Among
the most important approaches; The Open Group Agile Architecture Framework™ (OAAF), the
Adaptive Integrated Digital Architecture Framework (AIDAF), and the Lightweight Enterprise
Architecture Framework (LEAF) integrate key concepts aligned to the identified core
components of RO1 including architecture agility, modularity, and evolution. This research
highlights the contribution of the TOGAF framework and its core methodology (ADM) as the
foundations for undertaking Enterprise Architecture for Digital Transformations in two of the
three examined approaches, those being AIDAF and LEAF.

In addition to the frameworks mentioned above, the research examined various methodologies,
techniques, reference architectures, and tools that contributed to a specific set of concerns for
organizations embarking on Digital Transformation projects. These approaches range from the
definition of bimodal architectures, such as two-speed IT in which IT components are divided in
predictable and explorative elements to respond effectively to agile transformations, to the use of
hypergraphs to use formal mathematical analytical methods for discovering misalignments
among IT strategies, information systems, and information architectures. As a result, multiple
instruments were explored as part of this thesis, hence stressing the importance of improving the
current state of the Enterprise Architecture practice in relation to Digital Transformations.

6.1.3 Research Objective 3 (RO3): Elaborate on how the Enterprise Architecture practice is
delivered in organizations that have embarked on Digital Transformation initiatives.

This study also analyzed in section 2.2.2.3: EA and industries undergoing Digital
Transformations how a variety of industries are relying on Enterprise Architecture to deliver
Digital Transformations into the organizations. Among the industries analyzed for this study, the
banking, manufacturing, logistics, and healthcare sectors are employing different mechanisms to
support enterprise transformation as part of their digital strategy. The studied methods for
developing EA for DT involve mapping digital capabilities across socio-technical structures of
the enterprise including processes, technology, and people, the utilization of industry specialized
95
 Conclusions | CHAPTER 6

IT reference architectures (e.g. SITAM), and the extension of EA meta-models for smart
manufacturing implementations.

The case study reviewed in section 2.3: Case Study EA for Digital Transformation at Intel
provided an overview of the Enterprise Architecture approach taken by Intel on their journey
towards successful Digital Transformation. In the first place, the company reformulated the EA
approach by taking advantage of the ADM cycle from TOGAF focusing on the virtues of
capability-based planning followed by Enterprise Portfolio Management, CI/CD, Service
Management, and ultimately Governance and Risk Management. Moreover, Intel introduced a
new EA operating model as part of the solution in order to obtain C-staff level buy-in and
support for the transformation program. The interdisciplinary structure of the operating model
involved multiple solution groups across the value streams or business and operation teams
across the organization. The implementation of the new EA approach at Intel for the Digital
Transformation strategy permitted the company to reduce the technical debt, improve the overall
enterprise data quality, and boost the company’s productivity.

6.1.4 Research Objective 4 (RO4): Design an Enterprise Architecture framework for Digital
Transformation.

Results extracted from both the Systematic Literature Review and the analysis of the case study,
with respect to the Enterprise Architecture approach for Digital Transformation embraced by
Intel, facilitated the definition of core objectives, described in section 3: Design Analysis, to be
attained by the designed artifact introduced in this thesis. Consequently, the identified artifact
objectives were associated with the main research objectives which involve the stimulation of
business agility, the simplification of architecture development and the collaboration across
business and IT units, so that validation results were able to trace back the contribution from the
proposed artifact to the main research objectives. The artifact objectives comprise the design of
an interdisciplinary organization, the utilization of modular and decoupled building blocks, the
simplification of the architecture development cycle, and the employment of architecture models
and designs to convey business agility.

The Enterprise Architecture Framework for Digital Transformation (EA4DT) described in

section 4: Artifact Desing introduces the essential building blocks and architecture catalysts,
based on the results from RO1, RO2, and RO3, for stimulating the development of modular,
agile and evolutionary architectures considered as fundamental in the context of Digital
Transformation initiatives. The artifact also includes a cycle-based architecture development
process following the principles of breaking the DT vision into manageable parts, utilizing
services as foundational architecture design building blocks, embracing a minimalistic maxim for
delivering architecture products, and ultimately design with clear business orientation. Moreover,
the 8 stages cycle of the EA4DT is greatly influenced by the TOGAF content metamodel, the
structured methodology of Lightweight Enterprise Architecture Framework (Nandico, 2016), the
96
 Conclusions | CHAPTER 6

two-speed, and bimodal architecture approaches from Bossert (2016) and Horlach, Drews &
Schirmer (2016), and the digital and agile transformation architecture concepts of The Open
Group Agile Architecture Framework (The Open Group, 2019). Ultimately, The EA4DT
addresses the main research question by enclosing the methodology around the architecture
catalyst previously mentioned so that all activities, deliverables, and guidelines are aligned to the
constituents for EA development in order to deliver a successful Digital Transformation into the
organization. Moreover, the cycle-based approach absorbs the virtues of all the examined body
of knowledge grouped into the following areas of concern:

Stimulation of business agility

The EA4DT conveys business agility to the organization in multiple ways. First, through
architecture designs by leveraging methods such as two-speed and bimodal IT in the Logical
Architecture phase to differentiate faster release cycles from slower stable transactional
architectures that coexist in an organization for a given Digital Transformation. Furthermore, the
artifact brings closer together social elements of the enterprise by designing a cross-functional
organization in the Architecture Vision phase. Due to the proximity of these interdisciplinary
teams, business requirements are meant to be delivered faster and efficiently. Lastly, the
enforcement of essential deliverables across the entire methodology in EA4DT contributes to the
acceleration of the architecture learning cycles.

Simplification of architecture development

To simplify the delivery of architecture work, the EA4DT defines phases to be undertaken at the
enterprise-level and at the project-level perspective. Thus, enabling the definition and execution
of smaller work packages and avoiding complexities brought by committing to big designs
upfront across all stages of the architecture development cycle. Moreover, the framework follows
at each stage of the cycle a minimalistic view for delivering architecture products while keeping
solutions simple according to the established business and architecture principles.

The EA4DT relies on the ArchiMate modeling language and uses a simplified version of its
metamodel as described in section 2.1.4: EA modelling support tools and notation, following the
recommendations from BizzDesign (2018), for portraying all the architecture models suggested
throughout the entire development cycle. Ultimately, the adoption of services as decoupled
building blocks for designing architectures promotes modularization within EA4DT, thus
simplifying the process for developing architecture products in the context of Digital
Transformations projects.

97
 Conclusions | CHAPTER 6

Promote collaboration across business and IT units

As part of the Architecture Vision phase, the EA4DT introduces cross-functional teams that are
in charge of maintaining and supporting the envisioned Digital Transformation program. The
framework presents a social structure that moves away from traditional organizational models
and aligns business and IT into highly cohesive delivery units aiming at reducing inter-team
dependencies. The foundations of designing a cross-functional organization in EA4DT belong to
the concept of architecting the agile transformation in OAAF described in section 2.2.2.1:
Architecture frameworks.

6.1.5 Research Objective 5 (RO5): Demonstrate and evaluate the Enterprise Architecture
framework for Digital Transformation in an organizational context.

The Technical action research study employed in this research served as a mechanism to validate
the artifact in the field. As described in section 5.2: Implementation of the Artifact, the Data and
Analytics (D&A) initiative at Apollo Vredestein B.V. acted as the problem context in which the
EA4DT was validated. The implementation of the EA4DT produced the required set of
architecture deliverables aligned to the business goals, objectives, and requirements of the D&A
program stated in the Architecture Vision phase of the methodology. Similarly, the executed and
documented activities through the entire cycle produced key architecture products in line with
the main objectives of this research which included the enterprise capabilities value stream cross-
mapping and the cross-functional organization design at the Architecture Vision phase, the
flexible high-level project composition plan of the Architecture Action Plan phase, the service-
oriented architecture models depicted in the Conceptual Architecture phase, the two-speed
application and technology design at the Logical Architecture stage, the hybrid cloud IT
configuration from the Physical Architecture phase, and ultimately, the management of change at
the Architecture Governance stage.

The results from applying the artifact to the real-world project were presented to three experts in
the areas of business and IT architecture in section 5.3: Artifact evaluation. The evaluation
process registered the designed artifact contribution to the research problem and to the practical
and implementation relevance according to the interviewees. As foreseen by the experts during
the interview sessions, the artifact contributes to the stimulation of business agility mainly
through the adoption of concepts such as two-speed and bimodal architectures as well as the
formation of cross-functional teams that will allow the organization to embrace quick wins when
implementing the proposed digital services. Furthermore, the EA4DT simplifies the architecture
development process mostly by following a service design pattern and committing to a reduced
version of the ArchiMate standard. However, there is a tradeoff, the notion of simplicity in
EA4DT is only recognized in the project-level phases of the methodology and it is perceived as a
complex practice at the enterprise level stages for large-scale Digital Transformation architecture
endeavors. Lastly, the promotion of collaborative business and IT units through the alignment of
98
 Conclusions | CHAPTER 6

social structures as part of the Architecture Vision phase in the D&A is considered among the
experts as a differentiator element in EA4DT from other EA approaches. Nevertheless, for this
element to be successfully implemented in AVBV, the enterprise culture transformation must be
addressed first.

6.2 Contribution

Considering the overall impact of this research delineated in section 1.6: Practical and Scientific
relevance, and the obtained evaluation results presented in section 5.3: Artifact evaluation, three
main contributions are identified. First, from a theoretical standpoint, this thesis contributes to
scholars of the Business and Information Technology discipline by introducing a novel approach
to develop Enterprise Architecture for Digital Transformation. The artifact assembles the
fundamental building blocks to embrace modular, agile, and evolutionary architectures based on
the results of a systematic literature review and the examination of a case study of a well-
recognized organization. Additionally, this study has conducted a Technical Action Research to
provide significant insights into how the proposed artifact contributes to Digital Transformation
initiatives by leveraging new techniques incorporated into a new Enterprise Architecture
methodology.

Secondly, academics could employ the proposed artifact for analyzing the business impact of
aligning social, cultural, and technological elements critical for delivering Digital
Transformations into organizations. Disciplines such as DevOps exemplify the importance
behind embracing new ways to arrange social elements to leverage strong collaboration and
agility in organizations. This framework has integrated the virtues of designing a cross-
functional and interdisciplinary organization as part of the architecture development
methodology in contrast to traditional EA approaches.

Ultimately, from a practical perspective, this study has validated the suggested framework and its
core methodologies in a real-world Digital Transformation project. The D&A initiative for
AVBV provided the appropriate environment to assess the usefulness of absorbed concepts from
other architecture frameworks or methods that were either presented only at a theoretical level or
were recently published where no real-world implementation cases existed. Therefore, this study
has served as a point of reference for the validation of such approaches with their particular
benefits and drawbacks in relation to practice. In general, experts interviewed at the evaluation
stage of this research have appraised the framework with a positive tone, especially with respect
to providing a well-founded Enterprise Architecture approach to address the particularities of
Digital Transformation efforts in practice.

99
 Conclusions | CHAPTER 6

6.3 Limitations

Despite the fact that the study has addressed the main research question and associated research
objectives as well as contributing to both scientific and practitioner communities, it is still
subject to limitations. The EA4DT focuses on the development of Enterprise Architecture for
Digital Transformation at a very high level, excluding key best practices for successful digital
initiative implementations such as leadership and communication as indicated by McKinsey &
Company (2018). Though the designed artifact contributes to the success of Digital
Transformations it is still bound to the organizing logic of business, information systems, and
technology in the context of Digital Transformations.

On the other hand, this research has undertaken an Enterprise Architecture approach for Digital
Transformation focused entirely on design and planning maneuvers, cutting out implementation
activities. As a consequence, the research is limited to derived predictions from executing the
validated framework in the problem context, leaving potential new challenges uncovered.
Moreover, while the designed framework introduces core building blocks and principles, as well
as the methodology for developing EA for DT according to the literature analysis, it overlooks
other relevant practice aspects e.g. capability maturity assessments, portfolio, service, and risk
management. This limitation was corroborated by the interview evaluation sessions detailed in
section 5.3: Artifact evaluation.

Finally, this research has adopted a simplified version of the ArchiMate metamodel aligned with
the recommendations from Singh (2019) and BizzDesign. (2018). As a result, the considered
elements and relationships were found sufficient for designing and modeling architecture
viewpoints across the entire development method. However, the latter observation cannot be
generalized to all the Digital Transformation initiatives. This simplification becomes a limitation
when portraying future viewpoints of the D&A initiative at AVBV that could potentially require
other passive, active, or behavioral elements from the ArchiMate metamodel which are not
included in this research.

6.4 Future research

As mentioned in the limitations section, further research is required to improve the proposed
Enterprise Architecture Framework for Digital Transformation and thus, provide a more
comprehensive approach to support new digital initiatives. Future research efforts must strive
towards:

 The integration of microservices and domain-driven design into Enterprise Architecture

development. This research has relied on the virtues of the service-oriented design for
architecting Digital Transformations, however, new emerging technologies such as cloud

100
 Conclusions | CHAPTER 6

computing-native architectures implement countless pieces of business logic embedded

into services that reflect business behavior to internal and external customers of the
organization. Therefore, the framework should incorporate a mechanism for modeling
new required business services into large-scale loosely coupled microservices, hence
stimulating the development of modular architectures.

 The inclusion of a maturity model for Digital Transformation that provides a complete
EA capability assessment. This includes areas of examination such as the architecture
development process, documentation of artifacts and standards and their connection to
business strategies and drivers, the involvement of senior management, availability of EA
content, governance processes, increased business agility, and reduced complexity. A
potential approach to be further studied and attached to the artifact is the OAAF maturity
model introduced by The Open Group (2019).

 Analyzing the adoption of risk, service, and portfolio management practices as part of the
architecture development process for Digital Transformations. Despite the fact that
Digital Transformation encourages risk-taking according to literature, practitioners have
indicated that the framework still needs to address risk control for regulatory proposes
across all the domains of the Enterprise Architecture approach. Furthermore, project and
portfolio management practices should be further studied to provide an exhaustive
approach on how to pivot between strategy and realization of a Digital Transformation
project. These concepts were encapsulated in the Architecture Action Plan and
Architecture outline phases in EA4DT, however, their level of involvement is rather
simplistic.

101
 References
Allen, M., & Cervo, D. (2015). Multi-domain master data management: advanced MDM and
data governance in practice. Morgan Kaufmann.

Babar, Z., & Yu, E. (2019, October). Digital Transformation–Implications for Enterprise
Modeling and Analysis. In 2019 IEEE 23rd International Enterprise Distributed Object
Computing Workshop (EDOCW) (pp. 1-8). IEEE.

Babar, Z., & Yu, E. (2015, June). Enterprise architecture in the age of digital transformation. In
International Conference on Advanced Information Systems Engineering (pp. 438-443).
Springer, Cham.

BizzDesign. (2018, July 1). Enterprise Architecture at Intel [Video file]. Retrieved from
https://www.youtube.com/watch?time_continue=3131&v=fJexihP9CQ8&feature=emb_logo.

Bondar, S., Hsu, J. C., Pfouga, A., & Stjepandić, J. (2017). Agile digital transformation of
System-of-Systems architecture models using Zachman framework. Journal of Industrial
Information Integration, 7, 33-43.

Bossert, O. (2016). A two-speed architecture for the digital enterprise. In Emerging Trends in the
Evolution of Service-Oriented and Enterprise Architectures (pp. 139-150). Springer, Cham.

Dremel, C., Wulf, J., Herterich, M. M., Waizmann, J. C., & Brenner, W. (2017). How AUDI AG
Established Big Data Analytics in Its Digital Transformation. MIS Quarterly Executive, 16(2).

European Comission (2015). Decision (EU) 2015/2240 of the European Parliament and of the
Council: establishing a programme on interoperability solutions and common frameworks for
European public administrations, businesses and citizens (ISA programme) as a means for
modernising the public sector. Official Journal of the European Union, 318, 1-16.

Evans, E. (2004). Domain-driven design: tackling complexity in the heart of software. Addison-
Wesley Professional.

Ford, N., Parsons, R., & Kua, P. (2017). Building evolutionary architectures: support constant
change. " O'Reilly Media, Inc.".

Fowler, M. (2014). Sacrificial Architecture. Retrieved from

https://martinfowler.com/bliki/SacrificialArchitecture.html

Fowler, M., & Highsmith, J. (2001). The agile manifesto. Software Development, 9(8), 28-35.

Franke, U., Hook, D., Konig, J., Lagerstrom, R., Narman, P., Ullberg, J., ... & Ekstedt, M. (2009,
May). EAF2-A framework for categorizing enterprise architecture frameworks. In 2009 10th
ACIS International Conference on Software Engineering, Artificial Intelligences, Networking
and Parallel/Distributed Computing (pp. 327-332). IEEE.
102
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1993, July). Design patterns: Abstraction and
reuse of object-oriented design. In European Conference on Object-Oriented Programming (pp.
406-431). Springer, Berlin, Heidelberg.

Gartner Glossary: Information Technology. (2020). Retrieved June 6, 2020, from

https://www.gartner.com/en/information-technology/glossary/descriptive-analytics

Gartner Glossary: Information Technology. (2020b). Retrieved June 6, 2020, from

https://www.gartner.com/en/information-technology/glossary/data-visualization

Gartner Glossary: Information Technology. (2020c). Retrieved January 15, 2020, from
https://www.gartner.com/en/information-technology/glossary/digital-transformation

Gartner Glossary: Information Technology. (2020d). Retrieved January 15, 2020, from
https://www.gartner.com/en/information-technology/glossary/digital-business-transformation

Gartner Glossary: Information Technology. (2020e). Retrieved January 15, 2020, from
https://www.gartner.com/en/information-technology/glossary/digitalization

Gartner Glossary: Information Technology. (2020f). Retrieved January 15, 2020, from
https://www.gartner.com/en/information-technology/glossary/bimodal

Gartner, Inc. (2019). Hype Cycle for Emerging Technologies, 2019. Retrieved February 11,
2020, from https://www.gartner.com/en/documents/3956015/hype-cycle-for-emerging-
technologies -2019

Gartner, Inc. (2017). No Data and Analytics Vision? No Business Impact!. Retrieved December
5, 2019, from https://www.gartner.com/en/doc/3748997-no-data-and-analytics-vision-no-
business-impact

Gartner, Inc. (2017b). 2017 Planning Guide for Data and Analytics. Retrieved December 10,
2019, from https://www.gartner.com/en/documents/3471553/2017-planning-guide-for-data-and-
analytics

Gaß, O., Ortbach, K., Kretzer, M., Maedche, A., & Niehaves, B. (2015). Conceptualizing
Individualization in Information Systems-A Literature Review. CAIS, 37, 3.

Gill, A. Q. (2014). Applying agility and living service systems thinking to enterprise
architecture. International Journal of Intelligent information technologies (IJIIT), 10(1), 1-15.

Goerzig, D., & Bauernhansl, T. (2018). Enterprise architectures for the digital transformation in
small and medium-sized enterprises. Procedia CIRP, 67, 540-545.

Hafsi, M., & Assar, S. (2016, August). What enterprise architecture can bring for digital
transformation: an exploratory study. In 2016 IEEE 18th Conference on Business Informatics
(CBI) (Vol. 2, pp. 83-89). IEEE.

Harrison, R. (2018). Togaf (r) 9 Foundation Study Guide. Van Haren.

103
Helfert, M., Melo, V. A. B., & Pourzolfaghar, Z. (2018, May). Digital and Smart Services-The
Application of Enterprise Architecture. In International Conference on Digital Transformation
and Global Society (pp. 277-288). Springer, Cham.

Hess, T., Matt, C., Benlian, A., & Wiesböck, F. (2016). Options for formulating a digital
transformation strategy. MIS Quarterly Executive, 15(2).

Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in information systems
research. MIS quarterly, 75-105.

Horlach, B., Drews, P., & Schirmer, I. (2016). Bimodal IT: Business-IT alignment in the age of
digital transformation. Multikonferenz Wirtschaftsinformatik (MKWI), 1417-1428.

Hsu, J. C., Clymer, J. R., Garcia Jr, J., & Gonzalez, E. (2009, July). Agent‐Based Modeling the
Emergent Behavior of A System‐of‐Systems. In INCOSE International Symposium (Vol. 19, No.
1, pp. 1581-1590).

IBM (2019). Data Migration. Retrieved June 2, 2020, from https://www.ibm.com

/cloud/learn/data-migration

ISO, I. (2011). IEC/IEEE Systems and Software Engineering: Architecture description.

ISO/IEC/IEEE 42010: 2011 (E)(Revision of ISO/IEC 42010: 2007 and IEEE Std 1471-2000).

Kane, G. C., Palmer, D., Phillips, A. N., Kiron, D., & Buckley, N. (2015). Strategy, not
technology, drives digital transformation. MIT Sloan Management Review and Deloitte
University Press, 14(1-25).

Kassner, L., Gröger, C., Königsberger, J., Hoos, E., Kiefer, C., Weber, C. & Mitschang, B.
(2016, April). The Stuttgart IT architecture for manufacturing. In International Conference on
Enterprise Information Systems (pp. 53-80). Springer, Cham.

Kitchenham, B., Brereton, O. P., Budgen, D., Turner, M., Bailey, J., & Linkman, S. (2009).
Systematic literature reviews in software engineering–a systematic literature review. Information
and software technology, 51(1), 7-15.

Lankhorst, M. (2009). Enterprise architecture at work (Vol. 352). Berlin: Springer.

Legner, C., Eymann, T., Hess, T., Matt, C., Böhmann, T., Drews, P., ... & Ahlemann, F. (2017).
Digitalization: opportunity and challenge for the business and information systems engineering
community. Business & information systems engineering, 59(4), 301-308.

Masuda, Y., & Viswanathan, M. (2019). Enterprise Architecture for Global Companies in a
Digital IT Era: Adaptive Integrated Digital Architecture Framework (AIDAF). Springer.

Masuda, Y., Shirasaka, S., Yamamoto, S., & Hardjono, T. (2017, July). Risk management for
digital transformation in architecture board: a case study on global enterprise. In 2017 6th IIAI
International Congress on Advanced Applied Informatics (IIAI-AAI) (pp. 255-262). IEEE.

104
Matt, C., Hess, T., & Benlian, A. (2015). Digital transformation strategies. Business &
Information Systems Engineering, 57(5), 339-343.

McKinsey & Company. (2018). Unlocking success in Digital Transformations. Retrieved from
https://www.mckinsey.com/business-functions/organization/our-insights/unlocking-success-in-
digital-transformations.

Molnár, B., & Őri, D. (2018, September). Towards a hypergraph-based formalism for enterprise
architecture representation to lead digital transformation. In European Conference on Advances
in Databases and Information Systems (pp. 364-376). Springer, Cham.

Mosley, M., Brackett, M. H., Earley, S., & Henderson, D. (2010). DAMA guide to the data
management body of knowledge. Technics Publications.

Nandico, O. F. (2016). A Framework to Support Digital Transformation. In Emerging Trends in

the Evolution of Service-Oriented and Enterprise Architectures (pp. 113-138). Springer, Cham.

Őri, D., & Szabó, Z. (2018, September). EAM Based Approach to Support IT Planning for
Digital Transformation in Public Organizations. In European Conference on Advances in
Databases and Information Systems (pp. 377-387). Springer, Cham.

Osterwalder, A., Pigneur, Y., Bernarda, G., & Smith, A. (2014). Value proposition design: How
to create products and services customers want. John Wiley & Sons.

Osterwalder, A., & Pigneur, Y. (2010). Business model generation: a handbook for visionaries,
game-changers, and challengers. John Wiley & Sons.

Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design science
research methodology for information systems research. Journal of management information
systems, 24(3), 45-77.

Reis, J., Amorim, M., Melão, N., & Matos, P. (2018, March). Digital transformation: a literature
review and guidelines for future research. In World conference on information systems and
technologies (pp. 411-421). Springer, Cham.

Ries, E. (2011). The lean startup: How today's entrepreneurs use continuous innovation to
create radically successful businesses. Currency.

Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise architecture as strategy: Creating a
foundation for business execution. Harvard business press.

Sebastian, I., Ross, J., Beath, C., Mocker, M., Moloney, K., & Fonstad, N. (2017). How big old
companies navigate digital transformation.

Schirmer, I., Drews, P., Saxe, S., Baldauf, U., & Tesse, J. (2016, July). Extending enterprise
architectures for adopting the internet of things–Lessons learned from the smartPORT projects in

105
Hamburg. In International Conference on Business Information Systems (pp. 169-180). Springer,
Cham.

Sia, S. K., Soh, C., & Weill, P. (2016). How DBS Bank Pursued a Digital Business Strategy. MIS
Quarterly Executive, 15(2).

Singh, P. (2019). Enterprise Architecture: Enabling Digital Transformation at Intel [White

paper]. Retrieved March 31, 2020 from https://www.intel.com/content/dam/www/public/us/en
/documents/white-papers/enterprise-architecture-enabling-digital-transformation.pdf

Temel, A., & Ayaz, M. (2019, September). Digital Transformation Design of Banbury Mixing
Unit in Tire Manufacturing. In 2019 International Conference on Applied Automation and
Industrial Diagnostics (ICAAID) (Vol. 1, pp. 1-6). IEEE.

The Open Group. (2020). Architecture Forum Members. Retrieved April 2, 2020 from
https://reports.opengroup.org/architecture_forum.shtml?_ga=2.253905422.762154421.15857298
64-1291766132.1576586669

The Open Group. (2019). The Open Group Agile Architecture Framework™ Draft Standard:
The Open Group Snapshot. Retrieved January 15, 2020, from
https://publications.opengroup.org/s192

The Open Group. (2019b). ArchiMate® 3.1 Specification. Retrieved February 10, 2020, from
https://pubs.opengroup.org/architecture/archimate3-doc/

The Open Group. (2018). The TOGAF® Standard, Version 9.2, a standard of The Open Group.
Retrieved March 21, 2020, https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Van't Wout, J., Waage, M., Hartman, H., Stahlecker, M., & Hofman, A. (2010). The integrated
architecture framework explained: why, what, how. Springer Science & Business Media.

Ward, A. C., & Sobek II, D. K. (2014). Lean product and process development. Lean Enterprise
Institute.

Wieringa, R. J. (2014). Design science methodology for information systems and software
engineering. Springer.

Wißotzki, M., & Sandkuhl, K. (2017, November). The digital business architect–towards method
support for digital innovation and transformation. In IFIP Working Conference on The Practice
of Enterprise Modeling (pp. 352-362). Springer, Cham.

Zachman, J. A. (1987). A framework for information systems architecture. IBM systems journal,
26(3), 276-292.

Zimmermann, A., Schmidt, R., Sandkuhl, K., Jugel, D., Bogner, J., & Möhring, M. (2018,
October). Evolution of enterprise architecture for digital transformation. In 2018 IEEE 22nd
International Enterprise Distributed Object Computing Workshop (EDOCW) (pp. 87-96). IEEE.

106
Zimmermann, A., Schmidt, R., Sandkuhl, K., Wißotzki, M., Jugel, D., & Möhring, M. (2015,
September). Digital enterprise architecture-transformation for the internet of things. In 2015
IEEE 19th International Enterprise Distributed Object Computing Workshop (pp. 130-138).
IEEE.

107