Future state

I am on a small distributed team planning the future state integration architecture for a $6B business. It isn't as glamorous as it might sound (replace glamorous with painful depending on your outlook). It is just a small part of my job. Most of time is spent dealing with present day integration and maintenance of past integrations. Plus, we all know how integration architecture standards go -- they are rarely followed when project deadlines loom, etc. But, I have learned a lot about integrating systems during my career and I have strong opinions so I'm going to give it my best effort. I don't think it will go 100% the way I think it should (nor should it), but I hope that I can at least save some poor sap some agony by keeping things as simple as possible, but not simpler.

Should be interesting to see where this goes.

I'm trying to remain objective and not just be knee jerk anti WS-* and anti anything EJB (i.e., ESBs built upon app servers). It is hard to a) keep my biases in check (established from in the trenches angst) b) compete with the industry echo chamber that says WS-* is good and you need an app server for every Java process.

I wonder if I'll end up recommending the same thing I said the last time I participated in planning a SOA integration strategy in 2002. How depressing would that be? There better be better options 4 years later.

The previous company I did this for couldn't be more different then the current. For starters it was a $700M business and is a high tech company. The integration challenges were just Java vs. .NET & Unix vs. Windows + a bunch of COTS packages (e.g., SAP, Siebel, Onyx). The current company has every platform ever invented - just like most major financial services companies. We have Unix, Linux, AS/400 (iSeries), MVS (z/OS), VSE (z/VSE - been around for 40 years), just to name the ones you might have heard of.

I don't know where this will go. Perhaps we'll just punt. It would be easy enough to lay something out that a) looked respectable, b) would sit on the file server unaccessed

I do know one thing - right now is a very bad time to place bets on future state. Sadly, there is a lot of uncertainty right now IMHO in integration land. I would have thought things would have come further in 4 years, but here we are. We have WS-* & SOAP, Service Centric ESBs, Message Centric ESBs, App Server Centric Don't-Write-Us-Off ESBs, EAI Vendor Centric Repackaged as Not-Sucking-Anymore ESBs, WS-* vs. REST, JBI (quickest spec to die in history? I set the over under at 1 year 6 months ago and still am comfortable as the house), SCA (Service Component Architecture), and vendors drafting standard after standard and having to sing Kumbaya before the whole house of cards falls down (dramatic?).

SOA is here to stay, that is for sure, but SOA is just an integration style. We've had that style since before I was born (don't tell my boss), but it is finally mainstream. You'd think there would be some consensus in 2006 around web service impl of SOA, but, the battle lines are just being drawn it seems. There is more uncertainty now, then ever IMHO.

So anyway, I'll likely be posting about this future state bit-o-panic a bit the next few months.

Oh yeah, so what was my recommendation last time? I suggested that we avoid SOAP based web services and find the best JMS provider (Microsoft still doesn't really do messaging in 2006) we could that would a) scale b) cluster c) fail over d) notify/monitor e) secure clients, destinations simply, support Java, C, C++, COM, .NET, & HTTP clients, maintain a simple Canonical Message Format (de-crufted OAGIS at the time), and build a lightweight ESB layer on top of it and then write services against the ESB layer's api.