Tuesday, February 24, 2009

Architecture or Firefighting?

For many organizations, the main worry today is Business Survival.

ZDNet blogger Ian Finley reckons "companies will need architects when the crisis is over, but today, they need fire fighters". (When the building’s on fire, who calls an architect?)

In response, fellow ZDNet blogger Joe McKendrick said that "the problem is we don’t have enough architecture as it is, and even when times are good, we’re always firefighting". (SOA 2009: Do we need architects or firefighters?) Mike Kavis agrees: "The reason there are so many fires is that there is so little architecture!"

Comparing the IT crisis with the financial crisis, my colleague David Sprott talks about a toxic mess of IT assets that can’t be easily cleared up. As he says, "although we may be cancelling projects and reducing activity, unless we get smart on architecture we are increasing the toxic mess". J.P. Morganthal uses another name for this concept - technology debt.

As far as I can tell from Joe's later post, Ian and Joe have found a middle point of agreement: focus-focus-focus on the essentials. (2009: a year of extreme focus)

These are not the only voices arguing that Little SOA is more practical/pragmatic than Big SOA. See for example Jordan Braunstein.

At the bottom of these debates is an important cultural clash. Some organizations have always been strongly focused on delivery - following the JFDI management style. In other organizations, the emphasis has often been on careful planning and inclusive consensus-building.

There are problems with both extremes. As a consultant, I once had the experience of working with two organizations at the opposite ends of this spectrum at the same time - trying to get the first organization to slow down and the second organization to speed up. (As a result of this experience, I came up with a novel approach to working with organizational culture, based on the five elements of ancient Chinese thought. Remind me to tell you about it sometime.)

In many organizations, there are strong cultural divisions within IT - developers versus architects versus project managers. (In previous posts I have used the metaphor of planets: Mars, Venus, Saturn, or Uranus, while of course Enterprise Architects are from Pluto.) The current climate maybe seems to favour the project managers and the developers over the architects. But that doesn't mean that the architects should abandon their principles and expertise, and pretend to be project managers or developers. As if that's what anyone needs.

What architects do need to do is find a new way of engaging with the business and the rest of IT, in a way that achieves a better balance between the different cultures. (If I can find the presentation, it's probably on a floppy disk somewhere, I'll stick it onto my Slideshare account. Update: Elements of Change)

No comments: