Tag Archives: in

the who, why, what, how and where of architecture

Have you ever been in a meeting where you ask ‘how’ something works and you only get an answer about what it does? Or .. you get an answer that is so detailed that you make a mental note never to invite the respondent to the meeting because they are “too low level”. Or .. you ask why a component works a certain way and the answer is ‘ask the architect’ (hmm .. I thought you were the architect?)

It almost seems that you get a different answer depending on WHO you ask – even within the same team! This is particularly bad in the IT architecture space because  – well – everyone wants to be an architect. I personally remember the feeling of absolute glee when after approx 5 years of waiting and 2 job changes, I officially landed a role where I was ‘the architect’. You would not believe what sort of other titles people will come up with just to avoid calling you an architect (at least that’s what it felt like at the time!).

Ok – back to the point of the post. I thought it might be an idea to try and express the different types of architect roles (WHO) in your typical big-IT environment and how their work interrelates in a complex web of why,what and how. If nothing else, it’ll help me remember who what sort of answer to expect when I ask the business architect ‘how’ a given component we are building affects the business user..

  • The business architect helps the business to define a suitable business process to achieve a given outcome (BUSINESS WHY) and out of this, what technology needs to do in order to support the business. At this stage, all we have is a ‘BUSINESS HOW’ that may have some technology components.
  • If a process involves technology, the solution architect is given the business process definition and any related material as input/justification (the SOLUTION WHY) and asked to come up with a solution. They start from the technology touchpoints identified in the BUSINESS HOW, and in conjunction with the business architect and/or business analysts gathers further details around how the business process will really interact with technology to achieve this outcome. At this stage, we have progressed our understanding to a ‘SOLUTION WHAT’ (ie what is the solution really meant to do, precisely defined in reasonably measurable tech-friendly terms).
  • next the solution architect works with various specialists (ok, “technical architects”) to devise a workable end to end solution to meet the objective. At this stage they have defined a ‘SOLUTION HOW’ at minimum, and if they have really taken the time to talk to the people responsible for all the components, they may also have specified what each components is responsible for – i.e. ‘COMPONENT WHAT’s. Interaction definitions within the solution design provide justification these capabilities, so the solution design also serves the role of the ‘COMPONENT WHY’.
  • finally in order to actually build out the components, the specialists need to work out ‘HOW’ they are going to make their component do what the solution architect has come up with. This gets captured in detailed specs which are the ‘COMPONENT HOW’s.  These of course form the builder’s WHY, based on which they will BUILD WHAT THEY ARE MEANT TO!
  • across all of this discussion, we haven’t even touched on the data. Data is the 4th dimension to all of this – ‘WHERE’. At solution level we talk about where data is mastered and where it is moved to and from as part of interactions. At component level we talk about where a data item can be found in transit (integration) or at rest (database, filesystem etc).
  • WHEN is always yesterday – no need to discuss this point.

Note that in smaller organisations, some architecs will wear multiple if not all of these hats.  It is however important to ensure that the different perspecitves of a solution are understood and addressed adequately.

For the non-architects out there who have to interact with IT’s most trusted profession, hopefully this gives you a view of the different perspectives that people labelled as “architects” might be viewing things from – if nothing else it will help you understand why they say they are in sync but are constantly arguing!

PS – having written this I think I’ll take another look at the Zachman framework – maybe the penny has finally dropped on what he’s on about 🙂