DevOps - Breaking Down Walls

DevOps stands for the fusion of software development and IT operations and describes more a philosophy of collaboration than a clearly defined methodology. What does DevOps generally consist of?

Jörg Landwehr: There are no clear rules that can be applied to DevOps. There is no one DevOps manifesto that defines what teams should or should not do.

Rather, DevOps is a flexible approach to work that can be adapted to the needs, processes and resources of any organization.

I was once told that DevOps transfers the principles of industrial manufacturing processes to the delivery of code. Nevertheless, there are some basic building blocks that support the shift to DevOps regardless of the starting point, namely agile software development (process), a culture of collaboration (people), and the appropriate automation tools (technology).

Implementing DevOps is difficult unless at least small progress is made in all these areas. But 100 percent is not even necessary at the beginning. Making improvements in just one of these fields can bring about huge improvements or even drive the entire DevOps transformation.

DevOps is often associated with continuous delivery. What is the difference?

Landwehr: Many use the terms DevOps and continuous delivery almost synonymously. This is not completely wrong, but there are some differences.

Jez Humble, expert and author on the subject of "continuous delivery" says that it is the ability to take changes of all kinds into production and thus put them into the hands of the user - safely, quickly and sustainably. We achieve this by ensuring that our code is always "usable.

DevOps can be seen as a more business-oriented approach, because it encompasses far more people and processes. However, it is not possible to speak of a clear demarcation; thematically, there is a lot of overlap.

At SAP, the impression is that continuous delivery is a result of DevOps. But I think it is more a result of goal setting after DevOps was integrated.

What are the main advantages of DevOps compared to classic methods?

Landwehr: A key advantage of DevOps is that current business needs are the focus. This means that an IT company must be able to respond to changes in requirements, e.g., due to customer requests or a disruptive new competitor.

In general, costs and risks are lower with DevOps and time to market is significantly shorter, resulting in better products and significantly more satisfied customers.

Teams that rely on classic approaches like waterfall development are not able to adapt to new circumstances as quickly. Problems are usually found later, are harder to diagnose and more expensive to fix.

DevOps also brings important improvements such as security and stability of applications and, incidentally, an increase in employee satisfaction and retention.

What challenges does a company have to overcome when implementing DevOps? How can the greatest possible resistance be overcome and a new culture of collaboration established?

Landwehr: When we talk to customers about DevOps, we realize that the biggest issue is the attitude towards work approaches and how teams work together, not how they are "officially" put together.

Everyone involved in a company project, for example, must become an owner of products and processes. The transition from silos to interdisciplinary teams with diverse skills is the key here.

However, this does not mean that the entire organization has to be turned upside down. Just a change in attitude towards the way of working and a corresponding new approach can be sufficient.

However, the question of organization can actually be a challenge here, and that is when important parts of the management of an SAP system have been outsourced to external partners.

The teams involved may not be in the same country and may also not have the same vendor. This can lead to a complicated situation, but one that can be overcome with enough focused work and communication.

What impact does DevOps have on the error rate in SAP projects?

Landwehr: The benefits that developed DevOps processes bring to an SAP landscape can be enormous. However, it must always be remembered that many benefits become apparent at the beginning, when long-term developed processes are still difficult to foresee.

We have customers who have reduced the error rate in production by 60 to 70 percent simply by using good tools and more automation. And that's before they got serious about agile software development and DevOps.

To what extent has DevOps already been implemented in the SAP communities?

Landwehr: If we are honest, we have to say that DevOps for SAP is still in its infancy when you look at the market as a whole.

Agile software development has enjoyed greater appeal so far. More and more teams are finding that agile development works in SAP, and I have the impression that this fact is also opening the eyes of stakeholders to DevOps.

No matter what the reason, DevOps is growing rapidly. In the last twelve months, we've seen an increase in organizations coming to us asking how we can help implement DevOps for SAP.

Some of them are already very far technically, but others would rather be described as stuck. Interestingly, even some of the traditional SAP users are now thinking about the benefits DevOps can bring to their business.

But there is still some time to go before DevOps becomes the norm in SAP environments. There is no doubt that the approach will gain in importance over the next few years. Companies simply need to make sure they have the right tools and processes in place to make it happen.

What are the differences between SMEs and larger companies?

Landwehr: DevOps is suitable for all company sizes. And as with all things, you have to ask yourself whether the results are worth the effort. The larger the company, the more likely it is to have a large and complex SAP landscape in which a great many changes have to be delivered.

Everyone can imagine that large organizations can achieve considerable benefits thanks to DevOps. For SMBs with lean IT teams, agility for role changes and new processes is much easier, leading to faster success.

DevOps and automation tools, like the ones we offer our customers, can also be very helpful for small teams, allowing professionals to focus on the work that really matters.

With the Hana Cloud Platform, SAP was able to develop microservices within the S/4 core. Is the new SAP paradigm suitable for the transition to DevOps?

Landwehr: DevOps is very widespread and covers many different areas of the IT world. Accordingly, drastic improvements cannot be attributed to a specific technology or concept.

However, the services provided by HCP to consume applications allow a greater focus on developments for enterprise purposes rather than technical rework, which is definitely in line with the DevOps philosophy.

No matter what specific technology is needed: We see S/4 Hana, HCP, etc. serving as a bellwether for many companies to re-evaluate how they manage their SAP systems.

These new options provide opportunities for much broader consideration of the use of existing methodologies, the composition of teams, tools, etc.

A very large multinational customer took the opportunity of the transition to S/4 Hana to review their entire SAP tool chain to adopt a modern best practice, which resulted in our DevOps toolset being selected to support the transition process.

With the DevOps toolset, you give companies a tool that simplifies the transition. How important are these tools for DevOps for SAP?

Landwehr: The importance of tools cannot be overstated, mainly because automation is an absolutely vital component in the DevOps concept.

At the end of the day, it is automation that provides the security and speed that makes DevOps stand out. For some organizations, this presents a challenge to some degree.

If DevOps has already been implemented outside of SAP, it is most likely that tools (such as Jenkins, Chef or Puppet) are already in use. The assumption is usually that these tools and the processes executed with them can be easily applied to SAP.

But the reality is that the specific nature of SAP requires special tools like our DevOps toolset. This gives users the SAP-specific automation they need, such as transport sequencing, checks for object dependencies, releases, deployments, and merges across different systems.

It is also important that SAP-specific tools can be integrated into the broader DevOps tool chain. Our DevOps toolset does just that, offering integration with Remedy, ServiceNow, Jira and more.

We also support the more people-oriented aspects of DevOps, such as a central dashboard that can be used by all users. One of our customers recently described this as "breaking down the walls" between SAP teams working in different countries.

What do you think is the next hot topic in connection with SAP and DevOps?

Landwehr: For us, testing is currently the hottest topic. Even in organizations that have already successfully implemented DevOps for SAP, regression testing can be a real challenge.

Typically, there is no time to perform a comprehensive regression test run for each SAP release because the systems are far too complex and changes occur at too high a rate.

We have been thinking for a long time about how to address the problem to make regression testing more practical, especially when SAP releases are shipped very frequently.

To do this, we have now launched a product that is capable of doing just that. It's called Testimony and it uses a completely new approach that eliminates the many hassles and costs of traditional solutions.

It's also not just tied to DevOps environments, making it a veritable marvel for large-scale projects like moving platforms to the cloud, and definitely has the potential to support a higher rhythm of regular changes. This tool is currently making our everyday life enormously exciting.