BIAN_IBM_PNC_white-paper_2014

Advances in Banking Transformation using BIAN and IBM Industry Models
0
Advances in Banking Transformation
using BIAN and IBM Industry Models
Whitepaper

1
Contents
Introduction 1
Banking Transformation Overview 2
Context 4
Approach 6
Results 8
Challenges & Opportunities 11
Conclusion 12
Authors
David Lee
Head of Architecture Delivery & Enterprise Architect,
PNC Bank
Santhosh Kumaran
Financial Services Sector Solutions Leader
IBM Software Group
Pattu Patnaik
Chief Architect, Banking Solutions
IBM Software Group
Introduction
PNC and IBM jointly performed a Proof-Of-Value (POV)
exercise to design & develop IT solutions leveraging
BIAN Service Landscape (SL) and IBM Banking Process
& Service Models (IFW). The primary goal of this
exercise was to evaluate the feasibility and benefits of
using IBM Banking Models & tools in developing IT
solutions conforming to BIAN standards for both top-
down & bottom-up approaches. We used business
processes of interest to PNC Bank (Account Opening &
Corporate Lending) to drive this exercise. This paper
outlines the work performed as part of this POV and
provides an analysis of the approach and the results
achieved.
Target audience for this paper is primarily the enterprise
architects, business architects, service architects and
application engineers, in banking.
We begin this paper with an overview of the
transformation of the IT systems of a bank towards
achieving better business-IT alignment, agility, and
efficiency. Specifically, we cover the business &
technology drivers for transformation, typical challenges
faced by banks in executing transformation initiatives,
transformational approaches, and the role of enterprise
architecture as an enabler of transformation.
Next we give an overview of the foundational elements
employed in the transformation methodology used in this
POV. These include the BIAN Service Landscape, IBM
Industry Models (IFW), tools, and the runtime stack. We
will use the enterprise architecture as a context for
explaining the foundational elements.
We then describe the POV exercise, including the
business problems addressed, approaches used, and
the results achieved.
We conclude with an analysis of the results, discussion
of the potential business outcomes & benefits that are
achievable if this approach is industrialized, contributions
of this work to banking transformation area, the issues &
challenges and how to address them.

2
Banking Transformation
Overview
Banks typically have very complex IT systems compared
to other types of firms. Part of the reason is that products
& services that are designed, developed, offered, and
services by a bank are fully manifested as IT constructs.
For example, contrast a bank with a firm that
manufactures automobiles. The latter uses IT to help
design, manufacture, sell, and service automobiles while
a bank that offers a car loan uses IT constructs such as
a set of CICS services as the manifestation of the
product itself.
Traditionally, banks (and other types of firms) have used
an application-centric approach to developing IT
solutions to business problems. This has resulted in a
very large number of IT applications, each supporting
some subset of business functions, sometimes
overlapping. In reality, business processes of the bank
cut across these applications, necessitating highly
complex integration requirements. To complicate things
further, business requirements constantly change,
resulting in new applications being developed to meet
these requirements. These new applications are then
integrated with existing applications, adding to the
complexity.
The bottom line: a bank is left with IT systems that are
inflexible, inefficient, and out-of-alignment with business
needs. This is the context for IT transformation in
banking. The goals of the transformation initiatives are to
reduce complexity, improve agility, standardize, and
achieve business-IT alignment.
From a business perspective, some of the key factors
that drive the transformation initiatives include the need
to comply with new and increasing regulations, the need
to become a customer-responsive enterprise, the need
to support omni-channel customer interaction, and the
need to operate in a boundary-less economy.
A perfect storm scenario emerges when you couple the
business drivers with the technology drivers. While the
business drivers provide the push for sustained
competitiveness, technology advances provide the pull.
These technology advances include component based
modeling (CBM), service oriented architecture (SOA),
model driven development (MDD), standardization,
business process & business rule management systems
(BPM/BRMS), mobile & social computing platforms,
analytics, cloud & Big Data. In addition, availability of
pre-defined service content & structure, like IFW, help
jump start SOA value ‘out of the box’.
While there are plenty of business and IT drivers for
transformation, there are significant challenges such as
dealing with legacy IT applications in the enterprise. For
most banks, a “rip and replace” approach is a non-
starter. The only feasible approach is to adopt an
incremental, progressive approach to transformation.
This implies that the bank needs to manage a hybrid
environment of new SOA components co-existing with
legacy applications which poses many integration
challenges. Bottom-up and top-down approaches to
transformation are used to deal with these challenges.
Bottom-up and top-down approaches to
transformation
The bottom up approach focuses on the current set of
applications in the enterprise and uses SOA to identify
how these applications can be incrementally
componentized.
The advantages of bottom-up approach are:
 You can continue to use the legacy apps.
 It is less risky
 It often provides faster time to market
 It is less expensive.
The disadvantages are:
 It may prevent true re-engineering
 Tie the new process too closely to the limitations
of the current environment.
In contrast, a top down approach starts with an SOA
based solution design to the business problem, develop
components driven by this design, and integrates these
components with legacy applications as appropriate. The
key advantage of this approach is that it provides the
ability to design and implement business processes
without the constraints imposed by the legacy

3
applications. But it does require the design &
development of the new service components.
In both of these scenarios we are looking to ensure that
the modeling process retains the component and service
based properties of separation of concerns, loose
coupling and encapsulation linked to a component based
banking business model.
Next we discuss the role of enterprise architecture in this
transformation.
Figure 1: Components of Enterprise Architecture
Enterprise Architecture
EA is more of a discipline than architecture. The EA
discipline defines and maintains the architecture models,
governance and transition initiatives needed to
effectively co-ordinate semi-autonomous groups towards
common business and/or IT goals. EA helps to link an
enterprise's business strategy to its change programs
through the definition of:
 Architecture models to capture the business'
intended structure (through a business
architecture) and to provide a clear specification
of how multiple projects and programs must
exploit information technology (through common,
and explicit, IS and IT architectures).
 Mechanisms, such as architecture governance
and transition planning, to help plan, coordinate,
and control all parts of the business, ensuring
they all pull in the same direction.
Listed below are the components of Enterprise
Architecture:
 Business architecture
 Enterprise data, message, process, & service
models
 SDLC methodologies & tools
 SW infrastructure standards
 HW infrastructure standards
 Governance
The approach we discuss in this paper is a specific
instance of enterprise architecture for banking, with
BIAN Service Landscape as the business architecture
and course grain component services and IFW models
as the fine grain enterprise service, message, & process
models.
Next we discuss the foundational elements of our
approach, using enterprise architecture as the context.
Business Architecture – BIAN Service Landscape
The BIAN Service Landscape is a reference framework
that contains all identified BIAN Service Domains. Its
purpose is to provide a mechanism for quickly identifying
and selecting non redundant Service Domains based on
business events. Different criteria can be used to classify
and organize Service Domains that would result in
different layouts of the standard set of BIAN Service
Domains. BIAN uses a ‘primary’ Service Landscape view
based on agreed categorizations that have been in use
by the BIAN membership.
A Service Domain defines a unique and discrete
business capability. The Service Domains are the
‘elemental /canonical building blocks’ of a service
landscape. Any business activity or event can be
represented by a suitable collection of one or more
Service Domains working together in collaboration.
There are ~270 identified BIAN Service Domains of
which ~200 can be identified as “Core Banking”
functionality while the rest can be considered as
“Business Support Functions.”
More details on BIAN Service landscape can be found at
bian.org.
Enterprise Message, Process, & Service Models -
IFW
IFW (IBM Banking Process and Service Models) is a
pre-defined content and structure rich set of models

4
designed specifically for financial services organizations.
They are regularly enhanced and extended to align with
the global requirements for risk and compliance and
optimally allow for the development of more efficient
straight through processing solutions. By using the
models, the approach to transformation can be
dramatically shortened, with consequent savings in time
and money for the organization. The models are a result
of leading edge practices and engagements and have
been validated through their use within many of the
world’s major financial services organizations.
More details on IBM Banking Process and Service
Models can be found at ibm.com.
Context
The PNC Financial Services Group, Inc. (NYSE: PNC) is
one of the nation’s largest diversified financial services
organizations with assets of $320 billion. PNC, operating
primarily in 19 states and the District of Columbia,
provides retail and business banking; residential
mortgage banking; specialized services for corporations
and government entities, including corporate banking,
real estate finance and asset-based lending; wealth
management and asset management with an estimated
2700 branches, 6.6 million checking customers, and
7400 ATMs.
The PNC IT landscape has grown dramatically resulting
in challenges related to:
1. Growing costs related to maintainability of its
complex core banking systems,
2. Time to market with innovation, and
3. Modernization of its application portfolio
A diagnostic of this complexity revealed an IT that was
resource intense and extensive use of narrow integration
techniques (e.g., point to point interactions between
applications). This has led to growing risk and high cost
to make even simple modifications and facilitate timely
isolation of problems for root cause analysis.
Given this situation, PNC’s senior management has
inaugurated a business and technology transformation
focused on agility, efficiency, and effectiveness.
Specifically on the strategic agenda is to architecturally
drive to the ‘next level’ of their SOA strategy. This SOA
strategic program will move its present SOA capabilities
to achieve the following aspirations:
1. Adapt a banking industry standard component
based model and design
2. Install a world class service design &
engineering capability coupled with a software
factory like assembly process
3. Focus Enterprise Architecture on developing a
comprehensive domain based architectural
roadmap to simplify the application portfolio.
In preparation, of this transformation agenda, the first
step was to validate the
PNC assumptions about a
BIAN-IFW relationship by
instantiating a hypothesis
that BIAN and IFW
together can be
synergistic in delivering
an end to end
methodology in designing
and delivering enterprise
services. This would mean transformed roles in
architecture, end to end capability and software
modeling, standard application engineering and a
componentized approach to building the agile vision.
The first order value logic of this exercise was to search
for what exists already (i.e. leveraging existing assets
as the fastest time to market). In the case of BIAN, a
universal banking model and defined canonical and
elemental service components. In the IFW model, a
catalog of services ‘out of the box’ with a proven method
and tooling to manage its development and deployment.
When and if a new or modified/extended service is
needed, apply BIAN and IFW modeling capabilities to
contextualize the extended development activity to retain
the SOA design paradigm.
By linking the iterative scoping and analysis and design
activities of BIAN and IFW, this should provide a set of
modeling constraints that are sufficient and necessary in

5
order to achieve a banking component vision linked to
service design and engineering. By linking these two
frameworks, it would provide the set of design
constraints that would aid in managing risk typically
associated with SOA projects. On the one hand,
uncoordinated service component proliferation, and the
other, stove piped creation of assets lowering the reuse
potential.
Scope
As has been mentioned, two business design scenarios
were applied to the BIAN-IFW POV exercise. In
scenario one, the corporate lending scenario (top down
or CL), we identified an interaction between the
corporate lending originations capability (a COTS
solution) to the corporate servicing capability (A legacy
application platform). This connection would be an A2A
integration scenario and would provide a directional
validation that a correlation or exact service identification
could be found for an operational capability reuse.
Starting with BIAN as a conceptual component frame,
could we link to IFW moving from UML to BPMN
semantics?
In summary, the specific CL objectives were:
 Demonstration of the use of BIAN & IFW in
designing an intra-enterprise, SOA-based
application integration layer
 Creation & validation of a SOA Architecture for
Corporate Lending
 Creation of the building blocks for a future-state
corporate lending solution
 Documentation of a top-down approach
leveraging BIAN and IFW for enterprise
application integration.
In the second business scenario account opening,
(bottom up or AO), we applied a common service pattern
that would exhibit the BIAN – IFW model capability to
identify existent process driven assets at the software
reuse level. Identifying lineage (search heuristics for
software pattern identification) is foundational to the idea
of reusability. We wanted to exercise the search
heuristics of utilizing an existing IFW asset. The AO test
case would give further insight on the role of BIAN in
establishing an inductive component business service
context by working up from IFW to a higher level of
abstraction. This would be an instance of a software
reuse going from the particulars to a generalization
design constraint (BIAN).
In summary, the specific AO objectives were:
 Deliver a business architecture and a solution
architecture for future state account opening
o The architecture will be validated by
implementing a subset
 The architecture will provide the following
business benefits:
o Omni channel support
o Channel integration layer that eliminates
the replicated business logic in channel
applications
o Product bundling & dynamic pricing
support
o Universal account opening with services
abstracted at the right level for reuse
across LOBs
o Common account opening.
In both of these design scenarios, the overall objective
was to observe the modeling behaviors of BIAN-IFW in
facilitating a more enterprise architectural & modeling
approach. Specifically,
 Evaluate the alignment of IBM Banking Models
(IFW) with BIAN Service Landscape (SL)
 Evaluate the use of IBM Banking Models &
Tools in developing IT solutions conforming to
BIAN standards for both top-down & bottom-up
approaches
 Develop an end-to-end methodology for solution
design & implementation leveraging BIAN
Service Landscape
 Advance PNC Component Business Modeling
project
 Contribute to the cause of BIAN by generating
and sharing insight on the practical use of the
Service Landscape.

6
Approach
The following series of steps summarizes the approach.
Step 1: Model Scoping
BIAN Service Landscape artifacts are used to retrieve a
subset of process, business object, & service models
from IFW that are relevant for the selected business
scenarios.
Figure 2: Model Scoping
Modeling Highlights:
1. Identify the associated BIAN Business Scenario
matched to the requirements
2. Use the IFW value chains to identify phases or
markers in the scenarios
3. Retrieve relevant IFW business processes, the
IFW services (using the activities in the
processes as indices), and IFW business objects
(using the in/out parameters of the services as
indices) using IFW scoping tool (Rational
Software Architect)
4. Capture the mappings in the BIAN-IFW
alignment model.
Step 2: Process Discovery
Business processes are formalized & adapted and
shared across the community using cloud-based tools,
primarily to communicate and gain consensus on the
scope.
Figure 3: Process Discovery
1. With the activity boundaries identified, identify
fine grain business processes for each step in
the business scenario.(Note: IFW Activities and
IFW Business processes identified based on
BIAN and IFW domain knowledge and with M1
tool help. Note that IFW may not be covering all
the activities, in which case define new activities.
While defining new activities use the IFW
business vocabulary to name the activities
appropriately).
2. Import IFW processes into BlueWorks Live
(BWL) and review and validate completeness of
process and activity descriptions,
information/data attributes, control flows,
decision points, and roles.
3. Perform any customizations as needed. Reuse
as much existing assets as possible
Step 3: Service Analysis & Design
Business processes are refined as model driven source
code is engineered as service and solutions leading to
software architecture delivery.
1. Scope out project level Business Object Model
(BOM)/Interface Design Model (IDM)/Service
Design Model (SDM) elements from the
conceptual level analysis models.
2. Validate the scoped models against the
business requirements identified in the process
discovery

7
3. Identify business capabilities in the BOM and
associated service operation (create a new ones
if necessary).
4. If required, identify a collaboration corresponding
to the operation in the IDM model to build a
composite service.
5. Link the collaboration diagram to the service
operation through a realization of UML.
6. BOM as the analytical object model, identify the
control object, and other business objects and
validate its attributes.
7. Define lifecycle model of the control object
utilizing the IFW fine grain process models. All
these activities are performed using UML
modeling tool, Rational Software Architect.
Figure 4: Service Analysis & Design
Step 4: Service implementation
Analyzed and designed service domains and service
operations are realized in a runtime environment through
an enterprise service bus.
Service Implementation Highlights:
1. Transform UML model, developed in the Service
Analysis and Design phase, to SOA runtime
artifacts. These artifacts include WSDL, XSD
definitions of the services, as well as BPEL flows
for straight through processing, BPMN for
process implementation, skeleton Java code.
Bring in the generated artifacts into Integration
Designer for service realization.
2. Identify existing application capabilities and
service touch points. Expose the application
functionality as APIs in service bus. (A variety of
technologies exist, depending on the nature of
the application, for exposing application
functionality as services such as enterprise
application adapters, POJO invocation, web
services, message queues, CICS, IMS, etc)
3. Develop mediation flows and service/message
maps from the canonical model to existing
applications through the exposed application
API.
4. Develop composite flows as BPEL microflows or
service orchestration in enterprise bus.
5. Bind service invocations to application end
points. Use a UDDI service registry as
necessary for service lookup and dynamic
service invocation. Unit test service
implementations.
Figure 5: Service Implementation
Step 5: Process Implementation
Business processes are refined for implementation
details such as service invocation targets, user
interfaces and human workflow.
Process Implementation Highlights:
1. Connect to BWL space and extract the analyzed
business processes into BPM Process Designer.
Bring in service definitions (WSDLs) and
message model (XSDs) from Service
Realization step into Process Designer.
2. Adorn processes with implementation details
such as service invocations, UI screen flows
(coaches), human workflow.

