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

Creating Software Modernization Roadmaps: The Architecture Options Workshop

Creating Software Modernization Roadmaps: The Architecture Options Workshop

Talk at Intl Conference on Software Architecture. Related paper: https://fink08.files.wordpress.com/2005/03/aows-wicsa.pdf

Neil Ernst

April 06, 2016
Tweet

More Decks by Neil Ernst

Other Decks in Technology

Transcript

  1. © 2015 Carnegie Mellon University
    Software Engineering Institute
    Carnegie Mellon University
    Pittsburgh, PA 15213
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    Creating Software Modernization
    Roadmaps: The Architecture Options
    Workshop
    Neil Ernst with Mary Popeck, Felix
    Bachmann, Pat Donohoe
    bit.ly/aows-wicsa
    The paper:

    View Slide

  2. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    2
    Copyright 2016 Carnegie Mellon University
    This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with
    Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center.
    Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily
    reflect the views of the United States Department of Defense.
    NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED
    ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR
    IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR
    MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY
    DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT
    INFRINGEMENT.
    [Distribution Statement A] This material has been approved for public release and unlimited distribution. Please see Copyright notice for
    non-US Government use and distribution.
    This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting
    formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering
    Institute at [email protected].
    Architecture Tradeoff Analysis Method® and ATAM® are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
    DM-0003494

    View Slide

  3. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    3
    2 Microservices and Their Shared Database
    original by
    Mathias Verraes

    View Slide

  4. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    4
    • Modernization Planning
    • Create a roadmap for future task orders, RFPs, etc.
    • Move from identifying problems to proposing solutions

    • Typical clients large (governmental) organizations
    • Three organizations as cases:
    • Bursatec, Mexican stock exchange
    • Org B, medical multinational middleware
    • Org C, governmental org. with operational legacy systems

    • Input from other (SEI) approaches:
    • Risk themes from Architecture Tradeoff Analysis (ATAM)
    • Issue themes from Quality Attribute/Mission Thread Workshops
    Problem Background

    View Slide

  5. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    5
    Threads Issues Issue Themes
    Business
    Goals
    Scenarios
    (Utility Tree)
    Risks Risk Themes
    High-level
    current state
    architecture
    Scenarios Options Decisions
    Near-term
    Roadmap
    exploring current arch
    with respect to risk themes
    ranked with respect to
    options
    derived from stakeholders
    and documents
    derived from stakeholders
    and business process models
    Mission Threads
    ATAMs
    Options Workshop

    View Slide

  6. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    6
    TAR as a Validation Method in Information Systems Design Science 231
    Problem investigation
    1. Stakeholders, goals, criteria?
    2. Phenomena, diagnosis?
    3. Evaluation?
    Artifact design
    Design validation
    2. Expected effects in context?
    3. Expected evaluation?
    4. Trade-offs?
    5. Sensitivity?
    Implementation
    - Transfer to the economy
    Implementation evaluation
    1. Stakeholders, goals, criteria?
    2. Achieved effects in context?
    3. Achieved evaluation?
    Improvement problem:
    To develop some useful artifact
    Improvement problem:
    To help a client
    Problem investigation
    1. Stakeholders, goals, criteria?
    2. Phenomena, diagnosis?
    3. Evaluation?
    Treatment design
    - Specify treatment using artifact
    - Agree on implementation plan
    Design validation
    2. Expected effects in client company?
    3. Expected evaluation?
    4. Trade-offs?
    5. Sensitivity?
    Implementation
    - in the client company
    Implementation evaluation
    1. Stakeholders, goals, criteria?
    2. Achieved effects in client company?
    3. Achieved evaluation?
    Research Problem investigation
    - Unit of study (population elements)?
    - Conceptual model?
    - Research questions?
    - Current knowledge?
    Research design
    - Acquire client
    - Agree on improvement goals
    - Agree on treatment
    - Agree on measurment
    - Reasoning?
    Research design validation
    - Effective for questiion-answering?
    - Good enough?
    - Trade-offs?
    - Sensitivity?
    Research execution
    - Perform the project
    Analysis of results
    - Observations?
    - Explanations?
    - Answers to research questions?
    - Generalizations?
    - Limitations?
    - Contribution to knowledge?
    - Consequences for improvement
    Knowledge problem:
    To answer some reseach questions
    Fig. 6. The structure of technical action research
    Wieringa, DESRIST 2012
    Approach: Technical Action Research

    View Slide

  7. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    7
    via: Analogic Inference
    Abductive Inference
    Statistical Inference

    View Slide

  8. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    8
    • Elaborate set of technical architecture alternatives
    • Propose initial target architecture from those alternatives
    • Use stakeholder prioritization and tradeoff analysis
    • a ‘next’ state (not end state)
    • Document rationale for decisions using simple cost/benefit
    assessment
    • Enforce decision making
    • Not full blown architecture re-design
    Architecture Options Workshops

    View Slide

  9. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    9
    Architecture Runway
    Developers build
    according to the path laid
    out by the architects.
    Architects set the
    parameters for the
    developers to follow
    Time delay between
    Stakeholder request
    and delivery is minimal
    The goal of the workshop
    is to find out what those
    parameters are.

    View Slide

  10. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    10
    Define Possible
    Options Per Scenario
    0–Preparation Phase II–Synthesis Phase
    Elicit Business Goals
    Define Scenarios
    Achieving Goal
    Prepare
    Roadmap
    Combine and
    Select Options
    Prioritize Options



    Assign Cost/
    Benefit Per Option




    I–Breadth Phase

    View Slide

  11. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    11
    • Need business goals and scenarios (tests)
    for those goals.
    One approach:
    • Scope with representative threads/high level
    scenarios
    • Org B: done offsite
    • Org C: three Mission Thread Workshops
    • Identify risks with architecture analysis
    • lightweight peer eval
    • ATAMs on critical systems from high-level
    scenarios
    • Identify critical problem components for
    AOWS (current-state)
    • Iterate & expand width/depth as needed
    • Need degree of technical realizability
    Preconditions Phase
    Systems
    System
    Component

    View Slide

  12. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    12
    • Input: goals and scenarios testing those goals
    • Walk each scenario (in our cases, 3-5) and elicit options from
    stakeholders
    • Stakeholders/participants: high-level technical knowledge,
    architecture and design experts, political power-wielders, business
    side
    • Each participant can suggest options. Options are solutions that
    could be used to achieve the scenario (in our cases, 6-7)
    • Collect pros and cons per option (free form text)
    • Collect consensus on costs and benefits per option
    • Generate spreadsheet with ⟨Option, Scenario, Pro, Con, Cost,
    Benefit⟩
    • e.g. Org C had 5 scenarios and 20 options (~8 hrs, 10-12
    people)
    Breadth Phase

    View Slide

  13. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    13
    • Prioritize the options
    • In our cases, this was done by the consultant team
    • Incorporate dependencies and org. capability
    • Options not always directly comparable (e.g. change to
    different DB vs. change table names)
    • Trickiest are the M/M options
    • Relate options to business goals (~15 per day)
    • Use a decision tree to enforce decision making
    • Exploratory/technical
    • Component-wise
    • Detail level
    • Create the roadmap - decisions, person responsible, date due
    Synthesis Phase

    View Slide

  14. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    14

    View Slide

  15. WICSA 2016: Modernization
    April 6, 2016
    © 2016 Carnegie Mellon University
    [Distribution Statement A] This material has been approved for public release and unlimited distribution.
    15
    • Measuring certainty
    • The AOWS (for now) very coarse-grained (HML on cost/
    benefit)
    • Support iteration and change
    • Include loopback tasks, knowledge gathering, and backout
    cost
    • Sensitivity points
    • How robust is a given modernization plan? How many plans
    exist?
    • How to evaluate ‘success’
    • Multiple years and unknown (unknowable?) roadmaps
    Observations and improvements

    View Slide

  16. Architecture Options, Part II
    Felix Bachmann, 27 April 2015
    © 2015 Carnegie Mellon University
    16
    Final Slide
    artifact x context => effects by mechanisms
    • Our artifact is the AOWS. We introduced a new way to identify
    architectural options
    • fills a gap between early design analysis and late-stage design
    assistance.
    • Our contexts were the three organizations to which we applied AOWS.
    • The effect was a roadmap that had the approval and understanding of key
    stake-holders.
    • Finally, our mechanisms include the three-phased AOWS approach and
    the necessary inputs.
    • The AOWS is an artifact we continue to refine so stay tuned!

    @neilernst – [email protected]

    View Slide