Enterprise Architectures (V2):
We Build It, Will They Come?
Enterprise architectures are a major initiative for many IS organizations. Yet, despite major investments in their development, many are stalled in implementation awaiting user compliance. The reasons are subtle but clear. Enterprise architectures raise two of the most challenging IT management issues today: how to manage technological complexity and how to manage IT when responsibilities are shared among multiple, independent IS organizations.
The central thesis of this paper is that enterprise architectures are an enterprise initiative. They are developed by the enterprise, to solve enterprise problems with the benefits mostly accruing to the enterprise. But, implementation depends upon the support and compliance of users. If they do not see the value for themselves, they will argue, resist, ignore and/or escalate their concerns through business management (with business needs nearly always trumping architectural needs). The best enterprise architecture will fail without user support.
Gaining user support depends upon resolving the following key issues:
The purpose of this paper is to bring these issues into view and to provide strategies for addressing them in the context of enterprise architectures.
Until the early 1990s, IT architectures and standards were not an issue. IS organizations acquired a system and the system was delivered with its own architecture and standards. Vendors (e.g., IBM, HP, Digital and others) developed systems based on an architecture that included hardware and its interfaces, an operating system and subsystems, and applications that were designed to interoperate with the architecture. Vendors such as IBM spent 60 percent of their manufacturing costs on developing, integrating and maintaining their architectures. Users bought a system, the system included an architecture and there was no issue architecture or standards were a given.
In the early 1990s, with the advent of open systems and client/server systems, that changed. Users acquired their own systems, largely based on cost and function, and there occurred a proliferation of hardware, software and networks across the enterprise. These systems were distributed and heterogeneous without a unifying architecture or standards. And, they were owned by users, not IS.
The result was an explosion in the complexity of IT management accompanied by dramatically increased enterprise IT costs. The hardware and software were cheap but the cost of integrating and managing them skyrocketed. The result was the need for a unifying architecture and standards this time to be developed by users. The burden of defining the architecture and standards as well as building, integrating, testing and maintaining it moved from vendors to users. This was the hidden cost of the transition from mainframes to distributed, heterogeneous computing.
There is some confusion about what an architecture is. Historically, it referred to IT architectures and standards. The architecture included frameworks, policies, processes and procedures as well as the IT standards that implemented them. Some enterprises have broadened the concept to be an enterprise architecture where business strategies, such as business transformation, are the driving force. The US Federal Enterprise Architecture is an excellent example of this. The key differences are the scope and focus of the architecture and who is driving it. IT architectures are typically focused on the IT infrastructure and are the responsibility of the CIO; enterprise architectures are typically focused on business strategies (with the IT architecture a component) and are the responsibility of senior business executives. To succeed, both must support the business goals of the enterprise the key difference is who (the CIO or the business executives) is driving the alignment.
For this paper, we will focus on the IT architecture and standards whether an IS-driven initiative or as the IT component of the enterprise architecture. The discussion focuses on IT architectures and standards but we believe that the principles are equally applicable to business-driven enterprise architectures.
Why is Implementation a Problem?
User resistance to IT architectures is the norm. Gaining compliance depends upon addressing four key issues: which standards are chosen, how the architecture is managed (governance), what benefits are delivered (and when) and overcoming user constraints.
IT architectures and standards initiatives are typically initiated and driven by corporate IS organizations and, often, by a Chief Architect. What often happens is that the Chief Architect selects the best and brightest technical gurus and sends them to a (metaphorical) mountaintop to select the best IT standards for the enterprise. After much debate, the gurus choose the right standards, inscribe them onto a tablet (i.e., document them) and return to proclaim the new architecture and standards. Everyone then awaits user compliance.
What actually happens is often nothing. Users resist (overtly or covertly). They fight over the IT architecture and standards that are chosen. Or, they ignore them. Or, they develop compelling reasons why they cannot incorporate the architecture and standards into their projects and then escalate their objections through business managers. IS may begin implementation but user resistance is a continuing battleground. The architectural initiative stalls awaiting user compliance.
The result of this approach is an ongoing architectural tug-of-war between the Chief Architect and users over architectural compliance. Sometimes, IS wins by brute force with mandates that erode IS leadership. Sometimes, the initiative stalls. In either case, the benefits of the architecture are lost or delayed.
There is a better way. Successful IT architectures gain user compliance by addressing four key issues:
The standards issue revolves around which IT standards to adopt and why? Should the enterprise adopt best of breed products, i.e., the ones that are most function-rich and durable over time or should they adopt the products that are easiest to integrate with existing technologies? Should the standard be a single product or can it be multiple products? And, what is a standard anyway? What criteria should Architects use in deciding which standards to adopt?
Similarly, the governance of an IT architecture is controversial. Historically, CIOs made decisions about technology issues. Today, business managers at all organizational levels are invested in their own systems and applications. They have a vital interest in architecture and standards and they demand a vote in which are adopted. Architecture and standards today is a shared responsibility between IS organizations and users. Questions like: who gets to decide what the architecture and standards will be? Who is responsible for the architecture? What is the penalty for non-compliance? How and when will the standards evolve? These questions (and many more) are now important organization and governance issues to be addressed in the framework for managing the enterprise architecture.
The benefits of the architecture and who benefits are issues too. What are the benefits of the architecture? Who benefits the enterprise or the business user? Which are more important: the efficiency benefits (i.e., reduced costs and/or increased productivity or the effectiveness benefits (e.g., value)? And, when will the architecture begin to deliver its benefits?
Finally, users have constraints that inhibit their ability to adopt the architecture and its standards. Examples include the impact on installed systems, migration costs and loss of control. These (often valid) constraints must be addressed to gain user compliance. What are those constraints and which strategies should IS organizations adopt to gain user compliance?
These are the issues that corporate IS organizations and Chief Architects must address and resolve to successfully implement the IT architecture and standards. Implementation means compliance. Without user compliance, the best architecture will fail. The goal of this paper is to provide strategies to overcome these issues.
What is a standard? Basically, it is an agreement about how we will do something. In IT, it could be an agreement about which language we will use to develop applications or the hardware and software configuration of a desktop PC. The standard is a statement of our agreement.
As an example, if we want to have a conversation, we need to agree on the language we will use. We could speak in English or French or Japanese. It doesnt matter which we choose (although we may have differing preferences) as long as we can both converse in it. There is no right choice; it is simply our agreement. So, the choice of language is a standard that we adopt and, having made a choice, we can communicate. Conversely, without a choice, we run the risk of not understanding one another and being unable to communicate effectively. The key criteria is that the choice is workable for both of us.
Similarly, in IT, we need to make choices about how we do things. The difficulty with IT standards arises from what we consider a standard to be (definition), how we choose the standard (criteria), when the standard is effective (timeline) and how and when the standard will evolve. We need to examine our notion of what a standard is.
Whats most important is that there is a standard. Which standard is chosen is frequently of little consequence. As an example, my e-mail address could be firstname.lastname@example.org or email@example.com or firstname.lastname@example.org. It really doesnt matter (although I may have a preference). Choose the standard that offers the best balance between the benefits received and the likelihood of user acceptance i.e., their workability.
Is an IT standard a product? Most frequently, we think of standards in terms of products. For example, we are a Windows XP shop or a Java shop. Setting the standard as a product has economy-of-scale advantages such as purchase volume discounts, ease of support, etc. However, it may not be possible to get agreement on a single product. Using relational databases as an example, some applications may be written using DB2, others with Sybase and others with Oracle. We may not be able to agree on which will be our standard. The impact of choosing a single product may be to force users to convert to that product, often with no benefit. One solution could be to raise the standard to a higher level such as an interface. We recognize that we cannot gain agreement on a single product so we set the standard at an interface level, such as SQL. Since each of the products supports SQL, we can allow multiple databases to coexist and still have a common interface between them. Even that may not work. If all products do not support the common interface, we may need to set the standard at a still higher level such as the format by which we will exchange data or pass messages. Each of these are standards. They differ in advantages and disadvantages (e.g., the number of products to be supported and/or dilution of support resources) but they have the distinct advantage of workability, i.e., users can adopt and comply with the standard.
Similarly, does a standard need to be a single thing? We think in terms of one standard, e.g., a product, such as our desktop client will be Windows XP. Most IS organizations can and do support multiple desktop configurations as well as various flavors (i.e., releases) of Windows. We may also support other desktop operating systems such as Linux, Macintosh or Unix. It would be simpler if we can standardize on a single desktop product but when the test of user acceptance is applied, it may not be workable to do so.
Finally, when will the standard be effective? The gurus returning from the mountaintop with the right standards may expect users to see the wisdom of their choices and rush to adopt the corporate standards. The reality is that users are heavily invested in the very products and technologies that created the diversity in the first place. They cannot (or, will not) adopt the new standard immediately. Compliance with standards is achieved over time. Standards must be presented as a statement of direction rather than a single point in time (today). Users need to know what the strategic direction is and how and when the standard will evolve. This provides guidance that allows the user to plan to intercept the standard over time. For example, if the desktop standard is Windows, which version of Windows is the standard? If its XP, when will the organization migrate to son of XP? This year? Next year? In three years? The best answer may depend upon the PC refreshment cycle. Similarly, when will IS drop support for old versions of the standard? By painting a picture of the standard as a strategic direction and the expected evolution of the standard over time, users can incorporate it into their planning. In our experience, the focus on standards as a fixed target state rather than a strategic direction over time is one of the major failings of IT architecture and standards initiatives.
We have developed an approach to documenting standards that addresses these issues in a focused statement of direction that provides guidance to users over time. The key idea is to describe, in one page, the standard, what it does, why it was chosen, what users should do and what they should not do and how and when the standard will evolve.
The following example is based on an IS organization that wanted to establish a standard for identity management services. It was currently supporting three identity management systems with support resources so diluted that none of them were being exploited. The standard describes the strategic direction and its effect on the three systems.
Directory Services Standard
What Does the Standard Do?
Provides identity management services (e.g., authentication, authorization, personalization, certificate handling and other application development services) and central administration of IT assets.
Why is a Standard Needed?
To consolidate 3 current Directory Services products to one and to develop a full-function, common infrastructure for use by application developers. To comply with corporate standards effective June 2007.
What Should Users Do:
The strategic direction for Directory Services is MS Active Directory.
Novell E-directory and Lotus Domino will be stabilized, with no further enhancements. These products will be repaired as needed.
MS Active Directory will be operational during 1QFY07. Existing HQ server migration will be piloted in 1QFY07 with data migration completed by 3QFY07. Field office migration will be piloted 1QFY07 and completed by 4QFY07. Data migration from Novell to Active Directory will be completed by Oct 07.
What Should Users Avoid:
Further development using Novell E-directory or Lotus Domino.
There are significant advantages to this approach. It describes the standard in a single page, is easy to read and understand, explains the rationale for the choice, provides guidance to users and shows the expected evolution of the standard over time. IS organizations should consider adopting this (or a similar) template.
How should IS organizations decide which standard to adopt? Each choice is a tradeoff with advantages and disadvantages. There are three principal tradeoffs: complexity, costs and effectiveness of support and services. These tradeoffs translate into efficiency (i.e., lower costs and/or greater productivity) and effectiveness (i.e., quantity and quality of support and services delivered) benefits.
Complexity refers to the ability to manage an IT environment. Complexity is a function of the number of things to be managed. In the context of IT, things refers to the number of products and their combinations and permutations. As the number of things increases, the ability to manage them decreases and the cost of managing them increases. At some point, the environment becomes so complex that it is unmanageable at any cost.
As an example, it is clearly more complex to manage ten desktop operating systems than one. Further, as the combinations and permutations of software on the ten systems increases, the management of the desktops becomes increasingly difficult as the number of potential interactions stretches (and finally breaks) the support infrastructure.
What standards accomplish is to reduce the numbers of products and their combinations and permutations from many to one (or, a few). The acquisition, deployment and support can be focused on the standard rather than diluted across many products. The reduction of complexity and its byproducts (lower costs and better support and service) are the single most important benefit of standards to IS organizations.
The most measureable benefit of a standard is lower IT costs. These costs include the costs of acquiring, testing, deploying, maintaining and supporting products. By reducing the number of things, these costs are focused on fewer products and services with the attendant benefits of economy of scale. Acquisition costs decrease through larger volume purchases, testing and deployment and maintenance are done one time rather than many, skills and support resources are concentrated on one technology rather than dispersed across many. Reducing IT costs is the most frequently sought after benefit of IT standards.
It is important to recognize that the benefit of reduced costs accrues to the corporate IS organization (and the enterprise), not to the user. In fact, the user frequently incurs additional costs in complying with the standard. The user must acquire products, test and deploy them, convert to the standard, develop new skills and more. There needs to be some offsetting benefit for users to comply.
The most likely user benefit will be better support and service. While less measureable, this is often the more important benefit to users improved quantity and quality of IT support and services. A proliferation of technologies forces a dilution of headcount, skills and service to customers. Standardization allows these resources to be concentrated resulting in increased levels of support. The expected benefit will be in terms of higher levels of customer satisfaction.
A single product reduces complexity (number of products supported), lowers costs (economies of scale) and increases the effectiveness of support and services (concentrates resources). A higher level standard (e.g., SQL) dilutes these advantages but increases the likelihood of user acceptance. In our view, the principal criteria in selecting a standard is workability i.e., the users ability and willingness to adopt the standard over time. A standard that is accepted and adopted by users is far preferable to one that is right but ignored or rebelled against. In most cases, a reasonable accommodation with users can be reached. If it cannot, it is better to choose an approach that builds compliance than one that will result in an ongoing battleground with users.
In summary, standards reduce complexity, lower IT costs and increase customer satisfaction. The key issue is which standards to adopt. In our view the most important criteria is that of workability that the standard is accepted by users and will be adopted over time.
The technology issues and the management issues of architectures and standards are two sides of the same coin. Both are rooted in the move to open systems and client/server systems. One is about how technology is organized and managed (addressed by standards); the other is about how independent IS organizations work together to achieve a common goal (in this case, an IT architecture).
In the mainframe era, the predominant management paradigm for technology and for IS organizations was centralized and hierarchical. Mainframes were delivered with an architecture and standards, supplied by the vendor, that organized and managed technology resources. In similar fashion, the management of technology was centralized in the IS organization. CIOs made technology decisions and few users were concerned about those decisions. Where islands of automation existed, decisions were typically made within a business unit and were independent of IS control.
In the early 1990s, that mainframe management model broke. With the advent of open systems and client/server systems, hardware and software was perceived to be cheap and business managers acquired their own hardware, software and networks, developed and supported their own applications and operated and supported their own IT systems. They became autonomous IS organizations. Ownership of IT became dispersed across the enterprise.
The result is the shared management problem, i.e., independent IS organizations that need to work together to achieve a common goal. Each IS organization owns IT resources, functions and skills such as technology assets (e.g., hardware, software and networks), IT functions (including application development, delivery and support functions) and IS people (including headcount and skills). They can work independent of one another as islands of automation or they can work together. When they need to work together, there must be an organizational and governance model that describes who is responsible for what and how decisions will be made among peer organizations. This is the crux of the shared management problem i.e., organization and governance.
This issue is particularly important in enterprise architectures. For many organizations, the IT architecture may be the first time that these islands need to work together. It immediately raises the question of who is in charge? We hasten to note that this is very much an issue of corporate style. A corporate, top down, directed style of management is common in many organizations and is perfectly acceptable. In the context of IT architectures, it can be problematic due to user resistance. For most CIOs, the mainframe management model of control doesnt work and leadership is needed instead. Users expect (and demand) a voice in architectures and standards decisions. IT architectures are an enterprise-driven initiative but their success depends upon the cooperation of the business units.
What makes the problem particularly difficult is that the motivation for the enterprise architecture and the benefits from it accrue to the enterprise, not to the business unit. The motivation for an architecture and standards is to reduce complexity, lower IT costs and improve support and service for the enterprise. These are enterprise problems, not business unit problems. Similarly, the benefits of accomplishing these goals accrue to the enterprise, not to the business unit. Over time, business units may benefit but, from a business unit perspective, compliance means extra expenses, delayed projects and may be difficult (or impossible) to accomplish. User benefits such as access to shared resources (e.g., networks or data) or better support and service (at lower cost after IS takes over delivery functions) are delivered later. The common goal of an enterprise architecture benefits the enterprise but costs the business unit.
The impact of this conundrum is an IT architecture that stalls. Users argue over issues such as which standards are chosen, delay, ignore and/or escalate compliance issues through their chain of command (with business goals nearly always trumping architectural compliance). This is the state of many IT architecture initiatives today.
To find a solution, we need to look to governance models that create a management framework among peer organizations. The most useful way to approach this issue is through a federated organizational model. The goal is to create a management framework, among peers, that creates and manages the IT architecture, gives all parties a voice and ensures that their concerns are heard, considered and resolved. In other words, the goal is workability.
The one we have found to be effective is similar to that of governments. Our federal system is a compact of the fifty states sharing power with a central government. It is a federated management model that defines who is responsible for what and how decisions will be made. The framework is spelled out through a constitution a management framework for peer organizations. It is useful to think in terms of an architectural constitution that answers questions such as:
The answers to these questions become the management framework for the IT architecture. They dont require a book. Clear, concise answers provide the management guidance needed.
The key point: in most organizations, business units need (and demand) a voice in architectural decisions. The most problematic issues will be the definition of roles and responsibilities, escalation processes for non-concurrence and the penalties for non-compliance. How that will be accommodated is the essence of an architecture management framework.
A value proposition describes the benefits i.e., value that will be delivered from an architecture. The key question: who will benefit, how and when?
An IT architecture is a blueprint for what will be built in the future. It is a strategic investment plan. Like the blueprint for a house, it shows what the house will look like after it is built and how the pieces will fit together. The value proposition is a statement of the benefits that will be realized after the house is built.
IT architecture value propositions are typically written by the corporate IS organization, from their perspective, with the benefits often accruing to them. There is an underlying assumption that if its good for IS, it will (somehow) translate into everyones benefit. For example, if we lower IS costs, the enterprise, business units and end users will also benefit. That may be true but it takes a leap of faith to see the connection.
We observe three common problems with architecture value propositions: 1) they often focus on IT goals but fail to show the linkage to and impact upon business objectives, 2) they are written from an enterprise (most commonly, IS) perspective, not from a user perspective and 3) they fail to convey the cumulative effect of time, i.e., that benefits grow with time. The practical effect of these shortcomings is that IT architectures are viewed as self-serving for the IS organization with little benefit for users.
There is not a formula for developing a value proposition. There is, however, a format and a series of questions that will help to develop a powerful and focused statement of benefits.
Introduction (or Context)
Strategic IT Direction
Timing of Benefits
We believe that two not one value propositions are needed. One written from the perspective of the enterprise (i.e., senior business managers); one written from the perspective of business unit managers and end users. They are separate and distinct audiences with separate and distinct perspectives and needs. Each must be addressed. The format will be similar but the content will differ.
The value proposition is the declaration of the benefits that will be delivered over time. It explains the value of investing in the architecture and standards. A well-constructed value proposition is vital to gaining acceptance, support and compliance from senior business managers, business units and end users.
Architectural implementation is about compliance, i.e., users understand the architecture and standards, align with it (i.e., incorporate it into their projects) and actively support the architectural initiative. The best architecture and standards will fail if users do not align with it.
Every architects fantasy is that they will announce the architecture and standards and then users will see the wisdom of it and immediately comply. It is a field of dreams theory: if we build it, they will come. The reality is that most users will resist. Architectural compliance happens over time as benefits are delivered.
In the best of situations, users find it difficult to align with the architecture even when they want to. The most common reason is installed applications which require new investments and/or enhancements to comply. Equally challenging are application packages that come with a vendor-supplied architecture. Finally, there may be other issues (e.g., loss of control) that cause users to resist the architecture. Resistance is the norm. Users cannot (or will not) comply in the near-term for four principal reasons:
These user constraints are valid. It is up to the corporate architecture staff to alter the users perception. It can be done but its takes more work than simply announcing the existence of the architecture and standards and waiting for it to happen.
The key point is that the benefits of an architecture and standards are like a snowball small in the beginning but increasing as the snowball rolls downhill. The analogy fits architectures. The benefits grow as the architectural initiative gains compliance. As more and more users align with the architecture, individual users gain access to more and more enterprise resources such as desktops, networks, data and support services. Access to resources is a key user benefit of the architecture.
IS organizations must create an implementation strategy that recognizes user concerns and addresses them over time. The strategy must identify and support tactical initiatives that move the architecture forward, maintain focus on the benefits to be delivered, and assist early adopters to ensure their experiences are positive. Strategies that work include:
The bottom line is that alignment i.e., compliance occurs over time. IS architects need to establish the strategic direction and then tactically partner with user organizations to implement key portions. At the same time, they need to paint the picture of the benefits that are and will be delivered and the benefits to user organizations that are being realized.
For many IS organizations, their architectures are stalled in implementation. Despite major investments in development, the architecture and standards sits on a shelf awaiting user compliance or is the source of continuing battles with users. Moving the architecture forward in implementation requires:
There is no silver bullet. Nevertheless, the issues that inhibit the adoption of the architecture and standards are manageable. And, they are worth managing. In the process, CIOs will also resolve two of the most challenging IT management issues of today: managing technological complexity and sharing responsibility for managing IT with independent IS organizations.
Home | Who Is WTMG | Bios | Services | White Papers | Contact Us
2006 Weston Technology Managment Group. All Rights Reserved.
Proudly Powered by Infinite Dominion.