You're facing a room of non-tech stakeholders. How do you explain complex software architecture to them?

I like to choose a simple, fun analogy because then people memorize it much more easily: think of software architecture as a giant sandwich. The bread slices are the user interface—what everyone sees and interacts with. The layers inside are like the different components: lettuce (data), tomatoes (business logic), cheese (APIs), and the secret sauce (security). Just like every ingredient has a role in making the sandwich tasty, each layer in the software has a specific function. Just like with a sandwich, if the foundation (the bread) is flimsy, the whole thing falls apart, making a mess. Without a sturdy base, we’ll end up with a kitchen disaster instead of a delicious masterpiece.

When explaining software architecture to non-tech stakeholders, I always start by laying a strong foundation with basic principles. I use everyday analogies to make these concepts relatable. For example, I compare software layers to floors in a building. Each floor has a specific function, yet they all work together to create a complete structure. I emphasize the importance of a solid foundation for future scalability and security, much like the foundation of a house needs to be strong to support additional floors or withstand storms. This approach helps non-tech stakeholders visualize the structure and purpose of the software without getting bogged down by technical jargon

I tend to apply a multi-pedagogy approach- after all, everyone learns and understands differently. I tend to start with modelling in a white-board presentation style and move to working with my clients to replay the concepts using real world examples and analogies in their business area which is more centered on them. My clients are the experts in their business so it is important for me to relate their knowledge back to a technical design and vice versa. It is imperative that clients can see how design capabilities introduced by me relate to their area of business strategy.

Analogy and visual assistance are the key for such situations. start with a Business problem, which everyone understand. Even best to ask a problem to the audience. Then try to make solution form outside in and create an interesting flow of discussion. Take a pause in every 2-4minutes, and encourage the stakeholders to participate in discussion and raise questions. If they keep on asking, you are in the right direction. On a side note, I think this task is best carried out Architects in Presales and Solutions team.

Visual aids can make a huge difference. I often use diagrams or flowcharts that represent the software architecture. For instance, I might show a multi-layered diagram where each layer is labeled with its role (e.g., user interface, business logic, data storage). These visual tools help stakeholders see how different parts of the system interact and support each other.

I relate software architecture to processes they are familiar with. For example, I might compare the workflow in the software to a supply chain in manufacturing. Each stage (or component) in the process has a specific role, and the efficiency of the whole system depends on how well these stages are integrated and managed.

I focus on the benefits of good software architecture, such as improved performance, easier maintenance, and scalability. I explain that, just like a well-designed building, a robust software architecture makes it easier to add new features (like adding new rooms) and ensures that the system can handle more users (like accommodating more people in a building).

I encourage stakeholders to ask questions and provide feedback. This helps me understand their concerns and adjust my explanations accordingly. It's important to create an open environment where they feel comfortable seeking clarification on any point.

It might not be practical to explain complex architecture to non-tec stakeholders. Instead, focus on: - Clearly explaining the problem at hand and the solution you propose/built. - Explain advantages, disadvantages, and set expectations for regular operation and performance. - Bring up consensus on SLAs/SLOs. - Use data and visuals to explain complex topics. Knowing your audience will propel your career forward, as well as make your presentations useful for everyone.