Book Review: A Practical Guide to Enterprise Architecture

Authors: James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, Elias K. Lo; forward by Oliver Sims

I say—all the time—that this blog is not written for the readers, it’s written for my own benefit. (I just like writing—if nobody reads it, it’s no skin off my back.) This post is further proof, since it’s a book review for a book that I’m sure none of my regular readers will ever want to read. (Although, if you do, let me know, and I’ll lend it to you.)

This book was recommended to me by a colleague, who is looking into these issues just as I am. He liked this book because of its practicality, and because it touched on so many areas of enterprise architecture. Unfortunately, it didn’t live up to my expectations. Now, as an author of a technical book myself—and, therefore, having undergone the technical editing process, which can be a nightmare—I want to try to be careful with this review; not just slam the book and try and make myself seem like I know more than these people, but only give valid criticisms. In fact, I don’t know more than these people, because they’ve all been in the industry longer than I have. (Probably; not all of them listed their years of experience, in the About the Authors section.) But that’s how I try and do all of my reviews, so it shouldn’t really be anything new.

Before I get to the negatives, let’s start out with a positive. The first thing I read in this book—as I am wont to do—was the foreword. I’m reproducing most of it here, in a blatant disregard for copyright laws; although I was disappointed by the bulk of the book, this was at least a good place to start:

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 out its contents into the first. As the temperature of the resulting mixture rose, its color started to change, and it suddenly effervessed, 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 the 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

….[Good material on these three points elided]….

Why This Book Is Important

Today, the encouraging coalescence of opinion among leaders in enterprise architecture is that many enterprise systems have the same architectural approach—although not all express it in this way. A similar convergence addresses the kinds of techniques, patterns, and designs that are independent of specific application domains and that enable effective production of responsive, scalable, flexible, and unifiable enterprise applications. This book is important because in many ways it epitomizes that convergence. It addresses the whole range of knowledge required for successful enterprise systems and pulls together many strands, from the essential data foundation (the part of a system that persists when the machine is turned off) through run-time software design, architectural separation of concerns, and scalability patterns, to the much-neglected area of user interface. Of equal importance, it addresses not only what should be built but also how, from tools and modeling, to agile development, and it includes the important question of human organization.

Moreover, what shines through the book is the sheer hardheaded practicality and competence of the authors—based on years of experience. This work contains much of the knowledge—or pointers to knowledge—that a budding enterprise architect needs, expressed in readable, relevant, and nondidactic presentation. It is also an ideal textbook—a foundation work—for a graduate course in enterprise architecture. In fact, I suspect it could well become an important part of the institutional knowledge about enterprise systems within our fascinating and vibrant industry.

When I read this, I was very encouraged. I may have been disappointed as the book went on, but at least it started good.

A good thing that this book had going for it was the table of contents. When I looked through all of the topics covered, I was looking forward to reading pretty much every chapter; there were some architectural areas that I don’t get involved in very often, and I was looking forward to getting some advice from people who know more about it than I do.

Overall, probably the thing I liked best about the book is the authors’ focus on “agile” techniques. In some ways, these agile techniques are improvements on existing techniques, and in other ways, they amount to throwing out existing ideas that don’t work, and replacing them with ideas that do. For example, instead of trying to produce copious documentation, that covers every aspect of the system, before you even begin—the current mind-set in much of the industry, which, in the worst case, leads to “analysis paralysis”, and in the best case is simply wasted time—agile techniques would say that you should only document what you need to document, and leave the rest undocumented.

I guess the first thing I could mention which wasn’t done well is the focus on the intended audience. They seemed to wander too much. As I mentioned, I worked on a technical book, called Beginning XML, originally published by Wrox Press (which has now been taken over by Wiley). By most accounts, the book did very well in its space (narrow as that space may be); my publisher recently told me that it is consistently the #1 or #2 best-selling XML book, according to the broadest sales data available. Is this because I and my fellow authors on the book are good writers? That might indeed have something to do with it, but I don’t think it’s the answer. I think a more important reason is that the publisher(s) pushed us to keep the audience in mind. When we were writing, we always tried to remember who we were writing for; that includes the structure of the book (what was included and what wasn’t), as well as the writing style. A Practical Guide to Enterprise Architecture didn’t seem to have that focus. It was unclear, at times, who the book was aimed at. At times, it seemed to be aimed at me (a budding architect), at other times at CIOs, and at other times I just wasn’t sure. I don’t know whether to blame the authors, for this, or the editors, since the editors on my book were very helpful in reminding me to stay on track.

