Metaphor and Mitosis

17 August 2012

On a recent project we used metaphors to help convey information about the system we were building, among our relatively small team.

The software was a run of the mill E-Commerce affair, featuring examples of customers purchasing products. There were rules effecting the sale of products, depending on certain properties of the customer, among other things.

After initial discussion with the designers, business people and information architects, we settled on the metaphor of customers taking a journey, guided through an online store, down a number of paths to purchase items. The items available for purchase along the journey depended on the customer, and their relationship with the business. Eventually, all journeys concluded at checkout, where external fulfilment systems provision the customer with their goods and services.

Initially, we started with a small team, working on a code base containing the usual suspects for building an online shop: An MVC application and a database.

After a few sprints the team was split into two, due to a desire to reuse the persistence part of the application across other business software. The metaphor (not fully explored) for the persistence layer emerged as a product catalogue; the canonical source of information for products sold by the business.

While we explored the guided journey metaphor, we neglected the product catalogue and allowed our understanding of layered software architecture to drive many design decisions: By thinking in terms of a service oriented architecture, we ended up building a horizontal slice (the database and REST API), and a single dumb client (the web application), that basically rendered JSON responses from the catalogue. The business logic for guiding a customer on their purchasing journey lived only in the horizontal product catalogue layer.

The metaphor was strained and unclear at this point and tension was building as we struggled to ignore the elephant in the room: the second client of the product catalogue service.

A third team started work on the second client of the product catalogue: An agent facing version of the online shop, designed to allow a sales representative to assist a customer with their shopping over the phone, in real-time. We quickly learnt that sales agents can deviate from the guided journey that the customer would be required to follow. In fact, the sales agents could bend our carefully constructed rules so much, that the API and business logic of the product catalogue was almost totally unsuitable for the agent-facing shop team to work with.

The product catalogue team attempted to meet the demands of these wildly different clients by declaring bankruptcy on their existing API and pushing more of the business logic out to the consumers. They reduced their responsibilities and went back to being a much simpler persistence layer, with a more generic search and purchase API.

All of the business logic for the guided journey now needed a new home. Some of it moved back into the client facing shop. Some of it moved to the agent facing shop. The common pieces of logic started moving towards a third system, to be shared by the two clients. For practical purposes, the two teams shared the code and started moving it into its own code base.

Throughout the project we felt the frustration of a metaphor that just didn’t seem to work. We spent a lot of time talking through the metaphor of the guided journey, without ever really reaping the benefit we felt it deserved. The reason for this, only became clear to me after recent conversations with Antony and Andy.

Instead of trying to stretch the edges of the guided journey metaphor past the point of usefulness, we should have embraced that pain and realised that a system can be usefully described by multiple metaphors. Had we recognised the product catalogue and the guided journey were overlapping but separate metaphors, we may have foreseen the problems caused by the next client of the product catalogue.

The agent facing shop, I have since recognised, could have used any number of interesting metaphors that ran parallel to the others. For example, what if the agents were super heroes, who were not bound by the same restrictions that mere mortal customers were? What if the world the super heroes and the regular people shared had emerged as a set of basic physical laws (a force like gravity; or a force like having to exchange money for products and services)?

If we had recognised the points where our metaphor was strained, and explored new metaphors as separate but overlapping things, perhaps we would have split our teams and systems differently; separating concerns and building a more flexible, emergent architecture.

Before this project, I appreciated that a metaphor can be a powerful carrier of information between small groups of people. I now believe that if we recognise a metaphor breaking down as a signal to split the system; a sort of ‘system mitosis’, splitting our existing architecture into naturally occurring interdependent systems. Together these systems, and their metaphors, convey a holistic story, and history, of their world in their own words.