Assign Functional Responsibilities to Elements
Every element in the architecture has a job to do. As we choose structures, we’ll assign specific functional responsibilities to each element so we can achieve all the essential functional requirements.
Let’s look at an example from our case study system, Project Lionheart. Here are some functional requirements gleaned from interviews with people from the Office of Management and Budget.
An Office of Management and Budget user can:
-
Search existing and past city contracts
-
Paginate through all results
-
View basic information about a company including the name, phone number, address, and list of past and active contracts
-
View basic information about a contract including the type, status, expiration date, PID, bidding companies, and who won the contract
-
Subscribe to receive alerts about contract updates
Several responsibilities are implied by these functional requirements, in addition to the things directly mentioned:
- Since users can search, this suggests it must be indexed.
- To show contract and company information it must be stored.
- Subscriptions require that the system stores email addresses.
- To alert users about changes implies something can recognize when a change has happened.
Here is one view of a set of elements that will allow us to achieve these functional requirements shown in the figure.
Here is an element responsibility catalog for this diagram:
Element | Responsibility |
|---|---|
Web UI | Renders a user interface for the user in their web browser, handles user interactions. |
Display Business | Authentication and authorization, proxy for other backing services, verifies business logic for application use. |
Search Service | Core processing for query parsing, search, pagination, filtering. |
Favorites Service | Normalizes tags, writes favorites to persistent storage. |
Alerting Service | Scheduled to look for recent changes, sends email based on subscriptions stored in user metadata database. |
Crawler | Reads data from the Contracts DB, transforms it for search, uploads to index. |
User Metadata DB | Persistent storage for user subscriptions and other user-added content. |
Search Index | Optimized representation of contract data designed for search. All contract data to be displayed in the UI is searchable, sortable, and stored. |
Contracts DB | Persistent storage. System of record for city RFP data. |
HTTP Relation | Communication among services over standard HTTP protocols. APIs are assumed to be RESTful. |
DB Driver Relation | Native driver/client for the to-be-selected database. |
The element responsibility catalog describes the essential duties each element in the architecture has the authority to perform. We created this element responsibility catalog by running down the list of the known influential functional requirements and ensuring each function was owned by one and only one element. Also, each element in the architecture should have at least one function for which it is responsible; otherwise, that element is without purpose.
Influential functional requirements make for a great checklist when assigning responsibilities to elements. One approach for identifying responsibilities is to model the system with component responsibility collaborator cards as described.