Narrative Based Design - Agile Architecture II
Software Architecture in a (Fr)Agile World - the Power of Sprint Zero
(image credit: smartai.studio alpha - AI generated stock image - unknown problem domain)
When you're tackling a new complex problem domain in software development, the architecture of your solution is critical. Without a strong architectural foundation, your solution might struggle to meet its requirements, be difficult to maintain, and fail to scale.
Great outcomes are possible when you adopt an optimized architecture process and marry that to a modern Agile software process. I encourage new agile software teams to participate in a set of “Sprint Zero” requirements and architecture activities, with the following roles assigned (at a minimum).
Product owner
UI/UX design lead
Quality / QA lead
System / software architect lead
ENG (or DEV) lead
These activities will help elaborate requirements and architecture before any actual development sprints get on their way. Startups or small teams may need to have individuals potentially wear multiple hats - but each role and it’s associated activities are critically important.
Sprint Zero
If the problem domain is complex (and/or unknown), then it’s important that the different stakeholder roles defined above, have a common understanding and vocabulary for the major entities and aspects of the system. A system narrative, use case diagram, list of actors, UML (Unified Modeling Language) static structure diagrams, and/or logical entity models are powerful tools to provide this foundation. The narrative, use case diagrams and list of actors contribute to a common understanding of the business requirements, potential customers (i.e. users), and the intended usage of the system. The static structure and entity models help clarify the language and vocabulary of the problem domain between all stakeholder roles, also provide a great head start to understanding the problem domain at a deeper level.
Enable Understanding not Laziness
As an engineering and/or architect lead, if a coherent system narrative and set of high level use cases (coarse-grained, epic level) are not successfully produced, for the first phase/milestone of the system, then I would advise you to hold your ground a bit.
Occasionally, the business does not know what it wants - they may deem that its a technical engineering exercise to determine what should be built. If so, then you may want to hold off on any product-level efforts and focus on a set of design and engineering incubations (proof of concepts), this can help the business and/or product teams decide and lock down the high level ask.
Otherwise, I would classify this a lazy response from the business and blurs the line of responsibility between the product and engineering teams. If you decide to move forward with a development effort, where a narrative cannot even be formulated, then I’m not sure how you will ever know what to build, or if what you built met any type of quality or product criteria, outside of your users telling you (which may be OK! - see the last section)
(image credit: smartai.studio alpha - AI generated stock image - walking into the unknown)
Sprint Zero Outputs - Understanding the WHAT
Let's see how each output contributes to understanding the problem domain:
System Narrative: This is a high-level description of the system that explains how it functions from a user's perspective. The system narrative is an excellent starting point because it establishes the problem you're trying to solve and how your proposed solution addresses it. This narrative sets the context for the entire software development effort.
Use Case Diagram: These diagrams represent the set of actions or functional requirements of the system. Each use case represents a specific process in the system and the interactions between the system and its users (actors). Use case diagrams help in understanding what the system is supposed to do, which is crucial in the early stages of software development.
List of Actors: An actor in a use case diagram can be a person, a system, or an external entity that interacts with the software system. Identifying all the actors gives a clear understanding of who the users are, what roles they play, and how they interact with the system. This helps to identify system requirements from different perspectives.
UML Static Structure Diagrams: These diagrams (often called class diagrams or object diagrams) depict the static structure of a system, including the system's classes, their attributes, methods, and the relationships among objects. These diagrams offer a blueprint of the system structure, which guides the implementation phase. They also provide a common language for developers to discuss the system's architecture and design.
Logical Entity Models: These models (also known as entity-relationship models or data models) represent the logical structure of the data in the system. They depict the types of data, their attributes, and the relationships between them. Logical entity models are crucial in designing the database architecture of the system and ensure the efficient handling of data.
Together, these tools allow the architects and developers to understand the system's requirements, structure, and design. They provide an excellent architectural start, helping to mitigate risks, improve maintainability, and ensure that the system can meet functional and non-functional requirements. Additionally, these tools also facilitate effective communication within the team and with stakeholders.
The Product Owner, engineering lead and relevant stakeholders can now start creating (and prioritizing) the backlog by decomposing the epics (i.e. use cases, features, etc) into user stories.
Sprint Zero Outputs - Synthesizing the HOW
Once you achieve a thorough understanding of the WHAT, the designers, architects and engineering leads can now synthesize a strong first pass on the HOW, including
Technology stack selection
Buy versus build decisions
Security Threat Modeling
Infrastructure Considerations
I would suggest the following set of outputs, primarily from the system architects and designers for the next steps of Sprint Zero.
Logical Block Diagram - An excellent communication tool, this ‘birds eye’ view of the system, can work magic in clarifying and synchronizing the various mental models at work in different stakeholder brains. This diagram will save your life when communicating to executives and engineers, and various technical and non-technical stakeholders, keep it up-to-date and at the ready.
Dynamic Sequence Diagrams: Once the problem domain is well understood , the architect can initiate modeling key dynamic aspects of the system, using UML Sequence diagrams. The diagrams should make use of names of the actors and entities defined in the HOW definition phase. These are coarse grained sequence diagrams, not detailed sequences that are generally produced during the development sprints. I would focus on the most complex and foundational dynamic flows, for example,
User authentication and registration flows,
Data processing and storage flows (from UI => data store),
Data Analytics & Aggregation flows, etc.
Test Cases / Test Strategy: At this point, the QA lead has enough information to create a viable test strategy and high level set of test cases for the system. (QA elaboration out of scope for this post)
Security Threat Model: (out of scope for this post)
I know what you’re going to say, “But Bert, this is ALOT, it’s going to take months and it sounds like Waterfall”. This is the OLD WAY !! There’s a ton of wisdom in the old ways, enabling $trillions in business over the last 30-40 years. Marrying the old with the new mitigates the risk of the new, with the wisdom of the old, cherry pick what works, throw away the parts that are slow or irrelevant and you have a risk-mitigated pragmatic solution.
If the organization is committed and properly resourced, a Sprint Zero can happen in 2-4 weeks, and if you’re a startup, it can happen in less than two weeks (a typical sprint) for an initial MVP or Phase I (or ALPHA) effort.
(image credit: smartai.studio alpha - AI generated stock image of an older man)
Forget All That, ITERATE Your Way To Success
Another viable approach, if you have the appetite and resources, is to iterate your way through your requirements and “WHAT” stage. This is a riskier iterative approach, but closer to the Agile principles and manifesto. In his “Has UML Died Without Noticing” blog post, Ernesto Garbarino states
Today’s paradigm, though, is that we are hopeless at understanding the problem anyway. Digital transformation gurus tell us that we should deploy into production and let the users tell us what the business requirement is, rather than formulating it ourselves a priori. We can take multiple shots until we get it right. Yes, fail fast, and often.
Definitely a viable option for funded startups — but I would recommend a more rigorous architecture / requirements phase for larger, more established business and organizations, where ‘failing fast’ is used during pep rallies and tech conferences but rarely truly supported by executives of larger organizations.
Agile Modeling is another software architecture driven process, more aligned with the iterative nature of agile - they also advocate an upfront requirements and architecture phase - to build a shared understanding of defining the system and associated business ask, and much tighter, JIT modeling sessions that align with the iterative nature of agile.
(image credit: smartai.studio alpha - AI generated stock image)
Conclusion / Recommendations
In terms of tools, the ‘youngens’ have pushed me off of Microsoft Visio and into Lucidchart and draw.io (now diagrams.net) but my favorite tool by far is a simple Miro board. I can create all my architecture and engineering artifacts in one place, taking advantage of the visual nature of the diagrams, laying them out next to each other, cross referencing diagrams — and presenting an architectural ‘single pane of glass’ - surely beats a document and in my experience, more effective than a wiki.
Narrative Based Design, is a pragmatic architectural approach marrying the wisdom and knowledge of decades of software analysis, architecture, design and development with the accelerated timelines and ambiguity of today.
Simple narratives and usage scenarios can launch a team into a common understanding of the ask - the WHAT. Visual architectural diagrams and pictures are the best way to synchronize the WHAT with the HOW, syncing mental models into a shared visual representation. As a modern software architect, creating the diagrams also serve as a forcing function to ensure that you (and your architects) deeply understand the problem domain, which can lead to the discovery of gaps and new ideas, which can then brought to the product and biz teams to consider and integrate into their product strategy.
Resources / Tools / Links:
Lucid Chart (UML) - subscription required
Miro - UML Diagram - subscription required - (search UML) in their shapes search box - you’ll find everything you need to build UML Sequence diagrams, static structures and more
Microsoft Visio - Office 365 - Create a UML Sequence Diagram
Has UML Died without Anyone Noticing - Ernesto Garbarino - Good article on the shift to iterating your way out of requirements ambiguity.
Agile Modeling - Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation.
Need help? Startup? Fortune 500? Fortune 50? Contact us at smartai.services for high impact consulting and virtual CIO services (or email: consulting).
Looking for a Generative AI Platform for your startup, small business or org? Contact us at info@smartai.systems and inquire about SaSSY - our Generative AI B2B SaaS Platform, enabling simplified entry and workflows across chat, text and image generative capabilities (current ALPHA complete, in active BETA dev)
Check out our smartai.studio stock images solution (alpha) based on SaSSY.