About 13 years ago, I found myself trying to get people to understand why it would be beneficial to use a services-oriented architecture in the work we were doing to build business systems at BBC Worldwide. It was a tricky task, because whilst it all felt right from a technical purist perspective, actually adding in the additional cost of building things for an unknown future was extremely challenging, and short term pragmatism often won out.
If, back in 1999, I’d argued that by 2012 people would use pocket and tablet computers to access internet-based services with almost as much frequency as desktop computers, and that we’d see massive fragmentation in the source of those devices with Microsoft amounting to about one third, Apple a significant proportion and Google making up the significant rest, I’d probably have been regarded as a lunatic. Remember, in 1999 the cutting edge of mobile computing was the Nokia 7110, and Google was only just celebrating its first birthday.
This hindsight has struck me in recent weeks looking at how companies are trying to make sense of the browser+apps world that we are living in. In a purist model, the ideal would be to have a cloud-based set of services that could be accessed by multiple clients – with apps and websites being functional layers sitting above those common services. Something like the way that, say, Twitter or Facebook work.
The reality of most established organisations, however, is far less clean. In the retail sector, for example, it will be common to have well-established (and probably fairly aged) logistics and stock systems, a website that will be tied fairly closely to those back end systems, and then new innovation happening that will do all sorts of magic to suck data out of the existing website. It’s quick and dirty, and usually involves building up some sort of “technical debt” – cheap decisions taken today that result in potential problems in the future.
Root-and-branch architectural projects to make things right are challenging, though, because they are costly, have the danger of going down all manner of technical dead-ends, get sidelined into using new and unproven technologies, and ultimately will often deliver services that are the same, or slightly worse, than those that existed beforehand -a stack of reasons why they are often avoided.
Expediency must always win out – but it is possible to hold on to a technology vision that can help shape short-term decisions to make sure that technical debt is managed in a controlled way; in my last role there were are number of decisions about sequencing of projects that meant that I took some risks in the short term to deliver meaningful business benefit that gave me the credibility and trust within the management of the business to then fix some of the underlying infrastructural issues. Moving to a cloud-based collaboration platform before replacing the aged network infrastructure was one of those risks, and it meant that we delivered something visible and of meaning to everyone before getting into a long and expensive project that, to our colleagues outside of IT, only really meant disruption and cost.
The alternative to the controlled management of technical debt is what in the past I have described as the “organic ostrich”. That’s where systems and applications are allowed to grown and multiply for the short term in an “organic” manner as the senior IT management firmly ram their heads into the sand…
(Thanks to @thebeebs for the chat that made this bloggage happen.)