I've been working on a new version of the 12 Steps, now just called SOA Steps. In my career I've written many methodologies, including structured application development, component development, object-oriented development, and now the larger, more holistic, but much more valuable SOA. I continue to learn, and refine my approach.

Methodologies are double-edge swords. When I was working for larger consulting firms in my youth they were really too cumbersome, designed primarily to turn the crank of billable hours more so then creating good information systems. However, not using a methodology could mean you're missing some very important steps. Thus, you need to strike a balance between too much rigor and not enough. That is what I'm attempting to do this time.

A few things to note at this point:

The core issues continue to be the ability to have a semantic level, service level, and process level understanding of the problem domain. No getting around that and that's the core work to be done when defining and designing a SOA.

The data resides in a data services layer which is really an abstract data layer existing above the physical databases. That layer is design to serve the services layers providing information bound to behavior. The abstract data layer is really just a re-instantiation of the physical schemas and data model into something that's more useful for the SOA, and the services that make up the SOA.

Process is still defined as common notion, and not defined as orchestrations as of yet. Albeit you can define your processes as orchestrations it's a bit early in the game to figure out if the process layer will be a process integration tool or an orchestration tool in its end state. Perhaps it should always be a common notion.

That's all for now.

Posted by Dave Linthicum on October 18, 2006 04:17 AM