Four Principles for Successful Application Integration
In today's fast-paced digital landscape, an era defined by the API economy, seamless application-to-application integration is a critical component of any organization's success. The strategic use of APIs is driving innovation and growth across industries. It ensures that different systems can communicate and collaborate efficiently, enabling businesses to stay agile and responsive to market demands.
At Rabobank, the Integration community have distilled our years of experience into four core principles that guide our approach to building integration platforms and assets. These principles not only reflect our commitment to best practices but also provide tangible business value to form the foundation of a modern integration strategy. In this article, I would like to explore each one of them.
Note: this article assumes a team way of working (not only one individual).
Ownership
Principle: Each team owns its integration services and registers them on the standard CMDB, even when it is running on a shared platform. As owners, each team is responsible for the lifecycle, security and data lineage of the service.
Business Value: This principle ensures clear accountability and responsibility, reduces bottlenecks and delays in service management. It streamlines decision-making processes, leads to faster integration delivery and better service quality.

Autonomy
Principle: Each team manages its integration services’ lifecycle itself. There is no central integration team managing services, nor should a team manage services it consumes from another team.
Business Value: Empowering individual teams to manage their services fosters a culture of self-sufficiency and innovation. It eliminates dependencies on a central team, accelerates development cycles, and enables teams to respond rapidly to changing business needs. As part of this principle, we also recommend teams to leverage public networks with strong application-layer security to enhance scalability and flexibility. It reduces the complexity of managing private networks and strengthens data protection measures.
Lightweight
Principle: Intelligent endpoints, dumb pipes. Team services do not contain logic depending on anything external to the integration service itself. Services do not use external data models, information systems, standards, or anything else. Meaning: no orchestrations, aggregations, transformations, filtering or routing in the integration service, but instead solving these things in either the providing and/or the consuming applications. The applications – not the integration services – take failure (of services they consume) into account. State, error handling, and idempotence are handled in the applications, not in the services or services platforms.
Business Value: Keeping integration services self-contained simplifies maintenance and reduces the risk of issues arising from external dependencies. It promotes agility by allowing services to evolve independently. Besides, applications – not the integration services – are designed to handle service failures and ensure system resilience, minimizing disruptions, allowing graceful degradation and better user experiences during service outages.
As-a-product
Principle: When choosing, building, or changing applications, the team considers interactions with other applications as first-class citizens. The team ensures that the services are easily discoverable, reusable, and attractive to use. In our organization, we achieve that by publishing all integrations in our Rabobank Integration Catalog.
Business Value: Treating integration services as products enables a self-explanatory service when they are well documented. In practice, it enhances team autonomy and facilitates self-service consumption. It also reduces the need of collaboration between teams and promotes a service-oriented mindset. It optimizes resource allocation, reduces duplication of efforts, and boosts overall efficiency. Once you have an integration product, the next level is to offer it in a centralized catalog to facilitate service discovery, which reduces integration effort and promotes reusability. A catalog provides a single source of truth for available services, enhances visibility and accessibility.
Conclusion
By adhering to these four principles, Rabobank has established a robust foundation for application integration. The principles guided our platform architecture decisions and were inspired by years of development from the Integration community. They formed a coherent approach to integration, emphasized the importance of ownership, autonomy, lightweight services and treated integration as a product. Embracing these best practices will enable your organization to thrive and innovate in an increasingly interconnected world.
Looking ahead, we are building our own “integration mesh” ecosystem, and this is a topic for my next article.
