"What makes a good BizTalk project"

Question

"What makes a good BizTalk project" is a question I was asked recently by a client's head of IT. It's rather open ended, so rephrasing it slightly to :

"what are you top ten best practices for a BizTalk 2006 and onwards projects - not limited to just technical practices, eg organisational"

Answer 1

I'll start with Environment and Deployment Planning. Especially testing deployment and matching your QA/Stage (whatever the pre-production environment is) to the production environment so you don't find out some weirdness at midnight when you are trying to go live.

Answer 2

I wrote an article called "Top 10 BizTalk Server Mistakes" that covers some key best practices in terms is usable information rather than a simple list. Here's the listing:

1. Using orchestrations for everything
2. Writing custom code instead of using existing adapters
3. Using non-serializable types and wrapping them inside an atomic transaction
4. Mixing transaction types
5. Relying on Public schemas for private processing
6. Using XmlDocument in a pipeline
7. Using ‘specify now' binding
8. Using BizTalk for ETL
9. Dumping debug/intermediate results to support debugging
   1. Propagating the myth that BizTalk is slow

...and the link to the complete article: [Top 10 BizTalk Server Mistakes] (http://artofbabel.com/columns/top-x/49-top-10-biztalk-server-mistakes.html)

Answer 3

The key point is to emphasize to the client that BizTalk is a swiss army knife for interop... an expensive swiss army knife. A programmer can wire up two enterprise systems with a WCF application as fast as you can with BizTalk. The key things to include/require when using BizTalk is to:

1. Have more than simple point integrations. If this is all you have, fine, see the rest.
2. Have all or a portion if a process that is valuable going theough BizTalk so that you can instrument it with BAM and provide process monitoring to the organization... maybe even some BI.
3. If you are implementing a one to many or many to one scenario, use of the BizTalk ESB patterns will pay deividends in th elong run
4. When there are items that need to be regularly tweaked - threshholds, URI'ss, etc... use of the Business Rules Engine can provide an easily maintainable solution.
5. When endpoints might be semi connected, BizTalk bakes in queueing of messages for no extra effort.
6. Complicated correlations or ordering of messages.
7. Integrating with exisitng enterprise systems can be simplified with the adapter packs provided as part of BizTalk. This alone can save big bucks. Asking Oracle, PeopleSoft or Siebel folks about XML and Web Services can be a challenging experience. The adapters get you and BizTalk through the enterprise apps' front door and reduces the work for themsignifcantly.
8. There are more I just can't think of at midnight.

Any of these items make BizTalk a winning candidate because so much of it is given to you with the platform. If you are not being required to provide any of these, you should really attempt to deliver some of these beneftis in highly visible way to the client. if you don't it's just an expensive and under utilized swiss army knife.