DevOps, an IBM Perspective - it’s going to be a culture thing for the Mutable Business, not just a technology thing, and most of IBM’s ideas have general application

I’ve just had an interesting conversation with a couple of DevOps people from IBM, Eric Minick, OM lead for DevOps and James Hunter strategy lead for DevOps.

IBM defines DevOps as an “essential enterprise capability for the continuous delivery of software-driven innovation that enables organizations to seize market opportunities and reduce time to customer feedback” (see here). We agreed that DevOps was very much a “culture thing” rather than a “technology thing”, although Eric did point out that the Kubernetes container orchestration software is an important enabler, from the IBM point of view. It is what helps one to produce cloud-neutral, scalable, solutions avoiding lock-in to any particular vendor platform. Kubernetes certainly has the mind-share which makes it a safe choice. That said, it seems that many people (including some at IBM) are finding the (equally “commercial Open Source) Nomad equivalent to Kubernetes from HashiCorp easier to use. There is a HashiCorp comparison (see here), which is not exactly disinterested but seems fairly balanced. There is a much longer, and more technical, discussion elsewhere (see here), which ends up saying that “schedulers [Kubernetes or Nomad] make it possible for developers to think about the operation of their service in the form of code, making it possible to truly get one step closer to the DevOps ideal of shared ownership of holistic software lifecycle”.

DevOps started as a collaboration between Dev and Ops, with the implication that Dev would start building software that made life easier for Ops. So, there was a tight feedback loop between building software with automated process and operational problems, which should help the automated processes to deliver better quality software; as well as to deliver it more efficiently and more cost-effectively (DevOps is sometimes thought to be about faster cheaper delivery of software, but without quality – fitness for purpose – software delivery can be too fast and too cheap).

However, IBM now seems to be concentrating on a bigger picture, the automation of the delivery of effective business outcomes. A very good idea, in my opinion, although I think that (although IBM has some notable success) this might be a stretch objective for some organisations. Eric says: “The “bigger picture” of automating delivery of business outcomes (and measuring that) is certainly something we’re putting the building blocks together for, but we recognize that most clients need more tactical improvements: better testing, or better deployment, or better monitoring. What’s the grand vision for when it all comes together? Winning in the market.”

IBM often seems to use its own internal software development organisation as an exemplar for agile at scale and DevOps automated delivery – but I am not sure how typical an organisation IBM really is. How many other organisations have a history in computers back into the middle of the last century, and have survived at least one near-death experience?

That said, there is much we can learn from IBM. Firstly, there is the need to manage the cultural changes needed to make DevOps work. If you are going to deliver better business outcomes with DevOps, you need collaboration across all stakeholders, with appropriate business decision-makers involved in the early stages in the DevOps delivery process. So, there is really no room for a new IT silo, where Dev has taken over Ops or Ops has taken over Dev. Neither is there room for business politics, where (say) being inefficient gives a manager a bigger headcount and more status in the organisation; nor is there room for managers who demonstrate their status by not attending meetings with other DevOps stakeholders.

IBM has set out its PoV in a paper “DevOps for hybrid cloud: an IBM point of view” (see here). I’m not about to repeat this in detail, but it does make some important, and generally applicable, points

IBM emphasises that, with DevOps, there is “an expanded set of stakeholders such as business owners and end users, and practices such as design thinking and user analytics”. It says that for line of business executives and CIOs, “a key concern is the capability of DevOps to enable business transformation through faster development of innovative software that meets emerging business needs – or even creates those needs in the market” – something that I think that we must all remember. It points out that “as customers seek a direct, digital link with the businesses they deal with –increasingly, from their mobile devices – application developers are taking on major responsibility for the customer experience”.

It also recognises “the challenges of multi-speed IT [which can be addressed] in combination with methods such as the Scaled Agile Framework environment (SAFe) to facilitate collaboration”. Multi-speed IT is about environments with significant legacy, and/or systems of record, and/or highly regulated applications where the extreme agility of mobile app development is neither feasible nor, in some cases, even appropriate.

