Notes from Interview

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.

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

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

The Glue that holds it together- IT Governance

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 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 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)Application Silo Architecture

2)Standardized Technology Architecture

3)Rationalized Data Architecture

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

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.

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.