Technology Commons Blog

The march of the acronyms continues. Although the concept has been around for a couple of decades, the term service oriented architecture (SOA) is being thrown about with great vigor as of late, and with good reason. While business process applications have gotten much more robust in recent years, getting them all to work together has become a sort of Holy Grail. Enter SOA.

SOA is not a product. It's not an application. It's not a hardware device that can be switched on to magically achieve interoperability. It's more of a concept. The idea is that all business process applications are essentially made up of various well-defined functions, or services, that exist beneath a user interface. These services are called upon by their applications to return a value, whether it's employee data, sales figures, or whatever. An SOA takes these services and allows them to share data with each other, or work together to complete a new function, all through the Internet.

Bruce Cleveland, senior vice president of products for Siebel Systems, uses the analogy of a home stereo. You could go out and buy an all-in-one unit with a tuner, CD player, and speakers all combined. Or you could get better quality components separately from different manufacturers. SOA is analogous to the standard wiring and connections that allow you to use these different components together. So while getting all of your business process software from one company may make them all work together better, having a way to get best-of-breed solutions to be truly interoperable is a goal many have been striving for.

This all sounds like common sense. People have been working on this for years. But the combination of SOA's open architecture - allowing an application to call on a separate function from inside or outside a company's network - and current hardware performance are making it a reality. With SOA, new applications can reuse existing functions. Developers do not have to keep creating the same redundant services each time they build an application. SOA has huge implications for business process engineering. By moving to an SOA, IT departments can better integrate their processes, eliminate massive redundancy, and build new applications much more quickly.

So what's the catch? Well, it takes the right skills to create and manage this type of architecture, and, depending on legacy systems, it can be costly to implement. Getting buy-in from on high can be difficult as well. Many executives see SOA as just another expensive acronym, and aren't very likely to allocate resources to something they think is simply the latest technology fad. The real challenge is convincing executives of SOA's benefits in cost reduction, agility, and productivity.