Don Box made an insightful post clarifying some of his statements that have been warped out of context as of late.
I totally agree with Don on this one. SOA does not mean the end of Objects. While Services are wonderful and can be pretty powerful in a large, distributed application, they can be overkill for a smaller project. If you're going to plant some small flowers in a flowerbed, you would not (at least if you are somewhat sane) plant those flowers using a large Bobcat.
The problem I see with SOA is not a problem with the architecture itself, but with the application of that architecture by “software engineers”. It's eerily similar to the problems I see with Software Design Processes. In software development, there is no such thing as a “silver bullet”, whether it be with testing, development, deployment, etc. If you look around, you see these phenomena a couple of times every few years, basically everytime a new acronym comes across our table, OOP, XML, XP, and now SOA. When you're holding a hammer, everything begins looking like a nail.
Why does this occur? My belief is that this occurs when developers start to emphasize technology over the problem domain itself. I guess one could say it is human nature. Better yet, one could say it is man nature. We Men have a tendency to start trying to solve a problem from the start (even if there is not a problem to solve). Women, on the other hand, tend to discuss the problem first. Listen! Listen! Listen! I'm sure when the wheel was invented, men started putting wheels on everything.
<Tangent>
Consumer: “Excuse me, dear sir, but what is that nifty contraption that you have there?“
Inventor: “It's the latest, greatest, bestest, friendliest, rolly-iest device invented to date“
Consumer: “Yeah, but what is it?“
Inventor: “Uhhhh, well actually, it's a full size picture of a man of the future (called “The Rory“) on “wheel-blades““
Consumer: “whatever...“
Or something like that. I'm not sure if “The Rory“ was really known that far back, but I like to thank so. After all, if he's as popular as he is today, why can't he be that popular several centuries ago? If you think about, The Rory has such amazing Star Power that he basically transcends the Space-Time Continuum. My own theory is that The Rory is the real-life embodiment of “Q“. But I realize some of you may not agree (those that don't agree with me can go to H-E-Double Hockey Sticks (I'm just kidding (not really kidding but kind of joking (and by joking I mean that I am totally serious)))).
</Tangent>
Anyways, how do we fight this “nature“ of ours when applied to software engineering? I think that the most important point to make is that when you are first analyzing any problem domain, DON'T THINK ABOUT IMPLEMENTATION TECHNOLOGY!!! Discover what the problem domain is all about first. Only after you understand the problem domain fully can you start asking what technology is best suited for implementation. After all, it may be that J2EE is the best environment, or .NET may be the best environment, or perhaps unmanaged-C++ may be better.
In closing, when you are engineering application, don't think like a developer. Put on your “engineering hat“ (aka, “Women Hat“ for us Men ;~)) and attempt to fully understand the issues at hand. Good Luck out there and happy engineering :~).