Up until C19, I would have said the biggest existential threat to our clients was large systems implementation. Large systems implementations have brought two of our clients to their knees in the last 5 years and a poorly implemented system continues to plague a third client that cannot afford the capital investment to replace the ailing system. Since I’m sure you’ve read enough about C19, let’s look at an alternative to large systems implementation, diffuse IT.

The key element that we as business owners must manage is one that doesn’t get much airtime at all, complexity debt, sometimes referred to as technical debt. I’ve mentioned it before, complexity debt is the future cost of maintaining systems or processes you put in place today that is related to the complexity of those systems or processes. For example, we all know an organization that has a savior figure in IT that does all the programming and keeps everything running on an ancient platform. Ostensibly, the cost of this combination of talent, hardware and software, is low. That guy’s or gal’s salary, the old, cheap hardware, and the software is essentially a portion of the salary. The complexity debt here is what happens when that person is taken out of the picture. The system, in all its complex glory must be maintained by someone that hasn’t seen it or upgraded to current technology that isn’t obsolete and unavailable. The bad part about complexity debt is that while we all think we can plan for it, it has a nasty habit of coming due when we least expect it. Accidents happen, people die, global pandemics happen and just during another crisis too. And since there is no way to accurately calculate complexity debt, we have no idea what the capital requirement of that event will be.

The goal here is to avoid accumulating complexity debt. It is measurable strictly speaking. You have to measure the magnitude consistently and be satisfied with a consistent measurement rather than a precise one. Large scale ERP systems with lots of bolts on and tight integration to other systems have high complexity debt. The system itself has complexity debt related to changes and “enhancements” that the developer initiates or demands that may not be compatible with your strategy. And the tighter the systems are integrated, the higher the complexity debt. A change in the main system causes ripples and requires changes in the auxiliary systems some of which may not be so auxiliary. And those ripples have to be coded away by someone inside the organization or inside by a vendor – and all that costs money.

This is where Diffuse IT comes in. Simply, diffusing Information Technology (IT) people, processes and technology (hardware and software) throughout the organization can reduce complexity debt by reducing the size of each implementation or computing node in the business. In theory, each one is small enough that if it fails or becomes obsolete, it won’t be a material challenge to the business. A classic move in this direction is to limit the functionality of an ERP-type system to data collection and to create a data lake of information about transactions that can be accessed by many applications across the organization. The ERP is reduced in complexity. The data lake can be restructured to meet evolving needs of the organization with minimal, if any dependence on the ERP system’s function and apps that take advantage of the data lake can be small(er) and easier to understand, develop and maintain. Problem solved, right?

As with all things where we make progress in business, we don’t get to stop managing. We must manage something else. No gain comes without unintended consequences.

My first consulting gig was coding a harness racing handicapping system on the TRS-80 computer system for a professional gambler. Most of the project was straight forward if not tedious math. Not knowing better though, I agreed to provide a sophisticated field entry user interface. This taught me some very valuable lessons; user interfaces can be way more than half of a development project, you should control scope with a written agreement, and user developed applications can have very naïve assumptions about the way the world works. I think I earned about a dollar an hour on that project. But it led to another project and eventually to a career in consulting.

That project also taught me that you can put something together that looks sophisticated, but the sophistication is completely independent of the fundamental math under the hood. I could just as easily develop something that looked great, but in which the math didn’t work. That is the challenge of Diffuse IT. As applications and professional developers get more sophisticated, the issue of under-engineering is less likely to occur, but the users of these systems must be prepared to test the math. They don’t substitute for expertise in the business side of things. And this goes doubly for anything developed by users with end-user computing tools like app development tools. The people developing these apps/systems must use software engineering principles in testing these systems and they need to be tested and audited like any other system the business relies on. Here is where complexity debt comes back. Hopefully in smaller, controlled quantities, but these systems must be audited and maintained to avoid kicking the complexity can down the road… or worse, generating false results that the business relies upon for decision making or operations.

Done properly, this approach can eliminate the single point of failure that is the all-knowing IT guru that everything depends on and instead infuses IT knowledge and processes throughout the organization in autonomous bite sized chunks. But take care to make sure that the complexity and reliability of all the systems the organization relies upon are understood and managed.

Call to Action

Here are some obvious steps to getting started toward a Diffuse IT strategy:

Review the organization’s systems architecture and applications map for complexity risk.
Develop a plan for diffusion of IT throughout the organization (this could take a decade to finish properly in a large organization.
Acquire talent and systems and develop applications in concert with a diffuse IT strategy.
Review the systems strategy, design, implementation and operation to ensure that complexity debt is managed from start to finish.

Here’s a link to Digital Disruption: Unleashing the Next Wave of Innovation Hardcover by James McQuivey. And here’s a good article from Forbes on Complexity Debt.