Review By: Jan Scott, QB Software Inc.
05/11/2004In “Software Fortresses: Modeling Enterprise Architectures,” Roger Sessions presents a way of thinking about systems and modeling an architecture for use within a large organization with many different hardware and software platforms.

The book begins by explaining how to diagram an architecture using the fortress methodology. A software fortress, as defined by the author, is a group of software systems that serve a common purpose and are owned by an organization within an enterprise. The software systems work together to provide functionality to other fortresses within the enterprise through interfaces called drawbridges. Fortresses also have “treaties” with other fortresses about how they will work together.

Sessions then discusses the nuts and bolts of an architecture such as transactions, interfaces, and types of security. Next, the types of fortresses (Internet, business, legacy, service, and treaty management) are discussed in relation to scalability, reliability, security, and integrity. The last two chapters deal with questions to ask in an architectural design review and a case study that serves as an example to illustrate the methodology.

The book is written in a clear, easy-to-read, and sometimes amusing style. At about 250 pages, it can be read quite quickly. The author does a good job of giving an overview of almost all the architectural features that the reader is liable to come across from a traditional transaction against a database to the Web services world of SOAP and WSDL.

The chapter on security, which discusses firewalls, validation, auditing, authentication, encryption, data integrity, and authorization, is especially good. Security can be a confusing and misunderstood subject, but this book provides a clear and concise explanation of the subject and shows how all elements of security can and should work together.

If you are a software developer, a software development manager, a project manager, or even a business manager with some technical background and interest, and you have wondered about all the technical terms and products being used today, this book is for you. It doesn't have a lot of technical depth, but it will give you a basic understanding of how the different pieces of an architecture fit together and which tools are used for which pieces. For example, the author explains the difference between synchronous and asynchronous transactions and when to use each. He explains terms used by Microsoft and Sun and discusses the differences between .NET and J2EE. However, if you are an expert in a particular technical area, you may find his treatment of your area of expertise a little shallow.

Some of the author's ideas are controversial and even counter to the common wisdom. He believes that databases shouldn't be shared across fortress boundaries; many companies have or wish to have an enterprise database. He advocates scaling your system by adding clusters of small machines; many large enterprises would say this is harder than adding larger machines.

I think the main value of the book is in the methodology it presents and its comprehensive overview of architectural components rather than its technical recommendations. The software fortress diagrams could be used very effectively for analysis and understanding of legacy systems as well as in designing new systems. In my work as a test manager at a large organization, I would not hesitate to use the techniques presented in this book.