Designing Solution Architectures with Architecture Use Cases

Dan Hughes
February 28, 2023
Monk writing at table.

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.

What is an Architecture Use Case?

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."

Use Case Clip Art

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.  

Applying Architecture Use Cases

Finding the Architecture Use Cases

Robot with binoculars to illustrate looking for Architecture Use Cases

You can follow a standard approach for determining the Architecture Use Cases:

  1. Pick a user from your Conceptual Solution Architecture Diagram
  2. Select an activity for that user from your Solution User Diagram
  3. Walk through the architecture on your Conceptual Solution Architecture Diagram, starting from the user and stepping through the integrations and systems that support the activity.
  4. Repeat these steps until you have covered all the possible flows through your architecture.

Once you complete this activity, you should have figured out the minimum set of Architecture Use Cases to explain your design.

Validating Coverage

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:

  1. One of the Use Cases you documented above already covers the activity. If necessary, you can tweak the name of your Use Case to be slightly broader and cover the full scope of activities.
  2. Oops. You missed something! Your architecture doesn't cover the activity. You need to add the missing activity as a Use Case and adjust the architecture to handle the new Use Case.

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.

What if I don't use the People-Centric Architecture method and diagrams?

Pirate walk the plank comic for people who don't use our architecture method

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.

Documenting Architecture Use Cases

We document Architecture Use Cases using a few elements and usually list them in a table.

IdThis 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 CaseThis 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
SolutionThis 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.

  • Always start with the role of the person performing the Use Case. It helps you keep the focus of your architecture on the people. We bold the role names so they pop.
  • Sometimes if your architecture is deep in the bowels of a more comprehensive solution, it can be difficult to trace your part back to a person performing an activity. You must do this. Don't ever have a Use Case called "Load File." Dig in and figure out what a person is doing that requires that file to be loaded and start there.
  • Using brief sentences, start from that role and walk your way through the layers of components involved in processing whatever that user is doing. Underline the components to help the user connect the narrative to your solution architecture diagram.

Let the Storytelling Begin!

Black and white drawing of medieval monk writing at a desk

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:

  1. They are the glue that connects your Solution User Diagram to your Conceptual Solution Architecture Diagram so that a solution architect can validate that a solution architecture addresses the user's needs.
  2. They help the solution architect determine the best people-centric approach for guiding your audience through the architecture diagram.
  3. They provide a narrative walkthrough of the architecture that makes "self-service" even more accurate for future consumers of the solution architecture.

Dan is the founder of Wittij Consulting. Prior to founding Wittij, he spent a decade in software development before moving into IT architecture, where he created an Open Group recognized architecture method and led delivery of all services for a company specializing in enterprise and solution architecture for 15 years. He is an energetic, thoughtful leader with an ability to engage and motivate people, and has been called a “force multiplier” for his ability to not only deliver great value, but also increase the value and capability of the people around him. Dan is a strong facilitator, able to understand and resolve complex disagreements with diplomacy. He comprehends and communicates clearly both at the detail level and the boardroom summary level to both business and technical audiences. His knowledge of enterprise techniques and technologies is broad and deep, and includes industry expertise in manufacturing, financial services, banking, health care, insurance, regulatory compliance, and NGOs.
Copyright © 2024 Wittij Inc.
crossmenu linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram