Cloud research exposes gaps between CIOs and the business. . .again Reply

In a recent article for Beyond IT Failure Michael Krigsman highlights the colossal disconnect between IT and the business.  Looking at the graph below has IT really spun off at a tangent?  Is IT just pursuing its pet projects again?

IT is not wrong.  IT is best placed to understand compliance requirements.  IT should understand which applications delivery value for money and IT should be able to choose which apps support competitive advantage.  Cloud is, by and large, a non-functional requirement as so does not need to be in the functional user spec.

“Business is not a toy shop and the argument “but I’ve got it on my phone” does not wash in a secure, structured enterprise environment.”

So why the disparity between what what the business thinks it needs and what IT choses?

  1. IT is a cost centre.   IT is responsible for delivering functionality in the most cost effective way.  Business is not a toy shop and the argument “but I’ve got it on my phone” does not wash in a secure, enterprise environment.
  2. Business Requirements.  I have never met a business vertical which understood its requirements.  Requirements engineering for the systematic design of accurate software is an entire segment of the tech industry.  It is complex and (mostly) poorly done.  Invest in getting it right if you want to deliver better systems.
  3. Engagement.  There is no two ways about it – IT is appalling at business engagement and business are shockingly bad at letting IT in and then articulating their needs (in order to begin the requirements process.
  4. Productivity.  Improved productivity is more of a human problem than a technological one.  New software will not make people smarter.  Unless the processes and collaboration structures already exist then new binary systems will only serve to compound the problem.  In such cases, software procurement becomes a very, very expensive process of sandboxing and prototyping to elicit accurate business requirements.

In order to achieve better ROI on tech investments whilst still delivering great software which improves productivity, businesses need to (a) understand where tech enables business capability in their value chains, (b) understand the development of their business’ capabilities, and (c)  create a ‘value ladder’ which supports the parallel propositions of architectural development and business productivity.

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.

Why?

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.