When Enterprise Architecture is Most Effective and the Primary Reasons that Enterprise Architecture Efforts Fail

Enterprise Architecture and Standards (EA&S) provide shared situational awareness to the entire organization’s operating model and enable the PMT and functional review teams to manage by exception. Traditional IT practitioners will equate the term architecture with a representation of hardware and software. Enterprise architecture, however, includes the technical architecture as well as the process and organizational views. It is a broader scope that becomes increasingly necessary as organizations achieve diminishing returns from technology investments and must combine process and organizational changes with technology to obtain greater value from investments.

The purpose of any architecture is integration: to ensure that each component of the system operates efficiently and effectively with other components. The purpose of IT architecture is to ensure that each application and hardware component operates in harmony with—or is properly isolated from—other components. The purpose of enterprise architecture is to ensure that processes, technology, and organizational responsibilities operate in concert.

Enterprise architecture provides the PMT and other decision makers with situational awareness of how the organization operates. In the absence of an enterprise architecture rendering, each decision maker has a different perception of how the organization operates. It is like the proverbial blind men trying to develop common understanding of what an elephant looks like. They might be able to piece together their individual impressions over time and arrive at a shared picture, but wouldn’t it be better if every senior leader had a common view of the whole elephant from the beginning? Enterprise architecture renderings show how each project fits into the bigger picture. They provide traceability from the business workflow requirements through to the IT infrastructure requirements. This feature allows designers to take a 360-degree look at what an application might affect (people, process, and technology) if changed, providing IT practitioners better contextual awareness of their actions, and helping business and IT managers understand the complexity involved in changing critical components (workflow, technology, policy, and roles). Finally, they help the PMT better understand the business implications of a project.

Like resource management, EA&S needs to be integrated into the portfolio management process. The PMT determines the cost structure of the organization. In so doing, it creates incentives (or disincentives) for efficient designs of process and systems. If the PMT values a better understanding of the enterprise architecture, it may sponsor its documentation or at least require some chief architect to learn the architecture and advise the PMT. If the organization wants to standardize, it had better get the PMT to understand, buy in to (accept accountability for), and enforce the standards. If the PMT is oblivious to the full effect of its decisions on the enterprise architecture, then it leaves to chance the possibility of achieving any benefits from EA&S. Consequently, huge investments in EA&S will not return significant value without the PMT on board and the EA&S activities integrated with the portfolio management decision making.

Contrary to popular belief, EA&S is not supposed to constrain the organization but to enable it. Projects with designs that comply with EA&S guidelines should move through the portfolio management processes without difficulty. The organization manages the design decisions by exception, trapping only those designs that do not comply with EA&S. The PMT or project governance team stops projects that do not comply to enable the organization to evaluate whether the enterprise architecture is flawed, the standards are obsolete, or the project design is unsuitable. Failure to trap noncompliant projects removes the teeth from the EA&S process.

The PMT is accountable for EA&S standards decisions. The enterprise architecture process consists of analysis (design) and decision-making (governance) activities. Enterprise architecture decisions are business decisions that must be made by the PMT in the context of the strategic plan and the bottom line. After the PMT buys into the enterprise architecture, then standards (for technology, process, facilities, human resources, etc.) can be established by the functional disciplines to facilitate the transition to the desired state. In the absence of an accepted future-state enterprise architecture rendering, technical standards decisions are made without a well-understood and agreed-upon roadmap (a time-sequenced list of required initiatives) that defines how the organization will make the transition from the current state to the desired state. Hence, for example, one manager thinks that standardization is the right answer while another thinks that decentralized autonomy is. One manager thinks that growth is most important while another thinks that cost containment is. Both may be the right answer, depending on what part of the business from which one is viewing things. Most staff functions strive for efficiency while most customer-facing functions strive for growth. As long as these parts of the organization hold conflicting visions, the effect of EA&S will be marginal at best. Rather than arguing such points, the organization as a whole is better served by creating the desired-state enterprise architecture rendering, and making all decisions in terms of how effectively and efficiently the standards effect a transition to the desired enterprise architecture.

Conflicting Visions

Because the objective of enterprise architecture is to gain common situational awareness of the desired state of the organization—including responsibilities, processes, and technology—the differences between creating an actionable enterprise architecture and one that sits on a shelf include the following:

• Understanding who is accountable for the outcome

• Determining which responsibilities those who are accountable are willing to delegate to a subteam

• Determining who will represent the organization on that subteam

Enterprise architecture is not exclusively an IT activity, because the most critical enterprise architecture decisions are workflow decisions, which are typically not IT decisions at all. Too often the organization will charter the IT department to go off, develop the architecture, and come back with a drawing. In part, this conception arises because the term architecture has a legacy rooted in technical activities (technology, engineering, construction, etc.). Business leaders are not as comfortable with enterprise architecture, whereas IT organizations have dealt with architecture issues for decades. Given the increasing number of transformational efforts requiring synchronized changes to processes, organizational structure, and technology, however, business leaders must learn to manage EA&S and take a proactive role in its definition.

