The Definitive Definition of SOA

One thing I’ve noticed since I started writing about SOA is that SOA pundits seem to be obsessed with the definition of SOA. Some people feel think business processes have to be part of the definition. Some people focus on interaction vs. integration. Some object to referring to SOA as equivalent to Web services or WOA, others believe that WOA is not only coupled with SOA, WOA is the future of SOA. One person who shall rename nameless believes that, while WOA and SOA may be different, SOA standards should spring from WOA. Still others think business agility is what defines SOA. Yet others link SOA with governance as the critical differentiator. I could go on ad nauseum.

Forget all that. I have what might be the world’s simplest definition of SOA, and my definition has the distinction of being able to shed light on why SOA is becoming popular now, as opposed to decades ago when companies like IBM were trying to get it off the ground under different names.

SOA is a networked subroutine.

Anything you add to that definition is unnecessary window dressing. In most cases, the subroutine will perform business functions, but why can’t you build a scientific function as a process, too? Of course you can, and it would still be SOA. You may end up using Web services as part of your implementation, but it’s still SOA, isn’t it? In most cases, SOA should contribute to business agility, otherwise you probably shouldn’t concern yourself with it. But the benefits of using SOA do not define SOA. Failures at reaping benefits from SOA are still based on SOA, aren’t they?

Why SOA Now?

Here’s why the definition may help you understand why SOA is growing. How many of you have ever written a program? At some point, you realize that you’ve coded basically the same process two or more times in the same application, and it seems like a waste of effort. So you yank the code out and make it a bit more generic, and then call that code as a subroutine. Now you can reference that subroutine whenever you need it without having to rewrite it again and again.

I chose the term “subroutine” because it’s about as BASIC as you can get, pun intended. As the art of programming got more sophisticated, so did the terms. Subroutines became procedures. Then programmers discovered object-oriented programming, which grouped procedures according to data and calls the combination objects with methods. Next came networked objects in the form of DCOM, CORBA, DCOP, or what have you. Then the age of the Internet dawned, and web services were born. Due to the nature of the web, this was a bit of a technological step backward, but the fact that you could access services over the Internet was a major step forward.

You might be thinking at this point that I’m about to conclude that SOA is the next logical step. It is the next logical step, but that’s not nearly as important as the fact that SOA benefits from the experience we have gained from all that preceded it. SOA is growing in popularity now because the tools to create SOA are now available and easier to use than ever. Average programmers now have enough experience under their belts to be able to understand SOA and code it, and that is why SOA is increasing in popularity. We could have reaped the benefits of SOA ages ago, but fewer people knew how to get there, then.

When you get down to it, all SOA really amounts to is extracting something you would normally program into a monolithic application and running it as a service that two or more applications can access over a network. That, my friends, is a networked subroutine.

With that definitive definition out of the way, we pundits can now move onto more important SOA topics.