You and I have never met. I have no idea what your business is. However, I do know what your enterprise architecture looks like. I can even show you the exact picture you use to describe your enterprise system. Take a look at Figure P.1. Look familiar?

It goes without saying that your enterprise is a perfect three-tier (or N-tier) software architecture. When describing your system, you wax poetic about your perky presentation tier, accepting HTTP requests from complacent clients and SOAP requests from congenial collaborators. You illuminate in minutiae how you manage your middle tier, running well-behaved business logic cherubs, all gleefully sharing database connections and other valuable system resources. Behind all of this, your enterprisewide database shouts encouragement from its sheltered back end.

See? I told you I know what your enterprise architecture looks like. I also know one other thing. I know you lie. You lie through your teeth. Your enterprise architecture looks nothing like Figure P.1. Do you want to see the real picture of your enterprise architecture? Take a look at Figure P.2. But first sit down. It isn't pretty!

In the real world your clients are not meek, but malicious. Your middle tier is not well behaved, but made up of a disparate bunch of applications developed without regard for the needs of their stablemates. Your "database" is not an enterprisewide anything, but rather a series of disorganized data storage technologies that spend most of their time cringing from the unreasonable and often conflicting demands of the business logic.

As architects, we have two choices. We can ignore this chaos, or we can model it. When we model it, we have the opportunity to bring it under some degree of intellectual control.

The Software Fortress Model

This book introduces a new approach for modeling large enterprise systems: the software fortress model. The software fortress model treats enterprise systems as a series of self-contained software fortresses. Each fortress makes its own choices as to software platform and data storage mechanisms and interacts with other fortresses through carefully crafted treaties. Without going into too much detail this early, I present in Figure P.3 a view of the same enterprise that is shown in Figure P.2, but as seen from the software fortress model. Don't worry at this point about what the cartoon figures mean; they will become familiar soon enough.

The software fortress model pushes simplification of the enterprise architecture further and further. As we use the model to decompose the enterprise, Figure P.3 becomes a series of collaborations, as shown in Figure P.4.

I will discuss what the software fortress model is throughout this book. For now, let's focus on why we need this model.

The most important reason for the software fortress model is so that we can better understand how our systems interact within our overall enterprise architecture. Even without knowing the details of how the software fortress model works, you can quickly get the sense that Figures P.3 and P.4 are a lot more approachable than Figure P.2.

We already have many good techniques for modeling software systems. The most prevalent is the Unified Modeling Language (UML). But existing systems, including UML, focus on the issues involved with designing software systems. They have little to offer the enterprise architect in modeling how the various software systems that make up the enterprise architecture relate to each other. In other words, they are fine for modeling a sales system, an inventory system, or an accounts payable system. They are not useful for showing how sales, inventory, and accounts payable systems need to work together to coordinate a customer purchase.

The software fortress model picks up where techniques like UML leave off. Or, to be more precise, UML picks up where the software fortress model leaves off. The software fortress model helps us describe and plan for the relationships between software systems. These relationships ultimately define the enterprise architecture. UML and related technologies can then be used to document how individual software systems are designed.

Who Cares about Software Fortresses?

The software fortress model has a lot to offer, especially for the high-level manager who is trying to understand the overall enterprise architecture, and for the enterprise architect who is trying to explain it.

For CTOs, the software fortress model offers these immediate payoffs:

• It aligns technology boundaries with organizational boundaries within the enterprise.
• It provides an intellectual framework for modeling and managing the technical complexity of enterprise systems.
• It cleanly separates issues that must be decided at the enterprise level from those that can be decided at the local level.
• It is independent of technology and allows groups with different technology biases to discuss architectures using a common language.

Enterprise architects will appreciate the following additional benefits of the software fortress model:

• It cleanly defines natural technical boundaries across which autonomous groups can agree to disagree.
• It provides a methodology for achieving interoperability between software systems.
• It provides a methodology for defining security at the enterprise level.
• It provides an intellectual framework within which different technologies can be meaningfully compared.

