email article
	printer friendly
	more resources

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.