Visuals for Communication, Design and Problem Solving

Wardley maps are an innovative way of visually representing strategy that capitalizes on how physical maps help people make on-the-ground decisions against corporate strategies.
This map adjusts the mapping concept in that: a) It deals with a single internal company product offering, b) it was done retrospectively to effectively communicate the multi-layered value of the effort.
After doing several of these, it also led to the insight that "multi-use" of a design is something I love to find opportunity for and build-in when it makes sense. On the above the multi-use is indicated by multiple user types using the product at varying levels in its value chain stack.
This map adjusts the mapping concept in that: a) It deals with a single internal company product offering, b) it was done retrospectively to effectively communicate the multi-layered value of the effort.
After doing several of these, it also led to the insight that "multi-use" of a design is something I love to find opportunity for and build-in when it makes sense. On the above the multi-use is indicated by multiple user types using the product at varying levels in its value chain stack.

This dashboard was devised because it was difficult to explain the status, effort and challenges of long term management of productized automation artifacts in an organization that was used to tracking regular software development using agile methods. In a way these products have cross the initial agile-surge of development - but they need to have their lifecycle impacts to vitality tracked and managed in order for them to maintain their usefulness to the organization.
It also attempts to account for gains and losses in vitality that are unpredictable, entropic (value erosion due to lack of attention) and predictable (can be planned for).
It also attempts to account for gains and losses in vitality that are unpredictable, entropic (value erosion due to lack of attention) and predictable (can be planned for).


This troubleshooting methodology I devised was much easier to understand when represented visually. When used in a presentation, it is unpacked slowly via non-distracting fade in animation so that participants can focus on what is being said.
Not a lot of thought is given to exactly where core automation logic should reside in order to service multiple orchestration tools and to avoid lock-in to a specific tool. This design advocates for pushing this logic down into packaging artifacts, leaving orchestration automation to function as wrappers that deliver files and parameters. This gives flexibility in reusing automation solutions across multiple orchestration methods - including those as simple as a shell script.
Implementation Features (Click to read Deep Dive on this Design):
- By implementing the CI/CD VPC in a fresh AWS Account, you can lock it down to new security levels during build - in the pictured case, to level 2 of the CIS AWS Foundations Benchmark. MFA on a VPN gateway provides an additional layer of protection (avoiding network level VPN).
- The inter-VPC routing tables and cross vpc security groups work together to create a CI/CD environment that is one-way polled by production only on the ports of the CD system.
- In the event of breach, either side can disable the two port, one way connection with a single security group change.
- The one attack vector available from CI/CD requires creating and deploying an Octopus Deploy job that production consumes - this would still require breaking into VPN (w/ MFA) and then breaking into Octopus Deploy.
- If deployments are scheduled events (rather than continuous), the production side routing table or security groups could be automated to only allow connection for periods of known deployment events.
- If the VPCs are only accessed by separate teams, this setup also creates a reasonable separation of concerns.
- Although not depicted, the three CI / CD services would have port 80 security group locked to the VPN gateway.