Enterprise Architecture (EA) means different things to different people. Every organization has heard of it. Many mid-to-large organizations have a department for it. On average, depending on the size of the Information Technology (IT) department, these EA departments consist of three to fifteen enterprise architects.

When EA departments first started, they presented a wide range of business cases to Chief Information Officers (CIOs). These cases covered everything from an EA that provides cheaper, better and more flexible system integration to an EA that increases shareholder value and EPS. In the real world, though, the CIOs that I know seldom see positive results emerge from these promises. Thus, the biggest challenge for an Enterprise Architecture department is proving its value to the IT department.

How does one go about proving the value of Enterprise Architecture? Let’s review the promises to see what needs to be done differently.

Better Technology Environment
Enterprise architects know that they can design systems consistently and plan better technology environments for the company. The problem with this promise is that most technology selections are not made because one technology is better than another. Technology decisions are made for two reasons: (1) People know people, and every IT exec already knows a few technology vendors; and (2) A lower-grade technology may fit within the already existing technology environment better than the best of the breed technology in the same category. Just as car consumers want more of a selection than Henry Ford’s Model T, having only one solution won’t fly in Enterprise Architecture, even if it’s the best. An EA department that understands these dynamics can start creating value by demonstrating different sides of a cube, laying down multiple options with supporting details, and educating the decision makers.

Flexibility to Change with Business
Another promise I’ve seen is that enterprise architects believe they can provide flexible systems to accommodate changes to the business processes. This is well and good if the flexibility of a system design worked like an on-off switch. First, it’s never that simple to have either an “all” flexible design or a “no” flexible design. Second, enterprise architects, being from IT, are not experts on business processes found within other business units. Once, the VP of a business unit asked me bluntly, “Do you know the business process within your own IT?” His point was well taken. We try to fix everyone’s world claiming we have a magic wand, but we don’t know what is happening in our own home. An EA department can start creating flexible designs by experimenting with its own systems. How about looking at the trouble ticket system? Or optimizing their change management system? Maybe even tackling the Enterprise Application Integration (EAI) environment? I am not discouraging architects from going into other business units, but I am encouraging them to get some experience before venturing out into other groups.

TCO & Footprint Reduction
EA departments often made another promise: Reducing the technology footprint and lowering the Total Cost of Ownership (TCO). Both of these tasks require extensive research, lots of data points, and support from almost the entire IT staff. Why? Let’s start with the TCO of a single system. The first challenge is that architects need to know the salaries (or bill rates) of all the people who support that system to understand the costs behind owning and supporting the system. Next they need to know how many other systems each person supports and obtain the percentage of time for each system they support. Some IT execs who own this budget won’t give it to architects in an Excel sheet simply because they need to protect their budgets. Even if we solved this part of the equation, architects still need to know the cost of the system’s original implementation. Good luck going through an accounting journal.

Let’s get to technology footprint reduction. Architects need to know the existing footprint to even begin reducing it. Then they need to plan how much to reduce. They have to start measuring the amount that they reduced, month after month, to prove that they have been successful at reducing the footprint. Many architects walk into these landmines and quickly abandon the trip, that is if they didn’t already get blown off by management. I’ve seen some smart technologists (or accountants in their past life) use a few techniques that raised my eyebrows. So, how to create value from this promise? Un-promise it. Work towards understanding the footprint. See if providing such transparency (commonly known as “as-is” or “current state”) can provide value to the IT Operations teams. And, I suggest not using the word TCO until the architects figure out how to measure it within their organization.

Standards & Roadmaps
On to the promise of defining the future: Architects like to say that they create technology standards and technology roadmaps. This promise is not as tricky as the TCO promise or the footprint reduction promise, but it does need some work. First, I wouldn’t suggest establishing technology standards without knowing the as-is (“current state”). For example, if the as-is environment at an organization has a bunch of DB2 and SQL Server databases, the architects should think twice before proposing the Oracle database as a standard. Irrespective of how cool it is, Oracle may not be a good fit for the culture and financials of that organization. On the other hand, technology roadmaps require the architects to have relationships with other parts of IT to gather input from them. I would like to go a step further and say that technology roadmaps should be owned by the people who support the respective technologies while architects act only as the facilitators and researchers. When the necessary teams are involved, the classic notion that “Enterprise architects live in an ivory tower” will quickly vanish and positive perceptions will be established.

Technology Governance
Finally, let’s look at the promise of Technology Governance. Architects often would like to act as a police for the technologies that come and go from IT. I agree that someone needs to watch this activity, but it requires building relationships before someone will allow architects to act as the police. It is much easier to govern technologies when architects position themselves as the go-to guys on technology aspects. If and when the EA department exhibits strong technical knowledge, technology governance can become a service that the rest of IT seeks instead of having the EA demand to be the technology police.

To conclude, there are ways Enterprise Architecture can become valuable to an IT organization. EA is a very necessary and highly desirable function for getting things organized and keeping the sanity across IT. Companies that have walked the talk understand that EA is not an isolated function. Successful Enterprise Architecture is a well integrated function within IT, and enterprise architects are well connected across IT.

Nagesh V. Anupindi, Ph.D. is an expert in Enterprise Architecture and IT Strategy and helps turn around EA organizations that aspire to find their sweet spot. Nagesh is currently serving as the Chief Architect for Smart Grid CityTM at Xcel Energy. He graduated from the Univ. of Rhode Island and the Indian Institute of Technology. His comments and opinions are his own and do not represent those of his current or past employers. Email: nagesh@nagesh.com; Website: www.Nagesh.com; Blog: myITstrategy.blogspot.com.