Software Fortresses: Modeling Enterprise Architectures [Paperback]

Roger Sessions (Author)

Book Description

Publication Date: February 24, 2003 | ISBN-10: 0321166086 | ISBN-13: 978-0321166081

While UML is very effective at modeling software systems, it is deficient in its ability to help practitioners understand how software systems interact -- this is where the software fortress model picks up. The vendor-independent 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. This unique approach simplifies the enterprise. It helps the software professional truly understand how systems interact. This book defines, clarifies, and explains the basics of software fortresses. The author believes this new approach will grow in popularity and evolve over time, and this book will be the genesis of a popular enterprise development movement.

Editorial Reviews

From the Back Cover

This book introduces a new approach for modeling large enterprise systems: the software fortress model. In the software fortress model, an enterprise architecture is viewed as a series of self-contained, mutually suspicious, marginally cooperating software fortresses interacting with each other through carefully crafted and meticulously managed treaty relationships.

The software fortress model is an intuitive, simple, expressive approach that maps readily to existing technologies such as .NET and Java 2 Enterprise Edition (J2EE). This book is designed to meet an immediate need to define, clarify, and explain the basics of this new modeling methodology for large enterprise software architectures.

Software Fortresses is your essential roadmap to all aspects of software fortresses.

Key topics include:

The fundamental concepts and terminology of software fortresses

Documentation techniques, including Fortress Ally Responsibility Cards (based on Class Responsibility Cards) and Sequence Ally Diagrams (based on UML's Class Sequence Diagrams)

The proper use of drawbridges to provide fortress interoperability

The innovative software fortress model for enterprise security

Correct design approaches to fortress walls, which keep intruders out, and to guards, which let allies in.

The role of loosely coupled and tightly coupled transactions in a software fortress architecture

Design and technology issues associated with the six major software fortress types

This book is a must-read for all enterprise software professionals, whether you are a manager seeking to rein in run-away enterprise system complexity, an architect seeking to design interoperable, scalable, and highly secure systems, a consultant expected to give advice on how .NET and J2EE fit into the enterprise space, an implementer wanting to understand how your system relates to a larger enterprise architecture, or a business analyst needing to know that your system requirements will be translated into a successful software implementation.

0321166086B12202002

About the Author

Roger Sessions is one of the world's leading experts in enterprise software architectures and the developer of the software fortress model. He has written six books and dozens of articles. He writes and publishes ObjectWatch, a widely read, highly regarded newsletter covering hotly debated topics on high-end software technologies. More than 50,000 people have attended his architect-level workshops in more than 30 countries.

0321166086AB01242003

See all Editorial Reviews

Product Details

• Paperback: 304 pages
• Publisher: Addison-Wesley Professional (February 24, 2003)
• Language: English
• ISBN-10: 0321166086
• ISBN-13: 978-0321166081
• Product Dimensions: 9.3 x 7.4 x 0.8 inches
• Shipping Weight: 1.3 pounds
• Average Customer Review: 3.6 out of 5 stars  See all reviews (7 customer reviews)
• Amazon Best Sellers Rank: #1,978,715 in Books (See Top 100 in Books)

More About the Author

Discover books, learn about writers, read author blogs, and more.

Customer Reviews

Most Helpful Customer Reviews

13 of 14 people found the following review helpful:

4.0 out of 5 stars Fortress = Interoperability with Security, June 19, 2003

By 

Thomas Adams (Scottsdale, AZ USA) - See all my reviews

This review is from: Software Fortresses: Modeling Enterprise Architectures (Paperback)

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 Model

A 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 design review contains 8 pertinent questions to be asked and answered for overall project management, 7 for enterprise architects, and 9 for fortress architects. The case study is made-up, but it illustrates the steps of design, use of tools, and trade-offs that are made. The "tens" summarize by reiterating the basics of fortresses, the reasons to adopt fortress architecture and fortress design rules. The most interesting "tens" are the 10 most controversial ideas in Software Fortresses, and 10 criticisms of the software industry.

He wraps up by stating "This model has the potential to move us as far beyond three-tier/N-tier architectures as three-tier/N-tier architectures moved us beyond client-server systems."

Analysis

It all sounds great, and I have a lot of respect for Roger because of his deep knowledge of this problem space, but at this stage, the book is just hand waving. He doesn't reference actual success stories using his architecture. Because it is new, unproven concept not invented by IBM or Microsoft, there are no tools that implement his architecture.

I know Sessions writes for people seeking a conceptual understanding of issues, not for coders. Roger is very good at explaining the concepts - I know of no one better. Nonetheless, I would be happier if he had designed and coded an enterprise with working fortresses - as an example along the Rocky Lhotka line ISBN 1-861002-07-6 (alternate, alternate).

Roger concedes that the model hasn't been proven, but the problem remains: what is being done now doesn't work, and he says there is no other solution on offer. After a little exploration, I think Model Driven Architecture (MDA) from the OMB...may be his competition. MDA provides:
·Portability
· Cross-platform Interoperability
· Platform Independence
Domain Specificity
· Productivity
MDA makes portability and platform independence goals, which Roger says is a waste of time. MDA doesn't have security as a goal, which is one of Roger's key points. MDA is an industry standard, where Software Fortresses is just one guy's idea.

Conclusion

No matter how good an idea, I don't think Software Fortresses is going very far unless it gets adopted as a standard. Roger gets in his own way here. He is brilliant, but he doesn't seem to play well with others. His books have minimal "additional resources" appendices and no footnotes to other authors work. His acknowledgements to other authors are sketchy. When asked, he could make no recommendation on a book on programming Objects Vs Components, and referred me to his newsletter article....

Learn about the Software Fortress architecture and use what you can.

6 of 6 people found the following review helpful:

4.0 out of 5 stars Software Fortress Architecture Overview, April 14, 2003

By 

James J Edelen IV (Jamison, Pa United States) - See all my reviews

This review is from: Software Fortresses: Modeling Enterprise Architectures (Paperback)

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.

4 of 5 people found the following review helpful:

1.0 out of 5 stars A far cry from "Modeling Enterprise Architectures", September 8, 2008

By 

J. Bot "Trottr" (Soest, the Netherlands) - See all my reviews
(REAL NAME)   

This review is from: Software Fortresses: Modeling Enterprise Architectures (Paperback)

This is by far the worst book on Enterprise Architecture I've ever come across. It's not that I don't like the odd joke, but I'm afraid that nobody will take an enterprise architect for serious who models a business as a comic book with a bunch of funny figures in medieval outfits. Worse still, anyone who envisions an enterprise architecture as a collection of strong fortresses doesn't get the real challenge of today's enterprise architect. I strongly believe that an enterprise that builds walls internally should better be split, in other words, the very word "enterprise" should indicate internal collaboration and synergy instead of mistrust and secrecy. In architectural terms: good architecture requires not just low coupling, but also high cohesion between the parts.

This book is entirely founded on the wrong presumption that parts of an enterprise are each others enemies until they explicitly agree upon an alliance. It's time to leave the middle ages behind and move forward to a more contempory, collaborative approach.