Brian Corson
Nadia Erinchek
Luke King
Brian Yost
2
Executive Summary
Introduction
IT Governance
IT Architecture
Case Study I
Case Study II
Summary
Page 4
Page 6
Page 7
Page 7
Page 15
Page 21
Page 31
3
Executive Summary
“Architecture is the most powerful governance tool CIO’s have under
their personal control. It is how the CIO’s enforce the goals of
technology standardization across a diverse company with many different
competing interests.” 1
-Chris Koch
The above quote perfectly illustrates the importance of IT architecture and the
considerable impact that it has on governance in the organization. Managers across all
industries are facing a situation in which IT systems and applications are developing at an
extraordinary pace. At the same time, these managers are being forced to maintain
flexibility due to the constantly changing demands of customers and suppliers.
Organizations must find a way to continually develop their IT, satisfy the needs of users,
and most importantly, continue to meet the goals and objectives set for the corporation.
This environment has led to IT architecture becoming one of the most important strategic
assets available to any organization.2
IT architecture provides a set of standards, guidelines and policies that direct
choices and decisions for IT within a corporation.3 The fact that IT architecture is an
important topic for managers to understand is an understatement. Agarwal and
Sambamurthy state that infrastructure management, or IT architecture, is one of eight
value creating processes used to create strategic differentiators for the firm.4 Similarly,
Weill believes that a decision on IT architecture is one of the five major IT decisions that
must be made.5 A growing number of corporations are beginning to realize the
significance of IT architecture and for that reason, they have begun to approach the
management of their systems from an architectural standpoint. 6 While IT architecture is
very important, the development, implementation, and maintenance can be a very
difficult process.
The development of IT architecture involves many different variables. Certainly,
organizations must understand the technical design of IT architecture and the manner in
which the existing systems will be integrated with incoming technology. But there is
another aspect of IT architecture that is very important, especially for managers, and that
is the governance of IT architecture. Instead of focusing on the “what” and “how”
questions, the governance of IT architecture identifies the “who” in IT architecture.
Understanding the impact of the management and decision makers on IT architecture is
just as, if not more important than knowing the technical functions.
The goal of this paper is to identify, analyze, and illustrate the governance of IT
architecture and evaluate the relative impact these governance mechanisms have on IT
architecture as well as the entire organization. This paper is structured in three main parts.
It will start off by defining both IT governance and IT architecture. It will then
thoroughly analyze the different stages of IT architecture developed by Jeanne Ross. The
last part will examine and evaluate the governance of IT architecture of two different
companies; Benefits Consulting Inc. and Bank of America.
4
The companies used for the two case studies were chosen due to our group
members’ close proximity to the organizations by employment and personal contacts. It
also gives the reader a unique perspective by allowing them to compare and contrast the
governance of IT architecture of a small insurance company to that of a large bank. The
information used in the studies came from personal knowledge, company history, and
most importantly, key interviews with IT professionals in the respective organizations.
Both cases will discuss the current governance structure and the current stage of IT
architecture. More importantly, both cases clearly illustrate the significance and impact
of governance throughout the entire process.
There are several lessons that can be taken away from this presentation. IT
architecture is a necessity and it requires constant attention and evaluation. Similarly,
good governance methods, especially in IT architecture, can bring an organization much
more success. The following are good practices that will allow managers to achieve
positive results from IT architecture:








CEO understands and supports IT Architecture
Obtain senior-level commitment
IT is aligned with the business. More efficient.
Work towards Consolidation, Standardization and Integration
Promotion of Re-usability
Promote and utilize IT as a Competitive Advantage
Take a long-term view approach
Build in flexibility while maintaining discipline
On the other hand, there were several practices identified in the studies that led to
negative results. The following are a list of bad practices that managers should
understand and avoid:




