White Paper


Enterprise Architectures (V2):

If We Build It, Will They Come?
June 2006

Mark L. Hess
Weston Technology Management Group
Phone: (843) 235-9890
E-Mail: Mark.Hess@WTMG.ORG

Executive Summary

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:

  1. Choosing standards based on “workability”, i.e., standards that users can and will adopt.
  2. Adopting a “shared management” governance model that gives users a “voice” in the management of the architecture.
  3. Developing two value propositions – one for the enterprise, one for end users – that shows each how the architecture will help them to achieve their business objectives over time.
  4. Mitigating user constraints through a support infrastructure that helps users overcome them.
  5. Building compliance over time through partners that can and will incorporate the architecture and standards into their projects.
  6. Developing and marketing the benefits “story” that demonstrates the growing list of benefits to users that are aligning with the architecture.

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:

  1. Which standards should be selected and why?
  2. What governance model will build user support?
  3. What benefits will the enterprise architecture deliver, when and to whom?
  4. How can IS organizations grow user compliance?

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.

Standards 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 doesn’t 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.

What’s 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 “mhess@wtmg.org” or “markhess@wtmg.org” or mark.hess@wtmg.org. It really doesn’t 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 it’s 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.

Standard Timeline:

FY06 FY07 FY08 FY09 FY10
Directory Services MS Active Directory (Installed - 4Q) MS Active Directory
(Operational – 1Q) MS Active Directory
(Exploitation) MS Active Directory
(Upgrade to current release) MS Active Directory
E-directory Stabilized Retired Retired Retired Retired
Domino Stabilized Stabilized Retired Retired Retired

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 user’s 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.

Management Issues

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” doesn’t 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:

  1. Preamble

    Why are we doing this? What is the problem to be solved and what are the common – i.e., shared by IS and by users – goals and benefits, that we hope to gain from the architecture and standards? Said differently, this is the context for the IT architecture and standards.

  2. Constituents

    Who is affected? The temptation is to say “everyone” in the enterprise. More likely, the architecture and standards are directed towards senior IS and senior business managers that make IT-dependent investment decisions. These are the individuals from whom compliance is needed and they are the target audience.

  3. Executive Responsibility

    Who is the executive responsible for the IT architecture and standards? Typically, this is the corporate CIO although responsibility may be delegated to an individual (e.g. a Chief Architect) or group (e.g., an Architecture Council). In addition, there needs to be business oversight (e.g., a Business Council) to resolve the inevitable disagreements over architectural compliance. The question is who has the ultimate responsibility for the architecture and standards initiative?

  4. Legislative Responsibility

    Who gets to vote on the architecture and standards? Who proposes standards, who gets to vote on them, how will non-concurrence be handled and who makes the final decision? Said differently, how will the “laws” of architecture and standards be decided? Does the CIO decide? The Architecture Council? Business unit managers? All or some business units? Perhaps most importantly, what is the review and concur/non-concur process? What is the escalation process if someone non-concurs and how will it be adjudicated?

  5. Judicial Responsibility

    What is the penalty for non-compliance? Is there a penalty? If so, what is it? Is it spending authority (e.g., dollar limit), procurement authority (i.e., will not approve a purchase order) or will something else bad happen? Often, IT procurements require the approval of a Business Council or a Capital Investment Committee and the penalty is an IS non-concurrence with the proposed project. The Business Council can override IS’ non-concurrence (for business reasons) but the process becomes far more difficult for the sponsoring manager.

  6. Amendments

    How and when will the architecture and standards evolve? Business strategies change; technologies change; products change; versions and releases change. How and when will the standards evolve to accommodate these changes? For example, if the PC refreshment cycle is three years, should all users plan to upgrade to the then-current versions of hardware and software at that time? How and when will new and different technologies be introduced?

The answers to these questions become the management framework for the IT architecture. They don’t 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.

Value Proposition

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 it’s good for IS, it will (somehow) translate into everyone’s 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.

  1. How does the architecture help business managers achieve their objectives? The most commonly cited benefits of an IT architecture are reduced complexity, lower IT costs and better support and service. These are worthy objectives but they are IS objectives, not business objectives. Business objectives are typically in terms of lower product and service costs, reduced cycle time to deliver them, added value or customer satisfaction. They will differ for every organization depending on what their strategy is. What problems does the architecture address that will help business managers accomplish these objectives? To be relevant, the value proposition needs to clearly establish the linkage to business goals and objectives.

  2. How does the architecture help business units and end users? IT architectures are typically an enterprise initiative with the benefits accruing to the enterprise. Will lower IT costs result in lower business unit and/or end user costs? If so, when and by how much? The value proposition must be written from the perspective of the end user and answer the “WIIFM” question (What’s In It For Me). If it does not, there is little incentive for users to support the architectural initiative.

    The reality is that architectures and standards negatively impact users. There is a cost for compliance. Sometimes that cost is financial (the need to buy new and/or additional products or investing in new skills); sometimes, it is additional work to fit projects into the architecture and standards; often it results in a delay in accomplishing projects.

  3. When will benefits be delivered? The benefits of an IT architecture are like a snowball. It starts small but, as it rolls downhill, it increases in mass, velocity and impact. So too, the benefits of the architecture grow over time. Which benefits will be delivered, to whom and when? IS organizations must “paint a picture” of the growing list of benefits, over time, as more and more users align with the architecture and the architectural snowball grows in size, momentum and impact.

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)

  1. Business (or Mission) of the Organization — What is the business trying to accomplish? For example, what are the most important strategic goals and objectives that reflect the strategic direction of the organization? This is the context within which the architecture must make sense.
  2. Current Problems or Issues – What gets in the way of accomplishing these goals and objectives? This is a statement of the impediments (i.e., problems, obstacles, issues and concerns) that must be overcome to accomplish the organization’s objectives. Said differently, they are the issues that the architecture and standards must address to be relevant.
  3. Linkage – How will the architecture and standards help the business accomplish its goals and objectives? The intent is to establish a direct linkage between the architecture and the business’s goals and objectives, i.e., how the architecture will solve the problems and thereby contribute to accomplishing the business goals and objectives.


  1. Mission Fulfillment – How will the architecture help the enterprise accomplish its business goals and objectives? These need to be expressed in business terms. For example, how will the architecture help the enterprise reduce its cycle time or deliver higher levels of service to its customers?
  2. Increased Efficiency – Efficiency refers to cost and productivity. It means doing things at lower cost per unit and/or increasing the number of “things” produced at the same cost. For example, the cost to support a PC is a cost metric; the number of PCs supported per support person is a productivity metric. Both may be benefits (although separate and distinct benefits) of the architecture. How will the architecture reduce costs (whether business costs or IT costs) and/or increase productivity?
  3. Increased Effectiveness – Effectiveness refers to the delivery of “value”. How will the architecture increase the value delivered to the enterprise? This could be similar to the mission fulfillment benefits but expressed at a more granular level. An IT example might be improved data quality or increased interoperability between applications, systems and/or other resources; a business example might be reduced cycle time to accomplish the mission.

Strategic IT Direction

  1. Having a blueprint of what the enterprise intends to build over time is often a major benefit of an architecture. It shows users where IT investments will be made and how users can best take advantage of those investments. The IT Strategic Plan is one expression of the IT investment strategy; the architecture is another expression of it.

Timing of Benefits

  1. When and how will these benefits be delivered. The intention is not to state a firm timeline but rather to create an expectation that benefits will be delivered over time and will grow in value as more and more of the architecture is built and more and more users align with the strategic direction.

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.

Building Compliance

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 architect’s 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:

  1. “Legacy” applications – Users experience the same problems that IS organizations encountered in the 1990s – they are constrained by installed applications and systems. They cannot stop and convert to the new architecture and standards even if they want to. They can only achieve alignment as new applications are developed or major investments to existing systems occur. Thus, alignment can only occur over time as new investments are made.

  2. Costs of Migration – It costs users to migrate to a new architecture and standards. Users must buy and deploy new products ranging from hardware and software to networks. They must acquire skills they don’t currently have. And it takes time to migrate to the new architecture resulting in delays to their projects. These user costs are rarely funded or mitigated in architectural implementation strategies.

    Migration costs are both a corporate issue and a user issue. However, the corporate costs are far more likely to be funded than the user costs. Users are typically “on their own” to find the money needed.

  3. No Perceived “Value” – When an architecture is announced, it has no value, i.e., it has not yet delivered any benefits. Its value lies in its potential to deliver benefits in the future but that is potential, not reality. Unless the value proposition presents a compelling case for future benefits, there is little reason for users to incur the costs of migration for no value.

  4. Loss of Control – Users feel (rightly or wrongly) they are in control of their own applications and systems. Their perception is that they get to make the decisions about what to do, when to do it and how to do it. Architectures may promise better support and service but that has (usually) not yet been demonstrated. A phase-in strategy may be needed whereby users gradually relinquish control as the benefits of corporate support and service are demonstrated.

