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.

What is ‘architecty’ about IT architecture? Reply

While the building and construction industry may rail against the self-proclamation of architect status by IT workers one wonders whether to whom the greater disservice is being done.  Although a ‘system’ may not manifest such obvious beauty to which we turn and marvel in the spectacle of its design the question should be asked – cannot a system have elegance too?

What is ‘architecty’ about architecture?

To me architecture has always encompassed the synergy of design and form.  It is the gentle blending of the functional with the artistic.  An objet d’art yet a liveable space with true vitruvian utility.  An expression of values and placement in the world yet something obviously sensible and practical.  Entirely down to earth yet striving to connect with the heavens.  Think of the pyramids, the Taj Mahal or the Paris Opera.  Can we compare IT to these? Could we ever design an IT system that could convey the sense of awe and achievement that great buildings and spaces inspire?


First we must broaden our perspective of ‘system’.  I always think of a system as a collection of parts functioning in unison for a common purpose:  the body, the metro, a biometric system at an airport or even a bee colony.  A system has spatio-temporal extent.  It is not conceptual and we can and do interact with it – purposefully or not.  It will always be hard to describe a network of underfloor cables and servers as beautiful.  But what about a well designed software application?  Where code has been masterfully crafted together into a contained system which delivers meaning to our lives and allows us greater utility to interact with humanity and our environment, can that be architecture?  What of the larger system?  Think of Ewan McGregor in “The Island”.  Possibly not the best example but a highly complex yet (almost) perfect blending of the utility of the system with the elegance of its structure.

What is elegant about systems?

Edward de Bono describes a good joke as one that is completely logical and obvious only in hindsight.  I think an elegant system is the same:  almost impossible to design logically and progressively but rather, it requires some divergent and parallel thinking to arrive at the seemingly obvious answer.  An architected system, therefore, should be a pleasure to use; inspiring and yet unintrusive, functional and provide us a clear means to our ultimate goal.  The Venetian transport system, Facebook even?

What do IT people do that is creative and beautiful?

IT allows us to interact with our environment in a way which not only heightens the end experience but the overall journey.  Software designers can create incredible applications which are not only functionally rich but are also a delight to interact with.  We can all think of a system that encompasses these things but there is one thing that architecture isn’t and that is haphazard.  ‘Architecting’ is design for purpose of a single entity.  Whether at the macro or micro level, architecting produces a single ‘architecture’.  It has unity, singular identity and purpose.  Think of the Parisian skyline.  There is one thing for certain and that is that architecting haphazardly is as bad as not architecting at all.

A new word for IT architects?

Even So, do IT architects ‘architect’.  Most usually not.  I would say that software designers often will come the closest.  This is not to say that IT is just Lego – positioning per-fabricated electronic building blocks to achieve a slightly different look.  By and large IT is more about technical engineering (capacity, throughput, interface, latency, queuing) than it is about designing into the human experience but this does not mean that it has to be nor is it always the case.