In the old-time, you had the SAP R3 ABAP system. There it was a pretty good tool to do change management. There was a limited number of objects that you could change and they could all be managed by one way of handling transports. In the new world, it is a lot more complicated.
Now the landscape is completely different. You have many different services that you need to find a way to manage. And if you start using SAP cloud solutions many of them have their own way of handling transports.
I have created a video to show, how I see the concept in some more details.
You have two options for Change Management: A generic approach or a specialized approach for your most important systems.
Generic Change management
No matter what you need to develop change, everything is handled in the same way. Then all developers know how to do change management for everything. It will speed up making it possible for other developers to handle the tooling.
The downside is that you will need to make a process that can encompass all systems. You will, therefore, get to little information or spend to much time creating the documents that you need for your project.
You may also miss an important part, and that is the ability to like changes both ways
Tool specific change management
If you have a lot of development or highly critical tools. It does make sense to have a better way to handle it.
When we are working on our Java application for the Figaf tool. We use Jira to create tickets in, Developers will then use this ticket number for all commits to a given ticket. Changes to our unit tests are also linked with the ticket. That is allowing us to trace all changes back to a ticket. That is a hyper-specialized tool to make change management for just one case. It can then be bundled with Jenkins to make build and test automation.
This type of specialization of your change management saves you time for your development. Because developers don’t need to note all the different places they are making modifications. It is handled automatically by the tool and captured as a part of the change.
Sure it will cost you more to buy or create an environment. It will cost both money, time and effort to get it working. Hopefully, this investment will be returned with better documentation, easier change management and faster delivery of code.
If you are using SAP Integrations products like SAP PI/PO, CPI or API mgt then we have a tool that will allow you to optimize your delivery process. Check the tools at https://figaf.com/IRT there are even free versions that allow you to get started.
With our approach we will handle all the tool-specific requirements in our application and then let your original system containing all organizational data.
If you want to see how our tool works to make DevOps possible check this video