In part one of this Cortex I rolled out what I referred to as the grand unified theory of Digital, DevOps, and Software-Defined Everything: to achieve the levels of agility necessary to deal with and capitalize on increasingly prevalent disruption, organizations must leverage shift left/Software-Defined principles to facilitate cross-organizational self-organization – and furthermore, this technology-enabled organizational change is at the core of every successful digital transformation.
Furthermore, I hazarded to coin the term Software-Defined Enterprise – but I asked whether it even makes sense to extend the notion of shift left/Software-Defined practices to an organization as a whole.
On its face, the big picture of a Software-Defined Enterprise is as tantalizing as it is unrealistic: push a button, deploy an entire enterprise, from its technology systems to its physical equipment, like Athena popping out of the head of Zeus.
If something goes wrong or you want to make a change, then follow the immutable infrastructure principle. Deprovision the lot, make adjustments to the script, and push the button again.
Clearly we’re not going to “deprovision” our buildings and office furniture if we want to make a change, although with the rate of innovation in the 3D printing arena, such a time may come sooner than you think.
Taking a shift left/Software-Defined approach to our software systems, however, is another matter entirely. Even so, the vision of a one-button deployment of the entire enterprise’s software stack, from the customer touchpoints to the systems of record, seems a pipe dream at best.
Such skepticism, therefore, seems reasonable. The risk we face with this skeptical line of reasoning, however, is not that we might come to the conclusion that our heads were in the clouds for considering the Software-Defined Enterprise in the first place.
Given the exponential pace of technology innovation all around us, the greater risk is that we miss the full significance of Software-Defined Everything and its impact on the digital enterprise – until it’s too late.
The Road to the Software-Defined Enterprise
To explain the notion of shift left in part one of this Cortex, I pointed out that in an Agile software project, the test plan is an abstracted representation of the corresponding working software. If you want to change the desired functionality of the software, the first thing you do is change the test plan accordingly.
However, it’s important to remember that the test plan is not a substitute for the working software. Developers still need to code the application, after all!
But if we take the notion of a test plan representing working software to the next level, we have the deployment recipes that DevOps folks use to package, configure, deploy, and in some cases manage the working software, typically in the Cloud. Now our abstracted representation of the working software includes a representation of the fully configured production environment.
Just one problem: even in the DevOps/Cloud world, of course, people still need to write the code – only now the people writing the application code, deployment recipes, as well as the test plans are all sitting together working as a self-organized team.
So, let’s take the next step on the journey to the Software-Defined Enterprise: remove the hand-coding from the equation, replacing it with declarative configuration activities – in other words, no-code application creation.
I’ve been writing quite a bit about the low-code/no-code space for a while now, and once you place these platforms into the context of the shift left/Software Defined story, the reason for all the excitement becomes clear.
If we combine no-code with DevOps properly, we now have a way of abstractly representing working production software, including its functionality. Not just the limited-scope apps that some no-code platforms are best known for, but full-blown, enterprise-class applications – created from nothing but their abstract representations with the push of a button.
Software-Defining the Digital Enterprise
The promise of the DevOps/no-code combination gives us a fully immutable enterprise software infrastructure, from the network to the running applications. In reality this promise still lies in the future, but given the relentlessly accelerating pace of technology innovation, we’ll be there sooner than you think.
Even so, this story so far focuses on automation. We’re taking tasks that people used to handle manually and removing the human from the equation. Automation is a wonderful thing, after all – it increases speed to delivery while improving quality and productivity.
But the digital story isn’t about automation. It’s about people – the users of all this now-automated gear. Customers to be sure, but in the broader sense, all the users of the technology, including the employees of the organization.
Interestingly enough, DevOps teaches us an important lesson about the relationship between automation and people, in another example of our grand unified theory in action.
Remember that DevOps is essentially a technology-enabled cultural shift, where better automation helps break down organizational silos – not by removing people from the equation, but by empowering people to focus their efforts on more valuable work.
As we move toward the vision of a Software-Defined Digital Enterprise, the progression toward increasingly sophisticated automation promises to have the same impact on everyone the enterprise touches as it did on the DevOps teams themselves.
The clearest example of this trend would be a digital enterprise whose products are themselves entirely digital – say, for example, a media company who has retired all of its traditional media to embrace a fully digital product line.
For such a company to be a Software-Defined Enterprise, all of its software, from its customer touchpoints across the entire customer journey to its delivery infrastructure to its digital products themselves, all have an abstracted, declarative representation.
Such a representation, or recipe if you like, enables this company to push a button and deploy what is in essence its entire digital business. If it wants to fix or change something, it can simply deprovision and redeploy the whole shebang. The end result: more value for customers.
In the more general case where an enterprise has a mix of digital and digitally-enabled physical products, the story is more complex, but no less Software-Defined.
The widgets rolling off the line may be physical, but if all the software controlling all the equipment on that line is fully Software-Defined, and furthermore, the rest of the end-to-end digital infrastructure from customer to systems of record are likewise, then such a manufacturer can also consider itself to be a Software-Defined Enterprise.
Note that this manufacturing example is not simply one of mass customization, as we’ve moved up a level. The Software-Defined manufacturer would have the ability to change the way it mass customized its products, as well as every other activity along the customer journey, with a simple push of a button.
The Intellyx Take: What Happened to the Composable Enterprise?
Even when we have all the technology in place to make the Software-Defined Enterprise a reality, it’s an oversimplification to assume that anyone would want to push a button to deploy or redeploy the whole thing.
In practice, people will deploy parts of it at separate times, depending upon which bits need fixing or updating.
However, for the enterprise to be Software-Defined, even this modular approach to adding or updating capabilities must be part of an overall, coordinated plan – in essence, an executable Enterprise Architecture model of the enterprise that both allows for modular updates as well as dealing with all the issues that result when you update some parts but not others.
In some ways, this modularity hearkens to discussions of the Composable Enterprise – the idea that we can represent all the software that runs an organization as composable, loosely-coupled components. (See the white paper I wrote about the Composable Enterprise last year).
So, is the vision for the Software-Defined Enterprise the same as the Composable Enterprise? Yes and no. There are some overlaps between the two, but in many ways these are distinct ideas.
The Composable Enterprise is part of the broader API Economy theme, where the focus is on establishing appropriate software interfaces to facilitate business-driven compositions.
However, if people either make or update such compositions after deployment of the components on an essentially manual, one-off basis, then such an enterprise might be composable but it certainly wouldn’t be Software-Defined.
We might say, therefore, that Software-Defined Enterprises must be composable, but the converse isn’t true, as there’s much more to being Software-Defined than simply being made up of composable elements.
Furthermore, as Conway’s Law would suggest, if an enterprise has a siloed organizational structure, then the composable modules that make up that organization would fall into those silos as well – a sure sign that the organization has not successfully undergone digital transformation.
In contrast, if our Software-Defined enterprise is digital, we’ve broken down those silos by extending DevOps principles across the entire organization – and once again, we’re back to our grand unified theory, where shift left/Software-Defined principles facilitate cross-organizational self-organization.
Copyright © Intellyx LLC. Intellyx publishes the Agile Digital Transformation Roadmap poster, advises companies on their digital transformation initiatives, and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers.