Lack of organization knowledge (Not teaching change process)
Too much redundancy (Not attending to unused and/or obsolete
systems/programs before moving forward)
Being reactive versus proactive to changes
Piecing applications on top of applications to standardize
5
Have You Ever Built A House?
Building a house can be a very time-consuming, expensive, and exhaustive
process and often times the finished product does not even come close to meeting
expectations. However, when a clear plan is outlined and effective guidelines are
enforced, and most importantly, a solid foundation is built, the outcome is very
rewarding. Similarly, corporate executives must follow the house building process when
managing their information technology (IT) department. More specifically, it is important
to develop guidelines and standards for all to follow. One of the most important IT
decisions for managers is IT architecture, or the foundation for which all else is built on,
similar to the foundation of a house.
Over the last several years, large multi-national corporations have continually
added new IT systems to their already complex operating systems, creating a hodgepodge
of software and hardware across the corporation. Giga Information Group states that the
average large corporation has a massive 150 different applications, tools and utilities
accessible from the desktop.7 The increasing demand for complex, super fly, dynamically
driven databases and applications coupled with the necessity of these systems to cooperate seamlessly has resulted in the development of an IT architecture becoming the
most significant process that an organization can undertake.
There are many variables that must be considered throughout the development of
IT architecture. Obviously, broad technical knowledge of systems development and
integration is necessary for the creation of an IT architecture. A detailed technical plan
will illustrate the path of interconnectivity across a corporation through the use of
standard interfaces and middleware.8 A clear technical plan answers many important
questions like the “why” and the “how” of IT architecture.
Although the technical element of IT architecture is necessary, there is another
component of IT architecture that must be addressed and, in our opinion, is much more
important. This component is known as the governance of IT architecture. Instead of
focusing on the “what” and “how” questions, the governance of IT architecture identifies
the “who” in IT architecture. Understanding the impact of the management and decision
makers on IT architecture is just as, if not more important than knowing the technical
functions.
The purpose of this paper is to identify, analyze, and illustrate the governance of
IT architecture and evaluate the relative impact that these governance mechanisms have
on IT architecture as well as the entire organization. The first two sections in the paper
identify and define governance archetypes and IT architecture. The next sections present
the benefits and challenges confronted in IT architecture. This is followed by a thorough
analysis of Ross’ four stages of IT architecture. Finally, all of this information is applied
and analyzed through two case studies. The first case study is a small insurance company,
Benefits Consulting, Inc., and the second case study is a large bank, Bank of America.
This paper is specially designed to inform future managers about the significance of IT
architecture, and more specifically, the governance mechanisms within IT architecture.
6
The Glue that holds it together- IT Governance
“Architecture is the most powerful governance tool CIO’s have under
their personal control. It is how the CIO’s enforce the goals of
technology standardization across a diverse company with many different
competing interests.” 9
This quote by Chris Koch perfectly illustrates the importance of IT architecture and the
considerable impact that it has on governance in the organization. In the article, “Don’t
just lead, Govern: How top-performing firms govern IT,” Peter Weill defines IT
governance as “…specifying the framework for decision rights and accountabilities to
encourage desirable behavior in the use of IT.”10 Corporations that establish good IT
governance will be able to ensure that IT related decisions match company wide
objectives. Companies with better than average IT governance earn at least 20% higher
rate of return than companies with weaker governance. 11
The importance of IT governance is obvious but the method of determining what
decision should be made and who should make the decision is not so clear. In the same
article mentioned above, Weill identifies the major IT decisions that must be made and
the different governance archetypes that determine who will make the decisions. The
governance archetypes discussed in the article are Business Monarchy, IT Monarchy,
Feudal, Federal, IT Duopoly and Anarchy.
The Business Monarchy governance archetype delegates senior business
executives as the only IT decision makers. The Chief Information Officer (CIO) is
usually given equal say among the executives.12 On the other hand, the IT decisions in an
IT Monarchy archetype are made solely by IT professionals. The decisions often come
from a single group or multiple groups of IT professionals. 13
The Feudal archetype allows the IT decisions to be made by the leaders of the
various business units, regions, or functions. The Federal archetype takes IT decision
making one step further than Feudal by delegating the decision making to a combination
of corporate executives and business leaders. The decisions made in a Federal archetype
are hard to come by and are often unsuccessful. 14
The IT Duopoly archetype usually reaches a more in-depth and knowledgeable
decision on IT. The reason is because IT decisions are made by a two party arrangement
of an always present IT executive and another business unit leader. 15 Finally, an Anarchy
governance archetype is exactly that, anarchy. IT decisions are made by every small
group in the organization, creating a very expensive and decentralized process. 16
What is IT Architecture?
IT architecture is identified and defined in many different ways. IT architecture
has been given various titles including IT Infrastructure, Enterprise IT architecture,
Technical architecture, and Application architecture. Likewise, IT architecture is
7
defined differently across the industry. Although there has yet to be an agreement on an
exact definition of IT architecture, there are several key characteristics that have been
agreed upon. Jeanne Ross provides a very good definition of IT architecture that
identifies the characteristics and creates a solid foundation for the analysis of IT
architecture:
“IT Architecture is the organizing logic for applications, data, and
infrastructure technologies, as captured in a set of policies and technical
choices, intended to enable the firm’s business strategy.”17
This is a clear definition but there are a few points that should be added. First, IT
architecture is a component of the IT and business strategies. The IT architecture
highlights the IT capabilities that are most critical to a firm’s strategic objective. Second,
the IT architecture must provide a base that can be expanded and modified to satisfy
evolving business needs. Finally, Ross’s definition states that IT architecture is “the
organizing logic for applications, data, and infrastructure technologies.” But there is one
important piece missing and that is the people. The design and logic of the IT architecture
must consider the management and decision makers. The analysis of the organization of
people in IT architecture is a necessity, illustrating the significance of our topic, The
Governance of IT Architecture.
IT Architecture is the same as IT strategy - Right?
The answer is wrong! This is one of the many misconceptions associated with IT
architecture. IT architecture is one component of IT and business strategy but it does not
take the place of these strategies.18 In addition, IT architecture is often mistaken for
technology or equipment. In actuality, IT architecture is the plan and design that will help
integrate the technology and equipment in the organization. Many executives implement
an IT architecture using a “set it and forget it” attitude. This is a big mistake and can lead
to serious problems. Creating an IT architecture is not a single event in the life of the
company but a long-term process that needs constant attention.19 Left unattended, the
benefits of any IT architecture will deteriorate over time. 20
Does my organization need IT architecture?
The answer is most definitely yes! There are several benefits created by the
implementation of IT architecture including improved interoperability, greater agility and
improved security. Obviously, one of the biggest benefits of an IT architecture is the cost
savings. IT architecture increases savings through the simplification of systems and the
ability to interconnect enterprises and people. The greater interconnectivity in the present
day economy has forced organizations to improve interoperability so that processes and
services are linked across businesses and geographies.21
The benefits of IT architecture are significant but there are many challenges a
corporation must face and overcome in order for the process to be successful. The
development and implementation of an IT architecture is very time consuming and
expensive. The typical costs of an IT architecture are at least one percent of IT budgets. 22
Just like many IT projects, IT architectures are sometimes hard to justify because it is
8
difficult to tie the benefits back to the program. Finally, one of the biggest challenges of
IT architecture is the tension created in the introduction and implantation process.
Business unit leaders and IT staff are often turned off by the idea of creating standards
and guidelines after years of developing and purchasing whatever their budget allows.
The Stages of IT Architecture
When discussing the governance of IT architecture, understanding and determining
the stages of IT architecture is important. A firm’s IT architecture stage is an important
factor in its governance. Jeanne Ross outlines the IT architecture stages in her paper,
“Creating a Strategic IT Architecture: Learning in Stages.”24 She outlines the following
four stages of IT architecture for a firm:
1)
2)
3)
4)
Application Silo Architecture
Standardized Technology Architecture
Rationalized Data Architecture
Modular Architecture
Figure A shows the four stages and each of the stage’s attributes. A firm’s strategic
implication of IT and architecture maturity advance together; therefore, as a firm’s
strategic implication of IT advances, so does its architecture maturity.
Figure A
Strategic Implications of IT
Local/Functional
Optimization
Specific Business Needs
IT Efficiency
Local Knowledge
Worker Support
Process
Optimization
Strategic
Choices
Non-core Business
Needs
Local Customizations
Core Process
Integration
Wired Business
Core
Technology
Standardization
Data Center
Application Silo
Standardized
Technology
Rationalized
Data
Modular
Architecture Maturity
9
Application Silo Architecture
In the application silo architecture stage, a firm’s main focus is on individual
applications. Business line managers review IT applications and decide on the
application that best fits their business need. The business line manager’s decision is
based solely on their individual business need. Once the application is chosen, the IT
department implements it for the business line. This application stands alone, similar to
the rest of the firm’s other applications.
There are benefits for a firm to be in the application silo stage. One benefit is that
it allows the IT architecture to be decided at the local level. The firm allows its front-line
management to make decisions on the applications to be used. These front-line managers
know both the firm’s and customers’ applications needs, which allow for a more utilized
application with immediate acceptance from the end users.
A second benefit is that the stage encourages innovation. This stage encourages
innovation because the business line manager’s only decision factor is to choose an
application that works best for their business need. Without constraints, business lines
choose and develop innovative applications.
The final benefit is that end users have high satisfaction with IT in this stage. The
high satisfaction comes from business line managers driving the decision on the
application. IT has support from the end-users, because the end-users made the
decisions.
Despite the benefits of this stage, it has become outdated because of its
limitations. One limitation is that the stage is very expensive to maintain. A firm in the
application silo stage requires its IT staff to have numerous experts in its applications. As
additional applications are added, the IT staff has to support each application separately.
This becomes very costly to the firm. The application innovation is offset by the cost to
develop and support these multiple applications. Due to the desire for firms to lower IT
costs, this limitation is a main reason firms decide to move into the next stage.
Another limitation is that adding additional applications to the system becomes
increasingly more difficult. As the number of applications grows in a firm’s architecture,
it becomes more and more difficult to link new applications to existing ones. This
linkage becomes more complex as more are added. The firm’s IT staff may have to write
new code to link additional applications. These issues cause significant delays to bring
new applications to market.
When we look at firms in the application silo stage, we find several common traits
among the firms. Most of the firms’ processes are limited by geography or function. The
firm may be located and/or service one community or focus on one specific function.
Another common trait is that the firms’ IT resources are focused on application
development. Its IT department’s main function is to implement applications. Rarely
does its IT staff get involved in any IT application decisions. These firms do not think of
the overall enterprise architecture, but of the individual applications.
10
One trait that is not common is the size of the firm. In Ross’ paper 23, she
discusses Johnson & Johnson and its architecture stages. In the mid-1990s, Johnson and
Johnson had over 150 operating companies. All of these operating companies were
independent of the rest. Each operating company’s IT department developed IT
applications for its own business need. In this decentralized model, no one was looking
at the enterprise’s IT architecture. Johnson & Johnson was in the application silo stage.
This decentralized model was difficult for Johnson & Johnson’s customers. A
customer would have to work with several different people at the different operating
companies. To solve this problem, senior management decided to present a single face to
its customers. This decision provided energy to move Johnson & Johnson’s IT
architecture into the next stage.
Standard Technology Architecture
The next stage in IT Architecture is the Standard Technology Architecture stage.
In Ross’ study, she found that 55 percent of firms were in this stage. In the standard
technology stage, a firm’s main focus is to establish IT standards, which would limit
choice and reduce the number of current platforms. To accomplish this, IT managers
would create IT standards for the firm. These standards would limit the applications the
firm could buy or use. When adding a new application, a business line manager would
need to ensure the application fits the IT standard. In this stage, the business line
manager’s decision is not based solely on their individual business need. Also, IT staff
would begin creating data warehouses and reduce platforms.
The Standard Technology stage provides several benefits to the firm. One of the
benefits is that it allows for significant cost savings. In Ross’ paper, she states that IT
managers reported savings up to 20 percent. These savings come from the reduction of
platforms and creating IT standards. Both provide a reduction in the firm’s hardware and
software needs.
Another benefit provided by this stage is reducing the complexity of the systems.
This is achieved by the IT standards. New applications can be easily implemented
because of the limitations placed on the architecture by the IT standards. This provides
for a standard system.
Another benefit provided by this stage is that it simplifies the lives of the IT
architects and developers. The IT standards provide IT managers with control of the
firm’s IT architecture. Now, IT management can say no to business line managers,
something they were unable to do in the application silo stage. This control simplifies the
lives of the IT staff.
Despite the benefits of this stage, there are some limitations. One limitation is
resistance from business line management. A firm in the standard technology stage
transfers almost all of the IT decision making to the IT management. The business line
management may be resistant to IT’s decisions because of their loss of decision making.
11
The IT management will have to cope with this resistance. This resistance could create
unutilized or inappropriate use of the systems.
Another limitation of this stage is the ability to effectively manage the system.
The IT standards provide the ability to manage the system; however, IT management
needs to understand and handle exceptions to the IT standards. A business need may
arise and an exception may need to be given. The IT management needs to handle these
exceptions appropriately. Allowing no exceptions may hurt the business’ ability to
compete and allowing too many exceptions would delude the limitations provided by the
IT standards.
When we look at firms in the standard technology stage, we find several common
traits among the firms. One common trait is that the firms are looking for IT cost
savings. IT cost savings are the major drivers for a firm to move into this stage. Another
common trait is that the firms envision enterprise architecture for its shared
infrastructure. To accomplish these goals, the firm’s IT department reduces its platforms
and creates IT standards. Also, a firm’s IT staff is involved in all of the IT decisions.
These are the common traits found in a firm in the standard technology stage.
Looking back at the Johnson & Johnson case, senior management decided to
present a single face to its customers. To accomplish this goal, Johnson & Johnson
implemented systems that would provide a single view to its customer. The first step was
to create IT standards and train IT managers on the new standards. At the first set of
training meetings, participants were resistant to the IT standards. However, as additional
training was provided, the majority of the participants learned the value of IT standards.
Johnson & Johnson has continued to work towards its goal of a single face to its
customers. Its numerous operating companies’ IT architectures have evolved into an
enterprise IT architecture. This evolution has helped Johnson & Johnson move from one
IT architecture stage to the next.
Rationalized Data Architecture
The next stage in IT Architecture is the Rationalized Data Architecture stage. In
the rationalized data stage, a firm’s main focus is on data management and infrastructure
development. The firm’s IT and senior management establish IT standards for its core
data and processes, which ensures the quality of the data. The control of the data and
processes is moved from the business line managers to senior and IT management. With
input from business line managers, senior and IT management must ensure its core data
and processes are selected for the standards. Also, the IT staff develops centralized data
stores for the data that powers core activities. This data will be extracted from the
applications and placed in the data stores. In this stage, IT management and senior
management make the majority of the decisions.
The Rationalized Data stage provides several benefits to the firm. One of the
benefits is that it provides efficiencies in business processes. The standardization of data
processing allows for greater efficiencies when the data is processed. These efficiencies
provide better quality for the data.
12
Another benefit of this stage is that it provides for a platform positioned for
innovation. By implementing rationalized data, a firm can use the data in numerous
ways. Firms can quickly add new services or discover customer problems from the data.
The stage allows firms to better understand the value of data.
Despite the benefits of this stage, the stage has limitations. One limitation is the
ability to extract data from the legacy applications. This task can be very difficult and
time consuming. Also, the quality of the extracted data may not be reliable or may be
unusable. This limitation provides a significant technical challenge.
Another limitation is the ability of the firm to implement the stage. Senior and IT
management could receive significant resistance from business line managers, due to the
loss of their control of the data and processes. Without their support, the project would
become impossible to implement. Also, the implementation may involve more changes
than the firm can handle. The firm’s staff may not be able to handle this new
environment. To combat these limitations, a firm should set smaller priorities and work
within its current capabilities, allowing the firm to move into the rationalized data stage.
When looking at firms in the rationalized data stage, we find several common
traits. One common trait is that the firms have support from senior management to make
these changes. Senior management’s support is needed to move into the rationalized data
stage. Their support is needed because they provide the funding for this change in
addition to the leadership and authority to take control of the data. Another common trait
is that the firm’s management knows how to articulate IT capabilities and strategic
opportunities. If a firm decides to move into this stage, it must know its core data and
processes that are of a strategic importance. It is very important for management to
articulate this information correctly because after the stage is implemented, it is nearly
impossible to change. These are the common traits found in a firm in the rationalized
data stage.
Ross discusses United Air Lines’ transition into the rationalized data stage in her
paper “Distinctive Styles of IT Architecture.” United Air Lines decided to create an IT
architecture that would ensure its staff had the correct information on the status of flights,
crews, and passengers. Senior management decided to reduce its 9 databases into 2
databases: Customer Experience and Airline Operations. After the implementation,
United Air Lines employees would change a data field in one system and it would
simultaneously change the data in the rest of its systems. This ensured all of United’s
systems were updated and accurate.
During this implementation, United’s senior management had to choose the
databases to maintain. If the wrong databases were chosen, United would have data that
was useless. This shows the importance of choosing the strategic data because it is nearly
impossible to change it after implementation.
13
Modular Architecture
The final stage in IT Architecture is the Modular Architecture stage. In Ross’
study, she found no firm that was in this stage; however, several firms were close. In the
modular stage, a firm’s IT architecture enables strategic agility through customized and
reusable modules. The firm’s senior management takes control of its data and processes
and defines which are core to its business for the modules. These modules allow for
strategic agility.
The firm can create reusable modules that allow local management or business
line managers to choose from a menu of processes and options. Also, the modules can
allow for greater discretion to local processes, as long as it’s part of the processes. These
abilities would allow the firm greater flexibility at the local level.
With the benefits to this stage, there are also limitations. One limitation is that no
firm is currently in this stage. It is estimated that only a few modular architecture
systems will be built in the next few years. The rarity of modular systems and experts
creates a limitation.
Another limitation is the ability to ensure data is rationalized in the data modules.
In the rush to introduce a data modular, IT staff must ensure the core data is rationalized.
The IT staff would need to create solid procedures to ensure the data is rationalized. Data
that is not rationalized will create unmanageable applications.
Figure B24 summarizes Ross’ four stages of IT architecture along with the stage’s
IT capability, approach, business case, and key learning. This chart is a great summary
of the four IT architecture stages.
Figure B
Silo
Standardized
Rationalized
Modular
Silos of
applications
with a data
center for
efficient
transaction
processing.
Firm-wide
technology
standards;
centralized or
federal IT
organization; data
warehouse for
shared data.
Infrastructure
includes core
transaction
processing; data
integration for
cross-functional
processes.
Components of
technology, data &
code; middleware
provide access to
shared data.
React to local
needs.
React to
enterprise-wide
needs
Create
opportunities for
core business
support.
Create opportunities
for new business
models.
Business Case for
Architecture
ROI of
applications.
ROI of
standardization.
Speed to market.
Strategic Agility.
Key Learning
Technologyenabled
change
management.
Standardization
and exception
management.
Process
integration for
customer
responsiveness.
Practice facilitating
reusability.
IT Capability
Approach to
Alignment
14
IT Governance Alignment with IT Architecture Stages25
After reviewing the four stages of IT architecture, we will discuss how the firm’s
IT governance aligns with its IT architecture stage. A firm in the application silo stage is
likely to have the Feudal approach to IT governance. In this stage, the business line
managers make decisions for IT architecture. Their decisions are based solely on their
business needs. IT management develops and/or purchases the applications. This
approach is consistent with the Feudal approach to IT governance.
A firm in the standardized technology stage is likely to have the IT Monarchy
approach to IT governance. In this stage, IT management with support of senior
management makes decisions for IT architecture. Business line managers rarely have
input in these decisions. This governance approach is consistent with the IT Monarchy
approach.
A firm in the rationalized data stage is likely to have the Federal approach to IT
governance. In this stage, IT management and senior management make decisions for IT
architecture. Also, business line managers must have input in the decisions to ensure
consensus on the core data and processes. This governance approach is consistent with
the Federal approach.
A firm in the modular stage is likely to have the Business Monarchy approach to
IT governance. In this stage, senior management makes decisions for IT architecture.
They also control the core data and processes. IT management works with the business
line managers to ensure the appropriate applications are selected from the modules. This
governance approach is consistent with the Business Monarchy approach.
Case Study I - Benefits Consulting
One of Forbes’ “200 Best Small Companies”
Benefits Consulting is an insurance brokerage firm that specializes on providing its
customers with comprehensive executive benefits packages including life insurance,
disability, long-term care and other related services like executive compensation analysis
and strategies. The main customers of the company are large US Corporations, Banks
and Healthcare Organizations. Please refer to Figure C for the information about the
company. Benefits Consulting’s goal is to help companies to keep their best people. The
values of Benefits Consulting are focused on the client and the ability to continuously
provide the best service to the client:
 Client First
 Sustainable Business Model
In recent years there have been a lot of changes in the industry, and in the company itself.
This raised questions about whether Benefits Consulting would be able to keep its clients
and sustain the quality of services and products while continuing to be profitable and
competitive in the market.
15
Figure C
Revenue / Net Income
Products/Services
Customers
Number of IT
Employees
Annual IT Budget
$325.9 million
•
•
•
Executive compensation analysis & strategies
Executive benefits design, funding, implementation
Executive life insurance, disability and long-term care
Corporate-owned and bank-owned life insurance
•
US Corporations, Banks and Healthcare Organizations
28 permanent and 2 contract employees (Executive
Benefits Practice)
$8.2 million
Insurance Today – Multi-system Migraine?
A soft market characterized insurance industry in the 1990s. Insurance companies
and brokerages were thriving with financial markets on the rise. New insurance products
were developed during this time; most supported and developed by different companies
using their own highly customized programs. As a result, by the end of the 1990s, the
number of companies operating in the insurance industry and the number of highly
customized products offered increased drastically. However, with the events of
September 11 and the dot.com crisis the period of hard market begins. Numerous
bankruptcies, mergers and acquisitions led to a decrease in the number of companies in
the insurance industry, and surviving ones started looking for efficiencies and
competitive positioning through IT. Please see Figure D for the example of the change in
the number of insurance agencies from 1992 to 2002.26
Figure D
Year
Number of Independent Insurance Agencies
1992
46,000
2002
40,000
Average Decline
-15%
In his article, Michael Voelker calls the current situation in the industry “the multi-system
migraine” and analyzing the past and present he comments that in the past,
“…systems didn’t communicate with each other; users needed to
maneuver a different interface for each system; and lack of overall
common architecture made it difficult for IT to support nimbly the
strategic objectives of the business. But today, things are …well, they’re
pretty much the same.”27
Current problems in the insurance industry that force companies to look closer at
their IT departments include numerous mergers and acquisitions, a large number of
stand-alone applications and customer-centric products, and constant coverage changes.
As noted by David Holtzman, “…in the last several years, insurance organizations have
16
been pushing hard to drive out inefficiencies and cost to gain competitive parity with
their financial services counterparts and their competitors.”28
Sad Diagnosis for Benefits Consulting IT Systems
All of the insurance industry problems described earlier have affected Benefits
Consulting. In the last several years, the company acquired a number of smaller firms that
each specialized in a different type of executive benefits product. In the process of
adding new lines of business, the management of Benefits Consulting did not have time
to think about integration of IT systems used by merged firms into the overall
architecture of the company. Since each firm was coming on board with its own set of
established clients and its own set of applications customized to serving those clients, the
management of the company decided that in order to maintain clients during the
transition period it is better to keep things simple and leave the systems intact. As a
result, management of Benefits Consulting set itself up for a “multi-system migraine.”
Today, the company consists of five business practices that operate using their own
applications and databases, which are not connected across practices in any way. The
Executive Benefits Practice is the largest and has as many as 10 applications. It is also
the core line of business from which the company originated and has the most
complicated products. Hence, it is where most of IT staff is located. Other practices
have 1 to 4 IT professionals. It is also important to mention that geographically all
practices are located in different states including Texas, California, Illinois, New York,
Minnesota, and Washington D.C. The Benefits Consulting current IT Organization is
shown on Figure E.
Figure E
Database for Time
Reporting & Accounting
Headquarters
Chief Technology Officer
Banking
Practice
Banking
Applications
+
Time Reporting
&Accounting
Database
Healthcare
Practice
Healthcare
Applications
+
Time Reporting
&Accounting
Database
Actuarial
Group
Actuarial
Applications
+
Time Reporting
&Accounting
Database
Executive
Benefits
10 EBP
Applications
+
Time Reporting
&Accounting
Database
Human
Capital
Employee Benefits
Applic.
+
Time Reporting
&Accounting
Database
It is clear that from the IT perspective that each practice operates as a separate
unit that is not connected to the rest of the company. The only application that is
common to all practices is time reporting and accounting, the database for which is
located in the headquarters of the company. All other practices have their own databases
that are not connected with each other. The current situation has created many of
17
inefficiencies in company operations and raised concerns about a long-term outlook for
Benefits Consulting. Our further discussion will show in detail the problems that were
identified, lessons and solutions that were identified by the management of Benefits
Consulting.
IT Organization – Who Makes Decisions?
In this section, we will take a closer look at the Executive Benefits Practice (EBP)
in order to get a better understanding of the IT decision processes in Benefits Consulting
and, hence, the IT architecture, which is one of the main components of IT governance,
as described earlier in the paper. Figure E shows how the EBP is organized. The main
point is that three IT teams – client benefits development, client benefits analysis and
business systems report to a Senior Vice President of Client Solutions, which is not an IT
position. The Senior Vice President of Client Solutions then reports to the EBP
President, who in turn reports to the Chief Technology Officer regarding IT issues and
projects. The CTO has some involvement in deciding on the general strategic IT
guidelines. However, it is up to the IT staff in each team to define and determine how to
fulfill the requirements passed down from the headquarters. In addition, teams act on
requests of the users of the illustration and administration applications. These requests
are usually very customer-specific and critical to the users. In the case of such requests,
IT staff makes decisions and implements accordingly without coordination with
headquarters or other Practices in the company. If the funding is necessary for IT
projects, IT staff requests and justifies the funding requirements to the Senior Vice
President of Client Solutions and EBP President, who in turn requests funds from the
CTO. Vice President of Application Development commented on this process –
“…we normally justify via the benefits a project will provide. Any
potential costs savings are discussed but usually not quantified. Project
success is measured mostly by completing it on time with the expected
level of resource and on user satisfaction with the results.”29
The same IT decision process is employed by each practice of Benefits Consulting. This,
again, shows how much the company is unit and client driven. This process of decision
making combined with the company history of acquisitions led to the following:
 IT resources focused on delivering individual customer-specific applications
 Applications are limited to a single function for each practice
 No centralized data centers and no connectivity between practices
 Business users focus on the value of their own applications and have separate
