14.3 Second-Pass Design


My SADs are starting to make me a little nervous. A lot of interfortress communication seems to be going on, especially for the ProcessOrder treaty. I know that interfortress communication is expensive. Even though I notice that most of the communication uses asynchronous drawbridges , which is good, the sheer volume of it is starting to seem overwhelming. I am starting to wonder if I can consolidate my fortresses .

My starting point for possible fortress consolidation is to notice which fortresses are involved in which treaties. Fortresses that are used within only a single treaty are good candidates for consolidation, although there may still be organizational reasons for keeping them separate. Table 14.1 shows an analysis of which fortresses are used within which treaties .

Table 14.1. Treaty/Fortress Relationships

Fortress

Treaty

ProcessOrder

CheckInventory

CustomerGateway

X

 

VendorGateway

 

X

OrderManagement

X

 

Customer

X

 

Inventory

X

X

Shipping

X

 

CreditCardProcessing

X

 

VendorInventoryCheck

 

X

Security

 

X

This analysis indicates that the Inventory fortress is the only fortress that is used in both treaties. Because inventory management seems very organizationally specialized and because the functionality is needed by both treaties, it seems reasonable to keep it a separate fortress. I decide to collapse the remaining treaty fortresses as much as possible while still maintaining my security buffer for the untrusted browsers and SOAP requests .

In my next pass I decide to consolidate the Customer, Shipping, and CreditCardProcessing fortresses into the OrderManagement fortress. Because OrderManagement is no longer orchestrating other fortresses as much as taking over their functionality, I change its type from treaty management (TMF) to business application (BAF). I similarly consolidate Security into VendorInventoryCheck because Security is used only to process a vendor request.

After this consolidation, I can redraw my FAD as shown in Figure 14.4. Notice how much simpler things are starting to look!

Figure 14.4. Simplified FAD

Breaking up the new FAD into the two enterprise treaties gives us the TADs (treaty “ally diagrams) shown in Figures 14.5 and 14.6. Each treaty now seems quite manageable.

Figure 14.5. TAD for ProcessOrder

Figure 14.6. TAD for CheckInventory

My official fortress count is now down to five: CustomerGateway (PF), OrderManagement (BAF), Inventory (BAF), VendorGateway (WSF), and VendorInventoryCheck (BAF). Creating fortress “ally “responsibility (FAR) cards will give me a handle on the major functions of each. The FAR cards for all of these fortresses are shown in Figure 14.7.

Figure 14.7. FAR Cards

In a very high-level treaty overview, we can also look at the treaty “ally “responsibility (TAR) cards, which are shown in Figure 14.8.

Figure 14.8. High-Level TAR Cards



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