I was speaking with a bright fellow at Burton Group's Catalyst Conference last week and he made the point that he's not interested in either/or technology paradigms, he's trying to figure out how to embrace "and" scenarios.
You can spend a lot of time reading about service-oriented architecture and not come across a better explanation of it than that. For instance, recently we ran a story on how Representational State Transfer (REST) could be the coming thing in Web services development, but don't take that as a signal that SOAP is on its last legs. REST and SOAP will co-exist.
Why? Because SOA is an "and" approach to technology, not an "or" approach. We sometimes get stuck in the Java vs. .NET paradigm as well. Yet the truth is, you'll be using both tactically inside your strategic SOA plan.
Last week we had a story on BPEL4People, which aims to tie together computer and human workflow. After all, you do need to the two to synch up at some point. Getting back to Java vs. .NET, there's some who engage in a side BPEL vs. Windows Workflow Foundation (WF) debate. Does this trumped up conflict enlighten anyone's universe? I suspect not. There's going to be times, like if you're a .NET programmer, that WF will make more sense. There will be others when you're looking for orchestration tools that extend beyond the Microsoft universe and BPEL will be the foundation for that.
We ran another story last week on how SOA management still isn't quite ready for full-blown heterogeneity. Simply put, you've got a wide variety of technology to manage. You'll need a management plan that's heavy on "and," probably far more so than what you've got in place today.
Burton analysts expounded upon many similar points last week and we'll have overview coverage tomorrow. One of the key things that emerged from the conference is that users need to constantly remind themselves SOA is an approach to technology, not a specific set of standards or a software package. It aims beyond petty technical squabbles.