The enterprise transformation theme of The Open Group’s recent San Francisco conference reminded me of the common assertion that architecture is about change, and the implication that enterprise architecture is thus about enterprise transformation.

We have to be careful that we don’t make change an end in itself. We have to remember that change is a means to the end of getting something we want that is different from what we have. In the enterprise context, that something has been labeled in different ways. One is “alignment,” specifically “business/IT alignment.” Some have concluded that alignment isn’t quite the right idea, and it’s really “integration” we are pursuing. Others have suggested that “coherency” is a better characterization of what we want.

I think all of these are still just means to an end, and that end is fitness for purpose. The pragmatist in me says I don’t really care if all the parts of a system are “aligned” or “integrated” or “coherent,” as long as that system is fit for purpose, i.e., does what it’s supposed to do. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

I’m sure some will argue that alignment and integration and coherency ensure that a system is “optimal” or “efficient,” but doing the wrong thing optimally or efficiently isn’t what we want systems to do. It’s easy to imagine a system that is aligned, integrated and coherent but still not fit for purpose, and it’s just as easy to imagine a system that is not aligned, not integrated and not coherent but that is fit for purpose.

Of course, we can insist that alignment, integration and coherency be with respect to a system’s purpose, but if that’s the case, why don’t we say so directly? Why use words that strongly suggest internal properties of the system, rather than its relationship to an external purpose?

Value is in implementation
Whatever we call it, continuous pursuit of something is ultimately the continuous failure to achieve it. It isn’t the chase that matters, it’s the catch. While I am sympathetic to the idea that there is intrinsic value in “doing architecture,” the real value is in the resulting architecture and its implementation. Until we actually implement the architecture, we can only answer the question, “Are we there yet?” with, “No, not yet.”

Let me be clear that I’m not arguing, or even assuming, that things don’t change and we don’t need to cope with change. Of course they do, and of course we do. But we should take a cue from rock climbers—the ones who don’t fall generally follow the principle “only move one limb at a time, from a secure position.”

What stakeholders mean by fitness for purpose must be periodically revisited and revised. It’s fashionable to say “Enterprise architecture is a journey, not a destination,” and this is reflected in definitions of enterprise architecture that refer to it as a “continuous process.” However, the fact is that journey has to pass through specific waypoints. There may be no final destination, but there is always a next destination.

Finally, we should not forget that while the pursuit of fitness for purpose may require that some things change; it may also require that some things not change. We risk losing this insight if we conclude that the primary purpose of architecture is to enable change. The primary purpose of architecture is to ensure fitness for purpose.

For a fuller treatment of the connection between architecture and fitness for purpose, see my presentations to The Open Group Conferences in Boston, July 2010, “What ‘Architecture’ in ‘Enterprise Architecture’ Ought to Mean,” and Amsterdam, October 2010, “Deriving Execution from Strategy: Architecture and the Enterprise.” Please note that you need your Open Group site password to download these files.

This guest post comes courtesy of Leonard Fehskens, Vice President of Skills and Capabilities at The Open Group.