Information versus the silos

IT’s raison d’être

Lab The idea that ‘information is important and we want to do more useful things with it’ transcends technology by virtue of it having been true long before IT vendors wanted to talk about it.

However, technology does have a key role to play in helping us exploit the information in our businesses, not least because of its ability to help us capture, sort, filter, transform and generally make sense of vast quantities of it.

To date, much of IT’s contribution in this area has traditionally been covered by ‘BI’ (business intelligence). However, the image of lofty software projects designed to provide retrospective reporting to senior business leaders does not hold as much appeal as it used to: many organisations already have such investments in place, while others feel they are too small to consider it.

That said, the most important reason that ‘the BI story’ doesn’t hold sway today is because the conversation has moved on.

It hasn’t failed; it just doesn’t hit the mark when we think about what really matters today when it comes to making the most of our information assets: getting it into the hands of people at the coalface to help them make better decisions. Many have called this the ‘democratisation of BI’. Call it what you will, but what it embraces is everything involved in capturing, cleaning, transforming, transporting and surfacing information where and when its needed.

The idea of managing information with this simple premise in mind asks some serious questions of how we’re arranged today from an IT point of view, and of how we capture or prioritise requirements from the business. The traditional technology silos and teams into which many organisations are divided may work very well independently. However, they do not easily allow the higher levels of flexibility and responsiveness we need to optimise the way we deliver information - for example, to allow a sales person to pull together several disparate data sources to answer a question asked of them only 5 minutes ago, or to enable an alert to be sent to a product manager immediately after an event at the call centre took place, preventing his customers from renegotiating their mobile phone contracts.

The answer is not ‘another software application’, but a more general focusing of capabilities across a number of disciplines, namely: information management (IM) - making sense of the information necessary to support decisions and ensuring that it is available in the right form when required; business process management (BPM) - defining business context and rules to make sure information turns up in the right place at the right time; and service oriented architecture (SOA) - making sure that all of this is done in a consistent and reusable manner.

In organisations where such disciplines are treated as separate and discrete, an important success factor will be in breaking down some of the boundaries between teams. If any of the three disciplines highlighted are not formally recognised in your organisation it’s not necessarily a problem because the prerequisite is not actually being expert in technology acronym soup, but in having a structured way of analysing, designing and implementing solutions that acknowledge the process view and service view, as well as the data view.

The important principle is that, if improvement programmes are seen ‘only’ as information management exercises (even though this is where much of the work will typically be required), the full benefits of a more holistic and architectural approach will not be realised, restricting improvements to ‘incremental’ rather than ‘transformational’.

So where do we start if we’re going to revisit the way we think about exploiting information? The benefits of doing all this are gained from getting ‘more than one thing’ working together, which, means, initially at least, getting the right people collaborating with each other.

If information delivery is the goal, the ‘your stuff and my stuff’ mindset will have to take a back seat. We’d be keen to your thoughts on how much the traditional siloed approach to technology and teams may be a hurdle to the horizontal flexibility we need to address this area, not least because if making this stuff better isn’t IT’s (collective) job, then what is? ®