A solution architecture design tells the story of a solution architecture to people in various roles. Architecture Use Cases can help a solution architect make that story more compelling. In Wittij People-Centric Architecture method, people are always front and center - as evidenced by our method name. Solution architects only design solution architectures because a person (aka. "user") needs a solution. The People-Centric Architecture method includes diagrams and approaches for telling the story of a solution architecture and ensuring the protagonists in that story are the people who will use the solution. One construct we use to guide this storytelling is Architecture Use Cases.
Architecture Use Cases provide a light narrative approach to help tell the story and to ensure a solution meets the end user's needs. In prior articles, I discussed the Solution User Diagram for scoping a solution by identifying the users who need a solution and what they need to do with it and a Conceptual Solution Architecture Diagram for visualizing a conceptual-level design. Architecturally significant use cases serve as the glue to tie those two together.
I sometimes use the phrase "Architecturally Significant Use Case" because it more accurately describes this tool. But that is quite a mouthful, so let's stick with "Architecture Use Case."
A Use Case describes the interactions between a user and a system to achieve a goal. The Use Cases communicate functions and features desired in a solution and often animate screen mockups. The core elements of a Use Case are a name, a goal, and a description of the interaction, which can range from informal to highly structured steps.
Architecture use cases are the functional Use Cases that impact the architecture design. Only a small subset of functional requirements drive solution architecture choices. Similarly, only a handful of functional Use Cases drive solution architecture decisions.
You can follow a standard approach for determining the Architecture Use Cases:
Once you complete this activity, you should have figured out the minimum set of Architecture Use Cases to explain your design.
Here is where the value starts to escalate! Next, you review any remaining activities from your Solution User Diagram. Each additional activity you check will result in one of the following outcomes:
When you finish, every activity on the Solution User diagram should map to one of your Use Cases, your Conceptual Architecture Diagram should cover every Use Case, and you will have confirmed that your architecture fulfills all the requirements.
Whaaaaaaaat?! You probably should evaluate that decision, but... don't worry. You can still produce value using this technique with alternative architecture methods. Start by selecting some sample activities users will perform using your solution. Walking users through a solution architecture diagram by picking activities they understand and explaining how those activities will flow through the architecture is the best way to present a solution architecture. If you figure out the minimum set of activities required to cover every box (component) and line (connection) on your diagram, you will have your list of architecturally significant use cases!
Walking users through a solution architecture diagram by picking activities they understand and explaining how those activities will flow through the architecture is the best way to present a solution architecture.
We document Architecture Use Cases using a few elements and usually list them in a table.
| Field | Description | Example |
|---|---|---|
| Id | This is the unique identifier for the Architecture Use Case. It is a unique number, usually just a simple sequence (1, 2, 3...). Makes it easy to reference the Use Case in discussion or other work products. | 1 |
| Use Case | This is the name of the Use Case using the standard use case naming convention, which is a verb followed by a domain-specific noun. Keep the names as brief and "on target" as possible, so it is clear to your audience what you mean. | Complete Application |
| Solution | This brief narrative describes how the solution architecture will implement this Use Case. More on this is below. | Agents will log on to the Agent Portal and complete an application. The Agent Portal will invoke Enterprise Agent APIs to prefill application fields. Once the Agent submits the application, the Agent Portal will invoke an API to submit the application to the Onboarding Workflow Platform. |
The Solution section deserves some additional discussion. Here are some tips for writing a good solution narrative in an Architecture Use Case. It is important to remember that you are not writing the actual Use Case here; you are providing a narrative overview of how your solution will handle the Use Case.
Architecture Use Cases are just one tool in our storytelling toolbox that help you design, communicate, and facilitate the discussions needed to develop a solution architecture. If you add these to your toolbox, you will find they bring value in numerous ways:
