Software Fortresses: Modeling Enterprise Architectures

By Roger Sessions

Book Overview

This book introduces a new approach for modelling large enterprise systems: the software fortress model. In the software fortress model, an enterprise architecture is viewed as a series of... This description may be from another edition of this product.

• Format: Paperback
• Language: English
• ISBN: 0321166086
• ISBN13: 9780321166081
• Release Date: February 2003
• Publisher: Addison-Wesley Professional
• Length: 277 Pages
• Weight: 1.40 lbs.
• Dimensions: 0.8" x 7.4" x 9.3"

Customer Reviews

An analogy that is understandable in practice and transference

A software fortress is a model for a conglomerate of software systems serving a common purpose. The systems work together very closely in a trust relationship to provide functionality to a world generally considered hostile. An enterprise system is then built from a collection of different fortresses where each one performs a different function. This model makes sense, in that there are those you trust and those you don't. Since a trust relationship requires more effort to maintain than one without trust, extraneous trust relationships are inefficient. Communication between fortresses can then be done using secure channels and trust relationships can be established by appropriate verifications between parties or by a trusted third party fortress. The ways in which two fortresses will work together are defined by formal agreements between them known as treaties. Channels through which fortresses communicate are known as drawbridges, using the castle, moat and drawbridge analogy. This is also a good one, as it is much easier to monitor communication when there are few channels that are easily controlled. I found the models to be very understandable, managers trying to get a handle on the general aspects of security in an enterprise will have no difficulty in applying the fortress analogies to their software enterprises. At first it would seem that the fortress model leads to a decrease in security, but that is a false supposition. By isolating and restricting the security to where it really needs to be, it is easier to make it sound. To be effective, an analogy must be understandable by itself and be transferable to the situation it describes in a way where the transference is also understandable. The software fortress analogies satisfy both conditions, everyone understands the concept of a castle with walls, a moat and drawbridges for access. Everyone inside trusts the other, and those outside the walls are generally considered dangerous. It is also transferable in an understandable way, which makes it suitable for the creation of an architectural view of a large software system.

Excellent for Enterprise Systems Architecture

I enjoyed the book thoroughly. The concept of using the fortress as a metaphor for system is fluently presented. It starts with simple and well understood characters in a typical fortress and evolves logically into the more difficult concepts, always building on previous discussions and reiterating important concepts if necessary. I found the book very useful in my role as an enterprise architect (more about that later) for a scientific agency here in Canberra. As an agency, we are concern about data interoperability. Our stakeholders download data from our internet site to use with their researches and other business activities. They need interoperable data. The same can be said about our own researchers who need interoperable data from other sites. So we need a system that facilitates that exchange of data. It will start with manual interface at first but will require machine2machine interfaces in time to come. We know web services technology is the obvious answer. Our challenge is to logically evolve from the big picture (all the requirements) to the technologies we need to build the system. Discussions about heterogenous/homogeneous synchronous/asynchronous drawbridges are excellent way to evolve logical designs to physical designs. Technology selection does not have to base on personal experiences anymore. The fortress software metaphor also gives me a perfect tool in painting the big picture to general users and management. The fortress analogy creates resonance immediately because we, as government agent, are paranoid about security. From a software development practice viewpoint, the software fortress model carries many of the virtues of object-based programming like reuse and data encapsulation. This is not a coincidence given the fact that author is a guru in this area. What the model gives us is also the opportunity to transition into this important practice from the current amateurish programming habits. From the point of an enterprise architect, software fortress is an excellent tool to develop the enterprise technology architecture from an enterprise system architecture. An enterprise system architecture satisfies the enterprise information architecture which in turn satisfies the enterprise business architecture. At the moment, that transition from systems to technology is more an art than a science. As the author asserted the software industry has no conceptual model for building enterprise systems. If I have any objection with the author, it is the usage of the term "enterprise architecture" in the book. Enterprise Architecture actually has a well defined meaning and acceptance, at least in USA. If you point your browser to http://www.whitehouse.gov/omb/egov/a-1-fea.html , you will see "enterprise architecture" actually consist of business, information, system and technology architecture. By "enterprise architectures" in the book, the author actually refers to enterprise system architecture. As an enterprise architect,

