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.