Topic: General
On the recommendation of a colleague, I read a report from the Cutter Consortium entitled, "Are Agile Methods and Enterprise Architecture Compatible? Yes, with Effort," by Jim Watson, Kurt Guenther, and Mike Rosen. You can obtain a copy from the Cutter link in the preceding sentence.
I found it to be an excellent ananlysis. (Either that, or I just think it's excellent because I happen to agree with it.) The authors have done a great job of identifying the natural clashes and natural synergies between enterprise architecture (EA) and agile methods (AM), and their recommendations for reconciling them are spot on.
I can't help noticing, though, that none of the authors, none of the Cutter consultants who must have reviewed the piece prior to publication (including Scott Ambler, a respected thought leader in the agile world), nor Amr Elssamadisy in his InfoQ review of the report reached the conclusion that naturally follows from their findings - that it is time to move beyond the conventional IT organizational structure to which we have grown accustomed, and which we take for granted. It is that organizational structure that impedes IT's ability to deal with the issues EA and AM, respectively, address. It is often the case that function follows from structure. Create a structure that makes "right" behavior the course of least resistance, and "right" behavior will tend to occur without much strain. A different IT organizational structure would facilitate the solution the authors call the "reconciliation" of EA and AM.
The present-day notion of how to divide personnel in an enterprise dates back to a time when "tech-heads" neither knew nor cared anything at all about business, and business people neither knew nor cared anything at all about computers. Some were even fearful of the mysterious beasts. How the world has changed since then! Just as it ultimately became commonplace for people to own and operate automobiles without having any knowledge of automotive engineering, it has become commonplace for people to own and operate computers without having any knowledge of computer science. What business person today doesn't know the Three Finger Salute, and perform it daily? What business person today doesn't carry a phone that is, itself, a more sophisticated and capable computing device than the hulking business computers of old? And what "tech-head" is truly content to twiddle bits in isolation, without a care for whether his/her work brings anyone any value? Dumping all the technical personnel and computer-related activities into the same bucket no longer makes sense. Keeping those personnel isolated from their own customers never really made sense in the first place. It only came about because the two groups were uncomfortable walking around in each other's little worlds. Fortunately, things aren't that way anymore.
The mission, scope, tools, mentality, culture, and personality types of enterprise architects and agilists are so radically different that (in my view) they call for separate administrative subdivisions in the enterprise. Not only is the nature of their work different, but the management styles, employment incentives, and career path options that work with one group don't work with the other. The staid working conditions and deliberate pace of progress of enterprise architecture work would bore and frustrate an agilist. Conversely, the intensity and unpredictability of agile development would stress out the type of person who tends to prefer things standardized and repeatable. Furthermore, and perhaps more importantly, as long as application developers live in the IT department while the customers they serve live elsewhere, enterprises will not achieve the level of collaboration they need to enjoy the full potential of agile methods.
I would take the conclusions of the Cutter report to the next step - have agile teams report directly to (and belong to the same organizations as) their business customers, while enterprise architecture remains a function of the central IT department. Enterprise architecture and agile methods are not merely two areas of specialization within the same occupation; they are two different occupations. They are as different from one another as are the accountant and the attorney, the surgeon and the back-hoe operator, the short-order cook and the telephone lineman. It's interesting, and a bit amusing, that the Cutter article lays all this out so clearly, and stops short of stating this rather obvious conclusion.
