Learning with Architecture Kata: Roles

A nice launch into the world of Architecture Kata is identifying the roles interacting with the solution. Sometimes these roles will be obvious. Sometimes they're hidden within the description and take some digging to discover.

Background

This is part of a series of articles about how I use Architecture Kata as a capability building exercise and a recruitment tool at ThoughtWorks.

Here are the previous articles in the series:

• Introduction

All these articles will be focused on the same kata; "I'll Have the BLT". See below for the description for this kata. I've chosen this one because it's in a domain (retail and food ordering/delivery) that most people have some innate understanding of, from either a consumer and/or employee perspective.

http://nealford.com/katas/kata?id=BLT

Note: If this is the first time you've looked at a kata description in detail, you will have as many questions as answers. This is deliberate: these kata are not intended to be exhaustively detailed requirements. They are merely brief descriptions of a problem. And without a human to add more context to the problem, you'll need to make lots of assumptions to fill out the missing pieces of the puzzle.

Identifying Roles

The first step in our journey is to find the user or system roles implied by the problem description.

So what are the roles that immediately jump out from the description?

• User

• Driver

• Franchise owner

Is that all? No, there's a couple of issues with this initial list:

Firstly, let's talk about Customer as a more specific form of User, because there are invariably other users of the system apart from those who are the people buying sandwiches.

It also occurs to me that the person placing the order need not be the same person physically picking up or receiving the delivery (i.e., separate Sandwich Orderer and Sandwich Recipient roles). This distinction may not be relevant in the long term, so we'll just store this in the back of our mind for now.

Reading between the lines, there are a few other human roles as well: the promotions are at national and local level and given the franchise model, that implies separate roles to create these offers. We'll work on good names for these roles soon.

Looking at the in-store customer interactions, there are roles required to receive payments from the Customer and actually make the sandwiches. Very likely this roles are shared across the same people, but let's keep them separate for now.

So the second version of our roles looks like:

• Customer User

• Driver

• Franchise Owner (also responsible for local promotions)

• Marketing (for national promotions)

• Cashier (for receiving in-store payment)

• Sandwich Hand (for making sandwiches)

Next Steps

In the next article, we'll identify the specific responsibilities for each of these roles. We also want to be open to discovering more roles as we go through the subsequent steps. Our current list is a good start, but - as our understanding deepens and we concentrate on more detailed business processes - we might spot some roles we missed on this first pass.

These roles will also make an appearance on our architecture diagrams. I'll be using the C4 model where roles are shown on Level 1 Context diagrams.