Creating Software Modernization Roadmaps: The Architecture Options Workshop

© 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

WICSA 2016: Modernization
April 6, 2016
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

April 6, 2016
3
2 Microservices and Their Shared Database
original by
Mathias Verraes

View Slide

April 6, 2016
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

April 6, 2016
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

April 6, 2016
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
2. Achieved effects in context?
3. Achieved evaluation?
Improvement problem:
To develop some useful artifact
Improvement problem:
To help a client
Problem investigation
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
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

April 6, 2016
7
via: Analogic Inference
Abductive Inference
Statistical Inference

View Slide

April 6, 2016
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

April 6, 2016
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

April 6, 2016
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

April 6, 2016
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

April 6, 2016
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

April 6, 2016
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

April 6, 2016
14

View Slide

April 6, 2016
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

Architecture Options, Part II
Felix Bachmann, 27 April 2015
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

Creating Software Modernization Roadmaps: The Architecture Options Workshop

Creating Software Modernization Roadmaps: The Architecture Options Workshop

Neil Ernst

More Decks by Neil Ernst

Other Decks in Technology

Featured

Transcript