Search in Book Reviews

The book is aimed at anybody working in a large corporate organization that has a stake on its IT architecture, including developers, architects, technical managers, and the end users.

The Software Fortress Model has two main building blocks. The first the Software Fortress - a "conglomerate of software systems serving a common purpose" that "work together in a tight trust relationship to provide consistent and meaningful functionality to a hostile outside world". The second the Software Fortress Architecture - an "enterprise architecture consisting of a series of self-contained, mutually suspicious, marginally cooperating software fortresses interacting through carefully crafted and meticulously managed treaty relationships."

The methodology also includes a graphical notation, derived from UML, and an adaptation of the Class Responsibility Cards called Fortress Ally Responsibility cards (FAR).

The book is well written and informative: it is readable, contains several interesting ideas, and does not require a strong technical background to be understood.

The book is let down by only two things.

First, it lacks a bibliography section. In my opinion, this is a major problem. New ideas are seldom developed in a vacuum - the author himself admits that many of the ideas in the book are not really new - and knowing what influenced their development can be useful for understanding them better.

Second, some opinions are misrepresented as facts. For example, the comparison of the costs of choosing .NET versus J2EE in paragraph 15.5 is based more on gut feelings than on evidence.

That said, even with its weaknesses, I think that this book is a valuable read for anyone interested in enterprise software architectures, also for people working in small organizations - even if the author claims that the Software Fortress Model is "overkill" for them.

Recommended.