After some intense work on a couple of key futures projects, one on SOA and System p; the other on processor threading architectures; I had a couple of minutes today to catch-up with some of my RSS feeds before heading out the door and catching the last flight up to NY for the annual IBM STG Senior Leadership meeting.
Two things in the feed list grabbed my attention, both from RedMonk, although one from the self-appointed RedNun(dangerously close to something I grew to loathe in the seventies, Blue Nun, but that’s another story).
First, James Governor “outed” me and my new business cards on the Mainframe blog. I didn’t so much the resent the outing, I think it was the notion that I’d gone from zSeries to System p that hurt. I never saw it that way, I’ve just come over to System p to do a job, it’s just technology mate.
Then I read Annes’ useful piece on Open Source ESBs and Decentralised SOA development. For an op.ed piece I’m with this entirely and not about to leap to defend the usual suspects. However, reading it I just couldn’t get past the words “decentralised” and “distributed”. In IT these are emotionally loaded terms.They, the words and the pragmatism that goes with them, are just as damaging as “monolithic” and “control”. They force technology to be an either or proposition. You are either for big, tightly controlled, centralised architectures, or you are against them and for decentralised, loosely coupled, distributed systems. Cathedral versus the Bazaar ?
I don’t see at that way at all. I see IT as a profession that requires discipline, training, experience and more. Professionals make decisions based on fact, knowledge, planning and from time to time, gut feel. Decisions about decentralisation and distribution should be made on business and technical need. They are implementation choices, not a lifestyles choice. If you can’t deliver a service with the required availability from a server because it has to be shutdown for batch for two hours each night; if the communication speed between here and there is too slow to sustain that number of remote concurrent users, these might be reasons to choose a decentralised or distributed implementation.
One of the great things about a service bus, and especially interconnected service buses, is that you can make these decisions based on business and technical need, not emotional based notional requirements about control. You can implement what is needed to deliver a business solution, not an idealism.
I’ve done virtualised time sharing systems(centralised); worked on the team of the worlds first home banking systems(distributed); downsized myself out of a job; worked on the worlds largest single decision support system(centralised); been a prime driver in the IBM mainframe rebirth as a server driving LAN integration(distributed), client/server(decentralised), although late to the party been heavily involved in the mainframe UNIX/XPG compliance(centralised); a mover and shaker in the adoption of object, Java, XML Internet technologies on the mainframe(decentralised, centralised and distributed) and a shill for Linux adoption. Like any professional workman I use the right tool for the right job.
So, I’m a centerprise architect. For many reasons, security, audit, compliance, backup, availability, recovery, getting the most out of an investment and more, I think complex service based systems, and that would be anything that needed an “enterprise” service bus, should be built, configured, managed centrally and the location of the ESB implementation based on business need.