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:
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 permission@sei.cmu.edu. Architecture Tradeoff Analysis Method® and ATAM® are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. DM-0003494
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
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
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
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
University [Distribution Statement A] This material has been approved for public release and unlimited distribution. 7 via: Analogic Inference Abductive Inference Statistical Inference
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
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.
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
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
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
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
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
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 – nernst@sei.cmu.edu
neilernst
inesmontani
hmsk
hiashisan
ks91
kzykmyzw
nwiizo
nenonaninu
mayumihirano
aiandrox
lamodatech
nacyot
eileencodes
tammyeverts
bkeepers
sferik
marcduiker
notwaldorf
reverentgeek
honnibal
lemiorhan
pedronauck
