Gijsbert’s BizTalk Notes

I’ve been invited to do an architecture session on BPM with BizTalk Server and SharePoint at the Microsoft Business Process Conference 2008 in the Netherlands.

The presentation will be about architectural and design decisions that can be made in order to make it possible to also have human interaction capabilities in a SOA environment based on BizTalk Server and the various SharePoint products, InfoPath and Office.

You can register here for this event.

Looking forward to meet you there!

In the many BizTalk implementations I have architected and designed in the pas 7 years, in most cases there’s always the big question in the very beginning of these projects: Should we use a Canonical Data Model? And my answer in by far the most cases is: Yes!

Basically, the only reason why you would not implement it is the performance hit (instead of translating every inbound or outbound transaction once, you do it twice).

But the advantages galore:

• Less transformation maps: When you have 2 transaction types, 5 external data formats and 3 internal data formats you would need 5*3*2 = 30 maps in a traditional peer-to-peer situation. With a Canonical Data Model, you’d only need 5*2 + 3*2 = 16 maps. You can imagine that the number of maps grows exponentially with peer-to-peer maps, when introducing new transaction types, more external formats and/or more internal formats…;
• Less subscription rules: Instead of having to subscribe all your internal systems and transaction types to all the different externally received message types, you only need to subscribe them to the Canonical Data Formats. This means less management and easier troubleshooting;
• Less impact of schema changes: Whenever an internal or external schema needs a change, it only impacts the one map between the external message and the canonical data format or the one map between the canonical data format and the internal message. This applies to most schema changes (of course there are exceptions);
• Everyone does not need to know everything: Maybe this is the most important reason. When designing a map for receiving let’s say an X12 4010 850 Purchase Order, you only need to know that format and the PO Canonical Data Format really well in order to be able to do that. You don’t need to know anything about the internal data formats (SAP, Oracle, Dynamics, Homegrown LOB systems, etc.). The same applies to maps to and from the internal systems. The people designing these don’t need to know anything about the external data formats.

So, unless you really, really need the very best performance from as little hardware as possible, my answer to the question in the title of this post is always going to be: YES!