I know everyone already piled on here, but I added the following to the comment section under the article:
READER FEEDBACK Miko Matsumura Wed, 2008-09-24 11:42 Funny to see so many people piling on... I would pile on myself but it seems like most of what needs to be said has been said. The thing that frustrates me about this article is that it is printed in CIO... With such a significant number of SOA "projects" not having C level visibility, you would hope that CIO would help executives understand the bigger picture of SOA, not such a drilled down piece that misses the point. SOA "projects" arent even the point. A SOA "project" doesnt need C Level support because it wont do anything substantial. SOA needs to be implemented across a set of projects, and in fact you could argue that SOA should be implemented across most, if not all IT projects going forward. This is the concept that deserves CIO support and this article misses that point completely. My 2 cents, Miko --- In [email protected], JP Morgenthal <[EMAIL PROTECTED]> wrote: > > I've added to the bashing...thanks for the post Rob. > > JP > > On Sep 23, 2008, at 3:43 PM, Rob Eamon wrote: > > > This article can be viewed at: > > > > http://www.cio.com/article/449921/The_Definitive_Definition_of_SOA? > > contentId=449921&slug=&source=nlt_cioinsider > > > > << 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. >> > > > > > > >
