Foreword

Once upon a time, a learned scientist, working in his laboratory, placed a beaker of liquid on a Bunsen burner. Picking up another beaker, he poured its contents into the first. As the temperature of the resulting mixture rose, its color started to change, and it suddenly effervesced, giving off the most wondrous aroma.

"Eureka!" the scientist shouted and ran from the lab to carry the good news to his superiors.

"We must go into production at once!" said the CEO. "We can sell two billion gallons this year alone!"

So a construction team was commissioned to build a two-hundred-foot-high Bunsen burner and a two-hundred-and-twenty-foot-high platform on which to place a half-million-gallon beaker, together with a five-hundred-foot crane to lift a second beaker into the air so that it could be poured into the first to mix the ingredients.

Well, no, that would be beyond absurd. An experiment in a lab is quite different from full-scale production. It is curious, then, that enterprise systems are sometimes built using the same architecture as one would use for an experiment. That, too, is beyond absurd. Enterprise systems are different from "dining room LAN" systems, but the difference lies in architecture, not design. Too often, however, architecture is confused with design. Architecture expresses the characteristics, structures, behavior, and relationships that are common across a family of things. Design expresses in detail how a specific member of a family will be built.

Architecture and design are always present. Much of the time, however, they are buried in the mind of the programmer. Now if all programmers were expert architect/designers, if all had long and fruitful experience with enterprise systems, if all enjoyed mind-meld with other programmers working on this and other related projects, and if no one after them ever had to maintain or build other enterprise systems, the invisibility of architecture and design would be irrelevant, and the world of IT would be quite different. But they aren't, they haven't, they don't, and they do.

Thus both architecture and design must be overt and separate. Architecture is produced by knowledgeable professionals who communicate, inspire, and lead. Design alone is not enough. Design of an enterprise system must be appropriate to the extrafunctional requirements of such systems scalability, integratability, flexibility, buildability, and so on which are specified by architecture.

One important reason enterprise systems often fail is that architecture and design are conflated. Other human endeavors are just as complex as enterprise systems, and yet they don't demonstrate anything close to the failure rate of large IT projects. Why is this? My answer is that the significant deficiencies within the IT industry currently occur in three major areas:

  • Architecture at the enterprise level (enterprise architecture)

  • Tools to support enterprise architecture

  • Organization to support enterprise architecture



Practical Guide to Enterprise Architecture, A
A Practical Guide to Enterprise Architecture
ISBN: 0131412752
EAN: 2147483647
Year: 2005
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net