8
3. Develop UI screens and screen flows using the
message model brought from Service
Realization step. Define attribute bindings to
screen widgets.
4. Wire service tasks to business services
developed in enterprise service bus. Develop
simple message maps from the UI objects to
service messages only if needed. Bind the
invocations to service end points.
5. Simulate and test the business processes.
Figure 6: Process Implementation
As shown in the figure below, the end result is fully
developed & deployed IT service components
conforming to BIAN Service Domains.
Figure 7: Putting It All Together
Results
Bottom-Up Results
Each business design problem had unique requirements
that were hypothesized in order to test out the BIAN-IFW
modeling framework. The bottom up approach (AO)
was created to test the ‘out of box’ pre-defined content
and structure of IFW with traceability from a generated
run-time environment back through to BIAN. This
correspondence (i.e. a model driven perspective) was
intentional in order to see if such capabilities would:
1. Enable software developer productivity (software
level service access and “as-is” reusability) and
2. Facilitate architectural reference management
(inductive modeling “markers” from IFW to BIAN
for end to end model integrity and
manageability).
Using an implementation subset of AO
“retrieveInvolvedParty”, we were able to obtain the
following results.
Primary Search Heuristics
The software developer, using the classic registry and
repository of the WSRR, can find the service
‘retrieveInvolvedParty’ by exact noun and verb search.
When a match is not found, the advance search
capability (ASC) could be used which required parsing of
the service into its elemental parts (3) retrieving the
synonyms of each and inventorying all phrases related
to the 3 elements.
Secondary Analysis and Design Heuristics
The software developer, having exhausted the primary
search heuristics of the IFW Framework, launches the
next level of search utilizes the M1 tool which provides
descriptive and qualitative filtering against the RSA
repository and facilities. Identification heuristics such as
the ‘Object Neighborhood’ was used to place an optic on
contextual search.
Tertiary Service Landscape Heuristics
The architect, in collaboration with the developer,
engages in the search by instantiating the final lineage in
locating the service involving the BIAN Service

9
Landscape. Moving to the component based design
context of the desired service definition provides:
 A canonical and elemental business coverage
view point on the service if it still cannot be
found.
 A landscape perspective to assess “where else
