Applications/DevOps

Can DevOps and Continuous Delivery Work with Commercial Off the Shelf Software?

By   |  

The short answer is often “Yes”. However, there are limitations and constraints to the level of automation allowed, the return on investing in automation, and influence over the development lifecycle that DevOps practices can introduce when dealing with Commercial-Off-The-Shelf (COTS) applications. For example, COTS applications will typically have a predefined and supported interface for managing configuration or accessing data. These endpoints may not be accessible or compatible with your existing tool chain and/or automated change management practices. The decision to onboard an application into a Continuous Delivery (CD) tool chain and to employ DevOps pipelines and practices in the development and management of the COTS solutions are ultimately up to the Enterprise. While it is often easy to lump all COTS solutions together, my experience suggests that these applications typically come in one of three flavors, namely closed, open, and platform, and that each flavor should be evaluated differently.

Closed COTS Applications

Closed COTS applications allow little to no customization to functionality and/or interfaces. They typically have predefined management consoles and a published list of commands or APIs that will allow external applications to interact with the COTS applications. A good example of a closed COTS applications is Microsoft Exchange.

Key considerations:

  • Can configurations be scripted and integrated with existing automation and orchestration tool chains?
  • Can configuration scripts be managed and maintain in external version control systems?
  • How are updates, patches, service packs applied and managed? Can these practices be automated?
  • What developer tools (APIs, SDKs, etc.) are available to extend and/or interact with the application and/or data?
  • Are these tools compatible with existing tools and expertise in the enterprise?
  • Can these developer tools be integrated within the existing tool chain?
  • How frequently are changes made to the base product?

Assuming that these applications can be managed by external systems and code developed to automate deployment, configuration and/or integration can be managed through version controlled pipeline, closed COTS application make good candidates for DevOps and CD. By applying CD principles, COTS binaries are versioned and stored in an artifact repository, install and configure scripts are managed through version control and IaaS workflows, and applications and integration endpoints are auto-tested through deployment pipelines. This is only made possible when consumers of the COTS application collaborate with operators of the COTS platform to ensure that the solution is aligned with enterprise goals, objectives, and standards related to portfolio management.

Open COTS Applications

Open COTS applications allow for significant modifications to functionality, data, and/or interfaces. These platform typically have rich SDKs, APIs, and embedded developer utilities that enable users and developer to modify all layers of the applications, namely presentation, business logic, and data. Open COTS applications typically have a large, complex footprint consisting of core services, data and/or GUI customizations, embedded applications, etc. Classic examples of open COTS solutions include ERP/CRM platforms (like SAP or Oracle) or portal platforms like Sharepoint, ServiceNow, or Websphere.

Key considerations:

  • All considerations from closed COTS solution above
  • How are customization created through internal design editors, logic builders, or data schema extensions version controlled? (Are these configurations stored in database or code?)
  • How are customizations created through internal tools packaged, installed, and configured in higher level environment like Stage or Production?
  • What does the development lifecycle for customization created with internal tools look like? What quality gates are required? Architectural standards?
  • How are custom applications/applets that are embedded in the application packaged, installed, and configured?
  • Can these custom applications/applets be run and tested separate from the underlying COTS application?
  • What does the development lifecycle for customizations created with external tools look like? What quality gates are required? Architectural standards?
  • Does the COTS application provide testing frameworks, mocks, and/or stubs for testing external dependencies?
  • What automated test suites are supported by the platform? (unit, functional, regression, capacity, etc.)
  • What is the upgrade path for customizations? (historically)

As you can imagine, open COTS applications add layers of complexity. In fact, when considering DevOps and CD with open COTS solutions, I suggesting 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. Before implementing a solution, study the development lifecycle and practices of the target COTS application before building your tool chain. Understanding how the end state platform is created and how change is introduced will strongly influence your tool chain and pipeline design. Below is an example of this model.

bart1

Platform COTS Applications

The third type of COTS application are the platforms. These applications provide a set of services and tools as well as proprietary runtimes that enable user to build and run custom applications on the platform. These are the most difficult type of applications to integrate into existing DevOps practices and CD tool chains because common practices like version control, testing, build, etc. are done through the platform rather than from external tools. Sample Platform COTS applications are Pegasystems, IBM Case Manager, etc. Platform COTS are packaged applications that enable customers to build applications on top of the base platform.

As a blend of closed and open, all consideration from above are valid. In most cases, the base platform acts as a closed system whereas the custom develop applications on top act like and open systems. For this type of application it is critical to understand what hooks and services are available to support DevOps practices and CD. Many of these platform are not going to fit within your existing tooling and may not be able to employ the workflows, dashboards, and reporting you have grown accustomed too from your current tool chain.

After analyzing the different types of COTS solution, I still maintain that COTS applications would benefit from the rigor and repeatability of DevOps and CD. And in many cases, CD tooling can be extended to support these platforms assuming there are no significant limitations introduce by the COTS application itself. That said, there are many considerations that should be addressed before starting a DevOps project on these applications.

About the Author: Bart Driscoll

Bart Driscoll is the Global Innovation Lead for Digital Services at Dell Technologies. This practice delivers a full spectrum of platform, data, application, and operations related services that help our clients navigate through the complexities and challenges of modernizing legacy portfolios, implementing continuous delivery systems, and adopting lean devops and agile practices. Bart’s passion for lean, collaborative systems combined with his tactical, action-oriented focus has helped Dell Technologies partner with some of the largest financial services and healthcare companies to begin the journey of digital transformation. Bart has broad experience in IT ranging from networking engineering to help desk management to application development and testing. He has spent the last 22 years honing his application development and delivery skills in roles such as Information Architect, Release Manager, Test Manager, Agile Coach, Architect, and Project/Program Manager. Bart has held certifications from PMI, Agile Alliance, Pegasystems, and Six Sigma. Bart earned a bachelor’s degree from the College of the Holy Cross and a master’s degree from the University of Virginia.