One of the things I want to accomplish with this blog is, as the title suggests, is bring you accounts of "SOA in action" -- to look beyond the bits and bytes and see how and where organizations are putting SOA to work on a day to day basis to grow the business.
That's why I was drawn to this account of International Truck's foray into SOA, just published in InformationWeek.
The challenge: International Truck had all types of back-end legacy systems that the company wanted to surface into a "Common Vehicle Tracking system" that could track truck production in near real time, and flag any defects or bottlenecks in production. If successfully deployed, such a system could save International Truck up to $3 million a year. But getting at the information -- which was spread across various ERP and homegrown systems -- was a challenge.
What's interesting about this deployment -- and I'm sure is the case at many enterprises -- is that the VP of IT knew that standards-based software would not be available for everything the company needed. Instead, they would have to rely on a hybrid of standardized and customized service interfaces to make it all work.
The credo I'm hearing a lot with SOA is to simply, as Nike says, 'just do it.' Standards may take some time and gnashing until they mature, and in the meantime, companies should forge ahead with their efforts. No two SOAs will ever look alike.
At International Truck, developers built two Java EE-based interfaces to a homegrown order management system and Baan ERP system. Plans are to extend these interfaces to customers and trading partners. Eventually, the company expects to be able to swap out the order management system with little or no disruption to the tracking system. Sounds like they're moving ahead in full gear.
So how is this implementation SOA versus just a web services implementation. I hear the terms used all of the time and would like to see/hear more about differentitators.
thanks