used” for concluding the need and a scoping for
a new or adjustable service
So, what do we achieve in the bottom-up scenario?
1. We were able to search and identify the
candidate service ‘retrieveInvolvedParty’.
2. We were able to establish lineage, through
layered searches, that the candidate service was
the desired existing asset.
3. The BIAN deliverables can serve as a reference
to benchmark architectural documentation for:
a. Service domains coverage as they are
identified and developed ,
b. Identifying gaps or overlaps from a
target state/current state business
model analysis and
c. Structuring the response to business
events e.g. M&As, COTS
implementation, integration scenarios.
4. The service lineage and search algorithm (BIAN
Search > BIAN-IFW Mapping > M1 Search +
Object Neighborhood > WSRR > ASC) pointed
to a potentially rich set of tools to enhance asset
management. Each layer was mutually
exclusive (i.e. the object and relations were not
‘hard coded’ but adequate association seem to
exist). The approach being ‘model based’ made
the secondary and tertiary search and
modifications more documentation than model
formalism and therefore optional versus a ‘model
driven’ standpoint where generative code can
result. (See discussion in the BIAN – IFW
Alignment Model section).
5. We believe potential value could be realized in
the area of time to market and programmer
productivity as this value is proportional to the %
hit on the service catalogue. The probability of
an exact match or correlation for refactoring is
dependent on the model content richness and
maturity.
6. We saw significant promise in the need to have
lineage that crossed the secondary and primary
layers not just for identification heuristics but
also for incremental componentization and
alignment that is maintaining an enterprise
component blueprint to govern the alignment of
process oriented service solutions to avoid
fragmentation and misaligned functionality.
7. The pre-defined content & structure of IFW that
were relevant for this exercise include fine grain
service interface definitions, message models,
use cases and collaboration diagrams that
identifies the atomic services that participate in
the execution of a coarse grain business service,
and process models that elaborate the behavior
of a composite service.
Top-Down Results
The top down approach (CL) was generated to observe
model design semantics and behaviors from BIAN as the
component business architecture and canonical service
landscape through implementation and run-time
comprising of WSDL and XSD documents. In this
scenario, the design objectives were to observe how:
1. Architects uses BIAN (CBD for logical
partitioning and delegation) to manage and drive
the service architecture development as a
reference model linked to IFW
2. Architects and Software developers can
collaborate on process and service design
adjustments and ultimately deliver solutions for
implementation and runtime code (Deductive
modeling behaviors from BIAN to IFW to ensure
non overlapping service design patterns).
Using an implementation subset of CL
“initiateLoanArrangement”, we were able to observe the
following:
1. We were able to start with BIAN to scope the
business goal and strategy and through the
business partitions of areas, domains, and sub
domains arrive at a service landscape / business

10
scenario identifying the candidate service
‘initiateLoanArrangement’ The BIAN deliverables
can serve as a reference to benchmark
architectural documentation for:
a. Scoping from the general to the
particulars and identification of relevant
service domains via a BIAN business
event or scenario
b. Service domain(s) as they are identified
and developed ,
c. Identifying gaps or overlaps
2. The key transition methodology hinged on a new
BIAN-IFW mapping model created in this
exercise to provide the linkage of the two
frameworks. This is referred to as the BIAN-IFW
Alignment Model (See next section).
3. From the business scenario identified with its
associated lifecycle end points, the IFW process
focus was established. Service identification,
specification, and realization were carried out to
completion resulting in an executable service
model. We believe this unconstrained approach
showed significant promise in the CL scenario in
taking a conceptual business service, identifying
its business context and typical event packaging
drilling down to the service operation and IFW
scoped process activity leading to generative
code (XSD, WSDL). The top down BIAN-IFW
benefits :
a. Logical groupings of all banking
components
b. Managed consistency as long as there
is a common vocabulary
4. This value could be significantly higher when the
approach becomes more model driven than
model based closing the gap on documentation
as model with model semantics as source code.
This will increase productivity and software
quality in the area of consistency and cohesion.
BIAN-IFW Alignment Model
A pivotal modeling activity in the BIAN-IFW framework
was the creation of the “BIAN-IFW Alignment Model”.
This alignment model reflects the linkage between BIAN
component business scenarios and IFW Analysis
Process Models. This was an essential “first step” that is
highlighted here because it exemplifies the challenges of
what the nature of the synergy might be and to what
extent it will become over time. In both the top-down
and bottom-up scenarios, the bidirectional pathways
relied on this semantic and structural cross road to
identify existing assets as candidate services and
specify the creation or modification of candidate
services.
There are some noteworthy modeling challenges that
emerged from this significant modeling artifact:
1. Interpretation of semantics - syntax and
definitions. There is an implied ‘model lexicon’
to bridge meaning.
2. Interpolation or the creation of this mapping
artifact which preserves the two frameworks as
distinct and complementary. This artifact serves
as the ‘‘Rosetta Stone’ between BIAN and IFW.
3. End to end matching of the BIAN –IFW models
for maintaining reusability in the analysis and
design phase, and determining interoperability.
This artifact is the only bridge that connects the
end to end view of an Enterprise SOA Strategy
(Coarse grain) to execution (fine grain).
Standardizing and relating the meta models of
both frameworks will accelerate process and
service definitions which will facilitate adoption of
an enterprise meta model. Model changes in
the analysis and design “loop” for BIAN and IFW
can be complex due to the manual and
document centric nature of the artifacts.
4. Any third party firm entering into this symbiosis
will need to augment the BIAN – IFW assets with
internal capabilities to ‘adopt/adapt’ the standard
and its dynamic implementation as the
standards body matures resulting in changing
content with increase in adoption in the ISV
marketplace.
5. The service type of SOA intended by BIAN
(operational capability based reuse) and IFW
(typically software reuse) are reconciled in the
top down and bottom up scenarios through this
BIAN – IFW Model integration artifact that links
static ingredients with dynamic model behaviors.
6. Because of the evolving content and maturity of
the BIAN-IFW models, reconciliation of the two

