Skip to content
Avatar

Services Oriented Architecture in a Retail Bank (BankTech.06)

The talk I gave at BankTech.06 on embedding SOA in a retail bank, reproduced from the slide deck, including the observation that NAB's ten architecture capabilities described an SOA while carefully avoiding the word.

This is the talk I gave at BankTech.06 in Sydney on the 27th and 28th of July 2006, when I was Head of Architecture, Technology Australia, Retail Banking at NAB. It is reproduced from the PowerPoint deck, and that makes it necessarily brief. A deck is scaffolding for a person standing in front of it, not a paper: the argument lives in what was said between the slides, and none of that was recorded. There are no speaker notes in the file. What follows is therefore the skeleton of a talk rather than the talk, and it reads like one — telegraphic where I would have been discursive, and silent exactly where the interesting part was.

The file’s own dates settle when it was written: created on the 27th of June 2006, last saved on the 5th of July, three weeks before the conference, across thirty revisions and seven and a half hours of editing. Ignore the “last printed” stamp of the 14th of February 2006 — it is four months earlier than the creation date, because it belongs to the nab+White+Background template the deck was built from and PowerPoint carried it forward.

Slide 19 carries ten [Commercial in confidence] markers. Those are mine, put there in 2006: the retail bank’s strategy boxes were blanked for a public audience and the surrounding scaffolding left in place, with one column deliberately readable because it was the one I wanted to talk about. The slide is reproduced as it stood, redactions and all. Nothing has been removed from it since.

Slides are given one to a section, in order, at the numbering the deck uses, so the numbering below skips the five that are not reproduced: the contents slide reappears unchanged at 8, 11, 16 and 21 to mark each section boundary, and 29 is a closing “thank you”. Nothing is lost by leaving them out — slide 2 carries the contents in full. Of the twenty-four that remain, ten are drawings and are reproduced as vector figures, converted from the deck itself rather than photographed: slides 6, 13, 14, 15, 18, 19, 20, 23, 24 and 28. The rest are set as text.

Three repairs are worth naming. Slide 15 carried nine stray shapes at coordinates a thousand times outside the slide, invisible in PowerPoint but not to a converter measuring the drawing’s extent, and it has been cropped back to the real slide canvas; slide 28 was cropped the same way, having carried six thousand units of empty space to the right of everything on it. On slide 20 the conversion broke two words across lines, leaving “Architectur e To Enable” and “Architectur e” in the theme boxes; both are rejoined, with the advance widths corrected so the text still sits where it did.

The words on every slide are the deck’s own, down to its ampersands and its abbreviations. Three things on the page are not. Three headings are split where two text boxes butt together in the source and run into one word — “Enterprise ArchitectureEnterprise Architecture Definitions”, “Mediation and Transport RefreshRationale and Objectives”, “SOA Working Groupestablish and govern”. A stray superscript 2 on slide 4 is dropped, a footnote marker pointing at a footnote that is not on the slide. And slide 14’s closing line is quoted beneath its figure as well as appearing in it, because it is the sharpest thing in the deck.

One thing in the deck is worth flagging up front. Slide 5 reports Gartner’s claim that “service oriented architecture” was coined in 1994 as a synonym for client/server. I had given a paper on client/server architectures that same year, which I did not know when I put the slide together.

Download the presentation (PPT, 464 KB)

Chris Tham Head of Architecture, Technology Australia, Retail Banking, NAB

1 Services Oriented Architecture

Where are the opportunities and challenges of embedding SOA in a Retail Bank?

Chris Tham (chris.tham@nab.com.au), Head of Architecture, Technology Australia, Retail Banking. Banktech.06, 27–28 July 2006, Sydney.

2 Contents

  • What is a Services Oriented Architecture (SOA)?
  • Positioning SOA against an overall Enterprise Architecture
  • SOA in the context of NAB Technology Strategy
  • Obtaining business buy in and alignment
  • NAB approach to date in implementing SOA

3 Just what is “SOA” anyway?

  • “The best thing since sliced bread” – guaranteed to cure cancer, solve world hunger, and retire Third World debt
  • Something to do with SOAP and Web Services
  • What my vendor says will be supported in their “Next Generation” product
  • Yet another meaningless Three Letter Acronym, to be replaced by another fad in 3 years
  • It’s the same thing as (OOP, RPC, CORBA, CICS, …)
  • All of the above?

