Transforming an Architecture Practice -

29
Transforming an Architecture Practice Chris Palmann Peter Eeles Design Transformation Lead FSS Industry Lead Lloyds Banking Group IBM Rational Worldwide Tiger Team [email protected] [email protected] 1685A © 2013 IBM Corporation

Transcript of Transforming an Architecture Practice -

Page 1: Transforming an Architecture Practice -

Transforming an Architecture Practice

Chris Palmann Peter Eeles

Design Transformation Lead FSS Industry Lead

Lloyds Banking Group IBM Rational Worldwide Tiger Team

[email protected] [email protected]

1685A

© 2013 IBM Corporation

Page 2: Transforming an Architecture Practice -

Agenda

Background to the Architecture Practice

Industry Input

From Theory to Practice

Summary

2

Page 3: Transforming an Architecture Practice -

About Lloyds Banking Group

Lloyds Banking Group is the UK’s largest Bank

30m Customers

100,000 Employees

UK’s leading provider of current accounts,

savings, personal loans, credit cards &

mortgages

Brands include Lloyds TSB, Bank of Scotland,

Halifax, Scottish Widows, Cheltenham &

Gloucester

3 3

Page 4: Transforming an Architecture Practice -

Company History

4

Lloyds Banking Group has been created from a series of mergers and

acquisitions….

… which created a complex legacy of IT applications, data and

infrastructure

Halifax

1852

Bank of Scotland

1695

TSB

1810

Lloyds Bank

1765

Llyods Bank

International

1911

HBOS

2001

Lloyds TSB

1995

1986

Lloyds Bank

Group

2009

Scottish Widows

1815 2000

2009

SWIP

2000

4

Page 5: Transforming an Architecture Practice -

Transformation Roadmap

5

0

10

20

30

40

50

People

Lifecycle

ToolsOrganisation

Language

Target State

5

Current

State

Industrialised Design 3E Plan

Target State

Industry

Standard

Design

People

Industry

Standard

Skills

Multiple Lifecycles

Waterfall,

Agile

Tools

RRC

RSA

RTC

Organisation

One Team

Collaborative

Language

UML 2, TML, IDF

0

5

10

15

20

25

30

People

Lifecycle

ToolsOrganisation

Language

Current State

Target State

3rd July 2012

Industrialised Design V1.0

Ready for General Rollout

LBG Design Process

People

LBG Defined Skills

Lifecycle Waterfall – One

size fits all

Tools

Word, Visio

Organisation

Siloed, Onshore, Defensive

Language

UML Lite

Use professional industry tools and

methods to deliver high quality designs fast

Page 6: Transforming an Architecture Practice -

Benefit Levers being Exercised

Business Benefits IT Enablers

Faster

Cheaper

Better

Collaboration

Standardisation

Reuse

Visibility and

Transparency

Impact Analysis

6

Page 7: Transforming an Architecture Practice -

Scope of Industrialised Design

7 7

Business GITO EAD ADM

SD Setting Business Vision

Defining Requirements

Defining Business

Process Changes

Requirements Gathering

Creating Business

Requirements

Creating Solution

Requirements

Identifying key

architectural elements

Concurrent

consideration of

functionality,

infrastructure, data and

security

Deriving solution

elements from (and

tracing elements to) the

defined requirements

Communicating the

architecture to

stakeholders

Producing and

consuming reusable

assets

Architectural governance

Detailed Design

Build

Test

Physical Design

Rational Transformation Programme

Page 8: Transforming an Architecture Practice -

Agenda

Background to the Architecture Practice

Industry Input

From Theory to Practice

Summary

8

Page 9: Transforming an Architecture Practice -

Inspiration

9

“If I have seen further it is only by standing on the shoulders of giants”

Sir Isaac Newton, letter to Robert Hooke, 15th February 1676

9

Page 10: Transforming an Architecture Practice -

Rational Unified Process

10

The Rational Unified Process (RUP) is an iterative software development process framework. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by organisations and software project teams that will

select the elements of the process that are appropriate for their needs.

The Industrialised Design Method is based on elements of RUP, tailored to suit the Group’s requirements.

The RUP has a project life cycle consisting of four phases. • These phases provide a focus for the iterations that are an inherent part of the project lifecycle • Each phase has a key objective and an associated milestone that denotes the objective being accomplished.

Mapping RUP to the Industrialised Design Method • Disciplines are organised by logical coherence

• The Industrial Design Method covers the Analysis and Design discipline.

• Phases are organised by timeframe:

• Most of the work for the Industrial Design Method will be done in the Inception and Elaboration Phases • Some work could also happen in the other phases if change requests or defects have to be respected • The significant milestone for the Industrial Design Process is the “lifecycle architecture milestone” at the end of the elaboration phase as one of its most significant demands is a stable architecture.

10

Page 11: Transforming an Architecture Practice -

Summary of Best Practices

