BETA
This is a BETA experience. You may opt-out by clicking here

More From Forbes

Edit Story

Enterprise Architecture: Moving From Chaos To Business Value

This article is more than 10 years old.

In a previous column, “How Enterprise Architecture Raises IT's Game”, I promised to delve deeper into my thesis that companies could use enterprise architecture to move from what Len Fehskens of The Open Group called Level 1 of IT to Levels 2 and 3. In Level 1, where most IT departments are stuck today, the IT staff is engaged in a struggle to make everything work. In Level 2, the IT department attempts to do the right thing for the business. In Level 3, the process of doing the right thing is optimized.

The question for today is how in concrete terms can enterprise architecture help achieve this transition. For those outside the world of IT it is worth explaining what enterprise architecture is and how it works well and how it can fail. To help figure all of this out I spoke again with Len Fehskens, who was joined by Chris Forde and Andrew Josey of The Open Group, a consortium of IT users and suppliers that develops standards facilitating Boundaryless Information Flow™. The Open Group is best known for TOGAF®, an enterprise architecture standard.

Enterprise architecture at its best is an effort to understand the strategic intent of a business and then have everything from business processes, to supporting technology, to partner relationships, to infrastructure of all sorts, to hiring and training, and anything else important work in alignment to achieve better business performance. Some observers, fed up with practitioners who emphasize methodology for its own sake, have made declarations that enterprise architecture is dead. There are many enterprise architecture methods out there, and all of them have been deployed ineptly at one time or another. But this failure is not inevitable by any means. After all, the reason that counterfeit money exists is because the real stuff has value.

Any organization of even modest size has an enterprise architecture. In the worst case, the enterprise architecture is an accident. Thinking about how to make everything work together just never happens.

Most companies have done some thinking about their strategy, the principles that they use to organize their business, the definition of processes, the applications that help execute processes, and the other infrastructure and technology that supports it. Because much of this thinking is done informally, it is hard to answer questions about the completeness of the analysis. Did you do enough? Did you do too little? How is it written down? How is the understanding of the business expanded and propagated?

What enterprise architecture of all kinds provides is a framework to make sure that you have covered all the bases and can steadily expand your analysis to include more and more issues and concerns.

Chris Forde, Vice President, Enterprise Architecture and Membership Capabilities at The Open Group, compares this to a medical doctor performing a diagnosis. “An enterprise architect a doctor who is helping an organization recover,” said Forde. “Like a doctor, you are going to look at the most important symptoms and focus on them. Then as they are addressed, other problems become more urgent.”

Enterprise architecture is meant to be incremental. Len Fehskens says that it should be approached like a jigsaw puzzle. First you find the corner pieces, then all the pieces on the borders, then you focus on one part of the puzzle and fill that all in. Start by doing projects that deliver real business value immediately, but at the same time lay the foundation for a long term architecture. and follow up by doing projects that also deliver value in the short term while building on and extending that foundation.

Methodologies for enterprise architecture provide a playbook for performing research and analysis in an orderly fashion. The members of The Open Group use TOGAF but they also contribute decades of man years of work back to the project. Like the other leading enterprise architecture frameworks, the TOGAF Architecture Development Method (ADM) has phases that fit into a cycle that can be executed over and over again. For the TOGAF ADM, the phases are: Preliminary Planning, Architecture Vision, Business Architecture, Information Systems Architecture, Technology Architecture, Opportunities and Solutions, Migration Planning, Implementation Governance, Architecture Change Management. Each of these phases draws on Requirements Management practices. The description of the TOGAF ADM runs to 150 pages, with TOGAF containing another 600 pages of further guidance and resources for enterprise architecture development including a Content Metamodel, Reference Models and a Capability Framework. In total there are 750 pages. The “pocket guide” summarizes this material in 150 pages.

So, how does performing all this work get you to Level 2? What happens is a simple process of expanding awareness. Most application development projects have some sort of architecture that explains who will use the system, what it will do, and how it will provide benefits. Enterprise architecture allows that thinking to be applied to groups of applications, to collections of departments, and eventually to the company as a whole.

During this process you start entering Level 2 because you understand the role that each business unit plays and the way that each technology component plays a supporting role. As this understanding grows, the important systems and the functions they perform become more obvious, as do the systems that are heading toward obsolescence. It becomes possible to prune the IT portfolio. Investment can flow toward the areas that will have the most impact, not the areas that reflect fashions or political power. Ideally, the systems are created so that they are under the control of the end-user, so that IT becomes less of a bottleneck.

The largest value of a living enterprise architecture comes from being able to quickly navigate the world of new technology. If you understand your technology needs, you can comfortably say “no” to a lot of new ideas that just don’t make sense for your company. This saves enormous amounts of time. Instead, you can find that small subset of technology that will make a huge difference and focus on making the most of that.

The danger in all this is that the process gets lost somewhere in the full 750 pages and stops being about diagnosing the state of the business and instead becomes an abstract exercise in methodology. This is what critics refer to when they declare enterprise architecture dead.

Only a small number of companies move from Level 2, in which they have focused their technology on the optimal way to support the business, to Level 3, in which they optimize this support. Making that transformation is a luxury problem. The more difficult challenge is the one we will address in the next article that examines barriers to creating a living enterprise architecture.

Dan Woods is chief technology officer and editor of CITO Research, a firm focused on the needs of CTOs and CIOs. He consults for many of the companies he writes about. For more stories about how CIOs and CTOs can grow visit CITOResearch.com.