design & development teams for different applications
The above list puts Benefits Consulting in the Silo stage of IT architecture (see Figure F),
according to Ross’ definition discussed earlier in the paper. Consistent with the silo
architecture stage, the IT governance of Benefits Consulting is very close to Feudal, in
which business units make IT decisions based on each unit’s specific needs. A closer
look at the EBP practice also shows that some elements of IT Monarchy, where IT
professionals make IT decisions, are also present.
18
Figure F
What are the benefits of the current IT architecture and governance for the
company? The obvious one is the ability to create highly customized applications per
client/user requests, which in turn creates high satisfaction of clients and helps fulfill the
primary value stated by Benefits Consulting – clients first. The Silo stage architecture
also offers simplicity to a certain extent. In the case of Benefits Consulting, simplicity of
keeping each practice’s IT intact was a benefit until the number of applications increased
to a level of “multi-system migraine” and the company realized that it can no longer
support its second value – a sustainable business model. The Vice President of
Applications Development in the EBP practice mentioned redundancy of applications and
data, large number of disconnected applications, nonexistence of a shared database, and
outdated technologies as the main limitations of the current IT architecture stage. Due to
these limitations of the IT architecture, it is very costly to maintain and update. It is
difficult to keep track of the data stored in different applications due to no shared
database. Often double entry is necessary, which can lead to mistakes. Outdated
technologies make it hard to update systems and take advantage of integrating new
technologies. Older technologies also require expertise from the IT staff that might be
hard to find.
Looking for a Cure for “Multi-system Migraine”
In an effort to find new efficiencies, improve competitiveness, and continue
building a sustainable business model, Benefits Consulting turned to reevaluating its
current IT departments, IT governance mechanism, and IT architecture. Two main
directions were identified.
First, in order to tackle and resolve problems of the IT architecture Benefits
Consulting needs to involve both IT and business staff at all levels in the decision making
process. This basically means creating an IT duopoly to replace the old partially Feudal,
and partially IT Monarchy governance. According to Peter Weill, from Massachusetts
Institute of Technology, “for enterprises with few synergies using duopoly for
19
application needs can work well because there is less to coordinate between business
units…”30
Second, Benefits Consulting must build a single logical database to integrate
applications that use the same data and provide similar services. If this is accomplished,
the company will be able to progress from the Application Silo stage of IT architecture to
the Standard Technology stage.
Plans for the Future IT Architecture
Development of the project dedicated to improving the IT of Benefits Consulting
was launched in October 2004. Vice President of Application Development described
the current stage as follows:
“We are in the beginning phases of a multi-year project to redevelop all of
our existing EBP application systems into a single logical application (i.e.
fully integrated systems) that utilizes one shared data base. We are
currently evaluating the possibility /practicality of integrating all/most
application systems for the practices which provide similar services for
different target markets…”31
The project is estimated to be three to five years long. The main objective is
consolidation of operations in Banking, Healthcare, and EBP Practices since they provide
similar services and currently use applications that are very much alike, but don’t have
any connectivity. Initial focus of the project is creating a single database and building
architecture using state of art technologies to map processes, identify business
requirements, and design and develop shared and custom applications. It is interesting to
mention that the first action taken in October 2004 was creation of two committees that
provide oversight of the project. Both include IT and business staff – an executive
committee and a committee for operational oversight of ongoing project activities that
will report to the executive committee. This is a step towards changing current IT
governance to a more integrated mechanism.
Also, just a couple of weeks ago, Benefits Consulting announced that the Human
Capital Practice would become a part of the EBP. Both committees agreed that
integration of actuarial consulting and registered investment advisory services, provided
by the Human Capital practice, into EBP, will be an extension of the range of capabilities
that EBP currently offers. EBP provides design and funding solutions in executive
benefits to over 500 corporate clients. It would then be logical to integrate the
applications used by both practices to keep track of all services provided to the 500
clients and cross-sell, generating more business for Benefits Consulting. Naturally, the
company anticipates that such combination of services will enhance integration and lead
to more opportunities. This also demonstrates the company’s commitment to provide
clients with integrated consulting and financial solutions.
20
Taking into consideration the above recent change and future plans for Benefits
Consulting, the future IT organization and architecture will probably look similar to the
chart in Figure G.
Figure G
Headquarters
Chief Technology Officer
Banking
Practice
Time Reporting
&Accounting
+
Illustration & Admin
Applications
Healthcare
Practice
Time Reporting
&Accounting
+
Illustration & Admin
Applications
Executive Benefits (EBP)
& Human Capital
Time Reporting
&Accounting
+
Illustration & Admin
Applications
Database for Time
Reporting & Accounting
Actuarial
Group
Time Reporting
&Accounting
+
Actuarial
Applications
Database
Database
According the Vice President of Application Development, the features of the
future IT architecture that Benefits Consulting is building will include flexibility for
expandability and scalability, reusability, minimize development and maintenance costs,
reduce “time-to-market” for new features, and, also, through the function of mass
customization, will allow tailoring applications by client or plan without hard-coding for
specific clients.
Case Study II - Bank of America
Integrated or not integrated, that is the question?
Bank of America is one of the largest and most well known banks worldwide. They are
in every major city and spend millions of dollars on advertising. Bank of America has
grown through numerous mergers and acquisitions with the most recent being with Fleet
Boston. They are experiencing major changes not only in their business strategy but also
their IT strategy. It appears this is just the beginning. As the business strategy becomes
clearer and better defined, the IT strategy will follow suit.
Bank of America’s Private Bank promotes itself as being America’s Trusted Wealth
Advisor by offering Integrated Advice. The question posed in this case study is “Does the
bank have the integrated structure to support the offering of integrated advice?” The
focus of this case study will be broken into the following four topics in an effort to
answer the above question:
21
1.
2.
3.
4.
Examine Bank of America’s current organizational structure
Discuss Bank of America’s current stage of IT Architecture
Discuss Bank of America’s current governance structure
Explain the importance of governance and its role in determining the stage of
Bank of America’s IT Architecture
Information about Bank of America (see Figure H) was gathered from an
interview with Jerry Bourbon.32 Jerry has been with the bank since 1990. He is a Service
Delivery Manager and Senior Vice President within the Private Bank, which is a business
line under Wealth and Investment Management (WIM). He is the interface to the
business groups for technology. His primary role is to work with the business groups to
better understand their needs and requirements. He takes that information back to his
respective IT groups and translates it into the required technology. He is the liaison
between the business and the technology. He also helps with planning tools and advice
and is apart of a strategy group.
Jerry was chosen for a number of reasons. Jerry has great deal of experience and
extensive knowledge in the world of IT. He understands the business and has seen it
change over the last 10 years. He has experienced a number of mergers and knows the
current IT Architecture better than anyone.
Figure H
Revenue / Net Income
$49 billion / $10.8 billion
Products/Services
•Banking Solutions (Checking, Savings, ATMs, credit cards)
•Credit Solutions (Consumer and Commercial)
•Investment Solutions (Wealth management, brokerage)
•Trust and Wealth Transfer (Trust Administration)
Customers
Number of IT
Employees
Annual IT Budget
Business Partners, Consumer, and Commercial
2,200 IT Employees
$2.6 billion
The Merging Banking Industry
Before discussing Bank of America’s current Governance and IT Architecture, it
is important to first highlight the banking industry, specifically how it has changed over
the last 10 years. Banks in general have been through numerous consolidations. The
industry seems to be constantly evolving, as does technology. It is not only important,
but also relevant that we highlight some of the factors contributing to this. Keep in mind
that there has been extensive research conducted on this topic alone. This paper will
merely highlight some of those ideas and conclusions.
Unlike the mergers 1960s and 1970s, which was merely a result of structural
changes, the 1980s let an even larger wave of mergers, more radical than those before.
This is evident, as we have seen a significant decline in the number of banks since the
1980s.33 For example, there were 11,433 banking organizations in 1984 compared to
6,578 in 2001. This is an average decline of 3.3%. Similarly, there were 14,392 banks in
22
1984 compared to 8,016 in 2001. This was an average decline of 3.4%.34 Some research
suggests that the “search for efficiencies” and “the relaxation of geographic restrictions”
had the most impact since the 1980s. For example, on June 1, 1997, Congress passed the
legislation allowing interstate branching under the Riegle-Neal Interstate Banking and
Branching Efficiency Act of 1994.35 This allowed banks to own and operate a bank
branch in any state other than their own home state.
Current research suggests two other factors played an even bigger role in the
consolidation of the industry over the more recent years; customer demand and
technology. Today, customers are demanding more real-time information. This demand
is driving change in the industry. The future depends on how fast banks can take
information, aggregate it, and get it back to the customer.36 Chris Britton points out,
“The most obvious difference between IT now and IT ten years ago is the
amount of new technology that has been introduced, especially having to
do with the Internet. It is just that new technology by itself does not solve
the major underlying problem, which is managing complexity. The major
source of complexity is that most organizations simply have too many
stand alone applications, each with its own presentation layer, business
processing logic, and database”.37
But both customer demand and technology go hand in hand. In order to meet those
demands, technology has evolved.
Tata Consulting Services, a world-leading
information technology company, has many clients in the financial services industry,
including banks. They have been in business since 1968 and have this to say about
technology and banks:
“Technology is the primary driver of the transformation that the banking
industry is going through. Banks have had to change into customercentric organizations: by leveraging the internet as a means for internal
and external communication; by having integrated processes and systems
to support ‘straight through processing’; and by adapting to the
convergence and consolidation that have happened in the financial
services across the world.”38
Allen Berger adds the following insight from his extensive research on banks and the
affects technology has had:
“Research suggests significant overall productivity increases in terms of
improved quality and variety of banking services. In addition, research
indicates that technological progress likely helped facilitate
consolidation of the industry.”39
His findings are similar to those of Tata’s. In a step further, Berger gives
examples in which technological changes can be observed and some of their
affects. They are as follows:
23
 Internet Banking – A relatively new front-office technology. Banks offer a
