In speaking, counseling and talking to people with regard to DevOps, I often frame the discussion in terms of the DevOps master process. While all of the parts of the master process are important, one aspect very often is overlooked. I call this often overlooked aspect the design stage. The design stage includes the gathering and visualization of requirements. If we assume that our goal is to deliver higher quality and more consistent and resilient deployments, then we must include expectations for how the software should operate and perform.
When we are able to streamline and optimize the DevOps master process we ensure maximum velocity and agility for delivery of IT services to the business. The importance of the master process is that it applies for both businesses that develop their own software as well as those that operate using only Commercial-Off-The-Shelf (COTS) and Software-as-a-Service (SaaS) products. Before discussing what is involved with design in more detail, let me take a moment to better define what I mean by the DevOps master process:
1. Design
2. Build
3. Test
4. Stage
5. Deploy
6. Operate
In future articles I will explore each of these elements in greater depth. For this article I wanted to focus in on the design element specifically.
To ignore the design aspect of the master process means that we have no linkage for what we are building or testing during the Dev phase and no concern for performance and service levels in the Ops phase. Simply because there are no tools that help to automate this aspect of master process, does not mean that it is not an important aspect to fulfilling our DevOps mission; it simply means that we need human intervention to ensure that our requirements are met at each stage of the process.
However, this is not all a one-way street with requirements only dictating to operations. In the past, traditional requirements gathering often focused on function with very little thought given to performance or consumption. Through our new DevOps collaboration, we introduce operations into the requirements gathering phase, which means that we can capture critical elements, such as service levels and usage models, ensuring all work across the master process leads to meeting these operational requirements. This will, hopefully, limit the spike in support calls operations needs to respond to immediately after deploying new software into production.
Perhaps the reason we don’t yet hear about the importance of this is because it’s difficult and the tools for requirements gathering and automation around testing against the requirements traceability matrices just don’t exist in the current popular DevOps tool chains. Dare I say, these have been completely ignored by the open source community? It would be understandable since open source communities grow out of interest more so than need and developers are more inclined to work tools and technologies that are interesting to their own efforts. Perhaps we will see better integration of automation of testing not only features but also service levels, from the enterprise DevOps software providers, such as IBM who are applying their Rational suite of tools toward DevOps initiatives.
Regardless, to achieve optimal benefits from DevOps, we need to automate around the entire master process. This means that we must translate requirements into automatable tasks by linking them to specific unit tests and load stress testing and ensuring that the requirement is only satisfied once these tests have passed.
