SOA 101

by Tara Swords, November 2010

Let’s start at the beginning. Integration has been a problem since the moment the second computer application was created, because someone wanted to connect it to the first one. Today, a global corporation such as GM might have hundreds of applications touching operations all over the world. If integrating two systems was a headache, imagine the nightmare of integrating hundreds. This has made integration an extremely painful, expensive, time-consuming process.

For example, in a non-SOA environment, the IT staff connects the customer relationship management (CRM) system to the financial system, the financial system to the reporting system, the reporting system to the executive dashboard, and the executive dashboard to everything.

As the systems and integrations evolve over time, diagramming this architecture on a whiteboard reveals a tangled web of interconnectedness. If changes to any of these systems are needed—which happens many times every year at any given company—IT staff can find themselves trapped in a maze of custom code and point-to-point integrations.

“You end up getting these very brittle systems if you tie everything together directly, and it’s very difficult to maintain,” says David Shaffer, vice president of product management at Oracle. “When you want to change something, you have no idea what’s going to be impacted by that change. You get to the point where you can’t change anything cheaply. You’re frozen.”

Enter SOA. In a SOA, instead of tying applications directly together, you expose an interface that enables integration with each system in an open, standard fashion. Then you create services, which you can think of as business capabilities that expose information from a system or kick off a business process. For example, you might create a service called “ChangeCustomerAddress.” This service might touch lots of proprietary data within a CRM system or even multiple systems, but the application or system that calls the service is insulated from the implementation details of the service.

In this example, someday the CIO will swap out the CRM system and upgrade the financials system. A point-to-point integration approach will get exponentially more complex with each added system and change.

But with SOA, adding services actually increases the value of the integrations over time. IT staff can change back-end systems more freely and can reuse services across disparate applications and processes.

“With this loosely coupled approach, we can isolate the impact of changes we need to make,” Shaffer says. “That approach provides agility and reuse, making it much more efficient to manage change.” 

For More Information

Stellar Service
Oracle Service-Oriented Architecture
Oracle Fusion Middleware

 


 Tara Swords is a freelance writer based in Chicago, Illinois.