Measuring Risk in Logical Processes Reply

logical-architecture.-wire-diagram.pngLogical architecture is valuable in the design of large systems for 2 key reasons:  (i)  it helps developers instantiate the softer concepts and  more social aspects of large systems, and (ii) it provides another review-gate to iron out design flaws before proceeding to the physical system.  Military systems provide good examples of the value of logical architecture.  Many Defence systems are so complex that they are never developed at all.  If they are at all then they are often broken down into such small components that the integration can become unmanageable.  Joint Effects Targeting, counter-IED exploitation, systems to fuse operational and intelligence and the nuclear firing chain are all areas which have enormous social input so that the development of a logical architecture is paramount.

Unless a person has a pedigree in military systems logical architecture is, usually, the least understood/used part of the design process.  Certainly in Agile environments or any area requiring rapid applications development where the application is fixed (portals, billing systems, SAP etc) then logical architecture design is nugatory.

In this blog we look at logical process design but the method is equally applicable to the entire logical design phase.


When designing processes, however, logical architecture is an invaluable tool in measuring, assessing and comparing risk before moving to the more expensive technical design & implementation phases.  Because logical designs can be created, compared and assessed, quickly,  they become an excellent technical/commercial appraisal tool.   Cross-functional teams of executives and architects can collaborate on logical designs before a GO/NO-GO investment decision and thereby create 3 major benefits:

  • Reduce the time of the physical design cycle.
  • Increase executive involvement and the effect of executive steering on designs.
  • Significantly reduce the risk in physical designs.


The Value of a Process

There is a way of viewing, and thereby measuring risk in logical processes.  Ultimately, the value of a process is its cost divided by its risk.  So, a process which has a total cost of $100,000 and a 60% chance of success has a nominal value (not “worth” or “price”) of $60,000.  Which is to say that on average the business will realise only 60% of its value.  This is roughly the same as saying that, on average, for each $100k in earnings, the firm will spend $40k on faults.  Whether the value indicator is dollars or white elephants does not matter, so long as it is applied consistently over the choices.  This simple measuring mechanism allows senior executives to engage in the design process and forces architects to help assign costs to difficult design components.


The difficulty is in ascribing costs to concepts.  In order to do this the team must first instantiate the concepts win some form of logical structure, such as a software system or a management committee/team.  The team then ascribes an industry benchmark cost to this structure, accounting for uncertainty.  Uncertainty is important because the benchmark cost will not represent the actual cost exactly (in fact the benchmark cost should represent the 50% CI cost).  So, when it comes to determining the probability it is vital to use the experts to come up with what the construct could cost (as little as and as much as).


The difficulty with measuring logical architectures is in measuring concepts.  Concepts usually have no value and no standard means of comparing them.  In short, (i) assemble a small, cross-functional team of experts, (ii) ascribe costs (with uncertainty) to the concepts, apply a risk equation, and then (iii) simulate.  One possible equation is:

Logical Risk Equation - An equation for measuring process risk in logical architectures.


  • R is the overall risk.
  • P is the probability of an adverse event occurring in the process.
  • Ct is the criticality of the location of the event, in the process.
  • is the likely time it will take to notice the manifestation of the risk (i.e. feedback mechanisms).
  • Cy is the availability of a contingency plan which is both close and effective to the point of the problem, in the process, and
  • Sl is the likelihood of success that the process will be fixed and achieve an acceptable outcome.
  • 100 simply makes it easier for the team to see differences between scores.

In this equation, we determine the overall risk of the process.  It does not have to be perfect but rather it just needs to be applied consistently and account for the major variables.  If applied rigorously and evenly, measuring risk in logical architectures has the ability to reduce the design cycle, increase the certainty of the choice, build better stakeholder buy-in and significantly reduce the risk in the physical solution.

BUSINESS PROCESS FAILURES: the importance of logical architectures Reply

business process risk. chart

In a recent 2012 survey by McKinsey & Co, IT executives noted that their top priorities were ‘improving the effectiveness and efficiency of business processes’.   One of the critical failings of IT, however, is to implement effective and efficient business process architectures in the first place.  The IT priorities to the left only serve to highlight what we already know:  that IT service companies implement processes badly.


Whether through a failing of Requirements or Integration (or both), IT service companies often implement inappropriate business process architectures and then spend the first 6 to 12 months fixing them.  This is why those companies ask for a 6 month service-credit holiday.  It is also the same reason those companies differentiate between Transition and Transformation.  The former is where they implement their cost model but the latter is where they implement their revenue model.

The failing is not within the design of the technical architecture.  Very few senior executives report that failed projects lacked the technical expertise.  Likewise, project management is usually excellent.  Requirements, too, are not usually the problem with business process implementations as most commercial systems implement standardised Level 1 or 2 business processes very well.

Logical Archtiectures instantiate the subtleties and complexities of social systems which the software must implement

The first failing in the development of a technical architecture to implement a business processes is the design of the Logical Architecture.  Logical Architectures are critical for two reasons: (i) because requirements are one hundred times cheaper to correct during early design phases as opposed to implementation, and (ii) because logical systems are where the social elements of software systems are implemented.  Requirements gathering will naturally throw up a varying range of features, technical requirements, operational dependencies and physical constraints (non-functional requirements) that Solution Architects inevitably miss.  Their focus and value is on sourcing and vendor selection rather than the capture of the subtleties and complexities of human social interactions and the translation of them into architect-able business constructs (that is the role of the Business Analyst).

The second failing is the development of Trade-Space.  This is the ability to make trade-offs between logical designs.  This is the critical stage before freezing the design for the technical architecture.  This is also vital where soft, social systems such as knowledge, decision making and collaboration are a core requirement.  However, trade-space cannot be affected unless there is some form of quantitative analysis.  The usual outcome is to make trade-offs between technical architectures.   Like magpies, executives and designers, by this stage have already chosen their favourite shiny things.  Energy and reputation has already been invested in various solutions, internal politicking has taken place and the final solution almost eschews all assurance and is pushed through the final stages of governance.

With proper development and assessment of trade-space, companies have the ability to instantiate the complex concepts of front and middle office processes.  Until  now, business analysts have hardly been able to articulate the complicated interactions between senior knowledge workers.   These, however, are far more profitable to outsource other than more mechanical clerical work which is already the subject of existing software solutions.  The higher pay bands and longer setup times for senior information work makes executive decision making the next frontier in outsourcing.

Service offerings

Logical architectures are not usually developed because there is no easy, standardised means of assessing them.  Despite the obvious cost effectiveness logical architectures most Business Analysts do not have the skills to design logical architectures and most Technical Architects move straight to solutions. Logical Architectures which are quantitatively measurable and designed within a standardised methodology have the potential to give large technical service and BPO organisations greater profits and faster times-to-market.

The future is already upon us.  BPO and enterprise services are already highly commoditised.  The margins in outsourcing are already decreasing, especially as cloud-based software becomes more capable.  If high cost labour companies (particularly those in based in Western democracies) are to move to more value-added middle and front office process outsourcing then they will need to use logical architecture methodologies to design more sophisticated offerings.

In the next blog we will show one method of quantitatively assessing logical architectures in order to assess trade-space and make good financial decisions around the choices of technical designs.