But CTOs and enterprise architects are not the only ones who will gain from the software fortress model; this model has the power to transform the entire industry. For the first time, the entire industry will have a lingua franca for discussing enterprise applications. Customers and clients will be able to communicate readily with programmers and architects, Java programmers will be able to understand Visual Basic programmers, and architects from different business fields will be able to compare approaches to common problems.

Over time, the software fortress model will influence the software platforms themselves. Tools will appear to directly support the model. Platforms will evolve as the model exposes underlying platform weaknesses. New technological approaches will be explored as the model helps us better understand the needs of the enterprise.

Perhaps the most important contribution of the model is simplification: simplification of security, simplification of interoperability, and simplification of collaboration. Simple systems are inherently better than complex systems. They are cheaper to build, they are more reliable, and they are more secure. We can all get behind that.

The Goals of This Book

The software fortress model is still quite young, even by software standards. However, I have already presented the main ideas that make up this model to over 3,000 developers and conducted in-depth workshops with very high-level enterprise architects from many large companies. I have also introduced the ideas to the readership of the ObjectWatch Newsletter, which has more than 20,000 readers, including highly placed managers and architects at virtually all of the Fortune 500 companies.

The response to the software fortress model, even in its relative state of immaturity, has been overwhelming. Almost everybody who is exposed to the software fortress model feels a strong sense of resonance, as if this model addresses a very basic requirement at their organization: the requirement to model and simplify their enterprise.

This book is designed to meet an immediate need: to define, clarify, and explain the basics of this new approach to modeling large-enterprise software architectures. This approach will evolve, and I hope the evolution will be aided by a universal language for describing software fortresses and a universal approach to modeling them. Once we can all speak the same language, we can quickly start to learn from each other. One goal of this book is to provide this common language.

Who Should Read This Book

The software fortress model is not for everyone. If you are one of five developers working in a ten-person company, this modeling technique is overkill for anything you need to do. You don't need this methodology, and you don't need this book.

The software fortress model is for the enterprise. If you are one of a hundred or more developers, architects, or technical managers working in a large corporate IT organization, then this modeling technique will prove invaluable, and the language defined in this book will likely soon be used throughout your organization.

If you work in a large enterprise, even if you are not directly involved in defining software fortresses, it will be important that you are able to understand and contribute to discussions about them.

If you are a consultant advising large enterprises, the information in this book will be critical to you. Whether or not you believe in software fortresses will be unimportant, but you will need to be able to discuss them. You can be for them or against them, but you can't ignore them.

If you are a client paying the bill for a corporate system, the software fortress model is your best shot at making sure that software architects understand your needs and that developers implement systems you can use.

The History of the Software Fortress Model

As I look back over the last year, the time during which I formed the basic ideas of the software fortress model, I can see clearly several threads that came together to form this tapestry.

First, I have been teaching master's classes for enterprise software architects for most of the last decade. For a decade before that, I was heavily involved in building enterprise infrastructure technologies. During most of this time, I have been preaching a consistent message: The two major issues facing the enterprise are interoperability and security. I have been looking for a modeling methodology that would focus on these critical issues.

Second, I have always been interested in the modeling ideas that were known as data silos. Those ideas seem to capture a key idea of data ownership.

Third, the architectural ideas introduced by transaction processing monitors—namely, the three-tier architectural model—gave us some important clues to understanding what was needed to build highly scalable software systems. I have been working in the middle-tier technologies for many years now, and these ideas have been extrapolated into the software fortress model.

Fourth, Pat Helland of Microsoft has been proposing a model for autonomous computing. It is based on what he calls software fiefdoms, with emissaries linking together different fiefdoms. This model has been very influential on me, especially because it seems to capture the idea of systems working together to accomplish a higher goal. I will discuss Helland's ideas further in Chapter 10 (Internet Fortresses), where they are most relevant.

Fifth, the readers of the ObjectWatch Newsletter, now more than 20,000 strong, have read earlier drafts of my software fortress ideas and have written back with excellent insights.

Sixth, participants at my two-day workshop have added immeasurably to my understanding of software fortresses. I have been fortunate to work with very high-level enterprise architects, with many years of collective real-world experience in building large enterprise systems. These participants have contributed valuable insights.

Finally, I have had opportunities to present the software fortress ideas at perhaps a dozen conferences to over 3,000 enterprise architects in the last year. The feedback of my audiences has been tremendously helpful.

I am grateful to all of these sources for the insight each has contributed to the ideas discussed in this book. I am also grateful to you, the reader, who I hope will be helping to advance these ideas in the near future.

Chapter 1 of this book is an introduction to software fortresses, discussing what they are, the terminologies we use to describe them, and how interfortress relationships work.

Chapter 2 is an overview of the various techniques we use to document fortresses, including fortress-ally-responsibility cards (based on class-responsibility-collaborator cards) and sequence-ally diagrams (based on UML's class sequence diagrams).

Chapter 3 gives an overview of transactional integrity. This is a background chapter needed to understand the many flavors of the word transaction and how different parts of software fortresses cooperate to coordinate their work.

Chapter 4 gives an overview of drawbridges. The two major subcategories of drawbridges, synchronous and asynchronous, are covered in more detail in Chapters 5 and 6, respectively.

Chapter 5 covers synchronous drawbridges, including component technologies on which they are based.

Chapter 6 covers asynchronous drawbridges, including the message queues on which they are based.

Chapter 7 discusses how security is implemented in software fortress architectures. It covers the two important aspects of security: keeping things out (wall technologies) and letting things in (guard technologies).

Chapter 8 discusses how software fortresses form partnerships and work together, through well-defined treaty relationships.

Chapter 9 gives a general overview of issues that are relevant to all fortress types.

Chapter 10 discusses the two Internet-connected fortresses: Web service fortresses, which accept programmatic requests over the Internet, and presentation fortresses, which interact with browsers.

Chapter 11 discusses the business application fortresses that run your mission-critical business systems.

Chapter 12 covers legacy, service, and treaty management fortresses.

Chapter 13 enumerates 25 important issues you should consider in a design review of a software fortress architecture.

Chapter 14 presents a software fortress architecture case study.

Chapter 15 gives a few (well, maybe more than a few) final thoughts on software fortresses.

Acknowledgments

I would like to thank the many people who have contributed to this book. I am especially grateful to my wife, Alice, and my children, Emily and Michael, for their support. Janet would like to thank her daughter Kate for her patience and smiles.

We would both still be half asleep if not for the continuous supply of marvelous macchiatos and luscious lattes made by the crew at our local Starbucks: Corey, Jo, Bert, Charlotte, Casey, Scott, Jay, Travis, and Z.

I have taught much of this material in one form or another to thousands of workshop participants. The discussion from these workshops has been tremendously helpful in refining these ideas. Thanks to all of the participants in these many workshops, and to the many more I hope to meet in the future.

This book has benefited from early reviews by some very talented and experienced individuals. I appreciate the feedback of the following people (company affiliations are included where allowed): Richard Campbell, Chris Corrado, Charles Erickson (VP of Development, WhisperWire), Stephen Fulcher (Principal, DeveloperLabs), Lynn Keele, Ruth Leuzinger (Senior IT Architect, Zurich Insurance Company, Switzerland), Don Pipkin, Ruben Prieto-Diaz, Carlos Recalde (Executive Director of Technology - Americas Region, KPMG. LLP), Stuart Sands (a Director of Technology Solutions at a major brokerage firm), and David L. Smith.

It has been great working with the staff at Addison-Wesley: Peter Gordon, Amy Fleischer, John Fuller, Bernard Gaffney, Karin Hansen, and unknown others. I am grateful for the careful attention of my copy editor, Stephanie Hiebert. After removing my many dangling modifiers, this book was greatly improved. (I know, I know . . . "Her removal of my many dangling modifiers greatly improved this book!")

Thanks to all of you.