Orchestrations as Business Processes, not Technical Processes (Part 2, Development)

Abstract: Once I read a book that said: “A complex system that works is invariably found to have evolved from a simple system that works”. That’s right for orchestrations, especially because they mix business and technical elements. Let’s see an approach to start simple and evolve to complex.

A good approach that works fine for me is the process that I call “make it, make it compile, make it work” (ha! I cheated; this is stolen from TDD folks). Well, it has some similitudes with TDD, and some specific characteristics. The process is:

1. Make It. Just draw the business process into BizTalk Orchestration Designer. Forget about tech and implementation details: it’s just the first version of the process into BizTalk. Useful for printing and documentation purposes, but no more, so you should move quickly to step 2.

2. Make It Compile. Include all the elements necessary for the compiler, but forget about the implementation details. You should include:

   1. Messages and variables, but doesn’t matter the types (all strings, for example). So, don’t create schemas yet.
   2. Port and port types. Define right names, but left bindings as "specify later"
   3. Correlation sets, with no or dummy properties
   4. Components to be called from orchestrations. Create empty components, with only interface.
   5. Transformations: do not create maps, just add dummy assign shapes.

3. Make it Work. The long part :-) go on working until it works as expected. A grosso modo, do the following:

   1. Create schemas and create maps
   2. Promote properties, fix correlation sets.
   3. Assign right values to variables, loop conditions, decision expressions, etc.
   4. Include Scopes, set transaction properties, add error handlers.
   5. Fill the components with logic.
   6. Create unit tests for the components, and tests for the orchestration. Using whatever unit testing framework you like.

And remember: the orchestration is finished when it works, and it works when all the tests cases work!

If you read the first part of this post, you will notice that design and development stages may overlap. That’s a nice property of designing/developing business processes with visual tools: the typical gap between design and development tend to disappear, and analysts and developers start talking in the same language.

feedback on this?

Comments

• Anonymous
  April 13, 2005
  Nice post. My only difference is in when to create your schemas. I always apply the "begin with the end in mind" principal and create my final output's schema first and then work backwards. The helps me to always keep in mind what the end "product" of my orchestration is while I'm developing things.
• Anonymous
  April 13, 2005
  I agree about schemas. When you start to develop an orchestration, the schemas involved should be as finished as possible. In fact, schema definition is probably the first task in projects...