Beware the application complexity monster

Posted by

How many new applications, tools, devices, and cloud services have you introduced into your environment over the past few years? Now think about how much you got rid of over that same period, i.e. how many things you decommissioned. Not such a big number, eh?

This is just one example of how complexity creeps up on us. We accumulate more stuff over time – sometimes for good reason, sometimes because it’s easier to add something new and live with the technical debt than disturb what’s already in place. Either way, it all needs to be integrated and managed, and the larger and more complex your environment gets, the more difficult this becomes. It also makes it harder to keep up with change and enhancement requests and more generally deliver a good user experience.

But these principles don’t just apply to enterprise IT environments: software vendors and cloud service providers are subject to them too. If your application suppliers, for example, don’t manage complexity, redundancy and technical debt, their overheads increase. That can mean fewer resources available for R&D and customer support, and possibly even higher prices. Not good for customers, who are also likely to experience more failures, inconsistencies and arbitrary constraints, including things not working as you would expect or in a seemingly illogical or overly-complicated manner.

Software that has been around for a long time are more prone to such issues, especially if the vendor has experienced rapid growth, has made significant acquisitions, and/or has had to pivot because of changing markets. The danger is always that in the rush to market, new functionality is layered on the old, and there’s never the time or money to properly rebuild, dedupe and harmonise.

Complexity’s clues

One giveaway is an admin console that dictates different ways to do essentially the same things depending on which part of the system you are managing. Another is being forced to bounce around a complicated menu structure and make changes in several places in order to achieve something quite simple. If you find yourself muttering “It shouldn’t be this hard”, your pain is very likely a legacy of historical thinking, short-cutting and compromises.

If you administer systems such as Salesforce.com or Office 365 you’ll know how it is. It takes significant training and/or a lot of trial and error to understand the complexities, inconsistencies and dependencies, and ultimately tame such environments. Sure, it keeps IT professionals in work, but most would prefer to spend their time on more useful and rewarding activities.

To be fair to the vendors, established customers are often displeased when platform and architecture changes force costly and risky migrations. However, both customers and suppliers can only put off such changes for so long before it becomes very difficult to move on.

Taming the monster

The lesson is to consider complexity when making buying decisions or reviewing existing systems. Complexity isn’t bad per se – it’s often needed to deal with more demanding requirements. It makes sense though to stop, think, and beware of the kind of complexity that causes cost and constraint while adding no real value.

For a deeper discussion of what to consider in relation to solution complexity when making buying decisions, download our paper entitled “The Application Complexity Monster“.

Leave a Reply