Measuring Success in Enterprise Architecture Projects

by Hamza Jahangir

Published February 2011

Part of the Oracle Experiences in Enterprise Architecture article series.

To measure the value of EA initiatives, you must look for tangible, concrete business benefits from every decision you make. Even if you are simply deciding what kind of server to buy or how much storage capacity you need, the solution you implement should enforce metrics such as the expected cost of managing a gigabyte of data in your enterprise. Enterprise architects connect each decision to a specific outcome and a measurable business impact.

IT metrics such as the cost of servers and storage devices can also be rolled up into business metrics. For example, a healthcare company might want to know the cost of managing a patient record. If patient records reside in five different databases, how much would you save by consolidating them? In addition to computing your specific internal costs, it's helpful to have something to benchmark against, such as the cost of these same activities among your competitors. Is your average cost of managing patient data higher than usual for your industry? Get the facts. To cite another example, a telco might be guided by metrics such as the cost of provisioning a new customer or troubleshooting a service outage. You can make better IT decisions if you have an industry metric for gauging your performance when you attempt to answer these types of operational questions.

Case in Point

BT, formerly known as British Telecom, is a case in point. This 100+ year-old global corporation operates in over 170 countries worldwide, and employs more than 100,000 people. BT's Group arm handles the procurement of all BT goods and services, managing more than 10,000 properties and 50,000 vehicles.

BT's problem was information diversity. The BT Property systems estate had grown organically through first- and second-generation web applications to a total of 46 systems utilizing a wide variety of application and database technologies. BT decided to rationalize their systems by putting together an enterprise architecture framework and standardizing their application development processes.

BT Procurement worked with BT Enterprise IT to develop a strategy for systems rationalization, service orientation, and agile delivery – with the goal of delivering a radically improved but lower cost service to the customer. Mike Blackmore, enterprise architect at BT, worked with the CIO to define a future state based on one unified application platform for the entire corporation, dubbed UniApp. According to Blackmore, the new architecture has been designed to "break BT away from the dictates of IT fashion, to exploit BT's wider software investments and become a foundation for reducing IT spend."

BT used the Oracle Enterprise Architecture Framework and the Oracle Architecture Development Process (OADP) to provide a decision-making framework. Along with Oracle Fusion Middleware development, these EA assets give BT a mechanism to make fast decisions that align with management's central vision and direction. Today the UniApp architecture gives BT a more standard, resilient, and scalable platform from which to deliver IT services to the wider business.

One lesson BT learned is that rapid and extreme programming techniques can sometimes expedite the process of failure if they are not properly governed by a common vision and a well though-out decision-making framework. The point of using OEAF and OADP, says Blackmore, is not to get in the way of agile development, but "steer it in a way that maximizes the value of IT to the business." (For more on BT's UniApp architecture, see Building Agile Applications using Fusion Development and Oracle Enterprise Architecture Principles.)

Aligning Technology with Business Goals

Ultimately companies such as BT want to learn how to measure the impact of EA on organizational competitiveness, revenue growth, operational excellence, strategic agility, governance and compliance. The Oracle EA framework helps them "connect the dots" between business decisions and technology infrastructure decisions, enforcing corporate objectives.

For example, if management wants to acquire a company, IT needs to plan for the impact on corporate operations. By drilling down to discern the impact of a potential merger, they can step back and align their IT strategy to the new business plan. For example, if the company plans to integrate a new sales force, then what are the key systems and processes that IT will have to put in place, such as quoting, forecasting, lead generation and pipeline management?

Enterprise architects have to figure out how all this will impact the operation so they can align their development and integration activities with management's goals and strategies. Once they have identified the correct sales processes, they can take it to the next level: what are the applications and ERP systems that will support those capabilities? Do they need a unified data hub for all sales data? Do they want a standardized data model and information architecture so they don't spend too much time integrating disparate sources of data? What are the information elements that the sales team needs? What is required to support the back office?

In short, what are the technology ramifications? What are the data center ramifications? What are the back office and front office ramifications? Answering these questions helps you create the EA framework. Take the high-level management objectives and break them down into low-level implementation details that architects and engineers can follow day to day. These professionals then have specific directions, a roadmap to follow, and a framework to structure their progress. They can tell if they are on track and meeting management goals.

No matter who is looking at the framework – the CFO, CIO or the project architect - individuals should have specific views and perspectives that are relevant to their jobs. EA is all about achieving multi-dimensional alignment to synchronize the different roles, people and perspectives in the business.

Additional Enterprise Architecture resources:

About the Author

Hamza Jahangir is an Enterprise Architect with Oracle Corporation.