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
Integration isn’t only aTechnology 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
The myth is ‘integration’ isabout technology onlySystematic 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.
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.
Create Functional Interfacesand 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
Integration DesignPrinciples 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
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
GovernancePre-Project Governance Project Project Governance Run Time Governance(What are the right (How should the (How should theservices 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
Design ApproachConsideration 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
Driving Process Changesoften 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
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
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
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
Contact InformationAxel WinterGlobal Head Transaction ArchitectureStandard Chartered Bankaxel.email@example.com or firstname.lastname@example.org