In the old days, 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.
Watch on YouTube Change Management. Specific or Generic Appoach
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 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 too little information or spend too much time creating the documents that you need for your project.
You may also miss an important part, and that is the ability to link 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. 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 integration products like SAP PI/PO, CPI or API Management, then we have a tool that will allow you to optimize your delivery process. Check the Figaf DevOps Suite or start a free trial.
With our approach we will handle all the tool-specific requirements in our application and then let your original system contain all organizational data.
If you want to see how our tool works to make DevOps possible check this video
