IDC's Financial Service Congress 2012 Presentation on IT Simplification, Integration, and SOA.

2. Keys to successful
integration for your
banking transformation
Axel Winter
Global Head Transaction Architecture
Standard Chartered Bank

3. “The New Normal”

4. Banks are changing, too
Organizational changes in banks,
integration Operations and
Technology
Value Networks with Retailers,
Telecoms, and Internet companies
Increase Value Generations and
decreased time to market
User increasingly focus on short
term needs
Long term decisions to be crafted
by Technology Teams
Sprawl of new technologies, to be
expected

5. Integration isn’t only a
Technology challenge
Technology view onto integration is to
exchange data between two or more
systems.
However, in truth we are enabling a business
process and capabilities across multiple
applications and technologies
The core goal is to facilitate these processes
seamlessly

6. The myth is ‘integration’ is
about technology only
Systematic issues: Hands on issues:
Drives System Custom Databases in X
Maintenance OPEX number of Systems
growth X number of Applications
Complexity drives used by one user
increased amount of For new products X
incidents and number of Systems to
prolonged resolution change
time resulting in X number of Vendors to
business impact/loss manage and require
Results in Capacity involvement in system
Limitations changes supporting a
single product
The Fragmented Architecture approach demands each applications to interface with each other. A replacement
of one point will automatically impact all connections. The Targeted Architecture prevents this complexity by
using middleware to 'own' the interfaces.
Implementing a tool set to specialize in integration and
'normalizing' interfaces into a common standard.

7. Enterprise Service Bus
• Every Application and
every interface type can be
integrated
• Providing general services
for all any-to-any
integration, with all
technologies
• Normalized Interfaces are
generic enough to be
reused, translation into
specifics done by the ESB
• Applications become
Service or Capability
providers vs. locked-in
source code.

8. Create Functional Interfaces
and measure benefits
• Creating Functional
Interfaces
(“Account Inquiry”)
and not application
to application
interfaces
• Measure benefits
and improve, where
required
• Start with tight
control and
management

9. Integration Design
Principles
Interfaces are autonomous — The logic governed by each service resides within an
explicit boundary. The service has control within this boundary, and is not dependent
on other services for it to execute its governance
Interfaces share a formal contract — In order for services to interact, they will not
share anything but a collection of public metadata that describes each service and
defines the terms of information exchange
Interfaces are loosely coupled — Dependencies between the underlying logic of a
service and its consumers are limited to conformance of the service contract
Interfaces abstract underlying logic — Underlying logic, beyond what is expressed
in the service contract metadata, is invisible to the outside world
Interfaces are composable — Services will compose others, allowing logic to be
represented at different levels of granularity. This promotes reusability and the
creation of service abstraction layers
Interfaces are reusable — Regardless of whether immediate reuse opportunities
exist, services are designed to support potential reuse
Interfaces are stateless — Services are designed to maximize statelessness and
state management are deferred to transactional database

10. ESB Implementation Models
Single Enterprise Bus – Technology governance, – Single vendor lock in
Input Channels Output Channels architecture, design and – Redevelopment of
guidelines are standardised existing services using
“One bus for the
– No interoperability issues other technologies
enterprise”
– Skill requirements – Cannot leverage some
LOB LOB LOB LOB LOB LOB standardised existing investments
1 2 3 4 5 n
– No need for bridge
technologies / development
Peer to Peer ESB – Existing services can be – Each LOB has different
LOB 1 LOB 2
reused directly (providing architecture, design ,
“One bus for interfaces allow for patterns and standards
LOB n LOB 3 each lines of interoperability) – Different ESB
business – No interoperability issues for technologies impose
LOB 5 LOB 4 LOBs using same technology significant interoperability
– Cross LOB service requests challenges
hops are limited to two
Federated ESB – Common ESB can be used by – Need for bridge
LOBs with no existing ESB technologies /
LOB 1 LOB 2 LOB 3 “One common – Common ESB is not development
bus to integrate detrimental to existing ESBs – Different ESB
the enterprise” – Standardisation of governance, technologies impose
LOB n LOB 5 LOB 4 architecture, design and significant interoperability
guidelines challenges

11. Governance
Pre-Project Governance
Project Project Governance Run Time Governance
(What are the right (How should the (How should the
services to build) services be designed services and processes
and build in a right be monitored and
• Interface Portfolio way?) managed?)
• Project Identification • Technology Reference • Monitor and Manage
• Funding Architecture
• Security Reference
Architecture
• Patterns and
Frameworks
• Information model and
Schemas

12. Design Approach
Consideration
Business Transformation
Top Down Business Model Change
Mergers & Acquisitions
Transform one process area at a time
Middle Out
– gain process visibility & control
Re-factor legacy interfaces and
Bottom Up
extract application services/ events

13. Driving Process Changes
often fails to deliver value
Central Reengineering often LEAN Six Sigma linking SMEs
delivers short term success and smaller teams
Service Providers deliver great Linking Process Design
processes, but adoption fails Capabilities to a execution
function with key metrics
Organization to fixed for self-
help Refocus Metrics
Over customization of Plan for “Customizations”
processes Empower Team Leaders and
Teams stick to broken focus on skill development
processes and wait for external Adopt Business Process
help Management Technologies, for
Applications “force” users into user manageable processes and
processes, but can be difficult faster time to delivery
to adapt

14. Transformation Journey
Future
Corporate State Refined
Vision & Objectives Strategy Strategy
Strategy
Design
Operating Model Facilities
Work Plan
Charter
Process Design
DESIGN BUILD
Planning Risks & Issues
Define Scope
REQUIREMENTS Assess Current State
Organization Finance
Envision
Governance
Organizational Design
Team Structure Architecture Vendor Selection Data & Workforce Transition
Current State
Enterprise
Innovation Future State
Architecture
Change Leadership Communications
Management Alignment
Leadership Alignment
Often Underestimated Stakeholder Engagement Management Technology
Strategy People
Operations Convergence

15. Goal: Creative Composites
Decompose Capabilities into functional building
blocks
LEAN before digitize – “under engineer”
processes
Drive Technology Expertise in-house with
vendors supporting, but not driving
Evolve versus Large Spent Projects
Both Open Source and Commercial Software
will address all needs

16. Final Considerations
Business Process Management based applications
Developing uniquely reusable “atoms” or components,
owning capabilities
Reconsider legacy technologies (e.g., Traditional
Databases, monolithic applications)
Considerations for “Buy” or “Build” and Consider Build
Drive deep technical expertise
Avoid Vendor Drive Architectures
Make use of an Enterprise Architect

17. Contact Information
Axel Winter
Global Head Transaction Architecture
Standard Chartered Bank
axel.winter@sc.com or aw@axelwinter.com