Presenting Cloud Architectural Diagrams to Business Leaders 

The Common Way to Present Diagrams 

Have you viewed or created slide decks with the following agenda? 

1. A few slides explaining your opportunity: 
    “We plan to expand our product into Europe. Our market research shows it will open up new customers that will enable sales to far exceed our targets” 

2. Followed by slides breaking it down into objectives:  
   “When we expand into Europe, we expect a rise in demand for demos and new client onboardings.  We need to make sure the increased activity does not impact the responsiveness of the application for both new and old customers.  We must also shorten our customer onboarding process, to keep up with the expected demand.   

3. An architectural diagram awkwardly inserted: 
   

4. Conclusion with slides covering what you need
   “We need a team of X, a budget of $Y and a timeframe of Z to make this a reality”

---

Wasted Opportunities with Business Leaders

In the best-case scenario, your business audience has a technical background or sufficient history with IT projects to understand and extract value from the diagram. Alternatively, they may call upon technologically savvy colleagues to assist.

In most cases, there is an expectation that you are the team’s expert. If you present as an engineer, non-technical stakeholders will gloss over the diagram or feel exposed by their lack of comprehension, increasing the risk of failure. How? You miss out on feedback from a business perspective. This results in a technically sound design, which is misaligned with business objectives.

Consider an extreme example: the design proposes an investment in DevOps with CI/CD to build deployment pipelines for an application being removed within the year, has no planned updates, and is only migrating to the Cloud to address compliance issues. The result is an overengineered design driven solely by technical aspirations.

How do you spark collaboration with business leaders to obtain the feedback you need? By presenting how your designs achieve the organization’s business goals.

---

Always Express Clear Business Goals

A common rationale for the selection of design approaches is to use what has worked historically. There is sound reasoning for this approach, as it allows you to:

1. use existing skills to reduce training and discovery efforts
2. improve your team’s skills in specific technologies and frameworks
3. re-use existing artifacts to drive efficiency implementing consistent designs to improve maintainability
4. reduce implementation time and defects

The list of justifications above is focused on implementation objectives, which are largely technically based even if there is an attempt to spin business value (e.g., maintainability). To improve business leader confidence, present design decisions which are clearly and explicitly aligned with their goals. Showing how their objectives will be met, enables their participation in discussions to validate your design.

Take the earlier example of expanding a product into Europe. Two business goals are:

1. Shorten the onboarding time for new clients to handle the rise in demand
2. Ensure consistent application performance so all users have the same experience

---

A Design Decision Aligned to Business Goals

Let’s examine a design decision that supports the first objective for a shorter onboarding process. The proposed technical design is investing in a CI/CD pipeline.

When presenting, justify your decision by showing how it satisfies the objective. In this case, the design reduces manual efforts by automating deployment activity. This will shorten onboarding by reducing:

• Delays introduced by inaccessible team members
• Rework created by errors in manual activity
• Training for deployment support staff
• Coordination effort

Correctly presented, the information will help business leaders understand the link between your design and achievement of their business goals. This will be reflected in their queries and level of engagement.

---

A Design Decision Not Aligned to Business Goals

Consider another example, in which a team is proposing the implementation of a warehouse to support data analytics.

---

Cloud Consideration

A Cloud project is much more dynamic than traditional IT.  Why?

1. Cloud platforms are continually releasing new services and capabilities.  Your toolset is even changing and growing over the lifespan of your project.
   
2. Organizations are struggling to establish and maintain compliance and governance controls in a volatile regulatory environment.  Expect directional changes and evolving policies during cloud adoption.
   
3. Cloud promotes innovation and experimentation.  The ease of experimenting with new services and capabilities will drive the evolution of your design decisions during your projects. 

While marketing teams promote the benefits of ever-changing capabilities of their technologies, companies using those capabilities know first-hand of the risk presented by any change, let alone frequent change.  This increases the need to consider adaptability in solution designs. 

When presenting a design, come prepared with additional options, estimates of effort, and impacts to business goals that would result from mid-course corrections.  In our Europe product example, switching out AWS Code Pipeline for Gitlab might result in:

• A four-week effort to replace the technology
• Fewer immediate productivity gains due to a lack of Gitlab in-house skill; onboarding-time may only improve slightly until staff are trained and have had time to hone their skills.

Presenting alternatives shows consideration of available options and preparedness if the design must change for unforeseen reasons.

Final Thoughts

There is no such thing as an optimal cloud solution architecture for all scenarios. Design teams are faced with the task of mapping business requirements to an architecture that meets short-term business objectives with the ability to adapt to future change.

Communicating the basis of your design to business leaders is vital for obtaining buy-in, demonstrating confidence, receiving valuable guidance, and ensuring alignment.

Here are a few final recommendations when you present your design:

• Use numerical measures where possible. For simplicity, this blog generalizes with statements like “reduction in manual errors reducing rework”. Whenever feasible use historical data and set meaningful targets.
“Over the last quarter, 20% of customer onboardings included at least 1 manual error, and our average onboarding process takes 3 hours. Our post-project target is to see quarterly results of less than 5% of onboardings impacted by manual error and the process taking on average under 30 min.”

• Define technical terms in a glossary using plain language
e.g., Kubernetes = A system that automates the deployment, scaling, and management of containers.

• Make technical diagrams a living document accessible to both technical and non-technical audiences
e.g., Use tooling like Lucid Charts to seamlessly share the diagram and ask for feedback by a specific date, allowing sufficient time for business leaders to absorb the material offline.

If you want to discuss further the challenges and surprises of cloud migration, you can reach me on LinkedIn or by email.

If your organization is looking for help on getting started (or tried and is now dealing with constant fire drills), don’t hesitate to reach out and grab 30 minutes. I enjoy the opportunity to be a sounding board, collaborate and learn more about your experience or upcoming challenge.

---