Into the Labyrinth – The Sources of Complexity

In the first entry of this five-part blog series, I laid the groundwork by diving into the complexities that are all too common in enterprise networking, underscoring the pressing need for simplicity. Then, in my second post, I highlighted the multiple costs that come with these complexities, focusing on both the financial toll and the burden on our human resources.

Before we talk about solving the problems caused by complexity identified in the last post, we should understand how we ended up in this tangled mess in the first place. Let’s dive into the sources of complexity that comprise this technology labyrinth in which we are caught.

Inherent Complications

It’s not hard to envision complexity arising as simple systems expand, merge, and take on more tasks. It seems as if complexity arises as time goes on. This is the natural, expected outcome of any system’s growth. It’s inevitable, even desirable, and a sign of maturity. This could imply that simplicity is a lack of sophistication, a lack of design, or intricacy. But what if the opposite were true?

When I discuss the pitfalls of complexity, I want to clarify that I am not advocating for oversimplification. Any extensive, multi-layered, and expansive system like enterprise IT naturally possesses a foundational level of complexity. Requirements, constraints, and stakeholders are numerous and frequently at odds. For any specific outcome desired, there are endless variations which can be implemented, rooted in diverse underlying technologies. Intelligently architecting a system is a skilled discipline which takes years to master, and no system exists in isolation. 

The touchpoints between systems, where technology stacks and vendors intertwine, are a hotbed of emergent complexity. Nor are systems static; the passage of time introduces changes unforeseen during design, necessitating adjustments as requirements evolve. When observed holistically, the IT footprint of single organization more closely resembles a constantly shifting geological landscape, as opposed to a tower built according to a blueprint. 

Furthermore, the individual technologies that comprise a larger system are inherently complex. They frequently involve advanced mathematics, applied physics, multiple layers of abstraction, and are implemented in a polyphony of languages. One might devote a lifetime mastering just one small slice of the technology spectrum. That being said, even though a system may inherently be complex, we can still simplify a lot of it and prioritize user-experience and efficiency.

An Intent Translator

Consider the last time you flicked on a light switch. Behind that simple action lies a vast and intricate infrastructure, yet you likely took it for granted. Did you think about the source of the electricity or how it was generated? How about the transmission and storage systems necessary to deliver the power to you? Maybe you thought about the multi-tiered metering, billing, and market system that that determine your charges? No? What about the operations teams, the regulatory and standards bodies ensuring interoperability? Chances are, you didn't. But you see where I'm going with this.

The system behind the light switch is crafted so that you can convey your intent effortlessly and attain the desired result. It translates your intention to illuminate the room into an orchestrated, intricate process that flows through a tremendously complex system, all without burdening you with the details of its operation.

In fact, when you stop to think about it, many of the systems we use every day are gnarly, tangled webs of complexity, and we're often blissfully unaware of their inner workings. Our vehicles, transit networks, financial institutions, and even the device you’re using to read this blog all function seamlessly while hiding their intricate processes from us. As humans, we’ve mastered the art of simplifying immensely complex systems, built over generations by teams of trained experts, so that even a layperson can reap their benefits.

Although problems are complex, the solutions should be as simple as possible. Yet, why hasn’t information technology (IT) realm adopted this approach? What is our counterpart to the elegantly simplified system that operates behind an ordinary light switch?

Emergent and Habitual Complexity

“Life is really simple, but we insist on making it complicated.” — Confucius

Unnecessary complexity adds friction throughout the technology lifecycle. But where does it come from? By examining the source of the problem, we can better understand how to address the cause rather than the symptom. So, let’s explore a few of the primary culprits behind needless complexity in the IT industry.

Systems Matching Organizations

There is a well-known adage among programmers called Conway’s Law. It states that:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

How does this make things complicated? When corporate silos and bureaucracy prioritize their specific domains, and lose sight of solving customer problems, it's evident in the products and services. When I was a systems administrator, one of my great frustrations was dealing with major vendors whose own products didn’t interoperate. What's more, some had overlapping functions dispersed among several products, yet none were entirely adequate for the task at hand. This leads to an unnecessary accumulation of disparate devices and services, raising management overhead and adding more interaction points. 

Now contrast this with a small startup, where every employee is relentlessly focused on solving customer problems. They don’t possess the luxury of an established install base and steady cash flow - it’s sink or swim. This lack of internal distraction is part of why startups can so often out-innovate a larger company with an impressive track record and a large stable of brilliant engineers. It’s about focus. 

Growth, Organic and Otherwise

It’s almost self-evident that as companies and systems grow, they become more complex. The swifter the growth, the more challenging it is to contemplate the long-term consequences of organizational design and interaction. Startups are notorious for their rapid growth initially, only to later bloat into the same kind of disorganized bureaucracy that they once triumphed over when they were lean and focused. 

