The very nature of software and data stacks that run smart on SAP is a heavyweight affair. Although there are an infinite variety of sub-elements inside the now heavily componentized and containerized world of modern cloud, the big picture we need to bring into focus is an essentially macro-sized view of information-based operations.
When we think about the way we work to bring our SAP DevOps competencies to bear in a live production environment, it’s always important to think about the way SAP’s own DNA evolves and expands. What we mean is, SAP has a large and lengthy legacy in terms of the way it builds software and the way it works.
This means that many elements of a deployed stack can not just be simply changed in minutes; a more considered approach is needed.
Ingrained inertia
In practical terms, we often find organizations have a lot of deeply ingrained governance surrounding the way they work with SAP. There’s a weight of inertia here that can at first appear impossible to shift. We do know that not all change is possible overnight, but customers can still take immediate action to build strategic plans to adapt, change – and to subsequently migrate to a modern Cloud platform when safe to do so.
Becoming a change architect and adapting to the new world of accelerated automation technologies is often initially scary for many firms. We know that – we get it. But we also know that automated testing can be used as a bridge to get out of the long grass and really start to accelerate innovation in any business vertical.
DevOps inside and outside of the SAP universe can be used as a key procedural, behavioral and cultural coalition mechanism to cross the chasm in even the toughest migrations, but the first problem is that many companies don’t actually understand how to embrace it, or indeed how to use it.
The challenge for many organizations is that the C-Suite (and the CIO in particular) often loves the idea of DevOps. They see it as an over-arching guidance mechanism that helps the total IT function to navigate around blockages and bottlenecks as they now work to get their job done more effectively. That’s the perception, but actually operating with DevOps for precision-engineered excellence is another thing altogether.
Moving to embrace CI/CD
Back down in the real world, at the coalface, on the command line and inside the real universe populated by DBAs, sysadmins and software developers, the reality can be somewhat different. Speeding up release cycles can be achieved through DevOps if the point of focus is accurately directed towards Continuous Integration and Continuous Deployment (CD/CI).
DevOps is good at CI/CD and it preaches and teaches functionalities associated with these services. SAP DevOps is a case in point… and this can be your secret sauce.
With CI/CD as forming a key operational paradigm inside the SAP DevOps teams, organizations can remove the roadblocks caused by users, departments or entire enterprises having to wait in line for the next tier of functionality that they need. Being able to bring the next release into production more quickly, teams can actually start to work in parallel and develop concurrent functionalities across their IT stack.
Where infrastructural elements are copied in CI/CD environments, they can be subjected to regression testing as they are moved through into production. The challenge that some teams face is that SAP is essentially a modular stack, so if testing identifies that change is needed, then that necessitates the requirement to test all key processes again.
An organization could isolate bits of functionality and perform risk-based test recipes on those portions of code, but when lots of services are mixed together inside a monolithic system, this can be troublesome. Once again though, it’s a question of getting all DevOps team members to think of themselves as change architects from the start to achieve maximum flexibility.
Keep asking questions
As organizations now move forwards with SAP DevOps in live production systems, it’s important to ask questions introspectively to make sure that all team members really do understand what DevOps means to them as a procedural cultural operational framework.
The application of these technologies will be different for every company. Not every business will be able to reduce its monthly release cycle to a couple of days, even if with fully automated testing under its belt. Some internal componentry and microservices might reach that kind of cadence – although 500 drops a day may not always be possible – so total system progression will depend upon the installed base of applications and their use cases.
Working enterprise software deployments running smart (and smarter) with SAP DevOps isn’t always the utopia that some people seem to think it is from day zero, but once team understands that the iteration goal ahead is a moving target, then we can all accept the fact that we don’t know everything that’s around the next corner.
Cool outcomes
If a business really wants to get to those ‘cool outcomes’ it dreams of with a highly functional, extremely responsive and low cost of operation IT stack, then they need to look at pressure points that can be fixed with DevOps as the antidote for digital business success.
This is the very essence of DevOps. It is self-management inside and outside of the DevOps team environment to ensure that scripts are tested automatically and releases are pushed forward with equal levels of automation efficiency.
Clarity and honesty matters a lot in this environment
We will lead that effort by example and say that for some customer implementations, we’re still learning ourselves. But this is the beauty of DevOps in a very real sense. As the team helps to drive a customer down a new path, all stakeholders get to learn the nuances of the task in hand and SAP DevOps helps to capture, codify and coalesce all those learning points for the future.