Establish a sense of urgency

Create the guiding coalition

Develop a vision and strategy

Communicate the change

vision

Empower employees for

broad-based action

Generate short-term wins

Consolidate gains and produce

more change

Anchor new approaches in the

culture

Consider all elements of a

development ecosystem

Plan improvements around

capabilities

Adopt capabilities

incrementally

Embrace principles of

organizational change

Implement a center of

excellence

Rational Kotter

11

Page 12: Transforming an Architecture Practice -

Can you Spot the Innovation Enablers?

12

Page 13: Transforming an Architecture Practice -

Proven Architecture Practices

13

Asset reuse

Quality attribute-

driven

development

Decision

capture

Component-based

development

Multiple

views

Architecture

proving

Page 14: Transforming an Architecture Practice -

Agenda

Background to the Architecture Practice

Industry Input

From Theory to Practice

Summary

14

Page 15: Transforming an Architecture Practice -

15 15

Industrialised Design Method Overview

Requirements Project Architecture Development

Requirements Functional

Non Functional

Req

uir

emen

ts

Art

efac

ts

Det

aile

d D

esig

n, B

uild

, Tes

t an

d Im

ple

me

nt

Outline Architecture Elements

Quality Gate

Application

Data

Infrastructure

Secu

rity

Business

Analyst

Business

Requirements Functional

Requirements

Architecture

Overview

Quality Gate

Detailed Architecture Elements

Infrastructure

View

Detail Architecture Elements

Data

View

Application

View Security

View

Non Functional

Requirements

Outlined Architecture Elements

Release

View

Secu

rity

Application

Data

Infrastructure

Architect

Architecture Guidance & Support

Quality Gate

Reusable Assets

(Models, Patterns,…)

Application

Model Infrastructure

Model

Data

Model

Application

Model Infrastructure

Model

Data

Model

Application view

Infrastructure view

Data view

Security view

Release View Software Architecture Description

Other

Views

Page 16: Transforming an Architecture Practice -

Architecture Method within the Architecture Practice

Survey

architecture

assets

Update software

architecture description

Review architecture

with stakeholders

Validate

architecture

Define architecture

overview

Document

architecture

decisions

Outline application

elements

Verify

architecture

Build

architecture

proof-of-concept

Elaborate

requirements

Outline security

concerns

Outline data

elements Outline infrastructure

elements

Detail application

elements Detail data

elements Detail infrastructure

elements

Detail security

concerns

Detail Architecture

Elements

Outline Architecture

Elements

16

Page 17: Transforming an Architecture Practice -

Method extended into Application Development

Survey

architecture

assets

Update software

architecture description

Review architecture

with stakeholders

Validate

architecture

Define architecture

overview

Document

architecture

decisions

Outline application

elements

Verify

architecture

Build

architecture

proof-of-concept

Elaborate

requirements

Outline security

concerns

Outline data

elements Outline infrastructure

elements

Detail application

elements Detail data

elements Detail infrastructure

elements

Detail security

concerns

Detail Interface

Realisations (Batch,

API, Services)

Detail Data

elements

Review Security

Concerns

Physical

Design

Review architecture

with stakeholders

Logical

Design

Detail Architecture

Elements

Outline Architecture

Elements

Cross Platform

Design

Platform Specific

Design

Cross Platform Design focuses on the Physical

representation of Logical High Level Architecture. Public

interfaces, APIs and Batch interfaces are described in

detail. Security Concerns are reviewed for impact to

individual platform applications 17

Page 18: Transforming an Architecture Practice -

Project Manager

(Project

Management)

Infrastructure

Solution Manager (Infrastructure Detailed

Design)

SME / Developer

(Detailed Design,

Coding)

Architect

(High Level

Design)

Business Analyst

(Requirements)

Rational

Team

Concert

Target Tools Architecture

Rational

Requirements

Composer

Rational

Software

Architect

18

Page 19: Transforming an Architecture Practice -

Architecture Models/Views

Reuse Repository (RSA)

Reference Services

Services

Information

EARL

Applications

Reuse Architecture Information Ownership and Control

19

Troux

Systinet

Capabilities Program/ Project Map

Application Portfolio

Application

Portfolio

Updates

ErWin

Applications

Published

Services

Reference

Services

Logical

Data

Groups/ SA

Logical Data

Groups/

Subject Areas

Lloyds Logical

Data Model

Physical Data

Models

Infrastructure Master

Software /

Hardware

Products

Interfaces

Software/ Hardware Products

Logical Data Groups

Application

Interfaces &

Services

Published

Services

Class Model

(LDM Derived)

Rochade

LCSM

GI

L&P

Mortgages

Reference Services

(Various Sources)

LCSM L&P

GI Mortgages

Patterns

Infrastructure

Security

Design

Page 20: Transforming an Architecture Practice -

Overall RSA Project Structure

01 Requirements

• Functional and Non Functional requirements

