Just before we dive into architecture diagrams for our kata, I want to take a little time to look at the types of information you find in most kata descriptions
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“. 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.
Inside the Kata description
Depending on how much you want to “get into character” as you work through a kata, there are usually a number of leads in each description, just like in any good detective story. Some of these leads might end up in dead ends, which neither deepen your understanding of the problem nor impact the architectural solution. However, others might suggest nuance and detail which help guide your hand when making the inevitable trade-offs that separate capable architects from the rest.
This article tries to find and pull on some of these background threads. I’m going to ask a lot of questions but answer very few of them. I’ll leave you, dear reader, to resolve these questions in a way that allows you to maintain a consistent context for your solution.
These are the key threads I’ve tended to think about when looking at the BLT kata over the years…
“national sandwich shop”
The food retail industry contains businesses that live-or-die on a high volume/low margin business model. Staff tend to be relatively lowly paid, but salaries will still be the biggest components of the businesses operational expenditure. Given food wastes quickly, stock control is critical to maximizing yield (i.e., making the best use of the stock with minimal waste) and keeping costs down. Such price conscious businesses will not have the ability to incur massive IT costs for new systems which suggests subscription-based IT services to amortise costs across a wider period.
Because sandwiches tend to consumed primarily at lunchtime (by the Australian definition and consumption of “sandwich” at least), this suggests opening hours are limited (business hours only?) and high availability might not be a key cross-functional requirement for in-store components of the solution.
‘fax in your order’
Possibly a red-herring, but could also speak to relatively low technical literacy (and maturity of IT systems) within the business. This would impact the design of system errors, fault tolerance and recovery, especially for the in-store components.
Understanding the key business drivers behind a system is critical to making appropriate trade-off decisions in architecture. What is driving the customer to this solution?
- Can they see their customer base moving to competitors because they don’t support online ordering?
- Is this part of a strategic uplift of the organisation in advance of expanding overseas, or possibly being purchased?
- Are services like UberEats disintermediating their market?
- If they do actually rely on physical faxes in stores, are there current or future hardware cost/support/availability issues?
- Will having an online solution lead to a better ability to understand their customers and therefore provide more tailored solutions?
Depending on how you answer and weigh these questions could have a significant impact on your solution.
“current fax-in service”
We’ve already considered this phrase to some degree in our business processes by assuming the existence of a Docket Printer in each store, but we should also think of what other current IT services we might need to consider and possibly integrate with. You could assume there wont be many such systems in stores (given the reliance on fax), but – if we hadn’t de-scoped Stock Management from our solution previously – we could have some significant integration requirements within the parent company IT infrastructure.
“Users: thousands, perhaps one day millions”
This statement is almost completely unhelpful without providing some more specific predictions such as orders/day, sandwiches/order or concurrent orders, but there’s nothing in this statement that suggests throughput or data storage volumes will be anything significant in the final solution. Even the caveat of “perhaps one day millions” sounds like the wishful thinking of a company executive and shouldn’t constrain our architectural thinking at this time.
“be given a time to pick up their sandwich”
This is a possible rabbit hole of a requirement. At the simplest level, you could hard-code a fixed period to prepare the sandwich, possibly with an increased delay for known peak periods. At the other end of the complexity spectrum, the System could be provided with current data around the throughput of the store based on number of incoming orders (online, fax and presumably walk-ups), and provide the Customer with a highly accurate estimate of the pickup time.
Because of the additional integration complexity around the latter solution, this would be a requirement I would strongly argue is not worth the time to implement, at least in the initial version of the solution.
“integrate with several external mapping services”
Hmmm, what do we make of this? Firstly, it suggests our Customer is using a mobile platform to navigate their way towards the shop, but given there’s no other mobile-specific requirement for customers, I’d err on interpreting this requirement to mean “we’ll add a link to the store address that you can use to navigate to Google Maps, or your relevant GIS provider.
This does lead to a consideration around the ordering process… does the Customer choose their store explicitly when they order, or do they order and provide their address, and then the order is routed to the appropriate store?
“if the shop offers a delivery service”
I’ve seen so many teams spend a disproportionate amount of time solving the delivery service integration… which is not even provided at each store! It would be nice to know what percentage of stores have a delivery service and how dynamic this number is to help understand how significant these requirements are. Is the company tending towards more delivery services in stores, or are they a holdover from a previous version of the business and being phased out?
“Sandwich shops are franchised, each with a different owner.”
If you understand how franchise models operate in retail (and I have enough knowledge to be dangerous), then there are significant architectural implications behind this statement. Franchise owners generally have very little choice over how their store operates; pricing, stock, menu, etc are all usually contractually owned and operated by the parent company. Similarly, IT infrastructure is usually a parent company responsibility.
What is less clear to me is who owns customer data if we build a solution that has the ability to create a strong sense of customer identity. If our solution eventually provides customer accounts and tracks customer order history, loyalty schemes and other customer-based promotions, then how is this data safely and securely stored, both away from the prying eyes of the general public, but also from other franchisees, who are effectively competing with each other for the same customer base?
“near-future plans to expand overseas”
With my architecture hat on, I’m loathe to ignore requirements that suggest a solution requiring internationalisation, but I’m even more reluctant to bake these assumptions into the initial solution which has yet to be built, let alone proven successful.
Operating in different markets implies:
- support for different currencies
- very likely different tax calculations
- integration to different Payment Gateway solutions
- local menu variations (either due to stock variations or customer demand)
- local promotion variations
- local visual design standards/expectations
- possible extended character sets needed for text display and even layout (e.g., right-to-left rendering)
- regional hosting restrictions (e.g., data sovereignty and specific laws like GDPR)
With such a large number of variations across so many significant architectural axes, I’m tempted to file this requirement in the “we’ll cross that bridge when we come to it” bucket and rely on general good design/abstraction practices to leave the initial solution open to future evolution.
“Corporate goal is to hire inexpensive labour to maximize profit.”
Somewhere in my kata journey, I can across the term Architecturally Significant Requirement… this is not one of those. I cannot imagine how I would approach this solution differently irrespective of the existence of this statement. You could argue that ease-of-use needs are highlighted by this statement, but I don’t think there’s anything compelling here to elevate those requirements above what you would normally do for any other retail food business.
If I’m being picky, it doesn’t sound like a corporate goal either 🙂
So we’ve trawled through the kata description and found a number of red herrings and statements that appeared significant on the surface but ended up being too vague to be helpful. We also found some more useful clues to the context for the solution and added a number of extra unanswered questions we’ll need to consider in subsequent articles.
The next article will use the C4 diagram model to define a high level view of the implementation of the System.
Did you find this article useful/interesting?