Battle of the SOA Models…

MomentumSI’s Todd Biske took me to task yesterday with my posting, okay reposting, of SOA Levels.

“While these levels may be an accurate portrayal of how many organizations leverage technology over time, I don’t see how they are an indicator of maturity, because there’s nothing that deals with the ability of the organization to leverage these things properly. Furthermore, not all organizations may proceed through these levels in the order presented by Dave.”

Todd may have missed the point entirely in an effort to promote his own views. Also, he may want to Google the larger paper(s) I wrote on this topic, it’s a bit more comprehensive, albeit old.

Todd seems to be CMMing SOA. Which is logical, in some respects, but I want to make sure my work is not misrepresented.

Specially:

“The easiest one to call out is level 5: orchestration. Many organizations that are trying to automate processes are leveraging orchestration engines. They may not have a common directory yet, they may have no need for content based routing, and they may not have a service management platform. You could certainly argue that they should have these things in place before leveraging orchestration, but the fact is, there are many paths that lead to technology adoption, and you can’t point to any particular path and say that is the only ‘right’ way.”

Not really accurate.

Just so we are clear, I am indeed am saying that there is the notion of maturity within “my levels.” So, if you have an orchestration layer, Level 5, than you should have all of the levels below it. For instance:

“Finally, Level 5 SOAs are SOAs that leverage everything in Level 4 [and levels 3, 2, 1, and 0], adding the notion of orchestration.”

This includes “content-based routing” and “service management.”

Thus, there is a dependency on the more primitive levels which is built into the model. Very much like the concepts Todd is putting forth, but the approaches are a bit different.

Just thought I would clear that up.

There is actually a lot of confusion here, and Todd’s post really proves that out. Indeed, there are more SOA stacks than SOA solutions out there now, all are different, and all are slicing-and-dicing the SOA world in different ways.

At the end of the day I’m not sure we’re serving the end user community as well as we should by promoting conflicting arguments. A better approach may be patterns of success, which I’m working on now, and I urge others to focus on these patterns versus creating new stacks and models. The world has enough of them now. I’m putting my stacks in the public domain, so have at it if you wish.

More from me here…keep reading.