| Of course, software fortresses work well only if your overall design is sound. What are the most important design rules for a software fortress architecture? Here are my top ten: -
At the enterprise level, focus on treaties . Use treaty “ally “responsibility (TAR) cards to get an overview of which fortresses play which parts in which treaties. Pay close attention to the sequence “ally diagrams (SADs), which are very helpful for gaining an understanding of how fortresses will work together and for identifying performance problems. -
Define fortresses with the right amount of granularity. If you have thousands of fortresses, you have most likely confused fortresses with components , or even worse , with objects. If you have only one fortress in a thousand-person organization, you have probably confused fortresses with enterprises . A good rule of thumb is one fortress for every 20 to 50 employees , and one for every purchased system. -
Look carefully at your walls. There should be only one possible way into a fortress: through a secured drawbridge. Firewalls, database security, role-based security, and access control lists are some of the technologies you can use to reinforce your fortress walls. You should also run your fortresses on stripped-down systems. Every unnecessary feature of the operating system is a potentially forgotten passageway into your fortress. Use as many layers of protection as you need to defeat likely intruders who are knocking against your fortress walls looking for weak spots. Make sure nobody can get into the fortress except through a drawbridge. -
Look carefully at your guards . If your walls are working well, then your guards are your last defense against the miscreants of the world. Ask yourself these questions: -
How do you know an infogram is coming from where you think it's coming from? -
Could somebody have read or tampered with an infogram en route? -
Could somebody have captured an infogram en route, and then replay it later? -
Might you be called upon later to prove that you really did receive an infogram that the sender denies having sent? Put your best security specialists on guard design and implementation. -
Make sure nobody can exit the fortress except through an envoy. Envoys protect the internal fortress workers from becoming entangled in the sometimes complex details of preparing infograms and placing them on drawbridges. Envoys also protect the fortress workers from inevitable changes in the drawbridges . -
Design infograms to be resilient. Some drawbridges, such as those based on message queues, have reliable delivery. Others, such as those based on HTTP, have unreliable delivery. Even the most reliable drawbridges cannot protect against implementation failures in the receiving fortress. The best protection against interfortress communications anomalies is designing the infograms to be highly resilient. A resilient infogram is one that, without causing problems, can be sent over and over again (i.e., is idempotent) and can be received in any order (i.e., is communicative). -
Design your fortresses to scale. My preference is to use a scale-out design for everything I can in the fortress. A scale-out design is based on loosely connected clusters of small, cheap machines. I like such clusters because they give an excellent cost/performance ratio and provide high reliability. The one part of the fortress that typically does not scale out is the data strongbox, especially when it is implemented with a database. Fortunately, through proper fortress granularity, careful state management, and judicious use of stored procedures, we can minimize the need to scale the data strongbox at all. -
Use only loosely coupled transactions across fortresses. Keep in mind that a loosely coupled transaction is not much of a transaction at all. It is really just some kind of an agreement between two or more fortresses to let each other know if their portion of the treaty workload failed. Usually this agreement is mediated by an independent body, either a treaty management fortress or a specialized service fortress that might be called a compensatory transaction manager or a business transaction manager. -
Use tightly coupled transactions only within the fortress. A tightly coupled transaction is a "real" transaction, one that involves absolute guarantees by the various transactional resources that they will either all commit or all roll back. This agreement is mediated by a distributed transaction coordinator (DTC). To make this guarantee, the resources typically need to maintain locks. We never allow a resource outside our fortress to determine when, if, and for how long we will hold resource locks. Therefore, distributed transaction coordinators are not shared across fortresses; they live strictly within only one fortress. Tightly coupled transactions are relevant mostly within business application fortresses. Such fortresses are typically implemented with component technology, either COM+ in the Microsoft space or Enterprise JavaBeans in the Java space. Both technologies provide automatic transaction boundary management algorithms that help considerably in building well-behaved components. -
Use asynchronous drawbridges wherever possible. Asynchronous drawbridges provide workflow averaging, nonblocking workflow, and high reliability. Where you absolutely can't use an asynchronous drawbridge, then at least back up the synchronous drawbridge with an internal asynchronous rerouting as quickly as possible. |
