8.1 A Treaty between Two FortressesMy morning usually starts at my local Starbucks. I am often there at 5:30 A.M. In fact, I am often there earlier, but until 5:30 A.M. , I am forced to sit outside looking pitiful. When I get in, I need my doppio macchiato, I need it bad, and I need it made without mistakes. Thinking of Starbucks in terms of fortresses, the counter forms a natural boundary between me and the Starbucks corporation. Starbucks is one self-contained fortress, and I am another. We interact across the counter. Each interaction goes through a drawbridge, and the sequence of interactions is defined by a treaty. I'll call this treaty the Purchase treaty. Because both Starbucks and I are self-contained fortresses, we don't ask each other a lot of stupid questions. Starbucks doesn't ask me how I got the money I am about to hand over. I don't ask Starbucks who fixes the espresso machine. Our relationship is simple. They want my money; I want their doppios. As we look more closely at the interactions between Starbucks and me that are needed to fulfill the requirements of the Purchase treaty, we see a carefully orchestrated dance . If any one of the interactions fails, the relationship disintegrates. Let's go through the different moves. First is the order interaction. This interaction is followed soon (hopefully) by the delivery interaction. Several other possible interactions have to do mostly with error control. The order interaction can be divided into these lower-level interactions:
It is worth taking a look at the overall asynchronicity of this system. Recall from Chapter 6 (Asynchronous Drawbridges ) that we always want our interfortress interactions (as opposed to intrafortress interactions) to be as asynchronous as possible. Asynchronous interactions are more reliable, easier for balancing workload, and naturally amenable to workflow averaging. Synchronous interactions, in contrast, are generally unreliable, difficult for balancing workload, and downright hostile to workflow averaging. How much of the Purchase treaty is being done asynchronously? I have identified six discrete interactions between the Roger and Starbucks fortresses, not including error control. Each one of these will require a dedicated drawbridge. A sequenceally diagram (SAD) for our current version of the Purchase treaty is shown in Figure 8.1. Figure 8.1. SAD for Purchase Treaty
Five of the six interactions between the Roger and Starbucks fortresses are synchronous. And this doesn't include error handling. This is not a good situation. But what are we to do? We are forced into these synchronous flows by the nature of our drawbridge designs. This treaty analysis has pointed out some weaknesses in our drawbridge design, as is typical of software fortress architectures. The design of the treaty reveals drawbridge weaknesses and forces further work in the design of the drawbridges. Once the draw bridges have been redesigned, the treaty is reconsidered and may point out new problems in the drawbridges. Let's redesign the Starbucks fortress so that all of the synchronous interactions are collapsed into a single megainteraction, preferably an asynchronous one. To do this, we replace the human interaction at the counter with a stack of order forms. To order my doppio macchiato, I grab an order from, fill it out, throw my payment in the payment envelope, and hand it to the counter person. Figure 8.2 shows an example of such an order form. Figure 8.2. The New Improved Starbucks Order Form
We can even throw in error management at a low cost by creating another drawbridge for the Starbucks fortress (one designed to accept complaints) and another formsay, the one shown in Figure 8.3. Figure 8.3. The New Improved Starbucks Error Form
Notice in Figure 8.4 how much simpler the SAD has become, even with error management thrown in! Figure 8.4. The New Improved SAD
Of course, I don't expect Starbucks actually to implement this new system. The folks at Starbucks probably think we all want the warm and fuzzy face-to-face experience. But if this system were implemented, you wouldn't ever have to wait on another around-the-block Starbucks line. You could simply walk into the Starbucks, hand in your form, sit down, relax, read the paper, and wait for your coffee to appear. Maybe warm and fuzzy is overrated! Several intrafortress events probably will occur within the boundaries of the Purchase treaty. For example, the Starbucks fortress will probably debit Roger's American Express account. It will probably do so in a transactionally protected manner. The order will probably initiate a request from the cashier guard to the espresso machine worker. None of these events, however, are relevant to anybody but those implementing the Starbucks fortress. Similarly, the Roger fortress may drink the macchiato on the spot or in his car. He may add more sugar, add chocolate, dump it into a thermos, throw it away, or give it to the next person he sees on the street holding a "will work for doppio macchiatos sign." None of these are the concern of the Starbucks fortress. It got what it wanted from the collaborationnamely, a buck eighty-seven. |