11 things that Integration Architects should check before approving a transport

I have worked on many different projects, all with different levels of governance. Some did not really care about it. Just make the integration work.

Others wanted some paper trail to ensure all changes was because of a service request etc.

I have never had anyone approve of the quality of my integrations or if it followed the standards.

If I was an Integration architect

If I were an integration architect at a company and had a team of developers working on my system, there is a list of things I would check.

1) Track the modified versions with a link to a Jira/SNOW or what is required. Of course, make sure it is the right version of objects in the transport.

2) That I can approve all requests from developers to look at what they are trying to release and give them the feedback before.

3) Follow the Design Guidelines setup in the organization. SAP have been good at creating and extending the guidelines making it a good tool to get some view of what if they follow the standard.

4) Checking the naming standards

5) What test cases do they have for this, and what is their status? It is intelligent to see if they have test cases so the next developer can easily support the integration.

6) Customs configured checks like CPIlint for the naming of different steps and bad patterns.

7) Perform your own checks for things you find bad and that you have found can cause problems like using unencrypted communication.

8) Check for all the externalized parameters if they have been configured for the QA system. And of cause check if there are unused. I have seen many iflows that used unused parameters it is better to get it cleaned up. Before you move to production.

9) Understand the changes in the transport, both code and BPMN models, to see the impact of a change. BPMN should be viewed graphically; otherwise, it is close to impossible to spot the important differences.

10) Check if all necessary dependencies like scripts and security artifacts are on the target system otherwise they should be on in transport.

11) Check for unit test for the Groovy code

PS. Is there anything else you would check.

In the ideal world this is what you should be able to check and probaly a few more things depending on the level of skill of the developer and the complexity??of the integration.

Making it easier

In Figaf you can check all of the items mentioned here in just a few clicks. This enables you to make the checks when somebody sends a transport for approval. You can get started with this today. From the Figaf transport configuration you can easily view all of this in just a clicks.

You can also build a dashboard to perform these checks yourself whenever you approve your transport. But why not explore what you can get out of the box and then decide if you want to build something yourself?

?