Moving to SOA is something that has to be seen in terms of a strategic plan, spread over as much as a ten- to fifteen-year time span in total. Within that overall gameplan, enterprises will step through a series of pragmatic, tactical objectives that gradually advance their wider strategy. Hedging their bets and planning to get at least halfway there are both part and parcel of that approach.
Phil Wainewright/Loosely Coupled weblog
Very nicely put. The first paragraph of Phil’s essay advances the useful notion that we’re doing brownfield work in this space. I discussed this topic in an earlier essay, and dance around its edges daily; this is the ongoing problem which drives my job and defines my days, both unofficially and officially. Thought I’d talk a bit about how this plays out where I work.
Everyone recognizes this problem. No one quite knows how to address it. We’ve chosen Siebel as part of the solution, and FileNet’s another piece; at a different level, MQ and SOAP are among the technologies we’re using to stitch the legacy systems to the new system, and to each other. Throw in some direct connections and some batch processes, and add some security to spice the process (and discussion) up.
It’s an unholy mess, but we make progress. I wouldn’t say we’ve got a strategy, exactly, but we’ve got a consensus that we need to get to this place, and that there are tools which can help build the department we envision. We’ve made some mistakes. We’ve learned that you can’t just buy stuff and expect it automatically to work with everything else, and that IT’s not blind to the shortcomings of the legacy systems. Systems have both inertia and entropy, and neither ever works to our advantage. The endeavor’s worthwhile, and needs to be made. Our customers–Michigan’s citizens–deserve our best efforts.
Time will move the target, and our current work will impede my successors (Shadow AT?) as much as it aids them. If I can help them think properly about methods, perhaps they can leave something better for their successors.