By Scott Ambler, Consulting Methodologist, Ambysoft Inc.
In Agile Architecture for Software Development Teams: Doing Agile I described a collection of techniques for agile architects, one of which is inclusive modeling. As agilists we work together closely in an iterative and highly collaborative manner in all aspects of our work, including architecture. Inclusive modeling is a practice from the Agile Modeling method where we purposefully use simple tools and techniques so that we include our stakeholders as much as possible.
As architects we have a wide range of stakeholders. At the one end are developers, people who are highly technical but who may not have much experience with modeling or software-based modeling tools. At the other end of the spectrum we have business executives, few of whom have a technical background and most of whom consider Microsoft Powerpoint to be their drawing tool of choice. In between these extremes we have other IT professionals, project managers, subject matter experts (SMEs), support engineers, and many more. Each individual will have varying levels of experience at modeling and with modeling tools, and in most cases will have little of either.
Our architecture work not only needs to address complex domains it also needs to stand the test of time in an environment of great change. This can lead us to assume that to address this complexity we need to use complex tools and complex techniques, but that assumption is wrong. To understand and address the complexities that we face we must work effectively with our stakeholders to understand their needs to and gain their insights. To do that we need to include them in our modeling efforts, we need to communicate and collaborate with them effectively – in short, we need to meet them where they are, not where we want them to be. The implication is that we need to adopt techniques and tools that are inclusive, that are simple enough for non-modelers, non-architects, to work with.
Simple Techniques
In general, agile architects try to stay away from complex diagrams when working with our stakeholders. As architects we often think abstractly and lean towards visual thinking, but this may not be true of our stakeholders. Similarly, we are likely very familiar with modeling notations such as those of the UML, whereas our stakeholders often struggle to understand these notations due to lack of familiarity. The implication is that we need to focus on simple technique to ensure inclusion.
Luckily, there are many straightforward and relatively simply architecture models that we can choose to create with our stakeholders. This includes, but is not limited to:
- Change cases. A change case is a description of a potential business or technical change that could occur at some point in the future. Change cases are often captured in point form text, often on sticky notes or index cards. Change cases enable architects to think about potential future challenges without necessarily acting on them right away.
- Domain models. Domain models capture the main business entities and the relationships between them. Although traditional data professionals will often produce highly detailed domain models, agilists instead prefer to keep them light weight and sparse to enable flexibility and understandability. The more details you capture, the greater the chance that your stakeholders will tune out.
- Event models. Event models capture how information is changed within systems, or within ecosystems, over time. Event models are often created via an application of agile modeling strategies called event storming that uses simple tools to work with stakeholders.
- Free-form diagrams. Free-form diagrams are very likely the most common form of architecture diagram, typically captured via whiteboards or Microsoft PowerPoint.
- Milky way maps. Milky way maps visualize the whole organization, from a business point of view, on one page. In the middle of the map is the organization logo as shown in the figure below. The center is surrounded by the value stream, which is divided into sectors that consist of capabilities.
- Network diagrams. Network diagrams are commonly used to depict hardware nodes as well as the connections between them. Network diagrams are often drawn as free-form diagrams or simplified UML deployment diagrams.
- Process flow diagrams. Process flow diagrams capture the business flow of a process or value stream. There are many styles of process flow diagram, including data flow diagrams (DFDs), free-form diagrams, flow charts, and UML activity diagrams.
- Security threat models. Security threat models capture a system’s security risks. Security threat modeling enables you to understand a system’s threat profile by examining it through the eyes of your potential foes.
Looking at this list, you’re probably thinking to yourself that you’ve seen many examples of complex versions of these models over the years. Yes, it happens. It’s your choice to keep them simple or to make them overly complex. I typically strive to have no more than four or five types of modeling elements on any given artifact. For example, on process flow diagrams I would use symbols for processes, flows, people, and systems and leave it at that. Juxtapose that with the dozens of symbols used on UML activity diagrams, which may be useful for visually coding the business logic but proves to be utterly confusing to business stakeholders (“what’s the difference again between this type of arrowhead and that type of arrowhead?”)
Simple Tools
For modeling to be inclusive we need to adopt tools that both we and our stakeholders are comfortable working with. Our stakeholders will rarely have deep experience in the software-based modeling tools that we often prefer to create detailed, permanent models with. These complex tools, which have their purposes, have the downside of leaving most of our stakeholders out of the modeling process. This points to an interesting philosophy: use simple tools for the act of modeling, and, if appropriate, more complex tools for the act of documentation.
Luckily there are many simple physical modeling tools available to us, including whiteboard, index cards, sticky notes, flip chart paper, and string. Consider the process flow diagram described earlier. On a whiteboard you could use sticky notes for nodes such as processes, people, and systems and then draw lines between them to represent flows. Or using a corkboard the nodes could be captured using index cards and the flows using string.
If COVID taught us anything, we need to be prepared to work remotely. Luckily there are many software-based collaborative tools that are easy to learn how to work with. This includes virtual whiteboard functionality built into meeting tools as well as collaborative environments such as Miro or Mural. And our normal business productivity tools such as MS Office and Google Office are now hosted in the cloud offering real-time, multi-editor access.
Why is Inclusive Modeling Important?
Inclusive modeling enables another critical Agile Modeling practice, active stakeholder participation. The people who are best suited to model what they want are the stakeholders themselves. Similarly, the people who are best suited to model how something will be built are the people who are going to build it. The implication is that when you are requirements modeling you want to work closely with stakeholders and when you’re architectural modeling you want to work closely with developers. Active stakeholder participation is the focus of my next article, stay tuned.
Scott can be reached at scott@scottambler.com