This is the second in a three-part series on Taming Complexity for Competitive Advantage. Part I of this series discusses the need to develop orchestration strategies to deal with the complexities of integrating cross-domain infrastructure. In part II, we introduce the temporal element of change, including the integration technology journeys brought on by mergers and acquisitions.
Markets are not static. One of the most significant barriers to success is the ability to anticipate and adapt to change. But change can be tricky and complex, even if it ultimately means delivering better value.
The complexity comes not just from the technologies but also from processes. And even when change is desired, simply replacing legacy models may not be viable. Organizations must manage the complexity of migrating between operational models without disrupting operations.
Companies that can tame these complexities can use the resulting speed and agility to create competitive advantages.
Our society and our technology did not spontaneously develop. They have advanced over hundreds and even thousands of years. Even genius like Sir Isaac Newton acknowledged that discovery and innovation are evolutionary with his famous quote:
“If I have seen further, it is by standing on the shoulders of giants.”
– Sir Isaac Newton
By building on the past, we defined the directions of our journey. Sometimes this is a conscious decision; other times, they are unintended constraints.
One of my favorite examples comes from NASA. A governing factor in the space shuttle’s performance was the width of its solid rock boosters – SRBs – at 12.17 ft. This width was limited by the 4 ft 8.5 inches standard gauge the US railroad used to transport them. The US railroad gauge was based on the UK railroad gauge, a legacy of the jigs used to build the pre-rail trams. These trams followed the ruts of the old Roman roads created by their chariots. The chariots were designed to accommodate the width of two equines, measured at their docks. Thus, the performance of the space shuttle was limited by the width of a horse’s rear end.
So often, the legacies we build upon can also limit the innovations we look to develop. Or, as my psychology teacher put it:
“You can’t outrun your past.”
So instead of letting bygones be bygones, enterprises need to understand that the complexities introduced by these bygone decisions can remain for some time. But first, let’s disperse the myth that you get to start from scratch.
Many look to the age of digital transformation as a solution. There is a belief that with new methods and technologies, companies’ IT organizations can become agile and autonomous and, more to the point, less complex.
Transformations do not represent greenfield opportunities. Enterprises need to continue to support the business during the transformation. They usually also have loads of technical debt that impede the financing and adoption of new technologies. Such transformations are frot with risks. An executive recommended building a completely new, parallel environment and cutting over the business over a long weekend may quickly find out how well they packed their Golden Parachute.
Businesses tend to take an evolutionary rather than revolutionary approach to innovation. They often rely on the same classic applications that have been for decades. ERP companies like Oracle and SAP are still going strong, despite being over 40 years old.
But, didn’t the mobile economy reduce complexity?
Mobile apps may improve the user experience, but they usually increase complexity. Many of the latest social media and entertainment apps started with new ideas, technologies, and architectures. But as they grew, they needed to integrate into financial sectors and more advanced supply chains. They adopted more traditional accounting and ERP applications to incorporate into these large ecosystems. And when it comes to more traditional businesses, those apps are built to improve the user’s experience. They are typically overlay built over their web applications, which are, in turn, built on legacy systems—complexity layered upon complexity.
The truth is that organizations develop around their technology decisions. These decisions become part of a company’s culture. Changing core technologies may require changes in the company ethos. That is why “greenfield opportunities of material size are few and far between; they are disruptive, inherently risky, and culturally challenging. The moving industry is a $21.7B business for this reason. We take our stuff with us. Only a precious few get to furnish the new house from scratch.
Brownfield is the term used to describe when legacy systems and software are still in play. And while you might think this aligns with Sir Isaac’s philosophy, brownfields are not about building on the past but more about accommodating those historical decisions: constraints more than enablement. And for those reasons outlined above, it is almost always the condition of the IT department.
And brownfields are not just the result of aging within an environment. To borrow a term often used to describe growth resulting from the internal force, “organic” browning. And just like growth, many other forms of “non-organic” browning involve external forces.
Complexities expand as companies grow but compound when companies merge. Consider that in a merger, each company’s technology services have entirely different histories. Each history will have its own technologies, domains, policies, and objectives. Moreover, they will almost certainly have different workflows with different approval and change management processes. It is like putting together puzzle pieces that were not designed to fit.
One benefit of public cloud and SAAS providers is the ability to stitch together domain automation tools into more fully orchestrated solutions. When companies migrate to the cloud, the number of automation tools can be reduced with an associated reduction in complexities.
However, combining cloud deployments as part of an M&A is nontrivial. One of the design parameters of SAAS is to keep tenants isolated. Merging them becomes an ETL exercise of data and policies. It can be even worse with SaaS provides. Each tenant has structures, flows, and nomenclatures that must be mapped out before any workflow or data can be moved between tenants.
And while the M&A market may have cooled with the retraction of the market in 2022, there were still over 8600 deals. That results in some level of integration of over 17,200 environments for business to fully achieve their intents of the deals.Unfortunately, these issues are often not considered when negotiations begin. In a recent article, Forbes1 described IT integration as “an afterthought post-merger.” Given the compounding complexities related to mergers, overlooking the required integration efforts can decrease productivity and increase overhead and result in delays in realizing the ROIs.
Cloud is about developing and automating workflows around functionality: provisioning, configuration drift, network automation, etc. Our discussion starts with the concept of technology domains. Domains are groups of technologies that provide a specific type of service. Simple domains include: compute, network, and storage. Security, governance, and change management are more involved domains. The key benefits of domains are to limit the interactions outside of the domains to predefined methods, which reduces risk from unknown interactions.
For example, server virtualization technologies enable the isolation of operating environments from the underlying technologies. Virtualization limits the interaction to known, predefined paths and allows for greater agility in deployments.
While domains have complexities, most OEMs provide management and automation across their specific domains. These tools help reduce complexities by centrally managing the domain’s provisioning, monitoring, and alerting. But they typically don’t address the complexities associated with the integration of domains. It can become more of an issue within the same domain when there are multiple OEMs or incompatible generations from the same OEM. This split domain requires multiple sets of management and automation tools, which act to increase complexity.
A few OEMs try to extend beyond their domains, which becomes problematic. These efforts require them to keep up with external upgrade cycles, new functionalities, and even competition with native tools of those domains.
Where the introduction of domains simplifies the interaction between technologies, workflows provide a repeatable and consistent flow of activities and outcomes. The idea of a workflow is to codify a series of tasks with an if-this-then-that (IFTTT) logic independent of the specific technologies within the domains.
But all of this needs to be developed and managed in a platform. That process is referred to as orchestration.
Orchestration represents an overlay on the other technologies to maintain the integration points to the Domain automation tools, manage the workflows, and provide data management tools for workflows to simplify deployment. Their platform preserves the process even as domain elements are updated, swapped out, or merged.
Orchestration changes how companies manage operations. Defining processes through workflows allows companies to manage the logic independent of the technologies. Workflows can enable companies to move away from past decisions more effectively. When companies merge environments, the integration can start at the top with the process and governing logic. The workflows provide consistency in operations and reduce the complexity of disparate technologies and approaches that result from ad-hoc decisions.
However, the effort to achieve this is often cited as a barrier to entry. It requires codifying the workflows, mapping processes, and building operational standards.
Fortunately, there is Orchestral.ai. Orchestral.ai is the leading provider of closed-loop orchestration. We are already helping Fortune 100 companies reduce the complexities of managing their hybrid cloud environments. With integration points with over 250 technologies and predefined workflows for everyday use cases, we can help you tackle the growing complexities your competitors struggle with, giving you a competitive edge.
Orchestral can help you move away from the game of infrastructure Jenga often played today.
But it is not only technologies that change over time. Often workflows need to be updated to reflect changes in capabilities, adoptions of new approaches, and evolve as the business innovates. We will turn to these workflows and the underlying process in our final post of this series.
In the concluding Part III of this series, we take a look at the kinds of workflows found in enterprise infrastructure and what makes them amenable to event-driven automation and cross-domain orchestration.