11
in mapping will result in differences (gaps) and
sometimes, exact service matches.
Challenges & Opportunities
The POV was focused on the implementation of a
subset of AO & CL functionality in order to draw out the
implications of the BIAN-IFW framework. This was done
at the “modeling” level of the SOA stack. The exercise
uncovered several challenges and opportunities for all
three types of participants: BIAN, IT Solution Providers
like IBM, and Financial Services Institutions like PNC.
1. Interpretation
a. BIAN & IBM: Lack of a common
vernacular shared by IFW and BIAN
Service Landscape.
b. FSI: Investment in knowledge transfer
(i.e. people, process and technology).
2. Interpolation
a. Supplier like IBM to maintain mapping
and bridge to the marketplace.
b. FSI: Service Modeling, Management
and Governance
3. End2End Model Integrity
a. The BIAN-IFW models can be at
different levels of maturity, both are in-
flight with regards to content, and the
available hard assets continue to grow
with time. It will be up to each
stakeholder to pursue its strategy as
distinct and complementary for the
benefit of the marketplace in which the
winning strategy for bank modernization
will not take a linear course.
b. FSIs will continue to enter into this BIAN
– IBM alliance recognizing the value of
industry based standards, supplier
adoption rates, and interpreting the
symbiosis for its own strategic
advantage.
4. Model Integration
a. The TOGAF BIAN Collaboration Work
Group has articulated the BIAN to
TOGAF partnership1
. This study
prepares the way for examining what
value can be created in the MDA
standards arena and its application to
MDD.
b. FSI: While the BIAN – IBM partnership
moves us in the right direction of
interoperability and platform
independence and we await the
adoption by major ISVs and other key
players, FSIs will do well to be vigilant
but leveraging of SOA principles and
component development appropriately
for strategic advantage.
These challenges will require significant leadership,
collaboration, and investment as we mature the
symbiotic components of the service model process,
people, and technologies.
Potential Business Benefits from the
Industrialization of the Approach
We anticipate the following business benefits and
contributions by industrializing the approach outlined in
this paper:
 Cost: Increase operating leverage though
standardization (Certify ISV offerings to increase
standardization) and modernization
(componentized and service based enterprise
that would enable cloud and optional
outsourcing of shared business processes).
 Revenue: Improving agility and customer
innovation by increasing technology productivity
and time to market solutions in the IT supply
chain.
 Asset Utilization: via reuse and value creation.
 Business and Technology Leadership. The
rapid digitization of businesses is not just about
the pervasiveness and ubiquity of technology. It
is ultimately about digitization for strategic
advantage. The firm of the future that wins will
be the one who achieves agility as its core DNA.
1
Integrating the TOGAF® Standard with the BIAN Service
Landscape; A whitepaper by P.Bonnie, ING, Thomas OBITZ,
KPMG LLP (UK), and the TOGAF BIAN Collaboration
Work Group, October, 2013.

12
 Improving managed risk by leveraging “known