These user constraints are valid. It is up to the corporate architecture staff to alter the user’s perception. It can be done but it’s 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:

  1. Seek Breadth and Depth – The tendency of IS organizations is to completely develop the architecture before announcing it and then to expect full compliance thereafter. In most cases, this isn’t realistic. The more likely scenario is a strategy whereby IS organizations (initially) broadly describe the architectural direction and then drill-down deeply into major, selected areas. It is an iterative process that continually broadens and deepens the architecture.

    Create a broad framework of what the architecture and standards will look like in the major environments to be addressed (such as server, desktops, networks, software, support services, application development, etc.) and then choose partners that are willing to drill down deeply into one of the areas.

    By following this strategy in each major area, the architectural initiative moves forward along all fronts. It helps users accomplish their projects, gives the IS organization experience with the implementation issues and builds a track record of architectural successes along each leg of the architecture. It’s a “win-win” strategy that moves the architecture and standards strategy and implementation forward.

  2. Focus on New Investments – New investments include new applications and/or systems and those for which major enhancements are planned (major investments are often defined as two or more man-weeks of programming enhancements). For these applications, funding is available and there are choices to be made. There is an opportunity to influence the choices. There is also leverage since they are subject to the investment approval process. The goal is to move these applications toward architectural compliance – if not today, then with an intercept strategy that increases compliance over time.

    The PC refreshment cycle is a prime example. PCs are normally replaced on a two to three year cycle. This replenishment is typically funded, provides an opportunity to introduce change and becomes a logical point in time at which to align with the corporate desktop standard.

  3. Find Partners – Over time, you want all users to become architecturally compliant; in the beginning, choose your battles. In every enterprise, there are a few large, prestigious business units that are viewed as leaders and whose endorsement (of the architecture) will influence other users. These are the ones to partner with initially. Choose partners that are willing and able to move along the architectural path. Focus your compliance efforts on them and provide your support to them to achieve an architectural “win”. You are trying to develop a marketing “story” that demonstrates that the most important user organizations (in terms of size and prestige) are aligning with the architecture. With their support, it will be far easier to bring the rest along later.

  4. Develop Intercept Strategies – Circumstances often prevent users from aligning with the architecture immediately. For these users, an intercept strategy needs to be developed that helps users to achieve alignment over time. Help the user to minimize the differences today and to intercept the architecture in the foreseeable future. An example might be the user that aligns with the architecture during the next PC refreshment cycle.

  5. Provide Help – Users will need help, especially early adopters of the architecture. IS organizations need to put a support infrastructure in place to deliver that help. For example, where do users go for assistance in understanding and adopting the architecture and standards? Early adopters will need help in planning and designing their applications to approach compliance. IS organizations should consider assigning a technical person to key projects to assist the user in compliance as well as learning first-hand the user issues in applying the standards. Similarly, training arrangements are needed to assist users in developing new skills. Finally, consider financial assistance to offset some of the unfunded costs of acquiring new products and services. The goal is to minimize and/or reduce the impacts on users of adopting the architecture and standards. This support infrastructure is similar to the kind of support that any IS organization would provide in deploying a new application.

  6. Market the Successes – Develop a communication strategy to market the architecture. You want to keep the architecture and standards continuously in the minds of users. In particular, you want to promote the successes as users align with the architecture and benefits are delivered. The goal is to paint a picture of growing alignment with the architecture and a growing list of benefits that users are receiving. You want it to appear to be in the user’s self-interest to be a part of and a beneficiary of the architecture. This is Marketing 101.

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:

  1. Choose standards for “workability”, i.e., ones that users can and will adopt. What’s important is that there is a standard; which standard is chosen will be a tradeoff between enterprise benefits and user compliance. Choose user compliance.
  2. Adopt a “shared management” governance model. Users need a “voice” in the management of the architecture. Develop a management framework that recognizes their role in the management process.
  3. Develop two value propositions – one for the enterprise, one for end users. Show how the architecture will help each to achieve their business objectives over time.
  4. Recognize and mitigate user constraints. They are valid. Develop a support infrastructure that helps users overcome them.
  5. Expect compliance over time. Seek breadth and depth with partners that can and will incorporate the architecture and standards into their projects. Develop and market the benefits “story” that shows the growing list of benefits for users that are aligning with the architecture.

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.