Software Fortresses

Oink.NET writes: "An interview with Roger Sessions discusses, among other things, his software fortress model for designing enterprise software systems, complete with guards, grunts, allies, and drawbridges. Enterprise systems are treated as mutually suspicious, marginally cooperating software fortresses, which he claims is perfect for the coexistence of J2EE and .NET systems."

Crabby bastard

[mapMonkey]

This guy seemed to have very little positive to say about anyone/anything except himself and his own "ideas". I got nothing out of that really.

Re:Crabby bastard

[hoquaim]

It's perhaps unreasonable to expect a great explanation in a short interview, but for someone who's company is "information transfer" Roger has done a pathetic job of conveying what the software fortress model really is.

All he says amounts to "abstraction" and "seperation". Not very insightful. His fortress metaphor is nowhere near as powerful as he seems to think.

Unplug from the Internet

[Perdo]

Go to the store and pay cash.

Perfect transaction security, privacy, and accountability.

When you are on a first name basis with The UPS driver, Fed Ex Driver, The alternate UPS Driver, The alternate Fed EX driver, The women who sound like they could rock your world from both UPS and Fed EX customer support, you decided to pave and widen your driveway just so the UPS truck would really deliver to your door, you opened up a secured visa online account to insure against shady vendors and the list of orders you are tracking requires it's own automated database that only delivers summaries of what is supposed to get here today and what needs your personal attention because it is over a week late, you really need to simplify your life.

Re:Unplug from the Internet

[Monkelectric]

The record to my residence was 8 packages in one day :)

(trying to start a pissing contest)

Yet Another Data Fortress Model...

[Kris_J]

It's a lovely pie-in-the-sky article, but it's not particularly practical. For example, to use the terms used in the article, what happens when two specific technologies used to build a fortress don't actually have a drawbridge that knows how to communicate between them? It's all well and good to say this is a solution to a debate or an agreement to disagree, but if payroll goes one way and HR goes another then no-one gets paid.

I think all the author has done is give names to what a significant number of sysadmins already try to do. Without really addressing issues like scalability or intra-departmental trust.

Re:Yet Another Data Fortress Model...

[jilles]

I agree it is not practical. However the concepts he presents are not bad. Architecture is all about communicating the intention of technical solutions and designs to other people including coders, testers, customers and managers.

The concept of a drawbridge is easy to understand and if you put a guard on it the intention is pretty clear. Of course it depends on how you implement these concepts whether it will actually work. If your drawbridge is http and the guard consists of a perl cgi script that will match a three letter password to an unprotected list of valid passwords you are fucked. But at least you will be able to explain that the guard is easy to bypass and your drawbridge is inherently insecure: much better to use https, encrypted passwords of at least 8 letters, etc.

What the industry needs is proven solutions with clear, well understood concepts. This guy proposes some useful concepts and analogies that are easy to understand and, as he argues, easy to map to existing, proven technology.

UML?

[winchester]

It's an interesting article until he mentiones UML is a methodology. That is where it stopped being interesting. Besides that, I believe that UML is not the right tool to maintain hundreds of relationships, unless you use an automated tool like Rational's Rose. And Rose is tied to RUP, so you more or less have to use that, whether it is the right development methodology for your enterprise or not.

I'll say it once again... UML is NOT a methodology. UML stands for Unified Modelling Language. Please tell me where the methodology is in that?

Re:UML?

[SimonK]

He also said "[UML's] real strength is at the object (ie. implementation) level", which was where I stopped reading. Using OO modelling techniques does not imply that one is modelling the OO implementation. Conceptual and specification level models are much more practical and useful. For a start, you don't need A0 paper to print them out on.

Seriously, though, we already have a implementation model. Its called "the code". The only reason to model implementation in UML is if you want to use some code generation thingy because typing method and class declarations is somehow too onerous for you. The best use for UML (IMHO) is to model the system at a level that lacks many of the implementation details that don't impact the system concepts or overall design. These things can get lost in the code, and thus modelling them can be a real benefit.

Fortress model considered harmful.

[Bazzargh]

Reading the article I was struck that I'd seen Bruce Schneier denigrating the 'passive defence' fortress security model in the past, and a quick search found the article - What Military History can Teach Network Security [counterpane.com].

I'm not going to completely denigrate Roger Sessions here. At some point in a system components have to trust each other. However that point is not actually the firewall, which was Schneiers point - you need application level security. And Roger explicitly mentions firewalls as a fortress implementation technology (yes they may well be the walls but I wouldnt want them implementing the door as well).

A second problem with his model is the fact that he lets anyone at all through the door, after the guard ok's them. This is the kind of thing that led to problems in the early days of the web [cert.org]. Perl's taint model is better, and in Roger's world represents every messenger from the outside being followed round the fortress by a guard, or better still, sending someone out on a horse to parley instead of letting the messenger in in the first place.

To sum up, anyone implementing the security model as described in that article would actually be repeating an old set of mistakes (which curiously went by the same name, and Roger hasn't noticed). It does not describe an 'improved' level of security, rather it describes pretty much what is on the ground in most places. That may well have been his intent, though, time will tell.

-Baz