waltz
waltz copied to clipboard
Cloud Roadmap viz
Continuation of investigations on showing calculated roadmap plans.......
- [ ] (Client only) brush selection improvements
- [x] table needs to be grid
- [ ] should correspond to colors
- [ ] click to highlight point in chart.
- [ ] (Client only) search/highlight app
- [ ] (Client only) hover-over support
- [x] (Client only) swim lane markers
- [ ] (Client only) perf tune the js
- [x] (Client only) dynamic scales
- [ ] sizing strategy
- [ ] server support
- [ ] client suport
- [ ] coloring stratgey
- [ ] server support
- [ ] client suport
- [ ] (Server only) Define roadmap definitions
- [ ] Exclusion groups
- [ ] Filters
- [ ] allow fixed dates for points
- [ ] server support
- [ ] client support
- [ ] Date adjusters
- [ ] client support (param tweaking)
- [ ] server support (evaluation)
- [x] Adjustment approach
-
Adjusters
- [ ] Complexity: flows / functions
- [ ] Involvment: DPO/DCO
- [ ] App group: Data council,
- [x] Assessment: CPoE, SOX, MAS
- [ ] Measurable ratings: Tech product
- [ ] exact
- [ ] rollup
- [ ] Cost considerations
Feedback RG: 2020-11-30
- Click on swimlane to 'brush all' in that swimlane
- Stats on brush selection:
- costs
- total
- plus rule based multiplier (i.e. retire cost is * 0.3, replatform cost = 1.2 )
- start to build out cost/benefit analysis
- business benefit of replatform etc.
- # servers (w/ breakdowns) (to show how many servers are released)
- flow breakdown (# flows, intra/extra - possible pop out to boingy)
- BUG: removing last decorator group causes problem!
- costs
Fixed shifts are calculated first to give a day offest from start
. Dynamic shifts are then applied to the fixed offset to give the final provisional date.
start: "2021-01-01",
rules: [
{
// fixed start rule examples
ruleEntityRef: {'ASSESSMENT_DEFINITION', 3 },
ruleName: "RType",
ruleType: 'ASSESSMENT_RATING'
outcomes: [
{ matcher: "REPLATFORM", fixedShift: 365 * 2},
{ matcher: "REHOST", fixedShift: 160},
]
{
// multiple rules could be declared for the same rule entity. ie. fixed and then dynamic
ruleEntityRef: {'ASSESSMENT_DEFINITION', 3 },
ruleName: "RType Dyn shift",
outcomes: [
{ matcher: "REPLATFORM", dynamicShift: 1.1},
{ matcher: "REHOST", dynamicShift: 0.8},
]
}, {
// some rules could use a f
ruleEntityRef: {'ASSESSMENT_DEFINITION', 12 },
ruleName: "MAS",
outcomes: [
{ matcher: "YES", fixedShift: 30 },
{ matcher: "CRITICAL", fixedShift: 90 },
]
}, {
ruleEntityRef: {'ASSESSMENT_DEFINITION', 33 },
ruleName: "CPoE",
outcomes: [
{ matcher: "YES", dynamicShift: 1.1 },
{ matcher: "NO", dynamicShift: 0.9 }
]
},
// do we need these or should we just limit to assessment and measurable ratings?
{
ruleEntityRef: {'INVOLVEMENT_KIND', 12},
ruleName: "Data Owner",
outcomes: [
{ matcher: true, dynamicShift: 0},
{ matcher: false, dynamicShift: 1.5 }
]
}, {
ruleEntityRef: {'APP_GROUP', 12345},
ruleName: "Data Group",
outcomes: [
{ matcher: true, fixedShift: 0},
{ matcher: false, fixedShift: 18, dynamicShift: 1.1 }
]
}, {
ruleEntityRef: {'MEASURABLE', 1},
ruleName: "Data Owner",
ruleOptions: {
ratingRollupRule: 'NONE'
outcomes: [
{ matcher: 'G, fixedShift: 5},
{ matcher: 'A, fixedShift: 10},
{ matcher: 'R, fixedShift: 15}
]
}, {
ruleEntityRef: {'MEASURABLE', 1},
ruleName: "Data Owner",
ruleType: "MEASURABLE_EXISTENCE_CHECK" -- we know looking down hierarchy
outcomes: [
{ matcher: true, fixedShift: 5},
{ matcher: false, fixedShift: 10}
]
}, {
ruleEntityRef: {'MEASURABLE', 12346},
ruleName: "Data Group",
ruleOptions: {
ratingRollupRule: 'NONE'
outcomes: [
{ matcher: 'Y', shiftType: 'DYNAMIC', shift: 1 },
{ matcher: 'Y', shiftType: 'FIXED', shift: 50 },
{ matcher: 'N', fixedShift: 18, dynamicShift: 1.1 }
]
}
]