After completing this lesson, you will be able to:
Apply integration best practices
Explain integration dos and don’ts as well as architecture blueprints
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:
Define Integration Dos and Don’ts.
Define Architecture Blueprints.
Integration Dos and Don’ts and Architecture Blueprints
Integration Dos and Don’ts Examples
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.
General Integration Dos and Don’ts
Use web-based APIs whenever possible, and use packages (content) wherever possible.
Don’t build any business logic into the interaction layer.
Design fault-tolerant integration scenarios (for example, input validation, exception handling).
Don’t overlook resource consumption and performance.
Build secure integrations (for example, secure communication, data privacy and protection)
Don’t underestimate the time required for testing and quality assurance.
Follow naming conventions when creating integration artifacts.
Don’t store any business data on the middleware.
These are only examples. Customers need to check if these fit their needs or require adjustments.
Discover the functions of Architecture Blueprints
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.
Create Tailored Development Guidelines
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:
Design of integration scenarios
Definition of reusable building blocks, such as enterprise integration patterns
Naming conventions for integration artefacts
Documentation of integration scenarios
Designing reliable, resilient, secure, well performing integration scenarios
Integration-related configurations of connected business applications (such communication arrangements and scenarios in SAP S/4HANA)
Releasing, updating, and deprecating integration scenarios