Chapter 1. Introduction

If you are one of those people who ignore prefaces and start with the first chapter, not so fast ! Go back and start with the preface. It contains important background information.

If you have read the preface and you are still reading, you are probably doing so because you believe that your software IT structure is a mess. If it weren't a mess, you would have no reason for learning about software fortresses . The primary goal of the software fortress model is to bring order to the IT mess.

I have some good news for you. Your IT structure is probably not as bad as you think. One of the benefits of the software fortress model is that you have probably been following it fairly closely all along. You just haven't been following it closely enough. Hopefully the gap between where you are and where you need to go is not too big.

Let's see how close you are to following the software fortress model. Take the following quiz, answering yes for each statement that describes your situation, and no for each statement that does not apply to you. Every yes answer brings you one step closer to the model, but also one step closer to the need to be following the model with a little more rigor. Here's the quiz:

1. My company has dozens of disparate independently developed systems, some built, others purchased, yet others acquired through mergers. With some, we don't even know where they came from!

2. Our systems are interrelated in such complex ways that we have no way to even guess what the ramifications of a given system failure would be.

3. We often get into religious wars about technology. Some groups are committed to Java, others just as committed to Microsoft. Neither camp seems able to communicate with the other.

4. The departments within my company don't trust each other's work.

5. Our databases are a mess. Each department has its own data bases, its own database administrators, and its own idea about how to manage database security.

6. My company worries about hooking up to the Internet. We have mission-critical and proprietary information that we are afraid somebody might steal and/or compromise.

7. We have legacy systems we depend on, but we are afraid to change many of them. Some we don't change because they are too fragile, some because they were purchased from companies no longer in business, some because the original developers have retired , and some because we have lost the source code.

Give yourself one point for each yes answer. How did you do? If you scored a 5 or higher, good news! You are already using many of the principles of software fortresses. Now you just need to add a few tweaks. The rest of this book is about those tweaks. So keep reading!

As you read through this book, you will notice a large number of acronyms and technical terms. Those that are part of the software fortress model are always defined in this book. But if you run into a term that is unfamiliar, whether from the software fortress model or elsewhere, use the glossary at the end of the book. The glossary includes every technical definition and acronym used in this book.