13.1 Group One: Enterprise Overview Questions

The questions in this first group are targeted at those who are responsible for managing the overall software development process.

Question 1: Do we need a software fortress architecture?

As much as I believe in the software fortress model, it clearly isn't for every software venture. As I said earlier in this book, the software fortress model is a serious architecture for large-scale enterprise systems. If you're working with three other programmers to build the next -generation word processor, I can't imagine this architecture helping you, and it may well introduce many problems. This architecture is for the enterprise environment. It is for building systems that involve hundreds of programmers organized in more or less autonomous groups.

Question 2: Do we all have the same understanding of the software fortress methodology?

It is important that everybody, including the CTO, the architects , and the developers, has a common understanding of what the software fortress methodology is. This is not to say that everybody will be involved in planning enterprise-level fortress relationships, but everybody needs to understand the basic ideas and terminology so that communication is facilitated.

You can take two important steps to ensure that everyone involved is on the same page. First, make this book required reading for everybody. I have purposely tried to keep the book at a level and length where it can be read in a weekend . With volume discounts , this is a cheap investment. Second, appoint one person to be the software fortress advocate within your organization. If your organization is large enough, appoint a small group of people to serve as software fortress resources. These people will eventually serve as the start of a corporate knowledge pool about software fortresses and will become valuable resources for future designs.

Question 3: Have the requirements for each fortress been clearly articulated ?

As you start to think about which technologies you will use for each fortress, you need to understand the requirements for each of those fortresses. These requirements may well affect decisions you make not only about fortress technologies, but about how you approach treaties and drawbridges .

You should assign a weight to each requirement. You are likely to find that different requirements conflict with each other. For example, a fortress might require the lowest possible unit-of-work cost and also need to be run on Unix. These are conflicting requirements. Low unit-of-work costs greatly favor Microsoft's .NET technologies, whereas running on the Unix platform greatly favors J2EE technologies. You must decide which of the two conflicting requirements is more important to you.

At the very least, for each fortress you should identify requirements with respect to unit-of-work cost, platform, and scalability.

Question 4: Have our fortresses been partitioned with organizational boundaries in mind?

Remember that a fortress is not just a collection of cooperating technologies; it is a collection of cooperating people working closely together. If you have a fortress that depends on two different groups who usually do not work together, do not report to the same person, and are suspicious of each other's work, you need to rethink your design. Don't try to force people into artificial constraints. Be realistic. Fortresses are more adaptable than people.

Question 5: Are our fortresses organized around natural trust boundaries?

Hopefully the importance of a fortress as a trust boundary is obvious by now. Remember, trust is not just a technical issue; it is also an organizational issue. Some fortresses may draw more suspicion than others, but every request originating outside the fortress should cause trepidation.

Question 6: Have we really made enterprise-level decisions at the enterprise level and fortress-level decisions at the fortress level?

Enterprise-level architects should work at the enterprise level, and fortress-level architects should work at the fortress level. They shouldn't unnecessarily get in each other's way by making inappropriate decisions at inappropriate levels.

For example, it is not appropriate to decide at the enterprise level whether to use Microsoft's .NET or IBM's WebSphere. This is a fortress-level decision. It is appropriate to decide at the enterprise level which J2EE vendors are acceptable alternatives.

It is not appropriate to decide at the enterprise level whether tightly coupled transaction boundaries will be managed automatically by the fortress infrastructure or whether they will be hard-coded ”a topic I covered in Chapter 11 (Business Application Fortresses). It is appropriate to decide at the enterprise level how compensatory transactions will be managed.

Question 7: Have we confused objects, components , and fortresses?

Confusion of objects, components, and fortresses is probably one of the most common reasons for failures in fortress and related architectures.

An object is an artifact of object-oriented programming. Object-oriented programming is one (not the only) technique we can use to implement algorithms. An object is therefore a unit of implementation. In Java, an object is an instantiation of a Java class. For .NET, an object is an instantiation of a class defined in one of the .NET languages, such as C#.

A component is an artifact of a component packaging technology. Component packaging is one of the ways we package compiled code together, identify remotely accessible interfaces to that code, and assign processes in which that code will run. A component usually encompasses some significant business functionality, such as an account. Ultimately, a component is a unit of packaging and distribution.

In Java, a component is typically an Enterprise JavaBean. In .NET, it is typically a COM+ component. Although COM+ pre-dated what most people think of as .NET, it still provides the component packaging technology for .NET. Most component technologies do not assume that the software systems they are packaging are implemented with objects (Java being the notable exception).

A software fortress is an artifact of the software fortress model. It is an organization of software systems along common trust boundaries. A software fortress is therefore a unit of organizational functionality. The concept of a software fortress is independent of the packaging technology used to package and distribute the underlying systems within the fortress. You can just as easily create a fortress around Enterprise JavaBean components as you can around COM+ components.

Question 8: Have we identified all of the security issues?

Enterprise security is one of the most obvious features of the software fortress model, but it is up to you to identify the security concerns of your architecture. There is no such thing as a perfectly secure fortress. The best you can do is make the cost of breaking into your fortresses greater than the value of the resulting break-in. For some systems you need to leverage every possible resource, encrypting every request, authenticating every infogram source, and authenticating every authenticator. For others, you can get by with basic operating system authentication. You need to use an appropriate security defense. To determine what an appropriate defense is, you must start by understanding both the risks and the costs of break-ins.