I had an interesting conversation with a friend of mine that resulted in some disagreements on root issues architects face. The topic of the Architect Nemesis came up. Where some of assertions were accurate it was still founded on a fundamental belief the we should correlate software architecture to the architecture of structures.
So what is the REAL Nemesis of Architecture?
Is it the engineer? Is it the templates and patterns? The CIO? NO…
I believe that the real nemesis of architecture here is in the name itself. Unfortunately we as an IT industry continue to compare ourselves with traditional architecture. Why is that? Well I think because it looks viable on the surface.
Here is why I think the Structural Architecture is different and why we shouldn’t compare the two (at least without having an understanding of where the analogy breaks down):
Maturity – traditional architecture has a head start of approx. 10,000 years old starting with Neolithic architecture that was around before 8000 BC. Since architecture has been around for such a long time there are clear lessons learned. A clear collection of knowledge, true repeatability and reuse, standardization and the creation of architectural styles.
History of Architecture – It is unfair to compare software architecture history to traditional architecture history. Contrasting with eras such as Classical –> Medieval –> Renaissance –> Modern architecture is looked at as a linear progression while it is far from a linear progression. As an example, before the fall of Rome there was running water and toilets in homes while it took close to 2,000 years to get that back. Another example is in South America where archeologists found ruminants of Nickel being created where that same feat wasn’t accomplished till the early 10th century. The history of architecture is a complex one driven by many forces and sometimes the great innovations are lost though time. The history of IT architecture is but a fraction compared to the architecture of structures.
Motives and Intent– The great architecture that are typically referenced in software architecture are by the Romans, the Greeks and occasionally the Egyptians. The problem with this is that the drivers to build these great architectures where often not the same drivers as for software architectures. These great architectures of ancient times were built based on personal ego, religion and conquest. Examples of this include: Via Appia roads in Rome (support conquest), Pantheon in Rome (ego/religious), Taj Mahal in India (religious), and Parthenon in Athens (religious). For software architecture the primary drivers are business drivers. Not how to sustain a legacy of an emperor or have a religious structure symbolize an ideology but to solve a set of problems for a particular point in time. Solutions are put into a portfolio because we know they will change (sometime radically).
Accountability Inherent – Building architects are accountable for there work when their specification fail while software architects are not. An example of this is the case of an architect stealing a design for the Freedom Tower or the example of MIT that sued well known architect for defective structures. There is clear accountability whereas I still haven’t heard of someone getting sued for copy & paste…
Models are Concrete – No ambiguity in a model from a building architect. Like the quote from George Box “all models are wrong, but some are useful”. This resonates and is very true in the software industry. It is very common to see an outdated and obsolete model hanging outside a cubical that isn’t fully understood by the IT staff supporting. While you will never find an inaccurate city planner model. Two different worlds on what is acceptable from the models.
Accreditation and Certification - Unlike the software architecture field, architects must be certified to work on an architectural project. This is vastly different in the software world. Often times the title of architect is given as a promotion to an engineer, a trendy title or just lack of understanding of what an architect really is. This leads to a level of ambiguity in the definition of what really is a software architect.
These are some initial points on the differences of these two vastly different professions. While they look relatively similar on paper they are different. Time and time again I see the correlation between these two professions and keep seeing the inaccuracies and false comparisons which I think leads to confusion and mistrust of our business leaders.
While I have been guilty of making these references when trying to convey ideas with something relatively similar. You maybe wondering if there are other parallels we can reference as software architects, I am not sure. How about the profession of an artist? Software architecture is more art than science, right? At least for now…
What are your thoughts?
Technorati Tags: Architecture
Share this post :
Comments