On first glance, Digital Transformation and DevOps seem to be separate, disconnected endeavors – especially once you realize that Digital Transformation is more about aligning the organization with changing customer needs and desires, rather than software.
DevOps, in contrast, appears to be all about the code – how to build, maintain, and update it more quickly. Yet this view of DevOps also misses the bigger picture, as the movement is more of a cultural and organizational change that fosters greater collaboration across development, operations, and other teams within the IT organization.
If you compare the two paragraphs above, however, one key concept joins the two initiatives: change.
Change, in fact, is what both Digital Transformation and DevOps are all about. Recognizing that change is constant. Every aspect of the organization, from the customers to the technology, is always changing.
Thus for organizations to survive and compete in today’s turbulent world, change must become a core competency.
The Myth of the ‘Final State’
Where many organizations go wrong on their path to Digital Transformation is to assume that ‘transformation’ means going from their current state to some digitally transformed one. After all, business transformations of the past have had some kind of end state, a light at the end of the tunnel if you will.
Not so with Digital Transformation. In reality, organizations must go from less able to deal with change to more able – in other words, making change itself something that they as organizations become experts at.
In order to embrace change in this way, the entire corporate culture must itself change. Management structures must change. Teams must change. How organizations large and small take action must change.
It’s a tall order. The challenge is so daunting, in fact, that many executives are at a loss as to where to start.
The good news: you’ve probably already begun this transformation. Look no further than your DevOps efforts.
DevOps as Model for Organizational Change
While improvements in automation have shifted many operational tasks ‘to the left’ (i.e., earlier in the software lifecycle), the real story of DevOps is greater reliance on self-organizing teams.
Self-organizing teams have been a part of the Agile story for almost two decades now, but DevOps extends the principles of self-organization to cross-functional teams. First dev and ops get involved, but soon, testers and security personnel join such teams as well.
Eventually, self-organization extends outside the realm of the techies altogether – to marketing, product teams, and other stakeholders. After all, involving stakeholders in the software lifecycle is also a core Agile principle – yet one that most organizations have long struggled to get right. DevOps moves this ball forward.
The Role of Continuous Quality
Quality has always been essential to software development. Waterfall put quality late in the lifecycle, while Agile pulled it earlier. DevOps, however, takes quality to the next level by leveraging improved automation technologies to make quality a continuous process.
Just as continuous integration and continuous deployment – CI/CD – are essential benefits of DevOps, so is continuous testing.
When you boil it down to its basics, quality isn’t about creating bug-free software. Quality is essentially the alignment of whatever it is you’re building to customer needs. Testers have always understood that software quality depends upon alignment with business requirements.
The continuous testing story gets more interesting when we tie it to Digital Transformation, because Digital Transformation blows up the traditional notion of a ‘business requirement.’
The old way: a business analyst sits down with various stakeholders and assembles a list of requirements that developers must build to and testers must work from.
No longer. The new way: customers drive all aspects of the digitally transformed business, so ‘requirements’ are a never-ending stream of needs, desires, and preferences – often as varied as they are dynamic.
In this context, quality is no longer a matter of checking that some application meets a checklist of specified requirements. Quality becomes an ongoing, continuous effort to ensure the software-empowered organization is adequately dealing with change sufficient to meet the competitive needs of the business overall.
The Intellyx Take
‘Change as core competency’ may sound like some hifalutin vision statement that doesn’t connect to the day-to-day realities of running an organization.
Nothing could be further from the truth. In reality, success with both Digital Transformation and DevOps depends upon organizations that can deal better with change – not just on particular occasions, but as a core part of their culture.
Furthermore, the essential meaning of ‘competency’ requires the alignment of actions with customer demands – in other words, quality. Not ‘check features off a list’ quality, but continuous alignment with dynamic customer desires quality.
As with the rest of the DevOps story, such quality depends upon automation. Digital Transformation may be customer-driven, but it’s software-empowered. Continuous testing is one such enabler.
Join Jason Bloomberg at the CA Continuous Delivery & Agile Summit, February 8th and 9th in London, where he will discuss why DevOps is essential for Digital Transformation.
In addition, join Jason Bloomberg February 13th at 11:00am EST for an informative discussion on tactical approaches that help facilitate the cultural change required to unlock the full potential of mainframe as a driver of digital transformation. Click here to register for this webinar.
Copyright © Intellyx LLC. CA Technologies is an Intellyx client. At the time of writing, none of the other organizations mentioned in this article are Intellyx clients. Intellyx retains full editorial control over the content of this article. Image credit: CA Technologies.
Excellent perspective Jason. I’d like to see you begin talking about the vital role of security or cybersecurity in the context of DevOps – some call this now SecDevOps or DevOpsSec. To us here at Pantheon, we like SecDevOps as it leads one to envision the strategic value of security – security needs to be core to the discussion, not treated as an afterthought. And where is there more change than anywhere else – in security. From new regulations to new threats daily. The hackers and criminals are smarter than ever before – at times it can be hard to keep up. So bake Security into your DevOps transformation.
Jason, I see a melding of theories. Years ago we used the terms, Super-pleasing, Operationally Efficient or Low Cost Provider (Michael Hammer – 1990’s?). A company had to choose between one of those three operating models in order to be an effective competitor in their business segment.
Your statement: “The new way: customers drive all aspects of the digitally transformed business, so ‘requirements’ are a never-ending stream of needs, desires, and preferences – often as varied as they are dynamic.”
This statement appears to me to be a recasting of the Super-pleasing operating model leveraged by Digital Technologies — an operating model that is flexible and changeable to meet customer demands. I don’t have an issue with this per-se but it needs to be balanced against the capital expense required for enabling a Super-pleasing operating model. For companies that don’t have access to affordable capital they may only be able to implement a Low Cost provider operating model so they can compete on the basis of price alone. But, most of my clients today are focused on investing their available capital on becoming Operationally Efficient – a focus on value, quality and reliability. They digitally transform everything within their core competency and added value functions and push upstream to the customer functions, that can be self-serviced by the customer and engage other business partners downstream to avoid cap-ex investment in functions they have no interest or expertise in managing. Their focus in becoming Operationally efficient is to control what must change to a bare minimum while expanding the moat around their added competitive value and core competency. They are thus able to avoid the disruption and cost of change that the Super-Pleasing operating model demands.
While Michael Hammer and his theory of Reengineering has fallen off the media buzz-feed, I find there is still much value in applying his theories to work with today’s new technology enablement capabilities.
M –