LinkedIn: Is it fair compare a Business Architect to a building architect?

<question group="Business Architecture Community">
Is it fair compare a Business Architect to a building architect?
Really, does it even make sense? I have been one that used the analogy, but is it a good analogy to use? Why is it that many of us use this one? I know both are hard, both document and are trying to create "blueprints", but...

There is very little science or agreed upon anything when it comes to business architecture. There is no standard certification that is respected by everyone. There is no set of common deliverables you ALWAYS do. There is no governance of business architecture from an industry standpoint. There is a lot of trial and error in business architecture.

This is a great contrast from a building architect. There is rigor and respect when it comes to licensing. There are standard deliverables. There is extreme rigor on governance - building inspectors, laws of physics, etc...

What are your thoughts?

</question>

At first, let’s back to basics to align our understanding.
In the civil architecture in each construction project there are three distinct roles: a client (an individual, or an organisation), a civil architect (a licensed individual who leads a team in the planning and design of buildings and participates in oversight of building construction) and a general contractor (a company which constructs buildings).

A client (maître d’ouvrage) contacts first a civil architect (maître d’œuvre) to communicate his/her "dream"; the latter presents to the client a solution (in some kind of a visual form, e.g. as a drawing or a scale model, because the aesthetic is often very important). After accepting the solution, the civil architect is empowered by the client to guarantee a good way of the construction. The civil architect selects a general contractor and the civil architect works with a foreman (contremaître) – an experienced professional who is in charge of with organising the overall construction including the construction crew.

The separation of duties between these roles is very important – a civil architect and a general contractor are different individuals or companies by obligation (at least in some countries). Such a separation guarantees the appropriate control and quality upon the results. Also, it is interesting to note that there is no an explicit project manager role per se – each role has to carry out some “project management” duties for itself. For example, a foreman is actually a project manager from the side of the general constructor (considering that he/she has come to the management position after experience as a construction worker, but not a professional project manager).

Just guessing the mapping of roles in your case. For example:
“client” = the whole organisation
“architect” = a business architect
“general contractor” = the whole IT department + many external consulting companies
“client’s dream” = merger, changing of unit’s structure, survival in heavy competition, cost cutting, modernisation of legacy applications, outsourcing the whole unit or just its IT environment, portfolio rationalization, etc.

Does it match your reality?

In any case, a business architect has to be armed with a coherent set of proven tools and practices which provides guidance and practical help for the effective transformation of an enterprise to achieve business vision and strategy (i.e. client’s dream).

Of course, a business architect has to work with many step-by-step improvements. We found that the most difficult is to deal with two streams of improvements – those for implementation of the “client’s dream” and those for improvement of the business system itself. The latter are also related to the “client’s dream”, but rather indirectly. Nevertheless, both streams are important, interdependent and to have be intermixed – in some sense a particular business system should be properly “trained” before realising great “client’s dream”.

So far, the most promising approach is a mixture of BPM+SOA as major tools and many supporting ones. (Like in the chess game – it is necessary to play with all chess mates together.) Artefacts, nomencltures, methods, patterns, recomendations etc. are available for this approach.

(Have a look at my talk this summer in Bangalore - http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf)

Thanks,
AS