A Post-Project Review of a Business Analyst

1) Applying the following Knowledge Areas of the BABOK (enterprise analysis, elicitation, requirements analysis and solution assessment and validation), analyse why the architects in Bank1 were unable to build stakeholder commitment and support for the enterprise architecture implementation (EAI). 1) Applying the following Knowledge Areas of the BABOK (enterprise analysis, elicitation, requirements analysis and solution assessment and validation), analyse why the architects in Bank1 were unable to build stakeholder commitment and support for the enterprise architecture implementation (EA

1
INF80014 CONTEMPORARY
ISSUES IN BUSIUNESS
ANALYSIS, S2 2021
ASSIGNMENT 1
INDIVIDUAL ASSIGNMENT
Assignment Submission and Weighting Details: See Unit Outline
Length:1,500 ± 10% words
ASSIGNMENT TASK
Please read the attached case study and complete the following 2 tasks
You are a business analyst and have been engaged by Bank1 to do a Post-Project review.
1) Applying the following Knowledge Areas of the BABOK (enterprise analysis,
elicitation, requirements analysis and solution assessment and validation), analyse why
the architects in Bank1 were unable to build stakeholder commitment and support for the
enterprise architecture implementation (EAI). 2) With reference to the above knowledge
areas, what would you do differently to ensure stakeholder commitment and support for
the EAI?
Please refer to the assignment rubric for additional information.

2
BANK1 ENTERPRISE ARCHITECTURE
IMPLEMENTATION CASE STUDY
Introduction
• 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 case study presentation
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.
Case Study: 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

3
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
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.

4
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.

5
Figure 5.1 Timeline for new strategy and EA
2011 2012 2013
New)Strategy)Announced
Formation)of)the)Architecture)
Review)Board)(ARB)
Architecture)Review)Board)
Disbanded
2014
Acceptance)of)the)EA)plans
Architects)begin)development)
of)the)EA)plans
Tentative)acceptance)of)the)
technology)components
Research)
interviews
Time)allowed)for)the)deployment)of)
the)new)hardware)and)software

6
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
1.1.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 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
CEO
CIO Business
Division A
Deputy CEO
Enterprise
Architects
Corporate
Services ….
Solution Delivery
Services
Solution
Architecture
Services
EAI Projects
Organisational Levels
Project
Management Office
Business
Division B
Business
Division C
Business
Division D
Specifying technology projects/
Monitoring and Supporting
Project resources required to
implement EAI projects
Senior Executive level
General Management level
Project/ Operational level
Project Architects Network/ Security
Specialists
Project Managers/
BAs
= Interview participants
Infrastructure ….

7
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.
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.

8
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.
Framing EAI Work – Architect’s Perspective
Comments categorized under this theme revealed how the architects perceived their EAI role 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.
1.1.2 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.

9
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 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

10
within the team, which gave preference to people with technical architecture experience.
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 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

11
EA plans.
1.1.3 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)
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’

12
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 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.
1.1.4 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

13
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 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.
1.1.5 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,

14
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.
1.1.6 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.
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.

15
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.
1.1.7 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 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).

16
1.1.8 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, 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.
1.1.9 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

17
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.
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.
1.1.10 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 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.

18
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.
1.1.11 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 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

19
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 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.
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.
1.1.12 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.

20
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 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).
1.1.13 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

21
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).
1.1.14 Addressing Problems with the Technology Portfolio
As well as considering the strategic, operational and outsourcing requirements associated with 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.

22
1.1.15 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 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

23
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).
1.1.16 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 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.

24
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 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,

25
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).
1.1.17 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 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.

26
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)?
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.
1.1.18 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).
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

27
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 “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

28
not communication (T2).
1.1.19 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 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).

29
1.1.20 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 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).
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

30
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.
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.
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?

31
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 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.