Competitive companies need to be able to change IT quickly to stay ahead of the game.
They can’t wait six months for new business functionality, or two years for a major transformation project – they need change now, tomorrow and next week. In fact, they need new releases continuously.
Go back in time and you’ll notice that the most competitive companies mastered something of their era.
Ford mastered the ‘age of manufacturing’, P&G mastered the ‘age of distribution’ and companies like Amazon and Google have mastered the ‘age of information’.
Today, we’re in the ‘age of the customer’ – where the war for exceptional customer experience, service and choice sets apart the winners from the also rans.
And the winners need to be responsive. Today’s market leaders run their IT in a different way – they blur the lines between Development – the coders who create software; and Operations – the techies who build and run environments.
The result is DevOps – a name first coined by Patrick Dubois in 2009 to describe this emerging approach.
The contention between Dev (deliver business functionality faster) and Ops (protect Production and keep the business running) has historically created a bureaucratic, siloed ‘them and us’ culture, where too much effort is wasted on things around the edges of delivery.
Things that are ‘important’ but not critical to competitive advantage.
What’s at the heart of DevOps?
Enable continuous development, integration and testing
Create an ecosystem where changes can be built, merged, tested and released on an ongoing basis.
Run parallel development and manage Dev activity more dynamically. Create Test systems using ‘Production-like’ data to improve testing quality and run code against more realistic test scenarios.
Small frequent SAP releases
Create a more agile development model where changes can be released in smaller increments.
Break up the ‘large waterfall’ project methodology by bundling changes based on technical independence.
Tear down the partitions so that Dev and Ops can work more closely together. Co-location, shared workspaces, daily stand up meetings and tools that enable everyone to work to a common version of the truth all help drive faster delivery.
Treat environments as code
Manage the hardware landscape the same way as code – quickly clone environments through a virtualized infrastructure, simplify and standardize server configurations.
80% of the cost of an SAP system is spent building it. 20% is spent running it and crucially, delivering real business benefits.
The implementation takes 1–2 years but you’ll probably run your SAP solution for 30 years.
Automate SAP deployment
Remove the dependency on people, and perform code deployment (like SAP transports) automatically based on approvals.
Shift quality ‘Left’ in the Dev lifecycle by making sure that code works earlier and ironing out performance and code compliance issues well before testing begins.
A KPI of DevOps is MTTRS – Mean Time to Restore Service. When you develop faster, you have to learn to expect Production issues.
Conversely, you need to find ways to solve them quickly – things like backing out failed transports quickly and self-healing interface recovery.
Although DevOps is rife in web and mobile worlds – and is picking up momentum in large enterprises – it has yet to make a cameo in the packaged software space.
But that’s changing.
Forrester and Gartner will both tell you that uptake and adoption of DevOps are accelerating. Unsurprisingly, the most forward thinking and competitive corporations are leading the way.
But there are barriers to DevOps for SAP – multi-vendor outsourcing – especially where Dev and Ops are contractually split, managing cultural change and crucially, identifying tools that solve practical DevOps challenges quickly.
Whether you’re on the Dev, Ops or business side of the fence, if you listen carefully, you’ll hear the wheels of change spinning up.
And they’ll be at full RPM in no time.
Download our ebook A Practical Guide to DevOps for SAP.