Defining Integration Best Practices

In the third phase, "Define Integration Best Practices", you learn how important those best practices are for your company. They help you to govern and safeguard the implementation of integration processes across your company. The scope of integration is constantly increasing and that is why more and more development teams and integration developers are working on that topic. Therefore, it’s important to define common quality standards, which enable transparency about integration design and implementation.

There are three different steps that have to be performed to define integration best practices:

1. Define Integration Dos and Don’ts.
2. Define Architecture Blueprints.
3. Implement Guidelines.

Integration dos and don'ts are important for the integration development, such as building secure integrations or avoiding overlooking resource consumption and performance, which you should always keep in mind, if you want to integrate something. With those dos and don’ts, essential standards for integration development are set and enterprise-grade integrations that safeguard your company’s mission-critical business processes can be delivered.

The integration dos and don’ts are not limited to technical aspects – non-technical aspects can also be included. You should always remember not to define too many integration dos and don'ts, otherwise, it becomes too complex and difficult for the integration developer to implement.

Another option to define integration best practices is to create architecture blueprints. So far, we know how to design a hybrid integration platform for our company. But even the best-defined platform will be useless if its developers and integrators do not know how to use the individual functions for integration. That’s the reason why it is so important to have some guidance that tells you:

• Which integration technologies can be selected for the hybrid platform?
• How can those integration technologies be used in orchestration?
• How to integrate them with different endpoints (for example, applications, data sources, APIs).

You can think of it roughly as architecture blueprint offering a kind of sample solution for an architecture in a specific domain. They describe and visualize which integration technologies can be selected and how they can be combined to implement integration use cases.

By using this concept, you create your architecture blueprints at the level of an integration use case and integration domain. Architecture blueprints can be defined for all types of environments (on premise, hybrid, and cloud environments). Each architecture blueprint can be complemented with additional information (for example, features and decisions that help developers to find the right architecture blueprint for your business requirements).

In the following figure, you can see an architecture blueprint example for the cross use case pattern "Digital Integration Hub" for the integration domain Cloud2OnPremise.

It can always be helpful to provide integration developers with detailed guidance by creating development guidelines for integration technologies.

Such integration development guidelines, better known as integration handbook, integration best practices, or similar, are common means for sharing integration best practices across distributed integration development teams. The goal behind such guidelines is to guarantee that integration processes are designed and implemented in a strong way, to protect business critical processes in your company.

Implementation guidelines not only deal with technical aspects, they also take care of organizational aspects of integration development. Examples of this include, for example, processes for integration governance and quality assurance.

An implementation guideline should cover the following best practices: