Talk of the business-IT divide is common. There is very little that happens now without the aid of technology so IT is now at the centre of everything that happens. Given that IT must always be involved why is it that the primary complaint is that this gap is widening with the IT and ‘the business’ becoming increasingly suspicious of one-another?
Design and development processes in enterprises typically follow the same sequence. It starts when someone in ‘the business’ comes up with an idea and explains this ‘concept’ in a document accompanied by what they see as a strong investment case that justifies the energy of the company to be directed at his idea. The ‘concept’ is analysed, discussed with the originator, as well as other directly or indirectly affected stakeholders, and a set of ‘business requirements’ written by a ‘business analyst’ (what does this term even mean? something to discuss in a later post) who firmly represents the IT function. These ‘business requirements’ are given to a technical designer or architect within IT who designs the end-to-end solution. Components of this solution are designed in detail by a specialist for that component and then these are built, tested and put into ‘production’.
When the originator of the idea complains that what was realised was not what he had asked for he is quite often told that the area of his complaint was built according to ‘business requirements’ which he signed off, often without really realising the gravity and finer nuances of some statements made within them. I have a real problem with this and feel this stems from a lack of ‘skin in the game’ from IT.
The ‘business requirement’ is something for the IT community to hide behind and to have an excuse for not really taking the time to understand what the initiator really wants. It is an excuse for the entire technical community to use the ‘business analyst’ as a human shield and not collaboratively deal with the issues that those on the sharp end, commercially or operationally, of the organisation are feeling.
The very idea of the ‘business requirement’ also sends a very clear message: IT is not part of ‘the business’. I’ve never seen an organisational chart that is split into two distinct areas, ‘the business’ and ‘not the business’, and find that support functions (because let’s face it, that’s what IT is) are interwoven with commercial and operational functions. Even if you ignore that IT is funded by the money-making parts of the business, how anyone can possibly say IT is not part of ‘the business’ with a straight face is absolutely beyond me. Whilst in many if not all cases IT has no direct P&L responsibility (it doesn’t directly sell stuff), it underpins the P&L of pretty much every commercial and supporting operational function. IT is very much part of ‘the business’ and the sooner it realises this the sooner the divide will start to close.
What this requires beyond anything else is that members of the IT function really understand what the company does and how it makes money (or intends to if it isn’t yet making money). IT must also take time to ensure its constituents understand what trends the company is genuinely interested in. I would go as far as saying every member of the IT function should spend some time seconded into ‘the business’ so they can understand a little more. Having said that ‘business analysts’ and architects are meant to be smart people that sit fairly high up the IT food-chain and really have no excuse for not understanding what ‘the business’ really does.
From an architecture perspective realising that architects are indeed part of ‘the business’ implies a number of things. Firstly, I am a firm believer that you don’t need a 50 page requirements document to design something. In fact you barely need a single statement but you do need ‘skin in the game’ and to be collaborative in exploring the initiator’s requirement with the initiator. You need to understand what the originator of the idea is trying to achieve, by this I mean what they really trying to achieve, understanding his motivations as well as what temporal, operational and commercial constraints exist in his world so that you can propose a sensible solution in terms of target architecture and interim steps to meet such constraints. This may require that you talk to people outside of a traditional engagement framework, often one-on-one, to really understand the problem space.
If you, as an architect, don’t understand where the initiator is really coming from you must not, as an architect, assume he is an idiot and that you know better – your time would be better spent with him to get inside his head. Doing so would increase your credibility with those whose requirements you are trying to meet making you a trusted partner and advisor.
At the same time, I am not suggesting that these discussions are not formalised for communication and future reference but asking the initiator and other stakeholders to sign off a requirement would be like asking someone to contract in a language completely foreign to them, not understanding the nuances of the statements being made – certain areas of the corporate world derive the same meaning from ‘should’ as they do of ‘must’ – the section at the beginning of a document explaining the difference doesn’t make a difference.
The definition of compliance should also extend beyond marking a requirement in the requirements document as fully, partially or non-compliant. Burying the compliance view in a document in this way is akin, in my opinion, to deceit and isn’t enough as it serves no purpose beyond being a box ticking exercise to ensure the technical designer or architect has read the ‘business requirements’ – nobody ever seems to check the actual compliance of every requirement marked as fully-compliant, choosing to want to discuss the partially and non-compliant items instead. Compliance should be about really understanding the problem space and being able to describe face-to-face the design decisions made as well as the implications, constraints and limitations introduced in the solution being proposed. This requires for courage and honesty with your peers, the ones that are in the same ‘business’ you are. Ultimately, the design should be fully compliant with the requirements, because there has been an agreement to change the requirements or solution in each case so that there is alignment between what has been asked for and what is being delivered.
Requirements do need to be classified in some way. This classification, in my opinion should be such that they indicate which part of the original ‘concept’ they relate to (go-to-market, legal, on-boarding, in-life, end-of-life, operational, technical, user experience etc).
There is enough ‘us and them’ in the corporate world and the IT function has a responsibility, to itself more than anything else, to ensure there isn’t any more in the domain in which it is focussed. If IT doesn’t act ‘the business’ will set up its own IT function who will see itself as part of ‘the business’ simply because they don’t see themselves as part of IT.