Link IT Investments to Business Metrics
Enterprise architecture governance offers shorter development times, greater reuse of IT assets, and more modularity in IT infrastructure.
by Chris Curran

To the heads of various business units, the COO, and often the CEO, the introduction of enterprise architecture (EA) governance is a red flag. It’s a signal to them that the IT department is about to try enforcing a new set of standards that will slow them down and keep them from getting the applications they think they need to run their business profitably.

The IT department typically introduces EA governance in an attempt to set itself up as sheriff, coming in to restore law and order to an unruly environment of runaway projects, unrealistic expectations, and unbridled spending. Even if, intellectually, the company knows it needs discipline, it's not long before the IT sheriff is run out of town (or more likely, ignored) and the company returns to its disorderly ways.

EA governance offers advantages to the IT department in terms of shorter development times, greater reuse of IT assets, more modularity in IT infrastructure, and increased efficiency. Ultimately, it can free IT personnel to work on more strategic, interesting projects.

The challenge is getting the rest of the organization to go along. We've found that the most effective approach to EA governance is one that substitutes alignment for enforcement—one that rationalizes governance not just as the right thing to do but rather as a critical factor in reaching the company's P&L and other goals. This article outlines an approach to EA governance that is becoming widely accepted in a number of large organizations—linking IT investments to specific business metrics. The three critical elements are selling the idea, setting the right metrics, and establishing the right organizational roles and responsibilities.

Selling the Idea
Although the relationship between the IT department and the rest of the company is unique to each enterprise, experience shows some common pitfalls that CIOs and architects must avoid to gain broad acceptance of their governance plans. Here are the five things you should never tell management about EA governance:

1. "We are here to govern you." The fundamental goal of EA governance is to provide visibility of standards and other useful assets to project teams. This must be a collaborative exchange that adds value, not one that looks like a parent scolding a child (or a policing activity).
2. "All you have to do is give us your deliverables, and we will let you know if you pass or fail." The "grading" mentality is common as IT tries to exert more control over the lawless business units. First, the "answer key," or standards documents, must be clearly communicated to all delivery teams so there are no surprises. Second, the deliverable review process needs to happen iteratively so that there are no major changes required at the end of a major design or delivery phase that cause serious rework and delays.
3. "It’s our job to determine if your project proposal aligns with the business objectives." One of the primary goals of EA is to provide a framework for explicitly linking business goals and objectives to technology investments and their delivered components. However, businesses will not propose projects they think are misaligned. Their ideas are well-intentioned but might be misguided. The ultimate goal is to get architects embedded in the business-planning processes to bake in the right technology considerations at the right point in time. In the meantime, the EA experts can offer work sessions to assist the other parts of the business as they form their ideas and project proposals.
4. "It will take more time, but it’s worth it." Adding governance checkpoints and meetings into an organization that lacks standards and suffers from inconsistency problems will seem to many people like additional overhead and unnecessary work. In that environment, it's a death sentence to set the expectation that governance will add more time to a project. The entire solution delivery lifecycle must be looked at in terms of the processes that are being improved, not just within the contexts of individuals. As an industry, we can increase productivity and quality by giving IT staff the tools to increase their engineering skills (standards, repeatable processes, tools) and reduce—not eliminate—the demand for them to act as artisans. Effective EA governance can greatly reduce development time by limiting redesign and rework in later stages of the delivery process. Compliance will improve once you can demonstrate that speed of delivery will increase by addressing architecture issues at points where they can most efficiently be addressed.
5. "Architects in our EA group will make the final decision in the event of disagreements." Medium-sized and large organizations often segment their architecture expertise into two camps: a relatively small enterprise group tasked with standards setting, blueprinting, and governance; and larger groups of architects, in a pool or deployed with project teams, that are tasked with applying the standards and blueprints to help solve business problems. The "project architects" can go a long way toward improving the communication and application of EA in the greater IT context and with business sponsors, so you don't want to alienate them. It's important to set up EA governance that allows the project architects to be major parts of the decision-making processes, not just deputies sent out to enforce the law.

Setting the Right Metrics
Many of us have tried to come up with the silver bullet for justifying EA. Some have deemed it a cost-cutting tool. Others have said it's a predictive model used to forecast the amount of change a particular business initiative will impart (particularly effective in organizations heavy into mergers and acquisitions, by the way). In both of these cases, and others, EA is positioned as the lynchpin between business requirements and their technology solutions. If we could somehow measure EA's effectiveness in business terms, we could at least have a common, fact-based language to discuss EA's impact (good and bad) with the business.

You need at least three kinds of metrics to begin establishing a linkage from the business needs and the implementation of them as guided by EA (see Table 1).

Each of the metric types supports the others. The EA governance metrics help management see if the processes are working. EA adoption (as measured by EA compliance metrics) is facilitated by effective governance (as measured by EA governance metrics). Finally, cost-effective delivery of business capabilities is supported by the other two.

The common characteristics in all these examples—in other words, how you know when you’ve got good metrics—are that they are measurable, you know where you can get the data from, and there is a common understanding as to the targets for each metric.

Organizational Roles and Responsibilities
The case of a major insurance carrier provides a prime example of successful EA governance. The EA governance organization is responsible for conducting reviews with selected projects and assessing their compliance with published enterprise standards and blueprints. Reviewed projects go through a disciplined checkpointing process before receiving EA approval. In addition, the EA governance organization has established management processes for such activities as logistics, issues management, architecture exception management, and follow-up. The organization also coordinates the updating of blueprints and standards to ensure that they are current and effective, and communicates directly with all relevant parties within the organization.

The EA governance organization is composed of a core governance team, subject matter experts, and a program manager. Each has specific responsibilities and roles (see Table 2).

Experience shows that successful EA governance can encompass each project's lifecycle from conception through deployment and be effectively coordinated with architecture reference materials. But within each enterprise it is the responsibility of the EA governance organization to define its future state and chart a course to get there. The EA team can't do it alone. Selling the idea of EA governance in terms that resonate with senior management and other non-IT executives is a crucial first step. Defining the right metrics is essential in demonstrating the value that EA governance delivers. Finally, having the right governance team in place, both at the enterprise level and as stakeholders in the success of specific business units or functions, can promote an environment where EA governance is viewed as a means of alignment, not the burden of arbitrary enforcement.

About the Author
Chris Curran is the Chief Technology Officer of DiamondCluster International. He is responsible for ensuring that the global management consulting firm maintains a thorough understanding of technology and architecture and the impact they can have on clients' success.