COTSOps - Automation
This is the fifth article in the COTSOps Ecosystem Optimization Strategy series. Links to the first, second, third, and fourth articles.
Per the title, this article will focus on automation. More specifically assessing the COTSOps enterprise's expectations and behaviors over the last few decades, identifying the primary constraint, and then offering how to specifically improve COTSOps ecosystem automation throughput.
Automation In the Cloud Era.
When we consume some cloud and SaaS services we experience great workload lifecycle automation.
The developers of these cloud and SaaS services, who are subject matter experts and have access to the software source code, have also created robust lifecycle automation for these cloud and SaaS services.
How do these great experiences influence our 'should be' expectation of all software; including COTS, regardless of workload architecture?
The modern expectation of the COTSOps ecosystem is COTS lifecycle automation 'batteries are included.
COTSOps Ecosystem Automation Constraints Assessment.
For decades, ISVs have shipped their COTS releases to their customers and each individual customer has individually created their own bespoke automation.
As previously covered, most COTS are proprietary software, so the COTSOps enterprise is not a subject matter expert of the COTS because only the ISV has access to the COTS software source code.
Each COTS is a complex system. COTSOps enterprises run 100s to 1,000s of these bespoke complex systems.
What is the outcome when one who is not a COTS subject matter expert attempts to create automation for a proprietary (black box) complex system?
At best, one creates some at best average quality Day 0 and maybe some Day 1 COTS automation and certainly not mature COTS lifecycle automation.
A Quick Recap On The Assessment Of The COTSOps Automation Constraints.
An ISV ships their COTS and 100s to 1,000s of the COTS customers each individually creating redundant automation for each COTS release. This bespoke COTS automation is at best a lowish quality automation because the proprietary COTS is a ‘black box’ complex system, created by people who are not subject matter experts of the proprietary COTS. Decades of market behavior have been each individual COTSOps enterprise attempts the self-delivery of COTS automation for many 100s to 1,000s of bespoke proprietary COTS complex systems.
Software Reuse
One of the principles of Cloud-Native Architecture is software reuse. Clearly, the software ecosystem market behavior for incumbent deployed COTS by COTSOps enterprises is not applying this modern software architecture pattern.
Besides being suboptimal for COTSOps enterprises, how does this strain the back office of COTS ISVs?
When COTSOps enterprises self-deliver proprietary COTS automation this can result in undesired customer complications and unnecessary on ISVs back office functions (i.e.; Support, Customer Success, Services, ..).
Might the self-delivery of COTS automation by each individual COTSOps enterprise be a form of creating destructive WIP?
COTSOps Enterprises COTS Automation Lifecycles Constraints.
Often COTSOps enterprise’s workload automation is project-based, not workload lifecycle programs. Whenever code is created, deployed, and relied upon, it needs to be maintained. A COTS application has a lifecycle, so clearly, whenever COTS automation is less than lifecycle commitment, we can expect problems.
Is it too soon to be thinking that when COTSOps enterprise invests their finite resources to create suboptimal COTS automation for their incumbent proprietary ‘black box’ COTS complex system(s), that this might be creating destructive WIP and present an opportunity to optimize?
Restating The COTSOps Enterprise's Automation Constraint As A Definitive Constraints Analysis Statement.
Recommended by LinkedIn
It is IMPOSSIBLE for a COTSOps enterprise, who is a subject matter expert of zero of their incumbent 100s to 1,000's of proprietary COTS, to self-deliver beyond below average quality, COTS automation.
Possibly it has been the decades of organizational behavior and habit as to why this redundant and bespoke self-delivery of proprietary COTS automation continues.
How Can The COTSOps Ecosystem Optimize COTS Lifecycle Automation?
Who in the COTSOps ecosystem is the subject matter expert of proprietary ISV COTS?
The COTS ISVs. Note: we can lump in hardware vendors and OEMs into this, but will keep it simple by referring to these COTSOps ecosystem partners as ISVs.
Who is not the subject matter expert of ISV COTS?
COTSOps enterprises, System Integrators, contractors, and cloud platform vendors.
If we were to change our expectations and behavior regarding who creates, delivers, and maintains robust COTS lifecycle automation, then who in the COTSOps ecosystem ‘should’ have the delivery responsibility?
Yes, the COTS ISVs.
And who should immediately change their expectations regarding the creation, delivery, and maintenance of COTS lifecycle automation and invert this responsibility to their incumbent software/hardware supply chain partners?
The COTSOps enterprises.
How May The COTSOps Ecosystem Quickly Execute?
First, COTSOps enterprises first need to standardize their automation platform(s).
In a previous COTSOps article, I shared a client's experience where individual silos had automation decision autonomy and how the value chain of their service delivery had little improvement in years. Platform standardization provides organizational and ecosystem partner leverage for continuous improvement.
In this automation platform standardization, COTSOps enterprises and the COTSOps ecosystem should leverage commercially supported open-source software. These software ecosystems are proven to deliver much faster than proprietary software and scale the global software ecosystem.
Furthermore, automation platform standardization must not be constrained by bespoke automation for individual mono-cloud vendor platforms. Most COTS ISVs have aggregate customer requirements to deliver their COTS across hybrid cloud (>5 mono-cloud vendor platforms) deployment options. So, the Cloud-Native Architectural principle of ‘portability’ or ‘build once; run anywhere’ is critical for workload lifecycle automation software and data with velocity and agility. Therefore, optimizing automation platform standardization has the foundational design architecture feature of supporting hybrid cloud deployment options. Build once; run anywhere.
Additionally, most COTSOps enterprises will have a mix of workload architectures (i.e.; distributed systems running on VMs, container/cloud-native, ..) and will have this mix for many years to come. So, to standardize the automation platform the requirements are not only hybrid cloud architecture support, but the platform must also support the Infrastructure stack and a mix of incumbent COTS architectures. A market example would include playbooks and operators that are universally supported across a hybrid cloud platform. This standardization intentionally avoids creating redundant COTS release automation for bespoke automation tools.
Summary
The goal of this COTS lifecycle automation delivery optimization are:
In execution, the COTSOps lifecycle automation delivery burden/responsibility is inverted. The delivery responsibility is distributed or crowdsourced to the subject matter experts (ISVs) who have the best ability and motivation to deliver robust COTS lifecycle automation. Furthermore, the ISVs create once and all of their COTS customers equally benefit and COTSOps enterprises get out of the business of creating automation for incumbent proprietary 3rd party systems.
This simple change in organizational expectations can quickly increase automation program maturity and can cultivate a virtuous continuous improvement operating model.
Note: There are other resources, including client workshops, that provide much more detail on the COTSOps workload lifecycle automation optimization strategy and execution program (‘Five I’s Of Lifecycle Automation Optimization’).