This blog post has been a collaborative effort with Marianne Hollier, Cindy VanEpps, Roger LeBlanc and Anita Rass Wan.

We are interested in getting feedback on how these scenarios could help to drive customer conversations when introducing the middleware portfolio in support of their DevOps initiatives.

Welcome to the first in a series of blog posts that will introduce DevOps scenarios for middleware.

Building middleware applications is challenging because of the multi-tier nature of the application. Discipline, communication, and transparency among all the teams are required to be successful in this endeavor. DevOps is an organizational capability focused on the agile relationship among the business, development, test, and operations organizations. The ultimate goal of DevOps is to deliver faster with higher quality in a continuous and integrated manner among these teams.

The DevOps scenarios for middleware that we will discuss in this series of posts reflect different lifecycles (or usage patterns) for middleware application development, improvement, and maintenance. Through the review of these scenarios, the idea is to show how DevOps can provide guidance to 1) accelerate software delivery; 2) balance speed, cost, quality, and risk; and 3) reduce time to feedback.

As we share these patterns, we are interested to hear your feedback. Which scenarios align best with what is going on in your organization? What primary use cases and scenarios are driving the adoption of DevOps in your organization? Which capabilities do you perceive as critical to achieving your DevOps objectives? Most of us are familiar with the process for creating and updating software, which usually follows a typical build, run, and manage scenario. However, motivators for these software changes are varied: a need to improve quality, a need to increase innovation or to scale agile practices across the enterprise, or the pressure to quickly resolve a problem that arises in production are examples. Are there particularities to each of these situations that warrant a variation of the DevOps lifecycle?

In this initial post, we propose a set of process flows supporting each of the motivators highlighted above, which should apply whether you are building microservices, application programming interfaces (APIs) for hire, or traditional services to be consumed internal to your application. In follow-on posts, we will deep-dive into each of these scenarios, providing process guidance for their possible implementation and subsequently illustrate a tool-chain which can be used to implement each scenario.

For the sake of simplicity across all of these scenario diagrams, we have opted to go with a sequential approach to mapping the various activities. In reality, we understand that several loops can exist between several of these activities resulting from the collaborative and interconnected nature of a DevOps flow.

Let’s start off with the typical DevOps scenario for implementing new updates to a middleware application. This scenario defines steps used in a development process to efficiently implement a code change while explicitly validating the value delivered to the business.

Next, we’ll look at a DevOps scenario that initiates from the production side of the house. Production environments are key to running the business. When a production environment encounters a problem, it needs to be resolved quickly with high quality and with safeguards to ensure the problem does not recur. Because of the criticality of production systems, transparency is key as development, operations, and management will want to know what happened, how the problem is being triaged, and how and when it is being resolved. When this happens, having a guided set of steps to resolve the issue helps to ensure communication, transparency, and quality in resolving the issue.

Do you have several innovative ideas on how to approach a solution but aren’t sure which ones your customers would prefer? Do you require confirmation that business objectives can be met before you invest too heavily? Use the Innovation scenario to determine which outcome best fits your customer needs, using a Lean Startup approach. The innovation scenario provides a guide on how to take different possible solutions and narrow down to the right approach to your solution using real customer usage feedback.

Are your teams finding high-impact defects late in the lifecycle, or even in production? Do they discover a lot of unreproducible defects in their different test environments? Are teams waiting to test until all the systems are available? Use the Quality Improvement scenario to “shift left” your testing activities. These shift-left practices help to avoid rework, delays, and churn that can occur when major defects are discovered late in the testing cycle–after all integrations and product components are finally brought together as a composite application and made available for the team to test. They avoid these issues by performing integration tests as the code is being delivered and deployed in a realistic production-like test lab. If any of the dependent application components are not available to test, virtual services can mimic the real components’ behavior until they are ready.

If your organization is challenged with scaling agile practices across a growing set of interdependent teams that need to tightly collaborate towards the delivery of complex releases or systems, then you are likely looking to adopt a SAFe (Scaled Agile Framework) style development model. The Scaled Agile Framework (SAFe) is a structure for applying agile development practices to teams-of-teams working in programs. The framework describes how to drive business value that is captured at the enterprise portfolio level down to its implementation across programs and teams. The IBM implementation of SAFe, combined with our scenario for program-level delivery to production, helps to ensure timely and cohesive delivery of large-scale business value.

This high level introduction to these scenarios provides a quick overview of how the principles of DevOps support the different motivators for software delivery in an organization. Stay tuned as our next set of posts delve into each of these patterns in more depth and talk about how they can be used to deliver business value faster with higher quality in a continuous and integrated manner.
Do you use these patterns in your software environment? Do you have other DevOps patterns that you use in your shop? We’d love to hear from you!