Back in 2008, I wrote a paper on Business Analysis. Recently, I’ve been revisiting this subject in my day-job and this made me realise how little things had changed and inspired me to write this post, which is, basically, the original article re-written, with additional thoughts (in
italics).
The role of the Business Analyst has never been more important but needs refocus on Information Systems not the technical solution. Many of us can recall a time when a distinction was made between the hardware and software supporting the business and the information used by the business – there was a clear difference between IT, to describe the former, and IS to describe the latter.
IS stood for Information Systems:
IS: The landscape of business information used by people within an organisation
and how they use information to deliver business outcomes.
IT, in contrast, meant:
IT: The hardware and software technology that automates or otherwise supports
information processing.
This distinction between these two concepts is all but lost, and the disciplines associated with Information Systems (such as Business Analysis and IS Architecture), are have become too obsessed with IT.
Where did the Business Analysts go?
The change of focus was probably, in part, caused by the rise in enterprise software packages and the associated promise that these out-of-the-box solutions could work miracles – magically automating all kinds of business processes and spraying efficiency glitter over all parts of the organisation. Powerful promises!
And to make them even more seductive, they contrasted sharply with often, expensive and unsatisfactory, custom-build software projects. Small wonder then, the new-kids-on-the-block, ERP packages, were seen as being more business relevant: enforcing standardisation and promising to boost efficiency. Business Analysts started to abandon their ‘real job’ to become, in effect, package ‘fit-and-configuration’ specialists. Inevitably, their work began to focus on the features and functions of the software, rather than the realities of the business with its complexities: messy processes and human interactions.
Since then, others with expertise in IS, have gravitated to the world of IT architecture. This discipline has proved increasingly important with the many large organisations who realise that packages – even so called ‘enterprise-wide’ ones, need to coexist the rest of the IT estate. You can’t buy architecture in-a-box!
At the same time, the revolution in Open Source and Web technologies meant that the focus of architecture began to move away from the organisation’s internal IS needs and towards the emerging global IT standards, tools and methods used by its customers, suppliers and partners. The sheer complexity of all aspects of ‘architecture’ meant that areas of technology-focused specialism began to develop within the architecture community.
This article suggests, it’s time to dust-off the concept of Information Systems, and return to business analysis practice that focuses on:
Simplifying [as much as makes-sense], balancing and consolidating requirements across all aspects of the business, but with, the important business outcomes, front-of-mind.
Identifying repeating patterns of business activity and seeking out opportunities for shared competencies and services.
Understanding the behavioural aspects of the business that have been proven to be barriers to adoption of IT solutions.
Studying the elementary aspects of the business’s Information System such as rules and constraints embedded in policies, the business-meaningful, real-world, events of interest and the information content being exchanged between individuals and groups.
Communicating and agreeing upon the business ‘what’ before getting immersed in the technology ‘how’.
What’s in a Word? The Problem with ‘Process’
There appears to be a problem with how we use the word ‘process’. To support business efficiency goals, many envisage the world as a set of neatly ordered, well planned, predetermined and logically sequenced set of activities – just as Henry Ford did when he introduced the production line. This is hardly surprising as it is a tried and tested approach to manufacturing, and more generally reflects a simple but intelligent goal – to be more efficient at a task through understanding and optimising all the steps. However, optimisation and automation require all the steps and parties involved to be specifically defined, so this approach usually seeks to ‘decompose’ the task into detailed models of all the interacting parts within the end-to-end process. The process being defined is also typically mapped to an organisational framework and financial models which constrain it within central and departmental rules, polices and edicts, which are often inherited from corporate decisions unrelated to the process in-hand. This is Six-Simga-Everything mentality! The most critical problem with this efficency-only focus, is in its poor representation of the softer, more knotty problems associated with differing values, policies, and operational ‘realities’.
To add to this problem, the language of users differs significantly from that of the IT specialist. This difference in language is a reflection of apparently opposing values (value systems) in play. Fundamentally, the users want a system that works the way they do one which is often prone to change and which supports learning. The IT specialist seeks a high degree of functional certainty and actionable rules that can be configured or encoded.
(see note about ‘Agile’ SDLC at little later).
To make matters worse, the gaps and inconsistencies in the expression of business requirements force a high degree of IT ‘engineering rigour’ that attempts to complete the picture. IT engineering relies upon techniques and tools that are designed to convert process and policy into precise rules and constraints. This can result in important behavioural dimensions such as the effect of variance in values and levels of trust – being left unspecified, and tension-points left unresolved. The dialogue between user and the IT specialist becomes focused on the detailed features and functions of the IT ‘solution’. The business outcomes of the sponsoring executive become obscured by this drive towards detail and by the end-users’ individual, and collective, ideas on how the ‘solution’ will work.
C-level ‘Businesss Stakeholder Standardisation Edicts’ or sent out in an attempt to ‘Get Things Back on Track’: ensure that operational efficiency goals are met and key business outcomes are delivered. This can result in an unwitting collusion between the C-level ‘Business Stakeholder’ and the IT specialist: both parties are motivated to build ‘standardised’ behaviour into the IT solution.
The top-down edict approach to driving IT-enabled business change projects suffers from three major problems:
Adoption Barriers
The users are less inclined to adopt the IT solution, claiming that it doesn’t work for them – they continue to use and develop ‘shadow’ IT solutions
Brittle Processes
The top-down specification of process works against flexibility and becomes a barrier to future business change.
Business/IT Misalignment
The organisational and management models of the business are not properly reflected in the IT solution. In, for example, a multinational business with diverse operations, it may be necessary and desirable to allow for local freedom-to-act, in say, Customer-facing processes.
It seems we need a different approach to how we specify requirements for IT: an approach that balances the desired business outcomes of the stakeholder with the needs of the user, yet with the precision needed by the IT specialist.
Significant improvements are being claimed by the ‘Agile’ development community, however, the problem still exists when likes of SCRUM and XP don’t apply, such as the deployment of a package solution or, increasingly, the purchase of SaaS. Not to mention, that ‘Agile’ approaches can be left wanting when in comes to cyber-security and data privacy.
It appears that the language-used, and a premature focus on IT, are at the root of this problem. The language problem starts with how we express the concept of processes. The word ‘process’ can have very different meanings and implications. These can range from the loose collection of unsystematic activities, that might support a contract negotiation, or an HR process, to the highly repetitious, and predetermined behaviour, of say, a production line. Maybe a common language for describing the range of business behaviour, across any type of process, would help?
A premature obsession with the details of the IT solution, seems to drive the analysis of the business problem towards IT engineering methods. Such methods often ignore or, at best, neglect softer, human, aspects. IT engineering methods and techniques are designed to drive completeness and precision for systems and, in doing so, introduce a language that is, by its nature, hard for the business to understand. This creates frustration on both sides of the Business/IT divide: neither party understanding the needs of the other. The sheer volume of information produced during the engineering life-cycle, means the overall business context gets lost in the production of flow diagrams and technical plans. The complexity of the task requires a high degree of technical specialism. This can lead to a lack of focus on the nuances of real-world behaviour and human interaction ‘on-the-ground’. Often the focus is slanted towards engineering ‘How’ rather than the business ‘What’: the business outcome.
The reality is that many business scenarios are more organic, and unpredictable, than pre-determinable, and mechanistic. In today’s connected world, many business scenarios encounter tensions between corporate and local functions, between customer and supplier, and between partners. No one is in control of the end end processes; rather, a combination of interacting service agreements make up the overall value delivered to the customer.
In contrast to usual business/IT dialogues, what’s needed is a natural-language that moves the focus away from any technologies and towards business behaviour – as expressed in values, policies, real-world events and any type of information [Content] being exchanged.
The original article bangs-on about VPEC-T and, our then, current, book ‘
Lost In Translation‘, which I’ll skip now [sigh of relief for many!]. I would end the article differently now. In hindsight, it missed-out some more fundamental (and frankly, more broadly applicable techniques) such as SWOT, Risk-Radar, Hypothesis-led and PESTLE analysis. Perhaps more importantly, I would emphasise the value of; ‘abstraction’ (conceptual and logical ‘What’ before ‘How’ thinking), an understanding of ‘Complex Systems’ – The
Cynefin Model (Dave Snowden) would be a good starting point – and workshop techniques such as those described in ‘
Gamestorming‘ (Dave Gray, Sunni Brown and James Macanufo).
I recently came across the ‘
Brown Cow Model‘ (Suzanne & James Robertson)
when wrestling with a culture of ‘How’ before ‘What’ behaviour – aka ‘I have the solution, so what’s the problem’ ! I love the simplicity of ‘Brown Cow’:
I’ve found this simple model a great way to keep project teams focused on understanding the ‘What’ before the ‘How’ and the importance of knowing the AS-IS situation before leaping to the TO-BE. This, for example, has opened-up the requirements discussion to include the, often-overlooked, business requirements of the transition between ‘Now’ and ‘Future’ states. Maybe, this is more of a problem here in Asia, but given some experiences I had in the UK over the past five years, I suspect not!
I about to run out of battery on my iPad now – so that’s all for now. As always, I ask for your comments! Thx.
