Customer Experiences with Modelling Presented by: David W. Thomas

Architecture Team Nationwide Group

INSURANCE INVESTMENTS LOANS MORTGAGES PENSIONS SAVINGSBANKING CREDIT CARDS

Introduction...

• About Nationwide

• Attempt #1: Process Author

• Learning Experiences

• Attempt #2: Wren

• Demo

• Learning Experiences

• Summary

About Nationwide

• World’s Largest Building Society

– Mutual not PLC

• 4th Largest UK Mortgage Lender

• Banc Assurer – current accounts, lending, insurance etc.

– Group of companies

• Over £100 Billion Assets

• 10,000,000 Members

• 15,000 employees

• ~700 branches

• UK’s first Internet Bank

• Distributed Call Centres

• 'Microsoft Shop' (since 1988) + mainframes.

Modelling: Attempt #1

Process Author (PA)

Process Author Goals

• Place Analysts at the heart of change/impact analysis

• Avoid ‘over the wall’ experience from analyst to developer

• Allow developers to concentrate on business process

• Support 3 (n) Tier development

– Model Process– Model Data (inside process)

• Facilitate re-use

– Data Structures– Processes– Business Rules

• Simplify Development Experience

• Remove ‘plumbing’ effort

What We Built

• Combined Runtime and Authoring Environment

• Authoring (modelling) Tool

– Graphical and Dialogue based Process Modeller

– Data Definition

– Rules scripting language

• Started development in 1994

• Written as a C++ DLL

• Originally targeted PowerBuilder UIs

• Fairly quickly targeted Visual Basic Thick Clients

– Relatively easy

• Later Still, Web Clients

Other Key Features

• Working Sets

– Metadata based in-memory database, modelled in tool

• COM

– ‘Easy’ construction of COM/DCOM based processes

• ‘PID’ files - 'easy' mainframe access

– Abstraction of ‘complex’ interfaces into standardised Working Set-based interface

PA

Outcomes

•Successful Projects– Customer Search/Enquiry System– Personal Loan Point of Sale Application– Mortgage Point of Sale System– Used in many others

•Huge volumes of Metadata about business processes

•Modelling of Process and Data generally regarded as successful

Learning Points

• Rule level re-use didn't work

– Artefacts have to be big enough to find

– ‘Safer’ to rewrite small rules from scratch – impact analysis

– Faster to rewrite complex rule than understand someone else’s

– Insufficient Versioning

• Ended up with ‘PA Script’ – our very own programming language

Learning Points

• Hard to support - we're a Financial Institution, not a Software House

• Building a comprehensive model-based solution can be expensive

– Sometimes it’s quicker just to cut code

– Interesting debate about the cost in terms of the entire product lifecycle

• Trade-off between the cost of building a tool and the savings that brings in building a system

– Many PA features only got used on one project

• ‘Plumbing’/features ended up being done by Core C++ tools dev team - just proxied the work elsewhere

Learning Points

• Written in C++ rather than managed code

– Expensive to maintain, memory leaks etc.

• Hard to fix problems

– Developers no longer understand the consequences of their actions because model ‘protects’ them

– Issues fixing bugs in the C++ PA runtime - small core team

• Lack of acceptance in many areas

– “It’s quicker to just write the code”

• Unable to take developers ‘off the street’

• Not seen as ‘career enhancing’

– Developers just want to write code …

Learning Points

• Large Runtime element as well as Design time

– Interpreted – server performance needs to be managed carefully

– Versioning Problematic

• Migrating from 16 bit to 32 bit proved fairly painless

– Only had to migrate the runtime – the application models were largely unchanged

• Having a fantastic model that you can change easily doesn’t obviate the need for thorough regression testing

Modelling: Attempt #2

Wren

Why Try Again?

• Initially we just wanted a 'standard' way of using .Net

• .Net Framework is fantastically flexible - offers lots of choice

• Wanted to enforce some level of standardisation

• Avoid effort expended reinventing the architectural wheel for each new project

– Effectively a tools-supported design pattern

Why Try Again?

• Recognised that Analyst-Developer gap is still an issue

• … but don't believe that analysts can/should write code (if they could, they'd be developers …)

• Want a way of maintaining fidelity between analysis and implementation

• Reduce the communication gap

• Want to ensure that the documentation is up to date

Why Try Again?

• Reduce Development Time

• Reduce re-work time when requirements change

• Eliminate as much plumbing code as possible by generating hooks into underlying .Net Framework

Why ‘Wren’?

• Sir Christopher Wren was a pretty good architect!!!

• Wrens are small and lightweight

– We didn’t want a heavyweight ‘model the universe’ framework

Why not OOA?

• Developer background

– Lots of ex-Cobol etc.

• Sometimes hard to get the model right