variety of levels of Internet services.
 ATM networks - Transactions on-line such as accessing accounts, transferring
funds, applying for a loan, and making investments. Widespread in a short time.
Substantial differences by bank size.
 Electronic payments technologies – Methods of transferring funds electronically
with relatively little paperwork. (ie. Loans processed with 80% less paperwork).
 Information Exchanges – Intermediaries through which banks and other creditors
share data relevant to the creditworthiness of loan applicants. These exchanges
collect data from financial institutions, trade creditors, public records and other
sources, aggregate and summarize the data and then provide credit reports or
credit scores to lending institutions.
Of course that is not to say that there are other factors behind the wave of mergers in
the banking industry. The following are some of the broader reasons:40
 Greater Efficiency – Able to operate more cost effectively by increasing size
 Leveraging technology – Needed to meet and maintain the technology customers
are demanding
 Changing laws (ie. Sarbanes Oxley, Patriot Act, and anti-money laundering)
 Diversification – Especially for lending
 Broader array of products – Creating the one-stop shop
So why is all of this important to know? Ivan Schneider has a good answer:
“Between bank mergers, shifting economic conditions and rapidly
evolving IT strategies, few banks have had the appetite to untangle the
morass of legacy systems running their businesses”.41
Systems cost a lot of money, they are hard to change, not very reliable, and often add to
poor customer service. It has caused companies, and in this case, Bank of America to
rethink their architecture.
Snapshot of Bank of America’s Organizational Chart – Subject to Change
It makes sense to begin describing Bank of America’s structure (see Figure I) by starting
with the CIO. The CIO, who is considered the president of technology, leads strategy
development and execution for the bank’s technology platforms and fulfillment
capabilities. Max Hopper, who was the former CIO of Bank of America, adds the
following: “…CIO should be managing and directing relationships and outcomes, not
applications”. 42 An important observation on the chart is whom the CIO reports to.
Steve Marlin points out the following:
“The fact that Barbara Desoer has been given both the CIO and
business-line responsibilities—and that she reports directly to Ken Lewis
CEO—signifies the emergence of IT as a key business area instead of
merely a support role. In banking, technology is driving a lot of change,
so this puts someone in charge who understands both the business and
24
the technology. There’s a recognition that technology and the business
need to be together.”43
Figure I
Under the CIO, there are multiple CIOs each responsible for a different business
unit. The current structure is aligned with the actual business structure. The key is that
the business strategy/decisions drives the technology. The 5 business units are as
follows: Wealth and Investment Management (WIM), Global Corporate Investment
Bank (GCIB), Consumer/Commercial Bank, Network Computing Group and Technology
and Operations. The important point is that each of these units has their own technology
support team and database warehouse. At this point, it is difficult to share information
between one unit and another because each uses different software and applications. The
IT Architecture is set-up as silos as each group makes their own IT decisions.
Under each business unit are the respective lines of business. For example, BAI
(brokerage), Private Bank, Asset Management, Investment Products, and a Strategy Team
all role up under WIM (see Figure J). Each one of these lines of businesses reports
directly to the WIM CIO. Each line of business is headed up by a Technology Executive
(TE). Under each TE, there is a Service Delivery Manager (SDM). Each SDM reports
directly to their respective TEs. There is also a Project Manager (PM) and a Project
Analyst (PA) under each business unit. The PA reports directly to the PM and the PM
reports directly to the PA. It is a vertical structure. There is also another group that
reports directly to the WIM CIO and that is Application Development. It is headed up by
the TEs from both the BAI and Investment Products line of businesses. Application
Development is made up of programmers, developers and testing and quality assurance
teams.
25
Figure J
One of GCIB’s main responsibilities is enterprise data, which happens to be one
of the biggest challenges the bank faces. Client information (loans, banking, investments,
etc) is across or among different channels. Brining that together so you know what’s
going on is a challenge because each group uses different applications. They are
currently looking at an application that will bring it all together but they first need to have
their enterprise data together.
Consumer and Commercial Lending are responsible for processing and
maintaining all of the loans. Once again, it is difficult to share this information across
other business lines.
NCG is in charge of all the infrastructure groups such as hosting, servers,
computer operations, networking, hardware, mainframes, data lines and phone lines.
They handle these items for each business unit. In fact, NCG also has a contact group
that supports each line of business, broken up into channels. For example, when a project
under WIM requires infrastructure changes, they are responsible for working with NCG’s
WIM group to handle those changes. So within NCG, there is a TE who works only with
WIM.
Another CIO is Technology and Operations. This is the operational support it
takes to run the bank, for example, check and statement processing. This is the biggest
group and makes up the most employees than anyone else.
So how do projects get imitated? The main point is that technology is aligned
and organized around the business. For example, the WIM CIO works directly with the
WIM President. In fact, the WIM CIO is included in all of the WIM business meetings.
Therefore, if a business strategy requires any technology changes, the WIM CIO is a part
26
of the discussion. Any mandates out of that business meeting are funneled down to his
respective lines of business and that line of business fulfills the need. It also may call for
a collaborative effort with other lines of business such as NCG or Tech/Opps.
For example, if a business change is made within the Private bank and requires a
new application, it will be communicated down from the WIM CIO. Problems can arise
because some Private Bankers are dually licensed. So, BAI will need to be involved as
well because they use different applications. So the SDM will need to work both with the
Private Bank and BAI, which is all under WIM. This would be somewhat easier to
control. But it gets harder when a change is made that affects other banking systems such
as ATMs, checking accounts, loans (mortgages), or credit cards. Each unit has their own
application and the Private Bank may need to leverage enterprise data across several
channels. This current structure helps them respond quickly to business changes within a
specific business line because they are so closely aligned with the business.
Unfortunately, it can become quite expensive and difficult to control.
The Recent Merger – Yes, another one!
Bank of America and FleetBoston completed their $47,850 billion merger this
year. Integrating these two companies is not any easy task. There are a lot of proprietary
systems that need to be sorted through. “In terms of redundant or overlapping systems,
my guess is that there’s probably 99% or 98% overlap in what BAC would have vs. what
Fleet would have,” says Dennis Rygwalski (former CIO of FleetBoston from 19992001).44
From the technology perspective, Jerry Bourbon stated that,
“(The IT group will be) taking the lead from the business. The business
will make the decision first. Leaders from both Fleet and Bank of
America meet and decide on the appropriate operating model. We fold
and map those applications and people from Fleet over to Bank of
America. So everyone is on the same page. The bottom line is that the
business strategy and decisions are driving the technology.”45
An important note is that the decisions are being driven by both business executives and
CIOs and not by each business line.
EDS wins again!
Bank of America spends a lot of money on outsourcing. Outsourcing is done at
various levels and once again business executives and CIOs now drive these decisions.
Before, each individual business line would have much input on those decisions.
EDS recently signed a $1.1 billion 8½ year contract with Bank of America to
integrate the communications infrastructure of recently acquired Fleet Boston. EDS
already provides Bank of America with managed network services as part of a 10-year
$4.5 billion contract signed in December of 2002.46
27
Who needs a budget anyway?
There are two types of budgets worth mentioning within the technology group;
Operating budget and Project Budget. The operating budget is the general budget that
keeps everything running. It is the largest and there are always ways to continue to save
money.
The project budget is for implementing change and getting new
applications/software. The process is very political because each business unit is fighting
for their share of the budget in order to better their group. The problem with this budget
is that it starts in August of each year. It is difficult to determine what and how much is
needed for the following year. Therefore, each group tends to over estimate how much
they will need. More often then not, these budget requests get drastically cut back.
The reason this is important to mention is because these decisions are being taken
out of the hands of each line of business and they are being determined by business
executives along with the input from CIOs. This lets upper management have more
control on spending and more control on what the money is spent on. This in turn affects
the IT Architecture and the future direction. It also ensures that IT is moving toward
centralization and standardization.
Stage of Architecture?
Modeling Bank of America’s current IT Architecture to Ross’ four stages, they
would fall into the ‘Application Silo Architecture’ stage (see Figure K). There are a
number of barriers keeping them from moving to the next stage. However, Bank of
America recognizes the need to move to the next stage and is taking the appropriate steps.
That is why we are placing Bank of America at the very end of the ‘Applications Silo
Architecture’ stage. They are very close to moving to the next stage but given they have
to contend with another merger, it may take them another year or so before they actually
cross the line into the “Standardized Technology Architecture” stage.
Figure K
28
The business executives and CIOs are trying to integrate each line of business. A
big focus is currently on reusability. They do not want anything specific for one channel
that will not work in others. They are diligently working to standardize all of the
applications.
So what is going to take them to the next stage? Will it be the standardization of
technology that will change the architecture or will the architecture change the
standardization of the technology? We believe it is a combination of both. The real
answer lies within how Bank of America is governed! This leads us to the discussion of
Bank of America’s governance structure.
Who is leading who? Bank of America’s Governance Structure…
Within Bank of America, most of the decisions regarding the IT Architecture are
made with IT Executives (CIOs) while the majority of the input is given jointly with
CxOs and IT Executives. It is a mixture between IT Monarchy and Duopoly. This type
of governance allows the IT group to strategically align themselves with the business
architecture. This is new for Bank of America. I consider them to be in a transition
phase. Prior to the merger, Bank of America had a Feudal archetype where each line of
business made many of the technology decisions, specifically relating to IT Architecture.
Decisions were made separately without considering the other lines. Each line operated
as a stand-alone or silo. Software and programs were not compatible and it was hard to
share information. Now, it appears the decisions are being taken out of the hands of each
business unit and are being made by CIOs and business executives. This will ensure that
all decisions will consider all lines of business and will help move the company as a
whole to the next stage, “Standardization”. Under the IT Monarchy and Duopoly
structure, it will ensure new software and applications can be shared across other business
lines. This will create a more integrated company where enterprise data can be
aggregated and shared in order to increase value-added services for the customers.
Peter Weil summarizes IT Duopoly as follows:
“Leaders in asset utilization typically use IT duopoly governance for all
five IT decisions. In the duopoly model, the IT group plays an important
coordinating role because it is one of the few groups that interacts with
all business units and can thus see firm-wide opportunities for sharing
and reuse across business units, business processes, and regions.”47
On a Positive Note!
In this case study, we have identified a number of things which we feel Bank of
America is doing right. The items listed below will help move them to the next stage:
 IT is supported by the CEO
 IT is aligned with the business – more efficient
 A lot of money and time is devoted to IT
 Use IT as a major differentiator (Competitive Advantage)
 Business executives and CIOs understand the need to standardize
 IT CIOs sit on business committees (Help influence decisions from an IT
perspective)
29
On a Negative Note!
Being as big as they are, Bank of America faces a number of
challenges/limitations/road blocks. We identified the ones in which we feel are keeping
the company from moving to the next level. They are as follows:
 Corporate politics (Management vs. IT)
 Organizational (Role clarity – who is responsible and accountable for what)
 Culture (Bureaucracy)
 Incentives not aligned properly
 Obtaining firm’s strategic objectives (Not clearly defined and/or communicated)
 Changing regulatory environment (Licensed vs. Non-licensed)
 Data sharing (Many barriers)
 Privacy and security (Confidentiality)
 Lack of knowledge of the organization
