Software Fortresses

I forget the first time I became aware of Roger Sessions. I think a collegue of mine in the .com days might have had him as a lecturer. Certainly I got on his ObjectWatch newsletter some time back. I picked up Software Fortresses - Modeling Enterprise Architectures from the library and it is an interesting read. While I don't see too much evidence that the methodology expoused by the book has been adopted by the mainstream, it is a book that is worth reading for some of the ideas none-the-less. Principle among these is the idea that system boundries should be seen in the context of organisational dynamics. In other words, if your organisation goes for a centralised database structure and that is unlikely to change in the near term, then it makes sense to model and build your systems that way. This is a great insight as far as I am concerned. It is too easy to be seduced by the idea that IT folk are hyper-rational geeks, and forget the reality that we are all just as human as the rest. Anyone who has tried to implement a system for real can attest to the fact that often it is the human factor that is the primary determinant of success. The last chapter ("Postlude") is worth the price of the book itself. Here it lists a series of Top-10s such as Ten Important Points about Software Fortresses Ten Reasons to Adopt the Software Fortress Model Ten Rules for Software Fortress Design At the enterprise level, focus on treaties (between fortresses) Define fortresses with the right amount of granularity Look carefully at your walls (for security implications especailly) Look carefully at your guards Make sure nobody can exit the fortress except through an envoy Design infograms to be resilient Design your fortress to scale Use only losely coupled transations across fortresses Use tightly coupled transations only within the fortress Use asynchronous drawbridges wherever possible Ten Controversial Ideas within the Sofftware Fortress Model Performance doesn't count (as much as the overall design) Put security only in the guard Organisational boundaries are related to fortress boundaries Tightly coupled transactions shouldn't cross fortress boundaries We need fortresses within fortresses The software fortress model should always be used Turn off database security(!) Don't share databases across fortresses Give scale-out priority to scale-up The model hasn;t been proven (but what has?) Ten Considerations for Evaluating J2EE versus .NET Ten Observations on the State of the Software Industry The industry has no conceptual model for building enterprise systems The software industry lacks a coherent vision for flowing transactions through the enterprise The software industry has a confusing hodgepodge of security capabilities and no model for how they should be used The software industry is wasting time defining portability standards when what we need are interoperability standards The software industry does not differentiate among implementation technologies (such as objects), distribution technologies (such as components), and interoperability technologies (such as fortresses) The software industry has no concept of the difference between the communications that must occur within a system and the communications that must occur between systems The software industry does not have a common model for interoperability, so different vendors create products that are difficult to glue together The software industry uses technology-specific terminology for describing what is being done, making it difficult to udnerstand when common approaches are being used (e.g. session beans v. COM+ components) The software industry assumes that interoperability will be solved by the choice of one single technology that will integrate everything The software industry frequently provides capabilities that are not only not useful, but downright harmful (examples include entity beans, distrubuted objects, Microsofts Transation Internet Protocol) The book was published in 2003, but I think we see some sign that the challenges expresed by Mr sessions may well be being addressed - such as the wide-spread adoption of SOAP/Web Services. Mr Sessions words do however spell a warning to those who try to overload such technologies with too much intre-fortress baggage.