• What is Service-Oriented Architecture (SOA)?
• What is a service?
• What's the difference between SOA and web services?
• How do I know whether I should adopt SOA as a strategy?
• What are the advantages of SOA?
• How do I balance the need for architecture planning in SOA with the need to prove value to the business quickly?
• How do I know which services will provide the most value for my investment?
• How will SOA affect my IT group?

What is Service-Oriented Architecture (SOA)?

SOA is a confusing term because it describes two very different things. The first two words describe a software development methodology. The third word, architecture, is a picture of all the software assets of a company, much as an architectural drawing is a representation of all the pieces that together form a building. Therefore, service-oriented architecture is a strategy that proclaims the intention to build all the software assets in the company using the service-oriented programming methodology.

What is a service?

Services are software chunks, or components, constructed so that they can be easily linked with other software components. The idea behind these services is simple: Technology should be expressed in chunks that business people can understand rather than as an arcane application such as ERP or CRM.

At the core of the services concept is abstraction, the idea that you can assemble software code into a chunk meaningful enough that it can be shared and reused in many different areas of the company. For example, there is a lot of software code that goes into creating an automated task such as sending a query to a credit reporting website to find out if a customer qualifies for a loan. But if the programmers at a bank can abstract all that code to a higher level—that is, take all the code that was written to perform the credit rating check and package it into a single unit called "get credit rating"—the programmers can reuse that chunk the next time the bank decides to launch a new loan product that requires the same information rather than having to write the code from scratch.

Developers create the abstraction by building a complex wrapper around the bundled code. This wrapper is an interface that describes what the chunk does and how to connect to it. It's an old concept that dates back to the 1980s, when object-oriented programming first appeared; the only difference is that today, the ambition for the size and sophistication of these software objects is far more grand.

For example, at telecom company Verizon, the service called "get CSR" (get customer service record) is a complex jumble of software actions and data extractions that uses Verizon's integration infrastructure to access more than 25 systems in as many as four data centers across the country. Before building the "get CSR" service, Verizon developers who needed that critical lump of data would have to build links to all 25 systems—adding their own links on top of the complex web of links already hanging off the popular systems. But with the "get CSR" service sitting in a central repository on Verizon's intranet, those developers can now use the simple object access protocol (SOAP) to build a single link to the carefully crafted interface that wraps around the service. Those 25 systems immediately line up and march, sending customer information to the new application and saving developers months, even years, of development time each time they use the service.

There are many different ways to connect services, such as custom programming links or integration software from vendors, but since 2001, a set of software communication mechanisms known as web services, which are built upon the ubiquitous World Wide Web, have become an increasingly popular method for linking software components together.