re-conceptualizing the practice of enterprise architecture implementation · 2017-11-14 ·...
TRANSCRIPT
RE-CONCEPTUALIZING THE PRACTICE OF ENTERPRISE ARCHITECTURE
IMPLEMENTATION
A Dissertation Submitted In Fulfillment of the
Requirements for the Degree of
Doctor of Philosophy
Mark Dale
Faculty of Business and Law
Swinburne University of Technology
2015
Abstract
This research into the implementation practices of enterprise architects (architects) is
motivated by the concern that organizations have difficulty in transitioning from the
development of their enterprise architecture (EA) plans to the implementation of those plans.
Enterprise architecture implementation (EAI) failure is potentially related to the challenges
that architects face in aligning their interpretations of what is important in an EAI with the
interpretations of business and technology stakeholders (reality-design gap). There are also
challenges arising from the perspectives and approaches of existing EAI methods and tools
and there is a need for improving our understanding of the EAI practices of architects. The
aim of this research is to address these concerns by undertaking practitioner-grounded
research into the implementation roles and practices of architects. My intention is to
understand the perspectives of architects, business and technology stakeholders and also
understand the skills, methods, and tools that architects may require when working with both
business and technology stakeholders. An interpretive research paradigm informed the
research design and an interpretivist multiple case study was conducted in two organizations.
Since my interest is to see an EAI as those involved see it and not be constrained by a priori
assumptions, I adopted a grounded theory data analysis method.
The research findings suggest the following implications for EAI. Though architects need to
maintain on-going relationships with business and technology stakeholders, they have direct
engagement with them on an as-needs basis for short-term task specific activities. EAI is an
ambiguous phenomenon and boundaries between architects and their stakeholders arise in
multiple ways including through different perceptions and expectations about the EAI roles of
architects, the priorities of the EAI, and the outcomes expected of the EAI initiative. Whilst
architects are required to liaise with business and technology stakeholders, the practices of
architects may not allow them to build effective connections with others. Boundaries around
the communities of architects exist in different states of permeability: thick and thin. If
architects prioritize what they think is important over the views and concerns of business and
technology stakeholders, this can create a ‘thick’ boundary which in turn can prevent
connections with others who have a legitimate interest in the EAI.
ii
ACKNOWLEDGMENTS
I wish to acknowledge the contribution of my supervisors, in particular Professor Judy
McKay. I am grateful for the time and effort that she has invested in this research.
I would also like to thank my Head of Department, Associate Professor Rosemary Stockdale
and Deputy, Paul Kindler. They generously provided me a reduced workload, which gave me
time to complete this work. Colleagues including Associate Professor Helana Scheepers and
Peter Sala graciously took on additional work in the final months of this research, which also
helped significantly. I would also like to acknowledge the support and guidance of Mr. Chris
Felstead. His interest in my work over the course of this research has been a great
encouragement.
Most of all, I wish to acknowledge in the most sincere way possible, the patience,
understanding and support of my wife, Jane Nash and daughter, Jordan Dale. A PhD is a
demanding and solitary activity and they have always been encouraging. I cannot thank them
enough.
To J
iii
DECLARATION
This dissertation contains no material, which has been accepted for the award to the candidate
of any other degree or diploma. To the best of my knowledge, the dissertation contains no
material previously published or written by another person except where due reference is
made in the text of the examinable outcome. The appendix provides a list of peer-reviewed
publications that resulted from this research. This dissertation contains material that has been
used in these publications.
Signed _____________________________________
Date _____________________________________
iv
TABLE OF CONTENTS
1 INTRODUCTION ...................................................................................................................... 1 1.1 Introduction to the Research ...................................................................... 1
1.2 Motivation for this Research ...................................................................... 3
1.2.1 EAI Failure: Challenges in Reconciling the Concerns and Perspectives of
Architects and Stakeholders ........................................................................................... 3 1.2.2 Challenges Associated with Perspectives and Approach to EAI ....................... 5 1.2.3 Improving Our Understanding of EAI Practice ....................................................... 6
1.3 Problem Statement and Research Aim ....................................................... 7
1.4 Structure of the Dissertation....................................................................... 8
2 LITERATURE REVIEW PART A – ENTERPRISE ARCHITECTURE AND ITS
IMPLEMENTATION ..............................................................................................................11 2.1 Introduction .............................................................................................. 11
2.2 Background .............................................................................................. 12
2.2.1 What is Enterprise Architecture? .............................................................................. 12 2.2.2 The Evolution of Enterprise Architecture and its Implementation .............. 13 2.2.3 Challenges for Defining EAI Arising from the Literature ................................. 24 2.2.4 Challenges for Defining EAI Arising from EA Practice ...................................... 27
2.3 Motivations for EAI ................................................................................. 28
2.4 Challenges of Successfully Implementing EA ......................................... 33
2.4.1 Approaches to the Problems of EAI .......................................................................... 35 2.4.2 Why Does it Matter to Address EAI Failure? ......................................................... 37
2.5 The Importance of Understanding the Relational Aspects of EAI ........... 39
2.6 Summary .................................................................................................. 40
3 LITERATURE REVIEW PART B – THEORETICAL PERSPECTIVES ........................42 3.1 Introduction .............................................................................................. 42
3.2 Adopting a Practice Perspective ............................................................... 42
3.3 A Communities-of-Practice (CoP) Perspective ........................................ 47
ix
3.3.1 Evolution and Conceptual Dimensions of CoP ...................................................... 48 3.3.2 Wenger’s (1998) Interpretation of Practice ......................................................... 49 3.3.3 Criticisms of the CoP Concept ...................................................................................... 51
3.4 The Concept of Practice Boundaries ........................................................ 55
3.5 Boundary Spanning and Boundary Objects ............................................. 56
3.5.1 Boundary Spanning and Boundary Object Research ......................................... 57 3.5.2 Implications of Boundary Spanning and Boundary Object Research to This
Research .............................................................................................................................. 67 3.6 The Research Objective and Research Questions .................................... 68
4 RESEARCH METHODOLOGY AND DESIGN ...................................................................70 4.1 Introduction .............................................................................................. 70
4.2 Research Paradigms and Their Philosophical Assumptions – Positivist,
Critical Research and Interpretivist ........................................................ 71
4.3 Selection of the Research Method ............................................................ 76
4.4 Justification for Using the Case Study Methodology............................... 77
4.5 The Case Study Method and Components ............................................... 79
4.5.1 Understanding ‘The Case’ in This Research ........................................................... 79 4.5.2 The Unit of Analysis ........................................................................................................ 80 4.5.3 Multiple Case Study Design .......................................................................................... 81 4.5.4 Case Selection .................................................................................................................... 81
4.6 Data Collection Methods ......................................................................... 82
4.6.1 Semi-Structured Interviews ......................................................................................... 82 4.6.2 Development of the Interview Protocol .................................................................. 83 4.6.3 Direct Observation .......................................................................................................... 84 4.6.4 Document Analysis .......................................................................................................... 84
4.7 Data Analysis Strategy ............................................................................. 85
4.7.1 Data Analysis Strategy .................................................................................................. 85 4.7.2 Data Analysis Approach - Within-Case Analysis .................................................. 89
4.7.2.1 Initial Coding .................................................................................................................................90 4.7.2.2 Focused Coding .............................................................................................................................91 4.7.2.3 Clustering and Memo Writing – Raising Focused Codes to Theoretical
x
Categories .......................................................................................................................................93 4.7.2.4 Developing Theoretical Categories ......................................................................................97 4.7.2.5 Developing Themes .....................................................................................................................99
4.7.1 Data Analysis – Cross-case Analysis ...................................................................... 105 4.8 Strategy for Writing the Results ............................................................. 105
4.8.1 Writing up the Cases .................................................................................................... 105 4.8.2 Writing up the Cross-Case Analysis ....................................................................... 108
4.9 Quality of Interpretive Research ............................................................ 108
4.9.1 Credibility......................................................................................................................... 112 4.9.2 Transferability ............................................................................................................... 112 4.9.3 Dependability ................................................................................................................. 113 4.9.4 Confirmability ................................................................................................................ 114
5 ANALYSIS OF CASE 1 ........................................................................................................ 115 5.1 Introduction ............................................................................................ 115
5.2 Case Study 1: Bank1 .............................................................................. 116
5.2.1 Information About the Research Participants .................................................. 120 5.3 Framing EAI Work – Architect’s Perspective ....................................... 122
5.3.1 Selecting the New Systems and Defining the Implementation Plans ....... 123 5.3.2 Focusing on Architectural Goals ............................................................................. 126 5.3.3 Not Discussing the Execution of the Implementation Plans ........................ 128 5.3.4 Wanting Management Control over the Implementation Plans ................ 129 5.3.5 Stopping Projects .......................................................................................................... 130
5.4 Practice Work in the Architecture Team ................................................ 131
5.4.1 Complying with the Team Charter ......................................................................... 131 5.4.2 Promoting Shared Understanding ......................................................................... 132 5.4.3 Practices that Contribute to Learning .................................................................. 133 5.4.4 Nature of Work – Engaging/ Dis-engaging ....................................................... 134 5.4.5 Perspectives on EAI Methodology and Tools ...................................................... 135
5.5 Framing EAI Work – Business and Technology Staff’s Perspective .... 137
5.5.1 Delivering a Technology Strategy .......................................................................... 137 5.5.2 Considering Outsourcing Arrangements ............................................................. 138
xi
5.5.3 Addressing Problems with the Technology Portfolio ...................................... 138 5.5.4 Engaging on an As-Needs Basis .............................................................................. 140 5.5.5 Building Support for the EAI .................................................................................... 141 5.5.6 Understanding the Impact of the EAI on People .............................................. 143
5.6 Interactions with Business and Technology Staff .................................. 145
5.6.1 Not Engaging .................................................................................................................. 145 5.6.2 Being in an Ivory Tower ............................................................................................. 147 5.6.3 Behaving as an Elite .................................................................................................... 148
5.7 Summary ................................................................................................ 149
5.8 Reflection on Case 1 .............................................................................. 151
6 ANALYSIS OF CASE 2 ........................................................................................................ 153 6.1 Introduction ............................................................................................ 153
6.2 Case Study 2: Bank2 .............................................................................. 153
6.2.1 Information about the Research Participants ................................................... 154 6.3 Framing EAI Work – Architects’ Perspective ....................................... 156
6.3.1 Selecting the New Systems ........................................................................................ 156 6.3.2 Building Relationships ................................................................................................ 158 6.3.3 Communicating ............................................................................................................. 159 6.3.4 Speaking in Two ‘Languages’ ................................................................................... 160 6.3.5 Being Flexible ................................................................................................................. 161 6.3.6 Sharing Tools and Knowledge with Technology Staff .................................... 162
6.4 Practice Work in the Architecture Team ................................................ 163
6.4.1 Complying with the Team’s Practices ................................................................... 163 6.4.2 Promoting Shared Understanding ......................................................................... 164 6.4.3 Practices that Contribute to Learning .................................................................. 165 6.4.4 Nature of Work – Engage/ Dis-engage ................................................................ 167 6.4.5 Perspectives on EAI Methodology and Tools ...................................................... 167
6.5 Framing EAI Work – Business and Technology Staff’s Perspective .... 169
6.5.1 Defining the Technology Strategy .......................................................................... 169 6.5.2 Promoting Agility.......................................................................................................... 170 6.5.3 Engaging on an As-Needs Basis .............................................................................. 171
xii
6.5.4 Building Support for the EAI .................................................................................... 172 6.6 Interactions with Business and Technology Staff .................................. 174
6.6.1 Dealing Collaboratively with Business and Technology Staff ..................... 174 6.6.2 Liaising and Negotiating ........................................................................................... 175 6.6.3 Communicating ............................................................................................................. 176 6.6.4 Building Common Tools ............................................................................................. 178
6.7 Summary ................................................................................................ 179
6.8 Reflection on Case 2 .............................................................................. 180
7 CROSS-CASE ANALYSIS .................................................................................................... 182 7.1 Introduction ............................................................................................ 182
7.2 Theme 1: Framing EAI Work – Architect’s Perspective ....................... 183
7.3 Theme 2: Practice Work in the Architecture Team................................ 191
7.4 Theme 3: Framing EAI Work – Business and Technology Staff’s
Perspective ............................................................................................ 196
7.5 Theme 4: Interactions with Business and Technology Staff .................. 202
7.6 Concluding remarks on the cross-case analysis ..................................... 208
8 EAI AS PERIPHERY CONNECTION................................................................................ 215 8.1 Introduction ............................................................................................ 215
8.2 Evidencing Boundaries .......................................................................... 216
8.2.1 Differences in perspectives between architects and business stakeholders
218 8.2.2 Differences in perspectives between architects and technology stakeholders
228 8.3 EAI practice as periphery connection .................................................... 238
8.3.1 Architects as periphery connection agents ......................................................... 238 8.3.2 Periphery connection practices of architects .................................................... 244
8.4 Discussing findings in relation to the adopted theoretical perspectives . 248
8.4.1 CoP theory and the findings from the EAI practices of architects ............. 249 8.4.1.1 Mutual engagement in the context of periphery connections ............................... 249 8.4.1.2 Joint enterprise in the context of periphery connections ......................................... 251
xiii
8.4.1.3 Shared repertoire and its efficacy in dealing with boundaries ............................. 252 8.4.2 Theorising the periphery connection concept ................................................... 253
8.5 The efficacy of the periphery connection perspective ........................... 258
9 CONCLUSIONS .................................................................................................................... 260 9.1 Introduction ............................................................................................ 260
9.2 Reflections on the EAI practices of architects ....................................... 262
9.3 Implications for practice ........................................................................ 267
9.4 Suggestions for future research .............................................................. 272
9.5 Reflections on the strengths and limitations of this research ................. 277
9.6 Concluding remarks ............................................................................... 278
10 BIBLIOGRAPHY .................................................................................................................. 279
11 APPENDICES ....................................................................................................................... 307 11.1 Case Study Interview Guide .................................................................. 308
11.2 List of Focused Codes ............................................................................ 311
11.3 Summary Tables for Discussing Themes ............................................... 316
11.3.1 Case 1: Bank1 ................................................................................................................. 316 11.3.2 Case 2: Bank2 ................................................................................................................. 325
11.4 List of Peer Reviewed Papers ................................................................ 338
xiv
LIST OF FIGURES
Figure 1.1 Gap between users’ reality and developer’s design .................................................. 4 Figure 1.2 EAI work in bridging the requirements-design gap between business and
technology ................................................................................................................................. 5 Figure 2.1 Definition of EA including EAI ....................................................................................... 13 Figure 2.2 PRISM framework (Hammer et al., 1986) ................................................................ 15 Figure 2.3 The original Zachman Framework for Information Systems Architecture
(Zachman, 1987) ................................................................................................................. 16 Figure 2.4 The expanded Zachman Framework for Information Systems Architecture
(Sowa and Zachman, 1992) ............................................................................................ 18 Figure 3.1 Three dimensions of practice (Based on Wenger, 1998, p.73) ......................... 51 Figure 3.2 Organizations as constellations of practices ........................................................... 55 Figure 3.3 Research question focus ................................................................................................... 69 Figure 4.1 Research framework adopted for this study ............................................................ 71 Figure 4.2 Identifying the ‘case’ .......................................................................................................... 80 Figure 4.3 Data analysis strategy ...................................................................................................... 86 Figure 4.4 Approach for within-case data analysis (based on Charmaz, 2006) ............. 89 Figure 4.5 Clustering example, ‘Remaking the organization’................................................. 95 Figure 4.6 Organization of theoretical categories for research question 1 ................... 107 Figure 4.7 Organization of theoretical categories for research question 2 ................... 108 Figure 5.1 Timeline for new strategy and EA ............................................................................. 119 Figure 5.2 Situating the architects at Bank1 ............................................................................. 120 Table 5.2 Summarized example of product evaluation model ............................................ 127 Figure 6.1 Situating the architects at Bank2 ............................................................................. 154 Figure 7.1 Relative importance of participants’ concerns .................................................... 210 Figure 7.2 Orientation of architects in two cases ..................................................................... 212 Figure 8.2 Boundaries between architects, business and technology stakeholders ... 217 Figure 8.3 Finer grain boundaries in an EAI context .............................................................. 218 Figure 8.4 Perspectives and assumptions of the architect’s EAI role and practices ... 235
xv
Figure 8.5 Architects as periphery connection agents ........................................................... 238 Figure 8.5 Different orientations in the approaches of architects ..................................... 241 Figure 8.6 Periphery connection practices of architects ....................................................... 245 Figure 8.7 Mutual engagement and meaningful actions in periphery connections ... 250 Figure 8.8 Adopted theoretical perspective: periphery connections ................................ 254 Figure 8.9 New theoretical perspective: periphery connection .......................................... 255
xvi
LIST OF TABLES
Table 1.1 Dissertation structure......................................................................................................... 10 Table 2.1 Descriptions of EAI found in the literature ................................................................ 26 Table 2.2 Purported benefits of EA (Based on Tamm et al., 2011) ....................................... 31 Table 2.3 Concepts of EAI failure ....................................................................................................... 36 Table 3.1 Meanings of practice ........................................................................................................... 45 Table 3.2 Applications of practice theory in IS research .......................................................... 46 Table 3.3 Types of practices (Based on Wenger, 1998, p.47).................................................. 50 Table 3.4 Definitions of boundary spanning.................................................................................. 60 Table 3.5 IS studies directly relevant to the EAI activities of architects ............................ 64 Table 4.1 An example of using initial coding during with-in case data analysis ............ 91 Table 4.2 An example of using focused codes during with-in case data analysis ........... 93 Table 4.3 An example of a memo ....................................................................................................... 97 Table 4.4 List of theoretical categories developed from focused codes .............................. 99 Table 4.5 Mapping the emphasis of theoretical categories in the two cases ................. 104 Table 4.6 Techniques to ensure trustworthiness of qualitative research (Based on
McKay and Marshall, 2000; Shenton, 2004) .......................................................... 111 Table 5.1 Summary of interview participants for Bank1 ...................................................... 122 Table 6.1 Summary of interview participants for Bank2 ...................................................... 155 Table 7.1 A Cross-case comparison on theme 1: framing EAI work – architect’s
perspective .......................................................................................................................... 190 Table 7.2 A Cross-case comparison on theme 2: practice work in the architecture team
................................................................................................................................................. 195 Table 7.3 A Cross-case comparison on theme 3: framing EAI work – business and
technology staff’s perspective ...................................................................................... 201 Table 7.4 A Cross-case comparison on theme 4: interactions with business and
technology staff ................................................................................................................. 207 Table 7.5 Using the orientation of architects to ‘make sense’ of differences across the
xvii
two cases .............................................................................................................................. 211 Table 8.1 Differences in perspectives between architects and business stakeholders 225 Table 8.2 Differences in perspectives between architects and technology staff........... 233 Table 8.3 Challenges involved in the spanning boundaries with business stakeholders
and technology stakeholders ....................................................................................... 257 Table 8.1 Research suggestions for developing the periphery connection concept .... 275 Table 11.1 Case study interview questions .................................................................................. 310 Table 11.2 Focused codes for cases: Bank1 and Bank2 ......................................................... 315 Table 11.3 Architect’s understanding of their role - Categories, codes, and summary of
architects’ perspectives (Bank1) ................................................................................ 317 Table 11.4 Practice work within the architecture team - Categories, codes, and
summary of architects’ perspectives (Bank1) ....................................................... 319 Table 11.5 Business and technology staffs’ perspective - Categories, codes, and
summary of business and technology staffs’ perspectives (Bank1) .............. 322 Table 11.6 Interactions with business and technology staff - Categories, codes, and
summary of business and technology staffs’ perspectives (Bank1) .............. 324 Table 11.7 Architect’s understanding of their role - Categories, codes, and summary of
architects’ perspectives (Bank2) ................................................................................ 327 Table 11.8 Practice work within the architecture team - Categories, codes, and
summary of architects’ perspectives (Bank2) ....................................................... 330 Table 11.9 Business and technology staffs’ perspective - Categories, codes, and
summary of business and technology staffs’ perspectives (Bank2) .............. 334 Table 11.10 Interactions with business and technology staff - Categories, codes, and
summary of business and technology staffs’ perspectives (Bank2) .............. 337
xviii
Chapter 1
1 INTRODUCTION
1.1 Introduction to the Research
This research is concerned with the practices of enterprise architects (hereafter referred to as
architects) as they seek to build support for and commitment to fund the implementation of
their enterprise architecture (EA) plans. The focus is on the practices of architects who are
responsible for selecting the systems that will enable the technology and organizational
capabilities specified in the EA plans and defining the programs of technology projects that
will deliver those systems into operation.
Enterprise architecture implementation (EAI) is critical to the realization of EA goals. EAI
initiatives can accelerate the re-alignment of an organizational technology portfolio with a new
organizational strategy (Ross et al., 2006), improve technology flexibility and efficiency1, and
provide common technology platforms fostering greater re-use and economies of technology
usage (Tamm et al., 2011). It is generally acknowledged that the sustainability and strategic
alignment of organizational technology portfolios can only be achieved through a successfully
implemented EA (e.g. Schulte, 2002; Schmidt and Buxman, 2011). A successful EAI can
1 The term ‘efficiency’ is borrowed from Schmidt and Buxman (2011). Technology efficiency is defined as the relation between the output of the technology functions that manage the technology portfolio and their total efforts. In this context, the output is given by the extent and quality of business process support (or automation) through the provision, maintenance and operation of technology components for the required information processing tasks.
1
improve the return on investment of existing and new applications and speed to market of
products and services (Ross et al., 2006), facilitate the adoption of mobile technologies and
new approaches to application and infrastructure service delivery such as Cloud (Alwadain et
al., 2013; Minoli, 2008) and improve IS/IT alignment (Bradley et al., 2012).
EAI has generated substantial practitioner interest. A recent survey by the Society for
Information Management (Kappelman et al., 2010) indicates that many organizations across a
number of industries including agriculture, banking, chemical, construction, education,
entertainment, tourism, and mining are adopting EA and are undertaking EAI initiatives.
Various professional organizations supporting EA practice including EAI have emerged (for
example, CAEAP, GEAO, IFEAD, The Open Group, ZIFA), and government EA initiatives
(e.g. FEAF, DoDAF, GEA, MoDAF) have been established in at least 40 different countries
across North and South America, Europe, Scandinavia, and Asia Pacific. Globally
organizations and governments are committing a significant amount of money, time and effort
developing their own EA and are looking to execute these.
Industry research indicates that there is an increasing demand for EAI skills (Enterprise
Architects, 2013; Leganza et al., 2014; Gartner, 2013) and architects continue to be well
remunerated (Payscale, 2015)2 and progress to executive management roles including CTO
and CIO (Levinson, 2011). Job search websites reflect the nature of this demand. For
example, a search on SEEK, a prominent Australian job search website, shows that amongst
the various IT positions, there is a very strong demand for architects with implementation
experience.
While the demand for EAI initiatives and practitioners is increasing, many EAI initiatives
continue to fail (Roeleven, 2008) and more are likely to fail than succeed (Kabai, 2013).
Despite the active interest of organizations and governments in EA, academic interest in this
area remains comparatively modest (Tamm et al., 2011; Schekkerman, 2004b). Most of the
research and the highest-cited works in the field are from the practitioner community, not
2 Payscale, an employment search and job salary aggregating web site calculates the median salary for architects at $150,000 per annum rising to 212,000 per annum.
2
academia. In fact, only four articles on EA have been published in the AIS Senior Scholars
‘six top IS journals’ since 1990: Richardson et al., 1990; Peristeras and Tarabanis, 2000; Boh
and Yellin, 2006; and Bradley et al., 2012. Additionally, none of the top ten highest-cited
works on EA3 have been published in journals or conferences listed in the ERA index of
research excellence4. Existing research and practitioner literature tends to focus on EA
frameworks, EA conceptualization, modeling approaches and methods, and the management
of the EA function (Simon et al., 2013).
1.2 Motivation for this Research
The problems associated with EAI motivated this research and can be grouped into the
following categories.
• EAI failure is related to the difficulties in bridging the different perspectives and
concerns of architects and stakeholders. I call this the reality-design gap.
• There are challenges associated with existing perspectives and approaches to
EAI.
• There is a need for improving our understanding of EAI practice.
These concerns are discussed in detail in the following sections.
1.2.1 EAI Failure: Challenges in Reconciling the Concerns and Perspectives of
Architects and Stakeholders
Whilst researchers have not previously developed theories or examined ways to bridge the gap
between what is important to architects and what is important to stakeholders, there are IS
3 Based on Google Scholar analysis 8th August, 2014.
4 Excellence in Research in Australia, published by the Australian Research Council is a benchmarking framework for the classification of research conducted in Australian Universities and is used for academic promotions and awards. It is based on a journal ranking hierarchy.
3
studies that are relevant. Heeks (2002) working in the field of information systems
development (ISD) in developing countries, suggests that ISD failure can be viewed as a
‘reality-design gap’ between the ‘current realities’ of the users and the ‘design conceptions’ of
the systems developers. Heeks argues that in relation to ISD projects, users’ perceptions of
reality and their expectations of the future are subjective and that users will have their own
version of reality. However, he only considers a two dimensional relationship, one between
users and system designers. The reality design-gap is presented as a gap between the reality of
the users and the design created by system developers (see Figure 1.1).
Figure 1.1 Gap between users’ reality and developer’s design
Heek’s model offers a way in which to conceptualize the challenges in successfully undertaking
an EAI. We need to consider the reality-design gap between architects, business and
technology stakeholders (see Figure 1.2). The challenge of understanding what is important to
business and technology stakeholders involved in an EAI requires that we understand the
current realities of their professional ‘lifeworlds’ and their expectations, at the same time, not
ignoring that architects also have their own ‘lifeworlds’ and expectations. In analyzing the
reality-design gaps that are relevant to ISD, Heeks mentions that such gaps could be
associated with many stakeholders, but fails to mention an important reality-design gap – the
practices of the people involved in the design of the system and the perceptions and
expectations of stakeholders (including users). A way forward would be to investigate the
4
practices of architects who are expected to understand the requirements (i.e. what is
important) of business and technology stakeholders and bridge the reality-design gap through
their interactions with those stakeholders. The differences in perceptions of architects,
business and technology stakeholders, may provide us insights into the challenges of EAI.
Figure 1.2 EAI work in bridging the requirements-design gap between business and technology
1.2.2 Challenges Associated with Perspectives and Approach to EAI
While there is an expectation that architects overcome a requirements-design gap between
themselves, business and technology stakeholders (Simon et al., 2013), the failure of architects
5
to identify and assimilate into their interpretation of an architectural problem or task what is
important to business and technology stakeholders is still viewed as a major factor leading to
EAI failure (Roeleven, 2008). This raises the question as to whether there are limitations in
the perspectives that underlie the EAI work of architects.
Existing EA methods and tools apply a rationalist worldview to the problems associated with
EAI. This worldview is implicit in the technical and one-best-way approaches to EAI
management (Weill and Ross, 2004), architectural design (Tiwana and Konsynski, 2010), EAI
frameworks (Op’t Land et al., 2009), modeling methods and tools (Harmon, 2005), and
implementation approaches (Venkatesh et al., 2007). These approaches are inevitably imposed
on stakeholders and result in an arguably ‘limited’ analysis of the architectural problem. Such a
view tries to categorize all EAI problems as objective, independent of the organizational
problem context and the interactions between architects, business and technology
stakeholders.
For several decades, researchers have argued that neglecting the context of an IS problem
situation leads to a poor understanding of the problem (Brown and Duguid 2000). Context
influences how the meaning associated with phenomena may be interpreted (Boland 1979) and
context-sensitivity is considered important for system developers, to enable them to better
understand and adapt to their work environment (Mathiassen, 1998). Oats and Fitzgerald
(2007) advocate that researchers should adopt a contextual approach to the problems
associated with IS so as to better understand the relationship between the IS problem and the
organizational environment. This research likewise adopts a contextual approach to the
problems of EAI and seeks to improve our understanding of the relationship between EAI
failure and the organizational context.
1.2.3 Improving Our Understanding of EAI Practice
As an EA scholar and practitioner, I am sensitive to the relevance of EAI research to the EA
practitioner community. In relation to EA research, researchers have argued for more
practically oriented EA planning methods and frameworks (Simon et al., 2013). In relation to
IS research, the relevance of IS research to IS practice has been questioned by scholars
6
(Benbasat and Zmud, 1999; Davenport and Markus, 1999; Klein and Rowe, 2008; Klein and
Hirschheim, 2008). Several authors have noted that knowledge created by the IS academic
community rarely translates into usable tools and practices for the practitioner community
(Frisk et al., 2014; Van De Ven, 2007; Benbasat and Zmud, 1999; Hirschheim and Klein, 2003;
Klein and Hirschheim, 2008). Lippert and Anandrajan (2004) argue that the published research
of IS academics and the published writing and research of IS practitioners focus on quite
different areas and Lyytinen (1999) suggests that IS academics are not researching topics of
interest and concern to practitioners. The concerns of IS scholars about the relevance of
research outcomes to practitioners has informed the approach taken in this research. The
research undertaken here seeks to promote a greater understanding of the challenges
associated with EAI and the role of organizational context in EAI failure. These are concerns
that are immediately relevant to EAI practitioners.
1.3 Problem Statement and Research Aim
This research focuses on the concern that EAI failure relates to the challenges that architects
face in aligning their interpretations of what is important in an EAI with the interpretations of
business and technology stakeholders (reality-design gap). There are also challenges arising
from the perspectives and approach of existing EAI methods and tools and there is a need for
improving our understanding of the EAI practices of architects. In the context of this
research, EAI failure is viewed to result from architects’ inability to understand the ‘lifeworld’
of stakeholders and inability to bridge the reality-design gap. These two drivers of EAI failure
are themselves considered related to factors such as the limitations in perspectives used in
EAI, inadequate EAI tools and methods and a limited understanding of EAI practice.
Previous research on the EAI practices of architects focuses on the integration of EAI
methods and process management (Esswein and Weiler, 2008), the improvement of EA
methodologies (Leist and Zellner, 2006) and the relationship between EAI literature and
practice (Schekkerman, 2004a). However, very little research has examined the roles and
practices of architects as they interact with both business and technology stakeholders to select
7
the new systems and plan the implementation of those systems and how differences in
perspectives and concerns between architects and their stakeholders are negotiated. Extant
EAI research and literature emphasizes the technical documentation outputs and expected
business benefits of an EAI and largely ignores the architect’s relationship with business and
technology stakeholders.
The aim of this research is to address the problem as outlined above by taking a practice-based
research approach to the EAI roles and practices of architects who are expected to bridge the
gap between their own subjective reality and the subjective reality of business and technology
stakeholders involved in an EAI. My intention is to derive insights into the practices of
architects that promote and hinder the development of effective relationships with their
stakeholders and to understand the nature of the relationships that architects must build with
their stakeholders in order to successfully complete an EAI.
1.4 Structure of the Dissertation
The structure of the dissertation is described in the following table (See Table 1.1).
8
Chapter Contents
Chapter 1
Introduction
• Research motivation
• Problem statement and research aim
• Dissertation structure
Chapter 2
Literature Review – EAI Practices of Architects
• A working definition of EA including EAI
• Evolution of EA and treatment of EAI by early authors
• Challenges for defining the EAI practices of architects arising from EAI literature and practice
• An emergent perspective for investigating the EAI roles and practices of architects
Chapter 3
Literature Review – Theoretical Perspective
• Adopting a practice lens
• A Communities-of-Practice perspective
• The concept of practice boundaries and boundary spanning
• IS studies relevant to the adopted perspectives
• Research objective and research questions
Chapter 4
Research Methodology and Design
• Research paradigms and their philosophical assumptions
• Justification for the interpretive research paradigm
• Selection of research method
• The case study method and its key elements
• Quality in interpretive research
Chapter 5
Analysis of Case 1
• Background to the case
• Information about the research participants
• The architect’s perspectives
• Business and technology staff’s perspectives
9
Chapter 6
Analysis of Case 2
• Background to the case
• Information about the research participants
• The architect’s perspectives
• Business and technology staff’s perspectives
Chapter 7
Cross-case Analysis
• A cross-case comparison • Theme 1: Framing EAI work – architect’s perspective • Theme 2: EAI practice work in the architecture team • Theme 3: Framing EAI work – business and technology
staff’s perspectives • Theme 4: Interactions with business and technology
staff
Chapter 8
EAI as Periphery Connection
• Responding to the research questions
• Understanding differences in EAI perspectives
• EAI as periphery connection and architects as periphery connection agents
• Discussing findings in relation to the adopted theoretical perspectives
Chapter 9
Conclusions
• Reflections on the EAI practices of architects
• Implications for EAI practice
• Suggestions for future EAI research
• Reflections on the strengths and limitations of this research
• Concluding remarks
Table 1.1 Dissertation structure.
10
Chapter 2
2 LITERATURE REVIEW PART A – ENTERPRISE
ARCHITECTURE AND ITS IMPLEMENTATION
2.1 Introduction
The literature review that informs this research is organized in two parts. In this chapter, I
discuss the evolution of enterprise architecture (EA), the literature on enterprise architecture
implementation (EAI) and the problems of EAI as discussed in the literature. The analysis of
this literature informs the research perspective on the EAI practices of architects. In chapter
3, I discuss communities-of-practice (CoP) theory and the boundary spanning concept that
were used to provide theoretical guidance for this research.
This chapter is organized as follows. I first put forward a view adopted in this research of EA
and provide an overview of the origins and evolution of EA. My purpose is to highlight the
motivations for EA, its development in government and industry as they attempted to the deal
with the challenges and opportunities of new technologies and the limited attention that early
EA authors gave to implementation. I then discuss the challenges arising from EA literature
and practice for developing a clear understanding of EAI practice today. I examine the
motivations for adopting EA and the challenges of successfully implementing EA. Finally, I
discuss the importance of understanding the relational aspects of EAI.
11
2.2 Background
2.2.1 What is Enterprise Architecture?
Contemporary organizations need to produce and deliver a complex mix of products and
services and adapt them quickly as market opportunities and regulatory conditions change. In
order to accomplish this efficiently, organizations must be able to reconcile a large number of
business processes and activities within a well-organized business and IT operating
environment (Ross et al., 2006). In today’s organizations, these business processes and
activities are supported by a complex array of business and IT systems and it is the
organization of these systems, which determines the adaptability, and flexibility of the
organization (Ross et al., 2006; Bruls et al., 2010).
EA is the organizing logic of an organization’s business and IT systems (Ross et al., 2006). An
EA conceptually models these systems as a structured collection of parts such as data,
application, infrastructure, integration, storage and security and integrates these in to a
coherent organization-wide ‘blueprint’ of a desired organizational technology portfolio (Ross et
al., 2006). An EA formulates the principles and guidelines for the acquisition of new
technology components and their implementation and is used to plan and govern the more
detailed architecting by project architects (Bruls et al., 2010).
The following diagram describes a process for developing and implementing an EA (see
Figure 2.1) and is informed by this research and my professional experience as an enterprise
architect (architect). As it is applied here, an EA is divided into four discrete phases:
1. Organizational strategy. This involves a change in the strategic direction of an organization,
which drives transformational IT change and the need for a new EA.
2. EA Development. This involves various analysis, planning and modeling activities
associated with defining the required systems and platforms to deliver the new strategy.
Architects model the required system and platform capabilities including processes, infrastructure,
networks, security, data, information and storage in an integrated manner.
3. EA Implementation. Architects identify the specific systems (i.e. products) to deliver the new
12
EA into operation and develop the implementation plans to schedule and coordinate the delivery
of those systems into operation.
4. Program/ Projects. This involves the project management and execution of the specified
technology programs and projects.
Figure 2.1 Definition of EA including EAI
2.2.2 The Evolution of Enterprise Architecture and its Implementation
In discussing the evolution of EA, my intention is to highlight the limited attention that the
early authors of EA frameworks and materials gave to the implementation of an EA. This
13
body of material in general did not mention EAI or assumed that whatever was planned would
be implemented. EAI was not seen as different to EA plan development and the issues of
implementation were seen as the same as the issues of EA plan development. In some of the
very early literature, the problems of implementation are discussed briefly and it seems that the
issues at that time are similar to the problems of implementation today.
The origins of EA date back to the 1960s to IBM’s Business Systems Planning (BSP) methodology
(Kerner, 1979).5 BSP clearly shows that IBM was exploring ways to align the technology
portfolio of an organization with data and business process requirements, though in a
partitioned or stovepiped way (Carlson, 1979; Zachman, 1982). In the 1980s, with the
increasing convergence of information technologies including office automation, word
processing, data processing and data communications technologies, organizations needed to
understand how they could oversee the acquisition and evolution of information technologies.
This need is captured in a series of three contemporaneous articles published in the Harvard
Business Review under the title The Information Archipelago (McKenney and McFarlan, 1982;
McFarlan et al., 1983; McFarlan et al., 1983) (Harrel, 2011). BSP resembled EA as it provided a
method for identifying not only what systems to integrate, but the role these systems should
play and how they should be implemented.
The term ‘architecture’, as it is applied in an IT context, dates back to the 1980s. PRISM6
published Dispersion and Interconnection: Approaches to Distributed Systems Architecture in which they
argued there was a compelling perception in many organizations that there existed “problems
which can only be addressed by the development of an architecture” (Hammer et al., 1986). Interestingly,
the PRISM report revealed that “no two … organizations mean the same thing by architecture when they
5 IBM’s Business Systems Planning (BSP) approach (where John Zachman was employed as regional manager) goes back to the late-1960s and may be considered the beginning of enterprise architecture. IBM used BSP internally at first before offering it as a commercial consulting product in 1981.
6 PRISM (Partnership for Research in Information Systems Management) was a joint venture of the Index Group and Hammer and Company. Index Group was originally Index Systems. Index Group was acquired by Computer Sciences Corporation (CSC) in 1989, was renamed CSC Index, and grew to over 650 employees in fourteen offices before being dissolved in 1999. Hammer and Company continues to operate (Harrel, 2011).
14
express the above belief.” This report also mentions that whilst architecture projects can be
successful, most architecture projects fail because of: 1) the perceived irrelevance of
architecture planning documentation, 2) completed architecture projects failing to address
relevant problems, 3) waning interest in the architecture effort, and 4) architecture projects
taking so long to complete they were obsolete by the time they were delivered (Hammer et al.,
1986, p. 2). The PRISM framework is the first published architecture framework identified by
this research and is represented as a four-by-four matrix as shown in Figure 2.2. It provided a
high level taxonomy based on viewpoints represented by the Inventory (As-is state) Principles,
Models (To-be state) and Standards columns and contexts represented by the Infrastructure, Data,
Application and Organization rows.
Figure 2.2 PRISM framework (Hammer et al., 1986)
In 1987, Zachman introduced his Framework for Information Systems Architecture (Zachman, 1987),
which drew on BSP’s emphasis on the alignment of data, business processes and technology
(See Figure 2.3). Zachman’s original framework is a high level architecture information
taxonomy based on viewpoints represented by the Ballpark View, Owner’s View, Designer’s View,
Builder’s View, Out- of-context View, and Actual System rows of the matrix and the contexts are
represented by the Data Description, Process Description and Network Description columns.
Although the framework provides a structure for EA information management and serves to
15
guide the practitioner on what to consider and how to organize EA information, it does not
address how an information systems architecture is implemented and the reader is left to work
through that problem themselves. Zachman (2008) asserts that his framework is an ontology
and an architecture meta model, but this description is something of an overstatement if the
framework is compared with more advanced and detailed architecture ontologies such as the
IEEE1471 2000 Recommended Practice for Architectural Descriptions of Software Intensive Systems. It
would be another decade before Zachman used the term ‘enterprise architecture’ in relation to
his framework.
Figure 2.3 The original Zachman Framework for Information Systems Architecture (Zachman, 1987)
16
In 1989, software architecture approaches began to emerge. The Object Management Group
was founded and began work specifying the Common Object Request Broker Architecture
(CORBA). That same year, Perry and Wolf published Foundations for the Study of Software
Architecture (Perry and Wolf, 1989). In 1992, Sowa and Zachman extended the original version
of the Zachman Framework for Information Systems Architecture (See Figure 2.4) and the concept of
an ‘enterprise-wide’ focus began to crystallize. While the word ‘enterprise’ only appeared twice
in (Zachman, 1987), it appears more than 40 times in Sowa’s and Zachman’s 1992 paper
(Sowa and Zachman, 1992), although the expression “enterprise architecture,” does not
appear in these papers. Whilst the extended Zachman Framework for Information Systems
Architecture adopted an enterprise focus in its classification of architecture information, the
framework lacks a defined method. Architecture, as the term is used by Sowa and Zachman
(1992), is an unbounded problem space that provides no clues on to where to begin, what is
important and should be performed first and what is not as important and should be deferred
to later or not done at all (Harrel, 2011).
17
Figure 2.4 The expanded Zachman Framework for Information Systems Architecture (Sowa and Zachman, 1992)
18
Sowa and Zachman (1992), treat implementation as part of EA plan development and
‘implementation models’ represent the technically most detailed models of all the artifacts
associated with an EA (See Functioning Systems row). In the context of the expanded Zachman
framework (Sowa and Zachman, 1992), the challenge of implementation is seen to be in
providing an appropriate and actionable level of architectural information, which can be
handed over to a developer to execute. How architects interact with business staff and
developers to produce these models and how they are able to build support for and
commitment to fund the specified systems are seen not to be relevant. The term ‘enterprise
architecture’ first appears in published form in 1992, when Spewak published, Enterprise
Architecture Planning: Developing a Blueprint for Data, Applications, and Technology (Spewak, 1992).
After 1992, interest in EA discipline grew rapidly, with many frameworks, methodologies,
model representations, definition languages, description languages, tools and styles being
produced. This interest in EA is reflective of the proliferation of network technologies, the
opportunities and disruptive change they brought to organizations who sought to adopt them
and the drive toward the inter-connection of business processes and functions. The Internet
was opened to the public in 1989 and the commercial application of the World Wide Web
emerged in 1994. Both developments made it possible for systems to be accessible across
organizations and around the world. It was at this time that governments, in particular the
United States Government, became interested in EA. In 1994, a Defense Science Board
report highlighted the need for EA within the Department of Defense (U.S. DoD) (U.S. DoD,
1994). This report highlighted “the need for a joint enterprise architectures framework” and described
three views of data and information architecture that became the Operational Architecture,
System Architecture and Technical Architecture framework of the U.S. DoD’s C4ISR14
Architecture Framework.7 Whilst many of these frameworks and tools addressed the technical
challenges of developing EA plans such as modeling and visualizing the different data and
systems dimensions of an EA, they did not address the types of implementation problems
7 C4ISR is the acronym for Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance.
19
raised in the PRISM report (Hammer et al., 1986) and authors tended to assume that if
architectural artifacts were technically competent, they would be implemented.
The motivation for EA adoption within the U.S Government intensified in 1996. On 16 July
1996, President Clinton signed Executive Order 13011 titled “Federal Information Technology.”
This executive order required federal agencies to appoint a Chief Information Officer (CIO)
and created the Federal CIO Council. Also in 1996, the Congress, mindful of all the money
spent by the U.S. Government on information technology, passed the Information
Technology Management Reform Act (ITMRA) (ITMRA, 1996) and the Federal Acquisition
Reform Act that together became known as the Clinger-Cohen Act. This legislation became
effective on 8 August 1996 and states in part,
‘Information technology architecture’, … means an integrated framework for evolving or
maintaining existing information technology and acquiring new information technology to
achieve the agency’s strategic goals and information resources management goals
(ITMRA, 1996).
Subsequent reports showed the convergence of information technology architecture and EA.
The concept of information technology architecture still fundamentally reflects the business
process, data and technology alignment emphases of BSP, but now incorporates the notion of
overarching design constraints. These reports are also of interest because of the insights they
offer into government motivations for adopting architecture. On 16 June 1997, the Office of
Management and Budget (OMB) issued a memorandum for the heads of executive
departments and agencies of the U.S. Government with the subject of Information Technology
Architectures (OMB, 1997) that stated,
The Information Technology Architecture (ITA) describes the relationships among the
work the agency does, the information the agency uses, and the information technology
that the agency needs. It includes standards that guide the design of new systems. An
ITA makes it easier to share information internally (e.g. agency-wide e-mail) and to
reduce the number of information systems that perform similar functions. The ITA
provides the technology vision to guide resource decisions that reduce costs and improve
20
mission performance (OMB, 1997).
In this memo (OMB, 1997), the OMB broadened the scope of information technology
architecture stating that it must also include an EA. It goes on to define EA as,
The explicit description of the current and desired relationships among business and
management processes and information technology. It describes the “target” situation,
which the agency wishes to create and maintain by managing its IT portfolio (OMB,
1997).
At this time, within the U.S Government, the meaning of EA is based on a system of
classifying architecture documentation and artifacts and this reflects the influence of
Zachman’s use of the term (OMB, 1997). EA artifacts include business principles and goals,
business process documentation, information flows and relationship models, applications, data
and technology infrastructure descriptions. The implementation of an EA, as it is
characterized in the government architecture documentation at this time, is treated as part of
the modeling activities associated with EA plan development. The transition from the
creation of the EA plans to the implementation of those plans does not attract the attention of
authors, since the underlying assumption is that whatever is planned is done.
The E-Government Act of 2002 (E-GA, 2002) expanded on previous government definitions
of EA, describing EA as a “strategic information asset base”, which
(i) defines the mission, (ii) the information necessary to perform the mission, (iii) the
technologies necessary to perform the mission and (iv) the transitional processes for
implementing new technologies in response to changing mission needs (E-GA, 2002)
Significantly, an EA effort is described as including: a baseline analysis of the existing
technology architecture, a target technology architecture, and a transition plan and this
approach has become standardized in many EA frameworks and methods today.
Outside of government EA efforts, interest in architecture continued in the late 1980s and
1990s and during this time EA methods began to converge with software architecture
21
methods. By the 1980s, the focus of software architecture was on standards and standards-
based technical architectures around the UNIX operating system (Harrel, 2011). The goal was
to standardize the UNIX operating system so that software applications could be written to a
standard specification and then run on any UNIX machine with little or no additional effort.
This work grew to include protocols and standard applications that could plug-and-play in a
UNIX environment and which were incorporated into EA frameworks such as The Open
Group Architecture Framework (TOGAF) (The Open Group, 1995 - 2003). Additional
software architecture methodologies were also developed specifically for software architecture.
These included Rational Unified Process (RUP), Rational 4+1 View Model and the Reference
Model for Open Distributed Processing (RM/ODP), later adopted as ISO/IEC 10746-3:1996
(Kruchten, 1995; Ellis et al.; 1996, ISO/ IEC, 1996).
Systems architecture frameworks began to emerge in the mid-1990s and have continued to
evolve (U.S. DoD, 1997; Sage and Lynch, 1998; U.S. DoD, 2004; Harrel, 2011). Descriptions
of architecture development methodologies were developed to support these frameworks
(Hammer et al., 1986; Bienvenu et al., 2000; Levis, 2009; Harrel, 2011). Of note is that some of
these frameworks have evolved to include EA like features such as an enterprise-wide focus,
consideration of business processes and data requirements (The Open Group, 2009; U.S.
DoD, 2009).
Interest in EA research also resulted in a number of EA frameworks at this time. Prior to the
late 1990s, EA was generally called ‘systems architecture’, ‘information architecture’, or
‘information systems architecture’. The phrase ‘enterprise architecture’ or ‘enterprise IT
architecture’ was applied later. Since PRISM first introduced the concept, there has been a
growing body of published works on EA frameworks. Some EA frameworks and
methodologies clearly evolved from software architecture and systems architecture
frameworks and methods, while others emerged from fresh perspectives (Hammer et al., 1986;
Zachman, 1987; Sowa and Zachman, 1992; Spewak, 1992; Henderson and Venkatraman,
1993; Luftman et al., 1993; Boar, 1998; Armour et al., 1999a; Armour et al., 1999b; TEAF,
2000; Armour and Kaisler, 2001; Carlock and Fenton, 2001; Sage and Cuppan, 2001;
McGovern et al., 2003; Perks and Beveridge, 2003; The Open Group, 2003; Bernard, 2004;
22
Schekkerman, 2004b; Theuerkorn, 2005; Vasconcelos et al., 2004; Whittle and Myrk, 2004;
Rouse, 2005a; Rouse, 2005b; Wagter et al., 2005; Blevins, 2006; Carlock and Lane, 2006; Ross
et al., 2006; Sage and Biemer, 2007; Sessions, 2008, The Open Group, 2009).
Since 2000, professional organizations have also played a role in trying to build a consistent
definition and body of knowledge associated with EA. Organizations such as the Centre for
the Advancement of the Enterprise Architecture Profession (CAEAP) have sought to
promote the EA profession distinguishing it from other professions and seek to promote the
professional development of architects through the certification of EA standards. Other
organizations such as the Institute for Enterprise Architecture Developments (IFEAD) and
the Association of Enterprise Architects (AEA) seek to promote EA research and the
exchange of EA knowledge within the EA community. The Guide to the (Evolving) Enterprise
Architecture Body of Knowledge (EABOK Draft)(Hagan, 2004) provides a competency framework
for the professional development of architects based around key knowledge areas associated
with EA practice. Whilst the EABOK specifically acknowledges EAI as a ‘transitional process
that involves the implementation of new systems’ (Hagan, 2004, p.12), it deliberately avoids
the area of implementation. Though the guide provides important information for
practitioners about the processes for developing EA plans and modeling methods for business
process, data, infrastructure and security, the practitioner is left to work through the challenges
of transitioning from the creation of the EA plans to the implementation of those plans for
themselves. Due to the absence of formal tertiary degree programs in EA, professional
organizations such as CAEAP, IFEAD, and materials such as the EABOK have filled an
important gap in building knowledge about EA. However, a characteristic of these
organizations and materials is that they continue to emphasize tools, methodologies, and
documentation, and offer comparatively little assistance for dealing with the practical realities
and difficulties that architects seem to face when transitioning from the creation of their EA
plans to the implementation of those plans.
In summary, the concept of EA emerged as distributed and internet-based technologies
emerged which made it possible to interconnect the information technologies within an
organization. Before these internet-based technologies emerged, organizational systems were
23
stovepiped and ‘islands’ of information proliferated. However, once internet-based
technologies became widely available and economically feasible, stovepiped environments
were no longer desirable and new inter-connected architectures were possible. Different
forms of architecture methods emerged including systems architecture, software architecture
and EA and these forms of architecture continue to co-exist and co-evolve. Whilst the early
EA literature treated the challenges of EA plan development and implementation differently,
later writing and materials either treated EAI as a part of EA plan development or deliberately
avoided it.
Unfortunately, there is little in the numerous descriptions of EA that helps clarify what
differentiates EA from other types of technology-related architecture. For the purpose of this
research, EA is differentiated from other types of architecture such as software architecture
and systems architecture by its enterprise-wide and mission focus, it includes models of
business processes, data, systems, networks and other technology infrastructure, it considers
the current and target technology portfolio and a transition plan, it is linked to the
organization’s strategic plans and is a basis for major technology acquisition and
implementation decision making.
Nearly three decades after Zachman’s Framework for Information Systems Architecture (Zachman,
1987), EA is well accepted and many organizations have spent significant amounts of money
establishing EA functions and developing EA plans. However, many of these organizations
are unable to realize the benefits they expected from their EA plans because they are unable to
implement them (Roeleven, 2008). The aim of this research is to examine the challenges
organizations have in transitioning from the production of their EA plans to the
implementation of those plans.
2.2.3 Challenges for Defining EAI Arising from the Literature
There is comparatively little consistency in the way EAI is treated in the literature. In doing
the research of this literature review, I examined both academic and practitioner-focused
literature in order to have a balanced perspective of the available body of knowledge
associated with EAI. It was interesting to note how notions of EAI varied across both
24
academic and practitioner literature. Descriptions of EAI focus on the application of EA
frameworks (O’Rourke et al., 2003), project planning activities (Van den Berg and Van
Steenbergen, 2006), architectural modeling work of architects (Rajput, 2000), data and
business process analysis (Lankhorst, 2005), project governance activities (The Open Group,
2009; Perks and Beveridge, 2003; Josey et al., 2009), and strategic planning activities (Ross et al.,
2006). Some authors view EAI as knowledge management involving the cataloguing and
updating of the various architectural artifacts (Institute of Electric and Electronics Engineers
[IEEE], 2000). Zachman (1987) for example, proposed a model for organizing architectural
artifacts in a consistent way. Others attempt to relate EAI with project management
approaches. For example, TOGAF v.8 (The Open Group, 2003) developed a comprehensive
method for EA development and EA implementation, which incorporates project
management related areas such as change management, project governance and
communication management. The different descriptions of the EAI found in the literature are
summarized in Table 2.1.
Descriptions of EAI References
Architects focus on risk mitigation from the perspective of technology suitability and interfaces. Architects evaluate available technology products against prescribed requirements and map interfaces among technology components to understand interdependencies between systems.
Armour and Kaisler, 2001
Architects assess the organization’s readiness to proceed to implementation. Architects work with key business and technology stakeholders to ensure that the implementation is given sufficient time, money and resources.
Van den Berg and van Steenbergen, 2006
Architects in collaboration with business stakeholders undertake strategic planning tasks including industry analysis, enterprise operating model analysis and base their selection of hardware and software components on the outcomes of those activities.
Ross et al., 2006
Architects work with project teams and business stakeholders to ensure expected benefits of the selected hardware and software components are delivered.
Gregor et al., 2007
25
Architects provide contingency planning advice to business stakeholders in case alternative technology projects need to be initiated because of changing business priorities.
Op’t Land et al., 2009
Architects lead technology acquisition and implementation tasks. Architects are responsible for mapping out the processes and methods for selecting and acquiring the appropriate technology components. Architects are also responsible for defining the implementation plans and also communication planning, change management and governance.
The Open Group, 2003; Josey et. al., 2009
Architects liaise with technolgy staff and set the ground rules for implementation projects including terminology, frameworks, methods and architectural models.
Kappelman, 2010
Table 2.1 Descriptions of EAI found in the literature
More recently, EAI has been described as the outcome of specific architectural planning
policies and standards (Schmidt and Buxman, 2011; Namba, 2005). This approach has been
criticized for ignoring the organizational context and social dimensions of an EAI (Ross,
2003), assuming that business requirements are stable and objective (Schmidt and Buxman,
2011) and of oversimplifying the on-going analysis and planning work associated with
selecting and implementing the required technology components (Armour and Kaisler, 2001).
A low level of integration exists between research on the strategic aspects of EAI and the
operational activities of architects and this may jeopardize the success of EAI initiatives (van
der Raadt et al., 2008; van der Raadt et al., 2010). This points to a planning-practice gap
between the development of the EA plans and the implementation practices of architects.
The extent of this gap is perceived to influence the success or failure of EAI initiatives and
suggests that the practices of architects do not encourage effective interaction and
communication with business and technology stakeholders and that this adversely affects the
outcomes of an EAI initiative (van der Raadt et al., 2008; van der Raadt et al., 2010).
Whilst the existing research into EAI has built knowledge concerning approaches to EAI
management, processes, and driven the development of new methods and tools (Lankhorst et
al., 2005), researchers have largely ignored the social relationships between architects, business
26
and technology stakeholders. While offering support for some of the technical challenges
inherent in EAI, they offer few insights into how the attendant social and political dimensions
of an EAI are to be managed, especially those associated with building the necessary
engagement of key stakeholder groups and delivering the changes specified in the EA. In
particular, the roles and practices of architects as they engage their stakeholders in genuine
collaboration so as to understand and satisfy business and technology requirements and also
build commitment for the funding of the technology components and programs specified in
the EA plans has largely been overlooked by researchers. Research has largely ignored the
meanings that architects and their business and technology stakeholders ascribe to EAI, and
how these meanings influence relations between them and the outcomes of EAI initiatives.
Relatively recent research suggests that the outcomes of EAI initiatives may be contingent on
the practices of architects and their ability to build relationships with their stakeholders
(Roeleven, 2008). Research also indicates that architects and stakeholders have difficulty
communicating with each other and in working together (Poutanen, 2012). Therefore, I am
interested in investigating the EAI roles and practices of architects as they interact with
business and technology stakeholders and understanding how these roles and practices may
affect relations between architects and their stakeholders and influence the outcome of EAI
initiatives. Moreover, I am interested in understanding how more effective relationships
between architects, business and technology stakeholders can be built.
2.2.4 Challenges for Defining EAI Arising from EA Practice
The problem in defining what is EAI and the role of architects during an EAI is that in
general descriptions of EA work vary considerably as do attendant job descriptions with EA in
the title. For example, the title of architect is used for someone in a technology strategy-
planning role (Miller, 1997; Moniz, 1999; Rajput, 2000; Kornak and Distefano, 2002). In more
recent literature, the title of architect is associated with someone in a technology and business
strategy role (Ross, 2003; Ross and Beath, 2006; Ross et al., 2006).
In some cases, the activities associated with an EA initiative are not only limited to people
with the title of architect, but are also evident in other job titles. For example, the problem
27
analysis and planning activities of architects involved in EA, for example, may be found in job
descriptions for ‘principal architects’, ‘domain architects’, ‘platform architects’, ‘infrastructure
architect’, ‘application architect’, ‘solution architects’, ‘user experience architect’ and ‘high-end
business analyst’.8 While job descriptions for the different types of architect overlap, they
emphasize different aspects associated with architecture work. Some job descriptions
emphasize a particular domain of architecture knowledge such as data, security, storage,
infrastructure, etc., others focus on the particular group of stakeholders to be engaged (e.g.
technology operations, technology project staff, business staff, a specific business division or
function, etc.), depending on the nature of the project. The view taken in this research is that
organization-wide liaising work (consultation, negotiation, collaboration) is central to the EAI
work of architects.
2.3 Motivations for EAI
As it is characterized in the literature, the motivations for doing EAI are twofold: the first is to
realize a change in an organization’s strategy and the second is a desire to improve the
management of data and technology resources. A change in an organization’s strategy is seen
as a primary motivation for pursuing EA (Ross et al., 2006). New technologies, moving
industry boundaries and an expanding and interconnected global economy are creating new
strategic opportunities. Organizations are forced to continuously update their strategies in
order to maintain a competitive advantage over their rivals (Porter, 1985). According to Ross
et al., (2006) when implementing technology resources to support a new strategy, the rate at
which organizations are able to develop the architectural competencies to implement those
systems evolves more slowly than the technology the organization is attempting to deploy and
manage. They propose that organizations evolve through four architecture maturity levels:
8 Seek.com. Keyword search ‘Enterprise Architect’, 7th May, 2013. Accessed from http://www.seek.com.au/JobSearch?DateRange=31&SearchFrom=quick&Keywords=enterprise+architect&nation=3000
28
Business Silos, Standardized Technology, Optimized Core, and Business Modularity. In their
empirical research, they found: (1) it took an average of five years for an organization to
evolve from one architecture maturity level to the next; (2) organizations could not skip
architecture maturity levels; and (3) transitioning from one architecture maturity level to the
next represented a paradigm shift in IT management and governance (Ross et al., 2006).
Organizations that were able to generate value at a particular maturity level or who were able
to successfully transition from one level were able to do so because they had implemented
their EA and were able to find ways to overcome the impediments that retard the enterprise
learning curve.
The technology and data management benefits ascribed to EA are numerous and well
documented in the academic research and practitioner literature (See Table 2.2). These
benefits generally fall into four broad categories: technology alignment, data access and
availability, portfolio optimization and economies of efficiency (e.g. technology re-use, re-use
of expertise, improved agility). Although the existing descriptions of EA benefits seem logical
and plausible, there is a general lack of empirical evidence and this has implications for our
ability to theorize about them (Tamm et al., 2011). This lack of empirical research into the
benefits of EA highlights an important area of future EA research.
29
IT Management Benefit
Description Reference
Technology Alignment
Integrated view of the enterprise; common understanding; improved communication
Bernard, 2005
Bridge between the business and technical domains; common goals and performance measures
Pereira and Sousa, 2004
Business-IT alignment Ross et al., 2006
The link between organizational and IS strategies is made stronger
Segars and Grover, 1996
Improved support for business operations Ross et al., 2006
Data Access and Availability
Standardized and shared reference information, improved understanding of technology portfolio
Bernard, 2005
Better access to customer data; shared data; more manageable IT environment, improved risk management; higher system reliability
Ross et al., 2006
Common data; more accurate, and timely data Spewak, 1992
Improved decision-making Ross et al., 2006
Single sources of data; improved information quality
Venkatesh et al., 2007
Portfolio Optimization
Discovery and elimination of redundancy Pereira and Sousa, 2004
Reduced duplication of technology resources Lankhorst et al., 2005
Reduced support and maintenance costs Niemann, 2005
Improved agility/ flexibility Kettinger et al., 2010
Resource prioritization leading to more cost effective outsourcing
Ross and Westerman, 2004
30
Homogeneous architecture Richardson et al., 1990
Standardization; reduction of technologies Ross et al., 2006
Fewer costly and complex interfaces Spewak, 1992
Standardizing IT applications and business processes
Venkatesh et al., 2007
Economies of Efficiency
Improved resource integration Bernard, 2005
Componentization; enhanced interoperability Ross et al., 2006
Integrated systems Segars and Grover, 1996
Improved economies of scale Venkatesh et al., 2007
Table 2.2 Purported benefits of EA (Based on Tamm et al., 2011)
Most of the benefits ascribed to EA depend on the implementation of the EA. This is hardly
surprising since a key motivation for EA is to deliver an improved technology and business
platform into operation (Ross et al., 2006). A number of studies discuss benefits from
technology and business platforms that are the result of EA plans that have been successfully
implemented. Two characteristic claims are that an operating platform produced by an
implemented EA is likely to support the business strategy and operating model (Ross et al.,
2006) and have a higher level of process and data standardization and integration (Boh and
Yellin, 2006; Lankhorst, 2005). However, apart from these themes, authors tend to diverge in
the organizational benefits they ascribe to EAI.
Although a significant amount of research attributes improvements in the management of data
and technology resources to an implemented EA, the role that architects play leading to the
delivery of the EA into operation is often not examined. For example, in Ross et al.’s (2006)
discussion of the benefits associated with an EA enabled technology platform, the roles and
practices of the architects in building support for and commitment to fund the technology
31
components and projects to deliver that platform receives only limited attention. Although
the authors state that EA is of key importance “allowing the organization to map out important
processes, data, and technology enabling desired levels of integration and standardization” (Ross et al., 2006,
p. 92), how architects interact with their stakeholders to make this happen is not examined.
There are two key questions that need to be addressed to better understand the benefits
associated with EA enabled technology platforms and the roles that architects play in helping
to deliver those platforms. First: How does EA lead to tangible business benefits and could these benefits
be achieved without the use of EA? Second: If EA does have a unique role in enabling business benefits, are
there any relational factors that affect moving from the EA plans to their implementation? The first
question is beyond the scope of this research, but the second is consistent with the objective
of this research to examine the roles and practices of architects. An EA plan is not a
guarantee of implementation success (Boh and Yellin, 2006) and is dependent on a number of
additional factors including the relationships architects have with their stakeholders and their
ability to form effective relationships with those stakeholders (Roeleven, 2008; Poutanen,
2012). As the systems specified by the architects to deliver the new strategy are implemented
through a series of technology and business improvement projects and programs of work, the
accepted project success factors can be said to apply (Finney and Corbett, 2007; Parr et al.,
1999). These factors include executive management support, transparent and agreed
acquisition process and methods, change management, risk management and project
management, among many others. As well as individual project and program successes,
proper IT project and architecture governance is of central importance to ensure that the
various projects follow the EA plans (Boh and Yellin, 2006; Ross et al., 2006; Weill and Ross,
2004). Also, due to the duration and cost, EA implementations are more likely to be subject
to unexpected shifts in business priorities, emerging financial constraints, or loss of
stakeholder interest (Tamm et al., 2011; Armour et al., 1999b; Richardson et al., 1990; Segars
and Grover, 1996; Spewak, 1992). Finally, due to the possibly enterprise-wide (i.e. global)
aims of an EA effort, there may be trade-offs in local optimization, local data access and
availability, and autonomy. EAI initiatives are also very likely to be impacted by organizational
politics (Janssen and Hjort-Madsen, 2007; Kettinger et al., 2010; Segars and Grover, 1996).
32
2.4 Challenges of Successfully Implementing EA
Though the need for EA appears to be well accepted and many organizations have adopted
EA, many organizations are unable to build and exploit their EA plans (Roeleven, 2008).
Despite the efforts of researchers to address the problem of EAI failure, the EAI failure rate
continues to be high and is a cause of concern. A relatively recent survey of eighty-nine
organizations revealed that sixty-six per cent of EAI efforts fail because of insufficient
awareness about the benefits to be delivered, differences in perspectives and expectations
amongst stakeholders and architects, and organizational politics (Roeleven, 2008). There are
concerns that the failure rate of EA initiatives is higher in comparison to other technology
projects (Sidorova and Kappelman, 2010). Many business and IT practitioners, as reported in
some surveys, have little confidence in EA being successful and anticipate EA projects to fail
(Shaw, 2010). A U.S. Department of Defense briefing (Harrel, 2011) on a relatively recent EA
effort highlights the disappointments and frustrations associated with EAI failure.
We have invested over $400 million developing architecture since 2001. There has been
value created in this effort, but none of that value is recognized due to a lack of tangible
program output. There is a strong opinion among oversight bodies, and within the
business organizations, that the effort has been one of developing architecture in the
absence of any plans for implementation. Architecture development has too many
“constructs”, too many models, too little recognizable links to business processes and
outcomes with business missions (Harrell, 2011, 61).
Cost is also seen as a principal determinant of implementation failure (DeMarco, 1995). The
collective, integrated set of architectures can become unaffordable when applied across the
organization and potentially the architect will not be able to demonstrate any positive return
on investment in the short to medium term. The following comments of an architect
practitioner illustrate how insufficient funding for an EAI effort can affect the realization of
EA goals.
In my consulting practice I see one organization after another engender an architecture
33
group because they realize that architecture is the key to product family reuse, and thus a
desirable goal. But then the architecture group is funded only as a part of the first
implementation project, and that project’s budget is set in the usual fashion for our
industry, i.e., in the mid-range between Impossible and Highly Unlikely. In other words,
the architecture group is a sham. It has a charter, but no funding. After a momentary
digression on reuse, it is treated as an adjunct to the project and driven by the same
dynamic as all the rest of the project, getting the product out the door as quickly and
cheaply as possible. It is no surprise that no useful architecture ever comes out of such a
group. Organizations that pay the cost of architecture get what they pay for and
organizations that don’t get [nothing]. My experience is that the enormous majority of
architectural efforts in our industry are in this latter category (DeMarco, 1995).
The difficulty that organizations have in developing an architecture competence is a possible
factor that causes stakeholders to lose interest in the EA effort. The empirical research of
Ross et al., (2006) indicates that enterprises develop their EA competence very slowly and as a
consequence the success rate for EA efforts is often much lower than expected. Some
enterprises greatly scale back or abandoned their EA efforts while others seek alternative
enterprise architecting strategies because the ones they have employed previously have not
delivered the expected benefits within the expected timeframe (Harrell, 2011).
The difficulty of establishing business requirements and the conflicting and multiple
perspectives of stakeholders are also factors affecting EAI failure. For some time, researchers
have been aware that the failure of EAI initiatives can be rooted in the gap between what is
designed by architects and the requirements of stakeholders (Goodhue et al., 1992). Architects
and their stakeholders have difficulty understanding one another (van der Raadt et al., 2008).
The failure of architects to identify and incorporate into their EA plans critical business
requirements is viewed as a driver of EAI failure (Roeleven, 2008). Part of the issue is that the
objectives of stakeholders may not help to meet organizational objectives (van der Raadt et al.,
2008) and as such have been characterized as ‘wicked’ because they are not amenable to a
single problem formulation or solution, have no well-defined set of potential solutions and can
be considered symptoms of other problems (Harrel, 2011). In spite of the contradictory,
34
competing and ‘wicked’ nature of stakeholder objectives, each stakeholder expects the EA to
meet their needs and the extent to which stakeholders see the EA as meeting their objectives
will determine their level of interest in and support for the implementation of the EA plans
(van der Raadt et al., 2008).
2.4.1 Approaches to the Problems of EAI
Over the last decade, the problems of EAI failure have attracted the attention of researchers
and practitioners. In examining this area, authors have tended to use a positivist paradigm
(Rajput, 2000; Kornak and Distefano, 2002) and focused on the different roles of frameworks,
methodologies and modeling techniques (Jonkers et al., 2003; Lankhorst et al., 2005), the
technical expertise and training of architects (Aier and Schelp, 2009), change management
processes (Josey et al., 2009; Janssen and Klievink, 2010), and governance processes and
structures (Buchanan and Soley, 2002; Ross, 2003). There have been several attempts at
categorizing the reasons why EA initiatives do not deliver their expected benefits (see Table
2.3). Most research has focused on identifying technical factors that cause EAI failure and
consequently reflects a rationalist assumption that if an architect deals with these factors, EAI
failure can be avoided.
Conceptualization of EAI Failure
Reference
Process failure Poutanen, 2012; Richardson et al., 1990; Boster et al., 2000; Van der Raadt et al., 2008, 2010; Hjort-Madsen, 2006; Martin, 2012
Design failure, Alignment failure
Bradley et al., 2012; Bruls et al., 2011; Boh and Yellin, 2006; Roeleven, 2008; Gregor et al., 2007
Framework failure Peristeras and Tarabanis, 2000
Management failure, Benefits failure
Simon et al., 2013; Schmidt and Buxman, 2011; Ross et al., 2006; Ross, 2003; Kettinger et, al., 2010
35
Project failure (time and budget)
Roeleven, 2008; Boster et al., 2000; Armour et al., 1999b
Partner/ Vendor Failure
Ross and Beath, 2006
Organizational learning failure
Poutanen, 2012
Table 2.3 Concepts of EAI failure
More recently, researchers have focused on dedicated EA management functions within
organizations and situate the execution of EAI projects within those functions (Schmidt and
Buxman, 2011). These functions have oversight of the organization’s IT environments and
provide continuous and long-term management of the EA. Whilst EA functions may provide
benefits to organizations in helping them to remain flexible and able to respond to market
opportunities, there is a need for further research exploring links between the implementation
effectiveness of such functions and relations between the architects and their stakeholders.
Although researchers’ focus on EA frameworks, tools and techniques has been questioned
(Ross et al., 2006), this focus is indicative of some of the problems with EA initiatives and has
resulted in significant contributions to knowledge in areas of EA management, planning,
design, and modeling methods (Simon et al., 2013). However, in the socio-technical context of
an EAI, Smolander et al. (2008) proposed there is too much emphasis on the technical aspects
of EAI and not enough on the social aspects. For example, in Zachman’s Framework for
Information Systems Architecture (Zachman, 1987), the emphasis is on the organization of
architectural artifacts and the individual artifacts displayed in each cell of the framework
represent architectural ‘facts’. Whilst the framework adds to our knowledge of how EA
artifacts may be organized, it does not advance our understanding of the social context of an
EAI or how the competing and contradictory objectives of stakeholders may be managed.
The TOGAF (Josey et al., 2009) characterizes the development and implementation of EA
plans as a ready-made and structured process that can be reproduced at will. The
36
development of an EA, in terms of the TOGAF, includes four architectural plans: a data
architecture plan, application architecture plan, technology architecture plan and business
architecture plan. These architectures interlink through predefined inputs and outputs and
architectural modeling activities. The assumption underlying the structured tasks associated
with implementing architectures is that if you get the technical aspects of the architecture
right, the human and relational aspects will fall into place. This view could be said to convey a
somewhat simplified and abstracted perspective that reveals little of what might be required in
actual practice. For example, the selection of technology components is seen as a two-step
sequence 1) defining the application functionality required, and 2) mapping the required
functionality to available commercial-off-the-shelf (COTS) products. The emphasis here is on
describing a decision-making process and such a view fails to highlight the different
perspectives and objectives that stakeholders may have, the trade-offs that architects may be
expected to make and the negotiation that may occur between architects and their
stakeholders.
2.4.2 Why Does it Matter to Address EAI Failure?
As an EA scholar and practitioner, I am sensitive to the relevance of EAI research to the EA
practitioner community. In relation to EAI research, researchers have argued for more
practically oriented EA planning methods and frameworks (Simon et al., 2013) and others have
argued for research that balances the current narrow technical focus of existing research with a
focus on the multiple perspectives on EA (Rozanski & Woods, 2007). Whilst existing
approaches may have served a technically oriented audience well, they have resulted in a lack
of research and skills in the social processes associated with an EAI. Recent research does
indicate that architecture represents design trade-offs among properties such as cost, usability,
maintainability and performance and these represent the explicit commitment of a particular
group toward a particular objective or course of action (Smolander et al., 2008). Architecture
is the product of a process of decision making and negotiation for resources needed for
building the systems, including personnel, expert skills and funding (Bass et al., 2003).
Likewise, a successful EAI can be considered as something that emerges from the cooperation
37
amongst stakeholders whilst taking into consideration situational constraints of monetary
resources, legacy systems, available technology and the skills and experience of staff.
A potential outcome of the limited research into the social processes associated with EAI may
be that EA researchers are in the main not addressing topics of interest and concern to
practitioners. This could be interpreted as indicating that EA researchers fail to appreciate the
sorts of implementation concerns that trouble practitioners and do not fully appreciate or
understand the implementation of an EA or the EAI role that architects are required to fulfill.
Research suggests that published EA research and the published writing and research of EA
practitioners focus on quite different areas and this inhibits the training and education of
architects (Simon et al., 2013). An investigation into how the roles and practices of architects
influence support for and commitment to an EAI would help tertiary institutions to be more
effective in preparing future architecture practitioners (Simon et al., 2013).
Research suggests that the disappointing outcomes associated with EAI are not related to the
development of the EA plans, but are related to the social aspects of EA (Smolander et al.,
2008). For example, there are problems with the working styles of architects, which do not
encourage effective interaction, and communication with stakeholders (Poutanen, 2012).
Authors have pointed out that architects and stakeholders have difficulty communicating with
each other and in working together (Poutanen, 2012), architects do not understand the
different perspectives of stakeholders (Smolander et al., 2008; Smolander and Rossi, 2008) and
the reclusive personalities of some architects causes difficulties in their interaction with
stakeholders (Van der Raadt et al., 2008). EAI failure is seen as the failure of architects to
develop an ‘empathetic’ understanding of their stakeholders, to ‘walk in the shoes’ of their
stakeholders and appreciate the ‘world’ from the perspectives and concerns of those
stakeholders (Seppänen, 2009; Isomäki et al., 2008 in Poutanen, 2012) and to bridge the
intellectual and organizational boundaries between themselves and their stakeholders
(Poutanen, 2012).
The social problems of EAI are not dissimilar to those found in the information systems
literature. For several decades, IS researchers have argued against the neglect of social issues
in understanding IS project requirements for the sake of more technical requirements
38
(Goguen, 1993). User requirements are viewed as coming from the social system of the
workplace rather than from the minds of the users (Goguen, 1993, Cited in Ramos and Berry,
2005) and this explains why some scholars have encouraged the use of anthropological
approaches in understanding IS project requirements (Hughes and Wood-Harper et. al., 1999).
Research highlights that not only are IS project requirements grounded in the social context of
the participants, but the process of requirements analysis is itself social (Goguen, 1993). For
example, it is argued that one needs to be aware of whose world view is being imposed during
requirements analysis when different stakeholders are involved in the same project (Goguen,
1993; Goguen, 1994). This research takes the view that useful insights can be derived into the
problems of EAI by understanding the social context of an EAI.
2.5 The Importance of Understanding the Relational Aspects of EAI
In a large organization, architects will interact with a number of stakeholders in the course of
an EAI (IEEE, 2000). Broadly speaking, the major stakeholder groups involved in an EAI
include: business and technology executives and general management, business and technology
teams, end users of different lines of business, systems development and operations staff,
technology project teams and external partners (e.g. vendors) (Schmidt and Buxman, 2011).
In relation to the literature, two observations can be made: firstly, no studies investigated the
different perspectives and objectives amongst business and technology stakeholders. Whilst
van der Raadt et al., (2008) examine stakeholders’ perceptions of an EA, they focus on
technology stakeholders and do not consider business stakeholders. Secondly, many EA
studies do not consistently adopt the same labels for the stakeholders involved in an EA. For
example, in some EA literature business and technology stakeholders are undifferentiated.
Kettinger et al., (2010) refer to the business and technology stakeholders involved in an EA as
general managers. In Ross and Beath (2006), all people involved in an EA initiative are
managers. In a few studies, researchers refer specifically to individual groups such as senior
management, program and project managers (van der Raadt et al., 2008, Schmidt and Buxman,
2011). In general, however, there is a lack of clarity about the participants referred to in the
studies and this raises questions as to whether the different stakeholders involved in an EAI
39
and their objectives and concerns are appropriately differentiated for understanding the nature
of their involvement and the nature of their interaction with architects.
Based on the gaps in our knowledge of the social aspects of EAI and the emphasis on the
technical aspects of EAI found in existing research, we need to improve our understanding of
the practices of architects, including the relationships they build with their stakeholders and
how this may affect the transition from the development of the EA plans to the
implementation of those plans. In this research, therefore, I adopt a practice perspective for
understanding the roles and ‘practices’ of architects. Adopting a practice perspective
implies an understanding that individuals are enabled and constrained by shared ‘practices’
by which they interpret the world and then behave in accordance with the meaning they
derive from their interpretations (Reckwitz, 2002). With this perspective, I attempt to
understand how architects conceptualize their EAI role and how these conceptualizations are
enacted through their practices and interactions with business and technology stakeholders
(See Figure 2. 1 Definition of EA including EAI ‘EA Implementation phase’).
2.6 Summary
This chapter articulates the concept of EAI and differentiates EAI from EA plan
development. It puts forward a historical analysis of EA to demonstrate that early authors of
EA frameworks, methods and tools did differentiate between EA plan development and EAI.
EAI was seen as a product of EA plan development and was assumed to follow on
immediately from EA plan development. A review of the EAI research indicates that EA plan
development and EAI are distinct phases of work and that many organizations have difficulty
transitioning from the development of their plans to the implementation of those plans.
Whilst there is considerable literature attesting to the benefits of EA, the motivations for EAI
are primarily to support a new organizational strategy and improve operational performance.
However, organizations have little confidence in implementing their EA plans, the costs
associated with EAI are too high and stakeholders lose interest in the EAI due to the
protracted time required to deliver the systems and platforms specified in the technology
40
selection plans. To date, much of the EAI literature has adopted a technical and rationalist
approach to the challenges of EAI and ignored the relational aspects of an EAI. In an EAI,
architects will engage with a number of stakeholders from the business and technology who
have a legitimate interest in the EAI. This research will examine the practices of architects
that promote and inhibit connections with these stakeholders.
41
Chapter 3
3 LITERATURE REVIEW PART B – THEORETICAL
PERSPECTIVES
3.1 Introduction
In chapter 2, I reflected on the challenges for understanding enterprise architecture
implementation (EAI) practice arising from both the literature and practice. I also discussed
the importance of understanding the relational aspects of EAI and the need to adopt a
different theoretical perspective for understanding the problems associated with EAI failure.
In this chapter, I will discuss the theoretical perspectives adopted for this research. In section
3.2, I discuss the practice perspective and in section 3.3, I discuss Communities-of-Practice
(CoP) theory and its relevance to this research. In section 3.4, I discuss the boundary
spanning and boundary object perspective, and consider IS studies that have adopted this
perspective in section 3.5. The chapter concludes with the articulation of my research
questions in section 3.6.
3.2 Adopting a Practice Perspective
There is no universally accepted definition of the term ‘practice’ and multiple meanings are
ascribed to the term (See Table 3.1). In common usage, practice simply refers to what people
do and what they say, however researchers have adopted different perspectives from which to
conceptualize the term. Some researchers have adopted a humanist orientation and view
practice as what people do (i.e. an array of human activities) (Schatzki, 2001). Focusing on
‘what people do’ however, does not give adequate attention to practice as something that is
shared between people (Wenger, 1998). By contrast, Wenger (1998) views practice as
42
highlighting the ‘social and negotiated character’ of how we understand the world and how we
build common understandings through mutual engagement in particular tasks (p. 47).
Focusing on ‘practice’ as something that ‘people do’ also detracts from the epistemological
dimension of practice. Gherardi (2009) views practice as a way of knowing and distinguishes
between ‘praxis’ (people’s actions) and practice as a generative source of knowledge.
According to Gherardi (2009), while actions start from the intentionality of individuals and
their desires to pursue courses of action, practices are viewed as coming from shared
understandings or ‘patterns in how conduct is enacted, performed and produced’ (p.115).
Other researchers who have adopted the epistemological perspective see practice as a
generator of social order. Reckwitz (2002) highlights the significance of shared or collective
knowledge in social order and Schatzki (2001) attributes social order to the nexus of shared
understandings, agreements, negotiations associated with what people do and say. In post-
humanist terms, some researchers have examined the role of objects in mediating relations
within the social world. According to Orlikowski (2007), the expertise of practitioners is
dependent on the alignment between the practitioner and the material (non-human) object.
She argues that the relationship between people and the objects they use is critical to
understanding practices.
Practice Concept References
Practices are self organizing and self-reproducing activities that are the basis of social order. Practices inform our practical understanding of the world (habitus).
Bourdieu, 1977, p.79
Practices are regularized acts enabled by social structures. Practices also reproduce social systems. Practices “are not brought into being by social actors but continually recreated by them via the very means whereby they express themselves as actors.”
Giddens, 1984, p.2
Practice is action informed by meaning drawn from a particular group context.
Cook and Brown, 1999, p. 387
Practice is considered as being complex, unpredictable and collective, and refers to a specific social system.
Schulz, 2005, p. 494
43
Practices are arrays of human activity organized around shared practical understanding.
Schatzki, 2001, p. 11
Practices (i.e. what people do) can be represented by describing the methods they employ. But these description are always partial since practice also includes tacit knowledge (i.e. personal know-how).
Lynch, 2001. p. 148
Practice as the conduct of transactional life, which involves the temporally-unfolding, symbolically-mediated interweaving of experience and action.
Simpson, 2009, p. 1338
‘Practices’ refer to shared routines of behaviour, including traditions, norms and procedures for thinking, acting and using ‘things’.
Whittington, 2006, p. 619
Practice is a way of talking about the shared historical and social resources, frameworks, and perspectives that can sustain mutual engagement in action.
Wenger, 1998, p. 5
Practice is a “routinised type of behaviour which consists of several elements, interconnected to one another: forms of bodily activities, forms of mental activities,‘things’ and their use, a background knowledge in the form of understanding, know-how, states of emotion and motivational knowledge.”
Reckwitz, 2002, p. 249
Practices are discernible patterns of actions arising from habituated tendencies and internalized dispositions rather than from deliberate, purposeful goal-setting initiatives. Practices are reflected in the patterned actions of actors, but they are also culturally and historically transmitted activities.
Chia and MacKay, 2007, p. 217
Practice is enacted knowledge. Practice theory is used to understand knowledgeability as grounded in everyday situated practice.
Orlikowski, 2002, p. 252; Feldman and Orloikowski, 2011; Gheradi, 2006
Practices are integral to the meaning and function of objects. The characteristics and capabilities of technologies are relational and enacted in practice. This idea is known as sociomateriality, which signals that technologies do not stand alone with certain inherent properties, but that their material characteristics and capabilities become salient only in relation with specific social practices.
Orlikowski, 2007
44
Practices provide “the behavioural, cognitive, procedural, discursive and physical resources through which multiple actors are able to interact in order to socially accomplish collective activity”.
Jarzabkowski et al., 2007, p. 9
Practice is a meaningful unit of work. It is a meaningful assemblage of human actors (including their intra-subjective and inter-subjective inner worlds), actions, linguistic objects (as utterances and documents) and material objects.
Goldkuhl 2011, p. 4
Table 3.1 Meanings of practice
Notwithstanding the different conceptualizations of the term, researchers who adopt a
practice perspective share a fundamental assumption that ‘social life is an ongoing production
and this emerges through people’s actions (Feldman and Orlikowski, 2011, p.1240). In
adopting a practice perspective, researchers have emphasized different foci. Whilst not using a
specific practice theory, some researchers have focused on how people act in organizational
contexts. Others have adopted a theoretical focus and have applied specific practice theories
to understand relations between the actions people take and the structures of social life. This
particular focus has attracted the attention of IS scholars. For example, IS researchers have
used Bourdieu’s theory of practice (e.g. Levina and Vaast, 2005), Gidden’s structuration theory
(e.g. Orlikowski, 2000), Wenger’s communities of practice concept (CoP) (e.g. Klein and
Hirschheim, 2008) and Orlikowski’s technology-as-practice approach (Andersson and
Lindgren, 2010). IS researchers have used practice theory to address the challenges of inter-
community connections and interactions in a range of contexts. For example, Klein and
Hirschheim (2008) used the CoP concept to reveal the paradigmatic fragmentation within the
IS discipline. Levina and Vaast (2008) used Bourdieu’s practice theory to understand the
challenges that arise in offshore-outsourced development projects due to different country and
organizational contexts. Researchers have used specific practice theories to examine cultural
differences in knowledge management systems (Mason, 2003), globalized digital libraries
(Mason, 2005) and global IT outsourcing (Levina and Vaast, 2008). Researchers have also
examined knowledge transfer and learning between different organizational units (Pawlowski
and Robey, 2004; Volkoff et al., 2004) using practice theories. In each of these studies,
45
important insights have been gleaned into the differences that exist between various
communities through a consideration of their practices, the meaning of boundaries between
practices, and how these boundaries can be bridged. The following table (See Table 3.2)
summarizes the practice areas investigated by IS researchers using a practice lens. A third
group of researchers have adopted a philosophical focus on the constitutive role of practices
in producing social reality and this includes Schatzki (2001) and Gherardi (2006).
IS Practices Investigated Using a Practice Lens
References
IT adoption/ use Orlikowski, 1999; Orlikowski, 2000; Levina and Vaast, 2006; Schultze and Orlikowski, 2004; Vaast and Walsham, 2005
Enterprise resource planning Boudreau and Robey, 2005
Information systems development
Cronholm and Goldkuhl, 2002, 2004; Bijker and Law, 1992; Levina and Orlikowski, 2009
Mobile technology implementation and use
Mazmanian et al., 2006; Cousins and Robey, 2005
System implementation and use Levina and Vaast, 2005
Off-shore collaboration/ Outsourcing
Levina and Vaast, 2008
IS research Klein and Hirschheim, 2008
Knowledge management Mason, 2003; Mason, 2005
Knowledge transfer and learning
Volkoff et al., 2004; Jonsson et al., 2009
Business analysis Vashist et al., 2010, 2011a, 2011b
Table 3.2 Applications of practice theory in IS research
46
Although the adoption of a practice lens has been beneficial in organizational and IS studies,
practice theorists argue that there are areas in which practice studies could be improved. More
engagement is required with the practitioner who enacts ‘practices’ and more understanding is
needed of how ‘practices’ evolve (Nicolini, 2012; Simpson, 2009). This would allow for analysis
of change within practices focusing on “innovative action, novel thinking creativity, and emergent practices”
(Elkjaer and Simpson 2006, p. 1). Secondly, there is a risk that in attempting to describe what
people do and foregrounding the activities of people, we become a-theoretical and simply
catalogue the list of things that people do (Schatzki, 2001). This approach sheds little light on
the meaning of the work of practitioners and the relationships between them. Thirdly, as
practice studies are based in a particular context they may not be able to compete with the
generalizations of “full-blown ‘grand theories” (Reckwitz, 2002, p.257). They can however, provide
useful heuristic devices for practitioners.
My research addresses all three areas in the following ways. Firstly, I adopt an empirical focus
on understanding the practices of a group of architects and seek to understand the meanings
manifest in the social interactions between architects and their stakeholders. Secondly, my
research has a theoretical focus as I use a specific practice theory to inform the empirical work.
The practice perspective allows me to examine the nature of the social processes associated with
an enterprise architecture implementation (EAI) rather than viewing EAI in a functional and
task-based manner. Thirdly, I aim to provide a theoretical understanding of the implementation
roles and practices of architects, which may provide useful insights and suggestions for
practitioners.
3.3 A Communities-of-Practice (CoP) Perspective
In this research, I adopt Wenger’s (1998) communities-of-practice (CoP) theory. A CoP is a
social configuration with its own practices (i.e. shared resources, frameworks and
perspectives), which sustain the mutual engagement of individuals in the CoP. Wenger’s
(1998) theory is broad and allows me to investigate ‘what’ people do, the shared logic driving
‘what people do’ and the shared physical artifacts that are used to mediate relations within the
47
group. I also adopt Wenger’s (1998) ontological position that organizations are essentially
‘constellations’ of interacting practices.
3.3.1 Evolution and Conceptual Dimensions of CoP
The early definitions of a CoP viewed CoP as a “set of relations among persons, activity and world,
over time and in relation with other tangential and overlapping communities of practice” (Lave and Wenger,
1991, p. 98). When this concept was applied to organizational research it led scholars such as
Brown and Draguid (1991, 1998) to view organizations as communities of communities or in
Wenger’s (1998) terms, “constellations of practices” (p.126).
Whereas treating such configurations as single communities of practice would gloss over
the discontinuities that are integral to their very structure, they can profitably be viewed as
constellations of interconnected practices (p.127).
The relationship between practice and identity subsequently attracted the interest of CoP
theorists. The view that practice is a way of learning for community members lead
theorists to examine how an individual’s identity changes over time as they develop
competencies and accumulate experiences and relationships with people and places.
The focus on the social aspect of learning is not a displacement of the person. On the
contrary, it is an emphasis on the person as a social participant, as a meaning-making
entity for whom the social world is a resource for constituting an identity. This meaning-
making person is not just a cognitive entity. It is a whole person, with a body, a heart, a
brain, relationships, aspirations, all the aspects of human experience, all involved in the
negotiation of meaning. The experience of the person in all these aspects is actively
constituted, shaped, and interpreted through learning. Learning is not just acquiring
skills and information; it is becoming a certain person - a knower in a context where
what it means to know is negotiated with respect to the regime of competence of a
community (Wenger 2000, p.2).
48
Within the literature, the CoP concept is interpreted in two ways. Firstly, it is used to discuss
how knowledge management in organizational communities can be established and nurtured
to support and enhance other knowledge management initiatives and structures and hence has
a ‘how to’ focus (Wenger and Snyder, 2000; Wenger et al., 2002; Newell et al., 2002; Hislop,
2005).
Secondly, the CoP concept is discussed as a specific practice theory and this is the sense in
which the concept is used in this research. Researchers who use the CoP concept to study
organizations use it to understand how organizations are made up of a federation of various
communities (Brown and Draguid, 1991; Wenger, 1998; DeSanctis, 2003; Vashist et al., 2010),
how these communities may be in competing relationships (Brown and Draguid, 1991), the
potentially destructive role of groupthink (Wenger, 2010) and the problems of exclusivity and
insularity within communities (Newell et al., 2002). CoP theory has been applied to
understand how practices can create epistemic barriers between communities and how
practices can impede the flow of knowledge between communities (Cohendet et al., 2001).
Further, CoP has also been used to help non-practitioners understand the ‘lifeworlds’ of
community members (Klein and Hirschheim, 2008). This research affirms the
appropriateness of CoP as a theoretical lens for research into the problems of EAI failure, an
area in which it has not previously been used.
The conceptual dimensions of Wenger’s (1998) CoP theory inform my empirical work for
understanding the EAI practices of architects. In order to understand these dimensions, I will
examine what is meant by ‘practice’ in the CoP concept and how it is related to a community
(i.e. to a social configuration).
3.3.2 Wenger’s (1998) Interpretation of Practice
Wenger’s (1998) definition of practice includes tacit and explicit practices, that is, what can be
easily observed, as opposed to what is intrinsic and not easily articulated. These two types of
practices are defined in the following table (See Table 3.3).
49
Explicit ‘language, tools, documents, images, symbols, well defined roles, specified criteria, codified procedures, regulations, and contracts that various practices make explicit for a variety of purposes’.
Tacit ‘implicit relations, tacit conventions, subtle cues, untold rules of thumb, recognizable intuitions, specific perceptions, well tuned sensitivities, embodied understandings, underlying assumptions and shared world views’
Table 3.3 Types of practices (Based on Wenger, 1998, p.47)
The central assertion of the CoP concept is that tacit and explicit practices take place within a
social configuration and are a source of shared perspective and social cohesion within that
group. To represent the relationship between tacit and explicit practices and social cohesion,
Wenger uses three conceptual dimensions: mutual engagement, joint enterprise and shared
repertoire (See Figure 3.1). Mutual engagement (ME) suggests that members of a community
of practice jointly engage in discussion, negotiation and exchange information by means of
their physical co-location, mutually complementary roles and shared goal orientation. Joint
enterprise (JE) implies that common interests, accountabilities and shared goals hold the
community of practice together. A shared repertoire (SR) of resources and practices suggests
that community members develop a shared ‘toolkit’ of resources (activities, symbols and
artifacts) through which they make sense of the world and which in turn, become identified
with the community (Wenger, 1998).
50
Figure 3.1 Three dimensions of practice (Based on Wenger, 1998, p.73)
3.3.3 Criticisms of the CoP Concept
In a comparative study of four seminal works on CoPs (Lave and Wenger 1991, Brown and
Duguid 1991, Wenger 1998, and Wenger et al., 2002), Cox (2005) noted basic differences in
the way key concepts such as community, learning, power, change, diversity and informality
were conceptualized. Cox (2005) views these differences as a source of continuing confusion
in CoP writing. However, as discussed earlier, although researchers who adopt a practice
perspective share a common assumption about the relationship between social structures and
recurrent actions, they may adopt different theoretical positions regarding the nature of the
relationship. Further, practice researchers may emphasize different meanings associated with
the term ‘practice’. While this diversity may be seen by some to contribute to the unstable
identity of the practice lens (Reckwitz, 2002), other scholars are more tolerant of the different
meanings. They see the field of practice theory rather than any one specific practice theory as
51
building a representative picture of the organizational world. Nicolini (2012) states,
While practice theories can offer a radically new way of understanding and explaining
social and organizational phenomena, they can only be approached as a plurality. Much
is to be gained if we appreciate both the similarities and differences among practice theories
(p.1).
My use of Wenger’s (1998) CoP theory and concepts, whilst not limited to, is predominantly
drawn from his Communities of Practice (1998). Wenger’s later works including Wenger et al.,
(2002) and Wenger (2010) demonstrate that whilst the meaning and nuances of some concepts
may have changed in his later writings, the ontological premise of his CoP theory (that
organizations are constellations of practices) and the meanings of its conceptual dimensions of
mutual engagement, joint enterprise and shared repertoire have remained constant.
Another criticism of the CoP concept is that it does not represent all types of workplace
learning (Fuller et al., 2005) and does not differentiate between different types of knowing in
action (Amin and Roberts, 2008). Amin and Roberts (2008) highlight that Lave and Wenger’s
(1991) original conceptualization of CoP was based on craft-based knowing, but there are
other forms of knowing-in-action, such as epistemic or high creativity knowing, professional
knowing and virtual knowing which “defy easy codification and standardization” (p. 365). Whilst
these criticisms may reflect a bias in Lave and Wenger’s (1991) case studies, the purpose of the
case studies is to illustrate a theoretical perspective, not to encapsulate an exhaustive typology
of learning modalities. Further, Wenger (1998) does examine professional learning in
organizational settings. However, in terms of virtual knowing, Lave’s and Wenger’s (1991)
work is a child of its time and reflects a period before face-to-screen video conferencing and
other forms of social mediating technologies existed or became commonplace in
organizations. In spite of these criticisms, my purpose in using Wenger’s (1998) CoP theory is
to understand the social processes that underpin the emergence of shared meaning and actions
rather than assess the efficacy of the theory to describe different types of learning.
Other scholars have expressed concerns about the validity of the CoP concept when applied
to social configurations of different sizes and also geographically dispersed social
52
configurations (Roberts 2006). Wenger (1998) illustrates the CoP concept with references to
cases that are based on craft-based as well as organizational communities where individuals are
located in the same physical space. However, Wenger’s CoP theory offers a generic lens and
could be assumed to apply equally to both small and large groups. Nonetheless, the social
configurations under investigation in this research are of similar size and are located in the
same geographical region.
A common criticism is that CoP theory does not place enough emphasis on issues of
power. Roberts (2006) and Cox (2005) for example, argue that CoP theory does not deal with
the role of power in the negotiation of meaning in a CoP. Firstly, Wenger (1998) does not
describe CoPs as harmonious and homogeneous and he says that CoPs can include
disagreement and conflict. Secondly, Wenger’s (1998) CoP theory is a theory of learning, not a
political theory. He did not set out to discuss power and how power may influence CoPs.
Consequently, Wenger (1998), views power not in terms of force, conflict and domination, but
instead believes that “power derives from belonging as well as from exercising control over what we belong
to” (p. 207). Within Wenger’s (1998) CoP theory, power is about belonging and not belonging,
being included or being excluded. Accordingly, Wenger treats issues of power in terms of the
‘negotiation of meaning and the formation of identities’ within CoPs (p.190). Whilst I
acknowledge that power is an inherent part of social relations, Wenger’s (1998) CoP theory is
foremost a social theory of learning and epistemologically, research based on a CoP lens will
not return data that is adequate for understanding the power relations between CoPs.
Consequently, power relations between architects and their stakeholders are outside of the
scope of this research.
This may lead some to ask, what is the relevance of a social theory about learning to this
research? Wenger’s (1998) CoP theory situates learning not in the head or outside of it,
but in the relationship between the individual and social world. Learning is a form of
participation in a social group and a way of becoming a member of that group. Whilst
Wenger (1998) views learning from four perspectives (identity, meaning, practice and
community), it is the community perspective that I am interested in since this describes
the processes through which people in a social group determine what is important,
53
meaningful and worth pursuing. Though power may be integral to that decision making
process, there are also other factors such as negotiation, discussion, agreement and the
reconciliation of values, views, concerns, objectives, etc., that are also relevant and it is the
social processes and competencies that enable negotiation, discussion and agreement
around a phenomenon of interest that I am interested in.
Though the CoP lens has been applied in a wide range of organizational settings (Roberts,
2006), critics argue that it is inadequate to understand corporate culture (Fox 2000). On the
contrary, I believe Wenger’s (1998) CoP theory is a way to understand, at a high level,
organizational culture and the discontinuities between cultures within organizations. As
described by Wenger (2000), CoPs are like ‘mini-cultures’ with their own stories, language,
objects, values, etc. (p.4). From the perspective of Wenger’s (1998) ontological position,
organizations can be viewed as constellations of interconnected mini-cultures. Whilst I am not
interested in adopting a specific cultural focus, adopting a CoP lens does illuminate the
landscape of different cultures within an organization and offer insights that may lead to
meaningful suggestions to practitioners.
In conclusion, whilst the criticisms of Wenger’s (1998) CoP theory may be relevant in other
contexts, they are not significant to this research. The strengths of its ontological position and
its conceptual dimensions of joint enterprise, mutual engagement and shared repertoire for
understanding the social relations in organizational contexts far outweigh the criticisms. The
CoP concept is suitable for studies in organizational settings as it was developed in and has
been widely applied as a theoretical lens in such settings (Brown and Duguid, 1991, 1998,
2001; Cohendet et al., 2001; Creplet et al., 2001; Garrety et al., 2004; Iverson and McPhee, 2002,
2008; Mutch, 2003; Vaast, 2004). As stated earlier, architects undertake enterprise architecture
implementations in organizations that can be viewed as constellations of interacting
communities and the dimensions of joint enterprise, mutual engagement and shared repertoire
are valid sensitizing tools for my research interest into how architects build connections with
those communities.
54
3.4 The Concept of Practice Boundaries
Wenger (1998) uses the concept of boundaries to delimit communities of practice (p. 129).
According to Wenger (1998) boundaries are not socially visible and denote discontinuities,
“lines of distinction between inside and outside, membership and non-membership, inclusion and exclusion”
(Wenger, 1998, p 120). He argues that an organization, independent of its size, is not
homogeneous in its practices and, rather than being viewed as a single CoP, it can be seen as
being made up of a constellation of practices (See Figure 3.2).
Figure 3.2 Organizations as constellations of practices
Wenger (1998) identifies three ways in which connections between two communities can arise:
boundary practices, overlaps and periphery connections. Periphery connections between
communities allow non-members various forms of casual and legitimate access to the practices
of a community, ‘without subjecting them to the demands of full membership’ (p.116).
Periphery connections can ‘involve observation, but can also extend beyond that to actual
forms of engagement’ (p.116). Overlaps are result of ‘direct and sustained interactions’
between two communities and are enacted by individuals who are skilled in the practices of
55
another community. Boundary practices evolve over a period of time as connections form
between two practices and have a specific goal: “to deal with boundaries and sustain a connection
between a number of other practices by addressing conflicts, reconciling perspectives, and finding resolution”
(Wenger 1998, p. 114).
Although the connections between CoPs are an important issue in the sense of organizational
function, there is very little research in the CoP literature that has systematically applied the
overlapping, boundary practice and periphery connection concepts. In a recent study, Vashist
et al. (2010) applied the boundary practice concept to the practices of business analysts and
whilst providing interesting insights into the roles and practices of business analysts, they do
not draw on the dimensions of joint enterprise, mutual engagement and shared repertoire to
examine the social processes associated with a boundary practice.
To supplement the limited research associated with boundary practices, overlaps and periphery
connections, I discuss relevant literature on boundary spanning, assuming that it holds
relevance since it may well be an antecedent to connections between CoPs. Boundary
spanning is viewed as a means toward building connections between CoPs as individuals are
involved in a social configuration in which they attempt to bridge the boundaries between
their own CoP and the CoPs of others. In the sections that follow, I discuss relevant literature
on boundary spanning research.
3.5 Boundary Spanning and Boundary Objects
Boundary spanning is a construct that ‘refers to crossing or bridging a boundary and is
grounded in open system theory in which the boundary is simultaneously a barrier and
permeable’ (Paulsen and Hernes, 2003, p 8). Boundary spanners are people who are involved
in a social configuration and who use artifacts (boundary objects) to connect to other
communities. Boundary spanners are critical in the creation and development of inter-
organizational partnerships (Sullivan and Skelcher, 2002; Williams, 2002; Marchington et al.,
2005) and in creating linkages between the organization and the external environment (Aldrich
and Herker, 1977; Steadman, 1992; Kickert et al., 1997). Levina and Vaast (2006) state that
56
boundary spanners take on, in part, the identity and interests of individuals in another
community while representing their relationships through the jointly produced boundary
objects and that through a wider adoption of these objects (artifacts), other individuals may
join the new boundary spanning practice.
Whilst boundary spanners are the human means through which communities connect,
boundary objects are processes or material objects that mediate relations and knowledge
between individuals involved in boundary spanning activities. Boundary objects are resources
in shared meaning creation (Lindgren et al., 2008) and serve as symbols of the newly acquired
identity, thereby identifying a group of boundary spanners (Levina and Vaast, 2005).
Boundary objects are described as localized and embedded knowledge resources which are
useful for “representing, learning about, and transforming knowledge to resolve the consequences that exist
at a given boundary” (Carlile, 2002, p. 442). Boundary objects are relevant to the practices of
multiple communities, but are used or viewed differently by each of them (Brown and Duguid,
1998). Boundary objects may be “artefacts, documents, terms, concepts, and other forms of reification
around which communities of practice can organize their interconnections” (Wenger, 1998, p. 107).
3.5.1 Boundary Spanning and Boundary Object Research
Researchers working in several disciplines have undertaken boundary spanning and boundary
object (BSBO) research. Researchers working in the management discipline have shown
greatest interest in BSBO research and have focused on the role of boundary spanners as they
form linkages that connect organizations with the external environment (Thompson, 1962).
Others have examined the different purposes of this linkage, ranging from knowledge
exchange relationships (Aldrich and Herker, 1977; Steadman, 1992) and the gathering of
information (Boulton et al., 1982), the achievement of inter-organizational coordination
(Sullivan and Skelcher, 2002), to developing and maintaining inter-organizational collaboration
or partnerships (Marchington et al., 2005). Boundary-spanning individuals have also been
observed to be important in spanning boundaries within organizations, in order to achieve
cooperation between departments (Lysonski, 1985). Other significant contributions to BSBO
research have come from sociology of the workplace (e.g. Star and Griesemer, 1989) and
57
education and learning research (e.g. Wenger, 1998).
There are a number of different types of boundary spanning described in the literature (See
Table 3.4). Boundaries can be physical, social, mental, organizational (Hernes, 2003) and
consequently, there is no single, widely accepted definition of boundary spanning. Different
definitions focus on professional boundaries (Edwards, 2012; Amedore and Knoff, 1993), on
perceptions and thoughts (Ankney and Curtin, 2002), on the importance of emotions
(Bacharach et al., 2000), and in a study of off-shoring, several types of boundaries (operational,
social, and knowledge) were identified (Krishnan and Ranganathan, 2009). Nonetheless, there
is an underlying assumption within the literature that in a social context, boundaries depend
on social interactions for their existence and differentiate one social group from another
(Hernes, 2003). Social boundaries also contain characteristics that come to the foreground
only in the experience of people at the boundaries (Diamond et al., 2004). Therefore, in this
research, I conceptualize the boundaries that differentiate one CoP from another in terms of
the perspectives, values and expectations of their members and I examine these differences
empirically.
A second assumption manifest in the BSBO literature is that people involved in boundary
spanning are motivated to bring about a connection between two CoPs. Relatively recent
research however indicates that boundary spanners involved in tripartite arrangements (three
communities) may be motivated in other ways. Vashist et al., (2010) found that business
analysts whilst they are expected to bridge the boundaries between the users and technology,
they are also expected to ‘protect’ users and IT staff from each other. They found that BAs
play the role of the ‘drawbridge’ for the users and ‘moat’ for the IT staff. This would suggest
that the complexity of the boundary spanning role increases as the number of CoPs involved
in the boundary spanning arrangement increases. My research potentially provides a more
complex multi-dimensional boundary spanning arrangement and may provide evidence of
additional roles and practices associated with boundary spanning.
58
Definitions of Boundary Spanning Reference
Boundary spanning facilitates the development of exchange relationships between an organization and its external environment. Boundary spanners are viewed as representatives of the organization.
Aldrich and Herker, 1977
Boundary spanners are persons who operate at the periphery or boundary of an organization, performing organizational relevant tasks, relating the organization with elements outside it.
Leifer and Delbecq 1978, p. 40-41
Boundary spanning creates linkages between the organization and the external environment and between departments within organizations. Product managers are viewed as boundary spanners as they function as transmitters of information about the product from the environment into the firm and vice versa.
Lysonski, 1985
Boundary spanning is the complete set of activities necessary to build support for the embryonic product, shape the demands of others, and coordinate the product’s development with other groups.
Ancona and Caldwell, 1990, p. 120
Boundary management implies choosing boundary management tactics, the set of tactical decisions actors make about their emotional investment in other actors.
Bacharach et al., 2000, p. 706
Boundary spanning individuals working within teams help build a common “construct of interest” between members of those teams. Boundary spanning is based on shared experiences, attitudes, perceptions, values, cognitions, or behaviors that are held in common by the members of a team. Boundary spanners reflect on the factors or processes which constrain variability among team members, rendering the construct of interest a shared property of the team?
Klein and Kozlowski, 2000
Boundary spanning occurs when professionals involved in children’s services cross the formal or informal professional or occupational boundaries that exist in their work environments to interact and coordinate their work with other professionals, resources, or agencies.
Edwards, 2012
Boundary spanners are individuals who develop and maintain interorganizational partnerships and play an important role in moderating the tensions between the orientations of different communities.
Sullivan and Skelcher, 2002
Boundary spanning clarifies the perceptions, thoughts and needs of the different groups to each other.
Ankney and Curtin 2002, p. 230
59
Team boundary spanning is intended to establish relationships and interactions with external actors that can assist their team in meeting its overall objectives. Boundary spanning activities are externally directed and serve an information-gathering function, or fulfill an external representation function, as team members communicate with external stakeholders to set expectations on team objectives, frame requests for needed resources, and update managers on project status. Boundary spanning involves establishing relationships with external actors with whom the team works interdependently or who can provide valued and needed resources.
Marrone et al., 2007, p. 1424
The capability to establish boundary-spanning practices within and across organizations has for a long time been recognized as a key strategic resource. Boundary spanning is a sense-making activity aimed at making sense of information that is perceived relevant to expand[ing] the knowledge of a given organizational activity.
Lindgren et al., 2008, p. 643
Boundary spanners connect distributed teams and facilitate knowledge sharing and coordination. Knowledge boundary spanning is defined as activities that facilitate locating and accessing external knowledge and incorporating it with functional and technical expertise within the organization.
Krishnan and Ranganathan, 2009
Table 3.4 Definitions of boundary spanning
In information systems (IS), BSBO research has been advanced by a number of scholars
working in the field (e.g. Vashist et al., 2010; Levina and Vaast, 2005, 2008; Pawlowski and
Robey, 2004; Lindgren et al., 2008). Whilst researchers have not previously applied BSBO
theory to EAI, there are four studies that are directly relevant to the EAI activities and roles of
architects. These studies are interested in the roles and practices of individuals involved in
boundary spanning activities (Vashist et al., 2010), the importance of knowledge transfer across
different practices (Pawlowski and Robey, 2004; Volkoff et al., 2004,), the integration of
practices with diverse expertise (Levina and Vaast, 2005) and are summarized in Table 3.5.
60
Reference Motivations for the study
Purpose of the study Theoretical guidance
Findings
Pawlowski and Robey, 2004
Understanding the practices of people responsible for facilitating knowledge transfer within organizations.
To identify the conditions, practices and consequences surrounding the role of knowledge broker, as played by IT professionals.
Boundary spanning and situated learning literature
Makes the critical point that the combination of boundary spanning individuals and boundary object(s) is critical to knowledge transfer across organizational boundaries. Neither the object nor individual alone would be likely to account for knowledge transfer.
Argues that shared objects provide the opportunity for boundary spanners to enter multiple organizational units and to transfer both technical and business knowledge across an enterprise.
61
Volkoff et al., 2004
Understand barriers to knowledge transfer between organizational CoPs.
Examine the barriers to knowledge transfer and identify mechanisms for overcoming them.
CoP Findings indicate that the main barrier to knowledge transfer between CoPs is the lack of common purpose (mutual engagement) and common practices (shared repertoire) between them. Boundary spanners must enact new practices that account for others’ practices.
62
Levina and Vaast, 2005
Understand practices that allow organizations to integrate diverse bases of expertise and overcome knowledge embeddedness and tacitness.
Understand how organizations develop boundary spanning and boundary object competencies. Understand how IT based artifacts can facilitate boundary spanning.
Bourdieu’s Practice Theory
Boundary spanners (a) become a legitimate, but possibly, peripheral, participant in the practices of both fields (b) they have legitimacy, not only as participants, but also as negotiators on behalf of the field whose interests they represent (c) boundary spanners have an inclination to boundary spanning and this inclination may stem from the perceived advantages associated with spanning boundaries (d) reflect on objects in each field and reflect on their utility in the context of the new joint field (e) create new artifacts and attempt to establish their new identity within the context of the new joint field, and (f) establish the local usefulness and symbolic value of the artifacts they are promoting as boundary objects.
63
Vashist et al., 2010
To understand if business analysts are able to effectively bridge the user-IT gap while determining business requirements.
Undertake practitioner-grounded research into the roles and practices of business analysts who are involved in determining business requirements.
Wenger’s CoP Firstly, people involved in boundary spanning activities may be involved in multiple roles: protecting and providing access to different CoPs. Secondly, boundary spanners are required to learn to live in the ‘world’ and to speak the ‘ language’ of individuals from the other CoP. Third, the concept of power or as Wenger (1998) describes it as negotiation of meaning plays out with more complexity for boundary spanners like BAs. Negotiating with practices across boundaries seems more important than negotiating within their own practice.
Table 3.5 IS studies directly relevant to the EAI activities of architects
64
These studies make significant contributions to BSBO research and are relevant to this
research. Levina and Vaast (2005) discuss the conditions under which boundary spanners
emerge and make use of boundary objects. Although there was a large pre-existing
volume of literature on boundary spanning, there was little explicit focus on how a
boundary spanning competence emerges in practice and the role of artifacts in promoting
joint fields. They also suggest that boundary objects do not emerge until a joint field is
established. However, is it possible for joint fields to emerge around artifacts and if so,
what are the boundary implications for CoPs? For example, should CoPs make efforts to
reduce the ‘thickness’ of their boundaries by allowing others casual access to their
knowledge and documentation? Furthermore, there is a distinction to be made between
boundary spanning-in-practice and boundary spanning-in-theory since in a theoretical
context, boundary spanners are nominated, designated and do not have ‘rival’ boundary
spanners. In practice, however, people in boundary spanning positions who fail to
develop an interest in boundary spanning may find others from within their own CoP or
from other CoPs taking on that role. This could for example, lead to role ambiguity
within a CoP as individuals take on more than their designated tasks to compensate for the
lack of a boundary spanner. It could also lead to bias within arrangements involving three
or more CoPs as connections between some CoPs may be stronger than with others
because of the greater boundary spanning efforts between them.
Vashist et al., (2010) found that the perceived trust of individuals is critical to the work of
boundary spanners. Organizational structure and the backgrounds of people involved in
boundary spanning roles can influence their work practices and this can influence the
closeness or distance of boundary spanners from the people they are engaging, the focus
of their work and the perceived trust of the individuals they are engaging with. Vashist et
al., (2010) suggest that boundary spanners should be located with the groups they are
engaging with and share the same physical office space as the groups they are engaging
with. An interesting point raised by the study is how do boundary spanners balance their
identity as members of their own CoP with their role as boundary spanners since they may
share the same office space as the people they are connecting with. This also has
implications for the professional learning of boundary spanners who may spend more time
in other CoPs than their own. The relevance of this research is that trust is seen as a
critical determinant of the effectiveness of boundary spanning and methods to build trust
though co-location may not be possible in multi-dimensional or ‘one-to-many’
65
arrangements, where boundary spanners engage with more than one CoP. Consequently,
we should investigate other ways to enable effective boundary spanning apart from
physical co-location. Furthermore, we should investigate the potential for identity and
bias issues associated with boundary spanning work. Are boundary spanners at risk of
losing their identification with the CoP they are members of and being perceived as
members of the CoP they are engaging with and what can organizations do to mitigate this
potential risk?
Pawlowski’s and Robey’s (2004) findings indicate that the tasks boundary spanners
undertake are an extension of their primary designated roles and that effective boundary
spanning involves re-framing these tasks in terms of the worldview of the other
community. In order to achieve this, boundary spanners must not only be inclined toward
learning about the practices of the other CoP, they must also be able to reflect on the
suitability and efficacy of the re-interpreted tasks and objects to promote the necessary
knowledge transfer. Learning about the world of the ‘other’ is an important aspect of the
boundary spanner’s work and Pawlowski’s and Robey’s (2004) findings indicate that
boundary spanners develop knowledge about the other CoP through their interactions in
the joint field. That suggests that what is meaningful and important to individuals
involved in boundary spanning activities may be different to what is meaningful and
important within their own CoP and that effective boundary spanning involves an
empathetic understanding of the ‘world’ of the other. These insights are relevant to my
research since they focus on the relational aspects of boundary spanning and focus
attention on the extent to which boundary spanners are able to take into consideration
what is important and meaningful to others and reflect those views and concerns in their
own understanding of the complexity of a task, problem or solution.
Volkoff et al., (2004) adopted a CoP perspective and provided significant insights in to
boundary spanning between two CoPs. Boundary spanners are required to build ‘bridges’
between two CoPs and the presence of boundary spanners reduces the distance between
them. They found that individuals who operate effectively as boundary spanners are able
to reconcile the purposes and practices of their own CoP with those of the CoP they are
engaging with. They are able to adapt their practices to account for the requirements of
the boundary engagement and build a common purpose with individuals they engage with.
An implication of Volkoff et al., (2004) for this research is that they allude to the social
complexity of the boundary spanner’s role and this perhaps explains why some
66
organizational initiatives such as an enterprise architecture implementation which are
dependent on effective boundary spanning between constituent CoPs are unsuccessful.
This research also adopts a CoP perspective to examine in detail the social processes
associated with boundary spanners’ efforts to assimilate the concerns and objectives of
others into their understanding of a task, problem or solution. The study also uses BSBO
theory to understand how people involved in spanning CoPs are able to facilitate mutual
engagement between CoPs. Grounded theory as my data analysis method will be used to
go beyond the theoretical insights provided by BSBO theory and examine the behaviors,
tools and perspectives that are conducive to effective boundary spanning.
3.5.2 Implications of Boundary Spanning and Boundary Object Research to
This Research
In the absence of any appropriate theory dealing with connections between CoPs, my
research is informed by BSBO research. BSBO research is viewed as providing a
theoretical foundation for understanding the processes and practices that enable two CoPs
to work effectively together in a relationship of mutual engagement. As noted in the
selected IS BSBO research, boundary spanners are necessary for ‘bridging’ two CoPs and
help to reduce the distance between CoPs (Volkoff et al., 2004). They are able to reflect
on the appropriateness and efficacy of existing tools and create new boundary objects that
facilitate knowledge exchange between communities (Pawlowski and Robey, 2004) and
which reconcile the perspectives, objectives and relevant knowledge within those
communities (Volkoff et al., 2004). Boundary spanners are able to build close working
relationships with individuals from ‘other’ CoPs and may be co-located with those
individuals in shared office arrangements (Vashist et al., 2010). Boundary spanners are also
able to understand the ‘world’ of the ‘other’ and have an empathetic understanding of
what is important and meaningful for those individuals (Pawlowski and Robey, 2004).
Importantly, they are able to incorporate the concerns and objectives of other CoPs in to
their own understanding of a phenomenon of interest.
Based on the discussion of CoP and BSBO concepts, in the next section I discuss the
research questions.
67
3.6 The Research Objective and Research Questions
In this research, the CoP and BSBO concepts are adopted for two reasons. First, the CoP
lens and the conceptual dimensions (joint enterprise, mutual engagement and shared
repertoire) allow me to conceptualize the roles and practices of architects in terms of
relations between CoPs. Stakeholders are not seen in isolation as individual agents
operating in a vacuum, but as members of CoPs with their own distinct perspectives,
values and tools. This is significant as it de-personalizes the difficulties that architects
have in building effective relations with their stakeholders and focuses the researcher’s
attention on the dominant attitudes and perspectives associated with architects as an
organizational social group (Wenger, 1998). The researcher is also encouraged to examine
the methods of social cohesion and knowledge transfer within the communities in order to
understand how these dominant attitudes and perspectives emerge and are maintained
(Wenger, 1998). Secondly, CoP research has paid little attention to connections between
CoPs, and this makes it necessary to draw on other relevant theories to supplement the
theoretical ‘gaps’ within CoP theory. BSBO research has highlighted what might
contribute to the creation of effective connections between CoPs (Volkoff et al., 2004), but
more recent research (Vashist et al., 2010) highlights the difficulty that people involved in
boundary spanning roles may have in developing trust. It is hoped that by focusing on the
conceptual dimensions associated with Wenger’s (1998) CoP theory (mutual engagement,
joint enterprise and shared repertoire), this research will illuminate the social processes
through which boundary spanners are able to build trust with those they are expected to
build connections with.
CoP and BSBO concepts are used in this research for understanding the EAI practices of
architects. First, by using the CoP concept, I aim to build an understanding of the EAI
roles and practices of architects and also examine the nature of the boundaries that may
form around communities of architects. Second, by using the boundary spanning
perspective, I aim to investigate how architects build effective connections with ‘other’
CoPs and which enable them to bridge the boundaries between themselves and people
belonging to other communities. This became the basis of the second research question
that focused on the interactions between architects, business and technology staff.
Thus, the broad, overarching objective for this research can be stated as follows:
• To gain an understanding of the roles and practices of architects engaged in an
68
EAI by using the CoP and boundary spanning perspectives.
From this objective, I have derived two research questions.
• Research Question 1: What insights into the relationship between the EAI practices of architects
and the outcomes of EAI initiatives are possible using the theoretical lenses of CoP and BSBO
theory?
• Research Question 2: What new theoretical insights beyond those provided by CoP and BSBO
theory are possible using grounded theory?
In summary, the focus of the two research questions is illustrated by Figure 3.3. The first
research question will provide insights into architects’ practices through an examination of
their interactions with each other and the meanings associated with the methods,
processes, tools, and documentation templates that they develop and use. The second
research question will provide insights into the challenges architects face in their
interactions with business and technology staff. The operationalization of the research
questions is discussed in chapter four.
Figure 3.3 Research question focus
69
Chapter 4
4 RESEARCH METHODOLOGY AND DESIGN
4.1 Introduction
This chapter provides a detailed discussion of the research design for this research.
Research design is the ‘logical blueprint’ which connects the empirical data to the study’s
initial research questions and, ultimately, to its conclusions (Yin, 2011, pp. 75-76). It deals
with the overall purpose of a research study, research questions, conceptual context and
methods (Maxwell, 1996). According to Myers (2009),
Research design involves deciding upon all the various components of a research
project: your philosophical assumptions, your research method, which data collection
techniques you will use, your approach to qualitative data analysis, your approach to
writing up (Myers 2009, p. 19).
This study incorporated the above research design elements in its planning and
operationalization (see Figure 4.1).
In this chapter, I investigate possible candidate research paradigms and their philosophical
assumptions in order to justify the selection of an interpretive research paradigm.
Secondly, I discuss the selection of the case study method. Thirdly, I discuss the following
key elements of the case study method: the definition of the case, multiple case study
design, case selection, strategies for data collection and analysis, and the approach to
presenting the research.
70
Figure 4.1 Research framework adopted for this study
4.2 Research Paradigms and Their Philosophical Assumptions – Positivist,
Critical Research and Interpretivist
The term ‘research paradigm’ refers to a set of underlying philosophical assumptions
about the nature of reality, what constitutes valid research and which research methods are
appropriate (Iivari et al., 1998). A research paradigm ‘defines, for its holder, the nature of the
“world” and the individual’s place in it’ (Guba and Lincoln, 1994, p.107) and “to be located in a
particular paradigm is to view the world in a particular way” (Burrell and Morgan, 1979, p. 24).
Regardless of their ‘worldview’, research paradigms make two fundamental assumptions
about the world and how we can know it: ontology and epistemology. Ontological
assumptions refer to beliefs about the nature of physical and social reality. More
specifically, these assumptions answer the question: “What is the form and nature of reality and,
therefore, what is there that can be known about it” (Guba and Lincoln, 1994, p. 108)?
71
Epistemological assumptions refer to beliefs about what it means to know (Crotty, 1998),
or what is the relationship between the researcher and what can be known (Guba and
Lincoln, 1994, p. 108).
In discussing research paradigms, scholars have suggested different classification schemas.
I use Orlikowski and Baroudi’s (1991) classification scheme, which itself is based on
Chua’s (1986) work. They suggest three research paradigms: positivist, interpretive, and
critical. Although this classification schema is just one of many, this three-fold distinction
seems to have been widely embraced within the IS research literature (Myers and Klein,
2011; Klein and Myers, 1999; McGrath, 2005; Myers 2009; Richardson and Robinson,
2007; Stahl and Brooke, 2008).
Ontologically, researchers who take a positivist position treat the phenomenon of their
study from an objectivist position (Crotty, 1998). Objectivism assumes that the world,
including the social world exists independently of consciousness and experience and is
made up of hard objective phenomena (Crotty, 1998). To a positivist, the world can be
explained by ‘empirically testable theories that can be verified and falsified’ (Orlikowski
and Baroudi, 1991, p. 10). As social researchers, positivists believe that the methods of the
natural sciences can be applied to the study of human affairs. According to positivists, the
study of the social world is value-free and the social world is composed of relatively
concrete empirical facts and relationships, which can be identified and measured using
approaches adapted from the natural sciences (Burrell and Morgan, 1979, p. 26).
Positivists view the social world in deterministic terms and regard humans and their
behavior as determined by the environment (Iivari et al., 1998). In terms of methodology,
positivists adopt nomothetic approaches to social science, relying on experimental or
formal mathematical techniques to test and verify hypotheses.
Authors have noted the important contribution that positivist research has played in
information systems research (Orlikowski and Baroudi, 1991; Lee and Hubona, 2009;
Venkatesh et al., 2013). Some authors have applied positivist techniques including
independent and dependent variables, mathematical propositions, quantitative data,
inferential statistics, and experimental controls in order to provide a scientific rigor to their
research (Lee and Hubona, 2009). Authors have used positivist techniques to depict
variables and relationships within technology acceptance models (Davis et al., 1989),
economic models for outsourcing in the banking industry (Ang and Straub, 1998) and to
define e-business value chains (Zhu and Kraemer, 2005). Some authors have argued for
72
mixed qualitative and quantitative methods (Venkatesh et al., 2013) and Lee (1991) argues
that positivist and interpretive approaches can be combined. However, Orlikowski and
Baroudi (1991) argue that positivism and interpretivism are mutually exclusive research
paradigms because of their incompatible ontological positions.
Critics of positivism as a research paradigm for studying the social world focus on the
basic assumptions implied by the positivist paradigm (Guba and Lincoln, 1994).
Orlikowski and Baroudi (1991) question the positivists’ claim for objectivity, universal
laws, the verification and falsification of hypotheses and value-neutrality. The claim to
objectivity is challenged by Morgan and Smircich (1980) who argue that as ‘human beings
we are unable to achieve any form of knowledge that is independent of our subjective
construction’ (p. 493) and that in choosing one theoretical framework over another, we
make fundamental assumptions about ontology and human nature. Second, Guba and
Lincoln (1994) challenge the positivist assumption of a single ‘truth’ that can be arrived at
by collecting facts, suggesting that a set of facts can be explained by different theories.
“No construction is or can be incontrovertibly right [and researchers] must rely on
persuasiveness and utility rather than proof in arguing [their] position” (Guba and
Lincoln, 1994, p. 108).
Guba and Lincoln (1994) argue that not only are facts ‘theory-laden’ but also ‘value-laden’.
Klein and Myers (1999) argue that ‘facts’ are ‘not just sitting there waiting to be gathered’,
but are produced as part and parcel of the social interaction of the researcher with the
participants (p. 74). The values of researchers cannot be separated from the ‘facts’ they
collect and therefore, the claims of objectivity do not hold.
The criticisms of positivism suggest that the paradigm was not appropriate for this
research as I am interested in understanding the challenges of enterprise architecture
implementation (EAI) by viewing it as a social practice involving architects and their
stakeholders. Though the positivist paradigm has been successful in studying and
explaining the natural world, it may not be adequate for understanding the subjective
aspects of social phenomena (Blumer, 1969). A positivist approach to EAI could lead to a
disregard for contextual conditions including the ‘organizational setting, politics and
culture’ (Orlikowski and Baroudi, 1991, p. 12). A positivist approach would also omit the
subjective meanings that people ascribe to an EAI including how architects conceptualize
their role, what meanings they give to their practices, how those roles and practices are
73
interpreted by their stakeholders and how the interactions between architects and their
stakeholders are interpreted. Consequently, a positivist paradigm on EAI was not
considered appropriate.
The critical research paradigm is viewed by some IS scholars as an emerging and
potentially important research paradigm (Myers and Klein, 2011) and is concerned with
social issues such as freedom, power, social control and values in relation to IT
development, use and impact. The critical research paradigm implies the ontological view
that social reality is historically constituted (Orlikowski and Baroudi, 1991) and the ability
of people to change their material and social circumstances is constrained by social,
political, cultural, economic, and gender values (Myers and Klein, 2011). Critical
researchers differ from positivist researchers in fundamental ways. Firstly, whilst positivist
research adheres to a view which denies any fundamental difference between the natural
and the social sciences, critical research emphasizes such difference. Furthermore, whilst a
positivist researcher holds that he/ she can stand outside of the subject of interest looking
in, so to speak, the only way a critical researcher can study people is from the inside
(Myers and Klein, 2011).
Though critical researchers share with interpretive researchers an ontological view that the
social world is created through the interactions between people and is manifest in their
words and actions (Klein and Myers, 1999), they differ in two significant ways. First,
critical researchers look beyond the words of actors and critique the power structures,
vested interests and limited resources that are the conditions of domination and
oppression in the social world. Second, researchers working in the critical paradigm use
their research to highlight oppressive social practices and to give voice to marginalized or
disadvantaged groups (Myers and Klein, 2011; Orlikowski and Baroudi, 1991).
For this research, however, the critical research paradigm was not seen as appropriate. My
research focus is primarily on understanding or gaining insight into the role and practices
of architects. Whilst I am interested in understanding how the roles and practices of
architects influence their social relations with stakeholders, I am not applying a social
critique or looking for structures of domination and oppression. I am interested in
understanding how architects and their stakeholders conceptualize EAI and how the
meanings ascribed to EAI play out in the social relations between architects and their
stakeholders. Consequently, I have no intent of transforming practices of EAI through
the emancipation of the individual or social theory.
74
Interpretivism emphasizes understanding social phenomena through the meanings that
people assign to them (Walsham, 1995). Interpretive researchers attempt to understand
the subjective reality of people in order to make sense of and understand their views and
actions. Researchers who adopt the interpretive research paradigm accept a relativist
ontology which holds that reality is what one makes it and that ‘we need to recognize that
different people may well inhabit different worlds and these worlds represent diverse ways
of knowing, distinguishable sets of meanings and separate realities’ (Crotty, 1998, p. 64).
There are, however, different views on how one ‘makes’ his/her own reality. For example,
one approach termed internal realism, views reality as an inter-subjective construction by
means of shared human cognition (Walsham, 1995). Another approach, idealism, views
people as constructing their own reality (Walsham, 1995) and this reality is confined to
one’s mind (Crotty, 1998).
Epistemologically, under an interpretivist paradigm, the research findings and the values of
the researcher cannot be separated (Guba and Lincoln, 1996; Walsham, 1995). I follow
Crotty (1998) in making a distinction between two epistemological approaches that can be
employed in the interpretive research paradigm - constructionism and subjectivism. While
both suggest that meaning is not ‘out there’ to be discovered, they suggest different
approaches. Constructionism is a belief that research findings are constructed through the
researcher’s engagement with the world. Subjectivism, on the other hand, views meaning
as created by the researcher and imposed on the object of their research. As discussed
previously, my research objective was to gain an understanding of the roles and practices
of architects from the point of view of the architects themselves and their stakeholders.
The two research questions discussed in chapter 3 focused on insights that result from
investigating a group of architects and their stakeholders as individual communities of
practice (CoP). I acknowledge that the theoretical lens taken in this research will shape my
research findings and, in so doing my research affirms the interpretivist view that the
theoretical lens that is used to understand the world influences research findings. Further,
my review of the literature helped construct my worldview of EAI as a social process
involving three broad, but distinct social configurations: architects, business stakeholders
and technology stakeholders. This worldview influenced not only the planning and
operationalization of my research, but also the findings. Therefore, I acknowledge that my
findings are also influenced by my worldview.
75
4.3 Selection of the Research Method
The key challenges in selecting the research method adopted in this study were to firstly,
review the salient features of key qualitative methodologies used in information systems
research highlighting their respective strengths and weaknesses and secondly, use the
characteristics of this study to justify the selection of the preferred research method. At
an organizational level of analysis, three common approaches are action research, case
study, and ethnography. Each method has advantages and disadvantages depending on
the type of research question, the control an investigator has over actual behavioral events
and the focus on contemporary as opposed to historical phenomena (Yin, 2003).
Action research is undertaken with the objective of producing new knowledge through
seeking solutions to ‘real world’ practical problem situations (McKay and Marshall, 2000).
Walsham (2006) refers to the action researcher as the ‘participant-observer’ (p. 321) and a
distinguishing feature of action research is the active and deliberate self-involvement of
the researcher in the context of their investigation. The action researcher is therefore a
key participant in the research process, working collaboratively with other concerned
and/or affected actors to bring about change in the problem context (Checkland, 1991;
Hult and Lennung, 1980). The researcher undertakes problem-solving actions in the
research organization and then examines the outcomes on that organization and on the
researcher themselves (McKay and Marshall, 2000). A limitation of the action research
method is that it usually involves a single organization and this makes it difficult to
generalize findings across other organizations. Action research can also be ‘very time
consuming, has opportunity costs, can be subject to perceptions of bias and the field
researcher may become socialized to views of the people in the field and thereby loses the
fresh outlook on the situation’ (Walsham, 2006, p. 322).
The case study method involves studying one or a small number of organizations in depth
over a period of time. An important advantage of case studies is that the researcher is able
to study a complex phenomenon in a specific context and is able to derive a much more
holistic and rich understanding of the phenomenon in a real-world setting than is possible
with experimental and survey methods. Case study method can be useful for testing
existing hypotheses, challenging current theories and also for generating hypotheses
(Benbasat et al., 1987). Critics of the case study method argue that single case studies can
provide little basis for generalization (Walsham, 2006). Yin suggests that a single case
76
study is appropriate if it is a revelatory case, a critical case or an extreme or unique case
(Yin, 2009). Case studies have a strong tradition in IS, social science, organizational
science and health science research.
Ethnographic research attempts to understand the meaning of a phenomenon of interest
and the meanings that people at a particular site assign to that phenomenon (Cavaye,
1996). In ethnographic research, the researcher adopts a participant-observer role and is
immersed in the ‘life-worlds of the people under study in order to understand the
phenomena of interest in its social and cultural context’ (Tan and Hall, 2007, p. 595).
Rather than interpreting the field data from a theoretical viewpoint or from the
researcher’s point of view, the data is interpreted through the eyes of the participants
(Cavaye, 1996). The advantage of ethnographic research is that it promotes in-depth
understanding of the phenomenon, the people involved, the organization and the broader
organizational context of the phenomenon (Myers, 1999). Whilst ethnography can
produce rich data, the long time frame associated with ethnographic research was not
feasible within the overall time constraint of this study.
4.4 Justification for Using the Case Study Methodology
The challenge of this study is to identify a research methodology that is able to capture the
complexity of the phenomenon under investigation and identify and examine the key
components of that phenomenon. Eisenhardt (1989), Yin (1989) and Markus and Lee
(1999) argue that case study research is an appropriate research approach for investigating
complex phenomena within their actual setting. Benbasat et al., (1987) consider the use of
case study methodology feasible for the following three reasons,
1. It is necessary to study the phenomenon in its natural setting,
2. The researcher is able to ask how and why questions in order to understand
the nature and complexity of the processes taking place, and
3. The research is focused on an area in which few previous studies have been
undertaken (p. 370).
Case studies employ multiple methods of data collection (archives, interviews,
questionnaires, and observations) and gather information from one or more actors
(people, groups, organizations) (Eisenhardt, 1989; Benbasat et al., 1987) to develop a
77
holistic understanding of the phenomenon. Benbasat et al., (1987) and Darke et al., (1998)
argue that case research is particularly appropriate for certain types of problems such as
those in which research and theory are at their early, formative stages and is especially
appropriate for “sticky practice-based problems where the experiences of the actors are important and the
context of the action is critical” (Benbasat et al., 1987, p. 369). Case studies have been used
widely in information systems research for several decades (Carlson et al., 1977; Markus,
1981; Robey, 1983; Franz and Robey, 1984; Hirschheim, 1985; Eaton et al., 2015).
The purpose of employing a case research approach in this study is, to paraphrase Glaser
and Strauss (1967), is to create an intimate connection with empirical reality based on
relevant and valid data. Harris and Sutton (1986) and Gersick (1988) argue that case
studies can be used to generate theory, though Dul and Hak (2008) argue that case studies
are better suited to theory testing than theory building because of the difficulty in
generalizing about findings from a particular case. However, authors such as Yin (2009)
claim that the problem of generalization can be resolved by multiple case studies.
Eisenhardt (1989) argues that case study research is ideally suited to theory building since
the emergent theory will 1) be empirical and closely tied to observable evidence, 2) will be
novel because of the need to constantly reframe the theoretical position in light of
contradictory and paradoxical evidence, and 3) can be tested, measured and proven false.
Notwithstanding the widespread use of case study research in information systems
research and its appropriateness in this study, there can be problems with the method.
Walsham (1995) advises the case study researcher that there are several methodological
issues to be taken care of in interpretive case studies: to make the epistemological stance
clear; to provide a ‘thick description’ of the phenomenon; and to discuss how theory is
used: as an initial guide for data collection, as part of an iterative process of data collection
and analysis, or as a final product of the research. Walsham (1995) recommends that the
role of the researcher in the data collection be made explicit: ‘that of outside observer or
that of involved researcher’ (p. 77). Furthermore, Walsham (1995) recommends providing
details on research sites, site selection criteria, the number of people interviewed, their
positions in the organization, data sources, period of study, and data analysis techniques
(p. 79). These considerations have been ‘designed in’ to my research design. Firstly, I
adopt a constructionist position since as previously discussed my findings are influenced
by my engagement with the literature and worldview. The data for my research includes
interview transcripts, field observations and documentation, which enabled me to view my
78
subject matter from different angles. In the following sections of this chapter, I discuss
the data analysis technique, the site selection criteria and how the CoP and BSBO
theoretical lenses were used as an initial guide for data collection and how these lenses are
re-invoked in the findings of this research. In the case studies of this research, I provide
details on research sites, the number of people interviewed, their positions in the
organization, data sources and the period of study.
4.5 The Case Study Method and Components
Yin (2003) recommends that the following steps in conducting case research be clearly
defined,
• Unit of analysis,
• Multiple case-designs,
• Case selection,
• Data collection, and
• Data analysis.
These are discussed in relation to the current study below.
4.5.1 Understanding ‘The Case’ in This Research
Defining the ‘case’ has important epistemological implications since it defines the
boundaries of the phenomenon of interest and represents the area in which the researcher
‘can draw conclusions about the phenomenon’ (Myers, 2009, p. 74). In defining the
context of the case in this study, I followed the definition offered in Payne and Payne
(2004) that the case is a ‘social unit usually located in a physical place, the people making
up the unit being differentiated from others who are not part of it. In short, the unit has
clear boundaries which make it easy to identify’ (p. 31). Stake (2000) argues that not
everything is a case and that in the social sciences, a case is a bounded social system,
The case has working parts; it is purposive … It is an integrated system (p. 436).
The aim of this study is not only to understand the roles and practices of architects and
the meanings that they ascribe to EAI, but also to understand the perspectives of the
79
business and technology staff involved in the EAI as well as the nature of their
interactions with the architects. Following Payne and Payne (2004), the ‘case’ in this study
is the integrated social system associated with the EAI – the architects, business and
technology staff (see Figure 4.2).
Figure 4.2 Identifying the ‘case’
4.5.2 The Unit of Analysis
By adopting a CoP perspective in this research, a deliberate design decision was taken to
conduct empirical work with groups of architects and the business and technology staff
they interact with rather than to study individual architects. Therefore, the unit of analysis
is a group of architects and its practices. The data collection involved eliciting perceptions
about the roles and practices of architects from individuals who were either part of the
group of architects or were business and technology staff who interacted with the
architects.
80
4.5.3 Multiple Case Study Design
Case studies can be categorized in to three types: intrinsic, instrumental, and/or a multiple
case study (Stake, 2008). An intrinsic case study is one in which the researcher is interested
in some specific aspects of a particular case: in other words, the case itself is of intrinsic
interest, and there is little interest in learning about some general phenomena. An
instrumental case study is one in which the researcher is interested in understanding the
case to learn something about some general phenomena and therefore the case is
‘instrumental’ in bringing about that learning. A multiple case study is an instrumental
case study, in which more than one case is selected by the researcher in order to allow for
a multifaceted understanding of a phenomenon of interest (Liamputtong, 2009, p. 193).
In this research, I have taken a design decision to have a multiple case study design to
pursue my instrumental interest in understanding the EAI roles and practices of architects.
Two cases have been selected from different organizations to allow for an understanding
of the EAI roles and practices of architects in different organizational contexts. The
practice perspective adopted in this research focuses on the social context of and
meanings ascribed to practice and therefore, I was interested in understanding the EAI
practices of architects in different organizations and the meanings and interpretations
applied to those practices in their different organizational contexts. Recognizing the
contextual nature of practice, a multiple-case design was adopted to investigate practices in
multiple organizations.
4.5.4 Case Selection
The selection of cases for in-depth study requires considerable care and my selection is
based upon theoretical and pragmatic considerations. From a theoretical perspective, EA
research in general focuses on the technical aspects of an EA initiative including
documentation outputs, methodologies, problem analysis and planning tools (Ross et al.,
2006; Kappelman, 2010). Whilst these technical approaches have made a valuable
contribution to EA practice, transitioning from the development of the EA plans to the
implementation of those plans continues to be a problem for organizations. Given the
continued failure of EAI initiatives, it is of particular interest to see if other approaches
based on an interpretivist lens and an in-depth and extended study of the relations
between architects and their stakeholders can offer new insights into the nature of the
81
problems associated with EAI.
The selection of the banking industry was made on practical grounds. In general, banks
have a high level of experience with EA (Schmidt and Buxman, 2011) and in a recent
study of European, North American and Australian banks, a large number participants
considered EA important (Schmidt and Buxman, 2011). Though there is limited research
on the problems of EAI and research specifically focused on the problems of EAI in the
banking industry is even more limited, my professional experience in the banking industry
over twenty years indicates that the progression from the development of the EA plans to
the implementation of those plans is problematic.
To eliminate inter-industry variation and to achieve a high degree of homogeneity with
respect to other contextual factors, the research was restricted to Australian banks. To
progress my research, I sought to identify executives leading the EA function in two banks
and contacted those people. These people were supportive of the research and arranged
contact names and email addresses for architects and stakeholders that could participate in
this research. As the research progressed, I was able to identify additional participants and
the Heads of both EA functions provided introductions and the contact details of those
participants.
4.6 Data Collection Methods
Case study research could involve gathering evidence from a variety of sources including
documentation, archival records, questionnaires, structured and semi-structured
interviews, observations and physical artifacts (Eisenhardt, 1989; Yin, 2003). Charmaz
(2006) argues that data collection methods should ‘advance emerging ideas’ (p. 16) and this
study employs a combination of data collection methods discussed below.
4.6.1 Semi-Structured Interviews
The primary data collection method used in this study is semi-structured interviews, as
these can lead to unexpected and insightful information about the ‘complex behavior of a
social group without limiting the field of inquiry’ (Fontana and Frey, 2000, p. 653). A
purposeful sampling strategy (Patton, 2002) informed the selection of interviewees from
the case study organizations. Within each organization, interview candidates were selected
82
from four managerial levels: highest level organizational executives, executive managers,
senior managers and non-managerial employees who had experience of the EAI. A total
of twenty-five interviews were conducted for the study (see within-case analyses for both
organizations for a list of interviewees) and each interview typically lasted between forty-
five minutes and one hour.
Substantial effort was made to ensure that the interviewee sample adequately represented
the different types of stakeholders involved in the EAI in each case organization. This
was important to ensure a balanced and accurate representation of the perspectives of the
different types of stakeholders from different levels and areas of both organizations that
are impacted by the EAI. Despite the researcher’s best efforts it was not possible to
interview more of the highest-level executives in Bank2 due to competing business
priorities and travel.
Interview questions were informed by my research questions and by a long-standing
academic and professional interest in the problems of EAI and concern with traditional
rationalist approaches. Interview questions were also informed by the careful reading of
qualitative information systems research and sought to capture the experiences of
interview participants and the meanings they ascribe to EAI. The interview questions
aimed to understand the roles and practices of architects from the perspective of the
architects themselves as well as the business and technology staff directly involved in the
EAI. These are included in Appendix Section 11.1 Case Study Interview Guide.
4.6.2 Development of the Interview Protocol
Yin (2001) suggests that interview protocol is a “mental framework” that helps guide the
conversation (p. 139). Kvale and Brinkmann (2009) suggest that in case study research
which focuses on a particular institution and / or situation, the interview protocol can be
used to “chart” the main aspects of the phenomenon of interest and merely contain the
areas of interest to be covered (p. 117). In this research, I adopted the ‘open’ protocol
model suggested by Yin (2009) and Kvale and Brinkmann (2009). In developing the
interview protocol, I started by considering two important concerns: 1) the EAI areas that
were relevant to my research aim and 2) the different organisational areas and levels that
the interview participants belonged to and their likely different EAI experiences. My
research aim to understand the EAI practices of architects led me to focus on areas such
83
the history of EAI in the organization, the motivation for implementing the EA, the
selection of the EAI framework, methods and tools, the work practices of the architects,
and the nature of EAI work in the architecture team. My interest in capturing the
different experiences of the interview participants meant led me to keep the interview
‘open’ and not stick strictly to scripted questions. This allowed me to follow up on the
interviewee’s answers and promote a positive interaction that kept the flow of
conversation going. Consistent with Yin (2011), the interview protocol served as a
conversational guide.
4.6.3 Direct Observation
As a data collection method, direct observation has several advantages: the researcher is
able to ‘understand and capture the context within which people interact’ and the
researcher has the ‘opportunity to see things that may escape the awareness of people in
their social setting’ (Patton, 2002, p. 262). I took a non-participant observer role in team
meetings and as recommended by Orlikowski and Baroudi, (1991), I noted the architects’
observations in their own words wherever possible, quoting them in order to better
understand their thoughts, emotions and impressions about the nature of an EAI and their
relationship with their business and technology staff. I also observed the architects as they
went about their work. I made field notes of architecture team meetings and my
experiences of the architects as they went about their work and used these to validate my
data analysis. Following the recommendation of Walsham (2006), I also wrote down
impressions and ideas that emerged from the interviews and used these inform my analysis
of the interview data. Based on Levina and Vaast (2005), field notes were also used as
primary sources in the data analysis.
4.6.4 Document Analysis
In organizational fieldwork, documents can provide important information about things
that cannot be observed, including those things that took place before the field research
began (Patton, 2002). For this study, documents from the architects provided valuable
information about the EA approach and the nature of the EAI. For both organizations,
the researcher was asked to sign a Non-Disclosure Agreement that allowed him to only
use materials for research purposes and not remove materials from the premises of both
84
organizations due to their commercially sensitive nature. Documents that were analyzed
included PowerPoint presentations, team charters, policy statements and specialized
architectural documentation of hardware, application and data components. Notes were
recorded into a field notebook.
As with the field notes from direct observation, documentation analysis was used during
the memo writing to check the validity of the emergent theoretical categories.
4.7 Data Analysis Strategy
In this section, I discuss issues that were fundamental to the selection of the data analysis
strategy and elaborate the data analysis strategy followed in this research.
4.7.1 Data Analysis Strategy
In determining the data analysis strategy of this research three factors were critical: the use
of theory in interpretive research (Klein and Myers, 1999; Walsham, 1995), instrumental
research interest (Stake, 1995) and a desire to not be constrained by a priori assumptions
about my area of interest (See Figure 4.3).
85
Figure 4.3 Data analysis strategy
Interpretive research focuses on the complexity of human sense making and attempts to
understand phenomena through the meanings that people assign to them (Boland, 1985,
1991; Deetz, 1996; Orlikowski and Baroudi, 1991). Theory plays an important sensitizing
role in interpretive research. Klein and Myers (1999) state,
The key point here is that theory plays a crucial role in interpretive research, and
clearly distinguishes it from just anecdotes. However, theory is used in a different
way than is common in positivist research; interpretive researchers are not so
interested in “falsifying” theories as in using theory more as a “sensitizing device” to
view the world in a certain way (p.75).
Walsham (1995) argues that interpretive studies can use theoretical concepts without being
constrained by them.
86
The motivation for the use of theory in the earlier stages of interpretive cases
studies is to create an initial theoretical framework which takes account of previous
knowledge, and which creates a sensible theoretical basis to inform the topics and
approach of the early empirical work … It is desirable in interpretive studies to
preserve a considerable degree of openness to the field data, and a willingness
to modify initial assumptions and theories. This results in an iterative process
of data collection and analysis, with initial theories being expanded, revised,
or abandoned altogether. A simple metaphor for this latter case is the use of
scaffolding in putting up a building, where the scaffolding is removed once it
has served its purpose (p. 76).
Orlikowski and Baroudi (1991) highlight that interpretive research focuses on themes and
categories which emerge from the researcher’s exposure to the phenomena, but which also
reflect the experience of the research participants.
Instead of the researcher coming to the field with a well-defined set of constructs and
instruments with which to measure the social reality, the interpretive researcher
attempts to derive his or her constructs from the field by in-depth examination of and
exposure to the phenomenon of interest. The categories and themes that emerge out of
this approach are intended to closely couple those relevant to the study's participants
(p. 14).
Although the concepts of CoP and boundary practice were used to frame the research
perspective and inform the empirical work, during the initial data analysis I attempted to
remain open to field data and tried not to be constrained by the theoretical concepts.
Therefore, I attempted to avoid using any predefined theoretical codes in my data analysis
strategy. However, as implied by Walsham (1995), I was inevitably sensitized to various
notions and concepts due to my acquaintance with the CoP and boundary practice
perspectives and literature. Thus, the CoP and boundary practice perspectives somewhat
influenced assigning codes to data, constructing categories from the codes, and merging
categories into themes. Once I completed the initial categorization of the data and
articulated my initial findings, I then explicitly revisited the theoretical concepts to account
for any ‘theoretical grounding’ of the codes and categories (Goldkuhl and Cronholm,
2003).
87
Stake’s (1995) suggestion that the data analysis strategy should follow the researcher’s
interest in the case was also influential. For intrinsic case studies in which the research
interest lies in the particular case, direct interpretation of data (interpretation without
creating categories by abstraction) is recommended. Efforts at categorizing data would
take the focus away from details of the case. However, this research is an instrumental
case study where more than one case was chosen to enable multi-faceted insights into the
EAI roles and practices of architects. For research that has an instrumental interest in a
case, abstraction by categorization is argued to be an appropriate strategy (Stake, 1995) and
this is the approach adopted in this research.
In formulating the data analysis strategy, I was sensitive to how my professional industry
experience positioned me in relation to my research and the potential for a priori
assumptions based on my professional experience to bias my interpretation of the data.
As Glaser and Strauss (1967) argue, the researcher does not approach reality as a tabula rasa
(blank slate). The danger according to Glaser (1992) is that researchers with a priori
experiential and theoretical knowledge are at risk of consciously or unconsciously applying
existing theoretical schemes to their data. Glaser and Strauss (1967) say that the researcher
can be guided by a comprehension of existing theories and that this may help the
researcher ‘see relevant data and abstract significant categories from his/ her scrutiny of
the data’ (p. 3). Although my previous experience of working as an architect in the
banking and consulting industries influenced my choice of research perspective and
empirical tasks, I wished to remain open to the field data and not be constrained by
existing theoretical knowledge or experiences. Strauss and Corbin (1990) identified a
number of mechanisms for developing a reflexive approach to the data and enhancing
theoretical sensitivity including the use of questioning, looking at language, thinking in
terms of metaphors and similes and asking ‘so what’ and ‘what if’ (p. 69). Birks and Mills
(2011) suggest that immersion in the data will help sensitize the researcher to those
elements of the data that have ‘meaning, relevance and consequence’ for developing
theory. In addition, the practice of memo development helps to ‘explicate assumptions
and challenge theoretical leanings’ (p.63).
In order to remain open to the field data and leverage, but not be constrained by a priori
learning and experience, the data analysis strategy used in this research is grounded theory.
In particular, I have adopted the coding and categorization techniques discussed in
Charmaz (2006). My purpose is to see the world as architects and their stakeholders do -
88
“from the inside” (Charmaz, 2006, p. 14). Nevertheless, it is acknowledged that a grounded
theory analysis of the roles and practices of architects involved in an EAI offers an
interpretive portrayal of the studied phenomena and is not an exact picture of it (Charmaz,
2006, 10).
The data analysis occurs in two phases. Firstly, I undertake a within-case analysis of each
of the two cases. In the second phase, I will undertake a cross-case analysis by considering
the findings across both cases (Creswell 2007, cited in Liamputtong, 2009). These are
discussed in detail in the next section.
4.7.2 Data Analysis Approach - Within-Case Analysis
The within-case analysis process is illustrated in the following diagram (See Figure 4.4).
Figure 4.4 Approach for within-case data analysis (based on Charmaz, 2006)
89
4.7.2.1 Initial Coding
Line-by-line coding of the interview transcripts involved moving through each line of data
and assigning a code that summarized and accounted for a piece of data. The codes were
established on the basis of my interpretation of participants’ words and actions (Charmaz,
2006, p. 49) and I followed suggestions to use gerunds as far as possible for the initial
codes. Table 4.1 is an example of how the initial codes were assigned. Birks and Mills
(2011) argue that initial coding is a reflexive approach that assists the researcher to avoid
subconsciously applying personal theories (Baily and Jackson, 2003; Charmaz, 2006). In
working and re-working through the initial coding of the interview transcripts, the codes
assigned to a particular line of text were updated as new insights were revealed
.
90
Table 4.1 An example of using initial coding during with-in case data analysis
4.7.2.2 Focused Coding
The next phase following on from initial coding, focused coding involves re-examining the
transcripts with the initial codes to determine which initial codes most logically explained
larger segments of data. According to Charmaz (2006) in focused coding,
91
One goal is to determine the adequacy of those codes. Focused coding requires decisions about
which initial codes make the most analytic sense to categorize your data incisively and completely
(pp. 57-58).
For example, as indicated in Table 4.2, from the ten initial codes (See Table 4.1), three
codes were selected as focused codes as each of these three codes was considered to
explain a larger segment of data.
The focused codes generated from the first case were available to be used for focused
coding in the second case. New focused codes were developed as required. Please see
Appendix Section 11.2 Lists of Focused Codes for a list of focused codes from both cases.
92
Table 4.2 An example of using focused codes during with-in case data analysis
4.7.2.3 Clustering and Memo Writing – Raising Focused Codes to
Theoretical Categories
My next step was to reflect on the data analysis progress, in particular questioning my data
and coding. Following Charmaz’s (2006) guidelines for raising focused codes to
93
theoretical categories, the possibility of each focused code being a category was
considered. Each focused code was evaluated for its capacity to go beyond a description
of the data and encapsulate an abstract understanding of the meanings and social
processes apparent in the categories and sub-categories created. In general, focused codes
were combined in order to determine if one focused code could become the category
while the other focused codes became its data set. The method I used to determine which
focused codes were raised to theoretical categories was clustering (Charmaz, 2006). The
following steps illustrate how this was achieved.
Step 1. The focused codes were organized into diagrammatic clusters by placing together
focus codes that appeared to be similar or closely related and which occurred frequently.
The clustering of focused codes served four purposes. First, it made it easier to initiate the
process of evaluating and comparing focused codes in order to recognize emergent
theoretical categories. Secondly, the configuration of clusters provides an image of how
each theoretical category connects and relates to other phenomena. Thirdly, the
convergence of relations around other nuclei within a cluster diagram suggested a new
cluster. Fourthly, each cluster provided a preliminary sketch for the memo to be written.
Considering the large number of focused codes and associated data sets, the structuring
and sorting achieved through clustering was highly beneficial. The following diagram 4.5
illustrates the clustering approach.
94
Figure 4.5 Clustering example, ‘Remaking the organization’
Step 2. For each focused code that was raised to a theoretical category, memos were
written (Charmaz, 2006). Charmaz (2006) suggests the following guidelines for memo
writing,
First, assess which codes best represent what you see happening in your data. In a
memo, raise them to conceptual categories for your developing analytic framework-
give them conceptual definition and analytic treatment in narrative form in your
memo. Thus, you go beyond using a code as a descriptive tool to view and synthesize
data (p. 91).
These memos consisted of narrative statements that defined the theoretical category in
95
terms of its properties, the conditions and also the context in which the theoretical
category arises, is maintained, changes, its consequences and its relationships with other
categories (Charmaz, 2006; Vashist, 2013). Following Vashist (2013), for each memo I also
identified questions that could be considered in future data collection.
Table 4.3 is an example of how each theoretical category was summarized in memos. The
category – Being remote was constructed from related focused codes and field notes.
Category: Being Remote
Focused Codes Setting themselves apart; Separating themselves from the rest of the organization; Being disconnected; Feeling alienated from the architects; Closing ranks; Not providing guidance; Not getting adequate support from the architects; Missing deadlines; Being seen as arrogant; Not knowing what the architects do.
Corroborating Secondary Sources
Observation
• The architects are physically located on another floor of the building to technology staff.
• Communication with architects is mediated via a wiki and ad hoc communication with the architects is discouraged.
• The architect’s desks are arranged in clusters and face inwards making it difficult to get the attention of individual architects. If someone is to approach an architect, they literally have to tap them on the shoulder to get their attention.
Field Note
• T4 said that he once went to speak with an architect and was told to leave the area where the architects are.
Characteristics These views are being expressed from business and technology staff who have a dependence on the architects for information about the selected technology components and implementation plans. In the context of this theoretical category, business and technology staff are evaluating how approachable and accessible the architects are in relation to:
• Getting information about the selected technology components and implementation plans,
• Getting architectural guidance for individual technology projects, and
• Understanding which technology components in the organizational technology portfolio will be retained and which will be replaced.
96
Conditions in which the category arises, is maintained or changes
This view of the architects is influenced by:
• The perceived heavy handed approach taken by the architects to project governance,
• The urgency to resolve operational technology problems, and
• The difficulty technology staff have in communicating with the architects.
Consequences Relations between the architects and technology staff are problematic. Some senior technology staff distrust the architects to deliver the appropriate technology components necessary to support the new organizational strategy.
This has potential consequences for the delivery of the EA as technology staff may fail to build support amongst senior technology staff for the technology components specified by the architects.
There are also potential consequences for the appropriateness and fit of the technology components specified by the architects. If the architects are not engaging with technology staff about the constraints of the technology portfolio, they may not select appropriate technology components or an appropriate implementation approach.
Emerging questions that are relevant to the category
How does the perception that the architects set themselves apart from the technology staff affect relations between the architects and technology staff?
How might the relationship between the architects and technology staff adversely affect the successful completion of the EAI?
Related categories
Not Liaising, Behaving as an Elite.
Table 4.3 An example of a memo
4.7.2.4 Developing Theoretical Categories
In my analysis of case 1, I constructed forty-seven theoretical categories. Table 4.4 gives
the list of the categories that were raised from the focused codes by writing memos and
clustering. These categories were used where appropriate for the second case, which
allowed for effective cross-case analysis. These categories were organized under four
themes as a way of organizing the results from the within-case analysis (see Table 4.5).
97
Theoretical Categories from Case 1
1. Selecting the new systems and defining the implementation plans
2. Focusing on strategic projects
3. Aligning architecture to the strategy
4. Focusing on architectural goals
5. Distrusting business and technology staff
6. Expecting conflict with business and technology staff
7. Wanting management control over the implementation plans
8. Stopping projects
9. Defending the EAI plans
10. Not discussing the execution of the implementation plans
11. Coordinating the different EAI plans
12. Complying with the team charter
13. Promoting shared understanding within the team
14. Practices that contribute to learning within the team
15. Nature of work - engaging / dis-engaging
16. Perspectives on EAI methodology and tools
17. Remaking the organization
18. Aligning to the Strategy
19. Enabling the business strategy
20. Building support for the EAI
21. Defining the technology strategy
22. Delivering a technology strategy
23. Considering outsourcing arrangements
24. Promoting agility
25. Remaking the organization
26. Addressing problems with the technology portfolio
27. Understanding the impact of the EAI on people
28. Engaging on an as-needs basis
29. Accommodating changing requirements
30. Being practical
31. Building relationships
32. Communicating
33. Being in an Ivory Tower
34. Wanting to control the business and technology
98
35. Not sharing the EAI plans
36. Not being participative
37. Not understanding the culture
38. Not communicating
39. Not engaging
40. Not understanding the commercial reality
41. Expecting people to agree with their technology choices
42. Lacking sufficient detail in the EAI plans
43. Using governance to stop technology projects
44. Not implementing the EA successfully
45. Behaving as an elite
46. Not focusing on practical outcomes
47. Selecting inappropriate software
Table 4.4 List of theoretical categories developed from focused codes
4.7.2.5 Developing Themes
The resultant forty-seven theoretical codes represented an unworkable number of
theoretical positions from which to begin the within-case analysis. According to Glaser
(1992), the goal of grounded theory is to generate theory that accounts for patterns of
social behavior. Following this principle, I adopted the practice recommended by
Goulding (2002) of linking theoretical codes to emerging themes to provide a more
complex and richer explanation of the social processes associated with EAI. This
additional process of abstraction and generalization is consistent with the “scaling up”
approach adopted by Urquhart et al. (2010, p. 372) and is in keeping with the
philosophical basis of interpretive field research as defined by Klein and Myers (1999),
Therefore, intrinsic to interpretive research is the attempt to relate particulars as may be
described under the principle of contextualization to very abstract categories; unique instances
can be related to ideas and concepts that apply to multiple situations (p. 75).
The development of the themes was informed by the research objectives of this study.
Firstly, I aim to develop an understanding of the roles and practices of the architects both
from the architect’s perspective and also from business and technology staff’s
99
perspectives. Secondly, I aim to investigate the social nature of EAI by investigating the
interactions between architects and business and technology staff.
From these research objectives, I have derived the following four themes.
Theme 1. Framing EAI work – architect’s perspective
This theme has an inward looking focus and is concerned with understanding the nature
of what it is architects do during an EAI from a within-group perspective. In order to
achieve this understanding, I organized the theoretical categories derived from the
architect interviews and transcripts of the architecture team meetings according to their
inward looking team focus.
Theme 2. Practice work in the architecture team
Whereas the first theme focused on the essence of what it is architects do from the
architect’s perspective, this theme discusses what the architects actually do in the course of
an EAI. This theme discusses interactions within the architecture team, relations amongst
the architects and their perspectives on methods and tools.
Theme 3. Framing EAI work – business and technology staff’s perspective
To balance the perspective offered in theme 1, understanding business and technology
staff’s perceptions of what it is architects do is the focus of the next theme. Theoretical
categories were arranged according to an outside-looking-in perspective. For this theme,
theoretical categories that made explicit the perceptions of business and technology staff
were selected.
Theme 4. Interaction with business and technology staff
In this theme, I compare and contrast the architect’s understanding of their EAI role and
practices with the views of business and technology staff, which leads to interesting
insights into the nature of the interaction between the architects, business and technology
staff. The following table (Table 4.5) maps the emphasis of the theoretical categories for
the two cases.
100
Theme Theoretical Category Case 1 Case 2
Framing EAI work –architect’s perspective
Selecting the new systems and defining the implementation plans
✓ ✓
Focusing on strategic projects ✓
Aligning architecture to the strategy
✓
Focusing on architectural goals ✓
Distrusting business and technology staff
✓
Expecting conflict with business and technology staff
✓
Wanting management control over the implementation plans
✓
Stopping projects ✓
Defending the EAI plans ✓
Not discussing the execution of the implementation plans
✓
Coordinating the different EAI plans
✓
Building relationships ✓
Communicating ✓
Speaking in two languages ✓
Being flexible ✓
Sharing tools and knowledge with business and technology staff
✓
Taking a flexible approach ✓
Interacting with business and technology staff
✓
Successfully completing the EAI ✓
101
Facilitating organizational change ✓
Being constructive ✓
Helping the business ✓
Collaborating with technology staff
✓
Influencing stakeholders ✓
Acting as a business analyst ✓
Being trusted advisors ✓
Practice Work in the Architecture Team
Complying with the team charter ✓
Promoting shared understanding within the team
✓ ✓
Practices that contribute to learning within the team
✓ ✓
Nature of work – engaging / dis-engaging
✓ ✓
Perspectives on EAI methodology and tools
✓ ✓
Complying with the team’s practices
✓
Framing EAI work – business and technology staff’s perspective
Remaking the organization
✓
Aligning to the Strategy ✓
Enabling the business strategy
✓ ✓
Building support for the EAI
✓ ✓
Defining the technology strategy ✓ ✓
Delivering a technology strategy
✓ ✓
Considering outsourcing arrangements
✓
Promoting agility ✓ ✓
Remaking the organization ✓
102
Addressing problems with the technology portfolio
✓
Understanding the impact of the EAI on people
✓
Engaging on an as-needs basis ✓ ✓
Accommodating changing requirements
✓
Being practical ✓ ✓
Building relationships ✓ ✓
Communicating ✓ ✓
Dealing collaboratively with business and technology staff
✓
Liaising and negotiating ✓
Having a business focus ✓
Dealing with rogue projects ✓
Providing governance ✓
Getting funding for the EAI ✓
Competing with vendors ✓
Modernizing the organization ✓
Promoting good architectural practices
✓
Interaction with business and technology staff
Being in an Ivory Tower ✓
Wanting to control the business and technology
✓
Not sharing the EAI plans ✓
Not being participative ✓
Not understanding the culture ✓
Not communicating ✓
Not engaging ✓
Building an ideal architecture ✓
103
Not understanding the commercial reality
✓
Expecting people to agree with their technology choices
✓
Lacking sufficient detail in the EAI plans
✓
Using governance to stop technology projects
✓
Not implementing the EA successfully
✓
Behaving as an elite ✓
Not focusing on practical outcomes
✓
Selecting inappropriate software ✓
Dealing collaboratively with business and technology staff
✓
Liaising and negotiating ✓
Communicating ✓
Building common tools ✓
Sharing the EAI plans ✓
Being inclusive ✓
Willing to change the EAI plans ✓
Appreciating the commercial reality
✓
Successfully delivering the EAI plans
✓
Getting commitment to fund the technology components
✓
Table 4.5 Mapping the emphasis of theoretical categories in the two cases
104
4.7.1 Data Analysis – Cross-case Analysis
The objective of my cross-case analysis is not to simply make a judgmental comparison of
the architect’s practices in both cases. Rather, my intention is to seek out significant
patterns and insights relevant to the social processes associated with EAI and which can
explain the factors that influence the ability of the architect’s to establish and maintain
connections with their stakeholders.
The four themes (Framing EAI work – architect’s perspective, Practice work in the architecture team,
Framing EAI work – business and technology staff’s perspective and Interaction with business and
technology staff) served as the starting point for reflecting on the similarities and differences
across both cases. During the analysis of the second case, notes were taken to record any
new insights and areas that might reveal new patterns and insights between the cases. This
allowed me to refine my list of theoretical categories and to re-evaluate if initially identified
themes were relevant to a particular case.
4.8 Strategy for Writing the Results
This section outlines the approach for writing up the results of the within-case analysis for
each case and the cross-case analysis.
4.8.1 Writing up the Cases
The structure of the within-case analysis is as follows and incorporates suggestions from
Eisenhardt and Graebner (2007), Stake (2005) and Yin (2009) regarding descriptive case
data.
Background to the case – According to Eisenhardt and Graebner (2007), case studies
emphasize the real world context of the phenomenon under study. Stake (2005) argues
that a ‘case is a complex entity located in its own situation’ (p. 12) and that a situation can
be interpreted from a number of perspectives including organization structure, people and
occasions and many others. This section therefore discusses some of the key contextual
information related to the organization such as the nature of its operations, products and
services and locates the case and agents in relation to the organization structure.
Information about the research participants – Individuals from each case organization
105
who participated in the interviews are recorded in the with-in case analyses (See
Information about Research Participants tables in the Within-Case Analysis). The
information provided about research participants is intended to validate their knowledge
of the EAI and assure the reader that they can add important insights. The anonymity of
research participants is preserved at all times during the within-case and cross-case
analyses.
Discussion of results - The results from the within-case analysis are structured according
to the four themes:
• Framing EAI work - architect’s perspective,
• Practice work in the architecture team,
• Framing EAI work - business and technology staff’s perspective, and
• Interaction with business and technology staff.
To answer the first research question (What insights into the relationship between the EAI
practices of architects and the outcomes of EAI initiatives are possible using the theoretical lenses of CoP
and BSBO theory?), I separated out the theoretical categories according to the first two
themes: Framing EAI work – architect’s perspective and Practice work in the architecture team (See
Figure 4.6). Here, I am concerned with 1) understanding how architects conceptualize
their EAI role and 2) the EAI practices of architects.
106
Figure 4.6 Organization of theoretical categories for research question 1
To answer the second research question (What is the nature of the connections that enterprise
architects need to make with relevant CoPs?), I organized the theoretical categories according to
the themes: Framing EAI work – business and technology staff’s perspective and Interaction with
business and technology staff (See Figure 4.7).
107
Figure 4.7 Organization of theoretical categories for research question 2
4.8.2 Writing up the Cross-Case Analysis
In chapter seven, the results of the cross-case analysis are discussed. The cross-case
analysis was guided by the four themes used to write up each within-case analysis:
• Framing EAI work – architect’s perspective,
• Practice work in the architecture team,
• Framing EAI work – business and technology staff’s perspective, and
• Interaction with business and technology staff.
4.9 Quality of Interpretive Research
As interpretive research, this study does not claim objectivity; rather the emergent theory
is one of multiple possible explanations from the empirical evidence (Eisenhardt and
Graebner, 2007). That is not to say that all interpretive research is trustworthy or credible
and it is the responsibility of the researcher to present research that is transparent,
108
methodical and based on explicit evidence (Lincoln and Guba, 1989).
Lincoln and Guba (1985) explain that because interpretive research is based on a different
set of ontological and epistemological assumptions than traditional positivist research, the
traditional notions of validity and reliability do not apply in the same way. They propose
an alternative set of criteria by which to judge the rigor of qualitative research: credibility,
transferability, dependability, and confirmability. Guba and Lincoln (1985) originally
identified techniques that researchers could apply to help meet the criterion and over time
scholars working in the field of IS (incl. McKay and Marshall, 2000; Shenton, 2004) have
added their own suggestions (see Table 4.6).
109
Traditional criteria
Trustworthiness
criteria
Possible methods for meeting trustworthiness criteria
Internal validity
Credibility Extended engagement in the field
Adoption of recognised research methods
Triangulation via different methods, different types of informants and different sites
Tactics to ensure honesty in informants
Peer de-briefing, debriefing sessions between researcher and supervisors
Use of reflective commentary
Member checks of data collected and interpretations/ theories formed
Thick description of the phenomena under study
Examination of previous research to frame findings
External validity
Transferability Provision of background data to establish context of study and detailed description of phenomenon under study to allow comparisons to be made
Triangulation of data types
Reliability Dependability In-depth methodological description to allow study to be repeated
Purposive and theoretical sampling
Informants’ confidentiality protected
Inquiry audit of data collection, management, and analysis processes
Objectivity Confirmability Triangulation to reduce effect of investigator bias
110
Admission of researcher’s beliefs and assumptions
Recognition of shortcomings in study’s methods and their potential effects
In-depth methodological description to allow integrity of research results to be scrutinised
Use of diagrams to demonstrate “audit trail”
Meticulous data management and recording:
• Verbatim transcription of interviews
• Careful notes of observations
• Clear notes on theoretical and methodological decisions
• Accurate records of contacts and interviews
Table 4.6 Techniques to ensure trustworthiness of qualitative research (Based on McKay and Marshall, 2000; Shenton, 2004)
111
4.9.1 Credibility
Credibility deals with the congruence between the research findings and the reality of the
research setting and seeks to give confidence in the ‘truth’ of the research findings
(Lincoln and Guba, 1985). Credible research ‘has an analytic generalizability’ which is
achieved through a clear presentation of the data and also a thick description of the social
context within which the data is collected and analyzed’ (Locke, 2003, p. 60). To ensure
credibility in this research, efforts have been made to discuss the case settings for the two
case studies and provide information about the research participants. As well, the
theoretical perspectives informing the research have been discussed as has my data analysis
strategy including the coding technique. The purpose of my coding technique is to
understand an enterprise architecture implementation from the perspective of those living
it, in their daily practice and the derived codes are accordingly designed to faithfully
represent the participants’ responses. As Sandelowski (1989) explains,
Credible research is research that presents such faithful descriptions or interpretations
of a human experience that the people having that experience would immediately
recognize it from those descriptions or interpretations as their own (p.30).
Confidence in the analytic generalizability of results can also be achieved through
triangulation (Trauth and Jessup, 2000). Triangulation using different data sources
including transcribed interview recordings, documentation analysis and field observations
was used to verify the interactions and relationships between the architects and their
stakeholders. Consistent with Walsham and Sahay (1999) confidence in my data analysis is
also achieved through practices I adopted, especially in the early stages of my data analysis.
I made formally typed transcriptions of recorded interviews, I carefully read and reflected
on field notes and the development grounded theory codes was based on open discussions
with my supervisors.
4.9.2 Transferability
The transferability of research means that others can decide whether the outcomes of a
research project apply to other settings, populations, and interventions and thus, “the onus
112
of transferability rests more with the transferor, rather than with the original researcher” (McKay and
Marshall, 2000, p. 3). In undertaking a multiple case study, the intention was to have a
multi-faceted understanding of the practices of architects. I acknowledge that practices
are situated in contexts and likely to differ and this limits the transferability of findings
from one case to another. Others may use my interpretations to understand other
settings. Following Klein and Myer’s (1999) principle of contextualization, I have provided
as much detail as possible about the settings and individuals so that others can make
decisions about the applicability of findings in other contexts. McKay and Marshall (2000)
argue that a rich description of the research setting, process and outcomes will aid the
transferability of findings. They suggest that triangulation using multiple cases, multiple
participants and/or multiple data collection techniques are all likely to increase the
transferability of research findings (McKay and Marshall, 2000). This study includes
various data sources including interview transcripts, transcripts of team meetings, field
observations, architectural artifacts and other EAI related documentation. The
transcriptions of interviews, team meetings and field notes were used in the data analysis
and this increased the richness of the descriptions of the research setting.
4.9.3 Dependability
Dependability relies on a transparent process, one that is established, traceable and
documentable (McKay and Marshall, 2000). For dependability, the research design has
been discussed in detail to ensure transparency of the process followed in this research.
The research process and many of the resulting findings have also been presented to
disinterested reviewers in the IS community. My research interest was served best by a
single theoretical perspective to inform the research, but I was open to other theories and
concepts to supplement my theoretical lens. As my research questions are not concerned
with ‘measuring’, my data collection was focused on generating qualitative data. Although
one researcher undertook the data analysis it was open to questioning by reviewers,
supervisors, and other researchers. Further, an effort was also made to establish and
maintain a chain of evidence, which would allow an external observer to follow the
derivation of case study findings, the coding cycles of grounded theory analysis, the
interview data and initial research questions. This involved a numbering system based on
the initial interview protocol and carried through in the analysis of the interview and
meeting transcripts.
113
4.9.4 Confirmability
The final construct for determining rigor, confirmability requires that research data can be
traced back to their source, and judgments and assertions made about that data are logical,
coherent, and are able to be confirmed by an expert other than the researcher (Guba and
Lincoln, 1989). The concern is that the researcher’s bias and subjectivity is removed from
the research interpretations and findings and that the findings from the research can be
demonstrated to grow out of the data, not from within the researcher. In this research, a
number of strategies were employed to ensure consistency in data collection and analysis.
Firstly, the case study protocol was used to guide the research process. The protocol is a
key tool in increasing the reliability of case study research and is intended to guide the
investigator in carrying out the case study. The protocol included the instrument (i.e. the
interview questions), as well as procedures and general rules that should be followed in
using the protocol. This ensured consistency in the data gathering procedures within cases
and across cases. Secondly, in order to reduce the likelihood of forgetting or
misinterpreting the data, and also to allow independent data analysis by other researchers,
interviews and team meetings were taped and transcribed. Thirdly, the application of a
numbering schema to the multiple coding cycles allowed systematic, consistent and
traceable analysis of qualitative data and increased the reliability of research since the
procedures and findings can be audited. Fourthly, the field notes were also transcribed for
future reference.
In the following chapters, I will discuss the results that emerged from operationalizing the
research design outlined in this chapter.
114
Chapter 5
5 ANALYSIS OF CASE 1
5.1 Introduction
In this chapter, I discuss my analysis of the Bank1 case study to highlight insights into the
roles and practices of architects during an EAI. The following format is used to discuss
each of the case studies.
• Background to the case: This includes information about the organization, its
operations and structure. Though it is important that the case studies be understood in
their wider organizational context, background information is presented in a way to ensure
that the identity of the organization and participants is not revealed.
• Information about the research participants: This describes the roles and
responsibilities of individuals who participated in the interviews.
As outlined in chapter four, the discussion of results from the data analysis is presented in
four themes. The first theme, EAI work – the architect’s perspective, highlights the architects’
view of their role in the EAI and how they conceptualize their implementation work. The
second theme: Practice work in the architecture team is focused on the nature of the interactions
amongst the architects and highlights the architect’s perspective on the EAI approach,
tools and documentation. The third theme, Framing EAI work – business and technology staff’s
perspective, highlights business and technology staff’s perceptions and expectations of the
implementation roles and practices of the architects. The fourth theme, Interactions with
business and technology staff, highlights the issues that reveal the nature of the relationship
between the architects, business and technology staff. In order to make explicit the
contribution of particular theoretical categories and codes towards the discussion of the
four themes, in each of the two cases, summary tables were developed. These tables are in
115
Appendix Section 11.3 Summary Tables for Discussing Themes.
5.2 Case Study 1: Bank1
Bank1 has over 48,000 employees, operates in more than 30 different countries including
Australia, New Zealand, the Pacific, Europe, Dubai, United States of America and has
over eight million customers worldwide. At the beginning of 2011, the CEO of Bank1
announced a new five-year strategic plan that required radical change to the business
model and structure of the organization and would see it operating in new international
markets. Such a radical change had significant ramifications for the existing enterprise
architecture (EA). The organization was restructured from sixteen business units to four
business divisions with greater emphasis on international markets. Many of the
technology management and operational functions that supported the sixteen business
units were to be disbanded and many of the technology systems and environments they
managed and maintained were to be upgraded or decommissioned. Previously the sixteen
business units had operated independently, but under the new strategy there was greater
emphasis on common platforms, applications and data sharing.
Producing the EA Plans
After the announcement of the new strategy, the architects met several times over six
weeks with the executives of the business divisions to understand their requirements.
According to the Deputy CEO, who was involved in these meetings, the business
executives and architects discussed the business process, product and service requirements
of the different business divisions, and also their customer data and information
requirements. For the next four and half months (until June 2011), the architects
developed an integrated set of EA models that described the desired systems and
platforms, including the data, application, infrastructure, integration, storage and security
specifications required to support the business divisions. In June/ July of 2011, the
architects presented the EA plans to the senior executives of the various business divisions
who approved them.
Implementing the EA
After the approval of the EA plans, the architects were involved in two significant
activities. Firstly, they selected the new software and hardware products to build the
116
systems and platforms specified in the EA plans. This task, which began in June/ July
2011, was expected to finish by December 2011. In December 2011, the architects
presented the plans for the selected hardware and software products and the programs of
work to the senior executives of the business divisions for approval. However, these
executives were reluctant to commit to funding the hardware and software products and
the programs of work specified by the architects, and by the end of 2011 the
implementation of the EA had stalled.
The second significant activity that the architects were involved with was the Architecture
Review Board (ARB). In June 2011, the CIO established the ARB to review the hardware
and software changes proposed by existing and new technology projects at Bank1. Senior
members of the architecture team staffed the ARB and the ARB became an important
approval step in the funding of technology projects at Bank1. Approval from the ARB
also gave projects access to critical implementation facilities like the development, testing
and production environments. Existing technology projects that were already underway,
as well new technology projects were required to submit their proposed hardware and
software changes to the ARB for approval. From its inception, the architects used the
ARB as an instrument to stabilize the technology environment of Bank1, thus ensuring the
relevance of the EA plans and the selected technology products and implementation plans.
The architects effectively used the ARB to stop new technology projects from beginning
and existing technology projects from implementing.
The ARB lasted approximately twelve months from June 2011 until May/ June 2012. The
interviews for this research were conducted from January 2012 until June 2012, a period
when business and technology stakeholders’ frustrations with the ARB and the practices
of the architects were growing.
The following diagram (See Figure 5.1) provides a timeline of significant events from the
announcement of the new strategy up to the time when the new organizational strategy
was expected to deliver its forecast profits. The timeline also identifies the period during
which the research interviews were conducted.
117
118
Figure 5.1 Timeline for new strategy and EA
119
The following diagram (See Figure 5.2) situates the architecture team within the organizational
structure of Bank1 and shows at what levels and areas of Bank1 this research was conducted.
To preserve the anonymity of Bank1, the individual business divisions are referred to
generically.
Figure 5.2 Situating the architects at Bank1
5.2.1 Information About the Research Participants
For this case study, I conducted thirteen interviews of forty-five to sixty minutes duration.
The interviews were conducted between January 2012 and June 2012. I also attended the
weekly EA team meetings for a period of four months from December 2011 – March 2012
and had access to EA documentation including the EA methodology documentation,
architectural models, EAI plans for all business divisions, architecture review board templates
and also the architecture team charter. Table 5.1 provides a summary of interview participants
120
and their role in the EAI.
Participant Role Role description
Legend BU = Business Unit T = Technology A = Architect
A1 Head Architecture team Has overall responsibility for EA plan development and EAI activities of the architecture team. Leads a team of 25 architects and also Heads the ARB.
A2 Senior Architect (Division A)
Responsible for planning and coordinating EA and EAI activities for Division A.
A3 Senior Architect (Country A)
Responsible for planning and coordinating EA and EAI activities for Country A.
A4 Architect (Division B) Responsible for the production of documentation outputs associated with the selection and implementation of hardware and software products for Division B.
A5 Practice Manager Architecture Team
Responsible for the day-to-day administration of the architecture team. Also responsible for reporting and communications associated with the EA and EAI.
BU1 Deputy CEO Responsible for stakeholder and regulatory matters, deputizes for CEO as necessary. Worked closely with architects in the development of the EA plans.
BU2 Head of Group Operations
Has overall responsibility for Technology at Bank1. Line manager of CIO and Head of architecture. Reports directly to CEO.
BU3 Head of Strategy Responsible for analysis and planning associated with the strategic direction of Bank1. Also responsible for outsourcing arrangements.
121
BU4 Head of Transformation Projects
Liaises with the Head of the architecture team and senior architects to plan and coordinate programs of work associated with the EAI.
T1 Head of Solution Delivery Services (Group)
Responsible for management and coordination of all technology projects and project staff at Bank1.
T2 Head of Solution Architecture (Division A)
Responsible for the management and coordination of solution architects for Division A. These staff will be involved in executing projects associated with the EAI for Division A.
T3 Senior Solution Architect (Division B)
Leads a team of solution architects working on various technology projects in Division B. These staff will be involved in EAI projects for Division B.
T4 Senior Infrastructure Architect (Division A)
Responsible for infrastructure planning and design for Division A and will be involved in EAI projects for Division A.
Table 5.1 Summary of interview participants for Bank1
The Challenges of EAI Work
In this section, I discuss insights into the architects’ EAI roles and practices under three of the
previously discussed four themes,
• Framing EAI work – architects’ perspective,
• Practice work in the architecture team, and
• Framing EAI work – business and technology staff’s perspective.
5.3 Framing EAI Work – Architect’s Perspective
Comments categorized under this theme revealed how the architects perceived their EAI role
122
and how their worldview may have influenced both their practices and their relationships with
business and technology staff. When the architects reflected on the nature of their EAI role,
they focused on their role as enabling strategy and the importance of selecting the appropriate
hardware and software products to realize the new organizational strategy. The issues that
emerged in this theme include, 1) the tendency of the architects to focus on internal
architecture team activities and processes, 2) the absence of business and technology
stakeholder involvement in the selection of the hardware and software products, 3) the
technological focus of the architect’s EAI efforts, and 4) the efforts made by the architects to
try to stop the business and technology from implementing new hardware and software into
the environment.
5.3.1 Selecting the New Systems and Defining the Implementation Plans
The main objective of the architects’ EAI work, as articulated by them, was to select the new
systems to deliver the new organizational strategy and develop the implementation plans to
deliver those systems into operation. My field notes indicate that the architects allowed
themselves twelve months to complete the EA plans and begin implementing the new
systems. It appears from the comments of A2 that the architects wanted to be seen as
proactive in responding to the new organizational strategy.
Once the strategy was announced, we moved fast. If we didn’t, we wouldn’t be visible.
We developed the architecture, leveraging earlier architecture designs and we got approval
from the executive leadership. Then we defined the technology assets [i.e. products] and
implementation plans. We made the decision on which systems the businesses needed to
execute the strategy. The business wasn’t involved … the architecture and roadmaps
[implementation plans] were completed in twelve months (A2).
The implementation plans describe the various hardware and software products, how they
should be implemented, the sequence in which they should be implemented and how the
existing legacy systems would be decommissioned. The architects allowed themselves six
months (June-December 2011) to complete the selection of the technology components, the
123
implementation plans and other technical documentation, and this may form part of the
explanation for their inward looking and team-focused approach. By December of 2011, their
task was not complete. In a team meeting in mid-December 2011, A1 commented,
This is a chicken and egg thing. We have to concentrate. It’s December. So we have to
define the assets [technology products] and roadmaps [implementation plans] as
soon as possible. It’s our number one priority. And to be honest, if ‘X’ and ‘Y’
[senior business executives] come to me and say, “Tell me what architecture I have
to implement?” We only have bits and pieces … We’ve [been] talking for six months
about transaction management and we still don’t have anything. There’s no criticism or
blame, but as long as we don’t have anything, no one is going to listen to us. It becomes
almost a joke, transaction management. It’s the same in the corporate center, the same in
integration but, there at least we have something moving, but we still don’t have the assets
defined (A1).
In selecting the various hardware and software products, the architects did not liaise with
business and technology stakeholders and seemed to assume that it was not important to do
so.
We are identifying the technology products that will deliver the new strategy. We’re not
focusing on business processes … They will come later. At this time, we’re focusing only
on hardware and software (A2).
Our role is first and all, to define the technology components and the implementation
plans. That’s all we do (A1).
Irrespective of what the business wants, we build technology capabilities (A1).
The technical and technology focus of the architect’s efforts may also be a result of
recruitment practices within the team, which gave preference to people with technical
architecture experience.
124
I used to work for HSBC in the UK where I was a strategy manager for the technology
department. So, I do have a technology bias. That may give you a perception of where
my answers are coming from because…I don’t look at it from an organization point of
view. I look at it from a technology point of view (A3).
The architects worked closely with one another, consulted representatives from other
organizations and also liaised with vendors when deciding which products they would select.
My field note observations record the following.
In the team meetings, the architects discuss the progress of the technology selections for each
of the business divisions. It appears from these meetings, that once the EA was approved
by the business executives, the architects immediately began meeting with hardware and
software vendors, locally and internationally in order to identify hardware and software
products that could deliver the technology capabilities and organizational capabilities (e.g.
inter-divisional data management, transaction management) specified in the EA. They
attended product demonstrations locally and internationally, reviewed product
documentation, and talked to people in reference organizations where a particular
software and hardware product had been implemented. They also talked to and took
advice from other architects in their team and discussed potential hardware and software
solutions with them. In team meetings, the architects also discuss and compare the
suitability of particular products. On the basis of their interactions with vendors and
colleagues, the architects selected the hardware and software products they thought would
deliver the new strategy. Business and technology were not involved in the selection of any
of these products and they were not involved in discussions with vendors or product
demonstrations.
It is suggested in the comments by A1 that he expected the senior business executives, based
on their approval of the EA plans, to fund the software and hardware products and their
implementation. Having previously spent many years working as an architect in some major
European banks, A1 said that in his experience the “European way was to honor the agreements you
made” and that he did not expect to have to seek the approval of the senior executives to fund
125
the technology components and implementation plans. Whilst the expectations of A1 may be
consistent with his previous employment experiences, they do suggest an underlying
assumption that the transition from the production of the EA plans to the implementation of
those plans is straightforward and an outcome of the acceptance of the EA plans.
5.3.2 Focusing on Architectural Goals
When selecting the software and hardware products, the architects mapped key architectural
objectives to available commercial-off-the-shelf (COTS) software and hardware products.
Working amongst themselves, they developed evaluation templates and criteria to help them
assess the suitability of various COTs products. The criteria emphasized architectural and
performance goals (i.e. strategy alignment, flexibility, scalability, interoperability) which
represented important improvements to the existing architecture of Bank1’s technology
portfolio. Business and technology staff were not involved in the design of the evaluation
template. Consequently, whilst these criteria may have reflected the values and concerns of
the architects, they represent a partial understanding of requirements since they take little
account of what is important to the business, especially when selecting new software and
hardware products. The following excerpt from my field notes illustrates this point.
There is an application catalogue containing all the applications selected by the architects.
Each application is evaluated against architecture criteria including flexibility, re-use,
simplification, integration, and maintainability. Very few of these criteria take into
account concerns that might seem relevant to the business.
An indicative representation of the application evaluation framework that the architects used is
represented below. (See Table 5.2)
126
Component Name and Description: Component A
Decision Criteria Rating Supporting Comment
Strategy and Architecture Alignment: Is the component aligned to the architecture principles?
Simplification of the environment H/M/L
Re-Use
Integration with platforms ‘X’, ‘Y’ & ‘Z’
Scalability
Compliance with communication protocol ‘X’
Compliance with integration standard ‘X’
Environmental Impact: Does the component improve energy consumption?
Impact on corporate sustainability rating
Impact on data centre energy consumption
Vendor
Commercial viability of vendor
Table 5.2 Summarized example of product evaluation model
The short time that the architects had to complete the selection of the technology components
and the implementation plans it appears may have forced them to prioritize what they thought
was important over the views and concerns of others. There is an implicit sense that the
127
architects are working to a critical path that emphasizes the production of key technical
documentation outputs over the harmonization of what they and their stakeholders consider
to be important. Although the architects were able to produce the technology selection and
implementation plans within the ambitious time frame of six months, that pressure made it
difficult for them to engage with and take account of other’s perspectives.
5.3.3 Not Discussing the Execution of the Implementation Plans
The architects viewed their role in the EAI as selecting the hardware and software
components and defining the programs of technology projects. The task of executing the
programs of work and delivering into operation the specified technology components, they
held, was the responsibility of the business and technology.
We focus on strategy and architecture, not project delivery. The businesses and technology
should play a bigger role and take ownership of the technology projects. They can’t hide.
They own the architecture (A1).
The decision of the architects to make the business and technology responsible for the
execution of the implementation plans did not involve consultation with business or
technology stakeholders. It was standard practice in Bank1 that the business and technology
were responsible for delivering projects that they had initiated and progressed together.
However, in the case of the EA, whilst the business had been involved in the development of
the EA plans, technology had not. Further, neither the business nor technology was involved
in the selection of the hardware and software components associated with the EAI. The
architects, it appeared, had amongst themselves defined the boundary of their EAI work,
which was limited to the production of documentation outputs associated with the selection of
the technology components, and implementation plans. The decision of the architects not to
discuss the scope of their EAI responsibilities with business and technology stakeholders
potentially created different and inconsistent expectations about what the architects are
responsible for. The architects believed they were responsible for the selection of the
technology products and the development of the implementation plans, but as they had not
128
discussed, negotiated and agreed this with their stakeholders, those stakeholders may have held
different views about what the architects are responsible for.
The funding of the architecture sits solely with the business or technology leader. They are
responsible for delivery. Is that clear? The business and technology have to fund the
architecture. It’s their responsibility. We are not involved (A1).
This reflects an interesting point about the difficulty associated with the architect’s EAI role
since there was no prima facie superordinate definition of what the architects were responsible
for. That the architects took responsibility for selecting the technology components and
developing the implementation plans can be seen as the ‘natural’ extension of their EA
planning activities and something that the architects could reasonably have thought they were
responsible for since they possessed the expertise to complete those tasks. Therefore, without
a clear and agreed understanding of their EAI role, it is understandable that the architects at
Bank1 might define for themselves the limits of their EAI role and not seek to validate that
view with the business and technology.
5.3.4 Wanting Management Control over the Implementation Plans
While they did not see executing the implementation plans as their role, the architects
nonetheless wanted management control over the business and technology to ensure the
implementation plans were appropriately carried out. It seems that there was a general sense
of distrust amongst the architects toward the motivations of business and technology staff.
There is always a trade-off between following the architects’ plans and delivering the
project on time and within budget. The first thing to be dropped is the architecture. The
business and technology go for a quick and dirty solution. We see that in projects all the
time (A4).
The architects discussed different management approaches to ensure business and technology
staff carried out the programs of work specified in the implementation plans. A4 stated,
129
The business has often just been driven by what the business has wanted to achieve. How
do we establish a head of architecture in the business, someone who is accountable to us as
well as to the business? … We could do a quarterly review to see how the businesses are
tracking against the implementation plans (A4).
In expecting to hand over the implementation plans to the business and technology to
execute, the architects view their EAI role in terms analogous to the sequential and
compartmentalized phases of the system development lifecycle (SDLC). They conceptualize
their role as analysis, planning and design with documented outputs of their work produced
for others to interpret and implement. The architects also seek to have control over the
efforts of business and technology staff in the same way that a project manager might have in
a technology project. Whilst it is reasonable that the architects as the ‘authors’ of the new EA
would want to have some oversight over how their plans are executed, their distrust toward
the business and technology is indicative of a relationship that needs attention. The architects
seem to see the success of the EAI as dependent on how effectively they can control the
business and technology acquiring the selected technology components and execute the
implementation plans as specified. The mechanism through which the architects envisaged
their EA plan being implemented as specified was governance, alternative methods did not
appear to have been considered.
5.3.5 Stopping Projects
As stated earlier, around the time that the architects completed the EA plans, the CIO created
the Architecture Review Board (ARB). The ARB was staffed by senior members of the
architecture team and reviewed the software and hardware components for all technology
projects at Bank1, existing and new. The ARB was empowered to withhold funding and
access to critical technology facilities and resources from technology projects, effectively
stopping them. The architects used the ARB to preserve the stability of the technology
portfolio so that the selected hardware and software components and implementation plans
remained relevant.
130
Over the twelve-month period from the completion of the EA plans to the completion of the
implementation plans, nearly all of the technology projects reviewed by the ARB were rejected
because they were regarded as inconsistent with the technology direction defined in the
technology selection plans. A2 said that the purpose of the ARB was to “shut everything down”
and to “kill projects, big and small”, as A1 wanted. A3 described the ARB as a “control freak”
concept of project governance. Asked about the effect of the ARB on relations between the
architects and the business and technology, A5 acknowledged that the ARB had caused
conflict between the architects and the business and technology, but that it was necessary to
shut projects down so that the technology portfolio remained stable.
5.4 Practice Work in the Architecture Team
The perspectives of the architects on their internal team practices highlight the importance of
complying with the team charter, working together in a cohesive and collaborative manner and
their tendency to interact with each other rather than with business and technology staff.
5.4.1 Complying with the Team Charter
The architects placed considerable importance on compliance with team practices. Some
practices adopted by the architects were designed specifically to help them cohere as a team.
In one team meeting, I observed the architects negotiate a “Charter of Acceptable Behavior” which
made individual architects accountable for their attendance at weekly team meetings,
prescribed how they corresponded via email with one another (and in particular, how they
should communicate with the architecture team leader) and how they should respond when
asked by business and technology staff what technology components had been selected as part
of the EAI. The team charter was printed as a small handbook and provided to each member
of the architecture team.
The team charter standardized behaviors and practices within the architecture team and
defined what was acceptable and what was not. For example, the document specifies that A1
should not be included in emails unless the email is specifically addressed to him. The
131
document also specifically forbids architects discussing the selected technology components
and implementation plans with business and technology staff. It appears that though A1 had
explicitly told architects not to share this information with business and technology staff, some
architects did so nonetheless. Through the charter, A1 wanted to reinforce to the team that he
alone was the appropriate person to have these discussions. He was also concerned that the
information being shared with the business and technology was creating unnecessary
problems.
We need to be clear about decision-making rules: what is the decision-making model,
solidarity, staying-on-message, who is the final decision-maker and what the final decision
is (A1).
DP means death penalty, and you can be shot twice, or three times. Even when you’re
dead I will shoot again. So... don’t discuss [the plans with the business]. Now this is very
important. Especially when you meet senior people. There was an instance a week ago.
Someone said something about technology that was eventually heard by one of the Board
of Directors. As an architect that’s the worst thing you can do. There was a full-day
escalation. So please take that into account (A1).
5.4.2 Promoting Shared Understanding
The weekly architecture team meetings were an important platform for promoting a shared
understanding within the team since they enabled the architects to engage with one another
directly and on a regular basis. A1 was adamant that all members of the architecture team
attend the team meetings and video-conferencing and teleconferencing facilities were made
available to individuals who were unable to attend in person.
Team meetings were important for updating the group on matters related to the selection of
the technology components and development of the implementation plans especially when
other architects were all working on different aspects of the same plans. At the beginning of
each meeting, each architect would update the team on the progress of his or her designated
tasks. Architects updated the team on matters such as information gathering from vendors,
132
arrangements for product demonstrations, hardware integration standards, and solutions to a
particular problem associated with the implementation planning. These sections of the team
meetings were primarily focused on the provision of information, but they could also be
interactive and architects who had an interest in a particular update or needed clarification on a
particular point were able to ask questions of other architects.
On some occasions, team meetings were used to discuss a matter of concern to the whole
group. In one team meeting, for example, A1 wanted to discuss how the architects, in light of
the fact that executing the implementation plans wasn’t their role, could still have management
control over the various programs of technology projects. This discussion lasted for well over
an hour and aroused strong feelings amongst the architects. Many different ideas ranging
from embedding architects in the business to an implementation governance model similar to
the ARB were put forward. Although no one approach was formally accepted as ‘the’
approach, there was a strong shared understanding generated as a result of the discussion that
the on-going involvement of the architects in the execution of the implementation plans was
an important concern.
5.4.3 Practices that Contribute to Learning
The architects highlighted their open plan office space as being important for facilitating
learning within the team. A5, who worked as A1’s assistant, said that he came from a
marketing background and had no architecture experience before joining Bank1. However, by
being in the same office space, being able to watch the interaction between the architects and
also talking with them, he said that this had furthered his understanding of EA.
I come from a marketing background and before coming to this team, I wasn’t sure what
architects did. But watching them work and talking to them has helped me get a clearer
picture of their design and strategy role (A5).
A2 commented that the physical co-location of the architects in one area and their close
physical proximity to one another facilitated informal learning between them.
133
I’m currently working on the implementation plans for Division A and if I need to speak
with an architect who specializes in a particular area, I can walk over, have the
discussion and get the information I need (A2).
There was no formal architecture training offered to the architects and learning within the
architecture team occurs primarily on the job. A1’s recruitment strategy was to employ
experienced architects because they would be able to “teach and mentor the other architects in the
team” (A1). This was preferred to certification in architecture frameworks such as TOGAF or
the Zachman Framework, which were not seen as appropriate to or fitting the requirements of
Bank1. Other practices that promoted learning within the architecture team included special
research projects (e.g. the Cloud, ‘gamification’, bring your own device (BYOD)) that A1
assigned to individual architects.
The architects developed a number of practices and tools, which facilitated the exchange of
knowledge between them. During the team meetings, I observed the architects: engage in
joint problem solving, coordinate their planning activities and outputs, hold discussions, give
presentations and learn from the professional experience of other more experienced architects.
There are specific documentation templates that facilitated knowledge transfer between the
architects. For example, the selection of the hardware and software products required people
with different areas of architecture expertise to share their knowledge. To help them evaluate
software products, the architects developed product evaluation templates that incorporated
data architecture, infrastructure architecture and security architecture information. They also
developed templates to coordinate the implementation of the many different systems and
platforms, taking into consideration the dependencies between the various programs of work.
They also produced a ‘global’ EAI plan that coordinated the individual implementation plans
for the different business divisions.
5.4.4 Nature of Work – Engaging/ Dis-engaging
In the architecture team, architects mainly work on individual tasks. Architects are aligned to
business divisions and countries (i.e. Australia/New Zealand, Singapore) and also technology
134
capabilities such as customer data management, customer channels and transaction
management. Group work does occur, but mainly within the context of the weekly team
meetings when architects may discuss a particular issue of importance to the team and these
interactions are focused on developing and sharing knowledge within the team.
Within the architecture team, there are healthy levels of engagement amongst the architects. It
is a characteristic of these interactions that the architects engage with one another for a
particular purpose and then once the objective of the interaction is satisfied, they disengage
and transition to the next task. During breaks in the weekly team meetings, it was not
uncommon to observe an architect approach another architect to discuss a particular task he
or she was working on. For example, in one team meeting I observed the architect
responsible for the customer data management platform liaise with the architect responsible
for infrastructure and networks to discuss a question he had regarding the capacity of the
network to support an increase in the number of business users. Once he got the information
he was looking for, he then disengaged from the discussion. It was also not uncommon in
these interactions for architects to improvise a diagrammatical model of the problem they
were discussing. This allowed them to clarify and agree a particular perspective or approach
and bring their respective expertise to bear on the particular problem they were discussing.
5.4.5 Perspectives on EAI Methodology and Tools
The architects at Bank1 preferred not to use prominent EAI methods such as TOGAF (The
Open Group, 2003) and instead developed their own EAI framework, templates and tools.
A2 described the EAI method of the architects as “telling the story” and this involved mapping
the systems and platforms specified in the EA to the existing technology portfolio, identifying
the capability gaps and then specifying the new technology components and implementation
plans to bridge those gaps.
Our approach was to organize the roadmaps [i.e. implementation plans] for each of
the divisions into different architectural perspectives: such as customer channel, transaction
management, etc. You can’t do that with the Zachman or TOGAF, they limit you to a
135
predefined set of architectures: data, application and infrastructure. We needed a broader
framework - something that fitted the story we wanted to tell the senior executives of the
divisions (A2).
A2 described the level of detail associated with the implementation plans as “high-level” and a
“60,000 foot view of the organization”, but he said the abstract and generic level of the information
facilitated the integration of the different implementation plans for the various business
divisions.
The modeling templates the architects used in their work revealed a strong technical emphasis.
Many were rich in technical detail and included architectural models that combined data flows,
system interfaces and infrastructure processes for entire countries. Some of the architectural
model documentation printed on single sheets of paper measured more than six feet high and
at least four feet wide. These diagrams and other architectural models and documentation
were kept in a locked room accessible only to the architects. When I asked A2 about the large
architectural diagrams and who was likely to use this work and what might it be used for, he
commented that it was primarily for the architects’ use. However, he could not explain how
the information contained in the model was operationalized.
There seemed to be little concern on the part of the architects that some of the documentation
they produced might not have a practical use to the EAI. My field observations include the
following comments.
Some of the architecture diagrams are highly detailed and technically complex. They are
notated in UML and reflect the format of activity state diagrams. On one wall on very
large single sheets of paper (approximately 6 ft. tall and 4ft wide) with very small font
(possibly 8 or 9 size) there are activity state diagrams for the technology portfolios for
particular countries. These models map all of the systems, the processes and data flows
that are involved for the different ways in which a customer can interact with the bank
(branch, telephone, internet, call center, hardcopy mail) in a particular country. They are
technically very impressive to observe, represent a significant effort to produce and integrate
highly specialized knowledge of the bank’s systems, processes, infrastructure and data, but
136
I’m not quite sure how they might be of practical use. They seem symbolic rather than
significant in the sense they represent the technical knowledge and modeling expertise
within the architecture team, but they are not made available to technology staff and
contain a lot more information than is required for the implementation plans.
5.5 Framing EAI Work – Business and Technology Staff’s Perspective
To balance the perspective of the architects on the nature of their EAI role, I now discuss the
perceptions of business and technology staff.
5.5.1 Delivering a Technology Strategy
Business and technology participants described the EA plans as articulating a technology
strategy for Bank1 and expected the EAI to deliver that technology strategy. BU2 described
the EA as defining a “strategic aiming point for technology” and he described the selection of the
technology components and implementation plans as “moving the organization in that direction”.
BU1 said that over the years the individual businesses had “done their own thing with respect to
technology” and that now the bank needed a new technology strategy.
In planning the technology components to deliver the new strategy, the architects were
expected to take a strategic industry view and consider the technology direction of the banking
industry and the potential benefits of new technologies and methods of technology service
delivery such as the Cloud. They were also expected to take into consideration the future
product and services envisaged by the different businesses, the markets they intended to
operate in and how customers would interact with the bank.
The architects need to work with the business executives to understand what the
businesses want to do, who they are going to compete with, what is their customer
proposition and what products they need. The architects need to understand what services
the businesses want to deliver, which markets they’re going to operate in, what channels
they’re going to use, all of those sorts of things. This then needs to be translated into
137
technology components and the architects have to be able to make the connection between
those technology components and the requirements of the businesses (BU1).
Technology participants wanted to know the architects’ plans for delivering the technology
components. They wanted to know how the technology components would be delivered and
what the programs of technology projects were. Technology managers were concerned that
the architects had not given due consideration to the organization’s level of preparedness and
level of disruption to the bank’s operations the implementation plans might cause.
We need to understand where we are going from an individual system perspective all the
way to what does our target architecture look like? You just can’t go and roll out a huge
monolithic ERP solution or a huge core banking solution (T3).
5.5.2 Considering Outsourcing Arrangements
Business executives wanted the architects to explain how the implementation of the EA could
affect strategic partnerships with external partners. Many of the systems and platforms used
by the business divisions were either supported or provided by third parties and some of these
were under contract for the next three to five years. Business executives such as BU3 were
concerned that the architects had not considered the implications of the existing outsourcing
contracts and wanted to know what would happen to those systems currently supported by
outsourcing arrangements.
It’s not a simple as clearing out the portfolio and starting again. There are contracts with
external partners that have to be taken into consideration. The architects can say that a
particular platform is to be replaced, but if there is a support contract or a service
provision contract, well, we are either stuck with it or we have to pay the contract out.
That’s just throwing money away (BU3).
5.5.3 Addressing Problems with the Technology Portfolio
As well as considering the strategic, operational and outsourcing requirements associated with
138
the new strategy, the architects were expected to address existing problems with the
technology portfolio. The EAI work of architects, as conceptualized by some technology
stakeholders, extended beyond the selection of technology components and development of
the implementation plans and included corrective and perfective changes to the technology
portfolio.
We have 2,500 applications. That’s a huge application portfolio and sounds wrong to
me for a bank of this size. The goal has to be the simplification of the application
environment … To me the consolidation and rationalization of the application
environment is a function of enterprise architecture. They should be asking what
functionality do these applications provide and is it possible to share them? (T4)
When reflecting on the problems associated with the technology portfolio, business and
technology participants showed they were able to enter in the ‘world’ of the other.
We have real problems sharing customer data across this organization. We can with
some effort work out how many products a particular customer has with us, but that can
take up to week to get all the information. Mortgages, superannuation and credit cards
don’t share customer data because their systems don’t talk. The new architecture must
allow the small business people talk to the mortgage people, or the capital finance business
to talk to the corporate bank. (T4).
The architects need to go through the bank business-by-business and look at how complex
the technology links are and how we could simplify the technology environment. We need
a simpler and more connected technology environment, more re-use, lower cost and an
environment that is more agile (BU1).
This shows that other stakeholders have expectations about what the investment in the EAI
will deliver. It also indicates that architects cannot assume that what matters and is important
to stakeholders is limited only to those areas for which stakeholders have management
responsibility and that stakeholders may have concerns beyond their immediate management
responsibilities.
139
5.5.4 Engaging on an As-Needs Basis
Business and technology stakeholders did not expect to have an on-going and continuous
engagement with the architects, but wanted to be able to engage with the architects, as
required on an as-needs basis. The nature of these engagements is that they are task specific
and that once the objectives of the task are completed, business and technology stakeholders
would disengage from their interaction with the architects. Comments from business and
technology participants indicate that they needed to engage with the architects on range of
different matters relating to the EAI including the implications of the EAI for the existing
outsourcing arrangements (See Section 5.5.2) or to discuss problems with the technology
portfolio (See Section 5.5.3). As well, technology managers who had responsibility for staffing
technology projects wanted to engage with the architects to understand the skills that would
be required to execute the implementation plans so that they could begin to plan the
recruitment of those staff.
The general manager of project delivery complained to the CIO that the architects are
producing implementation plans that we can’t implement because we don’t have the staff
or the skills required to deliver them (T2).
T1, who has overall management responsibility for technology project delivery (including
project managers, solution architects, developers, testers, etc.) at Bank1, commented that
whilst he didn’t need to engage with the architects continuously, he needed to engage with
them occasionally to understand the staffing requirements of the EAI. He wanted to be able
to advise his line management staff (who had day-to-day management responsibility for
project delivery staff) about how they should plan for the allocation of technology staff to the
programs of work associated with the EAI. T1 said that the consequences of not being able
to engage with the architects meant that he was not able to adequately plan the staffing
requirements of the EAI and that “there will be a mad scramble to find project delivery staff” (T1).
Technology staff were also dependent on the architects for information about the selected
technology components and the implementation plans. They wanted to be able to engage
with the architects to understand what level of dependency there was between their particular
140
project and the technology components that the architects had selected. Though the
architects were using the Architecture Review Board (ARB) to stop technology projects from
beginning, nonetheless, there were projects that began before the ARB was established, which
needed to be completed. Technology staff involved in these projects were concerned to know
whether or not the systems they were implementing or interfacing with would be replaced by
the EAI. The potential risk for those technology projects and the businesses funding them
was that they may spend a large sum of money and effort deploying a system only to find out
that it is scheduled to be replaced.
I’ve been in meetings where somebody from a project has asked a question about the
implementation plans and the architect can tell them an answer, but he won’t because
information about the implementation plans is restricted (T3).
5.5.5 Building Support for the EAI
Both business and technology participants interviewed for this research expected the architects
to build support for and commitment to fund the technology projects specified in the
implementation plans. Business and technology participants commented that the architects
could not expect that the technology components and implementation plans would
automatically be funded once the EA plans were approved. Participants emphasized that the
support of people at the senior executive level of the business divisions was critical to the
delivery of the EAI since the business divisions funded all technology projects at Bank1. As
commented by BU1, the senior business executives who had responsibility for running the
business divisions were more likely to strive for their own interests rather than support the
EAI.
People are being measured on the success of their divisions. The architects are not
allowing them to be as successful as they would like to be. So this is about people’s
behaviors (BU1).
Therefore, according to BU1, if the architects are to be successful in building commitment to
141
the EAI, they must be able to influence people at this senior level to think beyond their own
individual interests and think in terms of what is best for the organization. It appears from the
comments of BU2 that the architects found this a difficult challenge.
Now we have business owners saying, “No, you can’t have any funding because I have a
higher priority.” This tells me the architects were not successful in getting the businesses
to prioritize the architecture over their individual concerns. They didn’t change that
mindset. (BU2).
A possible factor influencing the individualistic approach of the senior executives are the
reward structures within the Bank1. BU2 indicated that business executives are assessed on
the basis of the performance of their individual division, rather than the whole organization.
Their contributions to the organization as a whole are secondary to the profits and cost
management of their particular division. Financially, the potential rewards for these executives
are significant if they meet their profit and cost reduction targets. BU1 indicated that bonuses
of the highest-level senior executives were several millions of dollars. According to BU2, the
architects needed to demonstrate how funding the technology components and
implementation plans would benefit the interests of those executives.
One of the things missing was buy-in from all the major stakeholders. We didn’t get all
the big hitters around the top table to absolutely agree to support these projects to the ‘nth-
degree’ of their lives. The architects have got work to do to convince those people that the
architecture is also in their interests (BU2).
Senior business executives interviewed for this research indicated that to be successful in
building support and commitment amongst the senior executives, the architects needed to
develop a sense of mutual engagement amongst the senior business executives.
If we can’t set up our technology in a way that supports our strategy, well we’re not going
to succeed. But that is not understood by the whole organization, yet! We have a
technology setup that doesn’t correspond with what we do as an organization. Therefore,
the enterprise architecture was not a co-owned initiative. It was more like, “well, it’s your
142
problem and you’re imposing it on me” (BU2).
There was also a strong sense that the architects needed to understand the formal processes
through which Bank1 allocated funding for transformational technology programs and how
those programs could affect the organization’s profit forecasts. The architects needed to be
aware that the organization is accountable to its shareholders for its profit forecasts (and what
the consequences were if the organization did not meet those forecast targets)
Organizations have a rhythm and cycle. The investment plan for the new systems was too
late for the strategic investment planning cycle. They asked for money at the wrong time
for consideration, you know way too late for us to re-do the budgets. They were way too
late for that conversation last year and it doesn’t happen for another year. You cannot
ask for such a large amount of money in that way because we’ve got to deliver a dollar
number this year which is ‘X’ percent more than last year and if we don’t do it, well,
we’re all dead (BU1).
The architects were also expected to understand the informal ways in which organizations
work and how the political networks at Bank1 could be used to build support for the
technology components and implementation plans at the senior executive level.
Nothing happens in a vacuum. They didn’t engage with people like me who can help
them turn the technology plans into a reality? At the organizational leadership level,
you’ve got to be dealing with the Head of Strategy, me, the division executives, technology
heads and really be fit and ready for the conversations. The architects have got to debate
why we should do the architecture and why we shouldn’t do ‘X’. They need the influence
of people like me (BU1).
5.5.6 Understanding the Impact of the EAI on People
When asked why the senior executives were reluctant to fund the technology components and
implementation plans, some interviewees mentioned people’s fear of losing management
control. The implementation of the EA was expected to retire the legacy systems replacing
143
them with new platforms, which meant staff that were responsible for those legacy systems
would, according to BU2, most likely be made redundant. Staff responsible for managing
outsourcing contracts for business platforms were also at risk, as a result of the new
technology portfolio introduced by the EA. Consequently, participants mentioned that the
architects needed to consider the emotional effect that implementing the EA might have on
some staff. The following comments by BU2 suggested that people’s fear of what might
happen to them was driving negative behavior within the organization and resistance to the
EAI.
We’re introducing new power structures. There’s a winner and a loser. Multiply that up
by multiple business divisions, multiple business lines and thousands of people, some
trying to win something, many believing they are losing, as opposed to adjusting what they
do. That makes for a very painful transition. The fundamental challenge is power and
control: I give up, you don’t give up, are we partners, are we in this together, do I trust
you? (BU2).
The EA introduced many shared platforms, which meant that the pools of technology staff
that were previously aligned to a business division, would instead be aligned to a particular
technology platform such as customer data management, payments, and document
management. This meant that people who once were responsible for a pool of technology
staff in a particular division would no longer have management control of those staff and
therefore their current management positions would also be at risk.
We are unpicking the structure of the organization. In particular, the control structure of
technology, which was [previously] deeply vertical and aligned to the divisions [and is
now] based on enterprise competencies. This brings new problems. Existing
management roles will no longer be relevant and people will have to apply for management
roles with some people being forced to move on (BU2).
According to T3, an important aspect of the architect’s EAI role is to explain to staff what the
EAI means for the existing structure of the technology function.
144
They should sit down with the technology leaders and their teams and explain the
consequences of their implementation plans and what the operationalized … architecture
would mean for them. Is the existing organizational structure of the technology function
still relevant (T3)?
5.6 Interactions with Business and Technology Staff
In this section, I discuss the interactions between the architects, business and technology staff.
Business and technology participants commented more about their interactions with the
architects than they did about the selection of technology components and implementation
plans. The strength of the comments from business and technology staff about their dealing
with the architects could be interpreted as a symptom of a relationship that needed more
careful attention.
5.6.1 Not Engaging
The architects did not treat all of their stakeholders in the same way and were viewed as being
selective in choosing who they communicated with. The architects were seen to be more
interested in communicating with the highest-level senior executives from the business and
technology and less interested in communicating with technology staff, especially those staff
working on technology projects. As indicated in the comments of technology participants,
this approach of the architects caused considerable frustration amongst technology staff.
These guys are very good ‘C-level’ communicators. They only talk to the CIOs, CEOs
and CTOs and it’s causing a great deal of friction with technology projects. I see the
problems all the time. There’s no point in pretending the problems don’t exist. We have
to work with them and they have to work with us (T2).
The implementation plans have not been communicated down to the project level. People
are trying to find out what technology resources [products] have been selected and when
they will be delivered. The communication problems are mostly downwards (T4).
145
Technology participants felt the architects did not adequately appreciate the extent to which
technology stakeholders were dependent on them for information about the selected
technology components and implementation plans. It was expressed very strongly in the
comments made by participants from technology that the architects would not share
information with them and in fact, withheld it. All of the technology participants interviewed
in this research highlighted the ARB as a key example of how the architects withheld
information and how that practice made life very difficult for technology project staff.
Participants noted the lack of consideration shown by the architects to technology project
teams and how dependent those teams were on the architects. T1 commented that because
the architects would not release the selected technology components, technology project
teams were in effect hoping that their proposed software and hardware changes were
consistent with the components specified by the architects. The perception that the architects
were deliberately impeding technology project teams by withholding critical information
aroused strong emotional responses from technology staff participating in this research. T4,
who had personal experience with the ARB, commented that technology staff “felt alienated”
and went to the ARB like “lambs to the slaughter.” T4 said that the architects were accountable
for explaining and communicating the EAI, “but they don’t live up to it.”
Communication is critical. But the architects don’t understand the importance of
communication. They won’t publish and communicate the implementation plans. They
won’t meet and talk to people. I’ve seen the architecture implementation plans hanging on
the walls where the architects are, but the architects haven’t discussed them with us and
won’t discuss them with us (T4).
The architects did release some architectural documents to technology staff and put these on a
portal. However, it appears from comments of T3 that the information contained on the
portal was seen as inadequate and the organization of that information made it difficult for
people to access.
I think the portal has served a purpose, but it does not address all of the problems. It
hasn’t fully served the purpose that I think it needs to because all of the documents have
146
“restricted” written on the bottom. There are principles in there, but they are not in one
place. You’ve got at least 7 or 8 different sets of principles and some of the principles
conflict. So, it looks like you have 7 or 8 different groups of people producing the
architecture (T3).
The architects, it seems, made it difficult for people to engage with them on an as-needs basis
and this can be seen in their preferred method of communicating, an online wiki. T1, who is a
peer of A1, commented that he had heard the architects had selected a particular technology
product and, based on his previous experience working with that product, he had concerns
about the suitability of that product. However, when he tried to share this information with
the architects, he was told to use the wiki. T2 commented that communicating with the
architects required more than a wiki.
They won’t meet with us. Yes, they have published a link to a website, a wiki, but that’s
not communication (T2).
5.6.2 Being in an Ivory Tower
This category focuses on the extent to which business and technology staff viewed the
architects as disconnected from the practical concerns of running a business or technology
function. Participants focused on the idealistic and impractical nature of the technology
components selected by the architects. BU2 felt that the architects were pursuing idealistic
and “Rolls Royce” solutions whereas they should be focusing on practical outcomes.
We have to draw a balance between architectural perfection and real-life constraints. No,
they can’t have 9 billion dollars to rebuild the bank. Is it really necessary to have the
Rolls Royce version of such and such a solution when the Band-Aid version would do fine
(BU2).
BU4 commented that the architects pursued idealistic technology solutions that cost “three
times more than other solutions” at a time when the Australian economy was being affected by the
Global Financial Crisis (GFC) and Australian banks were being asked to contain their
147
spending in order to have sufficient cash reserves.
Even though it may be building foundational capability for the organization, it was
impossible because of the GFC (BU4).
Some interview participants specifically characterized the architects as being in an “ivory tower”.
T1 who had previously worked with some of the architects on projects unrelated to the EAI
commented that the solutions they advocated “were not based in reality and could not be delivered”.
T1 said the architects had selected software that was untried in other organizations and was
very difficult to implement at Bank1 because staff did not have the appropriate skills. T2, who
had also worked with the architects prior to the EAI, made similar comments.
The architects looked at brochure-ware and some of the demos of the vendors and thought
the software would absolutely meet our functional requirements and was right for us.
But, when it came to the reality, there were no people in the bank or in the region who
knew how to integrate those products with our systems. The projects just failed miserably
(T2).
5.6.3 Behaving as an Elite
There was a strong sense from the comments made by technology participants that the
architects behaved as an elite. An example illustrating this point is the decision of A1 to
disallow other technology staff at Bank1 to use the term ‘architect’ in their job title. All
technology staff interviewed for this research raised this matter. A1 persuaded the CIO to
reserve the term ‘architect’ for the architects exclusively. This meant that the job descriptions
for many people in technology changed and those who used the word ‘architect’ in their title
would instead be called ‘designers’ or ‘engineers’. This in effect increased the distance
between the architects and technology staff because, as participants commented, this decision
devalued the work of staff such as solution architects and infrastructure and network
architects.
This has just created a bigger and bigger chasm between the architects and us. Although
148
the architects are looked up to as knowledgeable, the solution architects are actually the
ones delivering projects and delivering value to the organization (T2).
T3 felt that taking away the title ‘architect’ had significant implications for people’s careers
both within and outside of Bank1.
There is an implicit exclusivity, a cache around the title ‘architect’. To remove the term
‘architect’ from the solution architecture group is a contravention of the way the
Australian IT market describes IT roles. We’re just completely befuddled as to why he
would do this. It just perpetuates the gulf between the architecture group and us (T3).
5.7 Summary
In conclusion, the architects at Bank1 wanted to complete the selection of the technology
components and implementation plans within six months. Their efforts were focused on the
internal team tasks and processes required to complete their work in the time they allowed for
themselves. The architects completed their work independently from their business and
technology stakeholders and consequently their approach and documentation templates had a
distinctly architecture focus. For example, in selecting the required software and hardware
products, the architects developed evaluation templates that prioritized architectural goals over
the interests and concerns of business or technology stakeholders.
The practices within the architecture team serve to support the functioning of the team and
the completion of the technical documentation associated with the technology selection and
implementation plans. There is a strong requirement to comply with the desired behaviors
within the team and not to disrupt the functioning of the team. Architects interact with one
another on an as-needs basis for the purpose of completing designated tasks. Learning is
based on experience and knowledge exchange between architects and occurs mainly on the
job, as architects engage with each other to solve problems that cross areas of expertise within
the architecture team. New knowledge is also developed through special research projects
assigned to architects.
149
It is also evident that business and technology participants expected the architects to liaise
closely with business and technology staff, but on an as-needs basis and to fulfill a number of
roles. Architects were expected to:
• Fulfill a strategy enablement role and select technologies that will enable the realization
of the new technology strategy,
• Take into consideration the technology direction of the banking industry and the
benefits of new technologies and methods of technology service delivery such as the
Cloud,
• Fulfill a ‘problem solving’ role and address different problems in the technology
portfolio including legacy systems and application redundancy,
• Understand the ‘external world’ of the business, in particular the accountability of the
organization to its external stakeholders,
• Understand the ‘internal world’ of the organization and how they could leverage the
political connections of senior business executives to build support for and
commitment to fund the selected technology components and implementation plans,
and
• Understand the potential emotional impact of the EAI and how people may fear the
changes introduced by it.
There is a perception amongst business and technology staff that the architects did not engage
with them. Although the architects shared the technology selection and implementation plans
with some of the senior business executives, they did not share these with technology staff.
This practice meant that staff involved in technology projects were unable to plan for the
software and hardware changes specified by the architects. Furthermore, both business and
technology participants described the architects as living in an ivory tower. Comments from
business and technology staff, suggest a link between the failure of the architects to build
support for and commitment to fund the EAI and their isolationist approach.
150
5.8 Reflection on Case 1
The purpose of this reflection is to address some key questions that arise from the Bank1 case
study. Firstly, why was the ARB established and why was it given the power to effectively
stop projects? Though the interview questions do not specifically explore this question, it
appears that the architects wanted to ‘lock’ down the technology portfolio after the EA plans
were approved. This makes sense if one considers that technology projects were introducing
new systems, creating new interfaces, retiring existing systems and these changes would
potentially make the EA plans obsolete. Thus, it seems the architects wanted to stop existing
and new technology projects from progressing to ensure the stability of the technology
portfolio and the relevance of the EA plans.
Secondly, why did technology and business staff persist with the Architecture Review Board
(ARB) when the architects were using the ARB to stop projects? It seems that compliance
with project governance processes was the reason why business and technology staff
continued to submit their project architectures to the ARB for approval. When I asked T3
why technology staff continued to submit their projects to the ARB when almost all of them
were rejected, he said that that was the process they had to follow. However, technology
projects eventually stopped submitting their software and hardware changes to the ARB,
effectively bypassing the architects. They were able to do this because business executives
who sponsored these projects had sufficient money to fund their own technology projects and
were able to re-allocate funding earmarked in the current year’s budget. This meant the EAI
had been unsuccessful as the business divisions began to implement their own architectures.
Furthermore, the efforts of the architects to build shared platforms were supplanted by the
interests of individual business divisions. When the ARB was dissolved in the middle of 2012,
there was effectively no global architecture governance at Bank1, as business divisions made
their own technology choices and investment decisions. Business divisions subsequently
focused on their own specific needs and priorities rather than overtly considering the interests
of the wider organization.
Another question that arises from the data analysis above is why didn’t technology executives
make greater efforts to understand what technology products had been selected by the
151
architects? As indicated in the data analysis above, the architects wanted to ‘lock down’ the
technology environment to ensure that it remained stable and thereby preserve the accuracy of
the EA plans. It seems that A1 was able to persuade the CIO that this was an appropriate
approach, though eventually when the businesses began to bypass the ARB and implement
their own architectures, the technology components selected by the architects became
irrelevant.
152
Chapter 6
6 ANALYSIS OF CASE 2
6.1 Introduction
In this chapter, I discuss my analysis of the Bank2 case study to highlight insights into the
roles and practices of architects during an EAI.
6.2 Case Study 2: Bank2
Bank2 has over 40 thousand employees, more than 12 million customers worldwide and
operates in Australia, New Zealand, England, North America and Asia. In 2010, the CEO of
Bank2 announced a new strategy to modernize the bank, digitizing its business operations,
upgrading the core banking platform and launching an online bank. The new strategy radically
changed the EA of Bank2 forcing the retirement of many legacy systems, the introduction of
shared platforms and new platforms to support the new online bank. The architects liaised
with the senior executives of the different business divisions and lower level staff from the
businesses and technology to understand the requirements of the divisions and also the
constraints of existing business processes and technology systems. They developed a new EA
and in conjunction with technology staff they selected new technology components and
developed implementation plans to operationalize those components. The new technology
components and implementation plans were accepted by the business and the first projects
associated with the EAI began in 2011.
153
The following diagram (See Figure 6.1) situates the architecture team within the organizational
structure of Bank2, and shows at what levels of Bank2 this research was conducted.
Figure 6.1 Situating the architects at Bank2
As they are represented in the above diagram, the architecture team comprises two distinct
groups, the business solutions architects and EA strategists. In order to be consistent with the
analysis of the Bank1 case, I will use the term architects to refer to both groups.
6.2.1 Information about the Research Participants
For this case study, I interviewed seven participants. Some of the participants were
interviewed more than once and in all I conducted twelve interviews of forty-five to sixty
minutes duration. The architecture team did not meet regularly as a group and so I did not
have the opportunity to observe team meetings, as I did at Bank1. However, I had access to
154
documentation including business strategy documentation, EA documentation and
implementation planning templates used by the architects. Table 6.1 provides a summary of
interview participants and their role in the EAI.
Participant Role Role description
Legend BU = Business Unit T = Technology
EA = Enterprise Architect
A7 Head of Architecture team
Has overall responsibility for EA plan development and EAI activities of the architecture team. Leads a team of 18 architects.
A8 Snr Architect (Division A)
Responsible for coordinating the EA and EAI activities for Division A.
A9 Snr Architect (Division B)
Responsible for coordinating the EA and EAI activities for Division B.
BU5 CEO online division
Responsible for the performance, management and strategic planning of the online bank.
BU6 Head of Finance and Risk, EAI Program X
Leads finance and risk management teams involved in EAI program X. Senior executive in the Finance function.
T5 Head of solution delivery (Group )
Responsible for the management and coordination of solution architects across the bank. These architects are involved in EAI projects.
T6 Solution architect (Division A)
Responsible for providing detailed architecture solutions for existing EAI projects.
Table 6.1 Summary of interview participants for Bank2
155
6.3 Framing EAI Work – Architects’ Perspective
In Bank2, the architects’ comments suggest that they were more comfortable and collaborative
in their interactions with business and technology stakeholders. Their comments highlight the
importance they ascribe to building and maintaining ongoing relationships with business and
technology staff and also the importance they place on personal and professional relationships
to build support for and commitment to fund the technology components and
implementation plans associated with the EAI. The comments of the architects at Bank2
provided insights into their views about the dynamic nature of an EAI and the flexible
approach architects must take to accommodate the changing priorities of the business.
6.3.1 Selecting the New Systems
To help them select appropriate systems, the architects developed strategic business plans with
senior executives and other representatives from each business division. These plans
identified the strategic objectives of the individual business divisions and their desired
products, customer services and business processes. A8 described the business strategic
planning as “high-end business analysis” and commented that its purpose was to document the
“future state of the business” and provide a framework for selecting appropriate software and
hardware products. A8 reflected on the benefits of the strategic business plans and said that
they helped business executives understand the connection between the selected systems and
the organizational capabilities, products and services they wanted to develop.
Business strategic planning definitely rings a bell with executives. What is the business
strategy, what are the business capabilities and how do we design those capabilities into
the organization? Then we ask what technology is required to achieve those capabilities.
When we link business strategy, business capability, business process and technology,
business and technology executives understand it and buy into it (A8).
We work quite closely with the business to understand when they are planning to release
new products. We ensure that our technology plan aligns to their product release strategy
156
(A8).
The document template for the business strategic plans was developed by the architects in
collaboration with senior business staff and is completed by the architects with involvement of
senior business staff. My field notes record the following observations about the document
template for the business strategic plans.
The document template for the business strategic plan is a ten-page PowerPoint document.
The document was developed in collaboration with the business and includes strategic
planning models such as PEST, SWOT, organizational competency planning models
and also Porter’s Value Chain and Five Forces models. The Value Chain model is
adapted to include high-level information about the key hardware and software systems
required to support the identified primary business functions. The Five Forces model is
used to describe the potential competitive effect of those systems in the market that the
business division operates in. The content of the document is high-level and does not
mention specific vendor products. Instead, it refers generically to systems and platforms
such as data management, document management, information frameworks, security, etc.
More detailed information about specific technology components and vendors is provided
in the corresponding technology architecture.
The business strategic plans are supplemented with a technology plan that specifies in detail
the specific software and hardware products for the systems specified in the strategic business
plan. The technology plan also includes implementation plans for delivering those products
into operation and describes the sequence of the various programs of work. In selecting the
technology products and developing the implementation plans, the architects liaise closely with
senior executives from the business and technology to evaluate the candidate technology
products against the required organizational capability, products, services and business
processes described in the strategic business plans.
We actually work quite intimately with the business to align the business and the
technology selection. We plan the business model, the customer channels, the types of
157
business products and services, and then with technology we will develop the technology
plan and specify the hardware and software products we want to use (A8).
6.3.2 Building Relationships
The architects focused on building strong on-going relationships with business and technology
stakeholders. I asked A9 how the architects were able to build support for and commitment
to fund the technology components and he said that it was “the relationships we build with our
business and technology stakeholders”.
The architects characterized their relationship with business and technology stakeholders as
based on practical considerations. Though they described the organizational culture of Bank2
as valuing and rewarding collaboration between staff, the architects said that over a period of
time business and technology staff had come to trust the advice of the architects. The
architects also made efforts to make themselves accessible to business and technology staff.
As an organization we have a culture of working closely together. This eliminates a lot of
unnecessary tension between us and the business and technology. We are not competing
with each other (A8).
It’s about the quality of what you have to say and being available. There is no point
going to see someone unless you have done the analysis and you have the time to take
them on the journey. If you provide them with sound, practical and sensible analysis and
support, which they see as valuable, then over time the relationship develops (A9).
The architects acknowledged that delivering on what they promised to the business and
technology was critical to maintaining the trust of business and technology staff. A9
commented that in the past the architects at Bank2 had not been able to build effective
relationships with the business because they had not developed the trust of the business.
We had to deliver on what we said we were going to do and deliver on time and within
the right parameters. We did that and we are now accepted and recognized as successful
158
by the business and technology. Previously, we were not connected into a number of
business and technology conversations, but we are now and we are more effective today
than we were two years ago (A9).
The architects spent a large part of their time liaising with business and technology
stakeholders, informally and formally. A9 calculated that he spent over fifty per cent of his
time each week meeting with business and technology staff. He said that the purpose of these
meetings varied from discussing the progress of a particular project, an emerging business
requirement or other matters important to the business and included formal meetings and
casual discussions over coffee. Though this meant that he had less time during the day for the
technical aspects of his role, this liaison work was very important since it allowed him to
understand what people were saying about the architects.
There are politics in the organization and they play out on a daily basis. In this
organization, politics is played out very quietly and in corridor conversations and often
you don’t hear what’s being said about you. We have to be able to detect those
conversations in order to intervene (A9).
6.3.3 Communicating
The architects placed great importance on communication and viewed it as critical to building
effective working relationships with business and technology stakeholders. It appears from
the comments of A7 that the architects had learnt from the mistakes they had made in the
past.
We've learned our lessons and now communicate better with stakeholders. For example,
in the past, we were criticized for not communicating the risks involved in projects. We
are now communicating those risks to the stakeholders (A7).
The architects put in place formal processes and on-line tools that facilitated communication
with business and technology stakeholders and allowed those people to voice their concerns
about the practices of the architects.
159
We have a regular quarterly performance feedback process. All our stakeholders, on a
consistent set of measures, assess the team and individual architects. We then have to
respond to that feedback, in person. This is critical since we rely on our relationship with
the business and technology to get projects done (A7).
According to A7, this feedback mechanism helped strengthen relations between the architects,
business and technology stakeholders since it provided a springboard for open and honest
dialogue and “helped surface criticisms rather than let them fester”. This process led to direct face-to-
face discussions between the architects, business and technology stakeholders and allowed
them to reach a shared understanding and agreement about a problem or problem solving
approach.
The first survey triggered a conversation that I had with the stakeholder a couple of days
ago. This person had marked us down. We had a lot of good marks from other
stakeholders. But, this particular business area marked us down. I had an open and
honest conversation with that person. He admitted that he was under stress because his
project was running late. I explained that the architecture standards that the government
have mandated require us to buy new technology. His comment to me that we should
discuss this further before we commit to a technology solution was fantastic. That is
exactly what we should be doing. It was great (A7).
It seems from the comments of A7 that on-line tools and problem resolution processes which
allow business and technology staff to voice their concerns and address them in person with
the architects are viewed as important by the architects since they effectively provide a release
valve for potential tensions. A7 commented that the “architects could not possibly please everyone all
the time” and that it was more important to be in an “ongoing conversation” with business and
technology stakeholders.
6.3.4 Speaking in Two ‘Languages’
The architects appreciated that business and technology staff inhabited different ‘worlds’ and
160
reflected on the potential of architecturally complex language to confuse and alienate them.
They saw that the effectiveness of their relationships with business and technology staff
depended on their ability to speak two languages: “business speak” and “technology speak”. When
talking to business staff, the architects were careful to use language that was meaningful to the
business.
We have to be able to communicate to the business in business-speak and not technology-
speak. If we communicate in technology speak, we will lose the business. It takes a long
time to build that communication skill (A8).
Architects reflected on the specialist skills required to converse with business staff and
commented that it was important for the architects to learn those skills in order to be more
effective in their interactions with business staff.
Business conversation capability ... that is a skill we have to learn. It’s certainly a talent
or capability that you can learn and we are trying to teach architects those skills because
we can always be more competent in that area (A9).
The architects’ efforts to speak the language of the business and technology suggest they tried
to adapt their practices to make them intelligible and accessible to business and technology
staff. It also shows a willingness on the part of the architects to act as bridges between their
practices as architects and the worlds of business and technology staff.
6.3.5 Being Flexible
The architects adopted a flexible approach to the hardware and software components
specified in the technology plans and made changes, as required, when business requirements
and priorities changed. The architects, it appears, gave priority to the operational and
regulatory requirements of the business.
Some you win some you lose. Unfortunately a lot of the technologies associated with the
new strategy cannot be implemented straightaway because the organization’s current
161
regulatory requirements have overtaken the implementation of the architecture (A7).
The architects are also pragmatic in their approach and whilst they seek to promote certain
architectural goals such as shared platforms, they also recognize that these goals may not be
possible or desirable for all businesses.
The portfolio of businesses that I look after is diverse: Finance, Risk, Treasury, Business
Services, Technology, Financial Crime, Human Resources, Marketing, Communications,
Group Governance and Legal. There are ten different strategies and with some
businesses you have to have some stand-alone systems (A9).
6.3.6 Sharing Tools and Knowledge with Technology Staff
The architects at Bank2 were aware that some of the tools and knowledge they developed in
the course of selecting the required technology components and developing the
implementation plans were also relevant to EAI and non-EAI projects. When I asked A7 if
the architects shared their tools with other people outside of the architecture team, he made
special reference to the “application master” which catalogued all of the applications in use at
Bank2 and identified which applications were strategic (i.e. to be retained) and which
applications would be retired. He commented that the architects developed the application
master and that technology project teams used the information in that tool to help them plan
their hardware and software solutions.
We are sharing our templates and tools. Many project staff working in projects use our
application master. We have defined the status of all applications: is it strategic, is it
tactical or is it to be decommissioned? We have also developed a schedule of technology
projects for the applications that will be decommissioned and project staff use that as the
gospel. They use it every day. We also have completed software and hardware plans for
the individual divisions and project teams make use of those as well (A7).
Though the data indicates that the architects did not specifically reflect on the fact that tools
such as the application master facilitated the exchange of knowledge between them and
162
technology staff, they were nonetheless aware of the effect of such tools in making life easier
for technology staff.
Some architects reflected on the alternative course of action: to not share their technology and
implementation plans with technology staff and the negative effect this would have on
relations with technology staff.
If we were to prevent technology people from having access to the application master or the
technology plans – then what's the point of doing them? That’s a policeman attitude and
that just creates trouble (A7).
This suggests that the architects were aware of the importance of sharing their tools and
knowledge with technology staff as a means of building and maintaining relationships with
them.
6.4 Practice Work in the Architecture Team
Like the architects at Bank1, the architects at Bank2 emphasized the importance of complying
with team practices. However, unlike Bank1 where the practices architects are expected to
comply with support interactions within the architecture team, at Bank2, team practices direct
architects to interact with business and technology staff.
6.4.1 Complying with the Team’s Practices
The architects at Bank2 are expected to comply with the methods and tools of the architecture
team. A point made by some architects was that the adoption of common document
templates gave legitimacy to the practices of the architects and reinforced their sense of
belonging to an architecture practice.
So we have now developed standard ways of conveying the implementation plans, business
strategy plans, and technology investment plans. We now have a library of common tools
that we use. If we’re not using the same tools, it looks a bit odd and ad hoc. As a
163
practice, we need to be using the same tools (A9).
Compliance with document templates and team practices was viewed very seriously in the
architecture team. A7 said that he had “moved-on” (i.e. dismissed) architects who were not
willing to adopt the documentation templates of the architecture team. Comments by A7
indicate that previously the practices of the architects had been somewhat haphazard and that
through compliance with team practices he had seen an improvement in architecture
outcomes.
Two years ago, the architecture function was not as effective as it could be. In terms of
implementation planning, some businesses were simply not included in the architecture.
We are achieving a better architecture outcome now as a result of architects following a
standard method for engaging with the different businesses (A7).
6.4.2 Promoting Shared Understanding
Whereas the architects at Bank1 used weekly team meetings to promote a shared
understanding on matters of importance to the team, the architects at Bank2 relied on the
internal management structure of the team and also on on-line tools. The architects met
infrequently as a team, sometimes only three to four times a year on an as-needs basis,
according to A7. However, A7, who is the Head of the architecture team met weekly with his
senior architects. In those meetings, various matters of importance to the team are discussed
including changes to documentation templates, management and administration processes, the
progress of current projects and planning for imminent projects. Decisions or changes arising
from those meetings were communicated to the rest of the team via the management
reporting lines within the architecture team.
The architects also used online tools to share and discuss architectural modeling approaches
and methods during the development of the EA. These tools included modeling templates,
documentation templates, template libraries and were accessible to all members of the
architecture team. A7 highlighted the tool “Planning IT”, an online portal, as one of the most
important and frequently used tools within the architecture team.
164
If you're working in the customer domain and you’ve got a question, issue or whatever,
you can find out who to speak to within the architecture team. We’ve implemented what
we call “Planning IT”. Everyone can access that (A7).
Some architects reflected on areas where an improved shared understanding amongst them is
required. A8 wanted to promote greater use of the business strategy planning template
amongst architecture teams outside of Australia. A9 wanted to give greater attention to the
importance of “soft skills” in managing business and technology stakeholders.
Some people are good at managing stakeholders and some people are not. I don’t know
whether it’s a black art, but it’s certainly a personal talent that you either have or you
don’t. We should be trying to be more consistent in how we manage and interact with
stakeholders (A9).
Though the architects wanted to promote common understandings in matters of importance
to the team, differences in understanding within and outside of the team were also seen to be
healthy and to lead to better solutions.
People have different ideas about how to solve a problem, but that is always good. We
bounce ideas off technology and project people to come up with a workable solution (A7).
6.4.3 Practices that Contribute to Learning
The architects relied on formal and informal learning opportunities to acquire the technical
skills needed in their EAI work. If architects wanted to pursue formal tertiary studies in
business, they were supported financially. A8 commented that she had done an MBA in order
to understand “how a bank operates as a business and the capabilities it needs”. The architects did not
undertake formal architecture training such as training in a particular framework like the
TOGAF since these frameworks were seen as generic and not providing a relevant banking
industry perspective.
TOGAF is still very system oriented and inward looking. It does not consider the
165
market-to-business-to-customer relationship. We need to take an industry perspective
(A8).
The professional development of architects occurred on the job through the interactions
between architects and also between architects and their stakeholders. The architecture team
was dispersed across a number of buildings and architects highlighted the importance of email
and phone to facilitate knowledge sharing.
If I need to talk to ‘X’ about a particular problem, I can easily pick up the phone. We
all have phones. I can also email, but it’s much easier to call (A9).
Architects are situated in the business divisions as this facilitates informal interaction with
business staff and learning. Whilst A8 appreciated that having the architecture team physically
co-located in one area would facilitate knowledge sharing within the team, he said the priority
of the architects was to be physically close to and “learn from” the business.
We are forced to continually re-evaluate the technology selection and implementation plans
because the regulatory and financial environment is changing continually. The
organization is evolving all the time and we have to adapt. To be more effective and
successful we have to be at the table with the business (A9).
In general, architects did not see the dispersion of the architecture team as a factor that
prevented learning. However, they did note that not sharing the same office space affected
their sense of belonging to the architecture team and some architects at times felt like they
belonged more in the business than in the architecture team.
There is a clear indication that the architects are aware of gaps in the overall skills of the team.
However, these are not technical or technological, but are skills associated with the
interpersonal and liaising aspects of their work.
As a group, we could be more competent in the area of managing stakeholders. Anyone
can produce technology plans. But the interpersonal aspects of EAI, the ability to
influence, communicate and align the different perspectives of people, these are much
166
harder to learn (A9).
6.4.4 Nature of Work – Engage/ Dis-engage
The nature of the architect’s work at Bank2 is to interact with other architects and business
and technology stakeholders on an as-needs basis. Architects are organized according to a
particular business division or ‘global’ technology capability (e.g. customer data management,
transaction management, etc.) and work in the architecture team is allocated accordingly.
Depending on the objectives of their designated tasks, architects may liaise with other
architects or with business or technology staff. Architects tended to only engage with others
(generally in one-to-one or small group arrangements) in order to complete a particular task
and then once the objectives of that task were satisfied, they disengaged from their interaction
and transitioned to a new task. For example, A8 attended monthly ‘account’ meetings with
senior business and technology executives associated with a particular business division. The
purpose of these meetings was to discuss and report on the progress of current EAI projects,
changing business priorities, emerging organizational and external constraints, as well as other
EAI matters important to that division.
We have monthly meetings with the business and technology and we discuss architecture
projects that are underway, plus projects that we are planning. These ‘account’ meetings
are our main link into what the business and technology are thinking and an opportunity
for the business and technology to understand what we are thinking. Once they are
completed, I discuss any changes to the business plans with the architects in the team
aligned to that business (A8).
6.4.5 Perspectives on EAI Methodology and Tools
The architects developed their own bespoke EAI method, documentation templates and tools
to support the selection of the hardware and software components and the implementation of
those components. A8 described the method for selecting technology products as “essentially a
business-technology gap-analysis”. The architects worked closely with business and technology
167
stakeholders in defining the business products, services and processes to support the new
strategy and the required systems to enable those products, services and processes. The
approach the architects adopted to identify the required systems included a number of
different, but standardized documentation templates based on strategic planning tools such as
Porter’s Five Forces (1980) and Value Chain (1980) models. The architects used these tools to
understand the competitive and cost benefits associated with particular platforms. A8 said
that these tools were adopted deliberately since they are more familiar to business staff and
more accessible than the technically oriented modeling methods.
UML and wiring diagrams – no one in the business understands them (A8).
Some architects found the documentation templates difficult to apply in their work. A9, who
worked with corporate functions such as finance and human resources commented that he
found the technology selection tools difficult to use because they were not easily adapted to
business units that did not operate as commercial businesses (i.e. as profit centers). Rather
than try to re-conceptualize the activities of these corporate functions (which run as cost
centers) so that they corresponded to profit centers, he made changes to the documentation
templates, with the consent of the Head of the architecture team, A7.
The retail business is organized around a single commercial market and the boundaries
between the retail business and other businesses is a lot clearer since they operate in
different markets. Therefore, it’s easier to use Porter’s tools because you are dealing with
businesses that compete in their respective markets. In my area, it's a collection of ten
separate corporate functions and they have different requirements based on the services
they provide to the organization. So I have had to make changes to the templates to
reflect the fact that competitive advantage is not an important consideration for the
corporate center businesses I look after. The team leader understands and is ok with the
changes (A9).
There was also an understanding that tools developed to assist in the selection of software and
hardware products associated with the EAI would also be made available to technology staff
168
to assist with their technology projects (non-EAI projects).
Project managers have always had their project management tools. But the application
master brings together relevant project and architecture information. You can look at
applications from a project lens and look at them from an architecture lens. And everyone
can share that information (A7).
6.5 Framing EAI Work – Business and Technology Staff’s Perspective
6.5.1 Defining the Technology Strategy
A view that was frequently expressed by business and technology participants at Bank2 was
that the purpose of the architects’ work was to define the technology components and
programs of work that would deliver the technology strategy.
The architects set the technology strategy and the technology direction of where the
organization is going. We know what systems and projects are coming and we know
when we need to implement them and the business value that is being delivered (T5).
Like their counterparts in Bank1, the architects at Bank2 were expected to liaise with the
senior executives from the business divisions since these people would ultimately fund the
new systems and the programs of work to implement them. BU5, who is the CEO of an
online subsidiary of Bank2, commented that the architects also needed to build support for
the EAI with other executives including the Chief Financial Officer (CFO) and Head of Risk.
In selecting the new software and hardware, the architects were expected to take a strategic
and industry competition perspective and also to consider the potential application of new
approaches of application service delivery such as Platform as a Service (PaaS) and the Cloud.
BU5 said that the architects needed to consider these technologies since they presented new
opportunities for engaging with customers. He commented that the online banking industry
was going through a transformation in terms of how products and services are provided to
169
customers and that customers were getting their service and product expectations from
companies like Google, Yahoo, eBay, Amazon and Apple who were able to release new and
“value-adding” applications quickly.
A perfect example, Google Plus launched about six-to-nine months ago. Someone
penciled in the launch date that happened to be a Friday. The Google marketers
cancelled the launch because nobody launches anything on a Friday, it’s always a
Monday. The Google engineers said, “Brilliant that gives us three more days to write
code”. If we are going to partner with organizations like Google, we have to be adaptable
like that (BU5).
BU5 referred to the “digital ecosystem” and that online banks would have to collaborate with
other organizations such as Google, Yahoo and Facebook, if they were to survive. He
expected the architects to select systems that would make the technology portfolio of the
online bank capable of replicating the change patterns and methods of digital companies like
Google. If the architects were able to demonstrate how their proposed systems could satisfy
this requirement, then he would fund them. He added, that the architects also had to justify
their choice of technology components and delivery approaches on a cost and benefit basis.
Participants ascribed several key objectives to the selection of new systems including replacing
legacy systems, reducing the operational costs of the technology portfolio and introducing new
methods of application service delivery such as the Cloud.
Application re-use is fundamentally the way to go. Architects have to do good designs,
but they must also consider the significant costs associated with the technology portfolio.
You can reduce costs by re-use and adoption of the cloud-based approaches to application
delivery. (T6).
6.5.2 Promoting Agility
Business participants expected the architects to build a technology portfolio that would allow
individual business divisions to pursue market opportunities as they emerged. They showed
170
considerable understanding of different architecture approaches (including service oriented
architecture) and were able to conceptualize how the architecture of the technology portfolio
could be structured to enable more agile operations.
We should operate like digital organizations, such as Google, be continually changing
and innovating. We can’t have a one-size-fits-all approach to change for the entire
portfolio. The SDLC approach is just too slow. Service oriented architecture enables us
to have a different change model for different parts of the stack [technology portfolio]
(BU5).
BU5 wanted the architects to select technology components that could be easily added to or
removed from the technology portfolio without too many side effects. BU6 expected the
architects to adopt ‘modular’ architectural approaches to support the potential need of the
businesses to quickly create new interfaces between systems in order to exchange data and
integrate business processes.
The architects are accountable for simplifying the technology portfolio, making sure that
we use common platforms where possible and that we can, as required, share data and
integrate processes across the organization (BU6).
In discussing how the architects were expected to enable the organization to respond quickly
to emerging opportunities, business participants showed they were not passive observers in
the selection of technology components and held expectations about the types of architectural
approaches adopted by architects and the architectural benefits associated with the technology
components selected by the architects.
6.5.3 Engaging on an As-Needs Basis
Business and technology staff did not expect to have an on-going and continuous engagement
with the architects, but wanted to be able to engage with the architects, as required on an as-
needs basis. Technology participants indicated that they needed to engage with the architects
for a particular purpose such as to discuss the implications of the EAI for a particular project
171
they were working on or when changes were required to the implementation plans. If a
business wanted to pursue an emerging market opportunity, technology staff wanted to be
able engage with architects to prepare alternative technology solutions, depending on the
requirements of the business.
If the business wanted to pursue a project, then the architecture must change. We would
work with the architects to frame the technology options, cost them out and make a
recommendation (T5).
Business participants also expected to engage with the architects as required. BU6 commented
that he needed to be able to engage with the architects frequently on a range of different
matters in relation to the EAI program he was involved with. Architects were not only
expected to deal with matters related to the selection of the technology components and their
implementation, but asked to bring their architectural expertise to bear in multiple areas, as
required. For example, BU6 commented that the architects were expected to work with the
program director of the EAI program he was involved with to establish a project governance
framework and assist with assigning accountabilities associated with that framework.
Architects were also expected to oversee testing activities associated with some systems and
once these activities were completed they were expected to be involved in other tasks. BU6
commented that although architects engaged with different program staff on a formal basis,
they were also expected to be accessible on an as-needs basis.
6.5.4 Building Support for the EAI
Business and technology participants viewed building support for and commitment to fund
the selected systems and programs of technology projects associated with the EAI as a key
responsibility of the architects. They reflected on how the architects had been successful in
this by building support and commitment one business division at a time.
Each business division has its own implementation plan. The architects didn’t deal with
the organization as a whole. It would be problematic dealing with that many egos
172
(BU5).
You have to be practical; getting buy-in from executives at the enterprise level is difficult.
It’s a very opinionated environment (T5).
The architects’ success was also attributed to their commercially practical and flexible
approach. Business participants prioritized the commercial needs of the organization over the
EAI and expected the architects to do likewise. Business participants commented that the
priorities of businesses may change unexpectedly and that businesses needed to pursue market
opportunities or respond to external challenges as they arose, even during the course of the
EAI. BU6 commented on the willingness of the architects to accommodate the changing
priorities of the businesses.
We can’t adopt a one-size-fits-all implementation framework for the architecture
program. We need to bring in a broad approach that can be tweaked and adapted to
achieve the outcomes that we want because requirements change. That is what is
happening and it’s what I've observed (BU6).
In the case of EAI projects that were underway, the architects were expected to accommodate
changes to the business’s requirements and also provide on-going consulting-type services to
projects. This latter expectation was considered important to business participants since they
still wanted to have access to the architects to discuss emerging ideas and challenges associated
with particular projects. BU6 commented that his requirements had changed as a result of
new information needs coming to light and unexpected constraints within the to-be deployed
system. These changes required new interfaces with systems previously out of project scope
and that the architects were critical in helping to work through the problems of creating the
new interfaces and data feeds.
Comments about the need for the architects to prioritize the commercial requirements of the
business over the EAI suggest that business and technology staff did not view the technology
selection and implementation plans as a one off occurrence. This approach contrasts with the
approach taken by the architects at Bank1, who sought to impose the selected technology
173
components primarily through the Architecture Review Board. The approach of the architects
at Bank1 led to significant conflict between the architects, business and technology staff. In
contrast, there were no references to any conflict with business and technology staff in the
comments of participants at Bank2 and it may be argued that this is due to the willingness of
the architects to accommodate the changing priorities and requirements of the business and
involve and consult with technology staff when selecting the new systems.
6.6 Interactions with Business and Technology Staff
In this section, I discuss the interactions between the architects, business and technology staff.
Comments made by business and technology participants about their interactions with the
architects focus on the efforts that the architects made to build effective working relationships
and how this in turn helped to build support for and commitment to the fund the new systems
and programs of technology projects associated with the EAI. In general, comments from
business and technology participants indicate a very positive working relationship with the
architects.
6.6.1 Dealing Collaboratively with Business and Technology Staff
Interviewees described the architects as building collaborative relationships with business and
technology staff. T5 said that the architects worked equally effectively with business and
technology staff.
The architects are able to work with business and technology people, equally well.
Working with business or technology people has not been a problem for them (T5).
The relationship between the architects, business and technology staff was generally
collaborative. Business and technology interviewees noted that the architects were prepared to
incorporate into their planning the concerns and views of business and technology staff and
were prepared to make changes to the selected software and hardware components as business
priorities changed or new market opportunities emerged. Evidence also indicates that the
174
architects were supportive of business initiatives and rather than try to block them, they defer
to and are supportive of the business. T6 commented that this approach was helpful in
building support for and commitment to the new systems.
It’s a collaborative relationship. The business and technology are making sure they align
to the architecture. If the business needs to make changes to the programs of work, they
will put those changes forward to the architects and discuss them. If a proposed change
doesn’t align with the overall direction of the architecture, the architects with help from
technology staff will put forward alternative solutions. The solutions are discussed by the
architects, business and technology staff and a preferred solution is agreed. (T6).
The architects are more involved with the business and meet with them regularly.
Previously, the architects were pointy headed, propeller heads, but now they are in touch
with the business, they are aware of the business’s direction, what the market is doing,
what the banking industry is doing and they speak the same language as the business.
The architects have a very close and open relationship with the business (T5).
6.6.2 Liaising and Negotiating
Participants commented positively on how the architects liaised with business and technology
staff when selecting the new systems. Whereas, at Bank 1 there was very little interaction
between the architects, business and technology staff during the selection of the new systems,
the approach of the architects at Bank2 was quite the opposite. They liaised with various
people at different levels within the business and technology.
Certainly, one of the challenges of planning the technology selection is making sure
everybody is agreed on what we’re buying. The architects have engaged with the security
architects, data architects, the infrastructure architects, and they’re engaged with people
from the business. They also have on-going engagement with technology projects to ensure
that those projects are aligned to the selected products and implementation plans. I’m
responsible for project delivery in division ‘A’ and I’m constantly talking to the architects
175
(T5).
Business and technology participants were appreciative of the efforts the architects made to
help businesses pursue their own technology projects. Rather than seek to stop the business
from pursuing a market opportunity, the architects discussed the motivation for the project
with the business sponsor and then worked with different technology staff to identify
technology products that would meet the requirements of the business. Depending on the
nature and scope of the proposed project, the architects might interact with various
technology specialists including infrastructure, security, network and operations specialists. In
their discussions with these people, the architects investigated different technology solutions,
negotiating their relative pros and cons and discussing their appropriateness in light of the EA.
After agreeing on the potential technology solutions, the architects with technology staff
discussed the proposed new systems with the business sponsor.
Working with the architects, we will frame the technology options, cost them out, decide on
a preferred solution and together with the architects we will go back to business and
discuss the different solution options. It really comes down to an agreement between the
architect, business and technology staff about what we are going to do (T5).
6.6.3 Communicating
Comments from participants indicated that they were appreciative of the efforts the architects
made to meet with business and technology staff and share information about the new
systems and their implementation. Business and technology staff were able to interact with
architects in a range of informal and formal contexts. Participants mentioned that the
architects made it possible for people to access information about the new systems, platforms,
or a particular program of work by holding informal lunchtime forums called “Brown Bag
Meetings”, which were open to all interested staff at Bank2. Comments indicated that these
forums were well attended (ranging from twenty up to approximately sixty people, according
to T4) and people were able to ask questions about the new system and the program of work.
176
The Brown Bag Meetings are meant to inform people about an upcoming program of
work and are informal affairs open to all staff. They usually begin with a presentation
about the program, its structure, program structure, vendors, technology components,
expected business benefits and impact to business operations. People are able to ask
questions about anything in relation to the program and there’s usually a discussion – it’s
not a one-way information push (T6).
The architects also used these lunchtime forums to announce forthcoming programs of work
and comments from participants indicated that people found these announcements helpful in
understanding the to-be deployed system, the duration of the program, its organizational
structure, key staff and whether there were any employment opportunities in the program.
Participants also mentioned impromptu ‘spur of the moment’ conversations between
themselves and the architects. Participants described the architects as approachable and that
staff were able to participate in so-called ‘water-fountain’ and ‘corridor conversations’ with the
architects. T5 commented that on several occasions he had been able to approach individual
members of the architecture team to discuss a particular concern or get clarification about a
particular matter and this method of communication was timely and satisfied his need for
immediate information.
I might cross paths with an architect when walking to a meeting or waiting for the lift.
It’s easy to ask them a question about a particular program and being able to have those
quick discussions makes our job much easier. We’re not waiting for an email response or
leaving a voicemail (T5).
When I asked participants about their communication with the architects, they spoke mainly
about face-to-face and the telephone communication. Email was hardly mentioned at all and
this suggests that the positive comments that interviewees made about their communication
with the architects were influenced by the opportunities for direct communication with the
architects.
177
6.6.4 Building Common Tools
The architects with the involvement of business and technology staff conjointly developed
many of the tools including documentation templates used in the selection of technology
components and implementation planning. The architects and technology staff co-developed
several documentation templates including spreadsheets, used for various tasks related to the
EAI, including cataloguing the existing application portfolio and mapping the strategic
objectives and desired capabilities of the business to prospective new systems. These tools
enabled the architects and technology staff for example, to share their knowledge and adopt an
agreed approach and solution to a particular problem.
The architects sit down with the business to understand their required business and
process capabilities. They then work with technology to understand the capability of the
existing technology portfolio. Both the architects and technology are guided by what the
business want to see and they tailor the technology around that (T6).
Business and technology participants commented on how the development of these tools
fostered a collaborative relationship between the architects, business and technology staff. In
particular, they reflected on how collaborating on one task could ‘snowball’ into collaborations
in other activities, suggesting that the tools developed in the course of the EAI helped foster
an on-going collaboration between the architects, business and technology.
We not only developed the strategic business plan together, selected the technology
components and the implementation plans, but we also defined and agreed the project
metrics and the reporting deliverables (BU6).
There was a strong sense of appreciation in the comments of some business participants that
the tools developed co-jointly between the architects and technology staff made life easier for
technology staff.
We worked with the architects to build the application inventory and define what the
inventory looked like in terms of its layout. There’s been some good work to document
178
the application landscape and that work has enabled project staff to understand how their
project is impacting system ‘x’ and what the strategy is for that system. It has really
made a significant difference to those staff (T6).
6.7 Summary
In conclusion, the architects’ perceptions of the nature of their EAI role emphasize the
selection of software and hardware components and also the liaising aspects of their work.
The architects commented on the importance of their influencing role and how they
consciously adapted their language and tools when dealing with business staff. They
emphasized the importance of talking the same language as the business and framing the
selection of software and hardware components in terms that are meaningful to business staff.
They emphasized the importance of being flexible and adopting a collaborative approach. The
architects defer to the market opportunities and operational needs of the business and accept
that the selection of the technology components and planning for the implementation of those
components are not one-off occurrences and must change to support the changing needs of
the business.
In their practices the architects make considerable efforts to enable business and technology
staff to participate in the selection of technology products, as well as the development of tools
associated with the EAI. Documentation templates were co-developed with business staff and
architecture tools such as the application inventory tool were co-developed with technology
staff. The information contained in these tools was shared with technology staff and the
architects viewed this as helping technology staff in their work. The architects viewed their
engagement with business and technology staff as important since they were able to discuss
and understand what was important to the business and technology. The architects also
viewed the co-development of templates associated with the selection of hardware and
software components as important to the exchange of knowledge between themselves and
business staff.
It is also evident that stakeholders expected the architects to liaise closely with business and
179
technology staff, adopt a commercially practical approach, and build support for the new
systems gradually business-by-business. Interviewees also expected the architects to prioritize
the commercial needs of the business divisions over the new systems and defer the
implementation of those new systems when business circumstances changed.
Interviews with business and technology participants highlight the positive working
relationship between the architects, business and technology staff. Comments by business and
technology participants about their interaction with the architects highlighted the efforts made
by the architects to build positive and effective working relationships. The architects made
changes to their selected systems and implementation plans in order to accommodate
changing business priorities and this helped build a collaborative relationship with the
business. The architects developed an application inventory to help them categorize the
applications in the Bank2 environment and shared that tool (and others) with technology staff.
It appears that the collaborative approach that the architects adopted had a positive effect on
business’s support for and commitment to fund the new systems and their implementation.
6.8 Reflection on Case 2
In contrast to the architects at Bank1, the architects at Bank2 enjoyed positive relations with
business and technology stakeholders. This seems to warrant an explanation as to the possible
reasons why the architects at Bank1 and Bank2 had different relations with their business and
technology stakeholders given that in both organizations the architects were experienced and
highly skilled. Though a detailed examination of the practices of the architects in both
organizations is provided in the cross-case analysis, this reflection will address the possible
reasons for the different relationships between the architects and business and technology
stakeholders in both organizations.
One possible explanation for the different relationships between architects and their
stakeholders in both organizations were the different expectations of the Heads of
architecture. The actions of the architects in both organizations were driven by the
expectations of the Heads of the architecture teams. The Head of architecture at Bank1
180
wanted to control the flow of information from the architecture team and the level of
interaction between the architects and their business and technology stakeholders. The
architects at Bank1 communicated with business and technology stakeholders via a wiki and
were not allowed to discuss the selection of the technology components with them. On the
other hand, the Head of architecture at Bank2 expected the architects to engage frequently
with their stakeholders. As well the formal opportunities for interaction through account
meetings, feedback surveys and lunchtime forums, the architects were encouraged to build
relationships with their stakeholders. Architects, business and technology stakeholders
commented about their informal ‘corridor’ and ‘water fountain’ conversations and how these
interactions allowed each party to address concerns in a timely manner.
The influence of the Heads of the architecture teams in setting the behavior parameters of the
architects in their respective organizations, suggests that power relations within the
architecture teams were an important factor. Both Heads of architecture were able to specify
the expected behaviors of the architects because of their management control over them.
Whilst the Head of architecture was quite direct in stating his expectations and the
consequences for non-compliance, the Head of architecture at Bank2 was less direct, but
nonetheless just as determined in making sure the architects built effective relationships with
their stakeholders. As described earlier, the Head of architecture at Bank2 had previously
dismissed an architect who was unable to build effective relationships with stakeholders.
181
Chapter 7
7 CROSS-CASE ANALYSIS
7.1 Introduction
In chapters five and six, I treated each case as a separate unit of analysis and presented the
results of the within-case analysis. In this chapter, the analytical focus is a comparison of the
two cases. My aim is to elucidate the critical similarities and differences between the cases in
order to understand the roles and practices of architects that inhibit and encourage
connections with people who have a legitimate interest in an EAI. The themes:
• Framing EAI work – architects’ perspective,
• Practice work in the architecture team,
• Framing EAI work - business and technology staffs’ perspective, and
• Interaction with business and technology staff,
are used in the cross-case analysis. By using a cross-case analysis, I will develop analytical
conclusions answering the two research questions: 1) What insights into the relationship between the
EAI practices of architects and the outcomes of EAI initiatives are possible using the theoretical lenses of CoP
and BSBO theory? 2) What new theoretical insight beyond that provided by CoP and BSBO theory is
possible using grounded theory?
182
7.2 Theme 1: Framing EAI Work – Architect’s Perspective
The cross-case analysis for Theme 1 is summarized in Table 7.1. The purpose of the table is
to map the emphases of the theoretical categories of the first theme: Framing EAI Work –
Architect’s Perspective. Blank cells indicate that a particular theoretical category did not emerge in
the data analysis.
In both cases, the architects adopted two roles during the EAI: a technology selection and
implementation role and a governance role. Architects viewed the selection of new systems
and development of implementation plans for those systems as their primary architectural
deliverable during the EAI. They also saw themselves as responsible for the governance of
the technology portfolio (Bank1) and not responsible for the delivery of the new systems. The
architects viewed the business and technology as responsible for delivering the new systems
into operation and saw themselves as being involved in those programs of work in either a
governance role (Bank1) or in an advisory role (Bank2).
The architects’ conceptualization of their EAI role demonstrates a contrast in EAI approach.
In selecting the new systems, the architects focused their efforts internally within the
architecture team, completing the required technical architecture artifacts and liaising with
other architects (Bank1). They developed their own decision-making framework for selecting
applications and in deriving their evaluation criteria, they focused on what they thought was
important from an architectural perspective more than from a business or technology
perspective (Bank1). Architects also worked closely with business and technology staff to
produce a business strategy plan that situated the new systems in a business context, linking
them with the strategic objectives of the individual business divisions, their various products,
services and business processes (Bank2). When selecting the new systems, the architects also
worked closely with technology staff to understand the constraints of the existing technology
portfolio and to ensure that the selected software and hardware was appropriate. This
approach, which is based around a discussion and negotiation of what is important to
architects, business and technology stakeholders, is viewed as critical to building support for
and commitment to fund the new systems as it is seen to bring architects closer to business
and technology staff (Bank2).
183
Architects who were more concerned with architectural goals when selecting new systems
adopted inward looking and technically focused objectives (Bank1). They used architectural
goals as the basis for evaluating new systems and whilst these goals reflected legitimate
requirements, they appeared to prioritize the architects’ requirements over the business’s
requirements by virtue of the fact that the business was not consulted during this phase
(Bank1). Architects also gave greater attention to how the implementation of the new systems
could be executed according to their specifications (Bank1). Here, the objective of architects
was to make the implementation of the new systems a governance matter rather than
something to be negotiated and discussed with business stakeholders. It appears that
implementation practices, which were technically oriented and did not involve the
participation of stakeholders, had a greater dependency on management control approaches to
achieve their desired objectives (Bank1).
Approaches to EAI that sought to build and maintain effective working relationships with
business and technology staff included efforts to support the commercial priorities of the
business and promote effective relationships with business staff (Bank2). Communication
tools such as on-line feedback surveys allowed business and technology staff to voice their
criticisms of the architects’ practices and led to face-to-face discussion to understand and
resolve those concerns. These tools helped architects to surface emerging problems and
maintain relationships with staff. Relationships between architects, business and technology
staff were also based on practical considerations and architects who maintained effective
relationships with business staff were able to learn what was important to business
stakeholders. This involved architects tapping into the political networks of the organization
and liaising with business and technology staff about current projects and emerging concerns
(Bank2).
Architects who sought to achieve a desired EAI outcome through governance measures
adopted practices focused on controlling the behavior of stakeholders rather than building
consensus with them (Bank1). Practices focused more on controlling the behavior of business
and technology staff than sharing information and engaging with them led to conflict between
the architects, business and technology staff. Such practices resulted in the business selecting
184
new systems themselves and ultimately, the failure of the EAI (Bank1). Furthermore,
practices that prioritized the stability of the technology portfolio over the business’s need to
pursue emergent opportunities were also a source of tension (Bank1). It appears that
practices, which prioritized controlling the behavior and technology choices of the business,
made it very difficult to build an effective relationship with them.
Practices inclusive of business and technology stakeholders led to good relations with them
(Bank2). Architects who tailored their language to the ‘worlds’ of business and technology
stakeholders reflected on the potential of language to be inclusive and also to exclude (Bank2).
They made efforts to accommodate the need of the business to respond to changed market
conditions and opportunities such as making changes to the technology components and
implementation plans as the priorities of the business change (Bank2). They also shared EAI
planning tools and documentation with business and technology staff to help them in their
project work.
Based on the above, it seems from the practices of the architects that building on-going
relationships with people who are able to fund the new systems and their implementation
requires a different mindset from the technology selection and implementation role and
requires a relationship management focus. This has implications for how architecture teams
are structured. For example, architecture teams may include architects who have architectural
expertise in particular areas such as data and information, security, and infrastructure and
architects whose role is to manage relationships with and provide on-going support to
business stakeholders. Adopting a relationship management focus may have implications for
recruiting, training, and placement of architects. For example, architects interested in working
on architecture related tasks might be interested in tasks of a shorter duration and may not be
appropriate for being placed in longer-term relationship management roles. Furthermore, an
architectural task such as mapping business and architectural requirements to commercially
available technology products may not be appropriate for architects in relationship
management roles. Likewise, architects in relationship management roles may adopt practices
and tools appropriate for business strategy planning, but may not be appropriate for more
technically oriented architecture tasks. Metrics that are applied to architects in an architecture
185
role may not be appropriate for architects in a relationship management role. The label of
‘relationship managers’ and the practice of providing on-going support to business
stakeholders may also contribute to a lack of clarity about the role of relationship management
architects.
186
Theme 1: Framing EAI Work – Architect’s Perspective
Theoretical Category Bank1 Bank2
Selecting the New Systems and Defining the Implementation Plans
The key outputs of the EAI are the selection of the new systems to deliver the new organizational strategy and plans for the implementation of those new systems
New systems are selected for each business division and implementation plans are organized accordingly
The selection of the new systems and development of the implementation plans for those systems are the products of internal architecture team activities and processes rather than engagement with business and technology staff. Business and technology staff are not involved
Architects also liaise with vendors to map required technology functionality to available commercially available hardware and software products
The selection of new systems is framed by strategic business planning. The architects work closely with business and technology stakeholders to select appropriate hardware and software products and develop the implementation plans to deliver those components into operation
The selection of the new systems is an outcome of effective working relationships with business and technology stakeholders
Focusing on Architectural Goals
Selecting hardware and software components on the basis of architectural goals (e.g. flexibility, scalability,) and not consulting with business or technology staff
Not consulting with either the business or technology to produce the software evaluation model
Not emphasised
187
Architects evaluate application components on the basis of their architectural values and concerns and do not incorporate the values and concerns of business and technology stakeholders into their planning
Building Relationships
Not emphasised Seeing a connection between effective and on-going working relationships with business and technology stakeholders and support for and commitment to fund the new systems and programs of work
Effective relations with business and technology stakeholders are dependent on the value that architects add to the business, the strength of their analysis and track record for meeting project goals
Architects spend up to 50 percent of the working week liaising with business and technology staff
Not Discussing the Execution of the Implementation Plans
Not seeing themselves as responsible for delivering the new technology components into operation
Not discussing and negotiating with business and technology stakeholders who are responsible for funding and delivering the specified technology components into operation
Not building support for and commitment to fund the new systems and their
Not emphasised
188
implementation
Communicating
Not emphasised Facilitating an open dialogue with business and technology staff
Architects create processes that allow business and technology staff to voice their criticisms of their practices
Feedback processes create opportunities for discussion and agreement between architects and the business
Seeking Management Control Over the Implementation Plans
Seeing the business and technology as motivated by different values
Believing that the business and technology will make their own choices and either not acquire the selected new systems or implement them as specified
Not emphasised
Stopping Projects
Stopping all existing and new technology projects in order to keep the technology portfolio stable
Not sharing information about the new systems
Not emphasised
Speaking in Two ‘Languages’
Not emphasised Tailoring language to their audience: using business-speak and technology-speak
Using terms that are meaningful to the business and technology
189
Being Flexible
Not emphasised Being willing to accommodate changes to the selected systems and their implementation plans
Accepting that business priorities change and making efforts to support the business meet emerging priorities
Sharing Tools and Knowledge with Business and Technology Staff
Not emphasised Sharing planning tools with the business and technology staff
Using the co-development of tools and documentation templates to encourage the business and technology to engage in the EAI process
Table 7.1 A Cross-case comparison on theme 1: framing EAI work – architect’s perspective
190
7.3 Theme 2: Practice Work in the Architecture Team
The cross-case analysis for Theme 2 is summarized in Table 7.2.
In both cases, the architects considered compliance with team practices important, but the
motivations to comply varied. Compliance was seen to stem from the values inherent in
the practices of the architects. Architects, regardless of their knowledge and experience,
were required to comply with a formal team charter that prescribed desired behaviors for
email interactions within the team, interactions with business and technology staff and
reinforced the role of the Head of the architecture team as the final decision-maker
(Bank1). Efforts focused on controlling the behavior of architects and standardizing how
they interacted with each other as well as with business and technology staff seemed to
have the potential to reinforce negative work practices and reduce efforts to engage with
business and technology staff (Bank1).
Compliance also stemmed from the value placed on relationships with business and
technology stakeholders and a need to reinforce a relationship focus in the practices of
architects (Bank2). Compliance may not have been overt and expressed in a formal
document like a team charter, but was expressed through the adoption of team tools,
document templates and work styles that reinforced to all architects the importance placed
on maintaining collaborative working relationships with business and technology staff.
Desired practices within the architecture team were an extension of the mandatory use of
documentation templates and other tools that required individual architects to interact
with and capture the views and concerns of business and technology staff in order to
satisfy the content requirements of those templates. Compliance was much more than
rule observance; it required adopting an outwardly focused work style that prioritized
relationships with business and technology staff (Bank2).
Compliance also stemmed from the architects’ need to adopt a common approach in their
work. Architects emphasized the importance of a common understanding around the use
of methods and tools (Bank1 and Bank2). This was necessary because, although they
worked on independent projects related to the selection of technology components, their
work was related to a global technology portfolio and coordinated implementation plan.
Thus, there would be benefits from adopting similar approaches to analysis and
191
documentation tasks.
Although architects had previous architecture experience, there was a need for architects
to adopt common practices. Certification courses in architecture frameworks such as The
Open Group Architecture Framework (TOGAF) were not regarded as relevant (Bank1
and Bank2). No formal internal architecture training was offered to architects.
Learning occurred informally whilst working and was focused on the use of EAI
documentation templates, tools and methods. However, architects had different
perspectives about how learning from each other might be supported. Having the team of
architects share an open plan office space was seen as a way to help the architects to
remain engaged with each other and support learning (Bank1). Team meetings were also
seen as providing opportunities for architects to learn from each other. These functioned
as forums for architects to exchange ideas, experiences, and knowledge with each other
(Bank1). Informal learning could be supported through the use of email and phone, which
allowed architects to stay in contact with one another (Bank2). Opportunities for
architects to communicate with one another were seen as critical to their practices,
especially given their disinterest in formal architecture education and their need to adopt
standardized planning templates, modeling templates, tools and methods.
The physical location of architects was seen to influence informal learning opportunities.
Architects who placed great importance on technical skill development preferred to share
the same physical office space to facilitate interacting with other architects (Bank1).
Architects who placed great importance on their relationships with business and
technology staff preferred to occupy the same office space as business and technology
staff so that they were able to interact with them informally (Bank2). Whilst the allocation
of work was based upon the divisional and organizational capability alignment of the
architect (Bank1 and Bank2), it can be suggested that other criteria could also be
considered, given the preference for informal learning and the potential for architects to
be dispersed across different office locations. For example, architects who needed to be
supported in learning how to use documentation templates and other tools may be better
off placed with other architects who have superior skills and experience in those tools.
Furthermore, the capacity of architects to bridge the language barrier and build strong
working relationships with business staff should be considered when placing architects in
the same physical office space with business staff. This could also give rise to issues of
identity and belonging since architects may begin to identify with the business community
192
they are located with and not the architecture team. However, the evidence presented here
suggests Bank2 was successful and its architects were placed in the business. The bigger
risk appears to be where the architects are placed together as this reinforced the culture of
not consulting stakeholders.
The two cases highlight different emphases in the documentation templates used in EAI
work. When the focus of architects was to describe in technical detail the systems to
support the organizational strategy, there was an emphasis on technical artifacts and the
use of modeling languages such as UML (Bank1). On the other hand, when architects
were focused on describing linkages between the strategic objectives, envisaged products,
services and processes of a business division and the supporting technology architecture,
they used familiar strategic planning models such as the Five Forces and Value Chain
models and modified them to reflect the dual business and technology focus of the
documentation task (Bank2). The use of modeling languages and symbols that have
meaning for the participants involved in a documentation task was seen to be helpful for
enabling people to participate in that task and contribute to the designated outcome in a
meaningful way. For tasks that involved contributions from people who belonged to
different communities and who had different ways of looking at and describing the
‘world’, documentation templates that incorporated familiar symbols and language were
helpful in breaking down cognitive barriers and building familiarity with and support for
the task at hand.
193
Theme 2: Practice Work in the Architecture Team
Theoretical Category Bank1 Bank2
Complying with the Team
Compliance is described as a process of following a team charter of acceptable behaviour
Compliance is acting in a way that does not upset others in the team
Compliance is adopting team tools and document templates
Compliance is adapting to the work style of the team: to liaise with the business and technology
Promoting Shared Understanding
Weekly team meetings in which architects are able to discuss matters of importance to the team as well as their work
Small team interactions
Use of online tools to facilitate communication between architects
Practices that Contribute to Learning
No formal architecture training is offered to architects. Architects have previous experience in architecture roles
Learning is focused on methods and tools used in the selection of technology components and development of implementation plans. Learning takes place whilst working and interacting with other architects
Open planned office and physical collocation of architects facilitates informal learning
Architects are able to undertake formal tertiary education and also have informal opportunities for learning whilst working
Architects are located across a number of office sites. Opportunities for informal learning are via the phone, email or face-to-face meetings
Learning is a matter of being engaged with the ‘other’. Architects are co-located with the business to provide opportunities to participate in discussions with and to understand what matters to the business
194
Nature of Work – Engaging / Disengaging
Work is allocated on the basis of divisional alignment and expertise
Architects generally work on individually assigned tasks although small group work does occur
Architects engage with one another on an as-needs basis for the purpose of learning and providing/ eliciting information. Architects disengage from their interactions with other architects once the objectives of their interaction are satisfied
Perspectives on EAI Methodology and Tools
Using their own bespoke EAI methodology
Viewing frameworks such as the Zachman and TOGAF as not adequate or relevant
Methodology is focused on the production of technical architecture outputs
Architectural modeling templates are highly detailed and some architectural documentation does not seem to have a practical purpose
Methodology and tools are based around engaging with business and technology staff
Documentation templates are developed with a particular purpose in mind: 1) familiarizing business staff with the technology selection and 2) providing project information to technology staff
Table 7.2 A Cross-case comparison on theme 2: practice work in the architecture team
195
7.4 Theme 3: Framing EAI Work – Business and Technology Staff’s Perspective
The cross-case analysis for Theme 3 is summarized in Table 7.3.
In the two cases, business and technology staff expected the architects to specify the systems
and programs of work that would deliver the new organizational strategy. Business divisions
(Bank1 and Bank2) were responsible for funding these systems and the programs of
technology projects. Therefore, it was critical for the architects to build support at the senior
executive levels of the business divisions (Bank1 and Bank2). Architects needed to consider
their approach to building support for the selected systems. One approach is for architects to
build support gradually, one business division at a time (Bank2). Where architects have not
built support for the new systems, the implementation of those systems has been problematic
(Bank1). In cases where there is a need to transform an organizational technology portfolio
reasonably quickly (Bank1), architects may feel pressured to prioritize the selection of new
systems over building support for them. In this situation, architects need to consider the
potential for senior business executives to prioritize their interests over the EAI.
During an EAI, architects were required to be more than technologists, able to frame their
system choices in ways that are familiar to business staff, especially staff in senior management
positions (Bank1 and Bank2). Architects must consider new technologies (e.g. the Cloud,
Platform as a Service, etc.), and be able to explain the business benefits of the selected systems
and what those systems would mean for outsourcing contracts that are still current. They
must also be able to explain how a particular system or systems will provide competitive
advantage and help to differentiate the organization from other organizations in a particular
market. One possible solution (Bank2) was to develop documentation templates that modify
familiar strategic planning models and allow the architects to make connections between
business processes, products and services, and the new systems. Architects must also be able
to assess the organization’s level of desire to transition from the production of the EA plans
to the implementation of those plans as staff may fear the EAI because of possible changes to
their employment (Bank1).
Architects were expected to liaise with a range of different stakeholders across the
organization (Bank1 and Bank2). Consequently, they needed to be able to modify their
196
language so that it was familiar to their stakeholders in different areas and at different levels in
the organization. They also needed to recognize the different perspectives, values and
concerns these stakeholders had in relation to the selected systems and take account of those
perspectives and concerns when making their technology selections. In large organizations
such as the case organizations in this research, many discourses could be in play at any one
time. Business stakeholders may express conflicting or competing requirements and architects
need to be skilled in resolving those issues (Bank1). Architects may find their ideas challenged
by business executives who are knowledgeable and conversant in architectural approaches and
unlikely to be passive participants in the EAI process (Bank2). Architects may have to explain
to technology stakeholders how the new systems address problems with legacy systems as well
as application growth and redundancy. They may also be expected to discuss the implications
of the new systems and their implementation for existing technology projects as well as new
technology projects.
Managing the scope of an EAI is also a potential problem that architects need to consider.
When there is no prima facie process for deciding what is in and out of scope, stakeholders may
develop their own interpretation about what is important. Technology stakeholders may
expect architects to make perfective and corrective change to the technology portfolio
(Bank1). Business executives expected the architects to introduce systems that allowed the
organization to respond quickly to changes in the online world (Bank2). Furthermore,
architects cannot assume that the frame of reference that stakeholders use when determining
what is and what is not important is limited to their role in the organization. Technology
participants showed they were adept at conceptualizing the limitations of the technology
portfolio in terms that are familiar to business people (Bank1). Business people likewise
showed they were adept at discussing architectural approaches.
If the scope of the EAI has not been articulated and agreed with stakeholders, a problem that
architects may face is that stakeholders who have different interests could define the scope of
the EAI differently. Stakeholders may attempt to influence architects to focus on their ‘local’
interests rather than the ‘global’ interests of the organization. In the absence of a
superordinate governance body (i.e. committee, board) that can define what is in and out of
the scope of the EAI, architects may be pressured to address the priorities of organizationally
197
powerful individuals. A failure to control the scope of the EAI may give rise to complexity
growth where demands on the architects increase because of multiple and competing
stakeholder priorities. At the extreme, complexity growth may lead to a situation where
architects are no longer able to focus on the EAI because of the additional demand on their
time and effort. To this end, architects may need to seek the assistance of senior people to
establish formal decision and approval processes and a superordinate governance body such as
a steering group.
There is a need for architects to build support and commitment to fund the EAI at the senior
executive level of the business divisions as they provide funding for an EAI (Bank1 and
Bank2). Whilst technology teams may staff technology projects, the technology function itself
does not fund the new systems or programs of work (Bank1 and Bank2). Organizations may
have formal capital investment review processes (Bank1), but building support for an EAI is
also a political process and architects must gain the support of senior business executives for
the EAI. This is of particular importance for maintaining on-going commitment to the EAI,
since this may take several years to complete (Bank1). Successful approaches to building
commitment for the EAI include building support incrementally, one business at a time
(Bank2) and demonstrating flexibility and a willingness to accommodate the changing
priorities of the business (Bank2).
An interesting difference between the cases was the expectation that architects have an
empathetic understanding of the impact of the EAI on people. An EAI is viewed as an
instrument of organizational change (Bank1) and stakeholders with a high level of involvement
in the EAI such as managers of technology functions may be uncertain about what the
selection of a particular platform means for their ongoing employment and position in the
organization and may feel that their employment or management position is at risk (Bank1).
Stakeholders may have a need for information that clarifies what the EAI means particularly
for them, and as a consequence, they may become emotionally involved in the EAI. If
architects do not consider the potential emotional impact of the EAI on people, especially
people at senior management levels, they may find that the EAI motivates negative responses
and the emergence of trust issues between people.
198
Theme 3: Framing EAI Work – Business and Technology Staff’s Perspective
Theoretical Category Bank1 Bank2
Defining the Technology Strategy
Architects are expected to specify the new systems and programs of work to deliver the technology strategy and enable the organizational strategy
When selecting the new systems, architects must take into consideration the dynamic nature of the online world and consider new methods of application service delivery such as Cloud and Platform as a Service
Considering Outsourcing Arrangements
Architects are expected to understand and explain the implications to existing outsourcing arrangements arising from the new systems and implementation plans
Not emphasised
Addressing Problems with the Technology Portfolio
Technology stakeholders expect the architects to address different and complex problems associated with the technology portfolio
The expectations of stakeholders are not limited to the immediate responsibilities of their organizational role
Not emphasised
Promoting Agility Not emphasised Incorporating different architectural approaches to enable the organization to make changes to the technology portfolio quickly
Business participants are not likely to be passive observers in the selection of technology components and
199
implementation plans
Engaging on an As-Needs Basis
Business and technology staff do not expect to have an on-going and continuous engagement with the architects, but expect to be able to engage with the architects, as required on an as-needs basis
Business and technology participants want to engage with the architects on range of different matters relating to the EAI as well as projects not included in the EAI, but which have a dependency on the EAI
Desired engagements are task specific and once the objectives of the task are completed, business and technology staff expect to disengage from their interaction with the architects
Building Support for the EAI
Being responsible for building support for and commitment to fund the new systems and programs of technology projects
Building support for the new systems means having to explain the benefits of the selected systems in terms that are familiar to stakeholders.
Building support is also a matter of understanding the formal organizational processes though which an organization decides how it will allocate money and resources to technology projects
Building support for the EAI is also a political process that involves gaining the support of people who can influence business executives
Not biting off more than you can chew. Building support for the EAI incrementally one division at a time
Being willing to accommodate the changing priorities of the business
Working with technology to provide alternative solutions that meet business requirements
200
Understanding the Impact of the EAI on People
Recognizing that changes associated with the EAI will arouse safety concerns as people may fear losing management control and potentially their employment
Not emphasised
Table 7.3 A Cross-case comparison on theme 3: framing EAI work – business and technology staff’s perspective
201
7.5 Theme 4: Interactions with Business and Technology Staff
The cross-case analysis of Theme 4 is summarized in Table 7.4.
The practices of the architects differed in terms of their interactions with business and
technology staff. In one case, the architects focused on building collaborative relationships
with business and technology staff and maintained ongoing interaction with them in order
to understand changing business priorities and to support business and technology staff in
understanding the technology components and implementation plans (Bank 2). In the other
case, the architects did not seek to build relationships with technology staff and were viewed
as being reclusive in their practices (Bank1). The architects were unwilling to communicate
and share information about the technology components and implementation plans with
technology staff and did not seem to appreciate the extent to which their actions made life
difficult for technology project teams (Bank1). This suggests that architects need to consider
that there might be persistent issues associated with an EAI, many of which are more
relational in nature than technical. However, given that the stakeholder community associated
with an EAI not only includes business and technology stakeholders, but can also include staff
involved in existing and new technology projects, the reclusive practices of architects could be
a strategy for reducing the scope of the stakeholder community, thereby making it more
manageable. It is difficult to speculate on how effective this type of strategy might be in
constraining the scope of the stakeholder community given that there are other contextual
influences, which are also relevant (e.g. relative skills and influence of the architects). There is
a potential for people involved in existing and new technology projects to simply ignore the
architects and do their ‘own thing’ in relation to the systems they deploy into the environment.
Whilst in the extreme this results in failure of the EAI – this is a ‘boundary’ question. The
point is that architects need to take care in how they seek to make their task ‘manageable’.
There were differences in the architects’ awareness and acceptance of the commercial realities
of the organization in which they worked. Some architects seemed to show little understanding
of the need for the organization to control its costs and continue to make a profit (Bank1).
They prioritized expensive systems over more pragmatic ones which satisficed the requirements
202
of business stakeholders. They also failed to appreciate the impact of the Global Financial
Crisis and that there was less money to allocate to the EAI. In contrast, some architects
understood the commercial reality of the business and the need of the business to pursue
emerging market opportunities or respond to regulatory changes as they arise. Rather than try
to prevent the business from pursuing technology projects, these architects made efforts to
accommodate the changing priorities of the business and together with technology staff, they
proposed alternative systems that satisfied the needs of the business. The willingness of
architects to deviate from the selected systems helped to foster a sense of mutual engagement
with the business, since through their actions the architects demonstrated that they did not
privilege the architecture over the needs of the business, but adopted a practical approach that
was supportive of the needs of the business to manage their costs, make a profit, and respond
to regulatory changes.
The different experiences of the technology and business staff in both cases raises an
interesting point in terms of the assumptions that architects may hold which may impact their
relationship with the business and technology. Given the uncertain and potentially emergent
nature of business requirements, architects must likewise adapt their system preferences and
implementation plans otherwise they will not meet business needs. Making assumptions about
what technology a business may require (on the basis of what is defined in the EA plans alone)
can result in systems that do not meet the requirements of some businesses. It also suggests
that developing an on-going relationship with business staff and more intimate knowledge of
the commercial and regulatory environment of the business may help in this regard.
If architects consider what is important to the business through engaging with them, this may
help them build an ongoing and constructive relationship with the business. This might mean
that architects have to consider their system preferences and implementation plans as fluid and
malleable to the changing priorities of the business. When architects do not consider what is
important to the business, competing priorities may emerge such as the architects’ pursuit of
architectural goals and the business’ requirement for systems that suffice. Architects can
consider different opportunities for interaction between themselves and business and
technology staff. Being open to informal interactions and providing opportunities for two-way
discussion and information sharing may help architects relate to the views and concerns of
203
business and technology staff. A distinct perception about the architects, which emerged from
the data, was that they thought they were doing the right thing (Bank1, Bank2). Consequently,
if architects do not appreciate that the priorities of the business may change, they may not be
able to build ongoing relationships with business stakeholders. Architects must also appreciate
that learning about changes in business priorities occurs during their interactions with business
staff.
Architects may build barriers between themselves, business and technology staff by adopting
reclusive and elitist practices. Technology staff felt that the architects did not acknowledge their
learning and experience and made it difficult for technology staff to participate in the selection
of new systems (Bank1). They were also frustrated that they were unable to call themselves
‘architects’ and that arbitrarily their job descriptions were changed without them having an
opportunity to discuss the matter. Technology staff who viewed themselves as currently
working in an architecture role or who had career aspirations of becoming an architect
expressed anger at this change in their job description (Bank1). Technology participants did
not reflect on the limitations of their architectural knowledge and were confident of their
abilities to work as architects (Bank1). There may be some power and expertise related issues
embedded in the decision to reserve the term ‘architect’ exclusively for the architects
responsible for the EA and its implementation.
204
Theme 4: Interactions with Business and Technology Staff
Theoretical Category Bank1 Bank2
Not Engaging Architects are perceived not to adequately appreciate the extent to which technology staff are dependent on them for information about the new systems and implementation plans
The difficulty technology staff have getting information from the architects is seen to prevent projects from progressing
Architects communicate with technology staff via a wiki
Not emphasised
Dealing Collaboratively with Business and Technology Staff
Not emphasised Building collaborative relationships with business and technology staff
Building a deeper understanding of the business through interaction with them
Recognizing the concerns and views of business and technology staff and being prepared to make changes to the selected systems and implementation plans
Liaising and Negotiating
Not emphasised Building a sense of mutual engagement in the selection of systems and development of implementation plans through efforts to liaise and collaborate with business and technology staff
205
Working with technology staff to develop technology solutions for changing business priorities
Being in an Ivory Tower
Pursuing impractical and idealistic systems, not considering the commercial reality of the organization
Prioritizing the architecture over the need of the organization to manage its costs, especially during the Global Financial Crisis
Not emphasised
Communicating Not emphasised Using formal and informal face-to-face methods to communicate with business and technology staff
Providing formal opportunities for people to ask questions about existing and future programs of work
Being open with people regardless of their position in the organization about the technology components and implementation plans
Behaving as an Elite Not allowing others to use the term ‘architect’ in their job titles
Not considering the emotional and career impact this had on technology staff
Not emphasised
206
Building Common Tools
Not emphasised Working together with business and technology staff to develop documentation templates. Promoting knowledge sharing and building a sense of common purpose
Table 7.4 A Cross-case comparison on theme 4: interactions with business and technology staff
207
7.6 Concluding remarks on the cross-case analysis
To conclude, the findings across the two cases contrast two different approaches to EAI
which maybe characterized as ‘isolationist’ and ‘collaborative’. The challenges associated
with an isolationist approach (Bank1) appear to me more acute than those challenges that arise
from a more collaborative approach (Bank2). One can also infer from the nature of concerns
associated with the isolationist approach that these concerns could arise from differences in
assumptions about the roles and practices of architects. The architects at Bank1 viewed their
EAI role in technical terms and their objectives were to select new systems and develop
implementation plans to deliver those systems into operation. They did not give adequate
consideration to the efforts required to build support for and commitment to fund the new
systems or the programs of work to deliver them, but assumed the business and technology
would execute their plans. The architects at Bank2 similarly viewed their role as selecting new
systems, however, they based their decision making on the strategic business planning
workshops they attended with business staff. The architects at Bank2 worked closely with
business staff to understand their long term and emergent needs and also worked closely with
technology staff when selecting systems to satisfy the changing priorities of the business.
The different approaches can also be linked to a difference in worldview and willingness to
recognize the experience and expertise of others. Architects who adopt a collaborative
approach accept that business priorities may change and are willing to modify their technology
selection and implementation plans, as required. Whilst they may question the motivation of
the business to make change, they factor the motivation and objectives of the business into
their system selection. In order to understand the constraints of the existing environment and
the implications for their decision making, the architects must also liaise with technology staff.
Whilst architects possess deep architecture knowledge across a number of areas, they are
dependent on the experience and expertise of technology staff who have a deeper
understanding of the technology portfolio and how the constraints of the portfolio may
influence system choices.
By accommodating the need of the business to make change and recognizing the experience
208
and expertise of technology staff the architects effectively demonstrated boundary spanning
behavior that allowed them to build relationships and mutual engagement with their
stakeholders. Architects unwilling to accept that the external environment of the business may
change and that the priorities of the business may also change are also unwilling to accept that
the selected technology components and implementation plans must change accordingly.
They view the system selection and implementation plans as one-off occurrences and resist the
efforts of the business and technology to make change. They seek to ‘protect’ the selected
systems and this approach can heighten tension between them and business and technology
staff.
Another characteristic associated with the isolationist and collaborative approaches is the
relative importance given to the concerns and objectives of architects over those of business
and technology staff. Many interviewee comments left me with an impression that the
architects’ prioritization of what matters to them over the requirements of business and
technology staff may have a role to play in some issues. Figure 7.1 illustrates my speculation
on what appears to be the priority given to the architects’ concerns relative to the concerns of
business and technology staff. In Bank1, the architects gave priority to architectural objectives
they considered important when selecting the technology components. They paid little
attention to the concerns and information needs of technology staff and did not engage with
them. The architects were virtually inaccessible to technology staff and gave little
consideration to their concerns, experience and expertise. Whilst evidence indicates that the
architects discussed the selection of technology components and implementation plans with
some senior business executives, the evidence also indicates that the architects prioritized what
they considered important (e.g. architectural objectives, performance goals, etc.) over what was
important to the business (cost versus benefit, manage costs, continue to make a profit, etc.).
At Bank2, there is little in the architects’ comments to suggest that they perceived themselves
to have a higher importance in the EAI than business or technology staff. To the contrary,
many comments from architects, business and technology staff suggest that architects worked
collaboratively with business and technology staff. However, whilst the architects considered
that they were responsible for the production of artifacts such as the business strategic plans
and implementation plans, they deferred to the needs and priorities of the business. When
business priorities changed, the architects and technology staff worked together to develop
209
alternative architectural solutions.
Figure 7.1 Relative importance of participants’ concerns
The tendency of architects to prioritize what is important to them relative to the views and
concerns of business and technology staff helps to make sense of some of the differences
observed across the two cases (see Table 7.5 and Figure 7.2). In Bank1, the architects seemed
to believe they could impose their technology selection and implementation plans on business
and technology staff. They effectively used the ARB to stop projects and prevent the business
divisions from pursuing their own technology projects. The Head of the architecture team
was able to prevent people in technology from using the title ‘architect’ in their job titles and
was also able to prevent technology staff getting access to information about the new systems
and implementation plans except in a controlled way through the portal. The situation in
Bank2 was different. The architects appeared to have influence, and used their influence to
build support for and commitment to fund the systems they selected. They adopted a
commercially pragmatic and collaborative approach and instead of making themselves
inaccessible to business and technology staff, the architects did exactly the opposite. They co-
developed and used strategic planning tools with business and technology staff, exchanged
knowledge and shared information with them, and recognized and incorporated into their
210
decision making the views and concerns of business and technology staff. They also made
themselves accountable to business and technology staff, responding in person to their
criticisms. In short, the architects at Bank2 showed a strong inclination to reduce the
boundaries between them and business and technology staff.
Case Orientation of the Architects Architects’ Concerns
Business’/ Technology’s Concerns
Bank1 • Isolationist approach
• Withdraw from business and technology stakeholders. Do not leverage the experience and knowledge of business and technology staff
High importance
Low importance
(relative to architect’s concerns)
Bank2 • Collaborative approach
• Promote mutual engagement with business and technology stakeholders
High importance
High importance
(relative to architect’s concerns)
Table 7.5 Using the orientation of architects to ‘make sense’ of differences across the two cases
211
Figure 7.2 Orientation of architects in two cases
212
As indicated by the findings in both cases, the practices of architects effectively created a
boundary around them. The boundaries around the communities of architects in each case
existed in different states of permeability: thick and thin. The practices of the architects at
Bank1 are indicative of a ‘thick’ boundary as they prevented connections with others who have
a legitimate interest in the EAI. The architects prioritized what they thought was important
over the views and concerns of business and technology stakeholders. They prioritized
architectural objectives over business objectives and did not take into consideration the
commercial constraints and profit imperative of the organization when selecting new systems.
Whilst the architects worked effectively as a team, they did not engage with others outside of
the team and very little information (e.g. selected technology components and implementation
plans) flowed out of the group. Obversely, very little information relating to the concerns,
objectives and values of others was able to enter into the group and consequently, technology
project staff were unable to plan for the new systems introduced by the architects.
The practices of the architects at Bank2 on the other hand, were indicative of a ‘thin’
permeable boundary as they allowed connections with others. These connections were not
just the place where planning and analysis activities important to the documentation outputs
of the architects occurred, but sites where the meaning and objectives of a task were
negotiated and agreed. The architects at Bank2 made efforts to engage with business and
technology stakeholders and take into account their needs as they interpreted the requirements
of a particular task. For example, through the connections they established with business
stakeholders, the architects learnt about changes to the priorities of the business and factored
the new priorities into their revised system selection. Through the strategic planning meetings
with business executives, architects learn about desired business processes, services and
products and used that knowledge to develop new EAI knowledge within the architecture
team in relation to the design of technology platforms and selection of technology
components.
The different boundaries around the architects’ practices in both cases were also explained by
the relative relational competencies of the architects. The relational competencies of
architects refers to their ability to understand the perspectives that others bring to bear on a
213
matter of interest and then align their own response to the enhanced interpretation (Edwards,
2012). The ability of architects to assimilate into their analysis and decision-making activities
the concerns and objectives of others can lower or heighten the permeability of the boundary
around their practice. Thick boundaries are related to a low level of relational competence:
the impermeable boundary created through the reclusive practices of the architects (Bank1).
Thin boundaries that allow knowledge to flow in and out of the architecture team are related
to a high level of relational competence since architects must be skilled in assimilating the
concerns and objectives of others into their decision-making.
214
Chapter 8
8 EAI AS PERIPHERY CONNECTION
8.1 Introduction
As discussed in chapter two, very few studies have highlighted differences in perspectives and
expectations between architects and their stakeholders. In chapter three, I discussed how
differences in perspectives represent boundaries between communities of practice (CoP).
Whilst there was little research investigating connections between CoPs, boundary spanning
research suggests that connections between CoPs are critical to the flow of knowledge and
development of mutual engagement between them. In this chapter I return to my research
questions, re-invoke my theoretical lens and ideas from boundary spanning literature to
discuss the results of my research, specifically in terms of the enterprise architecture
implementation (EAI) roles and practices of architects.
The chapter is organized as follows. In section 8.2, in response to the first research question
(What insights into the relationship between the EAI practices of architects and the outcomes of EAI
initiatives are possible using the theoretical lenses of CoP and BSBO theory?), I discuss differences in
perspectives between architects, business and technology stakeholders that are evident in the
data and indicative of boundaries between them. I also discuss the relational competencies
that architects may need to bring to bear to bridge the boundaries between themselves and
their business and technology stakeholders. In section 8.3, in response to the second research
question (What new theoretical insight beyond that provided by CoP and BSBO theory is possible using
215
grounded theory?), I articulate a theory of EAI as a periphery connection, drawing on insights
from the interactions between architects and also the interactions between architects and their
business and technology stakeholders. In section 8.4, I return to the first research question
and re-invoke the conceptual dimensions of Wenger’s (1998) CoP theory (joint enterprise,
mutual engagement and shared repertoire) to theorize the EAI roles and practices of architects
as periphery connection agents.
8.2 Evidencing Boundaries
In discussing the motivations for this research, I highlighted the low level of integration
between research on the strategic aspects of EAI and the EAI activities of architects and how
this may jeopardize the success of EAI initiatives (van der Raadt et al., 2008). In addition,
research has shown that architects and their stakeholders have difficulty communicating with
each other and in working together (Poutanen, 2012). Given this, in chapter one, I raised the
question as to whether architects are able to bridge the reality-design gap effectively. In this
study of the meanings that architects, business and technology stakeholders ascribe to EAI
and the interactions between them, clear differences in perspectives have emerged between
architects and business stakeholders and architects and technology stakeholders (see Figure
8.2). These differences in perspectives are evidence of boundaries between architects and
business stakeholders and architects and technology stakeholders.
216
Figure 8.2 Boundaries between architects, business and technology stakeholders
Moreover, if we consider the different levels and areas of the organization that interview
participants represent, this has the potential to introduce other boundaries: boundaries
between the architects and business executives, architects and technology executives, architects
and business general managers, architects and technology general managers, and architects and
technology operational stakeholders, for instance. Such boundaries, in addition to the
boundaries between architects and business stakeholders and architects and technology
stakeholders are likely to add to the complexity and challenges of the boundary spanning role
of architects. Whilst a detailed examination of the extent to which the different articulated
perspectives of stakeholders may indicate finer grain CoPs within the broader business and
technology communities is beyond the scope of this research, I point to these differences in
perspectives to highlight the social complexity of an EAI and the difficulty that architects may
have in aligning their objectives and concerns with those of others so that a connection
between them can be established. Therefore, in the sections that follow, I compare and
contrast the perspectives of architects with those of business and technology stakeholders and
identify differences between them that suggest finer grain boundaries between the architects
217
and business stakeholders and architects and technology stakeholders.
Figure 8.3 Finer grain boundaries in an EAI context
8.2.1 Differences in perspectives between architects and business stakeholders
The differences in perspectives between the architects and business stakeholders for both
cases are summarized in Table 8.1 below.
An important difference in the perspectives of the architects and business stakeholders was
the architects’ priorities and whose interests they served. Architect’s prioritization of their
own objectives and views of what is important over those of the business is evidence of a
significant boundary. Business participants commented that the objective of the businesses
was to manage costs and to make a profit and this gave priority to cost effective technology
solutions that satisficed rather than satisfied architectural goals. Architects were also expected
to make corrective and perfective changes to the technology portfolio. For example, BU1
wanted access to customer data and to be able to share customer data across the organization
and accordingly, he prioritized the use of shared platforms and business process integration.
Business participants also expected the architects to understand that changes in the external
218
environment (e.g. Global Financial Crisis, regulatory change, emergent market opportunities)
could re-order the priorities of the business. Consequently, EAI projects that were previously
considered important had to be deferred to accommodate new projects. On the other hand,
the architects’ perspective presents a very different picture. For example, A1’s comment that
“our role is first and all, to define the technology components and the implementation plans, that’s all we do”
indicates that the architects prioritized the completion of the technical documentation
associated with the EAI over the needs of the business. It was interesting to note that A2 did
not seem concerned by the absence of a broader industry perspective in the architects’
approach or by the huge costs associated with the technology components.
The different priorities of architects and business stakeholders may relate to a difference in
worldview. Business executives viewed the external environment as fluid and highly unstable
and found it difficult to predict what their future requirements would be. Though they
sympathized with the architects, business executives were quite clear that this was the reality of
the banking industry and the architects must accept that business priorities and requirements
will change as industry and regulatory conditions change.
Many of the businesses have got so much on their plate managing today’s environment
that getting them to be really clear about what their future customer proposition is is a
challenge. Because they’re not clear and flip-flop, they end up in this potential conflict
with the architects who are trying to define from a technology perspective what they need.
In the last nine months, for example, there have been so many changes to the
environment, the Global Financial Crisis, regulation, and other things that need to be
done. All of these claim resources or effort. The architects need to understand that
(BU1).
Whilst business executives expected the architects to recognize that changes in the external
environment can make it necessary to make changes to the selected technology components
and implementation plans, they also expected architects to provide technology solutions that
satisfied an emergent need, even if those solutions were inconsistent with the aims of the EA.
In contrast, architects may perceive the technology selection and implementations plans as a
one-off occurrence and may not be willing to accommodate changes in the priorities of the
219
organization and business divisions.
You lock it in, you agree, that’s effectively speaking our approach to the technology (A1).
So this is the plan. There’s no other plan. That’s the plan and it’s not going to change
(A1).
Differences in role expectations are evidence of a significant boundary between architects and
business stakeholders. Architects may make assumptions about the nature of their role, which
can heighten boundaries between themselves and business stakeholders and potentially lead to
conflict. Architects may identify their role as designing the new technology portfolio of the
organization and planning for the delivery of that new portfolio into operation. They may use
governance instruments to maintain the stability of the technology portfolio thus maintaining
the accuracy of their technology selection and implementation plans. Architects may strive to
have ongoing management control over the programs of work related to the EAI as “the
business has often been driven by what the business wants to achieve” (A5). Though they may not want
to have responsibility for the execution of the implementation plans, the architects may seek
ways in which to maintain control over the execution of those plans (See section 5.3.1 Selecting
the New Systems and Defining the Implementation Plans). Even though there is a clear need for
architects to be involved in the programs of work beyond technology product selection and
implementation planning, we need to ask the question: does the architects’ emphasis on
management control serve the interests of the organization or does it reflect the architect’s
prioritization of their concerns over the interests of the business? Architects may be
concerned that without adequate oversight, business staff with the help of technology will
make their own choices in relation to the selected technology components and
implementation plans. This could suggest a trust boundary between the architects and the
business, which has practical implications for their on-going relationship. A distrust of the
motives of business stakeholders is seen to prevent the architects from focusing on efforts to
build mutual engagement with them and instead focus on efforts to control their behavior.
Business stakeholders may view architects as fulfilling a change agent role and expect them to
build support for and commitment to fund the new systems and implementation plans. They
may expect architects to advocate on behalf of the implementation of the EA and hold the
220
architects explicitly responsible for the implementation of the EA plans.
One of the things missing was buy-in from all the major stakeholders. We didn’t get all
the big hitters around the top table to absolutely agree to support these projects to the
‘n’th-degree’ of their lives. The architects have got work to do to convince those people
that the architecture is also in their interests (BU2).
Architects may also need to be aware of formal capital investment processes, which are used
to allocate funding for programs of technology work such as an EAI. There may be senior
people in the organization who can advocate on behalf of the EAI and help build support for
the EAI amongst senior executives. As commented by BU1 (See Section 5.5.1 Building Support
for the EAI),
Nothing happens in a vacuum. They didn’t engage with people like me who can help
them turn the technology plans into a reality … They need the influence of people like me
(BU1).
Architects, on the other hand, may view the business (and also technology) as responsible for
executing the implementations plans and, by extension, expect the business to fund those
plans.
Business stakeholders may view the architects as strategy enablers and focus on their role to
align the technology portfolio with the new strategic objectives of the organization. BU1
viewed the enablement role of the architects as critical because of their technical expertise. He
also alluded to a fundamental tension in the enablement role of the architects between the
desire of the organization to change and the latency associated with operationalizing the
required systems.
God knows we might change the strategy again. The trouble is the technology’s spines
through the organization are so complicated and take such a long time to develop and
build, you know the organization runs ahead of that and it takes a long time and real
consistency and discipline to build the frame which everything hangs off. It becomes a very
expensive and slow process (BU1).
221
Some business stakeholders expected the architects to fulfill a project consulting role, assisting
with problem solving tasks and also discussing emerging ideas and challenges. They found
having access to the architects to be effective in helping them to analyze and resolve technical
problems associated with technology projects. Comments of business participants indicated
that having direct communication with the architects and being able to call on their expertise
as required is the basis for high quality service to the business.
I spend a hell of a lot of time with the architects on different tasks. I purposefully join
them as much as I can to make sure that what I'm doing corresponds with the
implementation plans. If we didn't have the architects, I wouldn't be happy with our
requirements, design, build, testing, deploying and doubt we would meet the outcomes
expected. As a program, I think we wouldn’t understand the internal dependencies
within the program or be able to manage the relationships with vendors and product
developers without the architects. How do we ensure that the fifty-odd projects within this
program are all achieving and delivering on one goal? (BU6)
Architects are also expected to understand the potential emotional impact of an EAI on
people and how people may respond to the uncertainty associated with the EAI. People may
fear the potential structural changes introduced by the EAI including the introduction of new
organization-wide technology capabilities, the retirement of legacy systems and the creation of
new management positions. They may fear losing management control over staff or
technology resources and may also fear for their on-going employment. As suggested by BU2
in Section 5.5.6 Understanding the Impact of the EAI on People, architects may need to be aware of
the negative behaviors that may arise in an environment of such uncertainty and may need to
intervene.
222
Case Architects’ Perceptions and Expectations
Business Stakeholders’ Perceptions and Expectations
Comments made by
Bank1
Perceive that what is important is the selection of technology components and development of implementation plans
Expect architects to understand the cost management and profit making imperatives of the business
BU1 & BU2
Perceive their objective is to align the technology portfolio with the organizational strategy
Expect architects to make corrective and perfective changes to the technology portfolio
BU1
Expect that business requirements are stable and known
Expect architects to understand that businesses must be able to respond to emergent opportunities and constraints
BU2 & BU3
Perceive that business requirements are satisfied by the selected technology products
Expect technology components selected by the architects to satisfice and not exceed business requirements
BU1, BU2 & BU4
Expect the business to acquire the selected technology products and execute the implementation plans
Expect the architects to build support for and commitment to the technology products and implementation plans
BU1, BU2, BU3 & BU4
Expect the technology portfolio to be stable to maintain relevance of technology product selection and implementation plans
Expect to be able to pursue emerging market opportunities as they arise and make changes to the technology portfolio as required
BU3 & BU4
223
Perceive that the technology product selection and implementation plans are a one-off occurrence and not to be changed
Expect the architects to make changes to the technology selection and implementation plans, as required
BU1 & BU2
Perceive that business stakeholders are motivated by self interest and will do as they please
Expect architects to understand the commercial reality of the business
BU1 & BU2
Expect that the approval of the EA plans is required to successfully transition from the EA plans to the implementation of those plans
Expect architects to understand that large technology programs such as an EAI require the approval of formal organizational capital investment and planning bodies and that there may be key ‘influencers’ who can help facilitate building support for the EAI
BU1
Perceive that the EAI is a technology oriented task
Expect architects to understand the emotional impact of the EAI on people
BU4
Bank2 Perceive that it is important to maintain an on-going relationship with the business and make connections, as required
Expect architects to maintain an on-going relationship and provide assistance, as required
BU6
Perceive that it is important to understand the strategic objectives, future products and services and desired capabilities of the business
Expect architects to understand the external business environment and the potential competitive impact of new technologies
BU5
Perceive that the technology components and implementation plans must be framed in a language and context that is meaningful to the business
Expect architects to speak the language of and understand the ‘world’ of the business
BU6
224
Expect that business requirements and priorities will change as opportunities and constraints emerge
Expect architects to accommodate changes, as required
BU5 & BU6
Expect to prioritize business objectives and constraints when selecting technology components
Expect architects to provide analysis to inform technology decision-making
BU6
Table 8.1 Differences in perspectives between architects and business stakeholders
225
Within the broad range of perspectives about the nature of the architects’ EAI, there were
discernible differences across the comments made by business participants and these may
suggest finer grain boundaries within the broader business function. Evidence indicated that
the concerns of business stakeholders were related to their positions in the organizations and
delegated responsibilities. For example, senior executives and lower level business
stakeholders expected the architects to address different concerns. Business executives
responsible for running divisions (BU1, BU2 and BU5) are less interested in the performance
aspects of the technology components and more interested in the cost benefit ratio, the
continued profitability of the organization and the impact of the selected components on the
competitive position of the business. At lower executive levels where people had executive
responsibility for organizational-wide arrangements such as the management of outsourcing
arrangements (BU3), the expectations of business people were focused on matters directly
related to the their management responsibilities. BU3, who was responsible for the
outsourcing arrangements at Bank1, expected the architects to take into consideration existing
outsourcing arrangements when selecting new technology products. At the general
management level, the expectations of business stakeholders were focused on specific projects
they were involved with. BU6 who was involved in an EAI program of work as the risk
management and finance work stream leader wanted to engage with architects on an as-needs
basis to discuss architectural concerns and ideas as they arose within that program.
Whilst further research is required to examine to what extent the different expectations
articulated by business stakeholders imply the existence of finer grain CoPs, the evidence
suggests that the business stakeholders of an EAI may not be a homogeneous group and that
stakeholders may have different expectations about the EAI role of the architects. This means
that architects should be mindful of the delegated responsibilities of different stakeholders and
how these may influence expectations about their role in the EAI initiative.
Summary
The discussion of the differences in architect-business stakeholder perspectives suggests
architects may need to consider the following types of relational competency in order to
226
bridge the boundaries between themselves and business stakeholders.
• Architects need to consider how they can identify the different types of business
stakeholders in an EAI and to what extent the interests of business stakeholders may
change as the EA initiative transitions from the development of the EA plans to the
implementation of those plans.
• Architects need to consider how to recognize and assimilate into their analysis and
planning the needs of business stakeholders at different management levels in the
organization.
• Architects need to be adept in understanding the different information needs of
business stakeholders and communicate with them in a manner that helps bridge the
boundaries between them. Information requirements of business stakeholders may
vary depending on their position and responsibilities in the organization. Architects
could give particular consideration to how the provision of information may be viewed
as the basis of a high quality of service by business stakeholders. Architects may be
required to explain how the selected technology products position the organization
strategically within a particular market, the potential opportunities for new business
products and services and implications for existing outsourcing arrangements.
• Architects may need to understand the broader industry environment of the
organization and how changes in that environment can impact the EAI. This relates
to an important area of difference in the focus of the architects and expectations of
business stakeholders. While business stakeholders expect architects to understand
how changes in the external environment may impact the organization strategically,
architects focused on other matters such as selecting technology products that satisfied
their own architectural objectives and values. Though this approach made sense to the
architects, it was not useful in bridging the gap between themselves and business
stakeholders. Architects could address business stakeholders’ concerns by
investigating broader industry environment issues that may impact business
stakeholders’ requirements. Architects could also consider how the technology
components and implementation plans can be changed to enable the organization to
respond to changes in the external environment whilst preserving the overall direction
227
of the EA.
• Another important area that architects need to consider relates to building support for
and commitment to fund the technology products and implementation plans.
Organizations may have formal capital investment and planning processes to allocate
money to technology programs. Architects need to understand the processes and the
timing associated within organizational capital investment and planning processes and
fit within them/ it.
• Architects need to consider how they can build support for the technology products
they select within institutionalized capital investment and planning processes.
Architects also need to consider informal approaches to building support for the EAI
and may need to engage with people in the highest executive roles that can advocate
amongst their peers for the acquisition and implementation of the selected technology
products.
• Architects need to understand the financial constraints of the business and factor those
constraints into their technology selection and implementation planning.
• Architects need to be adept at translating the organizational-wide benefits of the
selected products in terms that are meaningful for business divisions and consistent
with the motivations of the executives leading them.
8.2.2 Differences in perspectives between architects and technology stakeholders
The differences in perspectives between the architects and technology stakeholders in both
cases are summarized in Table 8.2.
The architects and technology stakeholders had different perceptions about the importance of
the architects’ work. Architects consider themselves as fulfilling a strategy enablement role, as
they are responsible for the production of the EA plans, the selection of technology products
and development of implementation plans to deliver those products into operation. In
contrast, technology stakeholders also expected the architects to make corrective and
perfective changes to the technology environment. For example, T3 and T4 expected the
228
architects to reduce the number of duplicate applications in the IS portfolio and to replace the
legacy systems.
Technology stakeholders and architects also had different expectations about the EAI role of
the architects. As described in Section 8.2.1, architects may see their role as primarily
concerned with the selection of technology products and may direct their efforts to that end.
Technology stakeholders on the other hand, expected the architects to fulfill a consulting role
and be involved, on an as-needs basis, in projects that have a dependency on the EAI.
Technology managers such as T3 expected the architects to be involved early on “when ideas for
the project are going back and forth between the business and technology”. T1 expected the architects to
remain accessible to projects throughout the project life cycle, providing ongoing problem
solving and other services to technology staff.
They’re accountable for implementation plans and once we begin to execute the plans,
gaps will emerge or changes to the plans will need to be made because of unforeseen
constraints. They don’t have to be hands-on all the time and working beside us day-to-
day, but they need to be accessible when we need them (T1).
Alternatively, architects may make themselves accessible to project staff and provide assistance
to technology projects, as required. Evidence indicates that this approach helps to build
connections between the architects and technology stakeholders as architects are seen to be
accountable to technology staff and the projects they are involved with.
Architects and technology stakeholders had different perceptions about the technical
knowledge required to undertake an EAI. Technology participants felt that the architects
needed to appreciate the importance of technology product knowledge and were frustrated
that the architects did not recognize their product knowledge and experience. Technology
interviewees felt that the architects did not fully understand the constraints of the existing
technology portfolio and might select products that would be difficult to implement or may
not deliver the expected business benefits. As cited earlier, T2 commented
The poor solution architects are actually the ones delivering projects and delivering value
… They’re the ones who know the systems and environment at a detailed level, not the
229
architects. Some of the architects have only been in the bank a couple of weeks. So, they
need to work with us and stop ignoring us (T2).
Architects’ prioritization of architectural objectives may cause them to give inadequate
attention to other technical knowledge that may be relevant to an EAI. Such an approach may
not be useful, as architects may fail to understand from technology staff, problems associated
with available commercial software and hardware products and the potential pitfalls of
deploying some products into the technology environment. This approach may also intensify
boundaries between architects and technology staff and affect the ongoing working
relationship with them.
Alternatively, architects may lower barriers between themselves and technology staff through
sharing their knowledge and also recognizing the expertise of technology staff. Architects may
co-develop tools and documentation templates with technology staff, which serve to
recognize, capture and make use of the expertise of technology staff. They may reflect on the
relational benefits of such an approach and how it helps build connections with technology
staff (See Section 6.3.6 Sharing Tools and Knowledge with Technology Staff). Technology staff may re-
use tools developed by the architects in projects that they are involved in and in a tangible
way, benefit from their relationship with the architects.
We are sharing our templates and tools. Many project staff working in projects use our
application master. We have defined the status of all applications: is it strategic, is it
tactical or is it to be decommissioned? We have also developed a schedule of technology
projects for the applications that will be decommissioned and project staff use that as the
gospel. They use it every day. We also have completed software and hardware plans for
the individual divisions and project teams make use of those as well (A7). .
As with business stakeholders, there were differences within the perspectives articulated by
technology executives, managers and project staff about the nature of the architects’ EAI role,
which may suggest finer grain boundaries within the broader technology community. For
example, technology executives such as T1 and T5 took a business view and expected the
architects to explain the connection between the selected technology products and business
processes and services. In particular, they wanted the architects to explain how the selected
230
technology products would improve the operating model of the business. A possible reason
for this perspective is that the technology executives who took part in this research were
aligned with business divisions and this may have been a deliberate organizational strategy to
encourage them to focus on matters important to the business.
The architects need to show how the technology assets [i.e. products] they’ve selected will
improve business operations. They have to make a connection between the platforms
they’ve designed and how the functionality of those platforms will be consumed by the
businesses. What are the new business processes, where are the new data flows, what new
information will be generated and who will access that information? You can’t just
implement a new platform out of the box (T1).
At times they can be too focused on the architecture without assessing the business value
that is being delivered (T5).
Technology managers (T3, T4, and T6) adopted a technology operations focus and expected
the architects to address problems associated with the technology portfolio including the
inefficient use of technology resources, legacy systems (See Section 5.5.3 Addressing Problems
with the Technology Portfolio) and application support costs (See Section 6.5.1 Defining the Technology
Strategy).
We have real problems sharing customer data across this organization … Mortgages,
superannuation and credit cards don’t share customer data because their systems don’t
talk. The new architecture must allow the small business people to talk to the mortgage
people, or the capital finance business to talk to the corporate bank. (T4).
Operational level technology staff (T5) expected the architects to be accessible to projects
providing architectural guidance for technology solutions, problem-solving assistance and to
discuss ideas and opportunities as they arose (See Table 8.2).
231
Case Architect’s Perceptions and Expectations
Technology Stakeholder’s Perceptions and Expectations
Comments made by
Bank1
Perceive that they are responsible for designing and planning the delivery of the technology portfolio to deliver the organizational strategy
Expect architects to address problems with the technology portfolio
T2, T3, & T4
Perceive they are responsible for the selection of technology components and development of the implementation plans
Expect architects to provide on-going problem solving assistance and advice to projects, as required
T3 & T4
Perceive they should have management control over the implementation plans and programs of work
Expect architects to engage throughout the project lifecycle, on an as-needs basis
T3 and T4
Perceive that it is not important to have direct contact with technology staff
Expect architects to explain connections between selected technology products and desired business processes, products and services
T1, T2, T3, & T4
Perceive that there is sufficient knowledge and experience within the architecture team to select appropriate technology products
Perceive that insufficient recognition is given to the experience and expertise of technology staff
T2, T3 & T4
Expect that technology products which satisfy architectural goals will also satisfy technology staff’s requirements
Expect architects to appreciate the constraints of the technology portfolio and the implications for the implementing the selected products
T1, T2, T3, & T4
232
Bank2 Perceive that technology staff have experience and knowledge that is beneficial to the EAI
Perceive architects provide opportunities for technology staff to share their knowledge and experience
T5 & T6
Perceive that involving technology staff in the selection of technology products is crucial to building support for those components
Expect architects to be available to discuss matters related to the selection of technology products
T5 & T6
Perceive that it is important to maintain direct communication with technology staff and be accessible to them
Expect architects to be accessible and provide opportunities for direct engagement, on an as-needs basis
T5 & T6
Perceive that it is important to share knowledge and tools with technology staff
Perceive tools and knowledge developed in the course of EAI are also relevant to non-EA related projects
T5 & T6
Perceive that developing documentation templates and other tools with technology staff will build connections with them
Perceive there is a strong sense of collaboration with technology staff
T5 & T6
Table 8.2 Differences in perspectives between architects and technology staff
233
Summary
The discussion of differences in architect-technology staff interactions suggests architects may
need to consider the following relational competencies in order to bridge the boundaries
between themselves and technology stakeholders.
• Architects need to consider how to recognize and incorporate in to their planning, the
requirements and concerns of technology staff at different levels in the organization
and how such an approach may help bridge the boundaries between them and their
technology stakeholders.
• Architects need to reflect on the technical gaps in their knowledge, how these may
impact the EAI initiative and how they may access the required information from
technology staff. They may also need to reflect on the positive impact that recognizing
the expertise of technology staff may have on their ongoing relationship with them.
• Architects need to consider how they establish and communicate the scope of their
EAI work in light of the different concerns and objectives of technology staff. As
technology staff may strive for their own concerns and objectives, this may extend and
/ or confuse the work that architects are responsible for. A possible approach is for
architects to discuss and negotiate with stakeholders what they are responsible for and
what they are not responsible for.
• Architects need to consider approaches for building the trust of technology staff and
their support for the technology components and implementation plans rather than
striving to find ways to compel technology staff to adopt them.
To conclude, adopting Wenger’s (1998) concept of the practice boundary advances our
understanding of the social complexity of an EAI. Whereas earlier EAI literature has assumed
that stakeholders’ requirements are stable and homogeneous, the research undertaken here
demonstrates that the stakeholders associated with an EAI may have different and competing
requirements (Peristeras and Tarabanis, 2000; Ross, 2003). Since an EAI is a potentially
ambiguous phenomenon, boundaries between architects and their stakeholders may arise in a
number of ways (See Figure 8.4). There may be different interpretations of the importance of
234
the architect’s role including strategy enablement, organizational enablement, stabilizing the
technology portfolio or making corrective and perfective changes. There may be different
expectations associated with the EAI roles of architects including selecting technology
products, implementation planning, governance, change agent, consulting or delivering the
EA. Stakeholders may have different priorities including implementing cost effective
solutions, retiring legacy systems, simplifying the application portfolio and having access to
customer data. As suggested by Smolander et al. (2008) and Smolander and Rossi (2008), the
disappointing outcomes associated with an EAI may be the result of the inability of architects
to understand the different boundaries that may exist between them and their stakeholders. In
order to build effective relationships with their stakeholders, architects must be able to bridge
the various boundaries that may arise between themselves and their stakeholders.
Figure 8.4 Perspectives and assumptions of the architect’s EAI role and practices
235
The extent to which architects are able to bridge the boundaries between themselves and their
stakeholders is dependent on their relational competencies. This research addresses concerns
raised by Rozanski and Woods (2007) that there is a need for researchers to demonstrate that
stakeholders associated with an EAI may have different objectives, concerns and perspectives
and the failure of architects to understand these differences may adversely affect the outcome
of an EAI. Though EAI literature has promoted technical solutions which have
supplemented our knowledge of the technical challenges associated with EAI, the relational
problems associated with EAI have been overlooked (Simon et al., 2013). Architects must be
able to assimilate the concerns and objectives of their stakeholders in order to build effective
connections with them. However, the potential for ambiguity in an EAI means that
boundaries are not stable and that new boundaries may emerge as stakeholder priorities
change or as the expectations of the architects’ role change. The variety of stakeholders adds
to the potential instability since stakeholders may come in and out of an EAI and new
stakeholders may bring new interpretations and expectations of the architects’ role.
Stakeholders may also include people from outside of the organization such as vendors who
may have their own interpretation of what systems are required and may strive for their own
interests. The potential for boundaries to shift means that architects must be able to adapt
their relational competence in order to accommodate the shifting concerns and assumptions
of stakeholders. As described in Figure 8.4, the capacity of architects to adapt their worldview
to accommodate this ambiguity and variability can impact their ability to span boundaries
between themselves and their stakeholders.
Researchers have raised concerns about the relationship between the EAI practices of
architects and the outcomes of EAI initiatives (van der Raadt et al., 2008; van der Raadt et al.,
2010). Architects’ practices must enable them to adapt to the variability of EAI boundaries
and the potential for those boundaries to shift. Suggestions that boundaries define the nature
of communities (Hernes, 2004) and practices within the communities reinforce boundaries
(Zietsma and Lawrence, 2010), highlights the causal relationship between practices and
boundaries. Permeable boundaries are seen to arise from practices that encourage engagement
with others who have a legitimate interest in the EAI. It is through these engagements and
interactions with stakeholders that architects are able to understand the boundaries that exist
in the EAI and are able to respond to them. BSBO research indicates that architects are able
236
to respond to boundaries in different ways. They may value the participation of the ‘other’,
recognizing their expertise and experience as critical supplements to their own expertise
(Pawlowski and Robey, 2004). They may allow others into their community, not as ‘full
members’ of the community, but as legitimate participants in a joint enterprise (Levina and
Vaast (2005). Architects may share the expertise and tools of their community with others to
enable them to complete project tasks (Volkoff et al., 2004). Whilst the expertise and tools
that architects share with others are representative of the architecture community, they are
‘partially’ representative of the total knowledge and tools of that practice. Therefore, the
connections that architects build with their stakeholders during an EAI occur at the periphery
of their community rather ‘fully’ inside the community.
Whilst descriptions of EAI vary within the literature (Rajput, 2000; O’Rourke et al., 2003;
Lankhorst, 2005), this research has provided insight into the nature of the interactions
between architects themselves and between architects and their stakeholders. The nature of
the connections between architects and their stakeholders during an EAI are episodic and
task-specific. Architects tended to engage with their stakeholders on a task-by-task basis
rather than in a continuous and ongoing relationship. For example, architects engaged with
business executives in business strategy planning meetings for the purpose of defining the
technology systems required to support the desired business products and services and to
select specific technology products. The architects’ objective in these meetings is either
information elicitation or provision and once those objectives have been satisfied, the
architects disengage from the interaction. Architects likewise engage with technology
stakeholders for the purpose of understanding the constraints of the technology portfolio,
which then informs the types of software, and hardware products the architects select.
Similarly, the architects disengage from those engagements with technology stakeholders once
the objectives of the particular task are satisfied. Architects, therefore, tended to engage with
stakeholders on an as-needs basis in an episodic rather than a continuous manner.
The as-needs basis of architects’ engagement with their stakeholders has implications for their
ability to respond to the potentially ambiguous nature of an EAI. Architects are unable to
work on and refine their relational competency skills as if they were in a continuous
engagement with their stakeholders; instead they must apply them efficiently in order to enter
237
into their episodic and task-specific engagements with their stakeholders. In the next section,
I theorize about the nature of architects’ engagement with their stakeholders and invoke the
periphery connection concept of Wenger (1998).
8.3 EAI practice as periphery connection
In this section, I present a more general understanding of EAI practice as a periphery
connection between architects, business and technology stakeholders. I discuss both what I
have understood about the interactions between architects, business and technology
stakeholders by viewing them as periphery connections, and insights I have gained into
periphery connections in general from the work of architects.
8.3.1 Architects as periphery connection agents
In order to understand EAI as a periphery connection, the nature of the architect’s role in
periphery connections and in relation to spanning boundaries will be discussed (See Figure
8.5).
Figure 8.5 Architects as periphery connection agents
238
Wenger (1998, p. 116) argues that ‘periphery connections allow non-members casual and
legitimate access to the practices of a community without subjecting them to the demands of
full membership’. Individuals involved in periphery connections are not in sustained
relationships with long term aims as in boundary practices where individuals sustain
connections with other practices by ‘addressing conflicts, reconciling perspectives, and
finding resolution’ (Wenger, 1998, 114). This describes the practices of architects during an
EAI in that they connect with business and technology stakeholders as required, to complete
certain tasks associated with the EAI or to provide consulting services to projects outside of
the EAI. However, it is my argument that for individuals to effectively enter into periphery
connections with individuals from other communities they need sufficient relational
competence to be able to take into consideration the perspectives and concerns of others to
reveal the complexity of the task at hand and align their own responses to that task with the
enhanced interpretation (Edwards, 2012).
Individuals involved in periphery connections are not looking to establish new practices, but
to enter efficiently into connections with individuals from other communities, to complete a
designated task and then disengage from that connection. BSBO research indicates that in
boundary spanning arrangements, individuals retain the identity of the community to which
they belong and provide the ‘other’ a partial perspective of the practices of that community
(Levina and Vaast, 2006). It is thus a description of the practice of architects involved in an
EAI, in that they enter into frequent episodic connections with business and technology staff
to complete a designated architectural task which reflects an aspect of what architects do, but
not all that architects do. Therefore, these connections occur at the periphery of the
architects’ CoP and are not fully inside or outside the CoP. Individuals entering into periphery
connections with architects are exposed to a partial representation of the architects’ CoP and
for a short time have access to that community, but do not become full members of it.
Throughout these connections, architects retain their identity as architects and the people
architects engage with likewise retain the identity of the community to which they belong.
This perspective may be further developed by discussing how different worldviews may result
in the different emphases of architects in their role as periphery connection agents (i.e.
individuals responsible for establishing periphery connections). My findings suggest that while
239
architects are required to span the boundaries between themselves and business and
technology stakeholders, as periphery connection agents, they may develop different views on
whose interests they represent while they engage with those people (Wenger, 1998). For
example, the architects at Bank2 were physically located with business groups with whom they
were meant to establish connections. Some architects at Bank2 were concerned that being
physically located with business staff may give rise to perceptions of bias toward the business.
As suggested by Vashist et al. (2010), individuals responsible for complex periphery connection
arrangements may adopt conflicting orientations, depending on the stakeholders they are
engaging with. The potential for architects to confuse whose interests they serve may result in
them adopting conflicting orientations: architecture-oriented versus business-orientated,
control-focused versus enablement-focused, isolationist-focus vs. collaborative focus (see
Figure 8.5). A ‘balanced orientation’ may appear to be what we might want to achieve in a
periphery connection. In this orientation, architects are situated between the business and
technology and are not biased towards either the business or technology. Architects are able
to engage with and ‘listen’ to both business and technology stakeholders, act equally in the
interests of both and assimilate the interests of both business and technology stakeholders in
their understanding of and response to a particular task. However, this may neither be the
best nor the desired orientation in organizations, as different business environments, different
organizational strategies, and different capabilities may imply a need for a different orientation.
In practice, as a result of their office location, architects may perceive themselves to be ‘closer’
to the business and distant from the architecture team. In Bank2, we saw the possibility that
architects might adopt this orientation if they are physically located in the business divisions
rather than located within the architecture group. The strength of this approach is a potential
increase in architects’ business orientation, which enables them to be viewed as ‘insiders’ by
business staff. But, the limitation is that architects may tend to focus more on particular local
business problems and less on the ‘global’ and organizational-wide aspects of technology
solutions. Similarly, if architects are located within the technology function, they may perceive
themselves to be ‘closer’ to technology staff and may become technology solution focused.
240
Figure 8.5 Different orientations in the approaches of architects
Though scholars such as Levina and Vaast (2005) working in the IS discipline have examined
the conditions under which boundary spanning behavior emerges, in general IS scholars have
not examined in detail the factors that may influence the motivation for boundary spanning.
Whilst my findings indicate that architects may be located strategically within business and
technology to bring about connections with individuals in those groups, the orientation and
boundary spanning practices of architects are influenced by other factors. The relationship
that architects have with business and technology staff, the architects’ background, entrenched
feelings of distrust, the experience of architects in working with business and technology staff
and the nature of the task at hand could all influence the orientation of architects and the
outcomes of their boundary spanning work.
241
Wenger’s (1998) description of periphery connections as episodic and partially inclusive does
not account for all the observed practices in this study. I argue that periphery connections
whilst they are task specific and intermittent, involve relational competence. Periphery
connections are dependent on the ability of the periphery connection agent to reconcile their
understanding of what is important with the perspectives and concerns of the people they are
designated to connect (Edwards, 2012). In this research there is evidence to suggest that
successful periphery connection agents are able to efficiently reconcile the perspectives of the
parties involved, bringing them closer together. People responsible for creating periphery
connections may see their role as facilitating the efficient interaction between parties. For
example, as was the case in Bank2, specific individuals in the architecture team were essentially
‘relationship managers’ responsible for managing the relationship between senior business
executives and the architects. To help bring about a sense of mutual engagement and achieve
the objectives of the task, these ‘relationship managers’ used strategic planning models familiar
to those executives to mediate the different perspectives between them. This approach helped
the architects and business executives agree on the required technology components to
support the EAI. Architects may also, as seemed the case in Bank1, not understand that their
role is to ‘listen’ to the ‘other’ and the extent to which this may influence the development of
periphery connections. Such arrangements seem contrary to Wenger’s (1998)
conceptualization of periphery connections. In the cases I studied, it seemed that architects
were able to effectively and efficiently enter into periphery connections when they were able to
understand the perspectives and concerns of the other party.
People responsible for boundary spanning activities such as periphery connection agents are
likely to perceive themselves as making significant contributions in organizations, have varied
role expectations, and face ambiguity associated with their role (Vashist, 2013). The findings
of this study largely support Vashist’s (2013) claims about role ambiguity (See Figure 8.4).
Regardless of the actual influence they might have in their organization, the architects
perceived themselves to be making useful contributions to the organization. For example,
they considered their role to select the technology products as realizing the organizational
strategy and the implementation plans as delivering the organizational strategy into operation.
They considered themselves responsible for providing consultancy type (i.e. problem-solving)
services and advice to projects that have a dependency on the EAI. They also saw their role in
242
the EAI as a governance one, controlling the technology portfolio and technology choices of
the business. The EAI role of architects may be viewed with some confusion in organizations
where there is ineffective communication about the role. For example, the governance role of
the architects may need to be clearly differentiated from other project governance or capital
investment review bodies by emphasizing that architects require more specialized architectural
knowledge than others may possess.
Tasks undertaken by periphery connection agents may be in conflict with their boundary
spanning role. As identified in Pawlowski and Robey (2004), tasks undertaken by boundary
spanners are an extension of their designated roles. However, where periphery connection
agents perform multiple roles, they may exploit certain roles to supplement other roles. The
governance role of the architects at Bank1 was intended to provide architecture oversight over
new technology investments and projects, but was used by the architects to shut projects
down and to preserve the accuracy of the EA plans. Periphery connection agents must be
able to reconcile the purpose of their tasks with those of communities that are required to
build connections with (Volkoff et al., 2004). An inclination toward boundary spanning is not
only seen in the tendency to reflect on the efficacy of tools to support connections between
communities (Pawlowski and Robey, 2004), but also in the ability of periphery connection
agents to reflect on the potential conflict in the multiple roles they may perform.
A characteristic that has been associated with effective boundary spanning in cross-functional
collaborations is the boundary spanners’ prior functional experience (Ancona and Caldwell
1990). The tendency to recruit people with previous architecture experience is indicative of a
tendency to value technological experience over business, management experience or
boundary spanning experience. Whilst every architect may not need to possess ‘boundary
spanning’ skills, the skills do need to be there in the team and the leader also needs to have the
skills. There is evidence from my research to suggest that possessing a high degree of
technical skill and knowledge was more important and more highly valued than experience in
boundary spanning. However, for people responsible for periphery connections, specialist
domain knowledge alone does not necessarily result in satisfactory outcomes (e.g. Bank1).
Thus, my research suggests that prior functional experience and technical expertise may be
somewhat less important than prior experience in cross functional roles or a high level of skill
243
in assimilating the perspectives and concerns of others.
8.3.2 Periphery connection practices of architects
Based on insights from the interactions between architects and the nature of shared
understanding and learning that occurs within architecture teams, in this section, I articulate
my understanding of these interactions for architects’ practices as periphery connection agents
(see Figure 8.6).
244
Figure 8.6 Periphery connection practices of architects
245
While the work of periphery connection agents suggests that shared understanding between
them and the practices they connect is important, there are areas where shared understanding
amongst the periphery connection agents themselves is required. For example, where a
number of architects are required to span the boundaries of a number of lines-of-business
within an organization to align them with the EA, a shared understanding amongst the
architects as to their aims, objectives, approaches and tools, for example, is important. For
example, a number of architects may be working on different tasks connected to the selection
of technology components and development of the implementation plans, but the tasks are
related in terms of implementing the ‘global’ EA. Further, my study revealed that the
architects’ efforts to comply with practices within their group supported the adoption of
common, shared practices. However, for periphery connection agents, finding a balance
between building connections across different practices, and complying with the standard
tools and methods within their own practice may be a challenge. For example, whilst A9
agreed with the use of common documentation templates for promoting a consistent
approach when dealing with the business divisions, he found them difficult to apply in his
engagements with the corporate functions such as finance, human resources, risk management
and needed to adapt them.
Periphery connection agents must be skilled in adapting boundary objects to help them
reconcile the perspectives and relevant knowledge of others with their own (Volkoff et al.,
2004). In both cases, the architects were aware that the artifacts used by them effectively
functioned to connect them as a team. The results from Bank1 suggested that where
architects make efforts to adapt their artifacts to accommodate the differences within their
group, this can lead to the successful completion of designated tasks. In Bank2, the use of
standardized documentation templates gave architects within the group a sense of identity as
architects and belonging to a defined group. The implications are significant for periphery
connection agents, since artifacts can be used in periphery connections to facilitate boundary
spanning and also to build a sense of joint enterprise within those connections. One may
speculate as to whether the inability or failure to adopt objects that serve to mediate the
different perspectives of those involved in periphery connections can lead to continuing
differences in perspectives within periphery connections and the inability of periphery
246
connections to progress. For example, in Bank1, the architects’ continued use of highly
detailed and complex technical architecture models, which have meaning for them, but only
limited meaning for technology stakeholders, served to continue rather than reconcile
differences in perspectives. In the case of Bank2, the use of objects such as the strategic
planning templates which served to reconcile the perspectives of architects and business
executives, provide a foundation on which their engagement was able to progress.
A characteristic highlighted by researchers for effective boundary spanning is the ability to
reflect on the usefulness of existing artifacts and develop and adopt new artifacts (Levina and
Vaast, 2005). There is evidence in my findings that architects are skilled at doing this. I
conjecture that this may be related to the mutual engagement inclinations of the architects
themselves, since architects who showed a tendency toward engagement with one another
were willing to investigate ways of building closer relationships with other architects (e.g. a
team charter). In contrast, architects who were not inclined toward building mutual
engagement with others outside of their community, used artifacts that were inward looking
and focused on things that mattered primarily to themselves. However, given the task of
spanning multiple different practices, I believe it important that architects as periphery
connection agents reflect on the potential alienating properties of the artifacts they employ and
make efforts to develop new artifacts which might enhance their effectiveness at the
boundaries of their practices.
A potential challenge for architects could be to balance the efforts invested in periphery
connections and those used for learning and developing as architects. For example, some
architects in Bank2 found that they spent up to fifty per cent of their working week interacting
with business and technology staff and spent comparatively less time working on architectural
modeling and analysis tasks and interacting as professionals with other architects in their team.
This may mean fewer opportunities for collective learning and improving practices within the
architecture team and developing new artifacts. The potential for limited interactions within
the architecture team has interesting theoretical implications. Wenger’s (1998) theories of
situated learning and community of practice (CoP) are based largely on learning from
interactions within social contexts. For periphery connection agents such as architects,
however, the interactions within their own community are not the focus of their work.
247
Consequently, the learning opportunities for peripheral agents are different to those of CoPs.
Of course, there are opportunities for periphery connection agents to learn from the practices
they span, but this raises interesting issues around the identity, learning and development of
periphery connection agents over time, if a significant part of their learning is occurring from
interactions with practices outside their own.
It is interesting to compare the findings on architects as periphery connection agents with the
characteristics of boundary spanners discussed in chapter three. The view that to be effective
at boundary spanning, individuals need to be well connected internally (Tushman and Scanlan,
1981a, 1981b) and have an ability to adapt to the needs of the other community (Barcellini et
al., 2008) seems to apply for periphery connection agents. For periphery connection agents
such as architects, the connections that seem to be most important are those that occur at the
boundaries of the practices that they connect, but it is the connections they form within their
own CoP which are critical to their learning and professional development.
8.4 Discussing findings in relation to the adopted theoretical perspectives
In Chapter 3, I argued that a useful research perspective would be one that examines the
nature of an EAI through the meanings that architects and their business and technology
stakeholders ascribe to an EAI, recognizes the social nature of work associated with EAI,
focuses on roles and ‘practices’ of architects, and is theoretically informed by the CoP and
boundary spanning perspectives (Wenger 1998). I adopted Walsham’s (2006) suggestion for
case study research and adopted the theoretical lens of CoP and boundary spanning concepts
to inform my initial data collection and then during data analysis, I removed the ‘scaffolds’ and
remained open to field data.
In this section, I discuss the empirical findings of my research in relation to the theoretical
concepts and their underlying assumptions. This discussion is based on suggestions that
researchers need to give consideration to whether or not their findings are theoretically
grounded (Goldkuhl and Cronholm, 2003). The periphery connection concept has not been
systematically applied in research and therefore it has not been developed further than being
seen as a type of connection between two CoPs. Firstly, I discuss the findings in relation to
248
the CoP perspective. Next, I build on this discussion to present a conceptual understanding
of the periphery connection concept.
8.4.1 CoP theory and the findings from the EAI practices of architects
Although practice researchers have no universally accepted definition of the term ‘practice’,
they share a concern for social order and how features embedded in practices (such as
agreements, negotiations, interactions, knowledge, skills, tools) are responsible for or by-
products of the emergence of a shared perspective, methods, tools and objectives within a
social configuration. Practices are associated with a specific social system (Schulz, 2005), are
organized around a shared practical understanding (Schatzki, 2001), shared routines
(Whittington, 2006), and serve to sustain mutual engagement (Wenger, 1998).
Wenger’s (1998) CoP theory makes explicit the processes that lead to social cohesion. The
central assertion of Wenger’s CoP theory is that practices belong to a social context and to
illustrate the forces that lead to social cohesion, Wenger (1998) uses three conceptual
dimensions - mutual engagement, joint enterprise, and shared repertoire (see section 3.3.2,
Wenger’s (1998) Interpretation of Practice). These three dimensions will be considered in relation
to my findings about the EAI practices of architects.
8.4.1.1 Mutual engagement in the context of periphery connections
The mutual engagement dimension suggests that the actions of individuals become meaningful
as a result of engagement among individuals in the same social configuration (Wenger 1998).
However, Wenger’s (1998) assertion may not accurately describe the situation in periphery
connections (see Figure 8.7). Given that many interactions of the architects are with members
of business and technology practices, and there is a relatively reduced opportunity for
engagement amongst the architects themselves when they do not share the same office space,
this suggests the architects’ meaningful actions as periphery connection agents are derived
largely outside of the architecture CoP. By contrast, in situations where architects adopt an
isolationist approach, their actions are meaningful for individuals within the same CoP, but for
individuals outside of that CoP, the actions of the architects have limited meaning. The social
249
configuration that is important for the architects is one that is formed with business
stakeholders on the one hand and with technology stakeholders on the other, or through what
I call ‘periphery engagement’. Assuming architects are typical of other periphery connection
agents, Wenger’s (1998) assertion needs modification in the context of a periphery connection.
My findings suggest that:
• The actions of an individual engaged in a periphery connection become meaningful as
a result of engagement with individuals from other social configurations, (see Figure
8.7).
Thus from a periphery engagement perspective, the architects’ understanding of what
constitutes meaningful action is influenced by their interactions with business and technology
stakeholders and not so much by their mutual engagement with other architects. Given that
‘being included in what matters is a requirement for being engaged’ (Wenger, 1998, p.74), and
‘what matters’ in the architects’ work as periphery practitioners is their work at the boundaries,
I would argue that the meaningful action in a periphery connection results from ‘periphery
engagement’ rather than mutual engagement.
Figure 8.7 Mutual engagement and meaningful actions in periphery connections
250
Given that mutual engagement within the architecture team is limited in periphery
connections, there could be challenges related to learning and compliance with prescribed
methods and tools. Unlike a CoP where learning is a matter of participation in what is
considered important to the group, for periphery connection agents, learning arises from
interactions with participations involved in the periphery connection. This suggests that
members of a periphery connection do not learn in the same way as the members of a CoP
and that there are different learning needs required for members of periphery connections.
Findings from this research suggest that the learning of architects involved in successful
periphery connections is acquired during their interactions with stakeholders and through the
skillful use of models and templates, which promote knowledge exchange and learning. This
is fundamentally different from Wenger’s (1998) notion of learning within a CoP where
mutual engagement is seen as the main source of learning.
My argument is not that physical proximity, institutional affiliation, or frequency of
interaction are irrelevant, but rather that the geography of practice cannot be reduced to
them. Practice is always located in time and space because it always exists in specific
communities and arises out of mutual engagement, which is largely dependent on specific
places and times. Yet the relations that constitute practice are primarily defined by
learning. As a result, the landscape of practice is an emergent structure in which learning
constantly creates localities that reconfigure the geography (Wenger, 1998, pp.129-130).
For architects engaged in an EAI, the sites that become places for learning are the periphery
connections in which they interact with the business and technology stakeholders. Thus, a key
theoretical contribution from this research is to argue that for periphery connections, the
concept of mutual engagement needs to be re-conceptualized as ‘periphery engagement’,
where meaningful action for the periphery connection agent is derived from engagement with
practices other than their own. This finding suggests the need for further research into the
learning that takes place at the boundaries between CoPs.
8.4.1.2 Joint enterprise in the context of periphery connections
Wenger (1998) describes joint enterprise as a source of social cohesion because it is the result
251
of a collective process of negotiation amongst members of the CoP about what is important to
the group (p.77). Further, joint enterprise does not simply mean a stated goal, but represents
the development of mutual accountability amongst individuals in a CoP. Given my re-
conceptualization of mutual engagement as periphery engagement, a reconsideration of the
concept of joint enterprise is also called for, as joint enterprise arises as a result of mutual
engagement. Thus we need to consider whether joint enterprise should be considered as
‘periphery enterprise’ in which the mutual accountability between architects, business and
technology staff is at the boundaries of those respective practices. In the EAI, architects
worked on tasks associated with the revision of the selected technology products and
implementation plans and their accountability was more towards the business and technology
stakeholders than with each other. As ‘being involved in what is important in the architects’
work shifts from the architects’ CoP to their periphery connections with business and
technology stakeholders, the mutual accountability that is important in the architects’ work
also appears to shift to the boundaries. Therefore, I argue that for periphery connections,
periphery engagement is the site at which mutual accountability develops.
8.4.1.3 Shared repertoire and its efficacy in dealing with boundaries
Wenger (1998) argues that over time, individuals engaged in a joint pursuit develop resources
for negotiating meaning between them (p.82). This shared repertoire of resources includes
activities, tools, and methods that the members in a CoP use. Two observations can be made
with respect to the shared repertoire of the architects in both cases. First, the architects used
shared methods and tools to promote shared meaning and social coherence within their teams.
Second, architects who were successful in building a sense of mutual engagement and joint
enterprise with individuals from other CoPs customized their tools and approach to reflect the
nature of the boundary in which they operated.
For architects skilled in dealing with business and technology stakeholders, periphery
engagement involves ‘living in the world’ of the other and speaking their language. Periphery
engagement (i.e. to be involved in what is important) and periphery enterprise (i.e. creating
relations of mutual accountability) for architects differ between dealings with business
stakeholders and dealings with technology stakeholders. For example, when the architects
252
engage with business stakeholders, what is important is the understanding of the business’s
strategic objectives, required business processes and products and services. Hence, mutual
accountability revolves around the progress of architect-business interactions and the selection
of appropriate technology products. When architects engage with technology stakeholders,
what is important is the technology stakeholders’ participation in the selection of technology
products. Mutual accountability between the architects and technology staff revolves around
the progress in their interactions. Thus, the shared repertoire required at the two periphery
engagements (architects-business and architects-technology), should be customized to support
the boundary enterprises that result from those engagements.
The findings of this research suggest that for peripheral connections, the critical dimensions of
engagement and enterprise are located at the boundaries between the intersecting CoPs. The
shared repertoire of the periphery connection would arguably be more effective if it were
customized for periphery engagements (e.g. architects-business and architects-technology).
The tools, methods, and other artifacts that architects use need to help them understand what
is important within each connection (periphery engagement) and enable mutual accountability
to be developed and sustained at each connection (periphery enterprise). This implies the
need to consider different ‘periphery repertoires’ at the connections between architects and
business stakeholders and architects and technology stakeholders and which also takes into
consideration the different boundaries that may arise between them (e.g. architects and
business executives, architects and technology executives, architects and technology project
staff, etc.).
In the next section, I build on this discussion to present an improved theoretical explanation
of the periphery connection concept.
8.4.2 Theorising the periphery connection concept
The periphery connection concept adopted to inform this research is illustrated in Figure 8.8.
As discussed in the previous section, existing CoP theory may not adequately characterize the
social processes associated with periphery connections. A re-conceptualization of the
periphery connection concept is provided in Figure 8.9.
253
Figure 8.8 Adopted theoretical perspective: periphery connections
254
Figure 8.9 New theoretical perspective: periphery connection
255
The new theoretical perspective in Figure 8.9 re-orientates the emphasis of the three
dimensions (mutual engagement, joint enterprise and shared repertoire) of Wenger’s (1998)
CoP theory for a periphery connection. Three observations are possible. First, given the
tendency toward individual liaison work and the amount of time spent in boundary spanning
work, the dimension of mutual engagement amongst periphery practitioners (members of
periphery connection) is less evident. Being involved in what matters and is important for the
periphery practitioners is not so much a matter of engagement amongst the periphery
practitioners themselves as it is between the periphery practitioners and the members of the
CoP that they connect. This engagement, I refer to as periphery engagement. Second,
considering Wenger’s (1998) suggestion that engagement results in a joint enterprise (relations
of mutual accountability), the limited opportunities for engagement amongst the periphery
practitioners and members of their own community would, in turn, mean there is little need
for mutual accountability and joint enterprise amongst them. Periphery engagement may
emphasize relations of mutual accountability between individuals involved in the engagement.
This enterprise, I refer to as periphery enterprise. Third, the detailed technical architecture
models and architecture evaluation criteria used by the architects, seem to be disconnected
from the requirements of the periphery connections where architects engage with other
communities. This raises concerns as to whether the shared repertoire of the architects, their
tools, methods, and artifacts whilst supporting their need for detailed architectural information
also supports their need to ‘live in multiple worlds’. Evidence from this research suggests that
some of the difficulties in an EAI are due to the lack of this capability. The extent to which
the periphery repertoire of architects is able to bridge the different perspectives of business
stakeholders and technology stakeholders, may depend on the extent to which tools, methods,
and artifacts are developed specifically for meeting the challenges of spanning the boundaries
between them (see Table 8.3).
256
Connecting with Challenges
Business
Stakeholders
• Strategic planning and analysis
• Emphasis on non-technology issues
• Recognize and leverage the knowledge and experience of business staff
• Making explicit the differences amongst different levels of business staff
• Identifying and enabling emergent changes to requirements
• Enabling staff to articulate requirements and changes to requirements
• Aligning requirements with cost effective technologies and methods of technology service delivery (e.g. the Cloud)
• Managing staff expectations about the nature the architect’s EAI role
• Communicating to staff the responsibilities and accountabilities of the architect’s role
• Understanding the impact of the EAI on the employment of business stakeholders
Technology
Stakeholders
• Keeping technology staff engaged with the changing nature of business requirements
• Recognizing and leveraging the knowledge and experience of technology staff
• Managing the level of technical detail in architecture documentation to improve relevance for technology staff
• Improve understanding of the potential impact of technology selection and implementation planning on technology projects
• Provide analysis and tools to technology staff
• Understand and support where practicable the information requirements of technology staff
• Provide architectural guidance and assistance to technology staff
• Understanding the impact of the EAI on the employment of technology stakeholders
Table 8.3 Challenges involved in the spanning boundaries with business stakeholders and technology stakeholders
It would be useful to understand the ways in which periphery repertoire can support the
periphery engagement and periphery enterprises of architects. To provide an effective
257
connection with business and technology stakeholders, the tools and methods architects use
need to be customized for supporting periphery engagements and sustaining periphery
enterprises. This repertoire needs to be shared not only amongst the architects, but also with
the communities architects are attempting to connect to. As has been established, the
different practices that the architects connect to have different concerns and objectives, and
therefore, the repertoires supporting periphery connections with these practices may well need
to be customized to accommodate these differing concerns and objectives.
8.5 The efficacy of the periphery connection perspective
As discussed in chapter two, most previous research into EAI characterizes the stakeholder
community as a unified entity and largely ignores the architect-business stakeholder
dimension, the architect-technology stakeholder dimension and the potential finer grain
boundaries within those broad communities. Recent EA literature and research does not
adequately differentiate the different types of stakeholders that architects must engage with
during an EAI. For example, Kettinger et al., (2010) does not differentiate the requirements of
business stakeholders and technology stakeholders, and so does not highlight the important
liaising role that architects play in an EAI. The tendency of researchers not to differentiate the
requirements of business stakeholders and technology stakeholders might imply that this
interaction is considered relatively unproblematic and that the practices and views of both
groups are considered to be similar.
The periphery connection perspective has been effective for gaining insights into the roles and
practices of architects and allowed me to investigate the generally held assumption that
business and technology have similar perspectives associated with an EAI. My findings
suggest that the perspectives of business and technology stakeholders differ quite substantially
and that there are differences in perspectives and concerns within those groups, depending on
the position and responsibilities of individuals. Therefore, the outcomes of EAI activities may
be dependent on not only the effective management of architect-business stakeholder and
architect-technology stakeholder interactions, but also on the management of finer grain
boundaries within those interactions. Ignoring the differences in stakeholder perspectives and
258
concerns suggests an assumption that the effectiveness of understanding and assimilating the
views and concerns of business and technology stakeholders depends only on the architect-
stakeholder interaction. However, my research suggests that the differences between
architects and business stakeholders and architects and technology stakeholders shape the
architects’ EAI role and determine how that role proceeds.
259
Chapter 9
9 CONCLUSIONS
9.1 Introduction
A number of insights and findings that resulted from my research have been discussed in
chapters seven and eight. In this chapter I summarize and highlight the major findings. In
terms of the first research question (What insights into the relationship between the EAI practices of
architects and the outcomes of EAI initiatives are possible using the theoretical lenses of CoP and BSBO
theory?), which was informed by Wenger’s (1998) concepts of mutual engagement, joint
enterprise, and shared repertoire, the major findings that emerged are as follows.
• The conceptual elements of mutual engagement and joint enterprise in Wenger's
(1998) CoP theory are modified in periphery connections. It appears that in periphery
connections, some conceptual properties of those dimensions change. For periphery
connection agents (i.e. individuals responsible for establishing periphery connections),
being involved in what is important is not so much a matter of engagement amongst
individuals from the CoP to which they belong as it is between them and the
individuals of the CoP that they connect with (periphery engagement). In periphery
connections, engagement tends to focus on relations of mutual accountability with
individuals involved in the connection (periphery enterprise).
• Although architects seemed to understand the importance of a shared repertoire of
tools and methods within their own CoP, architects successful in their periphery
engagements were aware of the importance of using different and appropriate methods
260
and tools in interacting with business stakeholders and with technology stakeholders.
Given that architects engage with stakeholders at different levels and from different
areas within business and technology, this may give rise to a need for multiple
periphery repertoires. This finding may generalize to include all enterprise architecture
implementation (EAI) initiatives, not just those investigated in this thesis.
• As periphery connection agents, architects may find it challenging to balance the
efforts invested in establishing connections with those invested for internal group
processes and activities including knowledge sharing, production of architectural
outputs and compliance with prescribed methods and tools.
• The nature of the EAI role of architects seems to vary within and between
organizations. Architects and their stakeholders may have different views about the
EAI role of the architects and what it is that architects do during an EAI. This
variation seems related to differences in perceptions about the importance of the
architect’s role, expectations of what architects do, the priorities of stakeholders, and
the variety of stakeholders. This indicates that the reality-design gap that architects are
expected to bridge is not uniform, but varies according to the different concerns and
objectives of architects and stakeholders (See Figure 8.4).
In terms of research question 2 (What new theoretical insight beyond that provided by CoP and BSBO
theory is possible using grounded theory?), which was focused on understanding the work of
architects as periphery connection agents, the major findings are as follows.
• The practice boundary perspective indicates that an EAI is an ambiguous phenomenon
and boundaries between architects and their stakeholders arise in multiple ways
including through different perceptions and expectations held by architects and
stakeholders about the EAI roles of architects, the priorities of the EAI, and the
outcomes of the EAI initiative.
• In order to bridge the boundaries between themselves and their stakeholders,
architects must develop relational competencies that allow them to assimilate the
perspectives and concerns of their stakeholders in their own responses to a particular
architectural task or problem.
261
• The extent to which architects are able to build mutual engagement with their
stakeholders in an EAI is dependent on their relational competencies. The potential
for ambiguity and variety in an EAI means that architects must be skillful in adapting
their relational competencies to reconcile different perspectives, concerns and
objectives associated with the EAI in order to establish effective connections with
different stakeholders.
• The periphery connection perspective also highlights that business and technology
stakeholders of an EAI are themselves not unified groups. The different views and
concerns expressed by business stakeholders and technology stakeholders may be
evidence of finer grain boundaries (i.e. differences in perspectives) within those
respective groups. However, as stated earlier, the extent to which the different
perspectives indicate finer grain CoPs, is subject to further research.
• The periphery connection perspective highlights the nature of the interactions between
architects and their stakeholders during an EAI. Though architects need to maintain
on-going relationships with business and technology stakeholders, they have direct
engagement with them on an as-needs basis for short-term task specific activities and
once the objectives of their engagement are satisfied, they then disengage from that
interaction.
The rest of this chapter is organized as follows. In section 9.2, I reflect on what I have learnt
about the EAI practices of architects from the two cases. In section 9.3, I discuss the
implications of my findings for EAI practice. In section 9.4, I consider future research that
could be conducted on the basis of the findings of my research. I conclude with a discussion
of the strengths and limitations of my research.
9.2 Reflections on the EAI practices of architects
In reflecting on the EAI practices of architects, it is important that I revisit the concern that
motivated this research.
This research focuses on the concern that EAI failure relates to the challenges that
262
architects face in aligning their interpretations of what is important in an EAI with the
interpretations of business and technology stakeholders (reality-design gap). There are
also challenges arising from the perspectives and approach of existing EAI methods and
tools and there is a need for improving our understanding of the EAI practices of
architects. In the context of this research, EAI failure is viewed to result from architects’
inability to understand the ‘lifeworld’ of stakeholders and inability to bridge the reality-
design gap (Chapter 1).
Although the findings from the two cases cannot be used to generalize the EAI practices of
architects across all industries, if the architects’ practices in these two cases and the responses
from business and technology stakeholders are indicative of what is generally happening in
organizations, we need to reflect upon whether the aim of recognizing and assimilating what is
important to stakeholders is achievable and how we may respond to the suggestion that there
is a need for considerable improvement in architecture practices (Ross et al., 2006).
Throughout chapters six and eight, I provided examples of how in one organization the
practices of the architects, performed most likely with good intentions and belief in the
appropriateness of their actions, were not perceived positively by either business stakeholders
or technology stakeholders. Specific concerns expressed by these stakeholders included the
failure to involve business and technology staff in the selection of technology products,
withholding important product and implementation information from technology projects, the
failure to recognize and leverage the expertise of business and technology staff, the emphasis
on highly detailed and complex architectural models that had dubious practical value, the
emphasis on governance and control rather than collaboration and influence, failure to
understand the emotional impact of the EAI on some executive staff, and a preference for
using online systems for communicating with technology staff. Manifestly, there was a
disconnection between the architects’ practices and the expectations of business and
technology stakeholders and this suggests that many challenges associated with EAI arise from
the practices and orientation of architects.
Given that architects are largely responsible for understanding and assimilating into their
understanding of a particular architectural problem or task, the concerns and requirements of
business and technology stakeholders, this disconnection is proof that we need to consider
263
some of the attitudes displayed by the architects. The attitudes apparent from the comments
of architects suggest probable reasons why difficulties may arise in architect and business
stakeholder and architect and technology stakeholder relationships and how they can lead to
trust-related problems, which in turn, may influence the outcome of an EAI. When architects
do not reflect on their practices and the potentially negative impact of those practices on
support for the EAI, they are unlikely to investigate alternative approaches. Where architects
do reflect on their practices (and also on the criticisms of stakeholders), they are likely to
investigate alternative approaches.
It seems there may be a more fundamental issue that underlies disconnection – the relational
competency of architects and their ability to develop an empathetic understanding of their
stakeholder’s perspective including their concerns, values and objectives. In cases where
architects demonstrated empathy with stakeholders’ perspectives and showed interest in the
fact that business stakeholders and technology stakeholders spoke different languages and
lived in different ‘worlds’, they made efforts to understand the ‘worlds’ of business and
technology stakeholders from the perspective of those individuals. It was also evident that
architects adapted their ‘practices’ (including their approach, language and tools) to be
effective in establishing connections with individuals from those two ‘worlds’.
Where architects developed an empathetic connection with business and technology
stakeholders, they were able to meet the expectations of those stakeholders. Where architects
did not develop an empathetic understanding of the ‘worlds’ of business and technology
stakeholders, the expectation that architects would be able to bridge the gap between
themselves and business and technology stakeholders seemed to fail despite the architectural
methods and tools used by the architects. This perhaps reflects a view held by the architects,
that EA requirements defined during the development of the EA plans are stable, not subject
to change and are something to be ‘taken’ once. Architects adopting this approach, which I
have termed ‘isolationist’ do not make efforts to maintain ongoing relationships with business
and technology stakeholders after the development of the EA plans. Architects appeared to
be more effective when they viewed their role in terms of promoting ongoing learning from
and engagement with business and technology stakeholders.
The challenge for the architects in their periphery connection agent role is to effectively
264
manage the numerous stakeholders who have legitimate interests in the EAI. Given that these
stakeholders may strive for their own ‘interests’, the architects would be expected to balance
the ‘interests’ of the multiple stakeholder groups and factor those interests into their own
interpretation of the architectural problem or task at hand. This may be difficult if one
considers the power differential between business stakeholders and technology stakeholders
and also between individuals within those broad groupings. For example, if a senior business
executive’s interests become a central concern of the architects to the exclusion of other
legitimate interests, the influence of that stakeholder can be evident in the prioritization of
their interests. In such situations, the architects could redress this imbalance by introducing
the concerns other stakeholders may have. However, this could lead architects to try to
constrain executive business stakeholders by trying to limit the frame of reference and possible
requirements options of those stakeholders. These practices would amount to interference, as
the architects would attempt through their practices to constrain one group’s frame of
reference over another. Perhaps it is more helpful to suggest all stakeholders were made aware
of their different requirements. As the role of architects is to build connections of mutual
engagement with business and technology stakeholders, it is critical that architects are aware of
the potential of some stakeholders to bias architectural outcomes toward their interests.
The findings from this research present challenges for the education of architects within our
tertiary institutions. It appears that formal architecture education and training did not feature
prominently in the career paths of architects in either of the organizations examined in this
research. This presents an opportunity to IS academics to reflect on whether formal university
education courses and qualifications sufficiently prepare students to deal with the technical
and relational challenges that architects must face?
Professional organizations may also have a role to play in helping architects to deal with the
technical and relational challenges that arise in practice. The Open Group, CAEAP, GEAO,
IFEAD, and ZIFA promote training programs and certification courses in architecture and
the Association of Enterprise Architecture is developing training and certificate courses in
various aspects of architecture practice. Though these organizations perform an important
function in promoting EA knowledge, they continue to emphasize tools, methodologies, and
documentation, and offer little insight in to the relational aspects of EA and how architects
265
may identify boundaries between themselves and their stakeholders. Though technical
architecture knowledge is critical to the EAI work of architects, architects must also
demonstrate a high level of relational competence in order to bridge the boundaries between
themselves and their stakeholders.
Further, the view of architecture practice evident in some materials and literature promoted by
professional organizations could be further developed to account for the practical realities of
EAI. For example, the definition of architecture promoted by CAEAP recognizes the liaison
role of architects, but emphasizes a technical perspective.
Enterprise architecture enables the design and implementation of the structures that link
an organization’s strategy with its execution. This vital link captures the organizational
strategy as blueprints that include enough guidance and detail for the various parts of the
organization to execute while facilitating collaboration and innovation. Enterprise
Architects use specialized practices to determine where the company is today, scenarios for
where it will be tomorrow, and they provide roadmaps that lead from one stage in the
journey to the next. 9
However, findings from this research suggest that architects may not be always be expected to
work in such an independent fashion and may be required to seek the involvement of business
and technology stakeholders. Also, they may not have sufficient influence within the
organization to deliver their specified technology products without the support and
commitment of those business and technology stakeholders.
Given that there seem to be differences in perspectives between business stakeholders and
technology stakeholders, architects may be more effective in viewing business and technology
as representing different practices. Such a view is in agreement with research that rejects the
homogeneity and unity of organizations (Wenger, 1998).
9 CAEAP, 2015 viewed 18 February 2015 from http://www.caeap.org/wp-content/uploads/2012/04/CAEAP-Brochure-20101.pdf
266
9.3 Implications for practice
In order to improve EAI outcomes, executives responsible for recruiting architects could
reflect on the following fundamental question: how do we get individuals in the architecture
role that are technically competent, but are also relationally competent? In this research, I
noted a tendency to appoint technology experts to architect roles. The appointment of
individuals to architect roles is arguably driven by the assumption that as architects, their
familiarity with a technology domain would enable them to function effectively in an EAI.
While this may be the case in some instances, my findings suggest that stakeholders are also
interested in architects’ skills in building mutual engagement and maintaining ongoing
relationships. Low levels of relational competence may contribute to a failure to understand
the meanings, assumptions, concerns and objectives that stakeholders ascribe to an EAI and
their expectations of the architect’s role. From this, one may conclude that appointing an
individual to an architecture role on the basis of technical subject matter expertise alone may
not be sufficient to ensure a satisfactory outcome in an EAI.
Architects could consider the following suggestions for producing better outcomes from their
interactions with business and technology stakeholders. Firstly, to assist architects understand
the organizational constraints and expectations associated with the EAI, architects should
engage with senior business executives who have authority to fund the selected technology
products and programs of work. As a result of not engaging with these executives, architects
may focus on architectural objectives and not on the concerns and constraints of these
executives. When this occurs, the concerns and constraints surface later when the technology
selection and implementation plans are completed. Secondly, adopting Pawlowski and
Robey's (2004) findings that IT professionals work as knowledge brokers between business
units, architects may help business executives better understand their requirement’s frame of
reference and possibilities by framing their elicitation of requirements in the context of 1)
available commercial products, their functionality and potential business value, 2) the
objectives and concerns of other senior business executives, and 3) the technology strategy of
the EAI.
Thirdly, the practices of architects should accommodate the potentially fluid nature of
business stakeholders’ priorities. The priorities of business stakeholders may evolve during the
267
transition from EA plan development to the implementation of the EA plans. The initial
articulation of requirements associated with the development of the EA plans needs to be
considered tentative. The challenge for architects therefore, is to support business
stakeholders to improve their understanding of business priorities and how these priorities
may change. This may perhaps require the adoption of approaches, activities, and artifacts
that recognize requirements are fluid and subject to change. For example, it may need a
fundamental rethink as to whether architecture artifacts such as complex system models or
tools such as ready-to-use standard modeling notations like UML with their underlying rules
and elicitation requirements effectively support architects to recognize and deal with the
evolving nature of business requirements. It appears that the use of formal and complex
models assumes that requirements are known, stable and therefore ready to be modeled.
Considering how the priorities of business executives may change as external circumstances
may change, this ‘model once’ approach only delays the learning and assimilation of what is
important to the business and can lead business executives to question the appropriateness
and relevance of the selected technology products.
In addition to being technology focused, the success of EAI is influenced by the role of
stakeholders and interactions between architects and stakeholders. Findings from my research
suggest that there are significant differences between architects and technology stakeholders
with regards to systems analysis practices. Architects’ expertise in linking multiple domains of
architecture into an integrated and coherent view of an organization’s technology portfolio
may be useful for planning the technology selection and coordinating the programs of
implementation work, but the efficacy of such work will largely depend on how well architects
are able to assimilate the perspectives and concerns of stakeholders. Firstly, architects need to
appreciate the potential intersections of their EAI work and the project work of technology
staff. Architects’ practices should support the project activities of technology staff and enable
them to understand the implications of the selected technology products and implementation
plans for their own technology projects. Secondly, the implementation plans should support
technology staff to execute those plans. To achieve this, the architects should seek to
understand the level of technical detail required by technology staff so that they are able to
execute those plans. From the perspective of those technology staff responsible for executing
the implementation plans, this could allow them to explore a greater number of project
268
implementation and system configuration choices. Thirdly, architects may be inclined to
generate more information than is required during an EAI. Architects need to be careful not
to ‘clutter’ their EAI work by producing unnecessary technical documentation, which will
leave them less time for important liaising work. Clearly, documentation needs to support
connections between architects and technology stakeholders and architects and business
stakeholders, as well the development of a ‘periphery engagement’ and ‘periphery enterprise’.
The nature of the EAI role of architects has significant implications for their professional
development. A large proportion of architecture work seems to be undertaken by individual
architects working on their own with business and technology stakeholders. Therefore,
architects, because they are involved in periphery connection roles, could potentially
experience less engagement within their own practice. The limited contact that architects may
have with other architects and limited opportunities for formal training, suggests that there
should be a focus on providing adequate professional development opportunities for
architects. One way to achieve this would be to consider online education and training
opportunities that architects could pursue at their convenience and which may result in
professional certification. It would be useful to provide training in a variety of hard and soft
problem solving approaches that architects could apply in their work. For example, it may be
useful for architects to apply Checkland’s (Checkland and Scholes, 1990) Soft Systems
Methodology to situations where there are large differences in the concerns and objectives
between themselves and stakeholders rather than apply more technically focused problem
modeling and solving approaches. Another approach could be through the physical design of
the architects’ office space. Architects should be given an open office space to work in close
proximity with one another. However, this may not always be practicable, as architects may
need to be located near business staff in order to build relationships with them, to understand
their ‘world’ and identify emergent changes in business requirements and constraints.
Learning on the job may not always be an effective and efficient way to improve the
knowledge and skills of architects who are transitioning from a technology to a business
domain or vice versa. Organizations may need to consider relevant university courses to
facilitate the necessary adjustment.
Professional development opportunities provided to architects should also consider the
269
boundary spanning nature of architects’ work. The importance of periphery engagements (i.e.
being involved in what is important to business and technology stakeholders) and periphery
enterprises (i.e. relations of mutual accountability with individuals involved in the connection)
for architects suggests that they need to learn to ‘live in the worlds’ of business and technology
stakeholders. Further, learning strategies would be effective if they not only enable the
architects to understand the ‘worlds’ of business and technology stakeholders, but also enable
business and technology stakeholders to learn about each other and about the ‘world’ of the
architects. An aim of such learning strategies is that business and technology stakeholders
should be encouraged to expand their knowledge beyond their respective domains.
In adopting such learning strategies, architects would be expected to facilitate the exchange of
knowledge between communities. There are implications for approaches that architects may
use to this end. Architects, more than business and technology stakeholders, may need to
recognize and draw attention to the differences in the perspectives between stakeholders, and
aim for achieving a shared understanding amongst them. Focusing on knowledge that is
common to stakeholders is one way to promote the ‘mobilization’ of knowledge across
functional boundaries (Edwards, 2012). Carlile (2004) argues that the key to knowledge
mobilization is the “capacity of the common knowledge to represent the differences and dependencies now of
consequence and the ability of the actors involved to use it” (2004, p. 557). Architects must also be
conscious that ‘as new knowledge is created, new differences and dependencies come into
existence which need to be identified and their consequences understood’ (Carlile, 2004, p.
556). Nowotny (2003) points to the dangers of aiming at the mere distribution of expertise
across boundaries because it might lead to a diluted form of knowledge. She argues that not
all knowledge that is transferred across boundaries is expert knowledge. Here architects must
validate the knowledge and appropriateness of the knowledge of the people they connect with.
This may involve architects validating the knowledge of people involved in periphery
connections with more senior managers and executives because individuals involved periphery
connections may be unqualified. For Nowotny the solution is to focus on task-focused work
across practice boundaries since “experts must now extend their knowledge, not simply to be an extension
of what they know in their specialist field, but to consist of building links and trying to integrate what they
know with what others want to, or should know and do” (Nowotny, 2003, p. 155).
270
There are further implications for the professional development of architects in organizations
where the focus of the architect’s role is managing relationships with stakeholders on an
ongoing basis. Whilst architects involved in periphery connections have episodic and task
focused contact with business and technology stakeholders, they need to maintain ongoing
relationships with business and technology executives in order to maintain continuity of
support for the EAI. Adopting this perspective, however, has implications for the approach,
skills and knowledge that architects may require. For example, in such environments, the
architects would be viewed and trained not so much as architects with a skillset required to
work on short term technical architectural tasks with specific technical outputs, but as
relationship managers that would perhaps need a more relational and long-term approach to
their work.
The relationship manager role has implications for staffing arrangements associated with
periphery connections. It appears that the short-term arrangements associated with periphery
connections may not be appropriate for architects required to function as relationship
managers. Architects performing a relationship manager role would need to take a long-term
view of the task of building and maintaining relationships with stakeholders. Furthermore,
stakeholders may be less willing to invest in building relationships with architects who they
only interact with for short-term activities.
In order to build and maintain effective relations and connections with stakeholders, we may
need to consider the location of architects in the organization structure. For example, the
architects’ location in the organization structure could influence their orientation and the focus
of their role. Architects’ focus on technology and the efforts they invest in selecting
technology products and developing implementation plans, could be influenced by their
location in the technology function (see Figure 5.2). Arguably, in a balanced orientation, one
may expect the architects to give equal consideration to business and technology stakeholder
requirements. Furthermore, in cases where architects are located in the technology function
they may be seen as ‘outsiders’ by business stakeholders, resulting in greater boundary
spanning efforts to connect with business stakeholders. Obversely, if the architects are located
in the business, technology stakeholders may view them as ‘outsiders’. However, evidence
suggests that where architects are able to build and maintain effective periphery enterprises
271
and engagements, their location in the organization structure is not perceived as significant by
business and technology stakeholders.
9.4 Suggestions for future research
A number of interesting research themes have emerged through the course of my research.
My research revealed that technical architecture expertise may not be the only requirement to
be an effective architect; as technical knowledge and skills may prevent a thorough contextual
understanding of stakeholder requirements and perspectives associated with technology
selection and implementation planning. An important research direction therefore would be
one that explores how the analysis and planning practices of architects could support a
thorough analysis of, and question the assumptions and concerns that relate to stakeholder
requirements and constraints. Given the importance of such practices to successful EAI,
future research may ask the following questions:
• What are stakeholders’ perceptions of the technical architecture expertise of architects
and its impact on the effectiveness of the EAI effort?
• What are the perceptions and expectations of architects with regards to understanding
the external and internal organizational context and stakeholder requirements of an
EAI?
The findings may have implications for the extent to which technical specialization is required
in the architecture role. It appears that while architects are required to have specialized
technical skills for undertaking architecture work, the findings of this research indicate the
importance of hybrid roles (roles that have knowledge of two areas) which are needed to build
peripheral connections with business and technology stakeholders. These findings may
provide an improved understanding of whether architects need to be technical specialists as
well as relationally competent, or can architecture subject matter expertise alone make
individuals suitable for the architecture role? The knowledge areas and competencies
prescribed in the materials produced by professional organizations could be reviewed in light
of these findings, providing an improved understanding to aspiring architects about
272
knowledge areas and competencies that they would need to be effective in their work.
My research suggests that whilst some architects do reflect on how tools, processes, and
documentation can be adapted to facilitate connections with business and technology
stakeholders, others do not. This would suggest that some architects do not reflect on the
utility of tools and documentation to support boundary spanning activities and how they can
be developed and implemented so that they support the reconciliation of two quite separate
spheres of interest (architects and business stakeholders, for instance). Interestingly, given the
emphases on modeling and other technical documentation outputs within EA literature, EAI
research literature is relatively quiet on this issue. Taking note of suggestions that objects can
bring individuals from different CoPs closer together and facilitate knowledge transfer across
boundaries (Lindgren et al., 2008); the following research directions would be useful to pursue:
• Given that business stakeholders and technology stakeholders ‘live in different worlds’,
how can the tools and methods of architects be customized to mediate the differences
between them and their stakeholders?
• Can the customization of tools and methods lead to an improvement in relations
between architects and business stakeholders and architects and technology
stakeholders and could these improvements be achieved without the use of tool and
method customization?
• If the customization of tools and methods does have a unique role in enabling
connections between architects and business stakeholders and architects and
technology stakeholders, what are the relational effects of customization?
The insights resulting from such research could support development of resources that would
enable architects to be more effective in their periphery connection work.
Another useful research direction would be one that focuses on improving learning amongst
architects. Given the informal nature of learning in the architecture teams of this research,
research could be conducted to understand what mechanisms for learning and development
would enable architects to develop in their roles whilst taking into account the periphery
connection focus of their work. It is important to note that an architect who is new to a team
may have considerable experience as an architect, but in a new organizational environment,
273
they may still need to undergo considerable learning. Such efforts should also recognize that
mutual engagement amongst architects might not be very high due to the periphery
connection nature of their work, where a significant amount of their time is spent liaising with
stakeholders. Therefore, insight may arise from combining the learning strategies of architects
with learning about the organizational technology portfolio.
Future research may also provide additional theoretical insights into the periphery connection
concept. First, we need to understand more about how periphery connections operate in
organizations. This would give us insights into the motivations of periphery connection
agents and outcomes for organizations in which periphery connections operate. More
specifically, the following questions may be asked:
• What contextual factors may influence periphery connections to be more focused on
the interests of a particular CoP?
• How can we recognize that such orientations exist? To what extent are stakeholders
aware of these orientations and their consequences?
• How do the tools and methods used by architects make it easier for biases to emerge
in periphery connections?
Second, it would be useful to investigate whether or not the mutual engagement and joint
enterprise concepts are evident in periphery connections. Insights in this direction would
contribute towards further development of the periphery connection concept as well to our
understanding of periphery engagement, periphery enterprise, and periphery repertoire. These
insights could be useful for periphery connection agents and organizations as they may lead to
an improved understanding of periphery connections. The research questions that may be
pursued are summarized in Table 8.1 and briefly discussed next.
Conceptual focus Questions that may be asked
Periphery engagement How do periphery connection agents involve themselves with the enterprises of the CoP they connect?
To what extent do members of the CoP encourage periphery
274
connection agents’ involvement in their ‘world’?
How does the organizational context influence periphery connections?
Periphery enterprise What is the nature of the mutual accountability that may arise between participants involved in periphery connections?
How is this mutual accountability developed by the periphery connection agent and members of CoP that they connect?
How and to what extent does mutual accountability influence the enterprise of the periphery connection? To what extent does the mutual accountability influence the enterprise of the CoPs involved in the connection?
Periphery repertoire How do the tools and methods support, or not support, periphery connection agents in establishing periphery engagements and periphery enterprises?
How do periphery connection agents adapt their tools and methods for differences between CoPs they connect with?
Boundaries
In what ways do practices that create a ‘thick’ boundary around a CoP, affect the periphery engagements and periphery enterprises of the periphery connection agents?
How do relationships of mutual accountability within CoPs who have ‘thick’ boundaries influence the development of periphery repertoire?
Table 8.1 Research suggestions for developing the periphery connection concept
Periphery engagement requires that the periphery connection agents are involved in what is
important to the members of the CoP they connect. Insights into the approach periphery
connection agents take to participate at the boundaries of the CoP may provide an
understanding of this engagement from the perspectives of both the periphery connection
agent and the members of the CoP they connect. Understanding the extent to which the CoP
accepts the involvement of the periphery connection agent, may provide insights into the
influence periphery connection agents can actually have on the CoP.
The role of organizational context in influencing periphery connections seems important and
needs to be investigated. There will be some periphery connection agents that will be able to
275
engage more meaningfully than others with the members of CoP that they connect. Insights
into the role organizational context plays in influencing periphery connections and the
orientation of architects are needed to support such connections.
Periphery enterprise involves establishing relations of mutual accountability as a result of
periphery engagement. Future research efforts could investigate the nature of mutual
accountability that arises in a periphery engagement. It would be useful to understand the
basis of mutual accountability, how it develops, and how the work of periphery connection
agents and the CoP they connect is influenced by it.
It would also be of practical value to understand how practices that create impermeable
boundaries around a CoP may influence the work of periphery connection agents. Also, to
what extent do strong relations of mutual accountability within practices that have ‘thick’
boundaries, influence the development of periphery repertoire?
It seems critical to conduct additional research into the tools and methods of the periphery
connection agent and how they can be used to improve mutual understanding within
periphery connections and how they can support periphery engagements and periphery
enterprises. Two challenges may arise for periphery connection agents in practice. The first
challenge is to customize their tools and methods for each boundary (i.e. connection) and the
second is to reconcile the perspectives and expectations of participants at the various
boundaries. It seems the relational challenges in the work of periphery connection agents may
persist unless their tools and methods reflect practices that are responsive to the interests of
the participant groups that they are connecting. This research could suggest ways by which
periphery repertoire can support periphery engagement and sustain periphery enterprise.
To conclude, concerns about the relational competence of architects, the potential for artifacts
to promote effective periphery connections, the professional development of architects
engaged in periphery connections, the role of organizational context and the nature of
boundaries around CoPs present an opportunity for future IS research that is relevant to EA
practitioners as well as to the IS research community. These research directions call for
greater collaboration between researchers and EA practitioners and would result in research
that would advance IS research and improve our understanding of EAI and potentially make a
significant contribution to EAI practice.
276
9.5 Reflections on the strengths and limitations of this research
In this last section, I discuss the strengths and limitations of my research.
In my research, I believe I have demonstrated a sound understanding of the qualitative
research process. I have explicitly reflected on my paradigmatic assumptions and related them
to the planning and implementation of my research. On the basis of my ontological and
epistemological beliefs, I was able to justify the selection of research method, data collection
method, and data analysis method. The selection of interpretive case study as the research
method, semi-structured interviews as the data collection method, and the use of practice
theory to ‘scaffold’ (Walsham, 1995) my research, was justified by the interpretive paradigm
that I adopted in the research. Chapters five, six and seven illustrate the research design and
the data analysis techniques adopted in this research.
In operationalizing the research design and discussing the findings from my data analysis, I
have been mindful of quality criteria for interpretive research. As discussed in chapter four, in
order to discuss the claims of my interpretations, I followed suggestions that interpretive
researchers make explicit their reflections pertaining to research practices and analytical
processes (Walsham, 1995). In chapter four, I also reflected on the research paradigm and
research design. I was also aware that others would have more confidence in my research
findings if I addressed relevant tests in evaluating the quality of research: credibility,
transferability, dependability and confirmability.
However, the research is not without its limitations. Firstly, my research findings are based on
an examination of two cases that involved twenty-five interviews. I cannot, therefore, claim
with certainty that my findings are representative of EAI practice in the wider business
environment. I have therefore been careful to present my findings in a tentative fashion and
have qualified their generalizability, when required.
A second potential limitation relates to the nature of situational inquiry and its core ideal to
engage with a local practice in order to deal with its problematic situation (Goldkuhl, 2011).
Goldkuhl (2011) explains that, in order to make contributions to a local practice (i.e. the
practice under investigation), a situational inquiry must produce three types of results -
diagnostic, design, and implementation. Diagnostic results include knowledge about the
277
condition of the local practice, design results may propose how the situation may be changed,
and implementation results are concerned with making changes to the practice. This research
was primarily concerned with improving understanding of the EAI roles and practices of
architects. My research, therefore, produced diagnosis results in two local practices and
drawing on insights from those practices, I proposed ways in which practice in general may be
improved. My research, however, remains limited by the absence of implementation results.
Implementation results would be useful with regards to ‘testing’ the outcomes proposed by the
diagnostic and design results produced in this research and perhaps achieving some desired
practical outcomes for the EAI practices of architects.
9.6 Concluding remarks
The aim of this research was to undertake practitioner-grounded research into the EAI roles
and practices of architects. The exploratory nature of this research provided many insights
and possible contributions to EAI practice and CoP theory and has led to some suggestions
for future research. In particular, the research has demonstrated that EAI is a socially
complex phenomenon and that in order to build support for and commitment to the EAI,
architects must reconcile the different and variable perspectives and concerns of stakeholders
with their own perspectives and concerns (reality-design gap).
278
10 BIBLIOGRAPHY
Aier, S., & Schelp, J. (2009). A Reassessment of Enterprise Architecture Implementation.
ICSOC/ServiceWave 09. Proceedings of the 2009 International Conference on Service-Oriented
Computing (pp. 35-47). Berlin, Springer-Verlag.
Aldrich, H. E., & Herker, D. (1977). Boundary Spanning Roles and Organizational Structure.
Academy of Management Review, Vol. 2(2), 217-230.
Alwadain, A., Fielt, E., Korthaus, A., & Roseman, M. (2013). A Critical Realist Perspective of
Enterprise Architecture Evolution: Preliminary Findings, 24th Australasian Conference on
Information Systems np. 4-6 Dec 2013, Melbourne.
Amedore, G. H., & Knoff, H. M. (1993). Boundary Spanning Activities and the
Multidisciplinary Team Process: Characteristics Affecting School Psychological Consultation.
Journal of Educational and Psychological Consultation, 4(4), 343-356.
Amin, A., & Roberts, J. (2008). Knowing in Action: Beyond Communities of Practice. Research
Policy, 37(2), 353-369.
Ancona, D. G., & Caldwell, D. (1990). Beyond Boundary Spanning: Managing External
Dependence in Product Development Teams. The Journal of High Technology Management Research,
1(2), 119-135.
Andersson, M., & Lindgren, R. (2010). Enacting Assemblage of Technology: A Practice Lens
Analysis. Proceedings of the 43rd Hawaii International Conference on System Science (pp. 1-10).
Ang, S., & Straub, D. W. (1998). Production and Transaction Economies and IS Outsourcing:
A Study of the U.S. Banking Industry. MIS Quarterly, 22(4), 535-552.
Ankney, R. N., & Curtin, P. A. (2002). Delineating (and Delimiting) the Boundary Spanning
Role of the Medical Public Information Officer. Public Relations Review, 28, 229-241.
Armour, F. J., & Kaisler, S. H. (2001, November/ December). Enterprise Architecture: Agile
Transition and Implementation. IT Pro, 30-37.
279
Armour, F. J., Kaisler, S. H., & Liu, S. Y. (1999a, January/ February). A Big-Picture Look at
Enterprise Architectures. IEEE IT Professional, 1(1), 35-42.
Armour, F. J., Kaisler, S. H., & Liu, S. Y. (1999b, July/ August). Building an Enterprise
Architecture Step by Step. IT Pro, 31-39.
Bacharach, S. B., Bamberger, P., & McKinney, V. (2000). Boundary Management Tactics and
Logics of Action: The Case of Peer Support Providers. Administrative Science Quarterly, 45, 704-
736.
Bailey, D., & Jackson, J. (2003). Qualitative Data Analysis: Challenges and Dilemmas Related
to Theory and Method. American Journal of Occupational Therapy, 57(1), 57- 65.
Barcellini, F., Detienne, F., & Burkhardt, J. (2008). User and Developer Mediation in an Open
Source Software Community: Boundary Spanning through Cross Participation in Online
Direction. International Journal of Human-Computer Studies, 66, 558-570.
Bass, L., Clements, P., & Kazman, R., (2003). Software Architecture in Practice (2nd ed.). Boston:
Addison-Wesley.
Benbasat, I., Goldstein, D. K., & Mead, M. (1987). The Case Research Strategy in Studies of
Information Systems. MIS Quarterly, 11(3), 369-386.
Benbasat, I., & Zmud, R. (1999). Empirical Research in Information Systems: The Practice of
Relevance. MIS Quarterly, 23(1), 3-16.
Bernard, S. A. (2005). Introduction to Enterprise Architecture, AuthorHouse.
Bienvenu, M., Shin, I., & Levis, A. H. (2000). C4ISR Architectures: III. An Object-Oriented
Approach for Architecture Design. Systems Engineering, 3(4), 288-311.
Bijker, W. E., & Law, J. (Eds.). (1992). Shaping Technology/Building Society: Studies in Sociotechnical
Change. Cambridge MA: MIT Press.
Birks, M., & Mills, J. (2011). Grounded Theory: A Practical Guide. London: SAGE Publications.
Blevins, T. (2006). The Architecture of Enterprise Architecture (MITRE Technical Paper 06-0390).
Retrieved from
http://www.mitre.org/work/tech_papers/tech_papers_06/06_0390/06_0390.pdf
280
Blumer, H. (1969). Symbolic Interactionism: Perspective and Methods. Berkely: University of
California Press.
Boar, B. H. (1998). Constructing Blueprints for Enterprise IT Architectures. New York: John Wiley &
Sons.
Boh, W., & Yellin, D. (2006). Using Enterprise Architecture Standards in Managing
Information Technology. Journal of Management Information Systems, 23(3), 163–207.
Boland, R. J. (1979). Control Causality and Information Systems Requirements. Accounting,
Organization and Society, 4(4), 259 -272.
Boland, R. J. (1985). Phenomenology: A Preferred Approach to Research on IS. In E.
Mumford, R. A. Hirschheim, G. Fitzgerald, G. & A. T. Wood-Harper (Eds.), Research Methods
in lnformation Systems (pp. 193-201). North Holland, Amsterdam: Elsevier Science Publishers.
Boland, R. J. (1991). Information System Use as a Hermeneutic Process. In H-E. Nissen, H.
K. Klein, R. A. Hirschheim (Eds.), Information Systems Research: Contemporary Approaches and
Emergent Traditions (pp. 439-464). North Holland, Amsterdam: Elsevier Science Publishers.
Boster, M., Liu, S., & Thomas, R. (2000, July/August). Getting the Most from Your
Enterprise Architecture. IEEE - IT Pro. Retrieved 14 April, 2011 from
<http://app.search.lib.unimelb.edu.au/>
Bourdieu, P. (1977). Outline of a Theory of Practice. Cambridge, Cambridge University Press.
Boudreau, M. C., & Robey, D. (2005). Enacting Integrated Information Technology: A
Human Agency Perspective. Organization Science, 16(1), 3-18.
Boulton, M. R., Lindsay W. M., Franklin, S. G., & Rue L.W. (1982). Strategic Planning:
Determining the Impact of Environment Characteristics and Uncertainty. Academy of
Management Journal, 25(3), 500-509.
Bradley, R. V., Pratt, R. M. E., Byrd, T. A., Outlay, C. N., & Wynn Jnr, D. E. (2012).
Enterprise Architecture, IT Effectiveness and the Mediating Role of IT Alignment in US
Hospitals. Information Systems Journal, 22(2), 97-127.
Brown, J. S., & Duguid, P. (1991). Organizational Learning and Communities-of- Practice:
281
Towards a Unified View of Working, Learning and Innovation. Organization Science, 2(1), 40-57.
Brown, J. S., & Duguid, P. (1998). Organizing Knowledge. California Management Review, 40(3),
90-111.
Brown, J. S., & Duguid, P. (2001). Knowledge and Organization: A Social-Practice
Perspective. Organization Science, 12(2), 198-213.
Bruls, W. A., Steenbergen, M. van., Foothuis, R. M., Bos, B., & Brinkemper, S. (2010).
Domain Architectures as an Instrument to Refine Architecture. Communications of the Association
of Information Systems, 27, 517-540.
Buchanan, R. D., & Soley R. M. (2002). Aligning Enterprise Architecture and IT Investments with
Corporate Goals. Massachusetts: Object Management Group.
Burrell, G., & Morgan, G. (1979). Sociological Paradigms and Organizational Analysis. London:
Heinemann Books.
Carlile, P. (2002). A Pragmatic View of Knowledge and Boundaries: Boundary Objects in New
Product Development. Organization Science, 13(4), 442-455.
Carlile, P. (2004). Transferring, Translating, and Transforming: An Integrative Framework for
Managing Knowledge Across Boundaries. Organization Science, 15(5), 555-568.
Carlock, P. G., & Fenton, R. E. (2001). System of Systems (SoS) Enterprise Systems
Engineering for Information-Intensive Organizations. Systems Engineering, 4(4), 242–261.
Carlock, P. G., & Lane, J. A. (2006). System of Systems Enterprise Systems Engineering, The Enterprise
Architecture Management Framework, and System of Systems Cost Estimation (Technical Report, 2006).
Retrieved from http://sunset.usc.edu/csse/TECHRPTS/2006/usccse2006-618/usccse2006-
618.pdf
Carlson, W. M. (1979). Business Information Analysis and Integration Technique (BIAIT) -
The New Horizon. Data Base, 10(4), 3-9.
Carlson, E. D., Grace, B. & Sutton, J. (1977). Case Studies of End User Requirements for
Interactive Problem-Solving Systems. MIS Quarterly, 1(1), 51-63.
Cavaye, A. L. M. (1996). Case Study Research: A Multi-Faceted Research Approach for IS.
282
Information Systems Journal, 6(3), 227-242.
Charmaz, K. (2006). Constructing Grounded Theory - A Practical Guide Through Qualitative Analysis.
Los Angeles: SAGE Publications.
Checkland, P. (1991). From Framework Through Experience to Learning: The Essential
Nature of Action Research. In H-E. Nissen, H. K. Klein, R. A. Hirschheim (Eds.), Information
Systems Research: Contemporary Approaches and Emergent Traditions (pp. 397-403). North Holland,
Amsterdam: Elsevier Science Publishers.
Checkland, P., & Scholes, J. (1990). Soft Systems Methodology in Action. Chichester: John Wiley &
Sons.
Chia, R., & Mackay, B. (2007). Post-processual Challenges for the Emerging Strategy-as-
Practice Perspective: Discovering Strategy in the Logic of Practice. Human Relations, 60(1), 217-
242.
Chua, W. F, (1986). Radical Developments in Accounting Thought. The Accounting Review, 61,
601-632.
Cohendet, P., Creplet, P., & Dupouet, O. (2001). Communities of Practice and Epistemic
Communities: A Renewed Approach of Organisational Learning within the Firm. Retrieved from
http://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=1&ved=
0CCMQFjAA&url=http%3A%2F%2Fwww.researchgate.net%2Fprofile%2FPatrick_Cohende
t%2Fpublication%2F228587324_Communities_of_practice_and_epistemic_communities_a_r
enewed_approach_of_organisational_learning_within_the_firm%2Flinks%2F004635150659fd
c78a000000.pdf&ei=0YhBVfu2J8bAmAWQgIHIDQ&usg=AFQjCNGFj6glEW4Xhju9guRA
pTrirPBjPw&bvm=bv.92189499,d.dGY
Cook, S. D. N., & Brown, J. S. (1999). Bridging Epistemologies: The Generative Dance
Between Organizational Knowledge and Organizational Knowing. Organization Science, 10(4),
381-400.
Cousins, K. C., & Robey, D. (2005). Human Agency in a Wireless World: Patterns of
Technology Use in Nomadic Computing Environments. Information and Organization, 15(2),
151-80.
283
Cox, A. (2005). What are Communities of Practice? A Comparative Review of Four Seminal
Works. Journal of Information Science, 31(6), 527-540.
Creplet, F., Dupouet, O., Kern, F. B, M., & Munier, B. (2001). Consultants and Experts in
Management Consulting Firms. Research Policy, 30(9), 1517-1535.
Creswell, J. W. (2007). Qualitative Inquiry and Research Design: Choosing Among Five
Approaches. Los Angeles: SAGE Publications.
Cronholm, S., & Goldkuhl, G. (2002). Actable Information Systems - Quality Ideals Put Into
Practice. Proceedings of the 11th International Conference on Information Systems Development, Riga.
Retrieved from http://www.vits.org/publikationer/dokument/245.pdf
Cronholm, S., & Goldkuhl, G. (2004). Conceptualizing Participatory Action Research – Three
Different Practices. Electronic Journal of Business Research Methods, 2(2). Retrieved from
http://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=1&ved=
0CCIQFjAA&url=http%3A%2F%2Fwww.ejbrm.com%2Fissue%2Fdownload.html%3FidArti
cle%3D134&ei=_xyvVI3RAYbamAXXh4KwCQ&usg=AFQjCNHiS6jZp_LlP35NdDr5qHj
56VZIPw&bvm=bv.83339334,d.dGY
Crotty, M. (1998). The Foundations of Social Research. Los Angeles: SAGE Publications.
Darke, P., Shanks, G., & Broadbent, M. (1998). Successfully Completing Case Study Research:
Combining Rigour, Relevance and Pragmatism. Information Systems Journal, 8(4), 273-289.
Davenport, T. H., & Markus, M. L. (1999). Rigor vs. Relevance Revisited: Response to
Benbasat and Zmud. MIS Quarterly, 23(1), 19-23.
Davis, F. D., Bagozzi, R. P., & Warshaw, P. R. (1989). User Acceptance of Computer
Technology: A Comparison of Two Theoretical Models. Management Science, 35(8), 982-1003.
Deetz, S. (1996). Describing Differences in Approaches to Organization Science: Rethinking
Burrell and Morgan and Their Legacy. Organization Science. 7(2), 191-207.
DeMarco, T. (1995). On Systems Architecture. Proceedings of the 1995 Monterey Workshop on
Specification-Based Software Architectures, U.S. Naval Postgraduate School, Monterey, CA. Retrieved
from http://www.systemsguild.com/GuildSite/TDM/Architecture.html In Harrel, J. M.
(2011). Developing Enterprise Architectures To Address The Enterprise Dilemma Of Deciding What
284
Should Be Sustained Versus What Should Be Changed. (PhD Thesis). George Mason University,
Fairfax, Virginia.
DeSanctis, G. (2003). The Social Life of Information Systems Research: A Response to
Benbasat and Zmud’ Call for Returning to the IT Artifact. Journal of the Association for Information
Systems, 4(7), 360-376.
Diamond, M., Allcorn, S., & Stein, H. (2004). The Surface of Organizational Boundaries: A
View from Psychoanalytic Object Relations Theory. Human Relations, 57(1), 31-53.
Dul, J., & Hak, T. (2008). Case Study Methodology In Business Research. Oxford: Butterworth-
Heinemann.
Eaton, B., Elaluf-Calderwood, S., Sorensen, C., & Yoo, Y. (2015). Distributed Tuning of
Boundary Resources: The Case of Apple’s iOS Service System. MIS Quarterly, 39(1), 217-243.
Edwards, A. (2012). The Role of Common Knowledge in Achieving Collaboration Across
Practices, Learning. Culture and Social Interaction, 1, 22-32.
E-Government Act of 2002, Pub. L. No. 107-347, § 101, 116 Stat. 2899 (2002). Retrieved
from http://www.cio.noaa.gov/itmanagement/egovact.pdf
Eisenhardt, K. M. (1989). Building Theories from Case Study Research. The Academy of
Management Review, 14(4), 532-550.
Eisenhardt, K. M., & Graebner, M. E. (2007). Theory Building From Cases: Opportunities and
Challenges. Academy of Management Journal, 50(1), 25-32.
Elkjaer, B., & Simpson, B. (2006). Towards a Pragmatic Theory of Creative Practice. Second
Organization Studies Summer Workshop, Mykonos, Greece. Retrieved from
http://pure.au.dk/ws/files/58/Elkjaer_Simpson_OS_2006.pdf
Ellis, W. J., Hilliard R. F. II., Poon, P. T., Rayford, D., Saunders, T. F., Sherlund, B., & Wade,
R. L. (1996). Toward a Recommended Practice for Architectural Description, Proceedings of the
2nd IEEE International Conference on Engineering of Complex Computer Systems, Montreal.
Retrieved from http://www.iso-architecture.org/ieee-1471/toward.pdf
Enterprise Architects. (2013). 9 Trends for Business and Architects in 2013. Retrieved from
285
http://enterprisearchitects.com/9-trends-worth-following-in-2013/
Esswein, W., & Weller, J. (2008). Unternehmensarchitekturen-Grundlagen, Verwendung und
Frameworks. HMD-Praxis der Wirtschaftsinformatik , 262, 6– 18. In Simon, D., Fischbach, K., &
Schoder, D. (2013). An Exploration of Enterprise Architecture Research. Communications of the
Association for Information Systems, 32, 1-72.
Feldman, M. S., & Orlikowski, W. J. (2011). Theorising Practice and Practicing Theory.
Organization Science, 22(5), 1240-1253.
Finney, S., & Corbett, M. (2007). ERP Implementation: A Compilation and Analysis of
Critical Success Factors. Business Process Management Journal, 13(3), 329–347.
Fontana, A., & Frey, J. H. (2000). The Interview from Structure Questions to Negotiated Text.
In K. Denzin & Y. S. Lincoln (Eds.), Handbook of Qualitative Research (645-672). Thousand
Oaks, CA: SAGE Publications.
Fox, S. (2000). Communities of Practice, Foucault, and Actor- Network Theory. Journal of
Management Studies, 37(6), 853-867.
Franz, C. R., & Robey, D. (1984). An Investigation of User-Led System Design: Rational and
Political Perspectives. Communications of the ACM, 27(12), 1202-1217.
Frisk, J. E., Bannister, F., & Lindgren, R. (2014). Evaluation of Information Systems
Investments: A Value Dials Approach to Closing the Theory-Practice Gap. Journal of
Information Technology, May, 1-17.
Fuller, A., Hodkinson, H., Hodkinson, P., & Unwin, L. (2005). Learning as Peripheral
Participation in Communities of Practice: A Reassessment of Key Concepts in Workplace
Learning. British Educational Research Journal, 31(1), 49-68.
Garrety, K., Robertson, P., & Badham, R. (2004). Integrating Communities of Practice in
Technology Development Projects. International Journal of Project Management, 22(5), 351-358.
Gartner. (2013). Gartner Says Enterprise Architecture Is Key to Driving Digital Strategy.
Retrieved from http://www.gartner.com/newsroom/id/2586115
Gersick, C. (1988). Time and Transition in Work Teams: Toward a New Model of Group
286
Development. Academy of Management Journal, 31, 9-41.
Gherardi, S. (2006). Organizational Knowledge: The Texture of Workplace Learning. Oxford:
Blackwell Publishing.
Gherardi, S. (2009). Introduction: The Critical Power of the ‘Practice Lens’. Management
Learning, 40(2), 115-128.
Giddens, A. (1984). The Constitution of Society: Outline of the Theory of Structuration. Cambridge,
Polity Press.
Glaser, B. G. (1992). Basics of Grounded Theory Analysis. Mill Valey, CA: Sociology Press.
Glaser, B. & Strauss, A. (1967). The Discovery of Grounded Theory: Strategies Of Qualitative Research.
London: Weidenfeld and Nicholson.
Goguen, J. A. (1993). Social Issues in Requirements Engineering. Proceedings of IEEE
International Symposium on Requirements Engineering. San Diego, California. Retrieved from
http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=896&filter%3DAND%28p_I
S_Number%3A7734%29&pageNumber=2
Goguen, J. A. (1994). Requirements Engineering as the Reconciliation of Social and Technical
Issues. In M. Jirotka &J. A. Goguen (Eds.), Requirements Engineering (pp. 165-199): Academic
Press Professional, Inc.
Goldkuhl, G. (2011). In I. Julkunen & G. Goldkuhl (Eds.), Theorizing and Situational Inquiry in
Practice Research. Paper presented at the International and Inter-Disciplinary Workshop on
Practice Research (Pre- ECIS 2011), Helsinki, Finland. Retrieved from
http://www.vits.org/uploads/PracticeResearch2011/GGPracticeResearch.pdf
Goldkuhl, G., & Cronholm, S. (2003). Multi-Grounded Theory - Adding Theoretical
Grounding to Grounded Theory. Proceedings of the 2nd European Conference on Research Methods in
Business and Management (ECRM 2003), Reading, UK. Retrieved from
http://www.vits.org/publikationer/dokument/336.pdf
Goodhue, D. L., Kirsch, L. J., Quillard, J. A., & Wybo, M. D. (1992). Strategic Data Planning:
Lessons From The Field. MIS Quarterly, 16(1), 11–34.
287
Goulding, C. (Ed.) (2002). Grounded Theory. Los Angeles: SAGE Publications.
Gregor, S., Hart, D., & Martin, N. (2007). Enterprise Architectures: Enablers Of Business
Strategy And IS/IT Alignment In Government. Information Technology and People, 20(2), 96-120.
Guba, E. G., & Lincoln, Y. S. (1994). Competing Paradigms in Qualitative Research. In K.
Denzin & Y. S. Lincoln (Eds.), Handbook of Qualitative Research (105-117). California, Thousand
Oaks: SAGE Publications.
Hagan, P. J. (Ed). (2004). Guide to the (Evolving) Enterprise Architecture Body of Knowledge, Draft, 6
February 2004. Retrieved from
http://www.mitre.org/work/tech_papers/tech_papers_04/04_0104/index.html
Hammer, M., Champy, J., & Davenport, D. (1986, June). Dispersion and Interconnection:
Approaches to Distributed Systems Architecture, Partnership for Research in Information Systems
Management (PRISM). Retrieved from
https://c.ymcdn.com/sites/www.globalaea.org/resource/collection/EAAC3D6C-D447-
451C-AC5F-6E1DC7788D42/PRISM_Report.pdf
Harmon, K. (2005). The “Systems” Nature of Enterprise Architecture. IEEE International
Conference on Systems, Man and Cybernetics, 1, 78-85.
Harrel, J. M. (2011). Developing Enterprise Architectures To Address The Enterprise Dilemma Of
Deciding What Should Be Sustained Versus What Should Be Changed (PhD Thesis). George Mason
University, Fairfax, Virginia.
Harris, S., & Sutton, R. (1986). Functions of Parting Ceremonies in Dying Organisations.
Academy of Management Journal, 29, 5-30.
Heeks, R. (2002). Information Systems and Developing Countries: Failure, Success, and Local
Improvisations. Information Society, 18(2), 101-112.
Henderson, J. C., & Venkatraman, N. (1993). Strategic Alignment: Leveraging Information
Technology for Transforming Organizations. IBM Systems Journal, 32(1), np.
Hernes, T. (2003) Enabling and Constraining Properties of Organizational Boundaries. In N
Paulsen and T Hernes (Eds.), Managing Boundaries in Organizations: Multiple Perspectives (pp. 35-
54). New York: Palgrave Macmillan.
288
Hernes, T. (2004). Studying Composite Boundaries: A Framework of Analysis. Human
Relations,
57(1), 9-29.
Hirschheim, R. (1985). User Experience With an Assessment of Participative Systems Design.
MIS Quarterly, 9(4), pp. 295-304.
Hirschheim, R., & Klein, H. (2003). Crisis in the IS Field? A Critical Reflection on the State of
the Discipline. Journal of the Association for Information Systems, 4(10), 237-293.
Hislop, D. H. (2005), Knowledge Management in Organizations: A Critical Introduction. Oxford
University Press.
Hjort-Madsen, K. (2006). Enterprise Architecture Implementation and Management: A Case
Study, Proceedings of the 39th Hawaii International Conference on System Sciences, 1-10. Retrieved from
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1579432&url=http%3A%2F%2Fiee
explore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1579432
Hughes, J., & Wood-Harper, T. (1999). Addressing Organisational Issues in Requirements
Engineering Practice: Lessons From Action Cases. Australasian Journal of Information Systems,
6(2), 64-74.
Hult, M., & Lennung, S. (1980). Towards a Definition of Action Research: A Note and a
Bibliography. Journal of Management Studies, 17, 241-250.
Iivari, J., Hirschheim, R., & Klein, H. (1998). A Paradigmatic Analysis Contrasting
Information Systems Development Approaches and Methodologies. Information Systems
Research, 9, 164–193.
Information Technology Management Reform Act of 1996, Sections 5001-5142 Retrieved
from http://govinfo.library.unt.edu/npr/library/misc/s1124.html
Institute of Electrical and Electronics Engineers. (2000). 1471-2000 - IEEE Recommended
Practice for Architectural Description for Software-Intensive Systems, IEEE Computer Society.
Retrieved from http://www.enterprise-
architecture.info/Images/Documents/IEEE%201471-2000.pdf
289
Isomäki, H., Liimatainen, K., & Valtonen, K. (2008). Challenges and Collaboration Opportunities of
Enterprise Architecture Work. Ministry of Finance. Finland.
ISO/IEC (1996). Reference Model for Open Distributed Processing. In Harrel, J. M. (2011). Developing
Enterprise Architectures To Address The Enterprise Dilemma Of Deciding What Should Be Sustained
Versus What Should Be Changed (PhD Thesis). George Mason University, Fairfax, Virginia.
Iverson, J. O., & McPhee, R. D. (2002). Knowledge Management in Communities of Practice:
Being True to the Communicative Character of Knowledge. Management Communication
Quarterly, 16(2), 259-266.
Iverson, J. O., & McPhee, R. D. (2008). Communicating Knowing Through Communities of
Practice: Exploring Communicative Processes and Differences Among CoPs. Journal of Applied
Communication Research, 36(2), 176-199.
Janssen, M., & Hjort-Madsen, K. (2007). Analyzing Enterprise Architecture in National
Governments: The Cases of Denmark and the Netherlands. Proceedings of the 40th Hawaii
International Conference on System Sciences (np). Retrieved from
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4076820&url=http%3A%2F%2Fiee
explore.ieee.org%2Fiel5%2F4076361%2F4076362%2F04076820.pdf%3Farnumber%3D4076
820
Janssen, M., & Klievink, B. (2010). ICT-Project Failure in Public Administration: The Need to
Include Risk Management in Enterprise Architectures. Proceedings of the 11th Annual International
Conference on Digital Government Research on Public Administration Online: Challenges and Opportunities,
Puebla, Mexico (pp. 147-152). Retrieved from http://dl.acm.org/citation.cfm?id=1809903
Jarzabkowski, P., Balogun, J., & Seidl, D. (2007). Strategizing: The Challenges of a Practice
Perspective. Human Relations, 60(1), 5-27.
Jonkers, H., Lankhorst, M., van Burren, R., Hoppenbrouwers, S., & Bonsangue, M. (2003).
Concepts for Modelling Enterprise Architecture. Via Nova Architectura. Retrieved from
http://www.via-nova-architectura.org/proceedings/lac-2003/concepts-for-modeling-
enterprise-architectures-2.html
Jonsson, K., Holstrom, J., & Lyytinen, K. (2009). Turn to the Material: Remote Diagnostic
290
Systems and New Forms of Boundary Spanning. Information and Organization, 19, 233-252.
Josey, A., Harrison, R., Homan, P., Rouse, M. F., van Sante, T., Turner, M. & van der Merwe,
P. (2009). TOGAF Version 9 – A Pocket Guide. Reading, UK: The Open Group.
Kabai, I. (2013, 26th March). 8 Reasons Enterprise Architecture Programs Fail. InformationWeek
Government. Retrieved from http://www.informationweek.com/it-leadership/8-reasons-
enterprise-architecture-programs-fail/d/d-id/1109248?
Kappelman, L. A. (Ed.). (2010). The SIM Guide to Enterprise Architecture. London: CRC Press.
Kerner, D. (1979). Business Information Characterization Study. Data Base, 10(4), 10-17.
Kettinger, W. J., Marchland, D. A., & Davis, J. M. (2010). Designing Enterprise IT
Architectures To Optimize Flexibility and Standardization in Global Business. MIS Quarterly
Executive, 9(2), 95 - 113.
Kickert, W., J. M., Klijn, E-H., & Koppenjan, J. F. M. (1997). Introduction: A Management
Perspective on Policy Network. In W. J. M Kickert, E-H Klijn and J. F. M Koppenjan (Eds.),
Managing Complex Networks: Strategies for the Public Sector. London: SAGE Publications.
Klein, H., & Hirschheim, R. (2008). The Structure of the IS Discipline Reconsidered:
Implications and Reflections from a Community-of-Practice Perspective. Information &
Organization, 18(4), 280-302.
Klein, K., & Kozlowski, S. (2000). From Micro to Meso: Critical Steps in Conceptualizing and
Conducting Multilevel Research. Organizational Research Methods, 3, 211-236.
Klein, H., & Myers, M. D. (1999). A Set of Principles for Conducting and Evaluating
Interpretive Field Studies in Information Systems. MIS Quarterly, 23(1), pp. 67-94.
Klein, H., & Rowe, F. (2008). Marshalling the Professional Experience of Doctoral Students:
A Contribution to the Practical Relevance Debate. MIS Quarterly, 32(4), 675-686.
Kornak, A., & Distefano, J. (2002). Cap Gemini Ernst & Young Guide to Wireless Enterprise
Application Architecture. New York: John Wiley & Sons.
Krishnan, P., & Ranganathan, C. (2009). Boundary Spanning in Offshored ISD Projects: A Project
Social Capital Perspective. Paper presented at the ACM's Special Interest Group on Management
291
Information Systems, Limerick, Ireland. Retrieved from
http://dl.acm.org/citation.cfm?id=1542175
Kruchten, P. B. (1995). The 4+1 View Model of Architecture, IEEE Software. Retrieved from
http://www.ics.uci.edu/~andre/ics223w2006/kruchten3.pdf
Kvale, S., & Brinkmann, S. (2009). Interviews: Learning the Craft of Qualitative Research Interviewing.
Los Angeles: Sage.
Lankhorst, M. M. (2005). Introduction to Enterprise Architecture. In M. M. Lankhorst, M. E.
Iacob, & H. Jonkers, (Eds.), Enterprise Architecture at Work: Modelling, Communication and Analysis
(pp.1-10). Berlin: Springer-Verlag.
Lankhorst, M.M., Iacob, M.E., & Jonkers, H. (2005). Enterprise Architecture at Work: Modelling,
Communication and Analysis. Berlin: Springer-Verlag.
Lave, J., & Wenger, E. (1991). Situated Learning: Legitimate Peripheral Participation. Cambridge:
Cambridge University Press.
Lee, A. S. (1991). Integrating Positivist and Interpretive Approaches to Organizational
Research. Organization Science, 2(4), 342–365.
Lee, A. S., & Hubona, G. S. (2009). A Scientific Basis for Rigor in Information Systems
Research. MIS Quarterly, 33(2), 237-262.
Leganza, G., Cullen, A., & McGovern, S. (2014). Build a High-Performance EA Practice.
Retrieved from
https://www.forrester.com/Build+A+HighPerformance+EA+Practice/fulltext/-/E-
RES73321
Leifer, R., & Delbecq, A. (1978). Organizational / Environmental Interchange: A Model of
Boundary Spanning Activity. Academy of Management Review, 3(1), 40-50.
Leist, S., & Zellner, G. (2006). Evaluation of Current Architecture Frameworks. Proceedings of
the 2006 ACM Symposium on Applied Computing (pp. 1546– 1553). Retrieved from
http://dl.acm.org/citation.cfm?id=1141635
Levina, N., & Orlikowski, W. J. (2009). Understanding Shifting Power Relations Within and
292
Across Fields of Practice: A Critical Genre Analysis. Academy of Management Journal, 52(4), 672–
703.
Levina, N., & Vaast, E. (2005). The Emergence of Boundary Spanning Competence in
Practice: Implications for Implementation and Use of IS. MIS Quarterly, 29(2), 335-363.
Levina, N., & Vaast, E. (2006). Turning a Community into a Market: A Practice Perspective
on Information Technology Use in Boundary Spanning. Journal of Management Information
Systems, 22(4), 13-27.
Levina, N., & Vaast, E. (2008). Innovating or Doing as Told? Status Differences and
Overlapping Boundaries in Offshore Collaboration. MIS Quarterly, 32(9), 307-332.
Levinson, M. (2011, 20th December). Resume Makeover: How an Enterprise Architect Can
Become a CIO. CIO. Retrieved from http://www.cio.com/article/2401051/careers-
staffing/resume-makeover--how-an-enterprise-architect-can-become-a-cio.html
Levis, A. H. (2009). System Architectures. In Sage, A. P. & Rouse, W. B. (Eds.), Handbook of
Systems Engineering and Management (2nd ed.) (pp. 479-506). New York: John Wiley and Sons.
Liamputtong, P. (2009). Qualitative Research Methods. Oxford: Oxford University Press.
Lindgren, R., Andersson, M., & Henfridsson, O., (2008). Multi-Contextuality in Boundary-
Spanning Practices. Information Systems Journal, 18, 641-661.
Lippert, S., & Anandrajan, M. (2004). Academic vs. Practitioner Systems Planning and
Analysis. Communications of the ACM, 47(9), 91-94.
Locke, K. D. (2003). Grounded Theory in Management Research. London: SAGE Publications.
Luftman, J. N., Lewis, P. R., & Oldach, S. H. (1993). Transforming the Enterprise: The
Alignment of Business and Information Technology Strategies. IBM Systems Journal, 32(1).
Lynch, M. (2001). Ethnomethodology and the Logic of Practice. In T. R. Schatzki & K. Cetina
(Eds.), The Practice Turn in Contemporary Theory. Hoboken: Routledge.
Lysonski, S. (1985). A Boundary Theory Investigation of the Product Manager’s Role. Journal
of Marketing, 49(1), 26 – 40.
Lyytinen, K. (1999). Empirical Research in Information Systems: On Relevance of Practice in
293
Thinking of IS Research. MIS Quarterly, 23(1), 25-28.
McFarlan, F. W., & McKenney, J. L. (1983). The Information Archipelago–Governing the
New World. Harvard Business Review, 61(4), 91-99.
McFarlan, F. W., McKenney, J., & Pyburn P. (1983). The Information Archipelago–Plotting a
Course. Harvard Business Review, 61(1), 145-156.
McGovern, J., Ambler, S. W., Stevens, M. E., Linn, J., Jo, E. L., Sharan, V. (2003). A Practical
Guide to Enterprise Architecture. Englewood-Cliffs, CA: Prentice Hall.
McGrath, K. (2005). Doing Critical Research in Information Systems: A Case of Theory and
Practice Not Informing Each Other. Information Systems Journal, (15), 85-101.
McKay, J., & Marshall, P. (2000). Quality and Rigour of Action Research in Information
Systems. ECIS 2000 Proceedings. Paper 38. Retrieved from http://aisel.aisnet.org/ecis2000/38
McKenny, J L., & McFarlan, F. W. (1979). The Information Archipelago–Maps and Bridges.
Harvard Business Review, 60(5), 109-114.
Marchington, M., Vincent, S., & Cooke, F. L., (2005). The Role of Boundary-Spanning Agents
in Inter-Organizational Contracting. In M. Marchington, D. Grimshaw, J. Rubery and H.
Willmott (Eds.), Fragmenting Work: Blurring Boundaries and Disordering Hierarchies (Books 24x7
version). Retrieved from
http://library.books24x7.com.ezproxy.lib.swin.edu.au/toc.aspx?bookid=12577
Markus, M. L. (1981) Implementation Politics: Top Management Support and User
Involvement, Systems, Objectives, Solutions, 1(4), 203-215.
Markus, M. L., & Lee, A. S. (Eds.). (1999). Foreword. Intensive Research in Information
Systems: Using Qualitative, Interpretative, and Case Methods to Study Information
Technology [Special Issue]. MIS Quarterly, 23(1), 35-38.
Marrone, J. A., Tesluk, P. E., & Carson, J. B. (2007). A Multilevel Investigation of Antecedents
and Consequences of Team Member Boundary-Spanning Behavior. Academy of Management
Journal, 50(6), 1423-1429.
Martin, A. (2012). Enterprise IT Architecture in Large Federated Organizations: The Art of
294
the Possible. Information Systems Management, 29(2), 137-147.
Mason, R. M. (2003). Culture-Free or Culture Bound? A Boundary Spanning Perspective on
Learning in Knowledge Management Systems. Journal of Global Information Management, 11(4),
20-36.
Mason, R. M. (2005). The Critical Role of Librarian/Information Officer as Boundary Spanner
Across Cultures. 71st IFLA General Conference and Council ,Oslo, Norway (pp. 1-18). Retrieved
from http://link.springer.com/chapter/10.1007%2F3-540-71011-6_9#page-1
Mathiassen, L. (1998). Reflective Systems Development. Scandinavian Journal of Information
Systems, 10(1&2), 67-118.
Maxwell, J. A. (1992). Understanding and Validity in Qualitative Research. Harvard Educational
Review, 62(3), 279-300.
Mazmanian, M., Yates, J. & Orlikowski, W. J. (2006). Ubiquitous Email: Individual
Experiences and Organizational Consequences of BlackBerry Use. Academy of Management
Proceedings, Atlanta GA: Academy of Management.
Miller, D. (1997). Enterprise Client/Server Planning. Information Systems Management, 14(2), 89-
104.
Minoli, D. (2008). Enterprise Architecture A To Z: Frameworks, Business Process Modelling, SOA, and
Infrastructure Technology. London: CRC Press.
Moniz, J. (1999), Enterprise Application Architecture. Birmingham: Wrox Press.
Morgan, G. & Smircich, L. (1980). The Case For Qualitative Research. Academy of Management
Review, 5, 491-500.
Mutch, A. (2003). Communities of Practice and Habitus: A Critique. Organization Studies, 24(3),
383-401.
Myers, M. D. (2009). Qualitative Research in Business and Management. London: SAGE
Publications.
Myers, M. D., & Klein, H. K. (2011). A Set of Principles for Conducting Critical Research in
Information Systems. MIS Quarterly, 35(1), 17-36.
295
Namba, Y. (2005). City Planning Approach for Rebuilding Enterprise Information Systems.
(PhD Thesis). Tokyo Institute of Technology. In Schmidt, C., & Buxman, P. (2011).
Outcomes And Success Factors of Enterprise IT Architecture Management: Empirical Insight
From The International Financial Services Industry. European Journal of Information Systems, 20,
168-185.
Newell, S, Robertson, M. Scarbrough, H., & Swan, J. (2002). Managing Knowledge Work. New
York: Palgrave.
Ngwenyama, O. (1991). The Critical Social Theory Approach To Information Systems:
Problems And Challenges. In H. E. Nissen, H. Klein, & R. Hirschheim (Eds.), Information
Systems Research: Contemporary Approaches and Emergent Traditions (pp. 267–280). Amsterdam:
North Holland.
Nicolini, D. (2012). Practice Theory, Work, and Organization. Oxford: Oxford University Press.
Niemann, K. D. (2005). From Enterprise Architecture to IT Governance: Elements of
Effective I T Management. Retrieved from
http://links.enterprisearchitecture.dk/links/files/Final_trial29-03-06.pdf
Nowotny, H. (2003). Dilemma of Expertise. Science and Public Policy, 30(3), 151–156.
Oates, B. J., & Fitzgerald, B. (2007). Multi-Metaphor Method: Organizational Metaphors in
Information Systems Development. Information Systems Journal, 17(4), 421-449.
Office of Management and Budget. (1997). Memorandum for the Heads of Executive
Departments and Agencies, M-97-16, 18 June. Retrieved from
http://www.whitehouse.gov/omb/memoranda_m97-16/
Op’t Land, M., Proper, E., Waage, M., Cloo, J., & Stehuis, C. (2009). Enterprise Architecture:
Creating Value by Informed Governance. Berlin, Springer-Verlag.
Orlikowski, W. J. (1999). Technologies-In-Practice: An Enacted Lens for Studying
Technologies in Practice. Retrieved from
http://dspace.mit.edu/bitstream/handle/1721.1/2742/SWP-4056-42019434.pdf?...
Orlikowski, W. J. (2000). Using Technology and Constituting Structures: A Practice Lens for
Studying Technology in Organizations. Organization Science, 11(4), 404-428.
296
Orlikowski, W. J. (2002). Knowing in Practice: Enacting a Collective Capability in Distributed
Organizing. Organization Science, 13(3), 249-273.
Orlikowski, W. J. (2007). Sociomaterial Practices: Exploring Technology at Work. Organization
Studies, 28(9), 1435-1448.
Orlikowski, W. J., & Baroudi, J. J. (1991). Studying Information Technology in Organizations:
Research Approaches and Assumptions. Information Systems Research, 2(1), 1-28.
O'Rourke, C., Fishman, N., & Selkow, W. (2003). Enterprise Architecture Using The Zachman
Framework. Sydney: Thomson Course Technology.
Parr, A.N., Shanks, G. G., & Darke, P. (1999). Identification of Necessary Factors for
Successful Implementation of ERP Systems, Proceedings of the IFIP TC8 WG8.2 (pp. 99–120).
Patton, M. Q. (2002). Qualitative Evaluation and Research Methods. Newbury Park, CA: SAGE
Publications.
Paulsen, N., & Hernes, T. (2003). Managing Boundaries in Organizations: Multiple Perspectives. New
York: Palgrave.
Payne, G., & Payne, J. (2004). Key Concepts in Social Research. London: SAGE Publications.
Payscale. (2015). Enterprise Architect, IT Salary (Australia). Retrieved from
http://www.payscale.com/research/AU/Job=Enterprise_Architect,_IT/Salary
Pawlowski, S., & Robey, D. (2004). Bridging User Organizations: Knowledge Brokering and
the Work of Information Technology Professionals. MIS Quarterly, 28(4), 645-672.
Pereira, C.M., & Sousa, P. (2004). A Method to Define an Enterprise Architecture Using the
Zachman Framework. Proceedings of the 2004 ACM Symposium on Applied Computing (pp. 1366–
1371).
Peristeras, V., & Tarabanis, K. (2000). Towards an Enterprise Architecture for Public
Administration Using a Top-Down Approach. European Journal of Information Systems, 9(4), 252–
260.
Perks, C., & Beveridge, T. (2003). A Guide to Enterprise Architecture. Berlin: Springer-Verlag.
Perry, D. E., & Wolf, A. L. (1989). Software Architecture. Retrieved from
297
http://users.ece.utexas.edu/~perry/work/papers/swa89.pdf
Porter. M. (1985). Competitive Advantage: Creating and Sustaining Superior Performance. New York:
The Free Press.
Poutanen, J. (2012). The Social Dimension of Enterprise Architecture in Government. Journal
of Enterprise Architecture, 8(2), 19-29.
Rajput, W. E. (2000). E-Commerce systems architecture and applications. Boston: Artech House.
Ramos, I., & Berry, D. M. (2005). Is Emotion Relevant to Requirements Engineering?
Requirements Engineering, 10, 238-242.
Reckwitz, A. (2002). Towards a Theory of Social Practices: A Development in Culturalist
Theorizing. European Journal of Social Theory, 5(2), 243-263.
Reddick, C. (2012). Public Administration and Information Technology. Burlington, MA: Jones and
Bartlett Learning.
Richardson, G., Jackson, B., & Dickson, G. (1990). A Principles-Based Enterprise
Architecture: Lessons from Texaco and Star Enterprise. MIS Quarterly, 14(4), 385–403.
Richardson, H., & Robinson, B. (2007). The Mysterious Case of the Missing Paradigm: A
Review of Critical Information Systems Research 1991-2001. Information Systems Journal,17(3),
251-270.
Roberts, J. (2006). Limits to Communities of Practice. Journal of Management Studies, 43(3), 623-
639.
Robey, D. (1983). Information Systems and Organizational Change: A Comparative Case
Study. Systems, Objectives, Solutions, 3(3), 143-154.
Roeleven, S. (2008). Why Two Thirds of Enterprise Architecture Projects Fail [Electronic
version]. ARIS Expert Paper. Retrieved from http://www.softwareag.com
Ross, J. (2003). Creating a Strategic IT Architecture Competency: Learning in Stages. MIS
Quarterly Executive. 2(1), 31-43.
Ross, J. W., & Beath, C. M. (2006). Sustainable IT Outsourcing Success: Let Enterprise
Architecture Be Your Guide. MIS Quarterly Executive, 5(4), 181 - 192.
298
Ross, J., Weill, P., & Robertson, D. (2006). Enterprise Architecture as Strategy: Creating a Foundation
For Execution. Boston, Harvard Business School Press.
Ross, J.W., & Westerman, G. (2004). Preparing for Utility Computing: The Role of IT
Architecture and Relationship Management. IBM Systems Journal, 43(1), 5–19.
Rouse, W. B. (2005a). Enterprises as Systems: Essential Challenges and Approaches to
Transformation. Systems Engineering, 8(2), 138-150.
Rouse, W. B. (2005b). A Theory of Enterprise Transformation. Systems Engineering, 8(4), 279-
295.
Rozanski, N., & Woods, E. (2007). Software Systems Architecture – Working with Stakeholders using
Viewpoints and Perspectives. Upper Saddle River: Addison-Wesley.
Sage, A. P., & Biemer, S. M. (2007, September). Processes for System Family Architecting,
Design, and Integration. IEEE Systems Journal, 1(1).
Sage, A. P., & Cuppan, C. D. (2001). On the Systems Engineering and Management of
Systems of Systems and Federations of Systems. Information, Knowledge, Systems Management, 2(4),
325-345.
Sage, A. P., & Lynch, C. L. (1998). Systems Integration and Architecting: An Overview of
Principles, Practices and Perspectives. Systems Engineering, 1(3), 176–227.
Sandelowski, M. (1989). The Problem of Rigor in Qualitative Research. Advances in Nursing
Science, 8(3), 27-37.
Schatzki, T. R. (2001). Introduction: Practice Theory. In T. R. Schatzki, K. Cetina & Savigny,
E. von (Eds.), The Practice Turn in Contemporary Theory. Hoboken: Routledge.
Schekkerman, J. (2004a). The Economic Benefits of Enterprise Architecture: How To Quantify and
Manage The Economic Value of Enterprise Architecture. Victoria, BC, Canada: Trafford Publishing.
Schekkerman, J. (2004b). Trends in Enterprise Architecture: How Are Organizations Progressing?
Amersfoort, Netherlands: Institute for Enterprise Architecture Developments.
Schmidt, C., & Buxman, P. (2011). Outcomes and Success Factors Of Enterprise IT
Architecture Management: Empirical Insight from The International Financial Services
299
Industry. European Journal of Information Systems, 20, 168-185.
Schulte, R. (2002). Enterprise Architecture and IT City Planning. Report No. COM-17-2304,
Gartner Research.
Schultze, U., & Orlikowski, W. J. (2004). A Practice Perspective on Technology-Mediated
Network Relations: The Use of Internet-Based Self-Serve Technologies. Information Systems
Research, 15(1), 87-106.
Schulz, P. (2005). Learning in Complex Organizations as Practicing and Reflecting. Journal of
Workplace Learning, 17(8), 493-507.
Segars, A.H., & Grover, V. (1996). Designing Company-Wide Information Systems: Risk
Factors and Coping Strategies. Long Range Planning, (29)3, 381–392.
Seppänen, V. (2009). Experiences on Enterprise Architecture Work in Government Administration.
Retrieved from Finnish Ministry of Finance. Retrieved from
www.vm.fi/vm/en/04_publications_and_documents/01_publications/04_public_manageme
nt/20090121Experi/name.jsp.
Sessions, R. (2008). Simple Architectures for Complex Enterprises. Washington: Microsoft Press.
Shaw, B. (2010) Enterprise Architecture – Will Yours Fail? Retrieved from
http://www.itprojecttemplates.com/WP_EA_Will_Yours_Fail.htm
Shenton, A. K. (2004). Strategies for Ensuring Trustworthiness in Qualitative Research
Projects. Education for Information, 22, 63-75.
Sidorova, A., & Kappelman, L. A. (2010) Enterprise Architecture As Politics: An Actor-
Network Theory Perspective. In L. A. Kappelman (Ed.), The SIM Guide To Enterprise
Architecture, Boca Raton: CRC Press.
Simon, D., Fischbach, K., & Schoder, D. (2013). An Exploration of Enterprise Architecture
Research. Communications of the Association for Information Systems, 32, 1-72.
Simpson, B. (2009). Pragmatism, Mead, and the Practice Turn. Organization Studies, 30(12),
1329-1347.
Smolander, K., & Rossi, M. (2008). Conflicts, Compromises, and Political Decisions:
300
Methodological Challenges of Enterprise-Wide E-Business Architecture Creation. Journal of
Database Management, 19(1), 19-40.
Smolander, K., Rossi, M. & Purao, S. (2008). Software Architectures Blueprint, Literature,
Language or Decision? European Journal of Information Systems, 17, 575-588.
Sowa, J. F. & Zachman, J. (1992). Extending and Formalizing the Framework for Information
Systems Architecture. IBM Systems, 31(3), 590-616.
Spewak, S. H. (1992). Enterprise Architecture Planning: Developing a Blueprint for Data, Applications
and Technology. New York: John Wiley and Sons.
Stahl, B. C., & Brooke, C. (2008). The Contribution of Critical IS Research. Communications of
the ACM, (51:3), pp. 51-55.
Stake, R. (1995). The Art of Case Study Research. Thousand Oaks, California: SAGE Publications.
Stake, R. (2000). Case Studies. In K. N. Denzin & S. L. Yvonna (Eds.), Handbook of Qualitative
Research (435-453). Thousand Oaks, California: SAGE Publications.
Stake, R. (2005). Multiple Case Study Analysis. New York: Guilford Publications.
Star, S. L., & Griesmer, J. R. (1989). Institutional Ecology, ‘Translations’ and Boundary
Objects: Amateurs and Professionals in Berkley's Museum Of Vertebrate Zoology. Social
Studies of Science, 19(3), 387-420.
Steadman, H. J. (1992). Boundary Spanners: A Key Component for the Effective Interaction
of Justice and Mental Health Systems. Law and Human Behaviour, 16(1), 75 – 87.
Strauss, A., & J. Corbin. (1990). Basics of Qualitative Research. Thousand Oaks, California: SAGE
Publications.
Sullivan, H., & Skelcher, C. (2002). Working across Boundaries: Collaboration in Public Services.
Basingstoke: Palgrave Macmillan.
Tamm, T., Seddon, P. B., Shanks, G., & Reynolds, P. (2011). How Does Enterprise
Architecture Add Value to Organisations? Communications of the Association for Information Systems,
28(10). Retrieved from http://aisel.aisnet.org/cais/vol28/iss1/10
Tan, M. T. K., & Hall. W. (2007). Beyond Theoretical and Methodological Pluralism in
301
Interpretivist IS Research: The Example of Symbolic Interactionist Ethnography.
Communication of the Association for Information Systems, 19, 589-610.
TEAF. (2000). Treasury Enterprise Architecture Framework, version 1. Retrieved from
http://en.wikipedia.org/wiki/Treasury_Enterprise_Architecture_Framework
The Open Group (1995). The Open Group Architecture Framework, version 1.0. Retrieved from
http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html
The Open Group. (2003). TOGAF (The Open Group Architecture Framework) Version 8.1.
Retrieved from www.opengroup.org/architecture/togaf8/ downloads.htm.
The Open Group. (2009). TOGAF Version 9 Enterprise Edition. Zaltbommel, Netherlands: Van
Haren Publishing.
Theuerkorn, F. (2005). Lightweight Enterprise Architectures. London: Auerbach Publications.
Thompson, J. D. (1962). Organizations and Output Transactions. American Journal of Sociology,
68(3), 309 – 324.
Tiwana, A., & Konsynski, B. (2010). Complementarities Between Organizational IT
Architecture and Governance Structure. Information Systems Research, 21(2), 288-304.
Trauth, E. M., & Jessup, L. M. (2000). Understanding Computer-Mediated Discussions:
Positivist and Interpretive Analyses of Group Support System Use. MIS Quaterly, 24(1), 43-79.
Tushman, M. L., & Scanlan, T. J. (1981a). Characteristics and External Orientations of
Boundary Spanning Individuals. Academy of Management Journal, 24(1), 83-98.
Tushman, M. L., & Scanlan, T. J. (1981b). Boundary Spanning Individuals: Their Role in
Information Transfer and Their Antecedents. Academy of Management Journal, 24(2), 289-305.
Urquhart, C., Lehmann, H., & Myers, M. M. (2010). Putting the ‘Theory’ Back into Grounded
Theory: Guidelines for Grounded Theory Studies in Information Systems. Information Systems
Journal, 20, 357-381.
U.S. Department of Defense, Defense Science Board. (1994). Report of the Defense Science Board
Summer Study Task Force on Information Architecture for the Battlefield (October). Retrieved from
https://www.google.com.au/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-
302
8#q=report%20of%20the%20defense%20science%20board%20summer%20study%20task%
20force%20on%20information%20architecture%20for%20the%20battlefield
U.S. Department of Defense. (1997). Department of Defense Command, Control, Communications,
Computers, Intelligence, Surveillance and Reconnaissance Architecture Framework (Version 2.0, 18
December). Retrieved from http://www.afcea.org/education/courses/archfwk2.pdf
U.S. Department of Defense. (2004). DoD Architecture Framework Version 1.0, 9. Retrieved
from http://links.enterprisearchitecture.dk/links/files/DoDAF_v1_Deskbook.pdf
U.S. Department of Defense. (2009). Department of Defense Architecture Framework
Version 2.0. Retrieved from
http://dodcio.defense.gov/TodayinCIO/DoDArchitectureFramework.aspx
Vaast, E. (2004). O Brother, Where Are Thou? From Communities to Networks of Practice
Through Intranet Use. Management Communication Quarterly, 18(1), 5-44.
Vaast, E., & Walsham, G. (2005). Representations and Actions: The Transformation of Work
Practices with IT Use. Information and Organization, 15(1), 65-89.
Van de Ven, A. (2007). Engaged Scholarship. Oxford: Oxford University Press.
Van den Berg, M., & van Steenbergen, M. (2006). Building an Enterprise Architecture Practice.
Berlin: Springer-Verlag.
Van der Raadt, B., Bonnet, M., Schouten, S., & van Vliet, H. (2010). The Relation Between
EA Effectiveness and Stakeholder Satisfaction. The Journal of Systems and Software, 83(10), 1954 -
1969.
Van der Raadt, B., Schouten, S., & van Vliet, H. (2008). Stakeholder Perceptions of Enterprise
Architecture, Software Architecture. Lecture Notes in Computer Science, 5292 (pp. 19-34Berlin:
Springer-Verlag.
Vasconcelos, A., da Silva, M. M., Fernandes, A., & Tribolet, J. (2004). An Information System
Architectural Framework for Enterprise Application Integration. Proceedings of the 37th Annual
Hawaii International Conference on System Sciences. Retrieved from
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1265551&url=http%3A%2F%2Fiee
explore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1265551
303
Vashist, R. (2013). A Boundary Practice Perspective on The Roles and Practices of Business
Analysts. (PhD Thesis), Swinburne University of Technology.
Vashist, R., McKay, J., & Marshall, P. (2010). The Roles and Practices of Business Analysts: A
Boundary Practice Perspective. In P. Green, M. Rosemann, & F. Rhode (Eds.), Australasian
Conference on Information Systems (Brisbane, Australia) Proceedings. Retrieved from
http://aisel.aisnet.org/acis2010/50
Vashist, R., McKay, J., & Marshall, P. (2011a). How Well Do We Understand Boundary
Practices? Empirical Evidence From a Practice of Business Analysts. In R. Lindgren & M.
Wiberg (Eds.), European Conference on Information Systems (Helsinki, Finland) Proceedings (Paper
158). Retrieved from http://aisel.aisnet.org/ecis2011/158/
Vashist, R., McKay, J., & Marshall, P. (2011b). Reflecting on Use of Practice Theories to
Understand ‘Practices’: A Boundary Practice Perspective on Work of Business Analysts. In G.
Goldkuhl, & I, Julkunen (Eds.), International and Inter-disciplinary workshop on Practice Research,
Helsinki Finland. Retrieved from http://www.vits.org/?pageId=380
Venkatesh, V., Bala, H., Venkatraman, S. & Bates, J. (2007). Enterprise Architecture Maturity:
The Story of the Veterans Health Administration. MIS Quarterly Executive, 6(2), 79 – 90.
Venkatesh, V., Brown, S., & Bala, H. (2013). Bridging the Qualitative-Quantitative Divide:
Guidelines for Conducting Mixed Methods Research in Information Systems. MIS Quarterly,
37(1), 21-54.
Volkoff, O., Elmes, M. B., & Strong, D. M. (2004). Enterprise Systems, Knowledge Transfer
and Power Users. Journal of Strategic Information System, 13, 279-304.
Wagter, R., van den Berg, M., Luijpers, J., van Steenbergen, M. (2005). Dynamic Enterprise
Architecture: How to Make it Work. New York: John Wiley & Sons.
Walsham, G. (1995). Interpretive Case Studies in IS Research: Nature and Method. European
Journal of Information Systems, 74-81.
Walsham, G. (2006). Doing Interpretive Research. European Journal of Information Systems, 15,
320-330.
Walsham, G., & Sahay, S. (1999). GIS For District-Level Administration in India: Problems
304
and Opportunities. MIS Quarterly, 23(1), 36-66.
Weill, P., & Ross, J. (2004). IT Governance: How Top Performers Manage IT Decision Rights for
Superior Results. Boston: Harvard Business School Press.
Wenger, E. (1998). Communities of Practice- Learning, Meaning, and Identity. Cambridge: Cambridge
University Press.
Wenger, E. (2000). Communities of Practice and Social Learning Systems. Organization, 7(2),
225- 246.
Wenger, E. (2010). Communities of Practice and Social Learning Systems: The Career of a
Concept. In Blackmore, C. (Ed.), Social Learning Systems and Communities of Practice. Berlin:
Springer.
Wenger, E., McDermott, R., & Snyder, W. (2002). A Guide to Managing Knowledge: Cultivating
Communities Of Practice. Boston: Harvard Business School Press.
Wenger, E., & Snyder, W. (2000). Communities of Practice: the Organizational Frontier.
Harvard Business Review, January - February, 139-145.
Whittington, R. (2006). Completing the Practice Turn in Strategy Research. Organization Studies,
27(5), 613-634.
Whittle, R., & Myrick, C. B. (2004). Enterprise Business Architecture: The Formal Link Between
Strategy and Results. London: Auerbach.
Williams, P. (2002). The Competent Boundary Spanner. Public Administration. Vol. 80(1) pp 103
–124.
Yin, R. (1989). Case Study Research. California: SAGE Publications.
Yin, R. K. (2003). Applications of Case Study Research (2nd ed.). California: SAGE Publications.
Yin, R. K. (2009). Case Study Research Design and Methods (4th ed.). California: SAGE
Publications.
Yin, R. (2011). Qualitative Research from Start to Finish. New York, Guildford Press.
Zachman, J. A. (1982). Business Systems Planning and Business Information Control Study: A
305
Comparison. IBM Systems Journal, 21(1), 31-53.
Zachman, J. (1987). A Framework for Information Systems Architecture. IBM Systems Journal,
26(3), np.
Zachman, J. A. (2008). John Zachman’s Concise Definition of The Zachman Framework.
Retrieved from https://www.zachman.com/about-the-zachman-framework
Zhu, K., & Kraemer, K. L. (2005). Post-Adoption Variations in Usage and Value of E-
business by Organizations: Cross-Country Evidence from the Retail Industry. Information
Systems Research, 16(1), 61-84.
Zietsma, C., & Lawrence, T. B. (2010). Institutional Work in Transformation of an
Organizational Field: The Interplay of Boundary Work and Practice Work. Administrative Science
Quarterly, 55, 189-221.
306
11 APPENDICES
307
11.1 Case Study Interview Guide
1 Introduction
1.1 Thank interviewee for giving their time.
1.2 Get consent form signed.
1.2 Give overview of the interview and main categories of questions.
1.3 Remind them that they can withdraw from the interview at any time, if they wish.
2 Background and History of Enterprise Architecture Implementation
2.1 Can you describe for me when enterprise architecture was implemented in your organization and how was it implemented?
2.2 Was the implementation considered successful or not? Could you please describe for me the views and feelings that people expressed about the implementation of the enterprise architecture at that time?
3 Motivation for Implementing the Enterprise Architecture
3.1 Why was enterprise architecture implemented? What reasons were given and what changes were expected?
4 Selection of the Enterprise Architecture Implementation Framework
4.1 What enterprise architecture implementation framework was selected and why? Can you describe how the decision to select that framework was made? Were other frameworks considered?
308
5 Implementing the Enterprise Architecture
5.1 Could you describe to me how the enterprise architecture was implemented? If there were problems in implementing the enterprise architecture, could you please explain them?
5.2 How were these problems addressed? What steps did the architects take to resolve the problems? What did the organization do to try and resolve them?
6 Conclusion
6.1 Thank the interviewee for their time and ask them that if they would like to follow up on any of the points discussed in the interview.
309
Additional Questions for Architects
1 Work in the Architecture Team
(Discuss nature of work, individual, team, allocation of work)
2 Work Practices of Architects
(Discuss interactions between architects, motivations for interaction)
3 Professional Development of Architects
(Discuss training opportunities available to architects for learning how to use methods and tools)
4 Discussion of Implementation Methods and Tools
(Discuss the development of implementation methods, choice of modeling methods and tools, problems with methods and tools)
Table 11.1 Case study interview questions
310
11.2 List of Focused Codes
Focused Codes from Case 1
Selecting the technology components; Discussing technology components; Liaising with
vendors; Defining the implementation plans; Classifying projects; Coordinating programs
of work; Working at a high- level; Aligning the implementation plans; Linking components
to the strategy; Focusing on strategic programs; Building global capabilities; Managing
dependencies between programs; Expecting the individual business plans to roll up to an
enterprise plan; Taking a technology perspective; Not involving the business; Evaluating
software and hardware components; Developing evaluation templates; Using architectural
and performance criteria; Not having business or technology involvement; Prioritizing
what they see as important; Ring-fencing their role; Not executing the implementation
plans; Making the business take responsibility for the implementation; Holding the business
to account; Differentiating between architecture and delivery; Having a design
responsibility; Assigning responsibilities for parts of the implementation; Not caring what
others think; Leaving technology to negotiate with the business; Expecting people to
execute the plans as specified; Monitoring the business; Setting goals for the business;
Expecting conflict; Defining new governance models; Distrusting technology; Making the
business accountable; Overseeing the implementation; Preventing rogue behaviour;
Holding technology to account; Seeing governance as necessary; Being responsible for
architecture governance; Scrutinizing all projects; Shutting projects down; “Control freak”
approach to governance; Stabilizing the portfolio; Expecting conflict with the business;
Causing problems for technology projects; Seeing governance as their role; Specifying what
is acceptable behaviour and what is not; Standardizing behaviours; Making architects
accountable; Having team rules; Publishing the rules, Specifying work styles; Regulating
interactions with the business; Making team meetings compulsory; Making architects
accountable to one another; Regulating the use of email; Helping the team to function;
Working through problems together; Clarifying for the team what is important; Clarifying
where architects should focus their efforts; Using team meetings to promote shared
understanding; Having all-day planning workshops; Reviewing the progress of the team
311
against key milestones; Discussing the team milestones for the next year; Linking the
architecture team’s objectives with the CIO’s objectives; Discussing their work; Learning
from other architects; Sharing knowledge within the team; Employing architects with
previous experience; Experienced architects mentoring less experienced architects; Sharing
the same office space; Interacting amongst themselves; Learning by osmosis; Not having
formal architecture training; Interacting with other architects; Engaging/ disengaging;
Working on individual tasks; Being organized according to business divisions; Engaging in
formal and formal settings; Engaging on an as-needs basis; Not using well known
frameworks; Developing their own implementation planning approach; Following a
standard approach; Having a high-level view; Having a technical emphasis; Developing
technically impressive architectural models; Usefulness of highly detailed models; Using
standard notation formats; Borrowing methods from other organizations; Having
consistent artefacts; Delivering the technology strategy; Aligning to the organizational
strategy; Focusing on strategic programs; Aligning business and technology architectures;
Providing direction for technology decision making; Considering the direction of the
banking industry; Considering benefits of new technologies; Working with the business;
Consolidating and standardizing; Giving direction to technology investment; Evolving in a
planned manner; Having external partners; Taking account of outsourcing arrangements;
Explaining the implications for existing contracts; Reducing the number of applications;
Being unable to share customer data; Having a fragmented operating model; Reducing the
complexity of the organization’s portfolio; Retiring legacy systems; Enabling faster
integration; Promoting shared use; Making technology easier to manage; Building common
platforms; Simplifying the portfolio; Supporting the new operating model; Wanting to
engage with the architects on a needs basis; Wanting task specific interactions; Not
expecting to work continuously with the architects; Wanting to discuss challenges with the
EAI; Wanting to plan for the EAI; Wanting to discuss staffing requirements; Wanting to
know impact of EAI to their technology project; Wanting to know about the technology
products; Building the case for the implementation; Getting stakeholder support; Needing
senior executive support; Articulating a business value proposition; Developing mutual
engagement; Selecting appropriate solutions; Understanding the ‘world’ of the business;
Building support through delivery of benefits; Focusing on ‘doing’ rather than ‘planning’;
Focusing on practical outcomes; Balancing theory with pragmatism; Agreeing priorities
with stakeholders; Being participative; Collaborating with stakeholders; Evolving the
architecture; Focusing on urgent problems; Engaging with people who have influence;
312
Building support through networks; Understanding formal organizational processes;
Selecting winners and losers; Changing organizational structures; Making positions
redundant; Fear of losing control; Motivating negative behaviour; Promoting uncertainty;
Not engaging; Communicating selectively; Not liaising with technology project staff; Not
discussing the technology products; Not getting involved with projects; Confusing
stakeholders; Not providing direction; Interacting via a wiki; Making it difficult for people
to engage with them; Not liaising with the business; Not recognizing the expertise of
others; Being reclusive; Being disconnected; Not understanding the ‘world’ of the business;
Working in isolation; Closing ranks; Pursuing “Rolls Royce” solutions; Making unfunded
decisions; Not understanding the constraints of the business; Not appreciating the Global
Financial Crisis; Not understanding business requirements; Not understanding the
dependencies of technology staff; Using a different language; Not being approachable;
Behaving as an elite; Not allowing others to use the term ‘architect’; Affecting careers;
Being seen as arrogant; Putting a cache on the term ‘architect’; Creating distance between
themselves and others.
Focused Codes from Case 2
Selecting technology products; Developing strategic business plans; Linking technology to
business strategy; Linking technology to products and services; Coordinating the
implementation plans; Working closely with the business; Taking into account the product
release strategy; Helping business to link technology to operations; Using strategic planning
tools; Consulting with technology; Having business focused conversations; Acting as a
business analyst; Defining programs of work; Ensuring expected outcomes are delivered;
Building relationships with business stakeholders; Building relationships with technology
stakeholders; Working closely with the business; Working closely with technology;
Relationships rather than governance; Focusing on relationships and networks; Promoting
collaboration; Building mutual respect; Making themselves available; Building trust;
Providing good advice; Delivering on what they promise; Being recognised as successful;
Liaising; Communication being critical; Accepting negative feedback; Running account
meetings with the business; Having a talent for communicating; Having an open and
honest conversation; Building awareness of their role; Engaging in difficult conversations;
Communicating better; Providing opportunities for feedback; Tailoring their language;
Speaking in business-speak; Speaking in technology-speak; Having a skill for
313
communicating; Reflecting on the importance of language; Seeing language as potentially
alienating; Not confusing people; Changing the technologies; Deferring to business
priorities; Understanding priorities change; Engaging with the business to learn about
priorities; Working with technology to provide alternative solutions; Understanding that
the external environment can change; being pragmatic; Prioritizing business goals over
architectural goals; Sharing their knowledge; Sharing the “application master”; Sharing
information about the selected software and hardware; Making life easier for technology
staff; Leveraging their knowledge and tools to build relationships; Providing access to
information; Having standard tools and methods; Being expected to adopt tools and
methods; Giving legitimacy to the architect’s practice; Promoting a sense of belonging;
Having consequences for not complying; Improving architecture outcomes; Meeting
infrequently as a team; Sharing information via reporting lines; Meeting regularly with
senior architects; Discussing modelling approaches; Discussing templates and tools;
Discussing projects; Using on-line tools; Having an online directory (“Planning IT”);
Promoting use of tools in the regions; Promoting greater awareness of soft skills; Valuing
different perspectives; Not having formal architecture training; Being supported to pursue
business related tertiary studies; Not sharing the same office space; Being located in the
business; Learning on the job; Liaising with other architects; Using email and telephone to
facilitate knowledge transfer and acquisition; Belonging to the business or to the
architecture team? Learning from the business; Perceiving skill gaps in the team;
Interacting with business and technology stakeholders; Working on individual tasks;
Liaising with other architects on a needs basis; Having task specific interactions; Engaging/
disengaging; Being organized according to business divisions; Having their own method;
Performing a business-technology gap analysis; Adopting standard documentation
templates; Leveraging strategic business planning models; Developing tools that are
familiar to business; Avoiding technology oriented methods; Having difficulty applying
standardised templates; Making tools available to technology staff; Co-developing tools
with technology and business; Facilitating knowledge exchange; Defining the technology
strategy; Identifying the technology components; Justifying the technology components;
Working toward the target architecture; Understanding business priorities; Increasing the
level of reuse; Introducing new technologies; Simplifying the technology portfolio;
Building common platforms; Building support for the technology components and their
implementation; Emulating successful digital companies; Defining the programs of work;
Coordinating the programs of work; Enabling business change; Applying different
314
architectural approaches; Being frustrated with the systems development lifecycle model;
Being unable to make timely change; Exploiting the technology expertise in the
organization; Making change easier; Wanting to make changes frequently; Wanting to
engage with the architects on an as-needs basis; Expecting task specific interactions; Not
expecting to work continuously with the architects; Wanting to discuss matters as they
arise; Wanting to have access to the architects as required; Consulting to technology
projects; Building support for the technology products; Building support for the
implementation plans; Building support one division at a time; Getting the support of
senior executives; Adopting a practical approach; Helping the business to respond to
external change; Being willing to accommodate changing business priorities; Re-doing the
technology architecture; Providing advice to the business; Helping projects; Prioritizing the
commercial needs of the businesses; Building support is an on-going process; Building a
sense of mutual engagement with business and technology stakeholders; Developing
strong relationships; Working effectively with business and technology; Taking account of
stakeholder’s perspectives and concerns; Supporting business projects; Being willing to
make changes to the technology components; Being willing to make changes to the
implementation plans; Engaging with the business regularly; Being accessible; Liaising with
the business; Liaising with technology; Building agreement; Understanding that
requirements change; Negotiating appropriate solutions to changing requirements;
Investigating alternative technology solutions; Discussing pros and cons of solutions with
technology staff; Discussing proposed solutions with the business; Making decisions with
business and technology; Communicating directly with people; Providing opportunities for
direct contact; Sharing information about the technology components; Sharing
implementation information; Discussing the implementation plans; Holding EAI
information sessions; Providing opportunities for information sharing; Discussing specific
programs associated with the EAI; Allowing people to ask questions; Being available;
Enabling timely access to information; Developing architecture tools with technology staff;
Fostering collaboration; Facilitating knowledge sharing; Negotiating an agreed approach;
Co-developing tools has mutual benefits.
Table 11.2 Focused codes for cases: Bank1 and Bank2
315
11.3 Summary Tables for Discussing Themes
11.3.1 Case 1: Bank1
Theme 1: Architect’s understanding of their role
Category Focused codes Summary of architect’s perspectives
Selecting the technology components and defining the implementation plans
Selecting the technology components; Discussing technology components; Liaising with vendors; Defining the implementation plans; Classifying projects; Coordinating programs of work; Working at a high- level; Aligning the implementation plans; Linking components to the strategy; Focusing on strategic programs; Building global capabilities; Managing dependencies between programs; Expecting the individual business plans to roll up to an enterprise plan; Taking a technology perspective; Not involving the business
• The architect’s understanding of their role is influenced by previous architecture roles
• The architect’s view this work as important to the enablement of the organizational strategy
• They prioritize the technical aspects of this work over the need to build support and commitment amongst the senior business executives
Focusing on architectural goals
Evaluating software and hardware components; Developing evaluation templates; Using architectural and performance criteria; Not having business or technology involvement; Prioritizing what they see as important
• The architect’s values prioritize architectural and performance criteria over other criteria (e.g. business)
316
Not discussing the execution of the implementation plans
Ring-fencing their role; Not executing the implementation plans; Making the business take responsibility for the implementation; Holding the business to account; Differentiating between architecture and delivery; Having a design responsibility; Assigning responsibilities for parts of the implementation; Not caring what others think; Leaving technology to negotiate with the business; Expecting people to execute the plans as specified
• They expect the business and technology to acquire the specified technology products and execute the implementation plans as specified
• They see the implementation of the EA as part of the selection of the technology components and assume that what technology is selected will be implemented
Wanting management control over the implementation plans
Monitoring the business; Setting goals for the business; Expecting conflict; Defining new governance models; Distrusting technology; Making the business accountable; Overseeing the implementation; Preventing rogue behaviour; Holding technology to account; Seeing governance as necessary
• Though the architects expect the business and technology to implement the EA, they nonetheless expect to have management oversight over the efforts of the business and technology
• The architects distrust the motives and values of the business and technology
Stopping projects Being responsible for architecture governance; Scrutinizing all projects; Shutting projects down; “Control freak” approach to governance; Stabilizing the portfolio; Expecting conflict with the business; Causing problems for technology projects; Seeing governance as their role
• The architects want to stabilize the technology portfolio so as to preserve the accuracy and relevance of the selected technology products and implementation plans
• They see themselves fulfilling an important governance role in the organization
Table 11.3 Architect’s understanding of their role - Categories, codes, and summary of architects’ perspectives (Bank1)
317
Theme 2: Practice work within the architecture team
Category Focused codes Summary of architect’s perspectives
Complying with the team charter
Specifying what is acceptable behaviour and what is not; Standardizing behaviours; Making architects accountable; Having team rules; Publishing the rules, Specifying work styles; Regulating interactions with the business; Making team meetings compulsory; Making architects accountable to one another; Regulating the use of email; Helping the team to function
• Need for compliance based on importance given to attendance at team meetings, email etiquette, controlling the level of contact between architects and business and technology stakeholders, etc.
• Compliance is seen as more than adherence to prescribed templates and tools and is looked upon as ‘standardizing’ ways of working
Promoting shared understanding
Working through problems together; Clarifying for the team what is important; Clarifying where architects should focus their efforts; Using team meetings to promote shared understanding; Having all-day planning workshops; Reviewing the progress of the team against key milestones; Discussing the team milestones for the next year; Linking the architecture team’s objectives with the CIO’s objectives; Discussing their work
• The understanding of the architects is shaped within the boundary of their team
• Understanding is based on matters that are important to the ‘smooth’ functioning of the team and the completion of assigned tasks
Practices that contribute to learning
Learning from other architects; Sharing knowledge within the team; Employing architects with previous experience; Experienced architects mentoring less experienced architects; Sharing the same office space; Interacting
• Learning on the job is important for the architects as formal training in architecture is not provided
• Architects learn from each other and this
318
amongst themselves; Learning by osmosis; Not having formal architecture training
is facilitated by them sharing the same office space
• Progression to an architecture role is based on previous architecture experience and is not based on formal training
Nature of work – engaging/ dis-engaging
Interacting with other architects; Engaging/ disengaging; Working on individual tasks; Being organized according to business divisions; Engaging in formal and formal settings; Engaging on an as-needs basis
• The nature of work within the architecture team is based around individually assigned tasks
• Architects engage with one another for the purpose of completing their designated tasks
• Interactions between architects are task-specific and architects must seek out other architects to get the assistance they require
Perspectives on EAI methodology and tools
Not using well known frameworks; Developing their own implementation planning approach; Following a standard approach; Having a high-level view; Having a technical emphasis; Developing technically impressive architectural models; Usefulness of highly detailed models; Using standard notation formats; Borrowing methods from other organizations; Having consistent artefacts
• The challenges of implementing the EA are seen to be not amenable to prominent EA frameworks such as the Zachman and TOGAF
• The architects have developed their own approach
• Modeling templates and methods display a technological emphasis in the architect’s approach
Table 11.4 Practice work within the architecture team - Categories, codes, and summary of architects’ perspectives (Bank1)
319
Theme 3: Business and technology staffs’ perspective
Category Focused codes Summary of business and technology staff’s perspectives
Delivering a technology strategy
Delivering the technology strategy; Aligning to the organizational strategy; Focusing on strategic programs; Aligning business and technology architectures; Providing direction for technology decision making; Considering the direction of the banking industry; Considering benefit of new technologies; Working with the business; Consolidating and standardizing; Giving direction to technology investment; Evolving in a planned manner
• Business and technology participants expect the architects to specify the technology components that will deliver the technology strategy articulated in the EA plans
• The technology components are expected to support the organizational strategy
• The new technology strategy is expected leverage new methods of application and infrastructure service delivery and take into account the technology direction of the banking industry
Considering outsourcing arrangements
Having external partners; Taking account of outsourcing arrangements; Explaining the implications for existing contracts
• The architects are expected to take into account existing outsourcing contracts when selecting new technology products
• This concern is motivated by a desire to not waste money and the need to plan for the expiry of existing outsourcing agreements
320
Addressing problems with the technology portfolio
Reducing the number of applications; Being unable to share customer data; Having a fragmented operating model; Reducing the complexity of the organization’s portfolio; Retiring legacy systems; Enabling faster integration; Promoting shared use; Making technology easier to manage; Building common platforms; Simplifying the portfolio; Supporting the new operating model
• Business and technology participants expect the new EA to address existing problems with the technology portfolio
• There are competing expectations about what the architects are expected to accomplish with the EAI
Engaging on an as-needs basis
Wanting to engage with the architects on a needs basis; Wanting task specific interactions; Not expecting to work continuously with the architects; Wanting to discuss challenges with the EAI; Wanting to plan for the EAI; Wanting to discuss staffing requirements; Wanting to know impact of EAI to their technology project; Wanting to know about the technology products
• Business and technology participants expect to interact with the architects episodically rather than on a continuous basis
• They see their involvement in the implementation as task focused and their interaction with the architects as based on matters that are specifically relevant to them
Building support for the EAI
Building the case for the implementation; Getting stakeholder support; Needing senior executive support; Articulating a business value proposition; Developing mutual engagement; Selecting appropriate solutions; Understanding the ‘world’ of the business; Building support through delivery of benefits; Focusing on ‘doing’ rather than ‘planning’; Focusing on practical outcomes; Balancing theory with pragmatism; Agreeing priorities with stakeholders; Being participative; Collaborating with stakeholders; Evolving the architecture; Focusing on urgent problems; Engaging with people who have influence; Building support through networks; Understanding formal organizational processes
• Business and technology participants view the architects as responsible for building support for and commitment to the technology products and implementation plans
• They expect the architects to exploit peer networks to build influence and also to be aware of formal funding processes
• The architects are expected to explain the business benefits of the EAI. They are also expected to select products that satisfice and also recognize the financial
321
constraints of the businesses
Understanding the impact of the EAI on people
Selecting winners and losers; Changing organizational structures; Making positions redundant; Fear of losing control; Motivating negative behaviour; Promoting uncertainty
• The implementation of the EA will make some management roles redundant and will give rise to new management roles
• These changes are seen to be motivating negative behaviours within the organization and resistance toward the EAI
Table 11.5 Business and technology staffs’ perspective - Categories, codes, and summary of business and technology staffs’ perspectives (Bank1)
322
Theme 4: Interactions with business and technology staff
Category Focused codes Summary of business and technology staff’s perspectives
Not engaging Not engaging; Communicating selectively; Not liaising with technology project staff; Not discussing the technology products; Not getting involved with projects; Confusing stakeholders; Not providing direction; Interacting via a wiki; Making it difficult for people to engage with them; Not liaising with the business; Not recognizing the expertise of others
• The architects are perceived as biased in whom they engage with. The architects do not liaise with technology staff, but have some contact with senior executives
• The architects are seen to not appreciate the extent to which technology staff are dependent on them for information about the technology components and their implementation
Being in an ivory tower
Being reclusive; Being disconnected; Not understanding the ‘world’ of the business; Working in isolation; Closing ranks; Pursuing “Rolls Royce” solutions; Making unfunded decisions; Not understanding the constraints of the business; Not appreciating the Global Financial Crisis; Not understanding business requirements; Not understanding the dependencies of technology staff; Using a different language; Not being approachable
• The architects are seen to keep themselves separate from the ‘worlds’ of the business and technology and to not understand what is important to them
• The architects are seen to be pursuing an idealistic architecture rather than a pragmatic one
323
Behaving as an elite Behaving as an elite; Not allowing others to use the term ‘architect’; Affecting careers; Being seen as arrogant; Putting a cache on the term ‘architect’; Creating distance between themselves and others
• The restriction on the use of the term ‘architect’ has serious consequences for the careers and future employment opportunities of technology staff
• This decision is seen to be devaluing the skills of technology staff
Table 11.6 Interactions with business and technology staff - Categories, codes, and summary of business and technology staffs’ perspectives (Bank1)
324
11.3.2 Case 2: Bank2
Theme 1: Architect’s understanding of their role
Category Focused codes Summary of architect’s perspectives
Selecting the new systems Selecting technology products; Developing strategic business plans; Linking technology to business strategy; Linking technology to products and services; Coordinating the implementation plans; Working closely with the business; Taking into account the product release strategy; Helping business to link technology to operations; Using strategic planning tools; Consulting with technology; Having business focused conversations; Acting as a business analyst; Defining programs of work; Ensuring expected outcomes are delivered
• The architects frame their selection of technology products in terms of the business strategy and the desired products and services of the businesses
• They see the involvement of business and technology staff as important to building support for implementation of the EA
Building relationships Building relationships with business stakeholders; Building relationships with technology stakeholders; Working closely with the business; Working closely with technology; Relationships rather than governance; Focusing on relationships and networks; Promoting collaboration; Building mutual respect; Making themselves available; Building trust; Providing good advice; Delivering on what they promise; Being recognised as successful; Liaising
• The architects place great importance on their relationships with both business and technology since they view these relationships as critical to the implementation of the EA
• The architects seek influence over the business and technology rather than governance control
325
Communicating Communication being critical; Accepting negative feedback; Running account meetings with the business; Having a talent for communicating; Having an open and honest conversation; Building awareness of their role; Engaging in difficult conversations; Communicating better; Providing opportunities for feedback
• Communication is seen as conducive to effective on-going relationships with business and technology
• Having direct contact with stakeholders is also seen as important for identifying potential problems in the relationships with them
Speaking in two languages Tailoring their language; Speaking in business-speak; Speaking in technology-speak; Having a skill for communicating; Reflecting on the importance of language; Seeing language as potentially alienating; Not confusing people
• The architects appreciate the potential of language to bring communities closer together and to also alienate
• The ability to use language that is familiar to the business and facilitates engagement with them is highly valued
326
Being flexible Changing the technologies; Deferring to business priorities; Understanding priorities change, Engaging with the business to learn about priorities; Working with technology to provide alternative solutions; Understanding that the external environment can change; being pragmatic; Prioritizing business goals over architectural goals
• The architects understand that the external environment of the business is not stable and that new opportunities and constraints may emerge
• They understand that they may have to revise their technology selection and implementation plans in light of emerging priorities
• These changes also present opportunities for the architects to collaborate with technology staff and involve them in the implementation of the EA
• This approach is seen as being practical and helpful to the business and useful for building support for and commitment to the implementation
Sharing tools and knowledge with technology staff
Sharing their knowledge; Sharing the “application master”; Sharing information about the selected software and hardware; Making life easier for technology staff; Leveraging their knowledge and tools to build relationships; Providing access to information
• The architects understand that the tools they develop in the course of the EAI may be beneficial to technology staff and are willing to share them
• This is seen as beneficial to the on-going relationship with technology
Table 11.7 Architect’s understanding of their role - Categories, codes, and summary of architects’ perspectives (Bank2)
327
Theme 2: Practice work within the architecture team
Category Focused codes Summary of architect’s perspectives
Complying with the team’s practices
Having standard tools and methods; Being expected to adopt tools and methods; Giving legitimacy to the architect’s practice; Promoting a sense of belonging; Having consequences for not complying; Improving architecture outcomes
• Compliance is viewed as conformance to prescribed methods and tools. Compliance also gives architects a sense of belonging to the architecture practice
Promoting shared understanding
Meeting infrequently as a team; Sharing information via reporting lines; Meeting regularly with senior architects; Discussing modelling approaches; Discussing templates and tools; Discussing projects; Using on-line tools; Having an online directory (“Planning IT”); Promoting use of tools in the regions; Promoting greater awareness of soft skills; Valuing different perspectives
• Shared understanding is seen as important to the consistent use of tools and templates
• The architects also acknowledge there are regions where a shared understanding of tools and templates could be improved
328
Practices that contribute to learning
Not having formal architecture training; Being supported to pursue business related tertiary studies; Not sharing the same office space; Being located in the business; Learning on the job; Liaising with other architects; Using email and telephone to facilitate knowledge transfer and acquisition; Belonging to the business or to the architecture team? Learning from the business; Perceiving skill gaps in the team
• Learning is focused on the use of tools and methods
• Architects learn on the job
• There is no formal architecture training available to architects, though architects are supported to pursue business-related study at a tertiary level
Nature of work – engage/ dis-engage
Interacting with business and technology stakeholders; Working on individual tasks; Liaising with other architects on a needs basis; Having task specific interactions; Engaging/ disengaging; Being organized according to business divisions
• The nature of work within the architecture team is based around individually assigned tasks
• Architects engage with one another for the purpose of completing their designated tasks
• Interactions between architects are task-specific and architects must seek out other architects to get the assistance they require
329
Perspectives on EAI methodology and tools
Having their own method; Performing a business-technology gap analysis; Adopting standard documentation templates; Leveraging strategic business planning models; Developing tools that are familiar to business; Avoiding technology oriented methods; Having difficulty applying standardised templates; Making tools available to technology staff; Co-developing tools with technology and business; Facilitating knowledge exchange
• Methods and tools support the selection of technology components and development of the implementation plans
• Documentation templates are designed to facilitate knowledge transfer between architects and business stakeholders
• There is a need to adapt some templates for some businesses since they function and are structured differently to other businesses
Table 11.8 Practice work within the architecture team - Categories, codes, and summary of architects’ perspectives (Bank2)
330
Theme 3: Business and technology staffs’ perspective
Category Focused codes Summary of business and technology staff’s perspectives
Defining the technology strategy
Defining the technology strategy; Identifying the technology components; Justifying the technology components; Working toward the target architecture; Understanding business priorities; Increasing the level of reuse; Introducing new technologies; Simplifying the technology portfolio; Building common platforms; Building support for the technology components and their implementation; Emulating successful digital companies; Defining the programs of work; Coordinating the programs of work
• The selection of the technology products is expected to give shape to the technology strategy
• The selected technology products are expected to be cost effective
• The architects are also expected to consider new methods of application and infrastructure service delivery such as the Cloud and Platform as a Service
331
Promoting agility Enabling business change; Applying different architectural approaches; Being frustrated with the systems development lifecycle model; Being unable to make timely change; Exploiting the technology expertise in the organization; Making change easier; Wanting to make changes frequently
• The external environment of the business is dynamic and the business needs to pursue market opportunities and respond to constraints as they emerge
• Business participants expect the new EA to support rapid changes such as introducing new systems and interfaces without negative side effects
332
Engaging on an as-needs basis
Wanting to engage with the architects on an as-needs basis; Expecting task specific interactions; Not expecting to work continuously with the architects; Wanting to discuss matters as they arise; Wanting to have access to the architects as required; Consulting to technology projects
• The implementation of the EA is seen to be complex and evolving. As new questions and concerns arise, business and technology participants expect to interact with the architects to address them
• They see their involvement in the implementation as task focused
• Business participants expect to be able to engage with the architects as required on an as-needs basis
333
Building support for the EAI
Building support for the technology products; Building support for the implementation plans; Building support one division at a time; Getting the support of senior executives; Adopting a practical approach; Helping the business to respond to external change; Being willing to accommodate changing business priorities; Re-doing the technology architecture; Providing advice to the business; Helping projects; Prioritizing the commercial needs of the businesses; Building support is an on-going process
• Business and technology participants view support for and commitment to the implementation of the EA as a continuous and on-going discussion rather than a one-off event
• The selection of the technology products and development of the implementation plans is seen to be a continuous planning activity
• Support for the implementation of the EA is based on the extent to which the architects are willing to continuously adapt their plans to the changing needs of the business
Table 11.9 Business and technology staffs’ perspective - Categories, codes, and summary of business and technology staffs’ perspectives (Bank2)
334
Theme 4: Interactions with business and technology staff
Category Focused codes Summary of business and technology staff’s perspectives
Dealing collaboratively with business and technology staff
Building a sense of mutual engagement with business and technology stakeholders; Developing strong relationships; Working effectively with business and technology; Taking account of stakeholder’s perspectives and concerns; Supporting business projects; Being willing to make changes to the technology components; Being willing to make changes to the implementation plans; Engaging with the business regularly; Being accessible
• The architects are perceived to build collaborative relationships with both business and technology stakeholders
• The architects are seen to recognize the concerns and perspectives of business and technology stakeholders and incorporate those concerns and perspectives into their technology and implementation planning
• Through their interactions with the architects, business stakeholders are able to communicate what is important to them
335
Liaising and negotiating Liaising with the business; Liaising with technology; Building agreement; Understanding that requirements change; Negotiating appropriate solutions to changing requirements; Investigating alternative technology solutions; Discussing pros and cons of solutions with technology staff; Discussing proposed solutions with the business; Making decisions with business and technology
• Business and technology participants view the implementation of the EA as a shared enterprise with the architects
• They recognize that funding for the implementation of the EA comes from the business divisions and that the architects must build support for and commitment to the EAI at that level
• They also understand that whilst the architects have specialist architecture knowledge, other types of knowledge are required to implement the selected technology components such as knowledge of the technology portfolio
Communicating Communicating directly with people; Providing opportunities for direct contact; Sharing information about the technology components; Sharing implementation information; Discussing the implementation plans; Holding EAI information sessions; Providing opportunities for information sharing; Discussing specific programs associated with the EAI; Allowing people to ask questions; Being available; Enabling timely access to information
• Business and technology participants want to have direct contact with the architects in order to address emerging questions and concerns
• Being able to communicate with the architects as required allows business and technology participants to efficiently address matters that are important to them
336
Building common tools Developing architecture tools with technology staff; Fostering collaboration; Facilitating knowledge sharing; Negotiating an agreed approach; Co-developing tools has mutual benefits
• The co-development of tools allows business and technology participants to be involved in the EAI and promotes a sense of mutual engagement with the architects
Table 11.10 Interactions with business and technology staff - Categories, codes, and summary of business and technology staffs’ perspectives (Bank2)
337
11.4 List of Peer Reviewed Papers
• Dale, M., (2013), Enterprise Architecture Implementation Governance: Managing
Meaning and Action, Journal of Enterprise Architecture, Vol. 9. No. 1. Pp. 77-88.
• Dale, M., Enterprise Architecture Implementation: Master Plan, Language and
Politics (Accepted as Research in Progress for PACIS 2014)
338