Two essential disciplines that may be new to many developers are “Design thinking: for a focus on delivering exceptional user experience and for increasing user conversion” and “Application and user analytics: for continuous learning used to improve the quality and value of applications”. Something that they will need (and may not have experienced before) is “an environment where developers can fail fast in a penalty-free environment where individuals are empowered to try something new and different without risk of doing damage or looking foolish and where they can turn small-scale mistakes into productive sources of future creativity”. And, IBM recognises the importance of DevSecOps, which is “the concept of integrating application security testing within a DevOps environment—this is a big process and cultural challenge because application delivery speed and release frequency are primary DevOps goals”. It says that: “risk-based integrated, automated security testing early and throughout the software delivery lifecycle, [is] essential for success”.

IBM offers free workshops to organisations starting the DevOps transformation, where organisational and cultural barriers to the transformation can be identified in advance, so they can be addressed before they induce a fatal loss of morale in the people introducing DevOps.

There is a YouTube example of such a workshop here. This is certainly a good starting point, although this one deals somewhat more with technical issues/barriers/objectives than business and cultural ones, it seems to me. There are many other DevOps videos on YouTube, of course.

It is important to get the culture right, with the right organisational roles present, as part of introducing DevOps. For instance, James emphasised the role of the Release Manager, coordinating the impact of software delivery across all of the parts of organisation that are affected (this is where system virtualisation capabilities are important).

It is also important, however, to build the software right for DevOps. Built-in transparency is important, so that any metrics the organisation needs for the delivery process are available, as well as operational metrics. IBM is starting to design software that reports on its own success, in business terms, as it is used. Since cultural transformation works best by “install small, grow by success”, such software feedback could be key to achieving a successful DevOps transformation across a company. As James pointed out, if key performance indicators for various parts of the business are published, even if they are anonymised, people are usually aware of whether they are amongst the better or worse performers, and there is a real incentive to adopt better practice, if one knows it is available and its use being noticed. According to Eric “David calls out that we’re starting to build software around metrics. That’s not a roadmap thing, that’s product (see here) in market that we are expanding (see here) upon.”

Another key transformation enabler is the internal “sharing webinar”. This is where a successful team reports on its achievements and how they were obtained – and then other teams have a chance to learn about new processes and tools they can use to improve their own practices.

Nevertheless, remember that if DevOps is all about better delivery of better business outcomes, it certainly isn’t about better delivery of software the business doesn’t need! DevOps won’t achieve better business outcomes unless there is a bigger feedback loop, from business outcomes to system architecture and design. This also implies, not only that business people with the power to make decisions about business strategy and practice are involved in the DevOps process, but that the business itself is Agile. Effective, agile, software delivery won’t count for much if the business doesn’t have good ideas for doing better business, and if parts of the business not immediately benefiting from a particular improvement aren’t prepared to facilitate the changes needed to support this.

Eric and James talked about a large online retailer’s new faster delivery commitments – a neat business idea and you “just” have to pull eligible orders off the queue for immediate processing. But, this potentially affects almost all areas of the retailer’s business. What stock control, fulfilment, reporting, employee reward processes may be impacted if a 2-hour premium-delivery purchase disappears from the usual fulfilment process? A potentially successful new sales-product will fail if it causes existing sales-products to fail.

And, of course, the business needs to have bright ideas that are worth developing automation for. A large sportswear manufacturer, for example, needs to innovate constantly, in case customers come to see it as just a purveyor of over-priced plimsolls, and (for example) a range of limited edition shoes, individually customised in near real-time, is a great way of doing this. Eric and James see this as the sort of innovation, DevOps helps make possible – but only if the business has the idea, and is prepared to support it, in the first place.

My takeaway, is that IBM sees DevOps as the best idea we have for developing software for the Mutable Business (the business in a constant state of evolutionary change). Nevertheless, it is not a cheap get-out-of-jail free card. DevOps needs more maturity, more real investment in automation, and a wider skill-base than older silo’d development processes. It is important the DevOps feedback goes from business impact back to business and technical architecture and design. And, it must be seen as more than the automation of the current status quo, with just a few improvements.