Customer Experiences with Modelling - PowerPoint PPT Presentation

1 / 38
About This Presentation
Title:

Customer Experiences with Modelling

Description:

Why Wren'? Sir Christopher Wren was a pretty good architect!!! Wrens are small and lightweight ... Modelling tool 'The Wren Diagrammer' Saves to XML format ... – PowerPoint PPT presentation

Number of Views:48
Avg rating:3.0/5.0
Slides: 39
Provided by: david2726
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com