– e.g. Customer Age - is 'over 18' a customer rule or a product rule?

Why not OOA?

• Business process can be hard to describe

• Can be even harder to implement as implementation 'flow' can get scattered across many classes

• No real appetite for purchasing expensive UML tools - hard to justify the ROI

• Parts of UML very useful -

• Use Cases, State Diagrams, Activity Diagrams

Wren Goals

• ‘The Model is the Master’

– Generate some code from model

– Allow many-time generation with no loss of developer code

– No round-tripping

• Maintain fidelity between model and implementation

• Allow systems analysts or 'analyst/programmers' to produce models

– Draw pictures

– Write English descriptions of business logic

• Low cost

– Had to be cheap to develop and support

Multi-Channel

• Genuinely ‘channel-neutral’ approach

– Support Nationwide’s multi-channel business strategy

• Local or remote access (via web service)

• Thin or Thick client

• No client

• Business Process entirely abstracted from UI

• Not only do we support the above UI styles, but the business process assembly is unchanged in all circumstances

Multi-Channel

• Means that the model must say nothing about channel-specific issues such as state maintenance, page structure etc.

• However, can use a model as input into channel-specific tools

• ‘Web UI Wizard’

– Uses metadata to build a set of ASP.Net pages

• ‘Web Service Wizard’

– Uses metadata to produce a web service interface to a process

Multi-channel (aside)

• Microsoft PAG's 'UI Process Application Block' does some very similar things

• Overall process flow is described in XML within the UI itself

• Regards business process as a UI-specific artefact

• Feels like there is an extent to which Business Process should be immutable, or at least channel-specific

• May allow per-channel variation within the process

.Net

Model

Wren and the Development Life-cycle

Process Definition

ProcessImplementation

UIImplementation

Wren Modelling

Tool

Analyst/Developer

Developer

GeneratedProcess Code

Wren CodeGenerator

1 way, many time generate1 way, many time generate

Write Business Logic codeWrite Business Logic code

Wren Wizards

Starter UI pagesfor Process

Write Presentation codeWrite Presentation code

Developer Experience

• Tools generate code describing the process flow

• Developers still write the business logic in C# or VB.Net

– Analyst’s descriptions are generated as code comments

• Process data is modelled in XSD

– Typically using standard VS tools

• 'No' runtime code - don't want Architecture tools team to be a bottleneck (or a scapegoat!)

– All runtime code is generated rather than shipped as assemblies

• Allow developer freedom

– If they really need to, they can change the generated code

• C# and VB.Net supported

– We can generate either (can even change your mind!)

Developer Experience

• 'Off the street' .Net developers

• Developers can make use of any parts of the .Net framework they need to

• Use the .Net plumbing wherever possible

– Model allows us to generate all this stuff

– Harder not to use it …

• Enterprise Instrumentation Framework

• ASP state management

• DataSets

Demo

Wren

• Modelling gives us a standardised approach

– Easier to support

– Easier for developers to move between business development teams

• Common programming model

• Sub-processes

– Built to common model

– Process re-use starts to become more attainable because everything works the same way

• Web Services

– Further encourages reuse

• Doesn’t solve every kind of problem

What we built

• Modelling tool – “The Wren Diagrammer”

• Saves to XML format (are there any other file formats?)

• Generators

– C#

– VB.Net

Other Wren Tools

• UI Wizard

• Web Service Wizard

• Process Wizard

• All making use of Process Metadata

• All built as Wren Processes

What else we delivered

• Lots of documentation

• 'How to' guides

• Help files

• Architecture overviews etc.

• SharePoint site

– Single point of access for information

– Code install point

– Discussion forum

• Training

Other Wren Tools

• 'Cottage industry' of tools

• Test generators

• Documentation generators

• 'Storyboard' UI generator

What We've achieved

• General acceptance

• Most new .Net development is Wren-based

• Process Models used as aid to business communication

– Is this what you thought you were getting?

Findings

• Analysts often can't draw processes that can be implemented

– Different levels of abstraction (both ways)

• Models turn out to be useful for different things

– e.g. test generation

• You can't have too much documentation

– (Dev's don't read documentation) …

Findings

• Most people claim to be more productive

• Re-work cycle following requirement change is shorter

• Business people find the models useful as a back-check

• ‘Lightweight’ modelling approach can deliver real value

– Tools Development team is currently circa 2.5 people

• Developers are ‘guided’ without being unnecessarily constrained

– Saves a lot of ‘debate’ at the start of projects!

Summary

• Don’t bite off more than you can chew!

• Model where it adds value

• Allow developers the freedom to drop down into code wherever they need to

• Provide plenty of supporting material

INSURANCE INVESTMENTS LOANS MORTGAGES PENSIONS SAVINGSBANKING CREDIT CARDS

Questions