How the wrong technology can cause nightmares
Just because a certain technology is popular doesn’t mean it’s suitable for every situation. Whenever you get all excited about the latest new thing, it’s important to rationally evaluate if you need to adopt it. In this article, Richard Gall goes over the nightmare scenarios that can arise from jumping on the latest bandwagon and how your organization can avoid them.
In the Wallace and Gromit animation The Wrong Trousers, plasticine inventor Wallace creates a pair of mechanical trousers that allows the wearer to walk on surfaces that would otherwise be contrary to the laws of physics. Up walls, along ceilings – Wallace’s trousers were a remarkable technological feat for a man with an already impressive track record of inventions.
The results, however, turn out to be pretty nightmarish. When Feathers McGraw (a criminal that also happens to be a penguin) steals the trousers for his own nefarious ends, everything begins to fall apart.
The Aardman animation is actually a great example of how the wrong technology can cause some pretty nightmarish scenarios. Of course, Wallace’s trousers weren’t intrinsically bad or disruptive. In the right situation, being able to walk on the ceiling could have been pretty useful. In the wrong hands, and deployed in the wrong way, technology can have pretty disastrous consequences.
Its impact can be felt in a number of ways:
- It makes life harder for people in the workplace – both engineers and non-technical people.
- It can impact customers and users that want – or need – to buy products or use information.
- It could open up new issues around privacy and safety – if information is lost or exposed.
- It can cost big, big money.
There are, broadly speaking, three ways in which the technology can cause significant problems.
- Out of date technology
- Poor migration planning
- Moving to unnecessary solutions
Let’s start by looking at what happens when you fail to keep up.
SEE ALSO: Learning from DevOps nightmares
Nightmare scenario 1: Out of date technology
The first is failing to keep up to date with changes and opportunities. This could be anything from failing to update legacy systems to pure complacency.
A great example of this is the continued dominance of Excel inside many organizations. Now, don’t get me wrong, Excel is a perfectly fine tool for working with data – up to a point. But when you begin relying on Excel for managing huge datasets on products or customers, you are going to run into some problems.
At a basic level, it’s a huge productivity nightmare – no one wants to upgrade their RAM just to open a spreadsheet. But it also could have repercussions for both security and governance.
Bob Katz, a former IT consultant, told me about a particularly bad experience he had doing work for a public mining company. “I was originally brought in as an Excel ‘expert’ to fix the earlier implementation but it was clear me that Excel was the wrong tool for the organization. Excel files were being distributed worldwide without version control, no reconciliation to the accounting systems, Excel errors etc.,” he told me over email.
Why was the company even using Excel? Katz explained that it was because “Excel is a ‘common language’ within the Finance organization, both at Corporate and the operating units in Brazil.” So, essentially, it’s a question of comfort – and, to a certain extent, some ignorance about other potential options.
For Katz’s client, the whole episode really was a nightmare. They spent “6 figures” on an “unworkable solution that had to be scrapped,” only to later implement a SaaS solution that was, by Katz’s account, a success.
“We were able to sync and reconcile with the company’s Brazil operations to convert from Brazil GAAP to Canadian GAAP and eventually US GAAP and IFRS reporting standards, all within the same application. We were also able to report and analyze operational metrics as well. We were also able to put together multiple forecast and Budget versions variations of gold price, operational changes, headcount, capital planning etc. and compare to previous budget/forecast versions.”
There are plenty of similar stories out there. Alan Santillan, who experienced struggles with Excel while working for a U.S. healthcare organization, said, “Using Excel as an alternative to dedicated business software not only limits productivity but also increases employee frustration and quality of life.”
Both stories are small scale stories about technological complacency leading to organizational nightmares. However, there are plenty of very public examples where complacency has been lethal. Just look at Blockbuster. This was a company completely unprepared for the impact of technology, only to be outfoxed and outmaneuvered by Netflix, today one of the most popular entertainment brands on the planet.
Of course, the Blockbuster scenario was much more complex than a frustrating inability to see beyond Excel spreadsheets but nevertheless comes from the same kind of culture that refuses to be curious about technology. Ironically, this conservatism can’t stop change – it will cause significant internal pain or it will completely put you out of business.
Nightmare scenario 2: Moving to the wrong software
If getting stuck on the wrong software – or forgetting to even think about it – can cause problems, so can moving to the wrong software.
This sort of scenario comes out of a completely different organizational culture – one where people are forced to make decisions ‘just because’ or because changing things is better than remaining stagnant. It’s often an attitude that develops out of a fear of the previous scenario. Rather than being complacent and conservative, curiosity and experimentation come to be valued for their own sake.
Many people have been in this sort of situation. Today, this is perhaps even more common than being hampered by conservatism. Many people have stories of CEOs reading about big data or microservices (if they’re a little more technically aware) and immediately slapping down requests on the desk of their CTO.
It’s not hard to find examples of this. Perhaps the best example was the NHS IT project, NPfIT, which was billed as the largest public IT project ever. The idea behind it was to centralize patient information, and in doing so making all aspects of the NHS much more efficient. Ultimately, it should have improved the patient experience. The frictions between medical institutions would have all but disappeared with this system.
A noble pursuit, perhaps. Ultimately, the project failed simply because it was not implemented properly. According to a Guardian article from 2013, this cost an eye-watering $10 billion.
There were a whole host of reasons that the implementation failed, but the crux of the matter was a total lack of alignment at every point. From government to contractors all the way down to the doctors and patients it was meant to serve, the solution (which gradually developed into a complex Frankenstein solution with a lack of leadership and vision) was ultimately nothing more than a dream around which people were retrofitting solutions.
True, the challenge here was as much cultural and strategic as it was technical, but it’s important to remember that the strategy was ultimately defined by a flawed understanding of the software at the center of the project. There was a complete lack of understanding of what planning and support would be needed in order to make it work.
Often, that is precisely the nightmare. It’s not the hyped software that’s the problem; it’s the fact that the software becomes shorthand for a great solution! Causing everyone to ignore the various facets needed to adapt it to their own needs and goals.
SEE ALSO: How to stay ahead of the data tsunami
The NPfIT is a great example of technological solution bloating like the decision-making infrastructure around it, but it’s also worth looking at something much more up to date. I’m thinking here of microservices, but you would probably find something similar in the case of other trends like artificial intelligence and blockchain (don’t get me started on the trouble blockchain can cause).
The problem with something like microservices is that they are actually incredibly useful. They are appealing to people who find themselves facing development challenges and tricky pieces of legacy IT. But they’re not incredibly useful to everyone.
It’s easy to see, however, how the decision to make the architectural change comes about. Say your current website is slow and your developers hate it. Making changes feels glacial – while it is making money and you seem to be growing in the right direction, you feel hampered – maybe like you’re sitting in nightmare scenario 1.
You read about the operational efficiency that microservices seem to offer; you find that all the Important People in the industry are talking about them. The whole concept just makes sense.
Before you know it, you’ve sent your engineering team (which has now doubled in size because you need the resources) down a microservice rabbit hole, where just about every aspect of your business has been re-architected into a microservice that is plugged into your site. After 18 months of pain, it becomes clear that the whole project was pointless and a colossal waste of money.
You’ve landed yourself in a true technical nightmare and you’re not sure why. You should have taken Martin Fowler’s advice: “Don’t even consider microservices unless you have a system that’s too complex to manage as a monolith.”
Avoid nightmares: Be technologically mindful
In talking about all these nightmares, it’s easy to feel like you’re going to run into trouble whatever you do. To a certain extent, that’s probably true; it’s inevitable if you’re working with software. However, there is a middle path you can take to avoid the sorts of situations like the ones mentioned above.
This is a path that is always mindful and alive to the opportunities new technologies might offer but is also attentive to business goals as well as the needs of people. If you can do this, you can avoid stagnation and also avoid diving down a rabbit hole from which you can’t escape.