Complexity at Scale: Trials and Tribulations of Success
Feb 28, 2016
“Complexity” is often viewed as a negative. This is perhaps even more the case at scale, where some degree of complexity is unavoidable. Any unnecessary complexity, states the conventional wisdom, is public enemy number one. But does that wisdom ring true? Let's look a little closer at the contours and implications of complexity at scale.
We’re trained to avoid complexity when we design systems, and call systems with poor architecture “too complex.” If you’ve worked in any large IT organization you understand the constant daily struggle against complexity at scale. Every day teams are starting new, “greenfield” development projects with the end-goal of replacing legacy systems that have grown too complex.The Reality: Today’s greenfield development project to replace a “too complex” legacy system will be tomorrow’s overly-complex legacy system. It isn’t the software that is complex it is the problem space, and complexity is a natural by-product of success.
What experienced engineers understand is that complexity is rarely a function of technology. Our IT systems are designed to model real, complex problems and reality can be difficult to simplify. Take an e-commerce system as an example, if you are building a small e-commerce system for a niche market you can afford to simplify problems and only accept one payment type. On the other hand if you are building an e-commerce system to compete with a global competitor you need to think about multiple currencies, complex sales tax regulations, and other complexities that only emerge when you operate at scale.
While a Fortune 500 company can take some steps to create more isolated teams at some point teams still needs to integrate into a single system. The software release process and the processes used to test and qualify these releases are the primary pain point in large software organizations. When you release software all the moving parts of the company have to come together to facilitate business operations, and release managers are the individuals that understand how to orchestrate and manage complexity at scale.
Large, Revenue-generating Systems are Complex
If you work at an international banking institution or run IT systems for a large government agency you understand that while we can attempt to create simpler, easier-to-manage IT systems some of the fundamental problems we are attempting to model in IT are complex by definition. If you work at a successful organization generating millions or billions in revenue you also understand that success often results in complexity.When a system starts to generate real revenue you almost immediately breed legacy IT infrastructure that has to be supported for many years. “If it ain’t broke, don’t fix it” is an inescapable factor in enterprise software development.
When you run a real business you are generating real revenue, and even if your software architects want to rewrite entire subsystems it is common for the largest organizations to maintain several generations of systems. Your software releases are not just focused on the new platform, they are dependent on back office systems that might be several years (or decades) old. It is this reality that needs to be factored into a comprehensive model of release risk. In a complex system an enterprise-wide release strategy can’t just emphasize agility for new systems it has to encompass existing systems.
Release Managers Address Complexity at Scale with Planning
While your IT architects and application developers have the liberty to focus on subsystems in isolation from one another your release managers have to think of software as an integrated system. When we are conducting a large software release spanning multiple generations of legacy systems alongside new, continuously delivered software we need a plan, and we need to use tools such as Plutora that understand that not every release falls into the same, cookie-cutter approach.
Plutora was designed to address the fact that release management and environment management in the modern IT organization is quickly gaining the spotlight and the role that pulls it all together is the release manager. Without a proper system to track and manage the challenges of legacy alongside the “next-generation” companies tend to experience release failure.
Complex Release Planning for Complex Systems?
One approach to managing software complexity is to create a model of the software development lifecycle that allows you to “de-risk” the process. This is what ITIL has attempted to do for IT service management, and the model works for several organizations. There are systems that lend themselves to the IT service management model, but these are rarely the fast-moving systems that deliver the agile success that modern IT departments are demanding today.
The answer to release complexity - the solution for this problem isn’t the creation of a new, inflexible model of release management. It isn’t to create more decision trees and roles focused on centralized release governance it is to create systems that facilitate “managed” agility across several independent teams. In other words, the solution for software complexity at scale isn’t to create a more complex process. It is to create systems that give enterprise release managers visibility into coordinated, independent releases across the enterprise.
Manage Complexity, Manage Decentralization
Enterprise release managers need to stop avoiding the natural complexity that accompanies success at scale, and they need to adopt a common set of tools that provide visibility into release functions across multiple projects in the organization. Taking a more realistic approach to software complexity involves creating new, decentralized approaches to containing and managing complexity when it starts to impact a large system. Instead of creating constricting, centralized approaches to manage release risk, today’s release managers need to embrace a new trend toward self-service and decentralized operations.
Plutora is the tool that allows your centralized “release management” function to enable individual teams to move at their own pace and adapt to release complexity as it develops in a particular project. Without this shift toward decentralized release “governance” away from centralized release “management” large, enterprise-scale systems will always be hamstrung by complexity. Instead of enabling project-level agility, teams will be stuck in an infinite loop.
Software complexity isn’t the problem, it’s your release process and the interdependencies that develop in large, complex systems. Manage the process and provide isolation by using a tool like Plutora to orchestrate multiple release teams and gain high-level visibility into release processes.