2.0 is to SOA what SOA is to ESB

About a year ago, I put out a blog post describing ambitions for SOA as an architectural basis within a single application domain. It was about relating messages, code, and data bi-directionally using transforms. Formal descriptions for those transforms could then become a new order of patterns in software architecture. The goal wasn’t to solve the gap between describing requirements and cutting code. It was to link the overall solution concerns more intelligently and pave the way for more declarative aspects and dynamic features.

The mistake I made was in trying to put a moniker around the concept – SOA 2.0! At the time, the ESB community was pushing really hard to say ESB==SOA. I wanted to distinguish architecting integration solutions – the bread and butter of an ESB – from architecting the traditionally opaque integral applications within an enterprise.

But calling it SOA 2.0 was clearly a bad choice. It’s sort of nice to be near the top of a search result (Google: “SOA 2.0”). Maybe your experience will vary, but I cringe when I see what company I have on the same page (but I did beat Oracle by a few months!). The post has been linked by others (Hinchcliffe, Little) but not exactly the way I hoped. A rookie blogging mistake if there ever was one.

Workflow Flavors

“Workflow” came up during a panel discussion I was in at Microsoft’s Tech-Ed conference this year. The word itself – like many IT terms these days – is overloaded to the point where it is hard to distinguish what a given “workflow toolkit” is meant to achieve. When explaining workflow concepts, I’ve started by making sure the audience understands the differences between 3 major categories of workflow:

• Human workflow is where information is conveyed to real people for action or simple notification. Workflow systems that present documents to employees have been around for years – so human workflow wins the right to actually use the word “workflow”. The key issue for human workflow is to have a system where non-technical users can actually program the routing.

• Orchestration is collaboration between application domains (and, by extension, between enterprises). BizTalk, Sonic, and ESB’s are all orchestration tools even though their target markets and general features may differ widely.

• Service Agents route execution of logic within a specific application domain. This is the sweet spot for Workflow Foundation. Service agents are under-served by toolkit vendors, which is surprising given the demands for content-based logic routing in the SOA world.

The trick for WF is to prove it can actually become the primary message pump for an enterprise application. But what drives me crazy is when people think of WF as some sort of “BizTalk Light”, which does both products a disservice.

PS. I haven’t blogged in quite a few months for no reason other than not being sure what to go into. So I thought a gentle entry like this might get the wheels moving forward.