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.
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.