What future working software must look like

Let’s think about what software might look like in the future, if it is designed for the purpose of helping someone do their job better.

So it is a tool, just like a carpenter or plumber has a box of tools, an oil and gas production engineer, or building facilites manager, has a box of digital tools to help them to do different things.

In this thought experiment we are going to try to throw away any ideas about what software should look like, or how we are going to sell it, or what the IT department are comfortable with, or what the customer expects, or what Mr IT Geek believes is going to ‘disrupt’ or align with the expansion of Moore’s Law.

Put all that to one side.

Here’s my answer.

There will probably be a range of different software tools to do different jobs. Work out what is happening, analyse some data, understand things a bit better, see if a task if worth doing right now.

All of these tools might be accessible from a kind of app store, and be continuously iterated and developed.

Beneath that, there will be a robust data platform where all the data which the customer might want is gathered together.

Integration and interoperability is not going to be a headache, so we’re probably talking about data exchange, data model standards, or some kind of API exchange.

The system is probably designed for a business which works in a certain way and has done for millennia. So the core logic of the domain is modelled into the system.

And running the whole thing is pretty inexpensive. The data platform and standards, once built, don’t cost much to keep running. Development work goes into the apps on an experimental basis.

Based on some interesting presentations at the ITF Technology Showcase this week, many companies, including BP and McLaren, can see the benefit of a customer driven digital system, where the person doing the work gets a digital environment where they can get everything they need, access to all the expertise they need.

But the systems being developed by McLaren and BP are probably pretty expensive. Perhaps it can be done much more cheaply.

Above all we have to get beyond the traditional tropes of software – installing complex packages, installing what we know about, complaining about ‘users’, struggling with data integration, bamboozling people, and get to something simple and straightforward and inexpensive, just like the physical tools in your tool box.

Is this a sensible direction to be thinking about?