Modularisation of the integration services must support reuse across business domains

Integration solutions are means to provide capability exposed as integration services. These services are govern by metadata in the service registry to be use during design-time. Current usage of service metadata is only for binding service contract. An emerging trend is extrapolating service metadata for semantic service discovery in run-time.

Integration services can be extended to meet domain specific business requirements. However, project team needs to factor in service version changes.

Reusable services is the core driver for most of "IT cost reduction" and "lowering cost of ownership" initiatives.

Service-Oriented Architecture (SOA) lays the foundation for reuse of functions through interfaces (refactoring your legacy functions as web services is not SOA enablement).

Service registry must be the starting point in your design options study. Reuse integration services where necessary. Follow policy to obey the service contract and register dependencies against the service. Good Architect must comes up with at least two design options for every solution.

Common processing steps must be separated from the specific requirements of individual products.

User oriented functions must be separated from core business logic processing.

Decision support functions must be separated from transactional processing.