Which brings me to my next point, for which I do not blame the authors at all: The book was not edited well. There were grammatical errors from time to time—the type of thing I can get away with on a blog, but on a book which has editors, should really get caught before publication. There was even an instance where they had something like “see Figure A for the before picture, and Figure B for the after picture”, but they were both the same picture. As a writer, working under a deadline, it’s easy to make these kinds of mistakes. The editors were clearly asleep at the switch.

The final thing I didn’t like about the book—or, at least, the final thing that I’ll mention—is that I’m suspicious of the authors’ reasons for writing this book. The more I got into it, the more it started to seem like it was more of an act of hubris, rather than a genuine belief that the book is needed in the marketplace. In other words, it felt like the authors are just proud of themselves, and wanted to write a book to prove how smart they are. They spent a lot of time writing about the fact that more experienced IT people will have more knowledge than others, which, as I’m sure we all know from experience—since this applies to pretty much any profession—is not always true. I’ve known a lot of senior architectural-type people who are really not earning their paycheques. When I get on a project with these people, they are usually not able to function properly without someone like me there to help them along.

I’ll end the review on a positive note, though, because there really were some good aspects to this book. I’ll quote another section I liked, from a chapter called Thought Leadership—a chapter which the authors just wrote because they felt like writing it, rather than because it was necessary to the book. This section was called The Savage Pursuit of Best Practices:

Many architects are pummelled by management (not leaders) with the idea that an organization should create initiatives that focus on the capture of best practices so others can benefit from them later. The mind-set that supports archiving these practices facilitates efficient problem solving, which leads over time to the way business should be conducted.

Of course, this goes against many agile approaches and is, in many ways, diametrically opposed to the agile manifesto of preferring interactions to comprehensive documentation. Solutions to business challenges are typically containerized by memorization of various “measures of goodness” (Booch) that also have embedded assumptions, nonpublic views of organizational strategy, and unwritten reward systems (e.g., what do I need to do to make my boss believe I am competent). The sad fact of many enterprises is that this mind-set breeds doing more of the same better, which only provides marginal returns that diminish over time.

For example, a frog is unable to detect gradual changes in temperature. A frog that is put into boiling water quickly has instincts that will tell it to jump out, but when it is put into room temperature water that is slowly brought to a boil (the vast majority of significant projects fall into this category), the frog will ultimately boil to death. The mantra of doing more of the same will result in locking in both desired and undesired behaviors that result in a death march. In other words, more of the same doesn’t help. The status quo mind-set must be abolished.

This mind-set is further compromised by the notion that knowledge can be stored by using information technology. We are aware that databases and groupware applications can store information that is structured and unstructured, but in the end that amounts simply to storing bits of data. Neither solution today can store the rich schemas that people possess for making sense of those bits. One fundamental truth exists that is often ignored: the simple fact that information is context-sensitive. The same data will elicit different responses from different people. When someone invents the technology that can scan a person’s mind and store it directly in a database, people will be able to experience the reality of another person. Since that isn’t possible, it is important to focus on interaction.

This does not mean that we are not for knowledge management or best practices. Rather, we think that they are useful tools for creating a consensus-driven view of the business problem. However, it must be acknowledged up front that this information is static, rational, and without context, but our business problems are anything but static, border on the line of insane, and definitely have context. These tools do not truly help with what is important, which is the ability to renew existing knowledge and assist in the creation of new knowledge.

The best practice that is never spoken about is the one that allows a culture to be unlearned. What is “best” today may be “garbage” tomorrow.

(I should mention, by the way, that just because I quoted two big sections from the book, it doesn’t mean these were the only good sections. They’re just the ones that I bothered to type out.)

I agree with whichever author wrote this section. In my profession, we get hounded all the time to record our best practices, and create “lessons learned” documents, and keep all of our documentation in repositories, but when push comes to shove, and someone needs information about a system, they don’t look in the repositories. They get on the phone, and call a person. (And if that person doesn’t work for the company anymore, then they’ll talk to someone the person worked with.) I do agree that capturing best practices is a good idea, and I have nothing against “knowledgebases” or repositories, but people—read: managers—need to understand what they’re good for, and what they’re not.

So, all in all, I was disappointed with the book. But I’ll probably end up reading it again, some day, or reading bits and pieces of it, when I want to work with a particular area of architecture that I don’t normally deal with. (Or I might re-read the section on Extreme Programming (XP), if I’m going to work on a project that will use it, for example.)