Problem Domain

Created by Jeff Mitchell
Last updated: Jun 06, 2014

Summary

Ikasan addresses the problem of integrating business systems with specific focus in the financial sector.

Financial institutions utilise a multitude of external and internal systems the latter of which can be a third-party product or in-house development. The purpose of Ikasan is to provide easily configured solutions to isolate the specifics of an integrated application whilst at the same time exposing the business artefacts thus presenting a common reusable business interface Ikasan addresses the problem of integrating business systems with specific focus in the financial sector.

Problem Definition

End users need to be able to access and orchestrate data as a function of the business without incurring the continued overheads from IT to achieve this.

This problem in the finance sector is exacerbated by

  • Greater adoption of “Best of Breed” specialist applications in financial services
  • Business applications distributed across disparate platforms
  • Business data distributed across isolated silos
  • Exponential integration requirements
  • Greater complexity of business demand on data orchestration

Starting Principles

Ikasan started through the definition of the following basic principles.

  • Enterprise integration is not simple!
  • Architecture must be driven by clear strategies
  • Architecture must be flexible to accommodate all integration scenarios
  • Enterprise Application Integration is more than just connecting applications
  • Any integration should be achievable through simple configuration or development without specialist knowledge

Architectural Strategies

From the above principles the following strategies emerged.

  • Commonality - all application integration should be undertaken through the same steps using the same constructs
  • Simplicity - integration should not require in-depth specialist knowledge
  • Flexibility - the architecture must support any complex integration requirement without breaking the previous two strategies
  • Robust and guaranteed operation - integrations must provide data integrity and automated recovery in failure scenarios with minimal manual intervention
  • Adoption of standard open technologies and specifications - all aspects of the project must enforce the avoidance of vendor lock-in
  • Clear separation of concerns - integration concerns must be clearly defined and separated i.e. comms, API, data, and distribution are all separate concerns of a single integration
  • Loose coupling - integrations should only require knowledge of each other through exchange of business artefacts - no lower level dependencies should exist
  • Tight cohesion - an integration's protocols and data syntax/semantics should not 'bleed out" unnecessarily
  • Complexity can be reduced through good architecture - integration is complex, but a good architecture will enforce boundaries without limiting a developer's creativity