Business architecture seems to move from the pointless to the absurd. Why do organisations spend so much time and money on documenting business processes and requirements only to see nearly all IT system deployments run over time and cost?
Can It Ever Be Useful?
Technically, by modelling business processes the business analyst (BA) should be able to derive the functional requirements of a system – largely by analysing “events”. Here’s how it should happen:
- The BA derives the Business Process Use Cases from the analysis of process documents.
- The BA then works with the business to devise ‘realisations’ of these use cases.
- The realisations are then analysed for System Use Cases.
- The system analyst (SA) then works with the tech teams to design system realisations which instantiate the system use cases.
- Then the programmers work to code all this so that the new system does exactly what the users wanted, i.e. business functionality.
So Why Does It Never Work?
The litany of well documented IT project failures highlight the fact that this process usually does not work. Although the process is clearly broken it is not fundamentally flawed. Firstly, requirements structures are over-simplified and their levels of abstraction are confused. This means that the link between most business modelling and business use case development is intuitive and a leap of faith.
The process of requirements development is well documented in the Rational Unified Process (RUP) and well supported by sysML, UML and Business Motivation Modelling (BMM). It is usually through a lack of BMM, however, that the process falls down. Not only does the process not work it also serves to hard-wire bad culture into the business. By designing software from poor requirements the business not only increases the cost of future change (approximately equal to x100) but it also ends up coding bad culture – the very culture/processes they wanted to steer away from by designing new software.
So What Is The Value Of BPM?
Apart from the sheer cost saving ability of a sleek requirements process, Business Process Modelling has great value in automating processes. BPMN models can be exported to BPEL and executed as computer processes. This gives huge flexibility in orchestrating complex process and workflows between machines.
Designing Directly from the Value Chain
The real power of good business modelling is when it gets ahead of the design curve and starts developing business architecture directly from the Value Chain. By analysing the hot-spots in the finances and then determining whether they are valuable-spots within the Value Chain, business architects can begin to develop or rationalise designs before they become pet projects. This is not done already, largely, because accounting standards mean that (a) costs are not coded according to a business’ Value Chain, and (b) virtually no business has a well documented Value Chain to start with. However, it is a valuable exercise to understand the correlations and dependencies between what a business spends money on and how it earns revenue. Who better to do this than the business analyst/architect?
The chart below only serves to prove Paul Strassman’s mantra that outsourcing is more an emetic than a cure. By and large the following is true:
- Outsourcing is a financial decision and not a business one.
- Companies engaging in heavy outsourcing activity are overall commercial losers.
- Financial gains from outsourcing are usually mythical as per user costs usually increase from declines in overall employment.
- The only financial gains from outsourcing are usually short term wins on the stock markets.
Large scale outsourcing of the IT function weakens corporate productivity by lessening flexibility at a time where the company must create additional agility in order to survive. The heavier the outsourcing activity the more likely the business is to lose its information management function, i.e. the ability access information (which now largely resides under vendor SLAs), package and use it quickly and effectively is now gone.
The secret to IT outsourcing is to (a) commoditised and (b) focus on capability. Firstly, businesses should not even have to think about infrastructure. There are very few arguments to retaining one’s own data centre. IT infrastructure and even network monitoring and optimisation are highly commoditised product offerings with very low risk. Just do it.
Secondly, focus on capability. Understand where technology creates value in your business. Focus on increasing the productivity (and reducing costs) of those areas of opportunity by packaging modular information offerings from high-end suppliers. For instance, some outsourcing companies specialise in data analytics and BI. Some specialise in risk analysis and some specialise in service-based client messaging. Start to build these services – all of which can be done better and cheaper by outsourcing firms – and begin to build them into a client narrative which allows your business to penetrate deeper into the middle and front offices. This is just an example but it highlights the fact that if your company has a modular information supply chain you have the agility to create great, differentiated service offering based on real customer value.
Be careful what you outsource. Get to grips with business complexity (it’s here to stay) and don’t derogate from your business responsibility to information management.
Aristotle wrote that “metaphor is the worst form of argument. He’s right. If you have something to show/prove, then do so precisely and in a way which is meaningful and useful to your target audience.
Recently the guys at Innovation of Risk posted an article on the use of infographics to analyse risk. I don’t know who coined the term “PowerPoint Engineering” but most infographics fit neatly into this category. Infographics can save presentation or they can sink it but mostly they are used to convey ill conceived and poorly thought out ideas which snowball into worse run projects. The best advice is to take these bath-tub moments (why do people think they have great ideas when they’re washing?) and run the analysis with an expert using an expert system. If you can’t do that then (a) you’re in the wrong department for having the idea in the first place, and (b) chances are that there is a tonne of minute but important detail you missed out.
Whilst I think that visual display of graphics is vital to achieve stakeholder buy-in, it is also clear that imprecise PPT-engineering masquerading as infographics is the worst form of management snake-oil there is. An erstwhile systems engineering mentor of mine used to say, “if you think they’re BS’ing you then ask them what the arrows mean”. 9 times out of 10 they won’t have a clue.
Although a recent article in SearchCIO alludes to competitive advantage by IT departments, arguments like this can take the CIO down a dangerous road. The holy grail of many CIOs is to run a department which is both profitable and also increases business capability. Mostly, however, IT departments are costly and the subject of constant complaint.
Can IT ever be a profit centre?
Economists have long argued that businesses should strip away overhead (i.e. not included in the cost of goods sold but pure overhead) cost chargebacks from business verticals and their processes in order to gain a clearer view of what is profitable and what is not. If they don’t then smaller, profitable processes are often in danger of being swamped with overhead. In this way, many businesses often outsource or cut the wrong activities.
It is notoriously difficult to cost IT chargebacks so that market verticals are charged just the right overhead. Should businesses charge their verticals for email? They often do but isn’t this just a cost of business that the centre should absorb? Isn’t the burden of communication and reporting largely placed onto verticals anyway? So if they could run their business units in a more entrepreneurial way wouldn’t the cost of IT be significantly reduced?
What if we extend that argument and let IT be a profit centre? Why don’t we let business units find cheaper ways of doing business and compete with the IT department? Security/integration/management time arguments aside – it is likely that if IT departments were able to charge for the thing they were really good at, this would be a source of competitive advantage within the business.
So, there is a good reason why IT departments aren’t profit centres but, of course, this doesn’t solve the problem of the high cost of IT inside business.
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?
- 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.
- 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.
- 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.
- 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.
In a recent article in CIO magazine Tom Kaneshige argues that the rise of BYOD spells the demise of the traditional Help Desk. He intimates that BYOD has now been overtaken by BYOS – bring-your-own-support! The network-enabled user, with access to huge volumes of information, requires a new Help Desk.
He is right that, ultimately, power-users need better, faster support delivered to them in a format and by people with a deeper understanding of the context and with more intricate solutions.
BYOS is the exception and not the rule.
Although the IT function is becoming more commoditised, the larger fields of knowledge work isn’t, hasn’t and won’t be commoditised anytime just yet. Otherwise, any 12 year old with a laptop would be in with a chance. Help Desks don’t need to be expanded but they do need to become more mature, agile and integrated into the KM procedures of modern networked enterprises (ie those businesses with a heavy KM focus). Expanding the remit of the Help Desk opens the door for colossal cost increases. Internal knowledge management functions need to become more structured beyond simplistic portals.
INTERNAL KNOWLEDGE MANAGEMENT
In a recent article in McKinsey Quarterly, Tom Davenport argues that organisations need to get a lot smarter in their approaches to supporting knowledge workers. He says that greater use of social media and internet use will harm the business more than help it. Lower level knowledge workers need more structured support to their processes. On the other hand, high-level knowledge workers are better supported by an open platform of tools. Getting the right balance is as much art as science.
BYOS is the wrong approach. It’s a derogation of KM responsibilities. Organisations need to focus on an approach to KM with the following structures:
- A good Help Desk function for knowledge workers involved in highly structured processes.
- An IT function which supports a flexible arrangement of tools for advanced knowledge workers.
- Knowledge Managers: people who provide the focal point for certain areas of knowledge.
- Portals: A single entry point for people seeking access to communities of interest.
So, be careful when thinking about Tom Kaneshige’s advice and “blowing up” your Help Desk. IT can be a self-licking lollipop. More tools and more information won’t necessarily improve productivity. At the lower level, sometimes it makes more economic sense to support the process. It’s only at the upper levels of expertise that it is more profitable to support the person.
The Perfect Storm for Cloud Computing?
There is no doubt that cloud computing is the technical elixir of our time. Unlike standard corporate virtualisation/thin client operating models the current technology provides 3 things in unison:
1. Huge processing capacity allows powerful software to run complex computations on very small devices.
2. Commoditisation means that there is a huge range of cloud-based software out there.
3. Commoditisation plus the simplicity of developer platforms has meant huge downward cost pressures.
Is this the perfect storm?
In order to create the perfect storm 1 additional factor would need to be present; Personal Virtualisation.
In order to create a competitive advantage through differentiation (particularly for professional service firms and other knowledge workers) the cloud computing offerings needs to provide for personalised virtualisation of applications or whole systems.
Although this is possible now it is not commoditised to the extent that it allows standard lay people the opportunity to take advantage of it. When this happens and knowledge workers can access highly specialised/customised niche apps through web browsers, then we can say that ‘cloud’ has come of age. http://ow.ly/jjc2F