my recent reads..

Oct 7, 2007 TechRead Read

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.


read more and comment..

Oct 7, 2007 Rails Software Web 2.0

BillMonk

I first heard about BillMonk on the Ruby on Rails podcast. It's a really neat concept, helping you to track and share bills and things you might lend. The podcast is very interesting because it of course covers the rails aspects as well as the story behind the site itself.

You can use the site stand-alone, but it also has good integration with facebook - which is what I've been testing with some of my friends.


Well worth checking out if you share a house or often end up splitting meal or vacation bills with friends - or even just to keep track of movies or books you may lend out.
read more and comment..

Oct 7, 2007 Read

The Paris Option


It's not that I have anything against France, but reading The Paris Option comes only a month on the heels of Hunter Killer - another terrorist action thriller with the French cast as the villains.

The Paris Option is another Covert-One novel in which Col. Jon Smith brings the world back from the brink, ably assisted by CIA operative Randi Russell, MI6 renegade Peter Howell and computer genius Marty Zellerbach. Its a rollicking good read, written by Gayle Lynds under the Robert Ludlum brand.

Gayle Lynds also wrote The Hades Factor, which is the first in the Covert-One series. Peter Larkin is the other main writer in the series. Peter did The Lazarus Vendetta and The Moscow Vector, which are the other books in the series that I have read.

The Covert-One series works really well - similar in a way the the Tom Clancy Net Force franchise - and I look forward to reading the remaining novels.








read more and comment..

Oct 5, 2007 Laugh

Ballmer Peak and the Programmers' Paradox

xkcd wrote up the Ballmer Peak recently. got me thinking about what I call the Programmer's Paradox, which is the lag in creativity behind skill on the inebriation scale. This has been shown to explain why you are more likely to wake up with pizza on your face than a finished program after that "flash of inspiration" last night. Here's my graphic...

read more and comment..