Posted on

Evolving Integration Strategy at Major Canadian Bank, Part 2

Integration Pattern

While understanding the importance of the APIF, we also recognize that good architectural practices and proper logical architecture of the application/services could be even more important than the service mesh. To support the integration strategy, CIBC has been developed Integration Pattern, which makes internal and external APIs the emerging standard for integration across the bank and beyond. This pattern transitions from existing legacy integration components and patterns to modern equivalents that embrace APIs and (micro)services by truly distributing all gateway and isolation layer functions.

The CIBC Integration Pattern is presented in the following diagram:

Posted on

Evolving Integration Strategy at a Major Canadian Bank, Part 1

Key Takeaways

  • CIBC is a major Canadian Bank with more than 150 years of history. The technology landscape is highly heterogeneous. Modernization of such a diversified environment is a tremendously difficult task. CIBC adopted an API strategy and developed Integration Pattern to support it. The article discusses major decisions an architect must make to apply the Pattern.
  • Having design patterns, recommendations, and best practices is not enough. Technology must support and enforce them through platforms and frameworks developers use to create products.
  • CIBC developed API Foundation Platform (APIF) to support and enforce CIBC Integration Pattern. It implements service mesh to support Cross-Cutting Concerns (XCC) in a unified manner across all Lines Of Business. APIF supports both sync and async (messaging and event-based) communication.
  • APIF implements recently emerged patterns to support eventual consistency; however, even with all these patterns, tools, and frameworks, eventual consistency remains an extremely difficult problem to solve. Some alternatives must be considered.
  • CIBC adopted an iterative approach to build new functionality or decompose legacy applications to (micro)services. For some use-cases, modular monolith architecture will be perfectly fine. Modules that meet defined microservices criteria might be extracted, packaged and deployed as independent (micro)services.

Executive Summary

With emerging new devices and technologies in the last years, CIBC, as the entire industry, goes through enormous changes in all aspects of developing new capabilities and delivering business value. To address the new requirements CIBC embraced and promotes API Strategy which in turn requires new Integration Strategy. CIBC developed a generalized Integration Pattern to reflect these changes and related standards to enforce the pattern. The pattern is directly supported by the API Foundation Platform built in our organization. Successful implementation of the pattern requires a steep learning curve and critical thinking to navigate through zillions of buzzwords to understand what would be the best possible solution for a concrete use-case.

The article discusses major decisions architects and designers should make to apply the pattern: what API protocol to choose? What would be the right architectural style to implement the API? What is the recommended roadmap, and the best strategy to progress from one architectural style to another one, say from a legacy application to a structured monolith, and then, if required to microservices? What are the options to implement the isolation layer? What design patterns to use to implement Cross-cutting concerns (XCC)? And what about eventual consistency?