What indeed is architecture? Martin Fowler summarises some views on architecture in his article - "Who needs an architect?", one of the most interesting definitions from that article is 'architecture is the set of decisions that the team hopes to get right, because they are expensive otherwise'.
For a number of years (some of which included me having a title "Solution architect"), I never really thought much about what architecture is, why we need it and if we are in need of an architect role. The worst part is that I thought less about architecture being a 'Solution architect'.
I like the idea of thinking about architecture as a set of decisions, but it is probably simpler to stick to the IEEE definition that 'architecture captures the structure (static/dynamic) and organisation of a system'. This is the one that most people intuitively think of as architecture -- lots of lines, bubbles and squares on paper, i.e. structural models. It is one of those things that are cheaper to accept and move on, i.e. the fight/effort does not yield a win-win situation.
The interesting thing however, is that an architecture does indeed reflect the set of decisions that someone has taken. We have a 'Start menu' in Windows because there was a decision taken by someone, or a group. In essense, every software system is nothing but a reflection of the set of decisions that people have taken.
Now for the crux, the real issue is "Which decisions do we bother to communicate?", and how much effort to we invest in this effort? And by starting to ask these questions -- we may start to reflect on our decisions rather than focus purely on the end-result.
Another blog soon on a technique for getting started with architectures ....