Fudge Sunday - Cloud in Public: Impact Mapping

by Jay Cuthrell
Share and discuss on LinkedIn or HN

This week we continue to take a look at public things for a public cloud.


This issue is part 5 of a 5 part series

  1. Fudge Sunday - Cloud in Public: Status Dashboards
  2. Fudge Sunday - Cloud in Public: Engineering SLO
  3. Fudge Sunday - Cloud in Public: DevCommsOps
  4. Fudge Sunday - Cloud in Public: Mean Time To RCA
  5. Fudge Sunday - Cloud in Public: Impact Mapping

As of this issue, we now have historical perspectives and definitions for status dashboardsEngineering SLODevCommsOps, and Mean Time to RCA. Next, let’s talk about the increasing importance of dependency mapping across hyperscale public cloud service providers and consider business value engineering and customer journeys.

Impact Mapping in practice

Over the past four weeks, we covered WhoWhat, Where, and When for cloud companies that “write it down” to pursue goals for The Perfect Team. This issue will get to the final remaining question: Why.

To get an understanding of Impact Mapping, you could start with a book of the same title. For now, assume Impact Mapping answers the question, Why.

The answer? “Because that’s what the business needs.”

Making a Big Impact with Software Products and Projects

Just around a decade ago, Gojko Adzic provided a practical guide to impact mapping. In a nutshell, impact mapping helps ensure the alignment of business and delivery.


Impact Mapping can be challenging because the public cloud is increasingly less about public access than private considerations for the public of specific places. Effectively, this means that Impact Mapping should consider the technology stack and the operating geography for the laws or regulatory landscape that may also evolve.

[email protected]


+15 years: Hyperscale public cloud service providers invest to enable globally diverse infrastructure to support well-architected frameworks.💰☁️

+15 months: GAIA-X Policy Rules and Architecture of Standards support geopolitical data sovereignty and balkanization frameworks.⚖️🤔 https://t.co/hv5wZJfOyA

2:36 PM - 31 Oct 2021

Let’s restate how we got here

Thinking back to our first issue and the inspiration for this series, Impact Mapping is meant to combine the “Service architecture documentation” and “Documented service dependency maps” from the blog post from @cloudpundit.

The “Service architecture documentation”

“helps us understand the ways a service is and isn’t resilient, so we can design accordingly”

The “Documented service dependency maps”

allow us to see the chain of dependencies for each of the services we use, allowing us to think about if Service X is really the best fallback alternative if Service Y goes down, as well as inform our troubleshooting"

When looking for evidence of Impact Mapping in hyperscale public cloud service providers, we can survey public information. Once again, the list is in no particular order or weighting other than shorter names to longer names.

IBM Cloud Impact Mapping examples:

Alibaba Cloud Impact Mapping examples:

  • Alibaba Cloud’s Well-Architected Framework promotes a “three pillars” approach to achieve 1. Reliability, 2. Security, and 3. Performance
  • Alibaba Cloud’s ChaosBlade offers an open-source approach to chaos engineering based upon the internal Alibaba Cloud Application High Availability Service (AHAS), MonkeyKing (fault drill platform), and chaos engineering tool.

Microsoft Impact Mapping examples:

Amazon Web Services Impact Mapping examples:

Google Cloud Platform Impact Mapping examples:

  • Google Cloud Architecture Framework promotes a “six pillars” approach to achieve 1. System Design, 2. Operational Excellence, 3. Security (Privacy and Compliance), 4. Reliability, 5. Cost Optimization, 6. Performance Optimization.
  • Google Blog posts are a call to action for learning about chaos engineering, SRE principles, Disaster Recover Training (DiRT), and applying the lessons learned.

Oracle Cloud Infrastructure Impact Mapping examples:


  • For this sampling, there was no access to consoles (portals) required.
  • IBM Cloud information linked to IBM Services for frameworks references which made “pillars” comparisons difficult.


