Solution Architecture dot Org
     
      | 
Keep architecture on purpose – the three stages of architecture development
Written by John Critchley   
Saturday, 21 May 2011 06:13

New architects often have a theoretical understanding of what an architecture should be, but are often left struggling with the level of detail required in their designs, frequently mixing physical solution with concepts. This frustrates stakeholders who are beginning to get their own visions of the solution. A few weeks later, and the purpose of the architect and his/her architecture is lost as the solution is being defined by everyone but the architect. It's not on purpose!

For example:

A new project is started, and everyone just knows that there are going to be some new IT systems.
In fact, everyone just knows it’s going to be a sales support solution, with a CRM installation of ‘product X’, that it’ll connect to existing customer databases Y and Z, and will produce regular management reports in exported spreadsheets.
Great – let’s just do it! That new architect on the third floor can be assigned – just brief him on our agreed solution.

Sounds familiar? And it just doesn’t feel right, does it! Why? Because it hasn’t taken a diligent approach to determining the right solution.

How do we know that the investment that will be made is going to capitalise on available opportunity? Is the person who just dictated the solution the right authority? How does this align to the business and IT strategies? Does this ‘pragmatic’ approach align well with other initiatives in the business?

In short, we don’t know if this approach and sketchy solution is on purpose.

To get to a solution that is on purpose, there are three stages of evolution that the architecture must go through, each with a distinct purpose of its own:

  • Conceptual solution – defines the agree scope of the required solution, based on the high-level needs of the solution’s identified stakeholders
  • Logical solution – identifies and evaluates the feasible solution options that correspond to functional requirements within the defined scope
  • Physical solution – specifies the physical solution of the options selected, in the context of the existing IT estate, and within the agreed scope.

Do architecture on purpose in three stages of development: define scope, identify and select options, and finally design the physical solution.

Although there’s nothing particularly new about this concept, an ‘on purpose’ approach is rarely adopted, often with stakeholders, project managers and engineers jumping to physical solution mode before agreeing the scope and options for the change. The result? The architect on the third floor has few options and is forced into a technical documenter and fixer mode, eroding the potential value that a purposeful approach to architecture would have for the business.

The outlined 'on purpose' approach can be adopted into any framework – waterfall, iterative, etc. – helping the architect determine the level of detail required at each point of decision making through the stages of architecture evolution.

Stay on purpose and you will produced an architecture on purpose.

In a later publications I’ll argue that there are different ‘primary’ stakeholders for the purpose of each respective stage.

Originally published on JohnCritchley.com.