Our customers sometimes amaze me – in a good way. Many organizations have been kicking around the agile, DevOps and continuous delivery phrases for some time now, but we haven’t seen very many execute on their plans.
In today’s fast-paced digital economy, there is a growing movement towards agile methodologies and DevOps for SAP. Increasingly, businesses are demanding more changes, more frequently with no loss in quality to meet the needs of customers, suppliers and partners.
I’ve been briefing analysts these last few weeks, primarily those in the ALM, DevOps or ITSM practice areas. It’s an exercise I really enjoy. Not only does it offer an opportunity to find out what is top of mind for analysts (i.e. customers) but it also helps validate our approach to businesses and organizations.
Over the last few posts I’ve been discussing some of the things SAP IT teams will need to address on their journey to accelerated SAP change delivery. In my previous post I explained the need for process maturity and process automation. This time, we will look at the value of multi path development and release management.
Recently, I came across a post outlining the steps for development teams to successfully start a DevOps transformation. In his post, John Jeremiah, points out that for a successful proactive transformation certain stars need to align. That is a business need for velocity and speed and management’s impatience with the current pace of change.
However, in speaking with SAP IT teams looking at a DevOps transformation it almost always is in reaction to pressure from the business rather than a proactive change in approach. So how can an SAP IT team better anticipate the need for change and become a little more proactive?
In speaking with SAP IT teams who are successfully pivoting to agile SAP development, one theme continues to stand out. Control of the SAP change and release process needs to move from a single, centralized point of control to multiple, decentralized points of control.
After many years analyzing customers’ change control processes we’ve learned that no two processes are ever the same. However, I’ve noticed that when a company sets out to improve their change control processes, they tend to make them more complex than necessary. Particularly when attempting agile processes for the first time.
I’d like to take credit for this, but can’t as I just heard it and I’m not even sure where I heard it, but it resonated with me…!
The gist of the article/conversation was that with more and more change automation being available to us, the desire for Agile change processes and the overall desire for speed of development, the comment was that going forward we should not be asking who is going to approve the change, but rather what is going to approve the change.
Last week an Infographic landed on my desk illustrating recent RedHat sponsored UBM research around the future of business IT applications. What caught my eye was the way the Gartner Bi-Modal IT concept was used to describe the different kinds of IT applications in play, rather than focussing on the way the different application types were managed – perhaps the area we normally speak into.
During a recent webinar, we asked attendees to what degree their SAP IT organization were feeling pressure from the business to ‘speed up’. The results were telling.