What is BIAN?
The Banking Industry Architecture Network is created to establish, promote, and provide a common framework for banking interoperability issues and to become and to be recognised as a world-class reference point for interoperability in the banking industry.
BIAN as a reference Architecture for the banking industry provides the guidelines to implement a composable architecture.
This is achieved using self-contained Service Domains or from a more implementation perspective, they can be viewed as individual microservices.
A Service Domain is constrained by a bounded context. This means that everything related to a specific domain is contained within that bounded context. For example, for current accounts, get balances, get fees, process deposits and withdrawals, generate statements etc, would all be part of this service domain.
Why Use BIAN?
Why would a financial institution want to implement BIAN?
There are many different reasons a financial institution might choose to implement the BIAN framework. These could include:
- Interoperability
- Standardisation
- Agility and Innovation
BIAN is a composable architecture that promotes re-use, and that re-use leads to cost savings.
A composable architecture gives us the following benefits:
- Change or create new service domains
- Self-servicing teams focusing on business value
What is the problem?
All sounds good so far, but BIAN is not implementation. And there are challenges as currently there are approximately 326 separate service domains identified in the BIAN landscape.
It’s not expected that any organisation will require all 326 Service Domains, but there is a high probability that you’ll need close to or above 100.
How do you consistently build across your project teams, at speed, and maintain quality?
Repeatability, Consistency, and Speed
Automate, Automate, Automate.
Over 100 years ago, Henry Ford started mass production of the Model T;
In 1908 Henry Ford introduced one of the mass-production vehicles, the Model T. In 1913 Henry Ford combined interchangeable parts with subdivided labour and fluid movement of materials to create his moving assembly line. The resulting productivity gains and price cuts led manufacturers of every type to adopt Ford’s innovative production methods.
DevOps, CICD, Agility and modern development tools are the digital equivalents of those production lines that allow us to implement various levels of automation.
Wrapping all these together under a platform engineering banner brings several benefits to an organisation:
- Increased Developer Productivity
- Scalability and Flexibility
- Improved Reliability and Stability
- Enhanced Compliance
- Collaboration and Knowledge Sharing
The Guts
Platform engineering can take DevOps to the next level but what are some of the basic tools we’d need to put this all together?
Backstage
We can’t expect multiple teams to create the same code with the same quality. From experience, we can’t always expect a single developer to consistently write the same style of code across projects.
Enter Backstage as a templated approach to creating skeleton projects. It’s a centralised platform for maintaining a Service Catalogue that fosters documentation and collaboration.
LaunchDarkly
LaunchDarkly enables organisations to adopt a continuous delivery approach by decoupling feature releases from code deployments. Feature flags allow you to control the release of features to specific user segments, enabling gradual rollouts, A/B testing, and canary releases. This empowers teams to continuously experiment and gather feedback from users without disrupting the entire user base.
Harness
Harness enables automation across the entire CD process, including building, testing, and deploying applications. It reduces manual effort and human error, leading to faster and more reliable releases.
Harness incorporates security and compliance best practices into the CD workflow. It includes features like secrets management, access controls, audit logs, and compliance reporting, ensuring that your deployments adhere to security standards and regulations.
The Future
BIAN is designed to be flexible and adaptable to emerging technologies and industry trends. It provides a foundation for banks to embrace digital transformation, cloud computing, artificial intelligence, blockchain, and other disruptive technologies. By implementing BIAN, banks can future proof their architecture and ensure compatibility with future advancements in the banking industry.
What’s Next and How do we Take it to Another Level?
You’ll never build the perfect solution first time around, it’s an ongoing continuous improvement cycle. Your Platform Engineering solution can constantly be enhanced and extended.
It’s not all about the code, and depending on your perspective, it’s never about the code.
Documentation is one of the things developers ‘get around to’, and usually towards the end of the development process, at which point, remembering what you did can be a guessing game.
For myself, who’s not much of a wordsmith, putting a good framework in place at the start of the development process always makes it easier, as I have somewhere to make notes.
Make use of Spotify’s TechDocs, a homegrown docs-like-code solution built directly into Backstage.
Summary
Overall, implementing BIAN offers banks a standardised and modular approach to architecture, leading to cost savings, increased agility, collaboration opportunities, and readiness for future innovations.
But there is a need to do this in a repeatable manner and apply those same principles to your code.
Scalability, Governance, Consistency and Standardisation can be built into the Platform Engineering process so new developers and engineers never have to worry about it.