Leveraging BIAN SOA Reference Model in EA

BIAN is the buzzword in the Banking industry in recent times. The testimony to the enormous interest it has generated is the significant number of banking giants that are adopting the BIAN SOA reference model to help drive their large scale business & technology transformation programs. This article is intended as an introduction to BIAN and also depicts how it can be leveraged to develop an EA repository, one of the many other business usages of BIAN.

Hello, I am BIAN

BIAN (Banking Industry Architecture Network) is a not-for-profit organization founded in April 2008. It aims to define SOA in Banking through standardization of IT services. At its core is the Banking Services Landscape that provides a reference Banking Business Architecture model to which the Enterprise IT services realizing corresponding business services should align to. The advantages of using the BIAN SOA model are manifold:    i) Reduction of business information inconsistencies and fragmentation.       ii) Reduction of IT integration costs while leveraging advantages of a service-oriented architecture.       iii) Alignment of business and IT services for reusability & simplification of landscape.  iv) Increased operational flexibility.

The primary assets of BIAN are:

i)   BIAN Service Landscape

ii)  BIAN Metamodel

iii) BIAN Business Scenarios

BIAN community members include leading financial institutions, software vendors & system integrators. TCS is also an active contributor to the BIAN consortium through its BANCS division. GCP BITA has been involved in business architecture work across banks in Norway, Mexico, USA among others.

Developing an EA repository using BIAN assets

The customer’s desire to develop a robust Enterprise Architecture repository is typically driven by the primary intentions of:

·         A shared understanding of business objectives & collaboration between business & IT should drive IT portfolio planning

·         A single view of enterprise business & IT services should drive agility and change related risks

·         A single view of application & infrastructure across business units should drive decisions on investment & reuse

·         Prioritized enterprise business services to develop new model for customer facing application SLA specifications

To realize this vision it is recommended that the customer should adopt a top down approach by assessing & cataloging the current enterprise business services, which will be mapped to information services and then further charted downstream to the corresponding application(s) & underlying infrastructure.

Approach to EA: BIAN model to complement TOGAF in EA

BIAN (Banking Industry Architecture Network) service landscape along with its accompanying metamodel should be used for base lining the customer specific business services and cataloging them. The major advantage this model provides is a service oriented business blueprint that has been built over the years with contributions from the banking industry and IT vendors. The model aims to achieve consistent business service definitions, levels of details & boundaries through SOA led standardization of IT services in banking.

BIAN model is closely aligned with TOGAF 9 ADM. All ADM phases, except for technology architecture (as BIAN model is implementation agnostic), can make use of BIAN’s deliverables to develop the architecture landscape.

BIAN & TOGAF synergy

Developing the EA metamodel

Realizing the customer’s vision necessitates a business service driven EA metamodel. BIAN SOA reference model is the right fit for assessing & developing the Business Architecture as a majority of the customers have embraced TOGAF for all their architecture work. This would allow a prioritization of customer facing services and their application SLA specifications. At the top layer are business services which are derived from service domains in the BIAN service catalog. This layer of repository is recommended to be owned by the customer’s Business group. The business services are realized a layer below by the Information System Services. These IS Services which comprise of process, data & technical level details are in turn realized by corresponding application(s) in the application layer. These two layers are recommended to be owned by IT Managers. Application specific Technology & Software infrastructures are also recorded at the bottom layer of the metamodel. This layer is to be owned by the IT Technical Architecture & Platform Group.

TOGAF ADM

Ownership

EA Metamodel

'        

High level Physical EA metamodel

Testing the waters

Once the EA metamodel is designed, it is time to test its adaptability within the enterprise through a POC that scopes a few top priority business services for the customer. Business should identify a set of business services which will be used as inputs for the business service cataloging activity. These business services should be mapped to corresponding service domains from the BIAN service landscape, thus forming the first level, L1, of business services. The service domains identified should further be decomposed into high level business services that make up the L2 of business services. Each of the L2 business services are to be realized by Information System Services at L1. These ISSs should be further broken down into high level ISSs at L2 such that these could be directly mapped to existing application(s) that realize the L2 ISSs. Capturing the underlying technical and software infrastructure for each application should follow next but is outside the purview of this exercise.

Sample: Physical Business Service Catalog (this example depicts flow across only one service per level)

Putting it all together

A successful POC’s end result is an EA metamodel using the BIAN business architecture repository that can be successfully implemented across all business units of the customer. The next step is to use the customer’s existing Enterprise Architecture solution or a new solution for EA assessment & development at the enterprise.  The metamodel derived from the above exercise should be imported to the EA solution tool. This is to be followed by capturing of data points in a top down, business services driven approach. The final result is a holistic view of how every business service in the enterprise is realized by an application(s) and the underlying infrastructure. Information services, as always, act as the bridge between the business services and applications layer.

Functionally redundant applications & services across the units will also be identified during this process, remediating these redundancies can not only help boost customer’s RoI but also the operational efficiencies in the long run.