In summary, there are incredibly stark variations amongst the hyperscalers in expressing Impact Mapping. Further, it is reasonable to expect the market will drive demand for standards that normalize the variations or promote wider adoption of approaches such as the C4 model.

  • Oracle Cloud emphasis is on 1. Security (and Compliance) whereas Alibaba Cloud, AWS, and Azure place emphasis on 2. Security and Google Cloud at 3. Security (Privacy and Compliance)
  • AWS emphasis is on 1. Operational Excellence whereas Google Cloud has 2. Operational Excellence and both Azure and Oracle Cloud has 4. Operational Excellence (Efficiency)
  • Alibaba Cloud and Azure emphasis is on 1. Reliability whereas Oracle Cloud has 2. Reliability (and Resilience), AWS has 3. Reliability, and Google Cloud has 4. Reliability
  • Google Cloud emphasis is on 1. System Design curiously with no comparable pillars to others since the end goal is to drive towards documentation, decoupling, and managed services adoption before seeking similar pillars of other frameworks.
  • Azure and Oracle Cloud emphasis is on 3. Cost Optimization whereas AWS and Google Cloud has 5. Cost Optimization
  • Emphasis on Performance is the last or next to last pillar for Alibaba Cloud, Azure, AWS, Oracle Cloud, and Google Cloud.
  • Looking back across these five newsletter issues, (stark) variations discovered seem to mirror similar findings from my blog post from March 2021 Multicloud March on low latency high bandwidth connectivity options.


Cloud in Public findings on Status DashboardsEngineering SLODevCommsOps, Mean Time to RCA, and Impact Mapping will not be static. As such, we want to understand what the Who, What, Where, When, and Why means in terms of business value engineering.

So, let’s get a quick overview of business value engineering and think about the customer journey.

Matt Smith, IFS discussing Business Value Engineering on SiliconANGLE Media's theCUBEMatt Smith, IFS discussing Business Value Engineering on SiliconANGLE Media’s theCUBE

Each hyperscale public cloud service provider will have to anticipate customers at various stages of a journey from status quo to one cloud or the eventuality of mutlicloud. So, having a business value engineering framework in place will ensure the following:

  1. Key business initiatives prioritization
  2. Key stakeholders in a living RACI matrix
  3. Structured Decision-making frameworks applied (Facts, Alternatives, Commitments, etc.)
  4. Predictions are possible because data, telemetry, and instrumentation enable the proper well-architected framework underpinned with the right technology at the right time
  5. Continuous improvement drives this back to step 1 again and again.

To state this another way, let’s loosely paraphrase Dean of Big Data Bill Schmarzo on the essential nature of step 4 and the WHILE.

The hyperscale cloud service provider must help customers achieve their initiatives WHILE they are conducting their present operational reality.

Help might come from so-called cloud pricing calculators like AWS Pricing Calculator, Azure Pricing Calculator, Google Cloud Pricing Calculator, Oracle Cloud Cost Estimator, IBM Cloud Cost Estimator, or Alibaba Cloud Price Calculator. However, in each example, there is no solid connection to Impact Mapping that permits building the business case with accurate modeling well in advance of OPEX decisions in any quantified manner.

Eventually, each hyperscale cloud service provider inputs from real-time pricing API or their calculators and estimators will become a consideration for business value engineering tools. So, keep an eye on tools companies for Impact Mapping updates for business value engineering (by alphabetical order) such as DecisionLink ValueCloud, Mainstay Advisor Value Platform, MediaFly Value Story Alinean, and VisualizeROI.

Ultimately, partnering with customers in business performance improvement terms is the only way hyperscale public cloud service providers will have an enduring competitive advantage. As such, each hyperscale public cloud service provider will need to make strategic investments that help the customer uncover the highest value opportunities to leverage the proper well-architected framework that is underpinned with the right technology – and at the right time.


I am linking to my disclosure.


✍️ 🤓 Edit on Github 🐙 ✍️

Share and discuss on LinkedIn or HN
  • Get Fudge Sunday each week