The world is full of bad technology
Spoiler alert: your company’s IT systems are bad.
Okay, let’s moderate, ameliorate, and validate that comment slightly: your company’s IT systems are not as well engineered, planned, architected, deployed or operated as well as they could be.
Systemic silo systems
There are many reasons for this inconvenient truth. One of the key culprits is the existence of silos.
So-called IT silos are applications, databases, network transport channels and other ‘chunks’ of technology that have been put in place with the best of intentions, but now represent a problem.
Some silos exist due to their age. These are legacy systems that still perform a useful task and so are still used as part of the working IT stack that the organization operates with every day.
Some silos exist as a result of poor planning. These are chunks of technology that may have originated before the era of cloud and near-ubiquitous connectivity. They may never enjoy the benefits of being fully integrated into the ‘total fabric’ of the modern IT network.
Some silos come into being simply because of bad IT architecture.
To make matters worse, the employees who designed and built the internal mechanics of these systems have now left the company and they failed to ‘annotate’ and document the systems they built during their time running them.
Digital gangland segregation
Whatever the reason for their existence, IT silos can be thought of as ghettoized blocks of monolithic system functionality.
Because there’s no hopping from one ghetto to another (it’s digital gangland segregation for real), we end up with a stilted company whose resources can only move up or down in one direction at any one time.
This restrictive nature of IT silos means that the company can’t be agile, can’t re-engineer quickly when new market opportunities arise and can’t move in any more than one single ‘plane’ of movement.
Innovation is stilted and profits are eventually hit.
What silo-based IT systems lack is orchestration and connected intelligence.
Yes, we now have the advantages offered by Machine Learning (ML) and the Artificial Intelligence (AI) systems that it drives, but unless we architect and build IT systems with an inherent openness for higher-level (eventually neural deep-learning driven) intelligence, then we remain in the gangland ghetto of monolithic mediocrity.
Deeper into the badlands
These problems are real. So far we’ve presented the high-level system-wide view, but you only have to look inside an application itself to see that an equal and opposite ‘bad factor’ is playing out… and architecture is once again to blame.
One app talks to another app (or another smaller component of data, or service) through an Application Programming Interface (API). Without forcing you to take Computer Science year one in full, you can think of APIs as the ‘glue’ that bind our world of web-connected computing.
But not all APIs are created equal; there are good APIs… and then there are bad, clunky, inefficient and altogether poorly architected APIs.
Bad APIs can be too chatty, that is – the software has to ‘call’ another piece of data too many times in order to find the information it needs.
Bad APIs can be too bloated, that is – the software makes its data call but takes too big a bite and comes back with the required information, plus a whole load of extraneous information that is essentially surplus to requirements.
Bad APIs can be ones that scale upwards really badly when the IT system needs to handle more users or shoulder a higher degree of data input. These nasty critters end up slowing down your entire IT stack if they exist… and they do exist.
There’s a whole bunch of other API misdemeanors and transgressions, but whatever form they take, they form part of the bad (or at least less than perfect) components of IT that populate all of our IT stacks today.
Is there a way forward or are we all condemned to run on bad IT systems for all eternity? The answer, as always, is yes and no.
Yes, we can address legacy silos as we re-engineer for connected cloud, but it’s a zen-like one brick at a time process, there is no rip-and-replace overnight fix.
Yes we can build better APIs and connect our internal system components together better, but it’s an ongoing Sisyphean challenge and there’s no room for laziness.
It’s also no. Some of these problems will always exist. But as will all evils, admitting we have a problem is the first step to resolution.
Sometimes it’s bad in IT, get used to it.