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.

Integration Architecture must be current and relevant

The Integration Architecture is both a process and the result of the process. The process is iterative and the results are incremental. It will be regularly enhanced, updated and communicated.

Strong Integration Architecture continuity requires constant updates to adapt with Technology, IT trends, economic condition and objectives of the organisation.

Lessons from the past:

• Development and projects must update the Integration Architecture.
• There must be a process for the review and assessment of Integration Architecture.
• Audit by an external consultant on a regular basis.
• Utilise industry standards.
• Peer review must be a minimum assurance mechanism for any change to the Integration Architecture.
• Business and information system strategy must inform Integration Architecture.
• Industry trends must be considered.
• The Integration Architecture must capture both the future state and the current state models.
• Short-term tactical solutions versus long-term strategic solutions must be constantly re-examined.
• “Just enough architecture, just in time”: The Pareto principle must be embedded within the architecture development cycle, creating an understanding for the application of the 80/20 rule and culture.