Who Needs an Architect Anyway? Part II - The Architect and Architectual Decisions

Let's assume I convinced you that some projects need architects (see Part I). Convinced, you go and hire an architect. Now what?

Let's start by looking at "architectural decisions" -- which is sure sounds like something we'd want an architect to do. I read once (I think that was something Martin Fowler wrote) that an architectural decision is a decision that in hindsight you wished you made right. if we look at a formal definition of software architecture (say from IEEE 1471) we see that the architecture embodies the fundamental decisions about the system its components, their relations and their properties. Using this definition an architectural decision is a fundamental decision about the system (which pretty much explain why we want to make them right etc.)

Well, here are two observations on what I've said thus far.

• One is that we would want to postpone architectural decision as much as we can, since changing them will cause us a lot of headache. The problem is that in order to postpone an architectural decision we need to build flexibility into the system which is an architectural quality in itself -- which might not be the top of the list if we prioritize it vs. other architectural qualities we need.

• The second observation is that if we "refactor" the pretty language out from both of these definition -- we can see that an architectural decision is basically a guess, hopefully that's an educated guess but it is a guess nonetheless. And as Albert Einstein once said it is hard to make predictions -- especially about the future.
  

This is why architect's breadth of knowledge -- which helps explain the architect training program I posted about a few weeks ago (see Architect training program Part I and Architect training program Part II).

Another aspect is experience. And to get a wider perspective it can be helpful if this experience includes other roles besides developer such as project manager or business analyst etc. Another important component is domain knowledge and understanding of the business.

Using all these you (as an architect) may come up with a reasonable architectural decision (e.g. use MVC pattern) and a design to match it and that's it.

Well, actually, not quite since as I said earlier it is still a guess. Remember an architectural decision (and any design for that matter) is a mirage no matter how beautiful the power point slide looks (or white board or UML sketch etc.).

Alas, power point compilers are still in the making. Which means that as an architect, you must be able to prove your point in writing -- that is coding. While you are at it, you also need to know a thing or two about the technology you are using because it too has an architecture, features etc. which can have a significant effect on the end result. (You can read a little bit more on this in the paper I published a while ago.)

The result of trying to postpone architectural decisions, ever changing requirements along with adding details as we unfold the architectural abstraction level to a working system, is that the architect can't just appear at the inception of a project and disappear afterwards -- they need to stick around for the game. This is especially true if you want to have an evolving architecture.

An architect needs to do more than "architectural decisions". There are also additional reasons why the architect should have continuous interaction with the rest of the development team. However that will
have to wait for Part III. :)

Posted by Arnon Rotem-Gal-Oz at 05:58 PM  Permalink