SOA in plain language

For the last few years, service-oriented architecture has been hyped as the next big thing in IT. Unfortunately, all the buzz and jargon have left some of us scratching our heads or even dismissing SOA as too good to be true. In fact, many companies are still mystified by it, and, as a result, have not begun the journey to create a faster,  more flexible enterprise architecture that better aligns business with IT.

SOA’s slow start doesn’t mean it deserves to be shelved, however. Remember the beginning of the Internet? It was hyped as something that would become indispensable in our everyday lives long before it actually was. But because the potential benefits were so striking, a lot of smart people powered through its problems and shortcomings—and here we are today.

Don’t let the jargon and hype lead you to miss a key opportunity. Building an SOA is a journey, and enterprises that get started today will have an edge on those that hesitate.

So here—in plain language—are the basics of service-oriented architecture.

Simply put, SOA is a framework for building an IT infrastructure. With SOA, IT delivers business functionality as shared, reusable services. Business processes drive the definition, creation and execution of these services.  Because you don’t have to rebuild each service from scratch, you can more quickly create new services to respond to business needs. 

Like the Internet, SOA is based on industry standards, not vendor preferences. As a result, services can run on any system—open or proprietary, compatible or not. You don’t need to buy new applications or hardware. You don’t need to throw out what you already have. 

Think about the core capabilities your company needs. A retail bank, for example, might need to process applications for credit cards, mortgages and checking accounts. Each involves a series of steps, or services, such as checking credit scores or verifying employment. SOA orients your IT architecture around those services so you can build, combine and modify them faster and more easily. The various applications can share data, communicate and coordinate activity. 

With a traditional IT architecture, whenever a new need arises, you implement another IT solution.  Need to process mortgage applications? Build a new system. Need to process credit card applications? Create another. The result is a collection of applications that replicate the same steps over and over, but are executed in different ways across separate systems.

Imagine that your company wants to change how customer records are formatted. The task seems simple on paper.  But that change might affect many different IT systems. It could take months for IT to update each system individually.  It might take so long that the business owner may come back with yet another change before the first is fully implemented. Compound this scenario by making it a time-sensitive request, and you will feel the frustration we’ve all experienced. Change keeps happening, but IT can’t respond quickly enough. Technology becomes the burden you can’t live without.

Enter SOA. Despite the technical jargon that surrounds it, service-oriented architecture truly is for the business person, mapping IT to desired business results: By mapping IT to desired business results, SOA lets business owners make decisions with fewer limitations from IT.

Say you run a credit card company and you have a traditional IT infrastructure. A customer calls to request a credit increase. Before you can grant her request, you need to perform a fresh credit check.

At this point you have a couple of options. You could put the customer on hold, pick up the phone and call your credit check partner, hoping that somebody’s available so you won’t have to wait. Or you could send the partner an e-mail requesting an updated credit score and tell the customer you’ll get back to her in a day or so. But your slow response could mean you lose the customer, perhaps to a competitor that communicates with the same credit check partner’s systems though a service-oriented architecture.

Here’s how your competitor’s SOA service works: Using industry standards, it sends out the customer’s name, address and Social Security number to the credit check company’s systems. “What’s her credit score?” it asks. A moment later a response comes in. No painstaking integration between the two systems is required.

In this example, the “service” part of the service-oriented architecture is just a bit of code that requests and receives a bit of data.  In other words, the credit card company can have its credit check database and customer account services connected or linked on demand.  And the services can communicate with each other through the SOA framework.  The communication can involve either simple data passing, or the services can coordinate activity between each other.  The result is that you can quickly check the customer’s credit and account records and approve the credit increase at the same time. 

Building a foundation for SOA is a process, but once the foundation is in place, IT changes become faster and easier. If you make a change affecting multiple systems, you need only modify the one service that is reused in multiple instances across the enterprise.

Service-oriented architecture is not a panacea.  It will not solve every business and IT challenge. Nothing will. But with the right planning and execution, SOA can deliver important benefits today and tomorrow.  SOA makes IT less of a constraining factor in business decisions, because it’s easier for IT to turn the business’s ideas into reality. And isn’t that, after all, the whole point of IT?

Get Started

Enterprise Library