Con-way, a freight transportation and logistics company, began developing its service-oriented architecture 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, talked to Computerworld US at the Enterprise Architecture Practitioners Conference.
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 organisational 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.
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. They can start re-engineering the services layer … and little by little start cutting over, that shows them a path. Otherwise, companies can’t figure out how to get off ancient technology.