SAP calls SAP Activate a “framework” for implementing S/4HANA, the latest incarnation of SAP software for running cloud and on-premise ERP workloads. I’m sure the word “framework” was carefully chosen given the wide diversity of elements the framework contains. What else would you call it? It’s more than a collection ready-to-run digital businesses (“SAP Best Practices)” we can show stakeholders and modify as needed. It’s more than a toolkit (“Guided Configurations”) that enables consultants and stakeholders to collaborate in that modification. It’s more than a prescribed process (“SAP Activate Methodology”) — ongoing iterations of fit-gap analysis, realize, and deploy. And it’s more than a collection of model workflows, schedules, and templates (“SAP Activate Assets”) for applying that process.

That’s quite a cornucopia of stuff. We find Agile in there. That’s clear from the emphasis on putting demonstrable deliverables in front of stakeholders quickly and iterating rapidly from there. There’s lean in there. That’s clear from the emphasis on reuse, continuous improvement, and value streams (“ready-to-run digital businesses”). And there’s continuous delivery in there — required if you’re going to continuously improve code in production.

You Have Role a Role to Play

So SAP Activate is really more than just a framework for implementation. It is a framework for DevOps. And it would be good for SAP consultants to view their work in that light. Because there’s more to SAP consulting than just implementing SAP the best way. It’s about creating the conditions for implementing SAP the best way — with the right tools, the right processes, the right culture, and so on. That’s our role as project leaders. With SAP Activate, SAP is saying someone needs to create those conditions, so here’s help. We can help by promoting DevOps and in doing so add significant value to projects.

Just like SAP Activate, DevOps leverages tools, methods, and processes to promote the collaboration and cross-functional integration between teams that traditionally work in separate silos like development, test, and operations. Agile, lean, and continuous delivery are all part of the mix. They are all methodologies to increase the speed and quality of software releases. DevOps, on the other hand, is about using those methodologies along with technologies like application release automation and continuous integration, to achieve the kind organization and culture where cross-functional teams thrive.

Methods and Tools Aren’t Enough

And that’s where project leaders can thrive — because methodologies and technologies do not build organizations and cultures automatically. Sure, they can make doing the right thing easier; they can make DevOps the path of least resistance. But if team members are still wedded to yesterday’s practices, functional silos, and waterfall mindsets, simply giving them a new set of tools won’t make them want to change. So the organization and culture needs to change. Otherwise, software will take longer to implement, quality will be less good, and customers will abandon us for for technology partners better able to support what those customers really care about — continuous innovation and sustainable competitive advantage.

If you don’t have a destination, any path will get you there. That’s why understanding and promoting DevOps among your team members, colleagues, and customers is so important. Because it puts light on the target. It’s much harder to walk the walk if you don’t talk the talk. So let’s start talking about DevOps more.