Orchestrations as Business Processes, not Technical Processes (Part 1, Design)

  • Article

Abstract: In a Business Process Management oriented project, orchestrations are business processes, not technical processes. A common mistake (mistake from the BPM point of view) is to use orchestration designer as 'visual coding'.

If you take the orchestration as a technical process, you are probably adding shapes and actions to deal with technical problems. At the end, the orchestration is not a representation of a business need. It’s a ‘visual piece of code’ that performs some functionality. This is not strictly bad, but it’s only readable by consultants and developers. It's hard or impossible to understand by business users. Worst, as things tend to get complicated by themselves, you'll probably end up with a huge, messy and difficult to maintain orchestration.

So during design and development stages it’s very easy to get lost in technical stuff. In order to avoid this, here is a proposed (and very simplified) design process:

  • First, the process should be designed from the business point of view, by a business user (note I've written process, not orchestration). This design can be done using Visio or any other diagramming tool. It’s a good idea to use the Orchestration Designer if the business user is assisted by the consultant (i.e. working together, some kind of pair designing).
    The result of this first step could be a simple BizTalk Orchestration that represents the business process, but contains no logic inside.
  • Second, a technician (consultant, developer) transforms the process into an orchestration, and evolves it with technical aspects (variables, error handling, component calls, etc.)
  • But never loose the business view of the orchestration. The best way to check this: ¿is the orchestration readable and understandable by the original business user? -> if not, you should refactor to abstract tech details from the main process.

Exception: The exception of this rule is, of course, when a technical process is the goal, but in this case we are not talking about BPM.

 

Coming soon: part 2. Orchestration development process viewed as “make it, make it compile, make it work”