Fortress = Interoperability with Security

In his previous two books, Roger made the distinction between implementation technology (objects) and distribution technology (his definition of components). Briefly, Sessions says components are different from and should not be confused with objects. The distinction is important because of transactions. Components need to take advantage of COMWare (COM+) transaction management in order to be scalable. In this book he introduces interoperability technology (fortresses) as the next higher level above components. Roger says interoperability and security are now the two biggest problems in the industry. His Fortress model is designed to solve the problem of disparate systems doing business together securely. It is appropriate for large-scale enterprise systems - "hundreds of programmers in autonomous groups". The book presents a modeling language based on a new architectural philosophy. He sets out sound principles for designing systems, clearly explains pitfalls and complexities that abound, and breaks the problem into easily remembered, easily understood chunks. It is based on the "autonomous fiefdom" model developed by Pat Helland of Microsoft...The Fortress ModelA Software Fortress is a collection of parts that work together as an integrated whole. The formal definition is: "... a conglomerate of software systems serving a common purpose and typically owned by a cohesive group of individuals. These software systems work together in a tight trust relationship to provide consistent and meaningful functionality to a hostile outside world." A Software Fortress is an entire system that contains components and can span several computers. An Enterprise will have different types of fortresses working as allies. Every Fortress has a Wall to prevent communications from entering except through a Drawbridge. Every message coming in the Drawbridge is compared against a Treaty by a Guard who rejects it or approves it and forwards appropriate requests to Workers. Workers access the Data Strongbox to complete the requests. An Envoy takes the completed work and prepares it (according to a Treaty) for communication to another fortress. Fortresses are all about trust boundaries, both technical and organizational. No fortress trusts any other fortress, but all the parts within a fortress trust each other. Since everything outside the fortress is potentially hostile, the Guard is a key player, and Treaties define legitimate communications. The Guard reforms every communication: nothing from the outside is ever passed directly to workers inside. While all fortresses share many features (above), Sessions has identified unique characteristics of 6 different types of Fortresses. The Fortress types are: Presentation, Web Service, Legacy, Business Application, Service, and Treaty Management. You'll have to read the book for more information. He concludes the book with chapters on design reviews, a case study, and "the part of tens" just like the "for dummies" books. The

Straightforward text, charts, questions and answers

Deftly written by enterprise software architectures expert Roger Sessions, Software Fortresses: Modeling Enterprise Architectures is an indispensable instructional and reference guide for advanced software engineers to the software fortress model of forging large enterprise systems. In this model, enterprise architecture is viewed as self-contained, mutually suspicious fortresses that interact through carefully crafted treaty relationships. Straightforward text, charts, questions and answers, and a great deal more, enhance the value and utility of Software Fortresses, making it a solid "must-read" for anyone looking to study and assimilate this particular methodology.

Software Fortress Architecture Overview

This book provides a basic introduction the Software Fortress model. Whether you are a systems architect, network engineer, developer, developer or consultant, you would benefit from knowing and understanding the software fortress architecture. This book uses excellent diagrams to illustrate and explain the discussed concepts very well. I found the discussion of fortress design principles very easy to understand. After reading, you will gain an understanding of the fortress model from a general perspective and have enough background in fortress architecture to be able to discuss the model in conversation and be able to comprehend what is going on if presented with a fortress model in your job. I however don't think the book delves into enough detail to be able to implement fortress software development techniques. The book talked a lot about theoretical fortresses, rather than focusing on practices. The book talks about the abstract concept of components, be discusses very little about actually building them. It tells you what to do with components, but not how to do it. I do not think this was a bad book at all, in fact I enjoyed it very much, but realize that the book does not cover Software Fortress practices, but more of and overview of the model itself gives you the ideas for how to design a fortress architecture, but no details on how to actually build it. Keep this in mind when deciding if this is the right book for you or not.