, , , , , , , ,

Systems exist to enable, optimise or support business processes. So far with our kata, we have created isolated sets of responsibilities for our roles/actors, but there’s nothing to piece them together into these valuable processes… yet.


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.


From responsibilities to business processes

Below are the responsibilities we created in the previous exercise…

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


If you join up these responsibilities, the underlying business process flow starts to emerge. I’ve produced some UML Sequence diagrams below for the primary ordering flows for this kata (i.e., for delivery and for in-store pickup). I like sequence diagrams because they clearly show the various roles/actors involved in process, but you could also use swim-lane diagrams, which have a similar focus but opposite orientation.

Note: there are a few new actors in these diagrams that we haven’t spoken of previously:

  • System – a very unimaginative name for the solution we’ll be building. Will this be implemented as a single application, or multiple ones? We don’t know yet – those decisions will be made later.
  • Docket Printer – this is part of the existing IT infrastructure I’ve assumed exists at all stores. This docket printer is connected to the current PoS (Point of Sale) hardware and prints the order details which become the physical copy of the order for the Sandwich Maker.
  • Payment Gateway – a 3rd party hosted solution allowing customers to make online payments using credit cards and notify the store of a successful payment. I’ve shown its use only for a single process below, but it applies to both ordering processes.


What about the business processes for the local and national promotions responsibilities we identified? Well, they certainly need to be supported by our solution, but I’m going to leave them out of scope for now. In my mind, I see promotions processes being largely identical to each other and centred around only a single role (Franchise Owner and Marketing respectively) with only limited integration with the System actor in terms of displaying the menu for the Customer.

Note: If there were some very tricky or specific requirements around how promotions are done (e.g., reliant on current stock levels or a firmer notion of Customer identity or previous buying behaviour), I might do some process mapping for promotions as well.

Next Steps

Before we get to the next steps, we should ask ourselves: are there any key risks in our thinking around the solution so far?

  • We haven’t described how the new System will integrate with the existing PoS systems. Do we now have two records of orders for a single store, depending on whether the order originated online or in-store? Or will the Docket Printer serve as the authoritative source of truth?
  • For customers wanting delivery, we haven’t identified a process to allow them to pay the driver electronically… is it reasonable for the driver to only accept cash on delivery?
  • If our Docket Printer fails to print the order, how will this situation be detected. Can the Docket Printer send a signal to the System? How will the Cashier be alerted to this situation? As a general note, the processes I’ve drawn show the happy path only.

Let’s sleep on these questions for now and see whether we have good answers for them by the end of the kata.

The next article will use the C4 diagram model to define a high level view of the implementation of the System. We’ll be making some more assumptions around the nature of the business we’re building this system for to confidently trade-off between various architectural qualities in our solution.

Did you find this article useful/interesting?

Rating: 1 out of 5.