Are You Ready for Enterprise Architecture?

Before you realize the benefits of EA, you must communicate its value to the business so that it''s implemented properly.

Enterprise architecture (EA) is often sold as an elixir for "better aligning IT goals with business goals." You've probably heard promises that EA can serve as a strategic vehicle for:

  • Reducing IT costs.
  • Enabling business change.
  • Simplifying technology portfolios.
  • Supporting greater flexibility.
  • Improving process effectiveness.
  • Delivering IT projects more quickly and cheaply.
  • Implementing IT governance, especially regulatory compliance such as the Sarbanes-Oxley Act.
  • Rationalizing application portfolios.

With these promises in mind, is it logical to think that your IT organization can implement EA? It depends. To the executives in your organization, how important is the value of information technology in terms of your business? What are other organizations in your industry are doing to meet business needs and cut IT costs? Does your IT group command credibility across other parts of the business? Is the group ready to embrace EA? Can the group members establish the discipline necessary for a successful EA implementation?

The job of EA is to translate internal and external technology forces so that your business managers can anticipate and prepare for future changes that might affect business processes. EA can better align IT capabilities with the needs of your business. EA can help your organization improve its ability to deliver IT services. EA can provide more effective IT governance, especially when combined with IT portfolio management, IT service management, and IT project management. But, unless you can communicate the essence of your EA efforts to your entire organization, EA's overall value is limited.

To communicate EA effectively, you might try to explain the importance of EA with combinations of PowerPoint presentations, Visio diagrams, Excel spreadsheets, Word documents, and so on. But for lack of a better solution, consultants are often hired as a human interface to bridge the gap between IT and business. Your position as part of the EA team within your organization can then evolve undesirably into the governance police or an on-call reference center.

Most of the EA tools in the marketplace are oriented toward an audience of enterprise architects, but the value of these tools depends on whether the information they capture and convey can be relayed to your colleagues who are not enterprise architects. The question "Does EA have any value if it's not communicated?" begins to sound similar to "If a tree falls in the forest and no one is there to hear it, does it make a sound?"

The EA Bridge
At its core EA is the bridge between business and technology. You must connect the technology groups and business groups, helping these divergent audiences share a common vision and a common vocabulary, and enabling them to establish a common set of expectations and objectives.

EA allows your organization to become technologically capable of joint performance by making its technological strengths more effective and simultaneously making its weaknesses irrelevant. Your organization's ability to and manage technology in the same way it manages money, people, and property is a measurement of its EA's success.

You can conceptualize an EA bridge by envisioning a twisted rope made up of three intertwined strands, where each strand is composed of many separate yarns. The first strand corresponds to models. Some of the model yarns describe business processes. Others represent data entities and relationships. Yet others define your organization's underlying technology architecture, which explains its infrastructure and application portfolio.

The second strand in the twisted rope analogy reflects documentation. It involves populating the models defined by the first strand. Models get represented simply in terms of graphics and structural metadata, but you might find it challenging to capture and collect the information that describes the complex artifacts associated with the models.

The twisted rope's third strand involves communicating the documented information organized around the models. You must resolve questions such as "What's the value of EA if its contents are not communicated effectively?" and "How much can EA be worth if the only ones who read what the enterprise architects have written are the authors themselves?"

EA and ROI
There's a fixation within the EA community to somehow find an easy way to demonstrate return on investment (ROI). Architects originally intended to use EA as a planning tool to better align IT with the overall business strategy. But the most successful implementations have come from organizations that used EA to communicate IT's future direction to the stakeholders, thereby helping managers make more informed technology decisions. By enforcing EA governance with respect to IT investment decisions, you can prevent different business groups from either reinventing the wheel or embarking on their own development of one-off, nonintegrated point solutions.

You must standardize and consolidate to achieve EA ROI. It doesn't matter which performance metric you measure; standardizing improves efficiency by lowering costs, shortening cycle times, and reducing staffing. Standardization coupled with consolidation also increases effectiveness, expands interoperability, and improves security. If you don't embrace this strategy, you waste IT resources: The unbridled acquisition of different project teams that buy different products delivers redundant functionality.

The purpose of establishing IT standards is to reduce complexity and increase efficiencies through consolidation and improved collaboration. You will find that standards enable an IT team to do more with less. You can cut costs significantly by consolidating data centers, standardizing platforms, and pruning redundancies.

However, you should be aware that EA groups are frequently considered cost-overhead and as such are subject to cost-cutting purges. To avoid this problem, you should focus initial EA initiatives on consolidation projects that dramatically cut costs. Then you need to communicate your EA successes and the value EA has achieved with other groups in your organization.

Architecture is a complicated, complex, and expensive process that changes and evolves continuously and never finishes. Your IT group must define its own EA models that describe its technology usage.

The largest individual investment your organization makes in EA can also be its most poorly managed—for example, the technical skills and product know-how that's locked up inside the heads of your organization's enterprise architects who use IT products and applications every day as a part of their jobs. Your IT group needs to improve how it collects and shares internal knowledge.

Typically the orientation of an EA effort is geared toward those who are producing the enterprise architecture. But EA should not be done in isolation. You must place importance on how the context of EA is delivered to groups in your organization that are not composed of enterprise architects.

As with business planning, the true value of EA is indirect. How do you measure the value of business planning? You measure it by the successful execution of your EA plan. How do you measure the value of EA? You measure it by the successful execution of common IT assets, components, and services. EA can deliver tremendous value, but you must use it. For EA to be implemented in your organization, you must first communicate its value to the business.