Fundamental Axiom of Architecture (Risk Driven Architecture)

I am currently engaged in some research on an approach towards quantifying organisational capabilities. Through this process I was reading ISO31000: 2009 (Risk Management Standard) from the International Standards Organisation (ISO) that succinctly defined “risk” as;

“The effect of uncertainty on objectives.”


This is particularly appropriate within the context of defining Architectures. I’d go so far as to assert that reducing uncertainty is one of the fundamental axioms of architecture, and therefore the role of an architect. Some simple examples to explain;

  • A Solution Architecture will reduce business risk relating to a solutions ability meet particular requirements (objectives). Said requirements, typically defined across business, functional and non-functional aspects of a solution, collectively deliver to an organisational outcome.  The architecture will reduce uncertainty regarding business interfaces, deployment and necessary support structures.
  • A Technology Strategy, and accompanying road-map, reduces uncertainty relating to required technology investment for ICT capabilities necessary to support the business objectives over a prescribed planning horizon. Therefore, such planning reduces organisational risk that ICT investment is ill-directed.
  • A Segment Architecture for Integrated Customer Service will reduce executive uncertainty regarding the level of ICT systems and organisational change required to support a new customer service division. The endorsed segment architecture will improve the organisations chances for success before venturing into a change program and therefore reduce the risk of abject failure.

Therefore it is a reasonable assertion that through the minimization of uncertainty, relating to an architectures ability to meet business objectives, the Architecture Practitioner is fundamentally managing and reducing risk. 


If you accept this axiom as true, you then begin to question the application of risk management principles to the way in which architectures are created. Through the adoption of a risk driven approach, an Architecture practitioner can address organisational concerns by focusing on components of the solution prioritized through risk assessment criteria. 


Every organisation will have their own risk appetite; The level of risk they are happy to carry through different types of engagements. The lower the risk appetite the more complete the architecture needs to be, and of course the inverse therefore applies. A simple risk matrix with analysis axis included below by way of example. As in Figure 1, where the likelyhood is low, and the impact is negligible, only light-touch analysis and design would be required. However if a component of the architecture has a major impact, and is likely to occur, then considerably more analysis and design will be required.

Driving architecture attention through risk assessment
Figure 1. Driving architecture attention through risk assessment

To build on this concept, an “Acceptable Risk Threshold” would represent an organisations risk appetite, and would be used to guage the level of analysis necessary within the architecture scope. As with Figure 1, the risk appetite is quite balanced, where only components of an architecture which are likely-or-almost certain, and a major-to-severe impact requiring the most analysis. Graphically this can be viewed in Figures 2 and 3, which show organisations with different Acceptable Risk Thresholds. Hopefully you can tell, from the images, that Figure 2 represents an organisation that has a low risk threshold (4). Figure 3 however is more middle level and somewhat reflective of the risk threshold in Figure 1 above with a higher risk threshold (11).

Assessed Risk Threshold = 4
Figure 2. Assessed Risk Threshold = 4


Assessed Risk Threshold = 11
Figure 3. Assessed Risk Threshold = 11

Such an approach is a considerable departure from standard practices. To support such an approach however would require an organisation to be quite structured in their architecture practice, and requires additional upfront planning and analysis in risk assessment of the components that make up the architecture. Standardized views and viewpoints, modelling notation and analysis methods would need to be in place, and the risk threshold could then be applied to the development of Statements of Architecture Work. Governance bodies would perhaps have a better means through which to assess completion of the Architecture, rather than a mere “tick-n-flick” that a document has been completed.

Undertaking Architecture itself will inevitably reduce implementation risk; though perhaps through the adoption of a Risk Driven Design approach, an Architecture will also be more likely to address the organisations needs through focusing effort on those areas that represent the greatest risk, rather than creating overly burdensome Architectural deliverable’s. Sure, the concept itself requires further development to prove within a working environment, however the basis behind the approach would seem to warrant further exploration.

 

leon.obrien