Con-way, a freight transportation and logistics company based in California, began developing its service-oriented architecture (SOA) in 1998. Since then, it has evolved into an event-driven architecture, where computer systems can subscribe to and publish "events" -- like an order being received -- and process events according to pre-defined rules. Maja Tibbling, lead enterprise architect at Con-way, sat down with Computerworld yesterday at The Open Group's Enterprise Architecture Practitioners Conference in San Diego to talk about the company's SOA history.
Excerpts from that conversation follow:
What are some of the major lessons your company has learned over the past seven years about developing an SOA, and what would you do differently if you began your work today?
You absolutely need executive sponsorship. One thing we did right was as soon as we proved the concept on our first pilot, it was understood we were approaching SOA as a systematic implementation. I don't see how it can be successful or valuable if you don't do that. Otherwise, you are in constant struggle with development managers about who will do development. We didn't define an [ROI] metric up-front, so in our early progress we really had nothing tangible, [and] some business leaders really like to have a number. We had more IT-ish things that showed value, but we couldn't quantify them in raw dollars. You definitely need to establish a reference architecture that will grow with your changing implementations.
The organizational and cultural [changes] are huge. We could have done better with that. We learned pretty quickly that we need to communicate often and thoroughly. We could have done more of that and articulated better some of the more intangible rules.
Today, we would have established very early on a good services repository in the middle tier. It ended up being almost that the architects were the repository with word of mouth. In the long run, that isn't the best way.
While many companies may be working on an SOA today, not many have gotten to the point of complex event-based processing or managing by exceptions. How have you gotten this far, and was this event-based architecture part of your vision from the beginning?
It certainly was part of the vision. We knew we wanted to do that level of complex event correlation and automation of business.
If you don't have the event sources publishing, then you have nothing to correlate. As [data sources] all publish out, you can also start defining what makes a complex event. An example is if I see in one part of the country a weather delay event and a road closure and some other event -- then I know I have a problem and I have to establish a different [trucking] route. Otherwise those events are disconnected. This is being used very heavily in our collections arena, where you can start monitoring payment patterns and when to start sending customers nice letters to start remind them (about a payment being due).
You mentioned that early on in your work you had not set specific metrics to show a concrete ROI. How have you shown an ROI from SOA to the business?
By now, we have clear business examples, (but) up-front you don't have those. If people can do it or if they have a mechanism of already measuring developer efficacy or the efficacy of the development department ...they can do a baseline before they start their first project. Then they will be more likely to show the value of the services reuse. You're still not going to sell it to the business based on it being SOA. You need to sell them on the idea and you need an executive sponsor, preferably like the CIO, that really buys into it and knows how to sell it to the business. Up front, they are going on faith a little bit. A lot of people will (struggle), because they are not figuring out how to do a systematic implementation. This is where they have to trust it will work eventually and stay with it. You have to focus on the architecture, not the technology. With a lousy architecture, they are not developing reusable services.
If they have some difficult scenarios, where it has been hard to get rid of a legacy application or if they can start reengineering the services layer on top ... and little by little start cutting over, that shows them a path where, otherwise, companies can't figure out how to get off ancient technology.