An architect’s primary job is to identify architectural components from requirements. Components are the building blocks of a system and depending on the architecture style, they may be a physical group of modules or an independent unit of architecture like in microservices. Knowing what components a system needs and how they interact is important for the success of the architecture.
We’ll use requirements from an exercise in Software Architecture Fundamentals. I have omitted parts that are not relevant for our purposes.
A national sandwich shop want to enable ‘fax in your order’ but over the internet instead (in addition to their current fax-in service)
- Users will place their order, then be given a time to pick up their sandwich and directions to the shop (which must integrate with several external mapping services that include traffic information)
- If the shop offers a delivery service, dispatch the driver with the sandwich and directions to the user.
- Mobile-device accessibility
- Offer national daily promotions/specials
- Offer local daily promotions/specials
- Accept payment online or in person/on delivery
Now that we have a set of requirements, we can start mining for components. The diagram below gives an overview of the component identification flow.
Identify Initial Components
There are a number of approaches to identifying components. With a workflow approach components are identified from the activities users do to achieve their goal and in an actor/actions approach components are discovered from the actions actors do in the system. We will use the actors/actions approach.
The first actor in our system is the customer. A customer performs the following actions.
- Purchase a sandwich
- Select a promotion
- Make payments
From these core functionalities we can tell that we’ll need a Purchase, Promotion and Payment components.
The second actor will be the sandwich shop, which does the following
- Accepts payment
- Offers promotions
- Adding/removing items from the inventory
- Delivers sandwiches
Given these core requirements, we will need an Inventory and Delivery components in addition to the components we had earlier.
With the actor/actions approach there’s always an element of the system. So it will be our third actor and it does the following
- Show order status
- Notify users when an order is ready
For these functionalities, we’ll need an OrderTracking and Notification components.
By focusing on the system’s core requirements we have identified the following components: Purchase, Promotion, Payment, Inventory, OrderTracking and Delivery.
It’s important to note that identifying components around entities is a common anti-pattern known as entity trap. It happens when an architect identifies database relationships as workflows.
Assigning Requirements to Components
The next step is to assign user stories or requirements to these components. Whenever a component is doing too much it is broken down further to two or more components. However, it might be the case that a component is doing too little, in that case it is consolidated with another component.
Analyze Roles and Responsibilities
Roles and responsibility of a component are analyzed to ensure component and domain granularity matches.
Analyze Architecture Characteristics
Architecture characteristics impact component division and granularity. For example, while two parts of a system might deal with user input, the part that deals with hundreds of concurrent users will have different architecture characteristics from the part that deals with only a few users. Leading to further subdivision.
Software architecture is an iterative process. As we design the architecture we learn of what were unknown unknowns forcing us to go back to the drawing board — pun intended — and restructure our components. Thus, an iterative approach is key.
Component identification from requirements is a critical step in the software architecture process.
Expections Of An Architect
An architect’s primary job is to identify architectural components from requirements....