I was learning about the role of service domain specialization in adopting the Banking Industry Architecture Network (BIAN), and felt there is a significant opportunity to take the OpenAPI for BIAN and apply OpenAPI Overlays to reflect the domain-based specialization they are highlighting. BIAN has defined a list of 327 service domains, which are designed to be mutually exclusive and collectively exhaustive, ensuring there I no functional redundancy between them. BIAN provides a pretty compelling list of reasons why specialization may be necessary which also speaks to the reasons I see enterprises exploring OpenAPI Overlays.
- Operating Models - Banks have different operating models, and the service domain landscape must align with a bank’s operating model to be used as a blueprint. This may require specialized service domains to align with specific products, customer segments, or organizational alignment.
- Technological Innovationss - The adoption of new technologies, such as AI or blockchain, might necessitate specialized service domains to leverage these innovations effectively in specific parts of the bank.
- Regulatory or Legal Requirementss - Different regulatory or legal considerations can mandate specialized service domains to ensure compliance.
- Geographical Considerationss - Multi-geography operations, along with legal and operational requirements, may also mandate specialization of service domains.
- Business Insightss - Specialization may be required to provide tailored business insights that support strategic decision-making, especially when standard service domains do not fully capture the nuances of a bank’s operations.
When it comes to operating models and business insights, I have long used OpenAPI as a source of truth, with Postman Collection derivatives reflecting specific business uses cases — something I’ve begun to evolve using OpenAPI Overlays. The regulatory and geographic considerations fits squarely into the intention of OpenAPI Overlays, but the technical innovations bullet which speaks to a variety of API consumer demands is a pretty compelling argument for OpenAPI Overlays. Using OpenAPI Overlays to express the different areas of specialization BIAN speaks of smells like a pretty significant opportunity, but I’d say applying OpenAPI Overlays across their areas across any business sector, as well as domain within the enterprise sounds like a massive opportunity.
