Implementation of EA Means Building User Compliance

Enterprise architectures are a major initiative for most IS organizations. Yet, despite major investments in their development, many are stalled in implementation awaiting user compliance.

In the best of situations, it is difficult for users to align with the architecture. They are constrained by “legacy” applications. They encounter significant costs for acquiring new products, developing new skills and reengineering support and services. Their projects are delayed to affect these changes. And, for them, the benefits are a future potential.

Until users perceive enough value to offset the upfront costs, the architecture will stall in its implementation. Users will argue, resist, ignore and/or escalate their concerns through business unit management (with business needs nearly always trumping architectural needs). The best enterprise architecture will fail without user support. This is the state of many enterprise architecture initiatives today.

Implementation of an enterprise architecture means building user compliance. User compliance, in turn, depends upon resolving 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?

Standards
A standard is an agreement about how we will do something. Which standard is chosen is a tradeoff between how specific the standard is, i.e., its granularity, and the ability of users to adopt the standard, i.e., its “workability.”

We think of a standard as a single “thing,” e.g., an IT product or business system. But, the more specific the standard, the more difficult it may be for users to adopt it. There are alternatives.

For example, a relational database standard could be a product, e.g., DB2 or Oracle. It could also be an interface, such as SQL, that accommodates multiple products. And it could be a format by which we exchange data. Each of these is a standard. They differ in specificity and the ease with which users can adopt the standard.

Similarly, a standard does not need to be a single “thing?” Most IS organizations can and do support multiple IT products and/or business systems. A standard can accommodate multiple “things.” A single product is simpler to manage but to gain user acceptance, it may not be workable.

Finally, standards need to be presented as a statement of direction over time rather than a single point in time (today). An evolving standard can become more specific over time. Defining the standard as a strategic direction, with an expected evolution, allows the standard to become more granular and allows users to incorporate it into their projects over time.

How should IS organizations decide the level of granularity to adopt for standards? The choice is a tradeoff between benefits and “workability.” A single product or system delivers maximum benefits, such as reduced complexity, lowered costs and increased effectiveness of support and services. A higher-level standard dilutes these advantages, but increases the likelihood of user acceptance. Drive toward the lowest level of granularity to gain user compliance. A standard that is accepted and adopted by users is far preferable to one that is “right,” but ignored.

Management Issues
In today’s enterprise, there are many IS organizations. Each “owns” technology assets, IT functions and IS people. Each of these peer IS organizations needs–and may demand–a “voice” in architectural decisions. To work together, they need a management framework for how that will be accomplished. For many enterprises, the architecture may be the first time that these “islands of automation” need to work together to achieve a common goal.

To develop and implement an enterprise architecture, these peer IS organizations need a common goal and a governance model that describes how the enterprise architecture will be managed. The model we have found to be effective is similar to that of governments– a federated management model that defines the common goals, who is responsible for what and how decisions will be made. It is spelled out through a constitution. It is useful to think in terms of an architectural “constitution.”

• Preamble: Why are we doing this? What are the common goals and benefits that we hope to gain from the architecture and standards?
   
• Constituents: Who is affected? Most likely, it is directed toward senior IS and senior business managers that make IT-dependent investment decisions.
   
• Executive Responsibility: Who is responsible for the IT architecture and standards? Frequently, this is the corporate CIO (although responsibility may be delegated to an individual or group). Typically, there is business oversight to resolve the inevitable disagreements over architectural compliance.
   
• Legislative Responsibility: How will the “laws” of architecture and standards be decided? Who proposes standards, who gets to vote on them, how will non-concurrence be handled and who makes the final decision?
   
• Judicial Responsibility: What is the penalty for noncompliance? Often, IT projects require approval by an Investment Review Board and the penalty is an IS non-concurrence with the proposed project. The IRB can override IS’ objections, but the process becomes far more difficult for the sponsoring manager.
   
• 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?

In most enterprises, business units need (and may demand) a “voice” in architectural decisions. 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?

Users have different needs from the enterprise–they are a different constituency. Typically, enterprises seek economy of scale benefits. By standardizing the IT environment, complexity is reduced and economies of scale become available. Support and service become focused on fewer products and systems, creating measurable improvements. In contrast, users want interconnectivity and interoperability. They want access to resources (e.g., desktops, networks, data), higher quality data, less rework and better support and service at lower costs. Their perspective tends to be more tactical and focused on better ways to perform their jobs.

IS organizations are accustomed to developing enterprise value propositions; they must also develop ones that address the needs of the business units. Two value propositions are needed, not one. Value propositions that target the business unit are similar to those for the enterprise, but they explain the enterprise architecture in terms that are meaningful to users and lead them toward alignment out of enlightened self-interest.

For a powerful and focused statement of benefits, three issues must be addressed–the business context of the benefits, the specific benefits that will be delivered and the timing of those benefits.

• Context: The context describes the user’s business environment and addresses three essential issues: 1) what is the user trying to accomplish, i.e., mission (or business objectives)? 2) what gets in the way of fulfilling these objectives, i.e., the impediments, problems and issues that must be overcome? 3) how will the architecture and standards reduce the obstacles and help the business unit accomplish its goals and objectives? The intent is to establish a direct linkage between the architecture and the business’s goals and objectives.
   
• Benefits: What benefits will the architecture provide? These are expressed as efficiency benefits and effectiveness benefits, for both business and IT. Efficiency benefits refer 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. How will the architecture reduce business and/or IT costs and increase productivity? Effectiveness benefits refer to the delivery of “value.” How will the architecture help the business unit accomplish its goals and objectives? For example, will the architecture help reduce cycle time or provide higher levels of service to customers? How will it improve data quality or increase access to applications, systems and/or other IT resources?
   
• Timing: When will these benefits be delivered? Benefits are like a “snowball” that grows in volume, mass and impact as it rolls downhill. Similarly, architectures grow in value as more and more users align with them and interconnectivity and interoperability increase. The value proposition must explain how users will gain increased access to resources, better quantity and quality of support, and lower costs over time. Conversely, users that are not aligned will lose access to these resources and their costs will increase. These differences will grow over time. Value propositions need a time horizon for the delivery of benefits.

Finally, there needs to be a communications strategy that “paints the picture” of the benefits of alignment versus the costs of non-compliance over time. It needs to show how the architectural “snowball” of benefits is increasing for organizations that are aligned with the architecture, while diminishing for those that are not aligned. And they must show how these gaps will widen over time. This message must be regularly communicated. The goal is to paint the benefits picture in terms that portrays the architecture as being in the user’s self-interest, i.e., users see–and want–the benefits of alignment.

Building Compliance

Architectural implementation is about compliance, i.e., users understand the architecture and standards, incorporate it into their projects and actively support the architectural initiative. However, users have real constraints. Implementation strategies must recognize these constraints, mitigate them where possible and build upon what users can and will do.

Users encounter significant barriers to architectural compliance. Understanding these obstacles and mitigating them is the key to building compliance. There are four principal issues:

1. “Legacy” applications: Users are constrained by installed applications and systems. Conversion of an operational system delivers no functional benefits except architectural compliance.

   Thus, implementation strategies need to focus on applications that are or will change. New applications create an opportunity to move toward compliance. Similarly, investments in existing applications, such as reengineering and/or enhancements, create opportunities for compliance. Implementation strategies that focus on these changing applications are far more likely to be successful.
    

2. Costs of Migration: It costs users to migrate to a new architecture and standards. They must buy and deploy new products. They must acquire skills they don’t currently have. They must reengineer service and support strategies. And it takes time to migrate to the new architecture resulting in delays to their projects.

   This means that implementation strategies should not expect progress toward compliance from users that do not have investment resources, but should focus their efforts where time, money and opportunity are available.
    

3. No Perceived “Value”: When an architecture is announced, its value is a future potential. Unless users see meaningful benefits being delivered, there is little reason for them to incur the costs of migration for no perceived value.

   The implications are that implementation strategies should focus on those users for whom the benefits of the architecture are significant. They must tell the benefits “story” in a way that serves the user’s self-interests.
    

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 lower costs and better support and service, but that has (usually) not yet been demonstrated.

   Implementation strategies may need a phase-in strategy, based on milestones achieved, whereby users gradually relinquish control as better corporate support and service and lower costs are demonstrated.

These constraints mean that most users will move toward architectural compliance in stages over time. The notion of immediate and full compliance is a fantasy. The most successful strategies broadly describe the architectural direction while drilling-down deeply into major, selected areas in an iterative process. These strategies are constructed from the following components:

• Seek Breadth and Depth: Create a broad framework of what the architecture and standards will look like in the major environments to be addressed and then choose partners that are willing to drill down deeply into one or more of the areas.
   
• Focus on New Investments: New investments include new applications and/or systems and those for which major enhancements are planned. For these applications, funding is available, they are undergoing change 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.
   
• Find Partners: In the beginning, choose your battles. Find partners that are willing and able to move along the architectural path, preferably a few large, prestigious business units that are viewed as leaders and whose endorsement of the architecture will influence other users. Focus your compliance efforts on them and provide support to them to achieve an architectural “win.”
   
• Develop Intercept Strategies: For users that cannot (or will not) align with the architecture today, develop intercept strategies that move them toward compliance over time. Help them to minimize the differences today and develop plans to intercept the architecture in the foreseeable future.
   
• Provide Help: Users need help, especially early adopters. IS organizations need a support infrastructure (whether real or virtual) that delivers it. Where do users go for help in understanding and applying the architecture and standards? Who will help in designing applications to move toward compliance? Where should they go for training to develop new skills? A support infrastructure, similar to the kind that they would provide in deploying any new application, is needed.
   
• Market the Successes: Develop a communication strategy that markets the architectural “wins.” The goal is to paint a picture of the growing number of organizations that are aligning with the architecture and the growing stream of benefits they are receiving. You want to keep this “story” continuously in the minds of users. And, you want to portray alignment as serving the selfinterests of users so that they want to be a part of and a beneficiary of the architecture.

  The bottom line is that compliance occurs in stages over time. Successful implementation strategies are built upon a series of architectural “wins” through tactical partnerships with users on applications that have investment resources and are undergoing change that move the architecture forward in an iterative process. Concurrently, they are marketed by continuously reminding users of the growing list of organizations that are aligning with the architectural direction and the stream of benefits that are being realized.

Summary

There is no silver bullet. However, the issues that inhibit 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 IT management among peer IS organizations.

Mark L Hess has more than 30 years of IT operational experience, including 14 years as a vice president of Gartner Group, where he led the development and delivery of Gartner research into CIO management issues, including aligning IT strategies with business strategies and IS organization and governance. Hess’s research and methodologies have been used by hundreds of Fortune 1000 enterprises worldwide and are the foundation for Gartner Group’s Consulting Practices Group.