Mergers and acquisitions complicate things even further. Disparate organizations, each having accumulated layers of technology over the years, are suddenly expected to function as one cohesive unit. Wall street often demands swift results, intensifying the impulse to rush ahead without fully evaluating technical redundancies and the respective strengths and weaknesses of each company’s technical framework. Often, existing systems from both of the original organizations remain with intentions to be “sorted out later”. Give the emphasis on revenue and growth, one can imagine the usual delay in addressing these issues.

The paradox of this growth is that the faster an organization expands, organically or otherwise, the more they are piling on layers of complexity that will in time hinder that very same growth. 

Architecture vs. Corporate Reality

Throughout my career, I’ve had the privilege of meeting amazing systems architects and engineers. These professionals approach their work with depth and consideration, often holding very strong opinions on how to tame complexity. They dedicate their time thinking of sustainable, systematic strategies to build systems that will give their business the agility and results they seek, in the most efficient way. 

Unfortunately, these plans rarely come to fruition as envisioned. Why? Office politics, shifting priorities, and purchasing departments focusing on the less crucial aspects of the “iceberg model” are some of the challenges faced. Additionally, a widespread lack of broadly-focused decision making further complicates matters. What usually occurs is a piecemeal adoption of a design, a band-aid approach, or even competing implementations by different departments. This leads to duplicated work, incompatible data silos, and wasted time. Without considering broad view, complexity can quickly spiral out of control. Once in place, it’s much harder to fix. 

Have it Your Way

In the world of consumer technology, applications and services are usually sold “as-is”. If I really am displeased with an update in an app’s interface, my ability to change it are usually non-existent. Unless I take the drastic step of buying the platform, like Elon Musk might, getting my desired features implemented is a long shot. 

In the enterprise IT world, the opposite is true. Companies frequently demand extensive customizations, not just in products but also in the associated “glue” and middleware. Why? Usually because it’s easier to demand that software fit an organization’s structure and policies, rather than reorienting the business to use a tool most efficiently. 

Yet, with every tweak and custom modification, we often add complexity. This makes our work more challenging. Deviating from the system builder's design and intent means support becomes more difficult. It requires more specialized knowledge to operate, and interactions with outside systems might not function as planned.

Who is Benefiting?

“Simplicity is a great virtue, but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” — Edsger Dijkstra 

Not everyone wants things to be easy. Overwhelming complexity, or at least the perception thereof, can benefit some. For example, if you’re a vendor who has built a layered hierarchy of increasingly arcane trainings and certifications, you aren’t motivated to do anything that devalues it. If a practitioner can quickly grasp your system due to its intuitive and thoughtful design, why invest in expensive and time-consuming training? 

Furthermore, if you’re an IT professional who has dedicated time learning and testing to earn certifications, you don’t want to see their value diminished. Your familiarity with the vendor and their methods fosters loyalty, which lead to more purchases. Of course, these will also require further training and certification, perpetuating the cycle of interdependence. Even if the technical solutions that you’re well-versed in aren’t the best way to solve the business problem, you will likely choose them. Such a choice reinforces your value to the organization as someone skilled in operating them.

And if you’re a systems integrator selling design and implementation services? Which solution results in more billable hours: a complex array of technologies which need to be coaxed to work together, or an all-in-one system that’s ready straight out of the box? 

I remember many years ago, I had begun working for a vendor whose product was designed for disruptive simplicity, starting with installation. I visited a customer in Seattle to set up a demonstration in their lab on a Monday morning. The onboarding process was so well designed, we had the whole demo completed before lunch. As I was leaving, I bumped into former colleagues who were also setting up a demonstration system cobbled together from three different vendors, intended to compete with the solution I showcased. Curious, I asked them how it was going so far, and they said they expected to finish the design phase by the end of the next day and, if all went well, complete the installation by week's end.

That incident really opened my eyes to the power of simplicity. Thanks to thoughtful design, they were productive for almost a full week while the other solution wasn’t unpacked from the cardboard box. Consider this in the context of a full-scale deployment, and extend those timelines by tenfold, and you get an idea why all this matters. In this fast-moving world, shortening the time to value is a real asset. 

We’ve Always Done it This Way

The culmination of all of these sources of complexity creates an IT labyrinth; a mashup of semi-compatible systems that demand specialized expertise and expensive customization, that’s frustrating to use and complex to fix. And probably the biggest reason all of this remains in place is because of inertia. 

The urge to stick with the familiar is powerful. Change especially on a large scale, is challenging. Rarely do we have the opportunity to start from scratch and build a greenfield system exactly as envisioned. Even then, it will drift over time if we don’t carefully maintain it. For the vast majority of IT professionals, they grapple with inherited systems, often finding it simpler to continue with the established ways rather than advocating for change.

In my next post in this blog series, I will explore some ways to shift that mindset and see how we as individuals and as an industry can change.