• rm@rmbastien.com

The Complexity Factory

The Complexity Factory

Did you know that your IT function is a giant complexity-generating machine? Your IT teams don’t create this complexity on purpose, but they do it systematically and continuously. There are four ways that unwanted and unnecessary complexity is created: duplicating, over-customizing, re-inventing the wheel, and casting in concrete.

Supernumerary, Extraneous and Unwanted

In software-based solutions — and that’s what digital systems are mostly made of — you can click it, download it, resize it, or copy and paste it ad infinitum if you wish.  It is usually simple and often effortless. It is immensely powerful. It is also a double-edged sword if over-used or not controlled adequately.

The fact that your organization’s IT platforms are made of hundreds of distinct business IT applications is not a problem in itself — when the size and diversity of your business warrants it. 

But if you have two accounting packages, three customer relationship management systems, six order processing applications with your business data copied right and left, and cannot answer “one, just one!”, then your digital portfolio is a victim of the (unnecessary) complexity factory. The extent of unnecessary duplicates is worse than you think: under the hood of each of these systems, there are hundreds of smaller or more technical components that can be copy-pasted without appropriate control.

The ease with which systems and data can be replicated fuels the complexity issue.

You may have heard of different attenuating circumstances for the state of the complexity of your digital portfolio. But do not get fooled: read more about the over-used IT excuses regarding IT complexity.


The most prejudicial side effect of the malleability of software-based systems is that it is very, very easy to modify, enhance or augment. Although this flexibility is indubitably an advantage, it is subject to the creation of two types of problems.

Customizing Costs More

First, one has to remember that it takes time and money to change or uplift a software-based system. In many other fields, the paying customers have some minimal knowledge to help them identify if customization is a wise choice. But there is a significant knowledge gap when it comes to digital technologies.

Customization You’re Not Aware Of

I’ve never purchased a forklift. You know, that small utility vehicle that lifts and carries pallets of goods in a warehouse. If a lift vendor would ask me if I want a customized anti-UV paint on the roof, I would at the very least understand what paint is, what a lift roof looks like, where ultra-violet rays come from and I’d be able to ask a few questions about nature of the covering, its cost and more. But in the case of software-based technologies, the concepts are in general so obscure that often you need a major in computer science just to understand the question. That’s why the question is frequently not even asked and decisions are made without any conscious consent or true appraisal of the value.

Bells And Whistles You May Not Need

For conscious choices, the situation is no better. Businesspersons without sufficient technical knowledge ask for too many bells and whistles that are of questionable business value. They request these to a single-desk IT function that acts both as the trusted advisor and the internal vendor that will get paid an hourly wage to build the demanded features. That’s not a winning model to start with when trying to limit over-customization.

If It’s Customized, It’s Not Standard

The second issue is that customization is diametrically opposed to standardization. The more you customize it, the less normalized it is. Every penny spent customizing brings you further from reaping the benefits of having standard components. That’s why the decision to customize something must be based on hard facts about the actual value of it being different. In some cases, that could be the differentiating factor that makes your customer experience unique and leaves competition dreaming they had done the same. In many cases, often without you — the paying party — ever being aware of it because these adaptations are too technical, customization has no differentiating value.

Reinvented Wheels

The reinvention of similar technical components by your IT teams is a special case of duplication except that it is not based on the easiness of the copy-paste function: it requires time and effort. Reinventing the same things over and over does more damage to your business because not only do you end up with too many of the same things, but you burn gas creating them, losing precious time for more valuable work. This pernicious tendency to fall on re-invention rather than re-use has many roots: the sempiternal silos that plague your organization, the lack of quality documentation left by previous projects, non-standard practices, and anemic governance.

Cast in Concrete

In all engineering fields — including IT — creating systems in which parts are easily unplugged, dismounted, removed, or replaced require more up-front thinking. That means more time spent cogitating before building. That means relentlessly standardizing. People who are judged solely on the attainment of short-term objectives cannot see much further than the next phase of the project they’re currently working on. Spending time thinking is in direct conflict with such an objective. Standardizing requires additional effort to define, communicate, enforce, and refine the norms; that too takes time and is at odds with short-term delivery.

It’s usually more profitable in the immediate future to take a few components, pour cement over them so that they can hold, and leave the thinking to the future generations that will deal with removal.

The result over time is catastrophic: hundreds of technical components that are unmovable without titanic efforts. Labeled as legacy IT, these systems stay where they are for years, even decades, creating huge liabilities to an organization’s capacity to evolve quickly. And don’t go thinking that it applies to the past; legacy is being created today as you read this.

Not By Design

Creeks pour into rivers that flow to the sea. No one ever designed the waterway courses of a given region: water simply follows the slope of the terrain it falls on. The IT complexity factory was never the result of conscious design; it just happens because the engagement model leads there.

There is a slope on the corporate IT shop floor. It funnels all the busy geeks and their work into a certain direction: the route of creeping complexity.

Why is this happening again and again, across industries, geographies, and time? People, like drops of water, take the path of least resistance. To get to the bottom of it, you’ll need to understand what’s wrong with that slope, and then do what’s necessary to get it leveled or have the penchant in the right place. The next step in your journey is to understand the structural issues in the engagement model that block any improvement.

Before going there, we need to clear some false root causes that have been over-used as excuses for this creeping complexity: NEXT…

Follow me: