Where was SOA when I needed it?
There was an interesting package of stories in Network World today, one of which featured Sun's own Greg Papadopoulos, on "the future of software. All are quick reads. All 5 stories talk about the move to software as a service, and 3 of the five hone in on SOA as the means to that end.
Which made me think back to my IT career. I spent the first 20 years of my professional career (as opposed to my pre-professional career pitting peaches and tending bar, among other things) in IT, starting in in aerospace. I was part of the industry as we progressed from batch to client server to n-tier, from mainframes to minis to workstations to PCs to thin clients. One of my first jobs was writing an interface to the Aerospace firm's MRPII system, written 15 years earlier in RPGII. "Interface" is probably too strong of a term - no one really understood the core of the code (we did not have source nor documentation for large portions of it) so what I really did was carefully determine what could be fed into the beast as input to get the output we needed for a new set of systems - without breaking anything. As far as I know some recent college graduate is still doing the same.
While in IT at Sun a considerable investment in time and architecture was invested in the information highway, a publish and subscribe mechanism which was ahead of it's time - preceding helpful web service standards such as xml, uddi and bpel, and preceding the enabling capabilities gained from solutions such as Sun's Composite Application Platform Suite. The information highway did keep us from writing point to point interfaces between what was then hundreds of systems but it was complex to maintain, and because it was proprietary it was eventually abandoned.
In both examples the IT organization I was in was dealing with the tension between a dynamic business, static systems, and limited resources. Rewriting everything was a non-starter. Integrating proprietary interface methods into the core of our ERP system made it very difficult and expensive to upgrade. IT is never "done". An IT organization taking more of a "pac-man" approach to component change, replacing applications exposed only through web services, is going to have the flexibility to stay up with the needs of their business - whether the systems are internally facing or external facing - while avoiding the upheavals of large, "big bang" systems migrations.
IT could be a fun place to be again...
Posted by jaylittlepage ( Feb 13 2006, 03:59:59 PM MST ) Permalink
