Table of Contents
Cloud architectural diagrams are fantastic visual aids; they paint a picture that summarizes design decisions, technology choices, and connectivity paths. When shared, they spark collaboration amongst your developers, network engineers, cloud architects, etc.
Despite this value, we rarely see technical diagrams presented to their full potential. Drafted by engineers, they are frequently created for an audience of their own peers. When shared with non-technical team members, they are shoehorned into presentations as the “obligatory” technical slide.
This doesn’t need to be the case and with some guidance, I will explore how you can expand them with techniques that spark discussions with business leaders and build trust in your designs.
The Common Way to Present Diagrams
Have you viewed or created slide decks with the following agenda?
- 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”
- 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.
- An architectural diagram awkwardly inserted:
- 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:
- use existing skills to reduce training and discovery efforts
- improve your team’s skills in specific technologies and frameworks
- re-use existing artifacts to drive efficiency implementing consistent designs to improve maintainability
- 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:
- Shorten the onboarding time for new clients to handle the rise in demand
- 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.
The data warehouse offers value but cannot be justified by the business objectives of the project. This should be a significant concern as you will:
- increase costs with unnecessary scope
- delay the business value with extended timelines
- add complexity and risk to the project
Capabilities which are not backed with project requirements, should be cataloged as options for a future presentation or discussion. I recommend creating a second diagram, targeting short and long term aspirations, to provide a clear delineation between short term scope and future potential.
The danger of architecture diagrams that illustrate broad, future looking scope is the generation of excitement amongst all stakeholders, business and technical, that can lead to unrealistic expectations. By focusing your presentation on business objectives, you are encouraged to limit your design to the necessary and immediately valuable capabilities.
A Cloud project is much more dynamic than traditional IT. Why?
- Cloud platforms are continually releasing new services and capabilities. Your toolset is even changing and growing over the lifespan of your project.
- 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.
- 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.
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 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.