News Stay informed about the latest enterprise technology news and product updates.

The art of a SOA implementation: Design for the future

I’ve been digging into service-oriented architecture this week again in an effort to understand a bit better the technical requirements of a SOA implementation. Daunting.

What I’ve found is that when doing a SOA implementation, wrapping an existing application exposes an interface in order to increase access. In addition, refacing an application provides a new interface to not only increase access but also to allow reuse. Deconstructing an application into components (“componentizing”), so that it can be reassembled exposes new services. And that feat, it seems, is the province of enterprise artists, tapping into the collective business and digital imagination of the company.

Reading up in preparation for some interviews with companies using service-oriented architecture, I kept coming across variations on the statement that doing a SOA implementation is more an art than a science. Knowing which services to expose for the maximum value requires judgment and taste, sensibilities rarely afforded much value in the world of IT. The notion that judgment and taste can make a huge difference made more sense after talking yesterday to Fred Falten, the chief architect at Amtrak. Here is Falten on designing for future generations with SOA:

“When you’re building a service, you need to plan ahead. Always think about how the service can be reused. Make the extra investment to not just have the project at hand be the mechanism that says, ‘Here is what the interface definition should be,’ but take the extra time to think about what would the entire company, or at least the next reasonable set of potential users, want.

“That pays dividends in so many ways, in terms of future savings. Don’t build services point to point, where you’re really defeating the purpose of SOA.

“The other thing I would say is granularity of the service. It’s extra work, but if you have existing environment it is all too easy of fall into the trap of taking the existing transactional environment and just exposing each transaction as a service. That makes it so fine grained that it is usually meaningless to other applications and other potential service users. It is exposing things at a level that no one knows what to do with, or if they did, it is a lot of extra hassle for them to figure out how to move all the little transactional pieces together. So, what you want to do, if you have a legacy environment that is highly transactional and has relatively small transactions in it, is take the extra time to think about how an external business unit would want this information to be presented, not the way the original team built it, but how it really means something to be business now.”

Check in with us next week to read details on how Falten dealt with the art and science of using SOA to make the Amtrak environment more fleet of foot, er … track.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.