SOA stands for Service Oriented Architecture. It’s one of those acronyms you see bandied about all over the place. But what does it really mean? Here’s my best guess and some SOA resources.
There are all kinds of buzzwords that we have to deal with on a daily basis. Understanding what they really mean and what’s behind them helps to make it easier to decide if a given technology is really good for the business or if the terms are just market-speak intended to separate us from our budget.
SOA is one of those new acronyms you see all over the place, but without a firm definition. Let’s see if we can nail it down a little.
What is SOA?
SOA stands for Service Oriented Architecture and is supposed to define a mind-set for application development. The problem with the term is that it’s one of those terms that is usually defined with lots of marketing language around it. The exact meaning often varies subtly depending on the vendor you’re talking to.
For example, Microsoft’s Web site describes SOA this way:
The goal for a SOA is a world wide mesh of collaborating services, which are published and available for invocation on the Service Bus. Adopting SOA is essential to deliver the business agility and IT flexibility promised by Web Services. These benefits are delivered not by just viewing service architecture from a technology perspective and the adoption of Web Service protocols, but require the creation of a Service Oriented Environment that is based on the following key principles:
And the site continues to list several defining principles that explain that SOA goes beyond platform and into practice.
IBM’s Web site defines SOA as being:
Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services. With the Smart SOA approach, you can find value at every stage of the SOA continuum, from departmental projects to enterprise-wide initiatives.
Smart SOA apparently is IBM’s take on SOA which is supposed to be… well… smarter than the approaches taken by other companies.
The SOA Consortium, a group dedicated to spreading the good news about SOA to businesses, is equally fuzzy about what SOA is and what it does:
The SOA Consortium is a new SOA advocacy group comprised of end users, service providers, and technology vendors, committed to helping the Global 1000 successfully adopt SOA by 2010.
The SOA Consortium mission, strategies, and tactics center on the following premises:
Service-oriented architecture adoption is a key enabler for the twenty-first-century enterprise
Achieving the benefits of service-oriented architecture requires significant changes for both IT and business executives
Service-oriented architecture is perceived by business executives as an IT integration and productivity story, rather than a business agility story
Enterprise SOA practitioners would greatly benefit from a vibrant practitioner community to drive local, business-driven, SOA success, and to spur broader enterprise, and industry-wide, SOA adoption.
As you can see, there is a lot of marketing and management speak surrounding the phrase. SOA isn’t a thing per se, as much as it is a concept. Because it’s conceptual in nature, it’s an easy term for vendors to spin their products around.
SOA represents a supposedly new and different way of approaching how we build systems in an organization. The idea is not to focus so much on the mechanics of a solution — the hardware, software, and networking things we need to get something done — but more on the business processes that need to be addressed.
Rather than using a shotgun approach, SOA is supposed to be more laser focused. For example, if your organization has special accounting needs, you could deploy a large accounting suite in the business with all its preconfigured features and extensions. You can hope that it has the customer service, shipping, and accounts payable/receivable feature that you need. If something doesn’t quite work, your users are forced to work around the product.
In a SOA approach, you break down each business process into components and build services around each process. Those services work with other services you create to build an overarching solution. Ideally each service, although related to others, is independent enough that it can be modified on its own.
So, with the accounting example above, rather than one large accounting suite that attempts to be all things to all people, you build services around each business process — one accounts receivable service, a shipping service, an inventory service, and so on. Each service is designed and built with its specific needs in mind but also being mindful that it may need to work with other services as well. When you’re done, you have a full package tailored to the organization’s specific needs. Changes can be implemented to one service quickly and inexpensively without causing too much of an impact to another system.
Most of these services are “officially” built around open Web platforms. That said, naturally every vendor like IBM, Sun, Oracle, Microsoft, and so on has their own SOA solution. IBM likes to build their SOA solutions around WebSphere. Microsoft uses Biztalk. Oracle has an entire SOA Suite that they offer.
As you can see, nailing down the true meaning of SOA is like nailing the proverbial Jello to the wall. You can find out more about SOA by checking out these resources:
SOA Information on TechRepublic includes:
- SOA Management: Bringing SOA into the Mainstream of IT Operations
- SOA Governance and Management: Enabling SOA to Control the Chaos of Enterprise IT
- The Business Case for SOA
- Demystifying SOA
- Getting Started: Your Guide to SOA Success
Also, there’s an entire blog on TechRepublic’s sister site ZDNet written by Joe McKendrick that focuses on SOA.
The bottom line for IT leaders
The term SOA can mean different things to different people. At its core, it’s merely a concept about how to approach building solutions efficiently to meet business needs. Not all SOA solutions offered by vendors are comparable. Don’t forget the vendors will take advantage of the nebulous nature of the concept to try to peddle their wares. If you decide to use SOA as the basis for application design in your organization, make sure that your definitions match before purchasing.