In this second article in the DevOps and DevSecOps series, I will explain some of the more classical motivations to use the aforementioned paradigms.
As I’ve already mentioned in my previous article, aside from simply saying “work better not harder” or that it serves to improve delivery cycles and quality, I will now try to explain how the use of these practices have a deeper connection to product improvement, and hopefully a more widespread effect on the end user experience.
The value chain.
Again, I must stress the use of the 3 “P’s” of my area of interest: people, processes, and product.
It should seem obvious that we all work to increase value in order to deliver it to the end client. Everyone in the value chain, receives something from an “ask” to transform it to a given result. In other words, we all have a client to deliver something to. A DevOps team recognizes this as a chain of people working together in a series of steps. Each trying to leverage proximity and a similar knowledge base to ensure the work ordered and delivered is passed along the chain as smoothly as possible. A process.
Additionally, these people centered around delivery of value to the client and enriching products’ lifecycles use technology and tools to accelerate and increase quality or the final delivery of the product.
It is the synergy of these 3 areas of interest that creates “the broad strokes” in which we can find where we must invest our energy in improving our ways of doing things. But there is an order that is often misunderstood, and it is profitable to understand the impact on our output, our product or our application.
People, processes, tools
This is the fact that people come first. They are the ones we must accommodate the most. Thought the are the most flexible element they are the one that require the most effort to understand how to coordinate effectively. In fact it is an never ending job of refining these notions, but in order to make them clear we use processes.
Processes are visual. They are a workflow. A program if you like. Where each subprocess has an input and an expected output. Through this flow the input item is enriched and become an improved version of itself and finally the desired output item. This can be seen and objectively measured throughout the flow. And that way we ca identify areas of improvements where we can change and get better results in the next delivery cycle. Whatever the methodology you use.
Concerning tools, it is worth repeating, this is tantamount the same as “eating your own dog food”. We are IT solution designers, it would be disingenuous for us to propose systems that help people improve their business and in turn, not use such systems of our own. There is a an extraordinarily vast library of tools to help regulate, automate, speed-up and solidify our processes. But this is subservient to the processes. Which in turn is subservient to the people.
This is the way
We are all in this together. I am not even being that much metaphorical when I say this. We all have a unique mission. Delivering value and a great user experience. In that regards we must cooperate a maximum to do so. And that is why we do Devops and DevSecOps.
It serves us better to include all stakeholder interests in all phases of the production of our product or application. We cannot create something, toss it overboard to another crew and expect everything to go smoothly, no matter how carefully we documented the product.
The change that is inevitable with each iteration of our product makes that proposal almost impossible to keep track of, manually. But automate it and you are obligated to keep track of it. To a tee, in fact. The operation of the product will simply break if you did not automate it and have not considered the destination technological platform. So, therefore it is oh so critical to have the DEV and OPS teams working as a single crew aboard our ship. And again, why DevOPS isn’t a department or a specialist but a way of doing things.
How this applies to DevSecOps is the same. It is just in how and what you are going to do to integrate the security imperatives in the crew that changes. And that can be all connected to how you plan on doing security. I like to break it down into the following areas.
- Data Integrity
- Data isolation and privacy
- Quality improvement (more on that later)
Your mileage may vary, but these are good areas to start with.
Again, having all areas of the business aware and responsible of these preoccupations will elevate the chances that you will have a better product and a better time creating and maintaining it. And in the end, it becomes a vehicle to improve the mood of the teams having to implement these preoccupations. “No surprises, no disappointments”, as I like to say.
The more an area might be subject to neglect, the more I like to put in “a close inspection” in my processes. And often these are the Quality and Monitoring areas.
There is no Quality without Security and vice versa.
There are few principles I can guarantee as much as this. In all honesty, I do not really like to speak of DevOPS practices so much. The fact that we might have to reinvent our ways again to include security, scares me, quite frankly. Our systems are more and more exposed and available through a common and accessible network. This exposure comes with additional benefits but also risks and I simply cannot consider my product as having any measurable “quality” without having considered the safety and security of its use.
I cannot presume perfection and that is what will make sure I keep improving. So, the only reasonable motivation I have to speak of DevOps first, is to allow assimilation of its guiding principles.
But if one can remember that the product must meet a quality standard it is just as easy to remember it must meet a safety standard and if you treat both these separate preoccupations as a single one, then it does not really matter what term you use because in fact they are actually synonymous. But as a reminder, I prefer to use DevSecOps every time I can. Just so people are prepared and reminded to include security as a preoccupation along with the rest. And There you have it, DevSecOps and why it is pertinent.
If we can agree that a more unified approach to our workforce, the processes that guide them and the better selections of tools and products targeted are valuable ideas, then we can agree that DevOps is a good practice. Then if we can agree that security is just another aspect of quality, then SecDevOps is a barely a stretch of the imagination to how we can improve ourselves through better integration of that preoccupation. I sincerely hope that you will find it easy to see the benefits of these practices. And if you do, I invite you to follow me in the next article in me explaining how we go about it, here at Emyode.