Loose coupling is a good thing, except when applied to the definition of terms

Todd Biske of MomentumSI and David Linthicum of Real World SOA are having an argument about SOA levels and maturity.

After reading through the paper in question I'm not nearly as interested in the argument as I am in the definition of orchestration and its placement at level 5 in David's model. I like to take issue with people who loosely couple terminology and concepts, especially in the SOA world, because it is certainly true that part of a successful SOA is a common language between business and technology and dag nabbit, it's obvious we aren't there yet by the varying use of the term "orchestration" to describe both application composition and business process automation.

Orchestration of applications is a high level automation mechanism that can't really be completed until there is a solid underlying SOA infrastructure and set of common services in place. It's the pinnacle of SOA achievement, the ultimate proof that an organization SOA can indeed provide the benefits touted by pundits. But orchestration of services should also be the mechanism by which applications are constructed.

While it certainly could be argued that an application actually is a business process and therefore rightly belongs higher in the SOA stack, I would point out that a single application does not sit at the same level as a business process - which should be loosely coupled to applications, as applications are loosely coupled to services - and while business logic is certainly one component of an application, it is the orchestration of services into an application that create an integration point into a wider business process. If you try to force a single service into being a process, you've destroyed your SOA by dilluting the granularity of the service too far, thus making it more difficult to achieve both IT and business agility.

Because many of the specific processes that comprise a single application are peculiar to the application and not some larger business process, they are not reusable are therefore not orchestrations in the business process sense but rather in the application sense.

A business process necessarily comprises abstract concepts. An application is the concrete manifestation of one of those concepts which, when orchestrated to interact with other applications, implements a business process. But both involve orchestration - just at differing levels.

So I'm not arguing that orchestration of business processes shouldn't be at level 5, I'm just arguing that the definition of orchestration can be interpreted in more than one way and should certainly be more narrowly defined in order to avoid confusion and get us all on the same page using the same terminology.

Imbibing: Mountain Dew