Lessons Learned
Organizational knowledge is one of the biggest learning curves. Learning how to
navigate through the organization in order to get things done is key. This is especially
important for new hires. The bank needs to provide new hires the proper training in order
for them to add value in the respective positions.
Plans for the future
It is difficult to determine what is in store for Bank of America going forward.
The main themes coming out of the interview are standardization and integration. The
future structure of Bank of America’s IT Architecture will depend on the business
structure and strategy. Until they better define this strategy, it appears the IT
Architecture will continue to evolve. It appears Bank of America knows where they want
to be; they just have a hard time knowing how to get there.
Summary and Recommendations
So does Bank of America have the IT Architecture to support their business
strategy of offering integrated advice? Without hesitation, the resounding answer is
“no”. Bank of America’s current architecture limits it from offering full-integrated
advice. The following comment by Ross summarizes what Bank of America should
focus on going forward.
“The objective is to get to the point where IT capabilities shape business
strategy while business strategy shapes IT capabilities in response to
changing market conditions and organizational realities”.48
Given Bank of America wants to have their business processes integrated; it makes sense
for the IT systems to be integrated as well.
Bank of America is on its way to fulfilling their business strategy but it is going to
take some time. Here are 4 recommendations:
30
1. Use Governance to drive the IT Architecture to the next stage
2. Build an IT Architecture that is responsive to change (IT Architecture has to
evolve along with the business)
3. Educate the IT group about the organization (process on how things get done)
4. Learn to communicate with executives (Technology vs. money)
By doing this, Bank of America will be able to create synergies between business
lines. As Broadbent and Weill mention in their paper,
“A high level of customer overlap between units provides opportunities
to cross-sell products and implies a need for common customer profiles
and databases.”49
But there definitely needs to be a balance between the business group and the IT group.
As Nunno points out, “Too much freedom, and you invite anarchy; too little, and you
miss opportunities and stifle innovation.”50
8 Overall “Best Practices” taken from both case studies
1.CEO understands and supports IT Architecture
2.Obtain senior-level commitment
3.IT is aligned with the business. More efficient.
4.Work towards Consolidation, Standardization and Integration
5.Promotion of Re-usability
6.Promote and utilize IT as a Competitive Advantage
7.Take a long-term view approach
8.Build in flexibility while maintaining discipline
4 Overall “Worst Practices” taken from both case studies
1.Lack of organization knowledge (Not teaching change process)
2.Too much redundancy (Not attending to unused and/or obsolete systems/programs
before moving forward)
3.Being reactive versus proactive to changes
4.Piecing applications on top of applications to standardize
10 Recommendations for creating Good Governance of IT Architecture
1.Understand the business in which you support
2.Strive to build a standards-based architecture around the business model
3.Balance discipline with flexibility (Freedom versus constraints)
4.Don’t talk technology, but capabilities with business executives
5.Create a written plan – revisit at least annually
6.Design from top-down – Begin with business needs first
7.Make it transparent to all key stakeholders
8.Create an architect committee combining both business and IT executives (change
members every other year)
9.Communicate and educate often
31
10.Make mistakes and learn from them (Can learn more from mistakes) – constantly
evolving
Overall Conclusion
As stated in the beginning, we liken the Governance of IT Architecture to
building a new house. The most important aspect of a new house are the decisions that
go into building the house, such as where the house is built, what materials are used, what
the budget is, who is in charge of doing what and so on. Usually, a general contractor
oversees and makes most of these decisions and works with the individual contractors.
This ensures progress in order to finish the home on time. Just think if these decisions
where made by each contractor. Most likely, you would encounter a number of problems
such as portions of the house not fitting together properly (not integrated) or spending too
much money on more expensive materials (over budget). Therefore, we believe that both
the person making the decisions and the decisions themselves going into building the
house are the most important. Now, compare this to governance and IT Architecture. If
companies want to move along to the next stage of architecture as modeled by Ross, they
need to have an appropriate governance structure. If the governance structure is setup so
that each line of business is in charge of their own decisions, most likely that firm will be
stuck in a “Silo Stage” with no integration or standardization as we have seen in both
case studies. When you change the decision maker to business executives and CIOs,
decisions will be made to ensure integration and standardization thus moving a company
further along the stages. That is why we believe that the appropriate governance of IT
Architecture is crucial if a company wants to move to the next stage.
Applying this to both case studies, we believe that each company’s governance
structure will keep them at their current stage or take them to the next stage of IT
Architecture as outlined by Ross. Without a proper governance structure, companies in
general, could find themselves stuck in the ‘Silo Stage’, which could have long-term
negative affects.
Koch, Chris “The Power of Architecture” CIO Framingham: Sept. 15, 2002. Vol 15. Issue 23; pg. 48
J.W. Ross, C.M. Beath, and D.L. Goodhue, “Develop Long-Term Competitiveness through IT Assets,”
Sloan Management Review, volume 38, Fall 1996, pp. 31-42.
3
Broadbent, Marianne “IT Architecture Matters” CIO.com 10 Sept. 2002.
http://www.cio.com.au/index.php/id;1699283945;fp;4;fpid;10
4
Agarwal, R., and Sambamurthy, V., “Principles and Models for Organizing IT,” MIS Quarterly
Executive, Vol. 1, 1, March 2002, pp. 1-16.
5
Weill, P., “Don’t just lead: Govern How Top Performing Firms Govern IT,” MIS Quarterly Executive,
Vol, 3, 1, March 2004, pp. 1-17.
6
Broadbent, Marianne “IT Architecture Matters” CIO.com 10 Sept. 2002.
http://www.cio.com.au/index.php/id;1699283945;fp;4;fpid;10
7
Schneider, Polly “Blueprint for Harmony” CIO Framingham: Sept. 1, 1999. Vol. 12, Issue 22; pg. 32
8
Nunno, Tina, “IT Architecture Matters” Gartner Symposium Itxpo 2003, pp. 1-19.
9
Koch, Chris “The Power of Architecture” CIO Framingham: Sept. 15, 2002. Vol 15. Issue 23; pg. 48
10
Weill, Peter “Don’t Just Lead, Govern: How Top-Performing Firms Govern IT” MIS Quarterly, pp. 14.
11
Ross, Jeanne and Weill, Peter “Recipe for Good Governance” CIO Framingham: Jun 15, 2004. Vol. 17,
Issue 17; pg. 1.
12
Weill, Peter “Don’t Just Lead, Govern: How Top-Performing Firms Govern IT” MIS Quarterly, pp. 14.
13
Weill, Peter “Don’t Just Lead, Govern: How Top-Performing Firms Govern IT” MIS Quarterly, pp. 14.
14
Weill, Peter “Don’t Just Lead, Govern: How Top-Performing Firms Govern IT” MIS Quarterly, pp. 14.
1
2
32
Weill, Peter “Don’t Just Lead, Govern: How Top-Performing Firms Govern IT” MIS Quarterly, pp. 14.
Weill, Peter “Don’t Just Lead, Govern: How Top-Performing Firms Govern IT” MIS Quarterly, pp. 14.
17
Ross, J., “Creating A Strategic IT Architecture Competency: Learning In Stages” MIS Quarterly
Executive, Vol. 2, 1, 2003, pp. 32
18
Nunno, Tina, “IT Architecture Matters” Gartner Symposium Itxpo 2003, pp. 1-19.
19
Schneider, Polly “Blueprint for Harmony” CIO Framingham: Sept. 1, 1999. Vol. 12, Issue 22; pg. 32
20
Nunno, Tina, “IT Architecture Matters” Gartner Symposium Itxpo 2003, pp. 1-19.
21
Nunno, Tina, “IT Architecture Matters” Gartner Symposium Itxpo 2003, pp. 1-19.
22
Nunno, Tina, “IT Architecture Matters” Gartner Symposium Itxpo 2003, pp. 1-19.
23
Ross, J., and Weill, P., “Stages of IT Architecture: Pursuing and Agility” Center for Information System
Research Briefing, Vol II, 2A, 2002, pp.1-2.
24
Ross, J., and Weill, P., “Stages of IT Architecture: Pursuing and Agility” Center for Information System
Research Briefing, Vol II, 2A, 2002, pp.1-2.
25
Weill, Peter, “Don’t Just Lead, Govern: How Top-Performing Firms Govern IT” MIS Quarterly
Executive, Vol. 3, 1, 2004, pp. 1-17.
26
Financial and Market Conditions July 2004, http://www.iii.org/media/hootpics/insurance/financialmar/,
viewed October 17, 2004.
27
Voelker, Michael, “The Multi-system Migraine”. The National Underwriter Company,
www.nationalunderwriter.com/tech/news/viewFeatures.asp?articleID=713, viewed September 1, 2004.
28
Holtzman, David, “Insurance Value Through Technology, Part IV: Infrastructure Optimization”
Insurance & Technology, insurancetech.com, 8, 2004, www.insurancetech.com, viewed September 1,
2004.
29
VP Application Development, EBP Practice, Benefits Consulting, Inc., Interviewed over the phone and
via email by Nadia Erinchek, September 29, 2004.
30
Weill, Peter, “Don’t Just Lead, Govern: How Top-Performing Firms Govern IT” MIS Quarterly
Executive, Vol. 3, 1, 2004, pp. 1-17.
31
VP Application Development, EBP Practice, Benefits Consulting, Inc., Interviewed over the phone and
via email by Nadia Erinchek, September 29, 2004.
32
Jerry Bourbon, Service Delivery Manager and Senior Vice President of Bank of America, interviewed in
person by Brian M. Yost, September 17, 2004.
33
Nolle, Daniel E., “Banking Industry Consolidation Past Changes and Implications for the Future” A
Conference of the Jerone Levy Economics Institute, pp. 1-53.
34
Berger, Allen N., “The Economic Effects of Technological Progress: Evidence from the Banking
Industry” Journal of Money, Credit, and Banking, Vol. 35, 2003, pp. 1-42 abstract.
35
Nolle, Daniel E., “Banking Industry Consolidation Past Changes and Implications for the Future” A
Conference of the Jerone Levy Economics Institute, pp. 1-53.
36
Schneider, Ivan, “Profitability and Risk Driving IT Architecture Shift, Say Capco and HP” Bank Systems
& Technology, May 5, 2004, pp. 2.
37
Britton, Chris, IT Architectures and Middleware Strategies for Building Large, Integrated
Systems, Addison-Wesley, Boston, 2000.
38
www.tcs.com/index.htm, viewed September 9,2004.
39
Berger, Allen N., “The Economic Effects of Technological Progress: Evidence from the Banking
Industry” Journal of Money, Credit, and Banking, Vol. 35, 2003, pp. 1-42 abstract.
40
“Banking Institution Mergers: Questions and Answers” ABA.com Industry Issues, September 14, 2004,
pp. 1.
41
Schneider, Ivan, “Plug-and-Play” Bank Systems & Technology, July 5, 2004, pp. 1
42
Olson, Larry, “The Strategic CIO: Lessons Learned, Insights Gained” InformationWeek, pp. 1.
43
Marlin, Steven “Bank of America Names New Payments Head” InformationWeek, August 25, 2004, pp.
1
44
Mearian, Lucas, “Q&A: Former Fleet CIO weighs in on Fleet/Bank of America Merger”
Computerworld, November 7, 2003, pp. 1-3.
45
Jerry Bourbon, Service Delivery Manager and Senior Vice President of Bank of America, interviewed in
person by Brian M. Yost, September 17, 2004.
46
Arnfield, Robin, “EDS Wins Bank of America Deal” CIO Today, 7/19/2004, pp. 1-2.
47
Weill, Peter “Don’t Just Lead, Govern: How Top-Performing Firms Govern IT” MIS Quarterly, pp. 14.
15
16
33
Ross, J., “Creating A Strategic IT Architecture Competency: Learning In Stages” MIS Quarterly
Executive, Vol. 2, 1, 2003, pp. 32
49
Broadbent, Marianne, and Weill, Peter, “Management by Maxim: How Business and IT Managers Can
Create IT Infrastructures” Sloan Management Review, Spring 1997, pp. 80.
50
Nunno, Tina, “IT Architecture Matters” Gartner Symposium Itxpo 2003 2003, pp. 1-19
48
34