2 years is a lifetime

At last year’s Devtoberfest (Octboer 2022, if you wonder how long it sometimes takes me to publish a post) there was a live session with SAP’s CTO. One part of the session was about APIs. You can watch the replay: at minute 15:40 Gregor Wolf asked a question about API and deprecation.

SAP API Deprecation Policy

The answer provided by Jürgen Müller was once to state that the APIs are stable, and therefore also upgrade stable. Moving to a newer SAP release should be not a problem at all, normally. The second part of the answer was about the availability of the API (public ones). If you are using an API now, and you update your system, you want to have the API still available in the new system. If not, your app will stop working. The answered highlighting an official document on this topic (jump to minute 17:00). The short version is: any productive API will be active for a minimum of 24 month. If the API is deprecated, it will be at least 12 month in deprecation state before it is decommissioned.

The API deprecation policy is available here. This policy is for the public APIs (there is also a policy for CDS views), published at api.sap.com and not for the internal APIs you can find in e.g. an S/4HANA system. The published APIs are the ones that SAP has full control over. If you use these to communicate with your SAP system, the policy applies and is important.

The policy explains very nicely what the implications are for an API. Any productive API has a minimum lifespan of 2 years. “SAP will provide a minimum lifespan for non-Beta APIs of 24 months in Active or Deprecated states before announcing a Decommissioned state. For example, the minimum API lifespan ‘M’ for an API after it is published in Active version V1 is 24 months, where M is defined as the combined periods in Active and Deprecated states.” [SAP Help]

Life expectancy: 2 years

The minimum you get is 2 years. Ignoring any exceptions like security issues. It could be more, but not less. Lifecycle is Beta -> Active -> Deprecated -> Decommissioned -> Deleted. This does not look strange, or off the reality. Taking a closer look at the example from the policy, the minimum time the API makes sense for business is more complicated and shorter than it seems.

You can’t use the beta API, as SAP states that it is not intended for productive use. Oh, and SAP can always delete beta APIs. You might use decommissioned APIs, but the risk in doing so is very high. SAP can remove the API at any time and your solution stops working. And if your app stops working, it’s your fault. Therefore: do not use decommissioned APIs. Everything green in the graphic is where customers can use the API.

You start using the API when it is active / public. If SAP sets the API status to deprecated after exactly one year, you get one additional year to use the API. Makes 2 years. If SAP sets the status to deprecated earlier, you still get 2 years in active mode. Looks good? Well, depends. If you start using an API that is set to deprecated, it will be moved to decommissioned at one time. It’s a high risk building a solution around a deprecated API. You’ll have to start evaluating alternatives / successors as soon as you decide to use a deprecated API. Basically, deprecated is tech speak for: no, do not use. If your project uses an API that is 1 ½ old, and since ½ year deprecated, you might only have 6 months left before it is removed and you must adjust your solution: design, coding, tests, etc. Even for an API that after 366 days is declared as deprecated: start searching for alternatives.

With this in mind, the best time you get from SAP for your worst case scenarios is 1 year in which you can run your solution. 365 days in active, and at day 366, it is deprecated. In the worst, worst case scenario, the active API is set to deprecated at day 1. While you still have 2 years to use it, you must start looking for an alternative as soon as your project starts.

The happy phase – the green boxes – where you can use the API is 1 year, counting from when the API is set to active. Everything on top is bonus. Be fast when it comes to API adoption. If you enter the lifecycle too late, you will have to cope with more problems.

Is two years not enough? Coincidentally, the 2 years minimum active phase matches the 2 years support cycle of S/4HANA. While you can upgrade to a newer S/4HANA release every 2 years and given that you did everything right in regard to clean core, you might be able to upgrade. But also check the APIs you are consuming. It won’t help you much when your S/4HANA is upgraded without any effort, but the API of another SAP system you consume was set to deprecated a year ago and is deleted tomorrow.

Implications

What are the implications? First, SAP does nothing unusual here. Many APIs from other vendors are also deprecated from time to time. Many APIs simply evolve over time (1.0.0 -> 1.5.9 -> 2.6.2). The question is as always: can we apply what works for others to SAP powered business scenarios too? It takes time at customers to adopt to a new solution. The number of customers that will start using in productive usage an active API at day 1 is close to zero. Planning, evaluation, coding, testing, roll-out, all takes time and even when it only takes 3 months, the intended usage time of the solution might be 5+ years. Deprecating (and even deleting) an API is common. Any project should be prepared for this scenario. The question is how much of a PITA the change this triggers will be. Is there a successor in place? Is it API compatible? Are the criteria which lead to a deprecation transparent? Can this be influenced by customers?

Example

The post was partly already written shorlty after Devtoberfest 2022. I adjusted some content now as I came across the following APIs for Enterprise Product Development.

Some APIs are deprecated. The API for conversion was deprecated in February 2022.

Today is July, and February 2022 is longer ago than 12 months. This API can be deleted any time. The promised replacement API is not listed. I guess that there is no successor. The risk using this API is very high.

Alternatives

I’d like to see some better guidance on the API lifecycle. What leads to a deprecation should be clearly communicated and transparent. Is it a lack of users, adoption? If so, at least say this to customers and make the numbers available. When customers have the transparency to understand what leads to deprecation and they can anticipate this, dealing with the risk is manageable. In fact, the risk is almost eliminated.

The minimum lifecycle should be 3 years, that is: 2 years at least active, with deprecation adding at least 1 year.

Successor: SAP can deprecate APIs when there is an compatible successor available. If version 1.1.0 is available, 1.0.0 can be deprecated. In case the successor changes the API and the app can break because of this (1.0.0 -> 2.0.0), deprecation should be 2+ years with a total lifetime of at least 4 years. Same 2+ years when no successor is available.

Deletion: With a successor in place, SAP can still delete APIs like today. Without a successor in place, the deletion should only occur after an additional year. While the API might not be maintained any longer. This should also give customers enough time to not only search and implement an alternative, but to also manage the transition period between both solutions. This will give 5 years to an API that is going to be deleted without a successor. 3 years after announced the API deprecated should be enough time for customers to adopt.

While this still might not fit the project timelines for a S/4HANA based solution, it will drastically reduce any risks associated with SAP APIs.