15.4 Ten Controversial Ideas within the Software Fortress Model

15.4 Ten Controversial Ideas within the Software Fortress Model

As I write this, the basic ideas of the software fortress model have been presented in person to thousands of managers, architects , and developers and in writing to tens of thousands more. The acceptance of the model is enthusiastic. However, I have noticed that certain questions, uncertainties, and controversies seem to pop up over and over. This is probably a good place to deal with them. Here are the most common ten:

1. Performance doesn't count. I have stated in this book several times that performance doesn't count. I have made this statement in two contexts: (1) drawbridge performance and (2) overall fortress performance.

   In the context of drawbridges , the cost of transporting an infogram is generally white noise in the background. Or at least it will be, if everything else has been well designed. Consider a donor fortress D working with an allied recipient fortress R. If D needs to work with R, it should make a very small number (preferably a number that looks a lot like one ) of infogram requests , so the cost of transporting those infograms should be small compared to the work R will be performing once the infograms have been received. If R does very little work after receiving the infogram, or if D needs to send many infograms to get its workload processed , then one of these issues, and not the cost of transporting a single infogram, will be the performance problem.

   In the context of fortresses , performance does count, but not as much as overall design. In my experience, implementors are notoriously unreliable when it comes to predicting performance problems. They often spend a great deal of time trying to optimize areas that ultimately make little or no difference to overall fortress performance. In a business application fortress, for example, overall performance will be dominated by the cost of the distributed transaction coordination, so trying to optimize a variable in a for loop is almost certainly a waste of time. Implementors are generally better off building with only minimal regard to performance, and then looking for bottlenecks and fixing them after the fact. These bottlenecks are almost never where they would have been predicted .

2. Put security only in the guard. The idea of putting security only in the guard runs counterintuitive among people who have been trained to build security in depth, meaning to build it into every layer of a system. In fact, building security everywhere is the same thing as building security nowhere.

   Very few developers have the skills necessary to manage security well. You are lucky if you have a few developers who really understand the issues of security. This is not to malign the typical developer. It is just that security is a very complex issue, and the typical developer has enough to keep track of just building a good business application or browser interface.

   Security is a specialized area. By putting security in the guard (and only the guard) we can be sure that nothing arrives in the fortress that has not been subjected to the most rigorous inspection. Should your fortress find itself under a new attack, one not anticipated in your initial design, you have only one place you need to go to deal with the situation. Should security requirements change (say, auditing is suddenly required), you can add it in one location and have it enabled for the entire fortress.

3. Organizational boundaries are related to fortress boundaries. Some people question my supposition that the software fortress boundary should in some way reflect organizational boundaries within the enterprise. They point out that organizational boundaries tend to shift over time.

   In my experience, fortress responsibilities tend to shift en masse when organizations are reorganized. In any case, I don't consider alignment of organizational and fortress boundaries to be an absolute rule; it's just that organizational boundaries tend to be natural trust boundaries, and it is usually most natural if the two boundaries (organizational and technical) align.

4. Tightly coupled transactions shouldn't cross fortress boundaries. As I write this, there are two significant efforts under way to standardize Web service transactions. One of these is sponsored by Microsoft, IBM, and BEA, and in their proposal, they suggest that tightly coupled transactions should be allowed to travel over SOAP. Within the context of a software fortress architecture, the implication is that these companies believe that tightly coupled transactions should be allowed to cross fortress boundaries.

   The only reason I can imagine enabling such functionality would be to allow different technology bases (such as Java's J2EE and Microsoft's .NET) to work within the same tightly coupled transaction. However, it is highly unlikely that J2EE and .NET would coexist in the same fortress. I am in favor of using both, but not in favor of mixing them in the same fortress. Assuming that we will have only one technology within a fortress, there is no reason to carry tightly coupled transactions over SOAP. SOAP is strictly a heterogeneous drawbridge technology.

   Some unusual situations might be able to take advantage of tightly coupled transactions over Web services. However, I believe that the potential danger is much greater than the potential benefit. In my view, this proposal is fatally flawed. Hopefully by the time you read this, the only transactions that will be widely accepted over SOAP will be the loosely coupled variety.

5. We need fortresses within fortresses. Some people have suggested that they would like to use a construct of a fortress within a fortress. This idea can also be described as allowing recursive fortresses, an approach that seems to be particularly attractive to the academic community. I see this concept as a variant of the argument that we shouldn't put all of our security eggs in the guard basket . The reason for allowing fortress recursion would be to allow many layers of security. My arguments in favor of single security focal points also argue against allowing recursive fortresses. I realize this idea is controversial, but as yet I have not seen a compelling case for allowing fortress recursion.

6. The software fortress model should always be used. Some people argue that, for many software enterprises , the software fortress model is overkill. I agree. I see this model as applicable to large enterprise systems, such as at banks, investment houses , or insurance companies, typically built by at least hundreds of different developers. However, I have been surprised by the number of people who see this model as offering value to software enterprises for which I had never envisioned using it. For example, the military establishment seems drawn to the basic fortress security model. So this model may gradually become more widely used than I had envisioned , but I can't imagine that it will ever be used to the ubiquitous extent, say, of object-oriented programming.

7. Turn off database security. Turn off database security? What, are you crazy? OK, if it will make you feel better, we don't really turn off database security; we use it only as a way of reinforcing the fortress walls, of making sure that outside processes are not allowed to access the database. Database security was designed for client “server systems. It didn't work for three- tier architectures. It doesn't work for software fortress architectures.

8. Don't share databases across fortresses. This is a tough one because large companies have shown somewhat of a trend to consolidate all database operations into a single group and to think of data as a corporate resource. I still prefer the architecture in which each fortress owns its own data.

   There are several possible compromise positions . One is that the database is centrally owned but partitioned so that each partition is controlled by one fortress. Another compromise is that we use another service fortress, one that is a consolidated data storage fortress. This is definitely an area where some may feel the need to make adjustments to the software fortress model.

9. Give scale-out priority over scale-up . Many organizations have found that managing clusters of small machines is more difficult than managing a small number of large machines. I still prefer the scale-out approach because of the reliability gains. However, many organizations find that they get great reliability using scale-up. In any case, I don't consider the choice of scale-up versus scale-out an essential feature of the model.

10. The model hasn't been proven. Some people object to the software fortress model on the basis that it hasn't been proven. This is true. The model is still very young. However, I would point out that some critical features of the model have been proven, albeit in different contexts. For example,

    • The idea that database centric security does not work has been known for two decades, since the advent of transaction processing monitors .

    • The idea that asynchronous communications can provide workflow averaging, nonblocking workflow, and high reliability has been known since message queues were first released.

    I would also mention that although this model has not been proven, it doesn't exactly have any competition. What are you going to do? Surely you have figured out that what you're doing now is not working! And nobody else is offering anything (and if they are, it hasn't been proven either).

    Furthermore, I would point out that the concepts have been presented over and over to many of the top software architects in the world, none of whom have found problems with the main ideas you have been reading about, other than the issues I have discussed in this section. Even here, debate focuses on the details (e.g., is scale-out really better than scale-up?), not the fundamentals of the software fortress approach.

    And finally, I might even argue that the software fortress model has been proven. One of the responses I frequently hear when presenting the software fortress model is that it corresponds closely to the way in which many organizations are building systems today. One of the things some people like about the model is that it formalizes an approach they feel they have already been using.