and proven asset use” and quality in change
management. Stronger business and
technology alignment through achieving MDD.
This would enhance traceability by installing a
‘round trip’ engineering approach to planning,
designing to implementation of services thereby
ensuring compliance to regulatory demands.
Manageability of complexity by having a pre-
defined pathway to interoperability and
portability. And finally the obvious impact
analytics that come from an enterprise
architected solution.
These business outcomes converge on a single value
driver for the bank of the future: Accelerating
shareholder value.
Contributions of this work to banking transformation
This exercise also brought out the possible options of a
core banking modernization program at the technical,
business, and industry levels. It demonstrates that it is
not too late to begin (given the challenges) to identify
what will be the dominant pattern for your bank
modernization strategy – single vendor vision (e.g. SAP)
as a closed solution stack or industry wide adoption of
technical, messaging, semantic, and service standards
or a third option, a hybrid of the two alternatives.
 Banks are more open to transformation -- they
see they have to develop a digital strategy. How
will banks transform into the digital future of
mobility, cloud, real-time technologies,
information analytics, & big data? These industry
based models (even in their current state) can
impact business outcomes and create value in
realizing enterprise agility by the careful
application of SOA principles and interoperability
design goals. At a minimum, these principles
and goals are essential because they emphasize
speed and nimbleness regardless of how the
end game plays out in the next 3-5 years.
 Architecture will play a strategic role in driving
the innovations required for modernization, but
more importantly, enterprise architects have a
significant opportunity to reap the benefits of the
BIAN – IFW synergies and accelerate their work
by laying a roadmap of the future consisting of
SOA principles and interoperability (plus
platform independence) linked to business
outcome and value. In terms of architectural
work, the IFW standards establish a shared
approach and vocabulary. The definition of the
architecture capability in the IFW standard helps
to identify processes relevant for setting up
appropriate architecture governance. The BIAN
deliverables can serve as a reference to
benchmark architectural documentation, for
identifying gaps and redundancy, and for
structuring the response to business events.
 Disintermediation. These capabilities are
critical not only because they are linked directly
to growth, but also because the growing number
of potential non-traditional competitors (such as
PayPal and Google) are very good at digital
customer engagement. How will banks compete
with these companies in the future? They have
to put the customer at the center. Digital and
mobile apps are all about the customer. In
mobility, usability is everything. "If customers
don't like a company's app, they'll delete the app
and download a different one. It's no different in
banking than in consumer products. The
disintermediation threat isn't just about losing
revenues, as banks get disintermediated, they
are losing information about the customer" -- for
example, when they lose payment flows (and the
related customer data) to an alternative
payments company such as PayPal.
Conclusion
We set out initially to prove the value of the BIAN-IFW
Framework. We conclude with a summary of what we
achieved:
1. An alignment of IBM Banking Models (IFW) with
BIAN Service Landscape (SL).
2. The utilization of IBM Banking Models & Tools in
developing IT solutions conforming to BIAN
standards for both top-down & bottom-up
approaches.

13
3. An end-to-end methodology for solution design
& implementation leveraging BIAN Service
Landscape.
4. Incremental advance of the PNC Component
Business Modeling project.
5. Contributions to the cause of BIAN by
generating and sharing insight on the practical
use of the Service Landscape.
IBM and the IBM logo are trademarks
of International Business Machines
Corporation in the United States, other
countries, or both.
Other company, product or service
names may be trademarks or service
marks of others.
References in this publication to IBM
products, programs or services do
References in this publication to IBM
products, programs or services do not
imply that IBM intends to make these
available in all countries in which IBM
operates. Any reference to an IBM
product, program or service is not
intended to imply that only IBM ’s
product, program or service may be
used. Any functionally equivalent
product, program or service may be
used instead.
IBM may have patents or pending
applications covering subjects in this
document. The furnishing of this
document does not give you any
license to use these patents.
The IBM home page can be found on
the Internet at ibm.com
This publication is for general guidance
only.
Licensed Materials – Property of IBM
© Copyright IBM Corp. 2014.
All Rights Reserved.

BIAN_IBM_PNC_white-paper_2014

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to BIAN_IBM_PNC_white-paper_2014 (20)

More from Asish Mohanty M@Vodafone Group (12)

BIAN_IBM_PNC_white-paper_2014