It follows then that the primary reason EA&S efforts fail is often insufficient participation by the business functions. More than 50% of architecture projects are overseen by IT managers with little or no business involvement. The enterprise architecture project degenerates into a technology architecture exercise. Another common reason for EA&S project failure is that the EA&S team attempts to get the to-be design right the first time. Although this intention may sound efficient, it is not particularly effective. Few organizations have a common understanding of the current-state architecture and issues. So, it is not reasonable to expect people to agree from the start about what the desired state should look like.

To be successful, the EA&S team must establish common situational awareness of the current-state issues and root causes as well as buy-in to the desired-state enterprise architecture. Accomplishing this buy-in often requires an iterative approach that brings the organization along step-by-step. The thought leaders may be three steps ahead of the rest of the organization, but it is not likely that the organization will just accept their expert opinion and move on from there. Thought leaders need to be patient and lead the organization through each step in the thought process. They need to guide the organization to the right answer, not cram it down their throats. Achieving buy-in may also require compromise. If the EA&S team develops a perfect architecture, from an engineering perspective, but the key decision makers do not truly support the vision, then the EA&S effort has failed. The EA&S team may need to compromise technical efficiency to accommodate political differences or real financial constraints. This concept is a difficult one for technologists and engineers to accept. It might take the organization several iterations over several years before the key stakeholders see the wisdom of the “perfect” architecture and are willing to support it. On the other hand, they may decide that the organization is inherently imperfect and, hence, cannot support the perfect architecture. In enterprise architecture, as in life, the best choice is not always the ideal answer.

Yet another reason EA&S efforts fail is that the project team suffers from documentation paralysis: it becomes maniacally focused on creating drawings and loses sight of the project objective. The best enterprise architecture can be written on a napkin if such a basic representation is what it takes to get the organization to buy in. More likely, the team will get caught in the trap of building complex models. These models have value in highly complex applications, but they take a considerable amount of time to build and often are not easily understood by the decision makers. They are often time-consuming to maintain. Unfortunately, most of the tools are designed for analysis, not presentation of the enterprise architecture renderings to senior leadership. This focus causes the EA&S team to create even more documentation to communicate to management and the rest of the organization. Before you know it, the team is devoting more time to documentation than it is to making meaningful recommendations. The team becomes resistant to change, because it is so time-consuming to make those changes. The effort it takes to maintain the models becomes prohibitive, the team becomes obstinate, the PMT loses patience, and a lot of resources are wasted.

Enterprise architecture is most effective when performed iteratively. Like all models, enterprise architecture models should start out simple and imperfect, and improve over time as the organization learns. Begin by notionally sketching out the processes, technologies, and responsibilities using simple block diagrams. Then the EA&S team can add more detail once a conceptual understanding of, and consensus on, the desired state is achieved. As the EA&S team drills down, it will need to involve additional decision makers. The senior leadership is not going to make detailed design decisions, so approval teams for each discipline are needed to make the detailed decisions. The pace of the EA&S team should match the rate at which the organization can learn. If the EA&S team gets too far out ahead of the organization, the EA&S team will have to slow its pace to obtain consensus. Think of an EA&S effort as a marathon in which the EA&S team needs to stay just in front of the rest of the pack. If it gets too far out in front, it will burn itself out before the race is finished. The marathon is long and runs on a track, each lap representing an increasing level of detail. The challenge in this marathon is that the pack has a tendency to get bored and wander off. The EA&S team will need to keep them sufficiently motivated and on track.

Large organizations spend millions of dollars and thousands of hours of their top technologists’ time establishing standards and technology architectures. The goal of these efforts has typically been to reduce the future installed-base complexity. However, creating standards in a business strategy and enterprise architecture vacuum is a waste of time and money. More often than not, the time invested in standards development is wasted when the business decides it “needs” a particular application that adds complexity to the installed base.

Why Standardization Is a Business Decision

Consider one mid-sized manufacturer of electrical components that standardized its ERP and CRM systems on Oracle software. The firm spent hundreds of hours researching the options and driving the organization to consensus. All that time was wasted when it decided to implement Siebel in its call center. The call center management argued that the Siebel software was better suited to its needs. Later, the organization decided to integrate its call center software with its order management software, so that call center agents could provide customers with estimated ship dates. The TCO—which now included the considerable cost of integrating Oracle and Siebel compounded by the ongoing maintenance cost of two application platforms plus integration—more than offset any incremental value that Siebel offered in the first place.

by Jeff Kaplan, PRTM Management Consultants