and use cases are represented in this folder.

These requirements are represented as

components imported from RRC.

02 Architecture

• EAD completes the Architecture Description in

this folder

• Models (Application, Data), Views, Topologies

and Requirements Realisations are created.

03 Cross Platform Design

• The design activity in this folder is the first

level of collaboration between EAD, ADM in

Level 4 with confidence.

04 Platform <Name> Design

• Designs activity completed by the Platform on

the basis of the agreements made in the

collaborative design work in Level 3 – Cross

Platform Design

Reusable Assets

20

Page 21: Transforming an Architecture Practice -

Topology Modelling Language (TML) Applied through RSA Deployment Planning and Automation (DP & A)

With

customized

palette

21

Page 22: Transforming an Architecture Practice -

Q. How and Where do EAD and ADM Collaborate RTC Project Structures Cross Platform design completes in the EAD Design Project Area before Platform Design progress in the Platform Project Areas

22

03 Detailed Design

Production

TH044 S&N Development

TH044 S&N Rel Candidate

TH044 S&N Development TH044 S& N Development

Platform C Project Area

Production

TH044 S&N Development

TH044 S&N Rel Candidate

TH044 S&N Development TH044 S& N Development

Platform B Project Area

Reusable Artefacts Project Area

Justin (Plat A)

Ian (Plat B)

Design Project Area

Production

TH044 S&N Development

TH044 S&N Rel Candidate

TH044 S&N Development TH044 S& N Development

Platform A Project Area

Scott (Plat C)

EAD & ADM

Collaborate on the

Detailed Design in

folder

03 Detailed Design

Each ADM Platform

involved in the design

uses the baseline project

from EAD and elaborates

the changes to their

applications in

04 Plat (A) Detailed

Design

EAD realises the

Requirements and builds

the Architecture Outline in

folders 01 Requirements

and 02 Architecture

1

2

3

Richard Elliott (Plat A)

TH044 S& N Level 4 Design

Page 23: Transforming an Architecture Practice -

Industrialised Design Method 3E Plan

23 23

Dec 2012

Iteration 1 Iteration 2 Iteration 3

3/7

Industrialised Design

Method V1.0

Ready for General Rollout

Industrialised Design

Method Definition and high

level agreement with EAD

HoFs and initial

engagement with ADM, SD

and GITO HoFs

Standard Templates and

Guidelines defined to

support easier usage of

tools and review with EAD,

ADM, SD and GITO HoFs.

2/5

Industrialised Design Method

Ready for Pilots

Adopt (Pilot Programs) Continuous

Improveme

nt

Review Mentoring Bootstrap Orientation

GOLD E2E

Simplification Transaction

Banking

Payments

Simplification

Process, Templates and

Guidelines refined based on

Pilot Program feedback and

review with EAD, ADM, SD

and GITO HoFs

IT BOARD APPROVAL

Transition to

BAU Phase 2 Phase 1

Pro

cess

Feedback

Pro

cess

Feedback

Top 20

Programs

Next 20

Programs

The Engage Phase of the plan

engages key pilot programs to

use the Industrialised Design

Method and Process for

delivering design. The aim is to

test the Method and learn from

the practical challenges faced

by the programs in

implementing the method.

Feedback captured corrects the

Enable Phase The Embed & Improve Phase of the

plan takes the general release (V1.0) of

the Industrialised Design Method to the

top 40 programs currently underway.

All new programs/projects kicking off

from July 2012 must use v1.0 of the

Industrialised Design Process.

2/7

IT Board

Approval for ID

Initiate

EAD Design

Workshops

Architectural

Thinking

(Peter Eeles)

UML Adoption

Architectural

Thinking Course

Material

July 2012 June 2012 May 2012 April 2012 2008 – Mar

2012

Page 24: Transforming an Architecture Practice -

Road shows

24

Page 25: Transforming an Architecture Practice -

Agenda

Background to the Architecture Practice

Industry Input

From Theory to Practice

Summary

25

Page 26: Transforming an Architecture Practice -

Summary

IBM perspective

– Adoption of architecture best practice

– Embracing principles of organizational change

– An opportunity to bring experiences from an engagement of this scale to the broader community

Lloyds Banking Group perspective

– A thought-through case study that exemplifies the method is key

– There is a real opportunity to “codify” patterns of practice

– People-related change is the most difficult aspect of transformation

26

Page 27: Transforming an Architecture Practice -

27

Page 28: Transforming an Architecture Practice -

28

Daily Apple TV giveaway

Complete your session surveys online each day at a conference kiosk or on

your Innovate 2013 Portal!

Each day that you complete all of that day’s session surveys, your name will

be entered to win the daily Apple TV!

On Wednesday be sure to complete your full conference evaluation to receive

your free conference t-shirt!

Page 29: Transforming an Architecture Practice -

29

© Copyright IBM Corporation 2013. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the 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.