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.