Meeting the need for enterprise-level thinking

• By Dan Romanchik
• May 1, 2004

Most enterprise-level project failures are not the result of choosing the wrong language, not having the right development tools or even having lousy programmers on the development team. The problem is that the architecture is not adequate enough to support the applications.

One reason this is so, according to the authors of “A Practical Guide to Enterprise Architecture,” is that architecture is not design and in many companies the two are often confused. Architecture and design are two separate endeavors, say the authors, and marrying them often leads to failure. In addition, there are some glaring deficiencies in our knowledge of enterprise architecture, as well as the tools and organizations meant to support the enterprise architecture effort.

The difference between architecture and design is that an enterprise architecture must not only take into account the hardware and software used to implement a computer system, but also the enterprise’s business goals and business processes. Designers will jump right in and begin working on a problem, be it an accounts payable system or a customer relationship management system. Architects, on the other hand, will take a step back and first ask questions such as, “How do we build this system so that it helps us reach our business goals”?

With that in mind, the authors proceed to lay out their philosophy of enterprise architecture. In developing their philosophy, they’ve adopted many of the ideas put forth by the Agile Alliance in their now famous “Manifesto for Agile Software Development.”

In fact, the authors call their approach to enterprise architecture Agile Architecture and list a set of principles for it. These include “Working software is the primary measure of progress” and “Businesspeople and developers must work together daily throughout the project.” The second principle, “Welcome changing requirements ... Agile processes harness change for the customer’s competitive advantage,” reflects the agile approach to ever-changing requirements.

One thing I like about this book is the way it talks about current topics in software development and how they relate to enterprise architecture. The chapter on software development methodologies, for example, examines five different methodologies: extreme programming, SEI/CMM, the Zachman framework, model-driven architecture and the Rational Unified Process (RUP). For each of the methodologies, the book not only describes the methodology, but also evaluates its plusses and minuses with respect to enterprise architecture.

If you’re concerned at all with enterprise architecture, you should consider buying this book. Even if you’re not an enterprise-level architect, nor aspire to be one, “A Practical Guide to Enterprise Architecture” will help you to understand the issues involved. And with any luck, that will lead to better architectures and, ultimately, better software.

“A Practical Guide to Enterprise Architecture” by James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, Elias K. Jo. ISBN 0-13-141275-2. Prentice Hall PTR, Indianapolis, Ind. 2004. $39.99