Customer Experiences with Modelling

1
Customer Experiences with Modelling
Presented by David W. Thomas Architecture
Team Nationwide Group
2
Introduction...

• About Nationwide
• Attempt 1 Process Author
• Learning Experiences
• Attempt 2 Wren
• Demo
• Learning Experiences
• Summary

3
About Nationwide

• Worlds 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
• UKs first Internet Bank
• Distributed Call Centres
• 'Microsoft Shop' (since 1988) mainframes.

4
Modelling Attempt 1

• Process Author (PA)

5
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

6
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

7
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

8
PA
9
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

10
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 elses
• Insufficient Versioning
• Ended up with PA Script our very own
  programming language ?

11
Learning Points

• Hard to support - we're a Financial Institution,
  not a Software House
• Building a comprehensive model-based solution can
  be expensive
• Sometimes its 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

12
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
• Its quicker to just write the code
• Unable to take developers off the street
• Not seen as career enhancing
• Developers just want to write code

13
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 doesnt obviate the need for thorough
  regression testing

14
Modelling Attempt 2

• Wren

15
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

16
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

17
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

18
Why Wren?

• Sir Christopher Wren was a pretty good
  architect!!!
• Wrens are small and lightweight
• We didnt want a heavyweight model the universe
  framework

19
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?

20
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

21
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

22
Multi-Channel

• Genuinely channel-neutral approach
• Support Nationwides 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

23
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

24
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

25
Wren and the Development Life-cycle
Model
Process Definition
Analyst /Developer
1 way, many time generate
.Net
Wren Code Generator
Generated Process Code
Write Business Logic code
Developer
Process Implementation
Wren Wizards
Starter UI pages for Process
Write Presentation code
UI Implementation
26
Developer Experience

• Tools generate code describing the process flow
• Developers still write the business logic in C
  or VB.Net
• Analysts 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!)

27
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

28
Demo
29
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
• Doesnt solve every kind of problem

30
What we built

• Modelling tool The Wren Diagrammer
• Saves to XML format (are there any other file
  formats?)
• Generators
• C
• VB.Net

31
Other Wren Tools

• UI Wizard
• Web Service Wizard
• Process Wizard
• All making use of Process Metadata
• All built as Wren Processes

32
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

33
Other Wren Tools

• 'Cottage industry' of tools
• Test generators
• Documentation generators
• 'Storyboard' UI generator

34
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?

35
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)

36
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!

37
Summary

• Dont 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

38
Questions