Stakeholder-driven presentation and high-level diagrams
Previous: https://medium.com/@svosh2/non-functional-requirements-ce6e55305900
Stakeholders in a system can vary widely in their roles, responsibilities, expertise, and levels of technical understanding. As a result, their understanding and knowledge of the system may also vary. To effectively communicate and explain the concepts of the system to different groups of stakeholders, it is essential to tailor the presentations and communication approaches accordingly. Here’s an overview of different types of presentations that can be used to cater to various stakeholder groups:
Executive or Management Presentations:
These guys don’t care about technical details. They want to know what value to business our solution will bring. We skip all the technical diagrams communication and implementation details etc.
We going to provide only high-level non-technical overviews of the system’s purpose, benefits, and strategic alignment with business objectives. We focus on the impact of key performance indicators, return on investment, and potential business value.
If we can provide any metrics about the benefits of our system (in money terms) — it will be a great attachment to this type of presentation.
Technical Presentations:
Here we need to share as many technical details as possible. These guys will implement our design, deploy it, support and take care of its security. We are going to provide architectural diagrams: present visual representations of the system’s architecture, components, and interactions. We use diagrams, such as block diagrams, flowcharts, or sequence diagrams, to illustrate the technical aspects and relationships between system elements. Let’s review a few useful types of diagrams we can use for this presentation type.
C4 Diagrams
C4 (Context, Container, Component, and Class) is a set of hierarchical diagrams used for visualizing and communicating the architecture of a software system. Using this set of diagrams we can describe the structure of the system with different levels of detalization.
Here’s an overview of the four types of C4 diagrams that can be used to provide the detail about our system to technical guys:
Context Diagram:
The Context diagram provides a high-level view of the system, emphasizing its interactions with external entities, such as users, systems, or external services. This type of diagram even can be shared with business stakeholders since it doesn’t have too many technical details.
Now, let’s imagine that we want to zoom into our system. Container Diagram — that’s what we will see.
Container Diagram:
Containers represent runtime environments, such as web servers, databases, or desktop applications, that host and execute components.
It showcases the major containers in the system as boxes and their interactions through labeled lines or arrows. The diagram highlights the relationships and dependencies between containers, giving an overview of how the system is divided into runtime components and their communication patterns.
Usually, a containers diagram has enough detalization for solution architects, but sometime when you have a goal to provide some specific structure of your application you may dive deeper into a components level.
Component Diagram:
The Component diagram focuses on the internal components within a container and their interactions. Components represent modular and cohesive units of functionality or modules within a container. It visualizes the key components within a container as labeled boxes and their relationships through lines or arrows.
We are not really going to zoom into a classes level, so we will just leave the definition of the last type of C4 diagrams (it may be useful for developers so if you are interested in it — feel free to read more on the official website: https://c4model.com/)
Class Diagram:
The Class diagram delves further into the internal structure of a component, focusing on the classes and their relationships. Classes represent the building blocks of a component and encapsulate its data and behavior.
Sequence diagram
A Sequence diagram is a type of interaction diagram that represents the interactions and order of messages exchanged between objects or components within a system on some shared timeline. This diagram is useful for understanding the sequence of interactions, dependencies, and collaborations among components or subsystems.
Here’s an explanation of the key components and elements of a Sequence diagram:
Lifeline:
A lifeline represents an object or component participating in the sequence of interactions.
Actor:
An actor represents an external entity or some component of the system, that interacts with/within the system being modeled.
Activation Bar:
An activation bar, also known as an execution specification or lifeline activation, represents the period of time during which an object is actively executing a method or processing a message.
Message:
Messages represent the communication or interaction between objects or actors in the system or inside the process of some object. They are depicted as arrows connecting the lifelines or actors.
Synchronous Message: Indicates a blocking or direct communication. Asynchronous Message: Represents a non-blocking or indirect communication, where the sender continues execution without waiting for a response. Return Message: Shows the response or return communication from the receiver object to the sender after processing a request.
Interaction Fragments:
Interaction fragments are used to represent specific scenarios or control flow constructs within a sequence diagram.
Flow diagram
A flow diagram, also known as a flowchart or process flow diagram, is a visual representation of a process or workflow. Flow diagrams provide a clear and visual representation of the steps and decision points within a process or workflow. Here’s an explanation of the key elements and symbols used in a flow diagram:
Start/End:
The start symbol represents the beginning point of the flow or process.
Process/Activity:
A process or activity represents a specific task or action within the workflow. The process/activity box typically contains a brief description of the task or action being performed.
Decision:
A decision symbol is used to represent a branching point or a decision point within the process. It indicates that the flow can follow different paths based on a specific condition or criteria. Each branch leaving the decision symbol represents a different outcome based on the decision’s condition.
Input/Output:
Input and output symbols represent the flow of data or information into and out of a process or activity. The input symbol represents data or information being provided to the process, while the output symbol represents the result or output generated by the process.
Arrows and Lines:
Arrows and lines are used to depict the direction and flow of the process. Arrows indicate the sequential order of steps or the flow from one activity to another.
NOTE: Feel free to combine sequence and flow diagrams. For example — you are able to present flow on the timeline with interactions between different system components or communication with external systems.
Deployment diagram
A Deployment diagram illustrates the physical deployment of software components and their relationships within a system. It focuses on visualizing the hardware and software infrastructure required to run and host the system. Deployment diagrams are useful for stakeholders who are responsible for system components deployment. Here’s an explanation of the key elements and symbols used in a Deployment diagram:
Nodes:
Nodes represent physical or virtual computing resources that host or execute software components. They can represent servers, devices, computers, or even cloud-based resources.
Components:
Components represent the software modules, libraries, or executables that run on the nodes. They encapsulate specific functionality or services provided by the system.
Artifacts:
Artifacts represent physical or digital files that are used or produced by the components during deployment or execution. They can include executables, configuration files, database scripts, or any other relevant files.
Relationships and Connections:
Relationships between nodes and components are depicted using lines or arrows connecting the nodes and the components they host.
The lines may represent different types of connections, such as network connections, communication protocols, or dependencies between components.
User-Focused Presentations:
Users. Oh, we really love these guys. We want to them to be satisfied and ready to bring us money (it’s a joke, but only partially).
This type of stakeholder won’t know anything about how our system works but they want to be sure that the system will solve their needs. There are a few types of presentations we can provide to them.
User Interface (UI) Walkthrough:
Demonstrate the system’s user interface, showcasing key features, workflows, and user interactions. Use screenshots, mockups, or prototypes to help users understand how to navigate and interact with the system. Usually, here we ask designers to help (they open Figma, make some magic, and… voila!) but for sure the architect should conduct a series of meetings with designers to be sure, that their ideas are feasible at all and not controversial with other stakeholders needs.
Use Case Scenarios:
Present real-world scenarios or stories that illustrate how the system addresses specific user needs or solves common problems. Emphasize the benefits, efficiencies, and improvements that the system brings to users’ workflows or tasks. Here’s an explanation of the key elements and symbols used in a Use Case Scenarios diagram:
Actors:
Actors represent individuals, users, or external systems that interact with the system being modeled. Actors can include end-users, administrators, external systems, or any other entities that interact with the system.
Use Cases:
Use cases represent specific interactions or tasks that an actor performs with the system. They depict the system’s functionality from the perspective of users or external systems. Use cases describe the system’s behavior, showing the actions or activities performed by the system in response to an actor’s request.
Relationships:
Relationships in Use Case Scenarios diagrams illustrate the associations and dependencies between actors and use cases.
System Boundary:
The system boundary represents the scope or context of the system being modeled. It encloses all the use cases and actors involved in the diagram.
Now we have all our needed weapons (almost) to design amazing architecture. But how to combine all of them together? Let’s discuss how all our outputs should be structured in the next article.
