So what about ‘workflow’?

It is often asked where the orchestration is handled between Service Domains. This differs fundamentally depending on the technical implementation and therefore what the Service Domain aligns/compares to in the business applications. In more traditional ‘monolithic’ transaction processing systems the Service Domains simply map to major functional modules that have hard wired interfaces and embedded processing logic. In this environment the workflow is likely to be built or integrated into the application itself. At the other end of the spectrum in a loose coupled cloud environment all communications are queue/event based and there is no central orchestration governing the interactions between Service Domains. In some intermediate “client server” models Service Domains may be interpreted as ‘passive’ capabilities and there can be an orchestration layer that coordinates predefined exchanges between these capabilities. The internal behavior will also vary greatly in different implementations and these may sensibly integrate workflow capabilities when appropriate. In summary the Service Domain does not require or replace all needs for workflow management. The role for workflow needs to be interpreted for the specific technical environment that the Service Domain partitions are applied to