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?