What’s hiding in your technology sock drawer?
Photo credit: Addy Mae on Unsplash
If you celebrate Christmas, I hope that you got some good presents. But you may also have got some presents that seem fun for a few weeks, or a few days, or a few hours and that you then put away, never to take out again.
In the fascinating podcast series Gamecraft (https://www.gamecraftpod.com/), Mitch Lasky and Blake Robbins explore the history of the video game industry. I learnt a lot from this series about the economics and history of video games, as well as the way that the behaviour of developers and players has shaped and been shaped by games. I recommend listening to the whole series, but there’s one concept that particularly stuck with me: the idea of ‘sock drawer ware’.
This is consumer technology that appears to be a good idea, and that looks like it will gain a committed, sustained audience, but ends up in the sock drawer after a few weeks. (This term crops up in the episode about virtual reality - sorry VR people, but this seems like a good way to describe the repeated waves of enthusiasm and indifference that have greeted developments in VR. Perhaps this time round it will be different.)
There is a lot of sock drawer ware in the field of enterprise technology too. In fact, there’s so much that it’s convenient to contract the term to sockware. If you are responsible for the architecture, operations, development or leadership of technology in any large enterprise, then you know that your metaphorical sock drawers are bulging with solutions and components of dubious value.
I know that in my career, I have been guilty of buying and building sockware.
Back in the first waves of excitement about Service Oriented Architecture (SOA), I deployed Enterprise Service Bus (ESB) technology that was supposed to make integration simple, connecting systems and transforming data. It became another semi-smart pipe which imposed overhead on the few systems that used it, and was avoided by most others.
In a period of enthusiasm for single customer views and data consolidation, I was part of a project to implement a customer Master Data Management (MDM) solution. Like most such solutions, the idea was that it would work initially as a data aggregator, and then become the true master, propagating reliable data to downstream systems. As this is not Doctor Who or Star Trek, we never figured out how to reverse the polarity, and the data only ever flowed in one direction.
And, of course, I have built each of the generations of solutions that aimed to solve the persistent problem that we gather data in many places, but want to analyse it all together: data cubes, data marts, data warehouses, data lakes and data fabrics. I think the success rate of these solutions has been about one in three, if I am generous.
As these examples show, in the field of enterprise technology, sockware has a more profound impact than that of a novelty Christmas present: if it is deployed in any way at all, it takes up more than space. It consumes cost, effort and attention, and becomes part of the cruft and complexity that makes the architecture fragile and difficult to change.
Is it possible to avoid sockware in enterprise technology? We encounter new developments in technology all the time, and I think it is right to be enthusiastic and excited about them: it is part of what makes technology valuable and fun, and we shouldn’t forget that many innovations are successful and have shaped our world. Developments such as touch screens, mobile networks and the Internet itself all had the signs of sockware at some point in their lifecycles, but are now fundamental to our lives.
However, while I doubt that we can prevent sockware entirely, but I think that we can do more to try to spot it when we see it. When we get excited about new technologies, we often conduct exercises that we call things like proofs of concept, experiments or pilots. These terms make it sound as if we are conducting considered research, with well defined parameters and conditions of success, that will lead to an objective conclusion about the value of the technology. In reality, we know that these exercises are often intended as the first phase of adoption, that the chances of that adoption being paused or abandoned are slim, and that we won’t find out whether we have sockware or a valuable component of our architecture until we attempt to scale.
Perhaps we should take these stages more seriously, and conduct them in the spirit of the ‘science’ part of ‘computer science’. We should use them not just to discover whether technology works (it usually does), but also to measure its cost, ease of adoption, ease of operation and likely value. We should be prepared to say when a proof of concept, experiment or pilot has discovered sockware - and we should be pleased about this discovery, because it has saved us cost, trouble and disappointment.
This approach would be no fun at Christmas: it would require honesty too brutal for a happy family occasion. But in the field of enterprise technology, that honesty may be the best gift we can give ourselves - and the best defence against sockware.
