Architecture or Folly?

This week sees me down in Bangalore at the Architecture World 07 conference. The two concepts of BPM and Enterprise Architecture are to be very related, success in both owes a lot to maintain an important mantra "just enough!"

I always have fun speaking with groups of IT about Enterprise Architecture as invariably they do not mean Enterprise but IT when they use the term. So in my quest to get them thinking differently I thought I'd introduce them to the term folly.

I am sure many of you can recollect pictures or sights of buildings that seem to serve no purpose or remain unfinished. How about Howard Hughes plane, the Spruce Goose? I am sure that "architects" were employed on many of these projects.

So what is a folly?

The Oxford English Dictionary defines a folly as: "A popular name for any costly structure considered to have shown folly in the builder,"

While Chambers' Dictionary says it is: "A great useless structure, or one left unfinished, having been begun without a reckoning of the cost."

Hmm... sounds a lot like the description of many Enterprise Architecture projects I have come across in the past few years.

On a (slightly) more serious note with the advent of Service Oriented Architecture, the word Architecture has once again been given prominence. In fact for some it can be fun to count just how many Architectures you need in IT – Model Driven Architecture, Service Oriented Architecture, Client Server Architecture... and so the list goes on.

With each new architecture fad comes more talk of why the business don't get it and why people in the business don't recognize the value of architecture.

Of course the answer to that question is to my mind very simple. The explanation can also be given using the very analogies that are used to try and explain architecture, namely the examples of buildings and aircraft.

Buildings are built to last for many years, in some cases they can last for thousands of years, these days some only tens of years. For aircraft they are built for at least 20 years of service and to be maintained for often much longer than that.

So in these cases some degree of architecture is justified, but even then sometimes we are really looking only at rigorous design. However in both cases any "overhead" in design is spread over many years of useful and hopefully profitable service.

Now, when we come to IT business people are being asked to constantly reequip, systems lasting it seems no more than two to five years. Small wonder then, that it can be challenging to persuade us of the value of Architecture. Perhaps then it would be easier to just explain that what is really meant is good design, you would like to build our systems using good design principles.

I think perhaps the French had the right idea with the concept of City Planning as being the base point for Enterprise Architecture. The idea that as with a town, you need to lay out "zones" for different activities and to make sure that the equivalent of the basic infrastructure is in place and that systems use appropriate interfaces. This is providing a longer lasting value and is using architecture at an appropriate level and then letting designers do the design. Saves on the overhead of architecting the design – which has always sounded like a bit of an overhead to me.

So it will be interesting to see and talk with the architects and designers down here in India and find out how they will be using architecture to help create agile, customer centric organizations that deliver greater value for the stakeholders in the business.