What Is SOA?

CRM customers can't get through a product pitch or demo without hearing about services-oriented architecture, or SOA. Many companies' products are built on SOA, designed around SOA principles, or are otherwise able to take advantage of SOA. But when was the last time anybody tried to explain what SOA really is, or why it's important to your business? SOA adds flexibility to business processes and the applications that drive them by breaking them down into smaller functional elements called services, then assembling them into applications to achieve standardization and interoperability--think of it as phonics for business. "In essence, services help provide functionality to your business," says Matthias Haendly, head of solution marketing, enterprise service architecture, at SAP. "In the past developers used programming languages to hardwire business processes. To change processes and functions, a company would either have to change their code, going through all the development work involved, or switch to a proprietary software package." In short, an implementation was all or nothing: Either the internal developers would beat the system into shape, or they would install a new one. In contrast, SOA comprises many smaller packets of code, each doing a very specific task--performing a service. By stringing services together you have a modular approach that allows much more flexibility. "You gain productivity efficiency, because you can use the best piece of code available," Haendly says. "You can add functionality easily and differentiate your offering." SOA--the newest buzzword for making processes more flexible--has been around since at least 1989, when Object Management Group released Common Object Request Broker Architecture, commonly known as CORBA. "The major difference is that we're finding ways to actually deliver on the promises now, using technologies like Web services," says Jake Frievald, director for iWay Software's Adaptive Framework product suite. "You could almost say that we needed a new acronym to show people that we mean it this time." The efficiency of SOA is clear. "You don't want to provide one million Web services," Haendly says. "The goal is to provide a linked architecture to automate pulling Web services into enterprise objects that interrelate." This efficiency--like ants working together to move a mountain--is lost when you build too much into a service: There comes a point when a few giant ants are less effective than several small ones. It also fades when the ants have to cover too much ground to stay in touch with one another. "If you have several applications built of many common services, all the functions have to talk to one another, or leave messages when one isn't available," Haendly says. "If they're all in the same environment, they can call one another directly. But if some are on a different machine, or outsourced, they can't talk directly. They have to communicate through an operator like XML, or leave messages in a cache, and the function slows down dramatically." The more granular the services are, the more message-based communication there has to be, resulting in performance issues. Although Web services and SOA are intertwined, they aren't the same thing. "A lot of people think that Web services gives you SOA, but that's not really true," Frievald says. "You can make a mess with Web services, too--it'll just be a standards-oriented mess." Organizations should publish as services only the functional elements that are needed across the organization, to preserve simplicity and reusability. Reuse of resources is the key to flexibility and agility. "If you allow everyone to reuse the same purchase order process, then when you want to upgrade your ERP system everyone will be upgraded at the same time. But if each division creates its own purchase order process, then everyone will have to upgrade independently, and that's a real mess."