, , , , , , , ,

Each role you’ve identified from your kata description should have a set of responsibilities associated with it. Identifying these responsibilities will be the basis of the requirements driving the solution.


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:

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.


The Role/Responsibility relationship

In the last article, we landed on this set of roles in the system:

  • 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)

A logical way of checking whether we’ve found all the necessary roles is to go back to the kata description and extract all the implied and assumed responsibilities for the people using the solution.

If we find responsibilities that don’t logically belong with any role (i.e., something to be done but no-one to do it), maybe we’ve missed a role that needs to be added.

If we have a role we cannot associate any responsibility with (i.e., someone who exists but with nothing to do), maybe we’ve found a role that actually doesn’t have any interaction with the system at all.

Identifying Responsibilities

How you go about identifying responsibilities is largely up to you. I’ve captured my thoughts in the table below. It’s typical at this point to start making more assumptions about how the proposed solution will work. These assumptions provide some context/boundaries for these responsibilities.

Let’s look at the responsibilities and then I’ll talk about the assumptions.

Customer– Place order with Cashier
– Pay for order to Cashier
– Travel to store
– Customer identity via order # only
– No change to payment systems
Cashier– Accept order from Customer
– Accept payment from Customer
– Print order for Customer
– No change to current in-store ordering process
Sandwich Hand– Receive order from Cashier
– Prepare sandwich
– Handover sandwich to Cashier
– No change to current in-store ordering process
Driver– Pickup order from Cashier
– Deliver order to Customer
– Accept payment from Customer
– Works only for single Franchise Owner
– Cash only payments from Customer upon delivery
Franchise Owner– Manage local promotions/specials
– Manage Driver(s) (if any)
– Stock management out-of-scope
Marketing– Manage national promotions/specials– Stock management out-of-scope
Roles & responsibilities

One BIG assumption I’ve made here is de-scoping stock management. Stock management is an entire business domain in itself, so I’m partially motivated by laziness and simplicity but also because it seems tangential to the core of the kata. With a large enough chain of sandwich shops (think Subway), stock management would likely be integrated into promotions (e.g., specials on sandwiches using ingredients that are need to be moved quickly).

A secondary key assumption regards no permanent notion of customer identity. The customer is identified only via their order number. Therefore, there is no need for the customer to create an account and login, which helpfully removes the need for lots of administrative functionality around user management (e.g., password resets, forgotten passwords, etc). This assumption relies on the existing payment infrastructure being able to handle an anonymous payment, which seems like a reasonable expectation.

Hopefully you would come up with a similar set of responsibilities for this kata as well. As I mentioned before, I suspect most of us have physically ordered food for in-store collection or delivery, so there shouldn’t be anything too foreign about this – not all kata are as broadly approachable however.

Next Steps

These roles reference each other quite heavily, but we don’t have a good sense of the natural business processes that the system supports. My table of responsibilities don’t talk about the order of these activities or how the responsibilities interrelate. In fact, my table doesn’t even recognize the existence of a System role, which handles much of the intermediary responsibilities between the human roles. This gap will be covered in the next article where we identify key business processes that the solution needs to support.

Did you find this article useful/interesting?

Rating: 1 out of 5.