Is DevOps in SAP dead?

Hello, everyone, and welcome to our panel discussion, is DevOps in SAP Dev? My name is Maria Robinson, and I will be moderating this conversation today. Before we start, just a few housekeeping items. The lines are muted, but you are more than welcome to enter any questions at any point in the question box, and we will get back to you, right after this session. The lines, so we have a distinguished panel of experts today to share some insights and perspectives about DevOps in SAP. We have Paul Hammersley, senior vice president of the ALM products here at IPS Labs, Nick Yohannu, the recently appointed director of solution engineers at Worksoft, and Chris Drake, head of product and strategy at RSC. So DevOps is not a new concept. We've heard it before. And around five years ago, it was every it was all everyone was talking about. But something went wrong within the SAP ecosystem. DevOps really couldn't really start kickoff, because something might have gone wrong. So I'm just gonna start, asking a question to Paul. If you can help us a little bit set the scene, why do you think DevOps five years ago didn't really work for SAP, and why are we talking about it again today? What has changed and what is giving us a new hope that we can actually become more agile within the SAP ecosystem? Thanks, Maria. So I think for the core, part of SAP or the, I guess, the unique selling point for SAP all those years ago was the integration between different departments. So, when an organization shipped something from the warehouse, it was immediately updated in the finance system. And so that brought massive benefits to organizations in the sort of early nineties, mid nineties, and into the two thousands. But when you then start to try and apply DevOps to say, well, we want to be able to fail fast, try things, we want to be able to do our developments in short sprints rather than big projects, this proved a big challenge because you couldn't go tinkering with one business process without implementing something that would affect all of the other ones as well. And so I think, in my own opinion, one of the reasons that people struggled with, DevOps was a desire to apply it unilaterally across the board to say, from now on, we are going to be agile. We're going to use DevOps. We're going to try things out, fail fast, and so on across the board. They didn't look specifically to say what type of projects we're looking at here. If you're building a new distribution center because your business has decided it needs a new distribution center, that's not the sort of thing that you can develop in, you know, short sprints in silos. And so the one of the reasons that I feel, the choice of projects or being able to say DevOps should apply in some places and not in others is because the research from Tap Inside a few years ago said that they felt that people's planning, of these projects was one of the main reasons that they were failing. I'm not sure it was necessarily the planning. I think it may have been they were trying to apply it to projects where it simply didn't fit. And if they'd actually been able to take a step back and say some of the things that we need to develop should actually go down that DevOps route. We should be able to get technology experts in early on. So business users and technology experts are working interactively to say, what can the world of technology now do for our business? And how do we prototype that and show it to people very quickly to say this is a good thing for our business or not? And if it's not, not waste lots of time on it and not waste lots of transports on it. That's perfectly valid. But by trying to apply it across the board, my own opinion is it gave DevOps Patrick, when it failed, would it failed spectacularly or just the frustration of you've said we're gonna do things quickly. You've said we're gonna move things through. I can't get a transport into production still. What's going on? Where's this DevOps? Where's this agility that you promised me? Yeah. No. That's, completely understandable. We collaborated with SAP Insider in twenty two to run a little research report to actually see how people were feeling about DevOps a few years in. And we definitely can, agree with what you just said, Paul. As well, they actually, people said, we can apply a more agile process with other technologies, but with SAP, it's just too risky. The smallest change in an SAP system can really, have some detrimental results, that people are just too scared. So, obviously, there is more attachment to testing, to do it right, to do it with the right data, to do it with the right or and then apply all the transports in the right order. So it's a little bit of a the sphere of change. And talking about change, Chris, at RC, you are experts in change management and agility. So I just wanted to know from your point of view, what are the top challenges that you have seen within your clients and the people that you work with, the top challenges in adopting a more agile methodology in SAP? Yeah. It's a good question. And, you know, sort of agreeing with what Paul's just said, it's down to managing objects, really. So, yes, everything's very interconnected, especially in the ABAP layer. These objects are intertwined. They're being used by multiple departments. They've got reports. They've got processes hanging off common objects. And when the objects are changed, they do this thing in a transport, which is you get the exact version of that object, and it was the time that the object was released or the transport was released, I should say. I was compared to the old, read, write, CD or, more the read CD drives, from, gee, late nineties, early two thousands where whatever you put on that CD, the time that you release it, and you have to release it for another computer to be able to read it, that's it. The version is what it is, and that's just how an SAP transport works. It takes the object. It captures them at the time that it's released. And then as soon as you've got multiple version of these objects flying around the system, being modified for various utilization cases or functional requirements across department, it becomes a very risky proposition to be able to then manage change at a pace that could impact specifically multiple, areas of the business. So agile is a challenge because the visibility on different areas impacting these objects and then also the dependencies that these objects have on other objects. And that's more to what Paul was saying is the processes. The process is normally across multiple objects that are all interdependent on each other. That visibility is what makes it very hard to go agile, and organizations have been very addicted to this waterfall approach for such a long time because it's safe. We know that everything that's been changed can be bundled up into one big waterfall release, and we test it all at once. We go live, and then we know it's safe because everything's in there, and the release is done. And as long as you get the sequence right, that's the way to do it with SAP add up. So that's a challenge, but, really, then it becomes getting the right tool sets to overcome this challenge. You can. It's the right checks at the right time. It's awareness of common objects being utilized for different cases. And where possible, avoiding using it. Delay something to another sprint or another release. And the more frequently you can release, the more easy it is to then shift to another sprint or another release because you can go, I have a priority here. I'll work on this object. If I work on this other functional requirement, it's gonna attain it change the same object. It's gonna have an interdependency. I can either delay or be conscious of the fact that I'm working on this and combine the requirements so that they can go at the same time. The awareness is what makes it possible, to be able to then go more agile by compartmentalizing, understanding other impacts to these objects, and either grouping them together consciously or consciously choosing to delay the work on these common objects or dependent objects. And this is one of the challenges. Organizations don't have this visibility. Of course, that's what our project our product, sorry, is, known for bringing to the market is making awareness. The second somebody tries to impact an object and touch it to make a functional enhancement, is there another person working on this object? And can we either combine the work effort in the same sprint, same release without compromising, the ability to be agile with the initial change, or is it something we should delay so that we can be more agile by doing things in bite sized chunks? So, I would say that's been the biggest challenge for organizations is that awareness of different needs to be able to impact a common object and then being able to adapt the process to handle the delivery of those objects. Brilliant. Very interesting to mind. Yeah. Thank you, Chris. And, Nick, building on what Chris just mentioned, obviously, there is the technology component, which is really important. And in this SAP insider paper that I will share after this chat with anyone who wants to have a read, within the first three reasons why people or the three the first three challenges that people found, it was the lack of appropriate technological tools for, testing and for transport management and data provisioning. Surprise. Surprise. So it's not a coincidence that I've asked the three of you to join us here because, obviously, all of you are experts within, all of these areas. So my question to you, Nick, is, beyond the obstacle of technology, which back in the day was clearly you know, there was a lack in the market possibly for tools like that. I don't know. Or a lack in resources at the time. What do you think prevents SAP teams from becoming more agile? Maybe like a mindset or what's what's your opinion on that? A good question. For today's discussion, I'm gonna kind of blend in DevOps and Agile and use the two, synonymously with each other. I'm not necessarily gonna distinguish between the two. The way I like to think about it, when I think about these things, I always think about it from a people, technology, data, and process point of view. Those four things need to kind of work together in order to get to the kind of outcomes that you'd be looking for. In my opinion, I think the main obstacle in adopting a DevOps approach is cultural resistance and an organizational mindset that doesn't necessarily want to or know how to adapt to more agile ways of doing things, especially in SAP ecosystems where you've got these monolithic systems that have sometimes been resistant to agile ways of actually working. So if we look at what DevOps is, DevOps is a culture shift. It's a way of working, a way of collaborating. The collaboration is meant to be seamless across different departments and teams. It's all about breaking down silos between development and operations and then help driving efficient and seamless collaboration and communication between them. So DevOps, this cultural shift, it's meant to impact the entire software delivery life cycle and help reduce time to market without compromising quality. And if you look at traditional older ways of working in SAP environments, there were often stock divide, and there are stock divides there between development QA and operational teams, which impacts agility and slow time to market due to how these teams collaborate and actually communicate. So years ago, it became apparent that if you wanted to become more agile, you would then have to break down those silos between departments because that in essence is where some of the biggest issues actually lie. But here's the thing about breaking silos. You can't do that without address without addressing the embedded culture or ethos across SAP business and IT teams. So if you're gonna be looking to affect and change culture to adopt DevOps and SAP, there are a good couple of things that are gonna need to be addressed, and I'm gonna mention three of them. This isn't an exhaustive list, but I wanna touch on these two things. First,ly, and I think this applies to anything within an organizational enterprise kind of culture. You need leadership buy in. I mean, we can sit there. We can talk hours about how to actually influence culture within an organization. And without leadership buy in, without executive sponsorship, you cannot change culture without senior stakeholders involved who are committed to the outcomes that you're working towards. Without leadership who understand the value of agile and DevOps, it's gonna be very difficult to secure all the necessary investment required to train up your teams, very difficult to get investments to, implement process changes, and very difficult to get sponsorship and resources in order to go and procure and implement new technology. So that's number one. The second thing you need to do is set expectations correctly. DevOps is not gonna be a silver bullet that's gonna be working for you overnight. It's not something, that you're gonna be able to implement enterprise wide, like Paul was saying initially. Right? DevOps should be something, and agile that goes with DevOps should be treated on a per project kind of basis. And I'd like us to start thinking of DevOps as a journey, not just a destination. Adopting DevOps as a culture can actually then take time. It's not something that you're gonna implement, in a week as mentioned or even over a couple of weeks or even over a month. It requires working with the right people, ensuring those people are skilled correctly. You're gonna be implementing the right processes to support those people. And then, of course, with the right technologies, you're gonna then be able to support the processes and the people which then work together while you're instituting that cultural change. So this goes back to that necessity of having leadership buy in who can help make the right investments and keep things moving forward when obstacles are encountered because you are gonna encounter some obstacles, some difficulties, you're gonna need people at a very executive level who are gonna help you then drive things forward when you are encountering those roadblocks. And then I'm gonna end on this third one. I mentioned there are a couple of other things, but I wanna just highlight three. The third one being you need to address fear of change. There is more fear of change when it comes to SAP ecosystems because SAP systems really support mission critical processes. They are so interconnected to all the critical processes that run so many organizations. So there is a very natural fear of disrupting operations. So teams may hesitate to adopt practices like continuous integration and frequent deployments worrying about potential impact on stability. Now as a technologist, of course, I know there are ways to help manage all of that with best of breed technologies and best practices. So things like test automation, change manage change management test data management solutions, and so on, which could go a long way to alleviating those kinds of concerns. Big, Nick. Also sorry. Marias, you'd said on the final point there, Nick, just in terms of, you know, that fear of change and, you know, what happens if we break our sales order process, for example. I think the changes that are happening with BTP and people moving processes, some of the extensions out to BTP moving towards, cleaner core, which is a whole other discussion, which we could, I'm sure, have for hours. But I'm sure that, change in the way that, people extend around SAP will help with this. Because if you're doing something in BTP rather than directly in the SAP system, you are, from the outset, at arm's length. Your apps in BTP can only interact with your core ERP solution via APIs that are enabled to do so. So it will, I think, foster some relief around what could be the impact if you're only working through those defined interfaces. Whereas, obviously, inside the core system, being able to make changes in, you know, not just the objects that Chris referred to, but also changes in customizing that, you know, we might end up sending, entries through from one customizing table, not realizing that someone else was in progress with some partial piece of work on there. And we then create a conflict or create something that now in the QA system and then onto production if not spotted, we'll actually break a fundamental process. So I do think as people make their journey to S4HANA, as they look at what they will be bringing from said programs and modifications, which I'm sure won't be everything, but some things will move to BTP. I think that will give them a slightly different view on the risk of becoming more agile than using DevOps. Yeah. That's brilliant, Paul. And thank you. I think the conversation naturally steering towards S4HANA, which was my next question. And, you know, the fear of change, as you said, Nick, is it's very real. And I believe within the SAP ecosystem, the change speed has been definitely ramping up. Even last last week, yes, at Unleash, SAP announced a series of new things and changes and partnerships with Databricks and whatnot. And this is all adding to that big change, mindset that's been going on and that now we all need to start adapting to. So my question is, Nick, how do you see DevOps practices or agile practices? Maybe, adding into what Paul already mentioned, impacting as for HANA transformation projects specifically. So it's is it a good time for people to start thinking of how to build that process? So to make their transition to us for HANA, a good one or not? I think it is a really good time going back to the entire discussion that we've had today. So things like being able to weave DevOps as a cultural change, the ability to use change management solutions to ensure that you're working correctly with objects, that you're not syncing objects that might conflict, and you've got that whole dependency structure built around it. Being able to create some of your customization, shift it out of your core, and move it into BTP makes it a lot easier to adopt things like, DevOps and agile practices. So the answer is, I think, absolutely, yes. DevOps can absolutely have a profound impact on s four hanger transformation projects. If you've got that right combination of people, process, technology, and data, This is gonna certainly help drive efficiency, agility, and quality throughout the implementation life cycle. So assuming you've got the right people, you've upskilled them, they know how to use the various tool sets, toolsets, how to implement the right processes, how to put in monitoring capabilities in order to handle all of this. The answer is a definite yes. So a couple of things come to mind, and, again, I like using the rule of three. So three things that I wanna maybe mention over here. So implementing DevOps correctly in an s four HANA transformation project, you're definitely gonna see accelerated development and development cycles because, ultimately, that's the goal of DevOps and agile. Right? Being able to release more, release faster, at the same time, derisking your organization and increasing quality. So by being able to automate your CICD pipelines, it's gonna allow for faster and more reliable, delivery of changes in your S4HANA transformation, which is absolutely critical, especially when it comes to implementing iterative changes, those custom extensions that we've been talking about, even larger, large scale kind of enhancements during the actual migration. The other big topic today has been breaking down silos. So in a project context, we're able to break down silos, improve collaboration between developments, between project teams, between QA and operations. This certainly gonna make things a lot more streamlined and move bottlenecks out of traditional processes. And thirdly, what you're gonna see when implementing DevOps and Agile properly, you're gonna see enhanced testing and quality assurance. So with the right tools, the right methodologies, automated testing can certainly help ensure that you're testing earlier in the life cycle as part of a shift left kind of methodology, catching defects earlier, but very importantly, helping remediate much earlier in the cycle with the added advantage of also increasing test coverage. All of this working together to ensure faster release cycles without, again, lowering that quality bar. Brilliant. Thank you, Nick. Chris, do you have anything to add from your side? Anything that you've seen that transport management and change management can help, during this very, very complex project? Yeah. Look. I think touching on almost one of the last things Nick said there is the shift left is just so important for us. We're sitting inside of the development system monitoring what developers are up to and, you know, not just spying, but also assisting them and making sure that they're taking the best decision making as early on as possible. As soon as we're sort of assessing what's going on, we're running necessary checks. The checks that make sure that firstly, there's not gonna be downstream or down pipeline problems because of dependencies or those conflicts. But the other interesting thing is also starting to have a look at the quality of code. You know, during an s four transformation, running s four readiness checks at the time that the developer is making the change and before that transport is allowed to be sent across an old ECC system, that's usually advantageous. You can start turning these checks on months before you even commence an s four transformation and actually have your code pre s four ready prior to doing a brownfield transformation. That could be megabucks, when it comes to actually starting that process of the digital transformation because your code's already ready to go, and it's functional in your old ECC production instance. That's super powerful. So not only is it shifting left, it's shifting left pre project. You know? So those are powerful concepts in being able to use or make the right decisions at the right time. As soon as a project is almost, decided upon, the these things can be implemented. So they should, and they should be enforced to an extent. That's another big thing I'd add to what Nick's saying is if you can enforce this behavior, you're effectively enforcing culture. Right? And when you have a team of people and more likely, maybe, a combination of some outsource partners, some in house skeleton staff, maybe some contractors that come in and come out on occasional work, They've all got their own interpretation of how to do things, but if you can sort of give them some good guidance on this is how we do things at this organization and doing that as early as possible, as soon as the decision is made to implement that type of culture at an organization, then that is, I agree, the best place to do it. That shift left is super powerful when it comes to transformations, but also implementing that DevOps culture in mindset. Brilliant. Thank you. And finally, Paul, if we bring everything that we've said today back to practicalities, how can Appius Labs, Worksoft, and RefTrack or ISC, assist clients in becoming more agile, in particularly in the testing aspect of DevOps. So you mentioned, Maria, the announcements, last week, and I think that was around SAP business data cloud and bringing data sphere in with analytics and the business warehouse, pulling that all together because SAP is hearing from their, customers that they aren't able to get good enough data to be able to really unleash, the powers of AI. And that's then being brought together with, what they call insight apps, which is essentially SAP giving you prepackaged, AI functionality, again, at this safe distance from BTP. It's not messing with your core system. It's not trying to change your processes. It's giving you insight from a safe distance as all well and good. But to really capture the capabilities that LLMs are bringing and are gonna increasingly bring a speed that's been staggering, I would say, you will need to start to get closer to your core business processes. So this has to come. This will come. So the fact that RevTrack can give you that awareness of who else might be working in a particular area in your core system, being able to track as changes happen on those objects and to see things that could actually harm you in your potential future path. So the example Chris gave there was great. Constantly monitoring, is this system going to be able to go through a brownfield migration, or are we introducing things that will cause a problem? Because those can be difficult to spot. You know, you've heard examples of a developer looked for a data type and just happened to pick something that was actually defined in IS Health Care, and IS Health Care doesn't exist in Espahana. So you've suddenly inadvertently used something that you've not got a lot of, likelihood of spotting is obsolete. It's something easy to hand. So I think that part is clearly going to be, helpful as your organization is pushing to try and really bring the value that LLMs can bring into that core business and those core processes. And then from the Worksoft side, Nick and I have talked through, an amazing number of ways that we can integrate our technologies. But what I've seen from Worksoft, the capability for them to be able to automate, not just the things that you might think, the actions inside, SAP itself, but also the other activities that the human would typically do. So being able to, for example, pick up files that we'd created with input data to run as part of the testing to be able to go get those files, from the server to a local desktop to be able to unzip the data, load the data in, to Worksoft. It can drive all sorts of automation for things that previously were manual tasks. So this really can, allow you to accelerate the pulling the pieces together, getting the information from different systems, getting the data from different systems, and then running through those automations. And I think that was also one of the things in the sat inside responses that was clear was organizations wanted to automate testing. They recognized that they've maybe held back from, really taking on change in their SAP systems. Many organizations for years have just gone through these technical upgrades. You know? We'd love to look at the new functionality. We'd love to get everybody together and really see how it could revert to standard and bring in new capability, but we're just all too busy. So we're just gonna do yet another technical upgrade. And they've created that debt, and now this project is the debt is the project where they're gonna try and pay off that debt. And so with so much change coming in, they have to automate the testing. It's absolutely inevitable. So that's where I see Worksoft playing a crucial part, just enabling people to accelerate the rate of testing in a way that doesn't mean adding, you know, three times as many people to their testing center of excellence. And then, of course, from our side, we bring the data. So, I think the SAP Business Data Cloud is SAP's attempt to try and look at the fact that people are struggling with bad data in, you know, garbage in, garbage out. This is what people know. And for us, looking at changes that need to happen inside the core, system and being able to make sure that you are testing on the valid data, the right data in terms of if you're looking at, you know, the master data that's required for a particular process. If it's not current in some businesses, in some organizations, it fundamentally negates the value of the test or in some cases, completely breaks the test. So us being able to allow Worksoft to automate the updating of data as part of the process, but also sometimes to be able to identify and help identify what makes a good test set. So there's work that, that Nick and I and our collective engineering teams are doing to see how we can take that even further to be able to automate the selection of what should be tested as well as the actual testing that happens underneath. Brilliant. Thank you. Thank you so much. Any final thoughts before we end this, wonderful conversation today from Chris or Nick? Anything to add? I do. You did ask me prior to us meeting, if I could share something on the, SAP road map specifically and, how I thought that could impact the need for more agility. And I did put some thought together on this, and, you know, we manage it's about two hundred and thirty, two hundred and forty different customers. Generally, the larger customers find themselves to rev track or those who are interested in compliance, or just wanna go real fast as we say. But we get a good understanding of how they're using their SAP systems. And because we're in the business of change, it's interesting because we kind of measure where are you doing your change, what sort of change is going on. And, you know, right now, SAP's road map is clear. I define it as one word cloud. Okay? They wanna shift everybody to the cloud. It's happening in a few ways. Obviously, the BTP is largely replacing what net NetWeaver did, but it's not even close to the same. You know? It's Cloud Foundry, so it's very flexible, and it's built in an environment where people are very used to working agile. DevOps is that's old. They don't talk about it because they fixed it, generations ago, in this area. But, you know, back to supporting what Paul said around the structure is fundamentally underneath that BTP is sitting in an s four system. And, again, aligned with the road map, the customer base is gonna split into a few different pathways. Ultimately, SAP would love everyone to be on the public cloud. You get automatic, updates. It's just a tenant, and everything works. But I would say that ninety nine point nine percent, pretty much all of our customers anyway, will not be going that path. They're gonna be sticking with a private instance either through WISE or s four private, or they're just staying on premise. And then that BTP will plug into the s four system. And what's gonna happen is you're gonna have, the BTP taking on more and more of the change. Right now, we we always talk like this in our meetings. Where are we at? And it's BTP and ABAP. And we suspect of our customer base about three to five percent of the change that they're doing today is BTP and ninety five to ninety seven sitting up here with the ABAP. And we suspect over time, it's going to start becoming more normal. In fact, there'll be a tipping point where more change, more innovation, and more, of that certainty that the customer needs is actually happening on the BTP. So I actually think that's going to be one of the driving forces that mean the ABAP team's going to have to get their act together and get in check and drive that let's get agile because these guys can move so quickly on the BTP side because they've got these tools that have been around for generations, and the ABAP teams are going to have to align because they're going to be delaying innovation. So that's one of those pull your socks up moments I do think is going to happen based on just the way the market is going. The BTP team is probably going to sit there and go, guys, when are you gonna be done? We need to go with this. And that's also a cultural thing that's probably going to, force the ABAP and those s four guys to get their house in order and get their DevOps in check, if you know what I mean. So that's a little bit about the road map forcing that need for agility, and it's going to be, I believe, anyway, you know, just guessing how things will go. It'll be a bit of a culture demand that comes out of this team that can innovate and perform, at the pace that most people are used to, most of the industries used to, and it's gonna force those s four people, into alignment. And that'll be good for everybody, but, obviously, we've a lot of work to do to be able to get there. And, again, that speaks to everything we've discussed today. So those are my thoughts on the road map anyway. Thank you, Chris. That's great. Well, I think, just to finish off, whether you're gonna go through change slowly or very quickly, you're going brownfield, greenfield, moving to Westpharma, definitely, this is the time to really look at your at how can you be more agile within your SAP development. I guess the answer to the question is DevOps dead. No. I don't think it is. Maybe we'll call it something different. It'll change its name. We just want to become more agile. And there's definitely a lot of hope in the ways that we can achieve the agility with the SAP development, of tools and change in general. And we can see here today, with test automation, test provisioning, and change management, this really can be achieved. So if you want to find out more about the technicalities of how we work with Worksoft and with RedTrack, We have two upcoming webinars, one on the sixth of March, and that's gonna be about Worksoft, and you're gonna see all the functionalities, how Worksoft, two, and DSM work together and really help with that test automation. And then on the twentieth of March, we're gonna be looking at RedTrack. And, you're gonna see demos. You're gonna see, a lot of technical, and you'll be able to ask all of the questions there and then. We will be sharing all the details and all the links to register, in the follow-up email that will go out, after this session. I hope you've enjoyed it. Chris, Nick, and Paul, thank you so much for all of your brilliant insights and your expertise that you brought to the table today. I hope you had a good time as well. And, yeah, thank you very much. See you next time. Thank you, Barbara. Thanks, everybody. Appreciate your time. Bye. Bye.