8.1 A Treaty between Two Fortresses


8.1 A Treaty between Two Fortresses

My 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:

  1. The Roger fortress (that's me) verbally places the order. The order has four components : item (macchiato), size (doppio), quantity (one), and frills (one brown sugar and extra foam). Note that only two of these (item and size) are defined by the menu.

  2. The Starbucks fortress verbally tells the Roger fortress how much money is owed. This is essentially an error control mechanism. The Roger fortress (having ordered thousands of doppio macchiatos) knows exactly what the cost should be ($1.87). If the Starbucks fortress responds with any other price, the Roger fortress will go into error correction mode.

  3. The Roger fortress authorizes a payment from his American Express account. To prove that he has the right to authorize the payment, he hands over an American Express credit card.

  4. The Starbucks fortress verifies that the American Express card is valid and then returns it and a receipt to the Roger fortress.

  5. The Roger fortress verifies that the amount on the receipt is accurate and signs it. His signature can later be used to prove that he has seen and accepted the amount of the debit, should he try to deny it.

  6. The order is delivered.

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.



Software Fortresses. Modeling Enterprise Architectures
Software Fortresses: Modeling Enterprise Architectures
ISBN: 0321166086
EAN: 2147483647
Year: 2003
Pages: 114

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net