FlipSide: A case for EA
A case for EA
- By Florence Olsen
- Aug 27, 2007
No agency wants to be without an enterprise architecture, according to a recent book on the topic whose authors focus on its strategic benefits.
“Enterprise Architecture as Strategy” avoids much of the mind-numbing detail associated with books on enterprise architecture. It focuses instead on the importance of good leadership in achieving the benefits of enterprise architecture.
Published last year by Harvard Business School Press, the book is based on research from the Massachusetts Institute of Technology’s Sloan School Center for Information Systems.
Its authors, Jeanne Ross, Peter Weill and David Robertson, acknowledge the contributions of Con Kenney, the Federal Aviation Administration’s enterprise architect, among others.
The authors identify nine signs that indicate an agency or business is having trouble adhering to an enterprise architecture or establishing one in the first place:
- A single question from the public elicits multiple and conflicting answers.
- Compliance with a new policy or reporting requirement requires a major effort.
- New capabilities take a long time to develop.
- The information technology shop is consistently a bottleneck.
- The use of various processes and systems to perform the same function is common.
- Information necessary for making decisions is not available.
- Employees spend their time moving data from one system to another.
- Senior executives dread discussing IT issues.
- Senior executives don’t know whether the agency gets good value from IT.
According to the book, the way to avoid experiencing those signs of poor strategic management is to make hard choices in establishing an enterprise architecture — and then stick to that architecture.
It’s a matter of putting a stake in the ground and building there.
The book recommends that agencies avoid enterprise architecture plans that look like circuit diagrams. Instead, an enterprise architecture plan should be a simple, one-page diagram that depicts the agencywide mission capabilities deemed desirable, the basic automation technologies and data standards necessary to achieve those capabilities, and the agency’s primary interfaces to the public or other agencies.
A one-page diagram requires leaders to formulate a simplified vision of a complex organization, and that’s difficult to do, according to the book.
Ross, Weill and Robertson wrote that the two most important aspects of an enterprise architecture are standardized and integrated business processes. Agencies can have as their goal standardized or integrated processes — or both — and they can choose to implement each to varying degrees.
The authors identify four stages of enterprise architecture maturity, and they recommend management practices appropriate to each stage. They also discuss the various skills that chief information officers should have at each stage.
Ross, Weill and Robertson argue that the most difficult growth phase of enterprise architecture occurs at Stage 3, when different parts of an agency or government try to integrate their data by adopting standard definitions and formats. “These can be difficult, time-consuming decisions,” the authors wrote. But the benefits are worth it: better customer service, better data for management decisions, easier data exchanges and speedier transactions.
The book defines enterprise architecture in a way that’s easy to comprehend. It states that an enterprise architecture plan should show the business processes and IT infrastructure necessary to support an organization’s requirements for standardization, integration and innovation.
The plan, the authors wrote, should be simple and to the point.