$30 off During Our Annual Pro Sale. View Details »

Deferring the Last Responsible Moment

Deferring the Last Responsible Moment

A recent concept borrowed from Lean thinking is that of the “last responsible moment” for a decision to be made. The idea is a simple one, in that having more information should result in a better decision. However, these moments often seem to loom up earlier than we would like them to. In this session, Eoin will review the idea of the last responsible moment and how that point is identified. We will then identify some design tactics we can use to defer the last responsible moment, illustrating each with some practical examples.

Eoin Woods

October 15, 2015
Tweet

More Decks by Eoin Woods

Other Decks in Programming

Transcript

  1. Deferring the Last Responsible Moment
    Eoin Woods, Endava
    Join the conversation on Twitter:
    @SoftArchConf #SoftwareArchitect2015
    20151013.2

    View Slide

  2. 2
    2
    Introductions
    Eoin Woods
    • CTO at Endava
    • Career has spanned products and applications
    • Architecture and software engineering
    • Bull, Sybase, InterTrust
    • BGI (Barclays) and UBS
    • Endava
    • Constantly fighting tendency to make decisions too early!

    View Slide

  3. 3
    3
    Content
    Introducing the Last Responsible Moment
    Introducing Real Options
    Balancing Early and Late Decision Making
    Tactics to Allow Decisions to be Delayed
    Summary

    View Slide

  4. Introducing the
    Last Responsible Moment

    View Slide

  5. 5
    5
    Roots in Lean Thinking
    Lean working systematically avoids waste
    • Initially applied to manufacturing
    • Honda and Toyota applied it to
    product development
    • In the 1990s “Lean Construction
    Institute” formed
    • Applied to software from early 2000s
    • Mary and Tom Poppendieck
    • Fits well with many of Agile’s principles

    View Slide

  6. 6
    6
    Key Principles for Lean Working
    Key principles
    1. Eliminate waste
    2. Amplify learning
    3. Decide as late as possible
    4. Deliver as fast as possible
    5. Empower the team
    6. Build quality in
    7. See the whole

    View Slide

  7. 7
    7
    The Last Responsible Moment
    A term coined by Lean Construction authors in ~2000
    • LCI’s white paper series by Howell, Ballard & Zabell
    A single conceptual design will normally be selected before
    the end of [the lean design] phase because the last
    responsible moment for making that decision will have
    usually passed. Design decisions will be deferred until the
    last responsible moment if doing so offers an opportunity to
    increase customer value.

    View Slide

  8. 8
    8
    The Last Responsible Moment
    Kenneth Rubin’s definition for software development
    • Essential Scrum, 2012
    A strategy of not making a premature decision but instead
    delaying commitment and keeping important and
    irreversible decisions open until the cost of not making a
    decision becomes greater than the cost of making a decision
    .

    View Slide

  9. 9
    9
    Difficulties with the Last Responsible Moment
    The problem is … simple to say, difficult to use
    • Actually spotting “the moment” is difficult
    • Very easy to realise it passed some time ago
    • How do you know when the cost of deferring is greater
    than the cost of committing?
    • Usually a period rather than a “moment”
    For example, you want to decide which JS UI framework to use
    … when is the last moment for this decision?

    View Slide

  10. Introducing Real Options

    View Slide

  11. 11
    11
    Real Options
    An extended model for LRM is “Real Options”
    • Based on the idea of a financial option
    • Defined by Chris Matts and Olav Maassen in ~2007
    A real option – “never commit without knowing why”
    • An option but not an obligation for a future decision
    • Has a “value”
    • Has an “expiry” (date or other condition)
    • Has a “cost to buy” and a “cost to exercise”
    Introduction from Matts and Maassen:
    http://www.infoq.com/articles/real-options-enhance-agility

    View Slide

  12. 12
    12
    Defining a Real Option
    The constituent of a Real Option are:
    • Value – what benefit will exercising this option have for
    the organisation? Could be time, money, opportunity, …
    • Expiry – what conditions mean that the option can no
    longer be exercised? A project date or when something
    happens (e.g. remaining budget falls to a point)
    • Cost to Buy – what do you need to do in order to have the
    option? PoCs? Research? Analysis? Design change?
    • Cost to Exercise – once you commit to this option, what is
    the cost to achieve it? Development work? Changes in
    Operations? New testing? Additional analysis? Licenses?

    View Slide

  13. 13
    13
    An Example of a Real Option
    Suppose we need an option on a database …
    The Option
    than a
    To use a document oriented database (rather
    relational database)
    The Value Reduced development cost (~15%) if database
    model matches problem domain
    The Expiry Time of first production release less time taken
    to replace DB access layer & deploy chosen
    database
    Purchase Cost A DB access layer (mocked) plus research to
    prove that both dbs could be deployed
    Exercise Cost db
    Write DB access layer, design operational
    environment, deploy db

    View Slide

  14. 14
    14
    Example of a Real Option (ii)
    Time
    Cost/
    Value
    R0
    DB Deploy Time
    Data Access
    Layer Build Time
    Value
    Cost
    Expiry
    Benefit
    T0

    View Slide

  15. 15
    15
    Using Real Options
    To create and manage a Real Option
    1. Identify your options for a decision
    2. Identify the conditions defining the last decision point
    • e.g. decision point = deadline - implementation time
    • e.g. decision point = resource0 < Value1
    3. Keep learning and looking for options until decision point
    4. Move back decision point where possible
    5. When decision point arrives, act as quickly as possible
    • Real Options ≠ procrastination!
    (More on moving back
    the decision point in the
    next section.)

    View Slide

  16. 16
    16
    How Real Options Help with Decision Making
    The value of Real Options
    • Real Options overcome natural tendency to decide early
    • Makes a “no decision” position clear
    • Requires precision about when a decision is needed
    • Overcomes aversion to uncertainty
    • Real Options encourage thinking about alternatives
    • Real Options force clarity in the options available
    • Real Options encourage gathering information
    Combination of factors create likelihood of better decisions

    View Slide

  17. Balancing Early and
    Late Decision Making

    View Slide

  18. 18
    18
    Balancing Late vs Early Decisions
    Not every decision can (or should) be delayed
    • Like any idea deferring decisions can be over used
    • Little benefit in deferring decisions with low impact
    • Decisions that can be changed at low cost
    • Decisions that have little tangible impact on the outcome
    • Decisions that aren’t going to affect customer value
    • Making no decisions early will just stall progress
    • Many people feel reassured when a decision is made
    • “any decision is better than no decision”
    • Real Options helps decision making to be more transparent
    • Lack of a decision may block others from progressing

    View Slide

  19. 19
    Early Decisions
    • Harder to validate due to
    less information
    • Have a tendency to
    optimise unwisely
    • Have a tendency to be
    wasteful (YAGNI)
    • Often look decisive
    • Can be (falsely?)
    reassuring
    Late Decisions
    • Maximise information
    available for decision
    • Avoid premature
    optimisation problems
    • Can block others from
    progressing
    • Can overwhelm decision
    making if too many
    • Can cause worry about
    lack of direction
    Late vs Early Decisions
    Remember need for communication, clarity and reasoning when making late
    decisions to avoid looking indecisive or unsettling people – psychological factors

    View Slide

  20. Tactics to Defer Decisions

    View Slide

  21. 21
    21
    Tactics to Defer Decisions
    (Re)Organise for Change
    • Run projects that can absorb
    change as late as possible
    Architect for Change
    • Design systems that can be
    changed regularly and
    reliably
    Design for Change
    • Implement software that
    limits the impact of change

    View Slide

  22. 22
    22
    (Re)Organise for Change
    Organise project to absorb change and allow late decisions
    • Domain Analysis
    • Know the domain to identify the options for late decisions
    • Early Sharing of Information
    • Don’t wait for perfection before validating
    • Minimum Viable Product
    • Build the smallest thing possible to gain more knowledge
    • Set Based Design
    • Back enough options to allow late selection of the solution

    View Slide

  23. 23
    Benefit
    • Good domain knowledge
    identifies alternatives
    • Domain analysis leads to
    new options
    • Collaboration across
    business and developers
    Cost
    • Significant time and
    effort to develop
    • Requires specialisation
    Domain Analysis
    www.uscis.gov

    View Slide

  24. 24
    Benefit
    • Allows collaboration to
    identify options
    • Early feedback to spot
    problems early
    • Clarity on direction
    Cost
    • Time for communication
    Share Information Early

    View Slide

  25. 25
    25
    Minimum Viable Product
    Don’t build anything that isn’t essential
    • A MVP is the product level version of “do the simplest
    thing that could possibly work”
    • The simplest set of features that could meet the
    requirement
    • Allows for rapid delivery, cost effective feedback loop and
    affordable mistakes to be made, so facilitates learning
    • The key is to decide what the minimum really is

    View Slide

  26. 26
    Benefit
    • Smallest number of
    decisions made each
    time
    • Options stay open until
    feature needed
    Cost
    • Effort to fit approach
    into many organisations
    • Difficult to “sell” without
    a defined end-state
    Minimum Viable Product
    cloudmanic.com

    View Slide

  27. 27
    27
    Set Based Design
    Why choose before the end?
    • Set based design develops a set of solutions for each
    problem where the best solution isn’t clear at the start
    • e.g. a “safe” solution, a “likely” solution & an “innovative” solution
    • As time progresses stop work on solutions that don’t work
    well or where their LRM has passed
    • Overall project assembled from “winning” solutions

    View Slide

  28. 28
    Benefit
    • Hedges options right
    through project
    • Latest decision possible
    Cost
    • Duplicated effort
    • Integration difficult if
    multiple choices
    • Can be confusing
    without careful
    management
    Set Based Design (ii)

    View Slide

  29. 29
    29
    Architect for Change
    Design a system that can be changed regularly, reliably
    • Separate Concerns
    • Limit items to be changed
    • Avoid Duplication (DRY)
    • Limit impact of change
    • Dependency Management
    • Know the impact of change
    • Variation Points
    • Manage a set of options through the lifecycle
    • Testing and Continuous Delivery
    • Enable reliable and rapid change

    View Slide

  30. 30
    Benefit
    • Avoid duplication
    • Change isolation
    • Simpler components
    • Adds options for reuse &
    extension
    Cost
    • Design effort
    • Refactoring
    Separate Concerns (Cohesion)

    View Slide

  31. 31
    Benefit
    • Avoids wasted effort
    • Easier change
    • Efficiency
    Cost
    • Effort
    • Refactoring impact
    Avoid Duplication (“Don’t Repeat Yourself”)
    deviq.com/don-t-repeat-yourself

    View Slide

  32. 32
    Benefit
    • Find change blackspots
    • Avoid high coupling
    • Structural insight
    Cost
    • Time & prioritisation
    • Refactoring
    • Tools
    Dependency Management (Coupling)

    View Slide

  33. 33
    33
    Variation Points
    Variation Points build options into design thinking
    • An idea from product line engineering
    • Design software as a set of assets designed for use in
    different situations
    • Explicit variation points in the (functional) design
    • Makes existence, constraints and cost of options clear
    • Promotes variability to be a feature of the system
    • Document & test the variation points for product owner

    View Slide

  34. 34
    34
    Variation Points (ii)
    Example in a payment processing system
    • Identify explicit options for variation of:
    • transaction authorisation mechanism
    • transaction message transport
    • security mechanisms
    • Product owner can now decide how and when to invest in
    these options
    • Variation points are enablers of a set of Real Options
    • Key is explicit design and management of the variation
    point set

    View Slide

  35. 35
    Benefit
    • First class options in the
    design
    • Excellent visibility of
    options for PO
    Cost
    • Up front design effort
    • Implementation effort
    • Requires a little
    clairvoyance (i.e. domain
    knowledge)
    Variation Points (iii)

    View Slide

  36. 36
    Benefit
    • Confident change
    • Reliable change
    • Rapid delivery of
    changes to production
    Cost
    • Implementation cost
    • Initial effort
    • Customer commitment
    Test Automation and Continuous Delivery
    derberg.github.io

    View Slide

  37. 37
    37
    Design for Change
    Design a system that can be changed regularly, reliably
    • Interfaces and Abstractions
    • Encourage substitutability
    • Parameterisation
    • Create logic that expects to delegate responsibility for details
    • Encapsulate Variation
    • Limit the impact of changing a decision

    View Slide

  38. 38
    Benefit
    • Delay implementation
    decision point
    • Substitutability (LSP)
    allows future options
    Cost
    • Complexity
    • Design effort
    • Mocking effort
    • LCD risks
    Oracle Adapter
    MSSQL Adapter
    «interface»
    Database Adapter
    Interfaces and Abstractions

    View Slide

  39. 39
    Benefit
    • Delays implementation
    decision
    • Allows build and test of
    parameterised modules
    • Allows decision to be
    changed repeatedly
    Cost
    • Complexity
    • Design effort
    Parameterisation
    setScoreCalculator(ScoreCalculator sc)
    Credit Score Reporting
    Customer List
    Rule Based
    Calculator
    Model Based
    Calculator
    OneR Calculator
    Bayesian
    Calculator

    View Slide

  40. 40
    Benefit
    • Localised change impact
    • Predictable and reliable
    change
    • Avoiding duplication
    Cost
    • Vigilance
    • Refactoring as
    knowledge improves
    • Structural complexity (?)
    Modularise and Encapsulate Variation
    Payroll Manager
    «interface»
    Hourly Rate
    Calculator
    Hourly Paid Hourly
    Rate Calculator
    Salary Based Hourly
    Rate Calculator

    View Slide

  41. Example

    View Slide

  42. 42
    42
    Delaying the Last Responsible Moment
    An enterprise system for compliance reporting
    • Receives all the business transactions for the company
    • Analyses, sorts, classifies the business activity
    • Contains a configurable rule set for report generation
    • Sends real time report feeds to some regulators
    • Generates document reports for other regulators
    • Provides controls such as “4 eyes” checks on dispatch
    • Needed “immediately” due to regulatory inspection

    View Slide

  43. 43
    43
    Regulatory Reporting System
    Project
    organisation to
    allow late change?
    Architecture for
    delaying change?
    Design to defer the
    last responsible
    moment?
    Regulatory Reporting System
    Reporting Analysts
    Supervisors
    Business
    Transactions
    Regulator
    Activity Reports

    View Slide

  44. 44
    44
    Regulatory Reporting System
    Project organisation ideas:
    • What is a minimum viable reporting system?
    • What will the regulator put up with? (Domain knowledge)
    • Which regulator first? (Domain knowledge)
    • Develop a simple file generator with manual processes
    alongside a fully automated system!

    View Slide

  45. 45
    45
    Regulatory Reporting System
    Architecture ideas:
    • What variation points will we need?
    • Report type (data included, data items, ….)
    • Regulator specific calculations for report items (e.g. NPV)
    • Transport for dispatch of reports
    • Continuous delivery to improve system every couple of
    days – allows better negotiation with the regulators
    • Automated testing of reports to avoid manual test cycle delays
    • Stress cohesion and low coupling to reuse and replace
    pieces of the process as the real requirements emerge

    View Slide

  46. 46
    46
    Regulatory Reporting System
    Design ideas:
    • Encapsulate all of the variation points we identified to
    allow rapid safe extension
    • Parameterise the report generation process to allow
    regulator specific calculations to be “injected”

    View Slide

  47. Summary

    View Slide

  48. 48
    48
    Summary
    Decisions need information so making them late helps
    • The last responsible moment is a difficult concept
    • Hard to measure and use
    • Real Options add some important concepts to the idea
    • Value, cost, expiry
    • It is often possible to move the “expiry moment”
    • Organise for Change
    • Architect for Change
    • Design for Change

    View Slide

  49. 49
    49
    Summary (ii)
    Moving the moment an option expires
    • Organise for Change
    • Domain Analysis, Share information early,
    MVP, Set-based design
    • Architect for Change
    • Separate Concerns, Avoid duplication, Manage dependencies,
    Variation points, Testing and continuous delivery
    • Design for Change
    • Interfaces and abstractions, Parameterisation,
    Encapsulate variation
    The tactics aren’t novel but using them to delay commitment may be

    View Slide

  50. 50
    50
    Resources
    http://www.infoq.com/articles/real-options-enhance-agility
    http://www.agilecoach.net

    View Slide

  51. 51
    Thank you
    QUALITY. PRODUCTIVITY. INNOVATION.
    Eoin Woods
    Endava
    [email protected]
    +44 207 367 1000
    en_ewoods

    View Slide