4 SOA – Industry definitions

Four definitions, quoted as they stood on the slide.

SOA is an architectural style for building software applications that use services available in a network such as the web. It promotes loose coupling between software components so that they can be reused. Applications in SOA are built based on services. A service is an implementation of a well-defined business functionality, and such services can then be consumed by clients in different applications or business processes.

SOA allows for the reuse of existing assets where new services can be created from an existing IT infrastructure of systems. In other words, it enables businesses to leverage existing investments by allowing them to reuse existing applications, and promises interoperability between heterogeneous applications and technologies. SOA provides a level of flexibility that wasn’t possible before in the sense that:

Services are software components with well-defined interfaces that are implementation-independent. An important aspect of SOA is the separation of the service interface (the what) from its implementation (the how). Such services are consumed by clients that are not concerned with how these services will execute their requests.

  • Services are self-contained (perform predetermined tasks) and loosely coupled (for independence)
  • Services can be dynamically discovered
  • Composite services can be built from aggregates of other services

Service-Oriented Architecture (SOA) and Web Services: The Road to Enterprise Application Integration (EAI), Sun Developer Network (http://java.sun.com/developer/technicalArticles/WebServices/soa/)

“SOA is a component model that inter-relates the different functional units of an application, called services, through well-defined interfaces and contracts between these services”. Defined as such, SOA is a collection of patterns for building an enterprise-level integration layer between applications while abstracting those applications as services. SOA approach advocates the use of open standards, while not ruling out proprietary technologies where they are appropriate, when integrating applications.

SOA relies on exposing application functions as services that can be invoked by external parties. The commonly agreed aspects of the definition of a service in SOA are:

  • Services are defined by explicit, implementation-independent interfaces.
  • Services are loosely bound and invoked through communication protocols that stress location transparency and interoperability.
  • Services encapsulate reusable business function.

Develop a migration strategy from a legacy enterprise IT infrastructure to an SOA-based enterprise architecture, Artem Papkov (artem@us.ibm.com) (http://www-128.ibm.com/developerworks/webservices/library/ws-migrate2soa/)

A style of design, deployment, and management of both applications and software infrastructure in which:

  • Applications are organized into business units of work (business services) that are (typically) network accessible.
  • Service interface definitions are first-class development artifacts, receiving the same degree of design attention (and more) as databases and applications.
  • Quality of service (QoS) characteristics (security, transactions, performance, style of service interaction, etc.) are explicitly identified and specified for each service.
  • Software infrastructure takes active responsibility for managing service access, execution, and QoS.
  • Services and their metadata are cataloged in a repository and discoverable by development tools and management tools.
  • Protocols and structures within the architecture are predominantly, but not exclusively, based on industry standards (such as the emerging stack of standards around SOAP).

Your Strategic SOA Platform Vision, Randy Heffner, Forrester

Service-oriented architecture represents a framework facilitating integration and interoperability of disparate systems. A service-oriented architecture consists of three key elements: a collection of services, a connection protocol by which these services can be accessed and can access each other, and a repository containing a catalog of available services. The governing principle of service-oriented architecture states that applications implement a collection of business capabilities and each of these capabilities can in turn be implemented by services, specialized pieces of software that implement a single business capability. Standardization acts as the key to a successful service-oriented architecture; not only must all services have the same structure in terms of the interface they present to the outside world, they must follow a standard protocol for advertising what they do and how they can be accessed and used.

Service-Oriented Architecture: Theory and Practice, Corporate Executive Board

5 What is a “Service-Oriented Architecture”

According to Gartner, the term “service oriented architecture” was first coined in 1994 by Alexander Pasik (a Gartner analyst) as a synonym for “client/server architecture” (request-response model for interprocess communication).

The current usage of the term has been expanded to incorporate IT concepts such as:

  • Distributed computing
  • Web services
  • Functional modularisation across applications
  • Object orientation

Related terms include:

  • Business process modelling and orchestration
  • Composite applications
  • Reusability
  • Component Architecture
  • Enterprise Service Bus
  • Workflow
  • Virtualisation

6 SOA definition as used in NAB — Integration Services Architecture Framework

A diagram of the NAB service model. An Integration Bus runs along the top; below it a Service box branches to three coloured boxes, Business Rule, Business Function and Business Process. To the right a stacked service taxonomy, Presentation Services, Distribution Services, Integrated Services over three Domain Services, and Technical Services, sits beside notes that the taxonomy defines how services interact, how they are governed and the key expected reuse points

7 Architectures : Service Taxonomy

Element What it does
Business Rule Business Rules do not change the business state. Instead, a rule derives business information. As such, rules are often described as calculations, decisions or lookups. These rules may ultimately lead to an outcome or action, but these are always realised through the vehicle of a process or function interacting with the rule. The actual execution of the rule only produces the derived information.
Business Process Business Processes achieve this result by managing a process-driven interaction between Business Processes, Business Functions, Business Rules. Thus the process realises a process inherent in the activity of the business.
Business Function Business Functions achieve this result by manipulating Technical Services (as well as interacting with other functions). In this respect a business function translates a business event (or function, or service) into the IT domain. The result of a Business Function may ultimately be a change in a database, a series of transactions or similar outcomes. A Business Function can also encapsulate an interaction with a user. This is expressed within the high-level patterns.

Business Functions and Business Processes tangibly change the business state from a business perspective. This is a distinct business outcome. For example, a payment is made or a new account is opened.

9 SOA in relation to Enterprise Architecture — Enterprise Architecture Definitions

ANSI/IEEE Std 1471-2000 definition of architecture:

“the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”.

Architecture description: a formal description of an information system, organized in a way that supports reasoning about the structural properties of the system. It defines the components or building blocks that make up the overall information system, and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system. It thus enables you to manage your overall IT investment in a way that meets the needs of your business.

Architecture framework: a tool which can be used for developing a broad range of different architectures. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.

Architecture Definition
Business (or business process) architecture this defines the business strategy, governance, organisation, and key business processes.
Application architecture this kind of architecture provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
Information/data architecture this describes the structure of an organization’s logical and physical data assets and data management resources.
Technology/Infrastructure architecture this describes the software infrastructure intended to support the deployment of core, mission-critical applications. This type of software is sometimes referred to as “middleware”.

Definitions taken from TOGAF Version 8. Where does Service Oriented Architecture sit?

10 Degrees of Service Orientation

  • Services Oriented Organisation — entire organisation modelled as a set of services, and roles and responsibilities aligned to
  • Services Oriented Business Unit/Process
  • Services Oriented IT — every IT function defined as a service
  • Services Oriented Architecture
  • Services Oriented Project
  • Services Oriented Application
  • Services Oriented Infrastructure

12 Drivers for NAB Technology Strategy (2005)

Key Business Drivers Key Technology Drivers
Objective to build a customer-centric organisation Ageing technical platforms do not have the functionality, flexibility or speed-to-market required
Need for new capabilities to manage a portfolio of businesses Need to address some critical execution, workforce management and sourcing capability gaps
A strong drive for cost competitiveness NAB’s traditional approach to managing IT has left the business poorly positioned to compete
A rebuild of critical infrastructure

13 An Enterprise Architecture is a key component of the Technology Strategy

Three horizontal bands, each opening with a numbered chevron. Band one, transform platforms to enable business strategy, holds three boxes of which A, move to integrated enterprise architecture with new capabilities, is ringed by a hand-drawn ellipse. Band two, uplift delivery capabilities to best in class, holds four ellipses around a central one, E, manage IT for value. Band three, manage IT differently to enable business transformation, holds three boxes. Key benefits are listed down the right of each band

14 The IT Strategy defines 10 major Architecture Capabilities …

The ten architecture capabilities in two columns of green boxes numbered 1 to 10, each paired with the bullets it must support. A hand-drawn ellipse rings capabilities 1 to 5 in the left column. A banner across the foot reads that these essentially describe the key characteristics of a Services Oriented Architecture, but avoiding the use of jargon

The line along the bottom reads:

… Essentially describing the key characteristics of a Services Oriented Architecture, but avoiding the use of jargon!

15 The 10 capabilities are mapped into an integrated Enterprise Architecture

The target enterprise architecture. Five horizontal layers, presentation and modular front end components, integration, support and information, transaction processing and infrastructure, cut by four business columns, wealth, retail, business, and finance and corporate. Named platforms sit in the layers, including the relationship-banker and Shop front-end platforms, regional integration services, core customer information, modular product manufacturing and administration, shared processing utilities and regionally interoperable infrastructure. Ten numbered lines connect them to the ten architecture capabilities listed on the right. Below, three thumbnails show the application, information and infrastructure architectures. Sourced from NAB Technology Strategy 2005

17 Key steps taken to obtain business buy in

CEO and Executive Committee: recognise importance of architecture

  • Alignment to enterprise architecture is now a necessary precondition for approval of new projects
  • Reconfirmation of Strategic Architecture Forum as the prime governance body for approval of major architecture decisions and ensuring programs implement agreed solutions

Head of Retail Banking Operations: conceptual discussion on SOA

  • Executive sponsorship and support for key SOA-aligned projects

Retail Banking Business Strategy

  • Explicit recognition of SOA as a strategy for realising a component of the business strategy
  • SOA initiatives embedded in Investment masterplan
  • Implementing business process management and workflow for consumer lending fulfilment based on TIBCO iProcess and BusinessWorks
  • Implementing a regional customer index supporting an integrated product offer based on IBM WCC

18 Strategic Architecture Forum is established to govern architecture

A governance chart. The Strategic Architecture Forum sits at the top listing its membership, the CIO, GM Strategy and Transformation as chair, the Chief Architect and six Heads of Technology. Below it, Heads of Architecture and business unit IT leadership teams feed a grey panel of Architecture Working Groups, eight named groups plus a Technical Infrastructure column carrying five sub-groups for mainframe, storage, mid range, end user computing and networking. Integration Services is ringed by a hand-drawn ellipse. Four annotations sit around the edges

19 Explicit recognition of SOA in Retail Banking Business Strategy

A five-row grid, Retail Bank Purpose, Differentiating Strategies, Enablers and Closing the Gap Strategy, Design and Solution Principles, and Key Leverage capabilities, with columns for Distribution Network and Sales Effectiveness, Remote and Electronic Channels participating in Sales, Product Solutions, and Efficiency. Most cells read Commercial in confidence. The Product Solutions column is left readable and ringed by a hand-drawn ellipse, listing what molecules, how to sell fulfil and service product bundles, and beneath it that molecule and customer focus lifts our game from single product focus and capacity, is not cross sales, a default molecule for mass market, and that the toolset needs to support molecule sales. Marked Work in Progress

20 Initiation of several key business initiatives delivering SOA components

A roadmap across 2006, 2007 and 2008 against four numbered green theme boxes: transform architecture to enable business needs, de-risk our architecture, reduce the inherent costs in our platforms, and redefine and strengthen our governance. The bars carry no labels except one running the full width of theme four, develop enterprise architecture. A legend keys them three ways, in-light or started project, new business initiatives, and suggested new initiatives. An ellipse rings the cluster under theme one

22 Current NAB approach in implementing SOA — Activities undertaken

  • Services Oriented Architecture is a key component of the overall Enterprise Architecture work plan (funded via the Investment master plan as well as Technology budget)
  • Integration Services Reference Architecture defined
  • Integration Services Cookbook (patterns and guidelines) defined for two major programs
  • Product evaluation to select key products for Mediation and Transport layer in Integration Services Architecture Framework
  • SOA Working Group established to govern definition and adoption of SOA
  • Innovation Lab established to future proof specific SOA components

23 SOA is a key component of overall Enterprise Architecture work plan

A roadmap chart across 2005, 2006, 2007 and a Not Prioritised column, with five workstream rows, Information Architecture, Integration Services Architecture, Sales Service and Channels Architecture, Product Manufacturing Architecture, and Efficiency and Operations. Around forty initiatives are drawn as chevrons keyed by status: completed, EA Planning Forum funded, in progress, not started, and not a strategy priority or managed elsewhere. A large ellipse rings the Integration Services, Sales Service and Channels, and Product Manufacturing rows

Three footnotes sit under the chart: initiative 1 was added after Portfolio Review and E2E de-scoping; 2 Imaging was added although it was originally in Doc Production; and 3 E2E Lending Strategy is to be treated as Current State Assessment input to Origination and Fulfilment.

24 Integration Services Reference Architecture

The reference architecture as a block diagram. Four stacked core capabilities, Business Process Integration, Business Function, Mediation and Transport, sit above Hardware and Network Infrastructure, flanked on the left by vertical Management, Security and Identity, and Business Rules columns and on the right by Data Objects and Metadata Definition. Labelled beneath as supporting capabilities enabling the operational and security architectures, core capabilities governed by the integration architecture, and supporting capabilities enabling the information architecture. A thumbnail of the target enterprise architecture sits top left, zooming in on the regional integration services row

It provides a consistent language to evaluate, position and evolve integration capabilities and assets. This representation shows the “Level 0” capabilities. This is underpinned by another two levels of detail (to Level 2). Each capability, at any level, has a description, rationale and a set of guidelines. Depending on the particular capability, a set of recommended standards are also defined.

The Reference Architecture is a tool – it provides the foundation and a single point of reference for the rest of the Integration Operating Framework. It has been developed by NAB Stakeholders, Architects, Industry Experts and NAB Subject Matter Experts.

25 Mediation and Transport Refresh — Rationale and Objectives

There are a number of current drivers and planned investments that require a strategic positioning in the mediation and transport layers of the Integration architecture, including:

  • Multiple investments in the integration stack by competing projects
  • Technology risk in current integration layer
  • Key capability gaps in current integration layer

The Key Objectives for this exercise are:

  • Select a Vendor that can provide the regional integration capabilities (Mediation and Transport) for the organisation.
  • Determine best approach for migration of existing assets to the new platform.
  • Review and determination of the direction for the Integration Centres of Competency (CoC).
  • Spot opportunities for a new solution to simplify, decommission or otherwise improve the NAB IT environment.

26 SOA Working Group — establish and govern usage of new and emerging integration technologies within a service model

Purpose: The SOA Architecture Review Group was introduced to develop the reference architecture for Service Orientation. It has progressed to development of programme architecture to provide overall architecture governance that ensures programme activities are aligned to the business and IT strategies.

The SOA AWG’s objective is to:

  • Ensure that SOA is implemented within the organisation such that it supports business plans and strategies
  • Provide agreed policies, principles, standards and architectures to guide the delivery of SOA, and rationale is understood
  • Ensure that optimised architecture decision making is attained with high level business buy-in
  • Give clear direction to programme and projects
  • Review key strategic architecture and solution design decisions – focussing on both “what” (conceptual), “how” (physical/pragmatic/delivery/transition) and “why”.

Engagement with the SOA AWG must be:

  • Through formal agenda items notified through the SOA AWG Lead or Project Director
  • During key milestones of a project/release that effect the delivery of a service model.
  • For all Enterprise Architecture decisions effecting the SOA related assets
  • For all key SOA Asset Life Cycle Plan

27 SOA Working Group — Responsibilities and Benefits

Responsibilities:

  • Develop an SOA containing agreed policies, principles, standards and architectures to guide the delivery of services in the organisation.
  • Provide the avenue for architects, release solution architects and solution designers to recommend, review and approve SOA solution design decisions.
  • Review and recommend SOA standards for submission to the SAF.
  • Providing guidance on how other projects and systems interact with SOA AWG.

Benefits:

  • Results in improved organisational agility and speed to market for programme to deliver towards business goals
  • Ensures a clear line of sight between business goals and the underlying architectures required to support them
  • Ensures SOA artifacts are endorsed and implemented consistently
  • Ensure programme releases are delivering sustainable SOA capability
  • Promotes reuse of architecture artifacts
  • Reduces overall TCO of systems and applications

28 Innovation Lab

On the left, the lab architecture: a Business Process Development panel with WB Modeler, Process Design, Real data and Business Prototypes around an orange cycle, a Service Orientated Architecture panel with WS Integration Developer, Service Orchestration, State, Business Process and EAR, and a Strategic Front End Architecture panel where a User feeds Service Mediation above three Business Services and three Technical Services. On the right, three streams are described, Business Process Development, Statefull Service Orchestration and Banker Central Portal

Sources

  • Banktech06 NAB Chris Tham SOA.ppt, the presentation file, 29 slides, created 27 June 2006 and last saved 5 July 2006. Reproduced above and available for download at the head of this article.
  • Slides 12 to 15 draw on the NAB Technology Strategy 2005, which slide 15 cites by name.
  • Slide 4 quotes four external definitions, attributed on the slide to the Sun Developer Network, IBM developerWorks, Forrester and the Corporate Executive Board. The two URLs are given as they appeared in 2006 and both have since moved.