Many of us enjoy a freshly baked donut. We not only think of the delicious taste, but also of the shape – a ring. And although you might reflexively think that the article at hand is dealing with the analogy of the outer shape of a donut and the Application Lifecycle Management ring, I will not go into that, but rather into the difference between plan-driven and value-driven development and their problems.
The question of why certain features are still missing from SAP Cloud ALM is particularly interesting. Many customers ask precisely this question: why is this or that feature still not available? I am not trying to defend SAP here, because it could certainly be argued that with more or faster developer resources, some things could be implemented more quickly. But for me, it is more about creating an understanding of the challenges: How do you balance the pressure of customer expectations with long-term vision and quality assurance? This is precisely where the difficulty of combining both stability and flexibility in a plan-driven approach to deliver sustainable value becomes apparent.
From SAP SolMan to SAP Cloud ALM
SAP Solution Manager (also affectionately known as SolMan by the community) will no longer be covered by mainstream maintenance from the end of 2027. Although SAP Cloud ALM is not a direct successor to SAP Solution Manager, as there will be no feature parity, it is at least the logical successor.
And it is precisely here that the connection between a doughnut and SAP Cloud ALM arises. We have already established that almost everyone knows that a doughnut is ring-shaped. Many of you also know what a good doughnut should taste like. And SAP customers know what the SAP Solution Manager looks like and what ALM functions it offers. It is therefore obvious that these are the functions that are expected of the “successor product”.
The Solution Manager can therefore be compared to a well-known doughnut recipe. It is a recipe and a preparation in which we know exactly which ingredients belong and what the end result should be. It is a proven recipe that is loved by many.
The development of SAP Cloud ALM, on the other hand, represents a completely new recipe and approach. It is no longer developed in a plan-driven manner, where the end product and its features are fixed from the outset. Rather, it is a value-driven approach that prioritizes customer value and benefit.
Value-Driven vs. Plan-Driven Development: A Recipe Duel
Understanding the differences between value-driven and plan-driven development is important to recognize the benefits and challenges. Here is a comparison:
Plan-Driven Development (PDD)
PDD is based on a systematic and sequential approach in which each phase (requirements, design, implementation, validation) of software development is strictly planned before it actually begins. The scope of services is fixed, while the costs and deadlines are “variable” or the levers that can be adjusted.
- Planning: The main focus is on advance planning. It is expected that all requirements will be determined at the beginning of the project and that little or no change will occur during the course of the project.
- Documentation: PDD emphasizes the importance of comprehensive documentation. Each step is documented in detail to ensure that all parties involved understand the process and requirements exactly.
- Flexibility: PDD is usually less flexible with regard to changes, since changes are often costly and time-consuming, especially if they are made late in the process.
- Risk management: PDD tries to minimize risks early on by planning everything in advance.
- Examples of methods: Waterfall model, V-model.
Value-Driven Development (VDD)
VDD focuses on creating continuous value for the customer or end user by relying on feedback and iterative development. With this approach, the costs and deadlines are “fixed” and the scope of services is variable. Good, agile requirements engineering is a must for VDD.
- Planning: Instead of strictly adhering to a predetermined plan, VDD flexibly adapts to new information or changing customer needs.
- Documentation: While documentation is still important, it can be less extensive in VDD than in PDD. The focus is on functional software and customer feedback.
- Flexibility: VDD is very flexible with regard to changes, since the approach expects that requirements may change over time.
- Risk management: VDD accepts that risks exist, but relies on minimizing them through regular feedback loops and adjustments.
- Examples of methods: Agile development methods such as Scrum and Kanban
Plan-driven Development: As familiar as a glazed doughnut or an SAP Solution Manager
A few years ago, SAP Solution Manager was developed. A platform for implementing and operating SAP solutions (mainly for on-premise products). The recipe is fixed, the ingredients are known, and the result is predictable, i.e. the principle for the development of SolMan was largely the systematic approach of “plan-driven development». Similar to an architect who plans every detail before construction begins.
The challenge of change: SAP Cloud ALM
Imagine you are standing in a modern doughnut bakery. Instead of just baking a set doughnut, the baker experiments with different ingredients. He first brings you the naked dough ring, the basic structure – a minimum viable product (MVP), so to speak. For some, this is already enough, others wait for the icing, still others for the sprinkles, and based on the feedback, the baker can gradually (in several iterations) refine the doughnut. Still others give feedback and demand a certain filling. Which way is the right one?
The development of SAP Cloud ALM is reminiscent of the trend towards experimental doughnut flavors. SAP Cloud ALM was also developed for the implementation and operation of SAP solutions, but with a clearer focus: for SAP cloud products.
Agile development at SAP Cloud ALM is now like the baker stopping by every two weeks and saying, “Try this!” But instead of a full doughnut, there might only be one bite. Some customers are excited about the quick delivery and the opportunity to provide feedback. Others might be disappointed that the doughnut isn’t “done” yet.
A world of flavors that is constantly changing
Just as the world of donuts is constantly evolving – just think of trends like cronuts or donut burgers – so is our world of information systems and general conditions. The most important thing is that we are prepared to adapt, provide feedback and be open to the countless possibilities that lie ahead.
Value-driven development requires flexibility and openness to change. And while some customers appreciate the opportunity to design their own “donuts,” others find it challenging to constantly adapt to new flavors.
A shift in mindset is needed in at least three ways:
- Development teams must adapt so that they are able to actually develop a product in an agile way.
- Customers must develop the willingness and acceptance that not every function already adds 100% value, but that sub-functions can be used more quickly and at least add partial value.
- Customers must embark on a journey and not just demand functions because they “have always done it that way”, but question whether alternative approaches could bring even greater benefits.
In a constantly changing (digital) world, we should perhaps all adopt the values of doughnut lovers a little more: curiosity, flexibility, patience and an open mind for the next potentially best and sweetest bite of doughnut innovation – even if one or two attempts don’t taste so good.
