Inappropriately comparing Building Architecture and Software Architecture

Mike Walker wrote a great little article describing that it is largely inappropriate to compare Software Architecture and Building Architecture professions - see here. I think Mike has a great point that the two types of architecture disciplines are so different that it's hard to rationally compare the two.

Mike's blog reminded me my wife's comments on article titled "If building architects had to work like IT architects" written a couple of years ago. By the way, my wife is a commercial and residential Building Architect. Anyway, in that article, Katheryn felt it inappropriately assumed similarities of Software Architecture and Building Architecture to the point she felt compelled to comment and help explain that the article's author is probably not too knowledgeable of the Building Architecture profession.

Note: Although I feel it is largely inappropriate to compare the two professions, I wish we could. Unfortunately, as Mike points out, Software Architecture is just way too immature a profession at the moment.

Here's a repost of my wife's comments to the "If building architects had to work like IT architects" article. Katheryn Morgan wrote:

"The article is misleading because your IT projects are better related to a commercial non- personal project. Your clients would be equivalent to a developer not an individual looking for a personal residence. It can be done different ways, but this way is very common:

Initial Design

If the client is really unsure of what he wants and only has a vague idea and he wants to see some ideas first then he is paying for the head designer's experience. The team is made up of different experienced architects and workers. Each person's time is charged to the client at a different rate. Just like consulting, we have to assign our time to each project. The head designer would charge more per hour than the person assigned to draw it up. The more re-draws based on the clients wishy-washy-ness the more money they are being charged. The client is charged for mileage for site visitations, city department visits etc. Once a design has been agreed on (the project can easily be, and often does get nixed because the client has not acquired the site for the project or the investors have backed out or there are problems with the city allowing such project etc. You can convert any of these problems into your IT world I'm sure) then there is a next phase of costs.

Documentation Phase

The client will be charged by how many sheets of documentation is required for the project to go to a contractor to get sufficient bids for cost of construction. The lead architect by experience should know how many sheets would be required based on the size of the project. The client is also charged for all printing and mailing costs.

Construction Documentation Bidding

The documents are sent to several prospective contractors chosen by the architects and sometime by the clients, as they have probably worked with some before and others chosen because of their direct experience with this particular type of project. The builders bid this project on the hopes they will receive the project and no money is charged by them. The winner is the one who comes back with the best realistic construction cost and can generally show a realistic construction time line with milestones that they are held accountable for and they receive partial payments as long as those milestones are reached. There can also be a bonus incentive for them to finish on time (which rarely happens). This process is kept in strict confidence and the architect never reveals to the other builders what the others bid was.

Construction

Here is a key point different to your world: the designers and the constructors (builders) are different entities. The architect’s role here is to see to the client’s BEST interest. the architects answers RFI's and does site visits to ensure the vision of the project is coming to fruition. The architect answers requests for payment by checking if the milestones have been met, reporting progress to the clients and if the client is satisfied he will approve payment, and the architect will pay the builder.
At the end of the project the architect does a walk thru with the client and builder and any things that need fixing are written and given to the builder. He has to finish these last things before a certificate of occupancy is issued and the builder is given his last payment and any incentive bonus. The architect is also in charge of getting all permits from the city and any official requirements so the client can easily transition."

Comments

• Anonymous
  March 02, 2009
  PingBack from http://www.anith.com/?p=14903

• Anonymous
  April 30, 2009
  I know this is a repost, but one thing that struck me on re-reading it:  The architect pays the builder. This is very different from today's dev environment, where either the architect is part of the dev team or the architect advises the dev team.  In the first case, the architect is incented to represent the dev team, not the client.  In the second, the dev team is free to ignore the architect. If we did this in IT, the architect becomes part of the project management process in very important ways.   Hmmmm.  What would be the implications of something this decisive on the way IT software is developed today?  What would be the implications on the skill set and readiness of architects to take on this responsibility?

• Anonymous
  June 23, 2009
  Thanks for the great article!  I recently took a class where they talked about enterprise architecture.  The instructor really pressed that architecture should be about solutions rather then a collection of pieces.  Every business should know what they want to do. <a href="Six'>http://exed.stthomas.edu/SixSigmaGreenBeltTrainingMN">Six Sigma Green Belt Certificate Program</a> at the University of St. Thomas.