<< 1 >>
Rating: 
Summary: Straightforward text, charts, questions and answers
Review: 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.
Rating:
Summary: Excellent for Enterprise Systems Architecture
Review: 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, I hope we all have a consistent use and meaning of the terminology.
Rating: 
Summary: Stolen ideas
Review: I found the contents of this book to be a very disturbing rehash of previously published and almost completely unackowledged material. It also is simplistic and does not provide realistic examples.
All that is new here is some cute cartoons and some medieval names for elements that prior authors have described in more details and with real world examples.
I recomend you do not buy this book and encourage such idea theft but rather read the original materials.
Rating: 
Summary: Fortress = Interoperability with Security
Review: 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.
Rating: 
Summary: Not very helpful
Review: The book has some interesting thoughts, although it makes some claims, which i absolutely can't agree with. 1. The author first writes very theoretically. There are no real life examples and so the whole architecture is somehow just a bubble. In the beginning of the book he writes about having objects, components and interfaces inside fortresses and a few chapters later he puts computers and routers inside a fortress. In my opinion the author somehow seems to mix up quite a lot of different aspects. 2. In chapter 4 he claims, that the decision between J2EE and .NET has not a long-term impact. I think this is plain wrong, because i have never seen a company porting an application from j2ee to .Net, or vice versa (at least not short-term). If choosing a technologie does not have an long-term-impact, then how comes, that there are still so many legacy systems using cobol? In comparison to that he writes, that choosing a drawbridge technology has serious long-term influence. Well, from my point of view, changing a drawbridge is be more likely to happen, then changing the technology. 3. In chapter 4 the author writes, that is is very unlikely, that a HTML-Frontend uses the same drawbridge to comunicate with the businesslogic, than for example soap. Errrr... Providing one interface for accessing businesslogic is often seen as best practice and Gamma even has a name for it: a fasade. 4. In chapter 11 the author claims, that you should choose .NET and not J2EE if low cost is important for your project. This claim sounds absolutely ridiculous to me. 5. The book start by telling you, that no matter what you have done, your enterprise architecture is a complete mess and that you are a liar, if you don't confess...Well, not a very nice way to start a book, i suppose. In my opinion the book lacks of: examples, prove of concept, examples, references, examples
Rating:
Summary: Software Fortress Architecture Overview
Review: 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.
Rating:
Summary: Software Fortress Architecture Overview
Review: 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.
<< 1 >>
| 
