Can COTS Work with DevOps? Experts Say Yes!

Open COTS systems allow for significant functionality, data, and/or interface modification and usually have robust utilities, APIs, and SDKs. Think SharePoint or Websphere.

For enterprises that need to deliver quality software in less time, DevOps is more than a mantra. As we covered previously, it’s a powerful way to organize teams and projects to enable continuous delivery (CD). But it has one issue that we’ve seen in aaS (as a Service) offerings—at first blush, it seems ready-made for young, nimble startups but challenging, if not impossible, for the old guard.

A key barrier for enterprises is the use of legacy or commercial off-the-shelf (COTS) software.

If you’re in need of support for legacy COTS applications in your data center, learn how our IT infrastructure management services can provide OS remediation and patching via our IT server management offering.

COTS and DevOps Both Make Sense

It’s not easy to abandon COTS. For one thing, such “standard” solutions often cost less than custom applications. They can also be less risky to implement. And they help keep IT staff focused on the core business, rather than expending resources on reengineering accounting software or other systems that perform important but common business functions.

The fact is, many organizations have made large, successful investments in COTs solutions and now they want DevOps to bring new tools to their sales teams, more competitive digital services to customers, and so on. But how can an accelerated development process integrate seamlessly with an inflexible back-end service?

Dell-EMC points out that there will almost always be “limitations and constraints to the level of automation,” given that a COTS application will likely have a pre-defined interface that may not play nicely with CD tools. But that doesn’t mean it’s impossible. They describe three types of COTS applications:

Closed COTS

As the name implies, these applications allow little to no functionality or interface customization and use published commands or APIs to integrate with external applications. Examples include Adobe products and Microsoft Exchange.

Solution: Dell-EMC recommends a version-controlled pipeline of installation and configuration scripts, as well as application and integration endpoint auto-testing.

Open COTS

Open COTS systems allow for significant functionality, data, and/or interface modification and usually have robust utilities, APIs, and SDKs. Think SharePoint or Websphere.

Solution: Here Dell-EMC suggests “building multiple pipelines to support each layer of the application in the DEV or Commit stage of the SDLC. Subsequent phases, like Test, Stage, and Prod, will use a converged pipeline built from known good artifacts of the DEV/Commit stage.” Fortunately, there’s a nice graphic in their blog to show how this would work.

Platform COTS

Platforms, such as IBM Case Manager, which allow customers to build applications on their base platform, are the toughest from a DevOps perspective. The base platforms tend to be closed, but custom application development on the platform is more akin to open COTS.

Solution: By applying the rules of the road for both closed and open COTS, DevOps leaders can find where to roll in CD, with an understanding that integration may be off-tool.

The Bottom Line

There is much more complexity to consider regarding COTS within a DevOps environment—and we’d definitely recommend the Dell-EMC post above as a starting place along with this piece for ideas on any application for which you can expose source code (including tips on bringing mainframe developers along!).

The takeaway here is that COTS isn’t the death of DevOps. When COTS solutions exist within the enterprise and cannot be eliminated, or when a COTS solution makes the best sense for a particular business function, there are options to include it under the DevOps umbrella. It will take work—so schedule adequate time for the task—but trust that it has proven possible in other organizations and can in yours as well.