By Dick Stark
Last November, the DevOps Handbook, was released with much fanfare and excitement. Authored by Gene Kim, et.al., the book is about “how to create world class agility, reliability, and security in technology organizations.” Since this is what RightStar does, I strongly suggested that all RightStar consultants read this book. Even better, I promised I’d very briefly, summarize the six parts of the book separately. I’ll begin with Part 1.
Specifically, Part 1 is about the three ways, or underlying pricipals from which all of the observed DevOps behavior can be derived:
- The first way is about the left-to right flow of work from Development to IT Operations.
- The second is about the constant flow of fast feedback from right-to-left at all stages of the value stream.
- The third way is about creating a culture that fosters two things: continual experimentation, and understanding that repetition and practice is the prerequisite to mastery.
An important first step in the DevOps lifecycle is the focus on the technology value stream, which includes a heavy emphasis on reducing the deployment lead time to minutes instead of months. This brought to mind the difficulty we often have getting ITSM projects started with large government agencies. Due to security constraints, the lead time to provision servers, open-up firewalls and ports can be months, not days. The value stream may look something like this:
An obvious “fix” is SaaS based security approved, e.g., FedRamp certified apps, that supply “dial-tone,” ready service. Reducing the deployment time by using a SaaS based app like BMC’s Remedyforce reduces the overall lead time and can significantly improve time to value.
The second way, the Principal of Feedback is also critically important. One common practice is swarming, or containing problems before they have a chance to spread, and to diagnose and treat the problem so it cannot reoccur.
This manifested itself during a BMC Service Broker (SB) install last week. Since SB is a brand new product, the accompanying installation documentation was incomplete. By “swarming,” contacting BMC support, BMC sales management and the BMC customer success office at the same time, enough attention was applied immediately to help get SB successfully installed. (Without SB installed, the project was at a complete standstill.) We were then moved to the next step: document the correct process, to ensure this won’t happen again.