If you work with any SAP Integration you have probably been asked about some documentation that is part of the governance process.
All the places I have worked with had some different ideas about what you would need as a governance process. Some good, some bad and some overkill.
Governance frameworks
There are a number of frameworks that defined which type of integration you need. Here are some examples:
- Sarbanes-Oxley Act (SOX) – U.S. federal law mandating certain practices for financial recording keeping and reporting by corporations
- General Data Protection Regulation (GDPR) – European law regulating the acquiring, handling and storage of data in the European Union
- Health Insurance Portability and Accountability (HIPPA) – U.S. federal law stipulating how patient medical information can be handled by healthcare and healthcare insurance providers
- Information Technology Infrastructure Library (ITIL) – List of practices surrounding IT activities to assist with aligning IT services with business strategy and needs
- Payment Card Industry Data Security Standard (PCI DSS) – Information Security standard for the handling of credit cards by organizations
- GXP – Guidelines and regulations stipulating “good practice” based on your industry (example, GAP for good agricultural practice)
- International Organization for Standardization (ISO) – International organization that set technical, commercial and industrial standards for different industries (example, ISO 9001:2015)
- Country Specific – Local, state, regional and national laws that can regulate business activities and/or tasks within your organization
These frameworks contain much of the same requirements plus or minus a few things. Moreover, in the terms of your requirements once it comes down to the developer level it is essentially the same thing.
What is important to document?
- How each change is made on which objects
- The ability to link all changes or development to a reason like a change or service requests. So all changes originates because some business use asked for it
- The separation of duties: No developer should have access to make changes to the system alone
- Documentation of which configurations to apply in an given system
- An approval process to ensure that people have done the work correctly
- A verification process to show that you have performed a test to ensure you know the impact
It is not easy as a standard.
You can be using your sharepoint/wiki to host the different changes that happens to the landscape.
As you can see from the survey question result (screenshot above), a majority of people use File Import/Export for transporting their integration. Yet, unfortunately that method of transporting integrations is not great governance.
SAP ChaRM added some extra capabilities to the mix in terms of having the correct approval process. However, just like CTS+ or SAP Cloud Transport Management, it can be difficult seeing what is being transported. Additionally, that makes the approval process a bit strange for approving something you don’t really know what it is.
Manual tasks
Once you import a SAP Integration, there is often the process about having some manual steps to perform the configuration. Moreover, this requires documentation of what should be configured and then the administrators that configures the document also perform it after the plan. Also, it is really tempting to make small changes, without the documentation if you find something missing.
Time-consuming
It is some pretty time-consuming tasks to perform all of the integrations this way.
Automation is the way
It is quite tempting to want to automate the process of handling the documentations. There is one solution that will enable you to handle the full integration easily.
At Figaf, we have been building tools that can help with the automating of governance. Therefore, you don’t need to focus on the process but just on creating the documentation. You can see a demonstration of below.