Enterprise DevOps: Bigger than Dev and Ops
Enterprise DevOps: Bigger than Dev and Ops
DevOps is widely acknowledged to include IT groups outside of Dev and Ops. Business analysts, testers, release management, information security and others. In the enterprise though, it is often other groups that are bottlenecks. The DevOps community has spent too little time talking about at these less traditional DevOps concerns.
That’s not to say that there has been no discussion. In explaining the “First Way of DevOps” Gene Kim describes that it is the value streams enabled by IT that need to be optimized end to end. Patrick Debois has nodded towards this wider view in some of his presentations and his blog on codi
The challenge we have is to look at how we deliver services, and where we find big delays. Often, other departments have built processes that worked well with slow development cycles but unnecessarily limit a more nimble IT organization adopting DevOps.
Finance departments and their policies can quickly become a barrier to faster innovation. Development teams that know that major approval processes will be needed in order to purchase the latest tablet for testing, will either not target that platform or be late to the market.
Similarly, automated provisioning technologies will not deliver faster time to market advantages if fina
Financial controls can inhibit experimentation and rapid delivery in more ways than just blocking acquisition of test devices and environments. Project kick-offs and other onerous justifications can pull talented people from productive work. The key is to look at your overall value streams. How do you go from idea to value? The policies put in place by Finance are for the benefit of the company. They want the company to be profitable. If they are getting in the way of that, identify how and help senior management open a conversation.
Tech Writers and Translation
While documentation and technical writing are generally tied to the technology team, they are often ignored in DevOps conversations. Agile values have placed less emphasis on the docs. For product companies, documentation is more critical. Good documentation saves your customers frustration whenever the UX isn’t quite perfect, and lessons your support burden. As UrbanCode, that was a big deal. Equally big was the fact that good documentation online is also good marketing material. Documentation is “long-tail” Google bait and some people will prefer to flip through your docs to get a feeling for the product before considering downloading it.
But documentation falls into some slow, waterfall patterns very quickly. It is hard to screenshot and document before the software is done – particularly when the details of features are allowed to emerge rather than being over specified up front. Now that we have joined IBM, UrbanCode’s documentation will be translated from English to another dozen or so languages. Translation has a four-week lead-time, and requires good estimates of change far in advance. That will either result in international docs being delivered after releases, or releases taking extra time to get to market.
So, we are working on our bottlenecks. Tim McMackin has a nice write-up looking at how to streamline translation processes. We also look to deliver value outside of major releases using fix-packs and plugin delivery. A quick look at one of our “What’s New” pages shows a steady stream of value.
Legal checks and approvals can be a boundary to rapid delivery. The challenge for teams is to work with legal to get policies set in place that enable rapid development and new project delivery so long as they are following some clear guidelines. One example of this would be to get a collection of open-source licenses pre-approved when using open source libraries in your applications. Instead of having legal review each library (lots of labor and slow responses), legal can be asked to review a dozen common licenses, such as the Apache 2.0 that are likely to cover 90% of what the development team would want to use.
More outside the box thinking
DevOps is anti-tribal and anti-silo. It’s one thing when the “Us vs Them” challenge is between two different groups that report to the CIO. It’s another when the other guys are further away. Is your group giving HR the support they need to hire the best talent for your team? Are they even asking for it? What about the sales or marketing teams? How often do you sit and talk with them to compare notes?
DevOps is challenging. We can’t accept barriers to efficient delivery. Instead we need to reach out to our colleagues in other groups, explain why the business needs a change, listen to their concerns and find a way to improve together.