So…almost three years ago (gulp) I wrote this
article on the use of orchestration naming conventions. In the post, I described
the value of orchestration diagrams and their use throughout the development cycle.
In my current engagement, we are doing analysis on the integrations between ERP, warehousing,
front-end commerce systems in multiple channels, and a PIM (Product Information Management)
solution. I’m finding that the BizTalk designer – used just as a modeling tool
with the constructs that it provides but not filling in deep detail – eliminates so
much of the ambiguity that a simple Visio can leave on the table. So I
thought I’d repeat my (now old) thoughts on this topic:
The opportunity exists to use an orchestration diagram in several interesting ways
within a project lifecycle:
-
As a way to capture an initial high-level design, using all the orchestration shapes
as intended but not yet bothering with real maps and schemas. Stubbing out schemas
(so you can declare messages and variables to be of proper types) and maps will allow
you to flesh out the orchestration diagram(s) quite a bit, using the compiler as just
a way to check for consistency. All of the external system interactions, communication
patterns, decision points, parallel vs. joined flows, etc. can be represented at this
point in a shell orchestration. -
As a way to gain consensus with the development team & business sponsor about
whether the right functionality is indeed going to be built. The high level
design just described is a great tool for this discussion. Put your orchestration(s)
up on a wall with a projector and do a walk-through with as many of the project stakeholders
as makes sense. Or use a tool like CutePDF to
print the orchestration as a PDF to send around via email. -
As a way to estimate work. The various shapes in your initial orchestration
can often represent reasonable granularity for time estimates. -
And finally, as a way to guide project work…Rather than starting with the entire
orchestration that you created to support steps 1-3, you might find it easier to create
a new orchestration that represents the path(s) you are tackling at a particular point.
You can cut/paste portions of that original orchestration or simply use it as a reference
for what comes next it serves as your outline.
To help realize some of these benefits, naming conventions within an orchestration
are quite important
While the naming conventions are good practice for variables, Messages, Multi-Part
types, etc. they are even more import for the workflow shapes. The goal is to
ensure that the intent of each shape is clear, and that the text associated with the
shape conveys as much as possible given the space constraints. Make liberal
use of group shapes where needed. In this way, a non-technical audience will
be able to use the orchestration as documentation.