Author: Richard Seroter

It’s just over a year ago that my company switched from their previous EAI platform to BizTalk Server 2006.  Over that time, we’ve learned some best practices for setting up a brand new BizTalk program, and I thought I’d share my “Top 10” recommendations for organizations getting started with BizTalk.   The below recommendations aren’t in any particular priority-based ordering …

1. The first project should be a quick win.  I’m sure that BizTalk Server was brought into your organization with a particular project in mind.  However, unless you have all the resources lined up to help with a complex project (see tips #2 and #3), I suggest identifying a “quick win” project that can be built with relative ease and minimal complexity in a short amount of time.  This helps establish the platform within the organization and builds confidence among the team.  If you bite off a monster project right off the bat, you greatly increase the risk of failure or disenchantment with your purchase.
2. Get an expert.  If your plan for getting BizTalk Server up and running is to hand a BizTalk Server 2006 book to your best developer and saying “read this over the weekend and be ready to lead a project on Monday”, you’re hosed.  You really need to hire (a) a full-time employee or (b) consultant to help you get the platform established in your company.   Why?  Integration solutions are a different beast than standard custom applications that developers are familiar with building.  There are different paradigms, patterns and gotchas that only an expert can help with.  Now, the tricky part is, there aren’t a lot of experts out there.  In my experience, significantly less than 50% of all folks who put “BizTalk” on their resume are qualified to lead your team.  I suggest seeking a BizTalk expert in your area to help with interviews.  Ping your local Microsoft specialist, or reach out to an MVP.  You want the best person possible brought onboard, and you should be confident that you’re getting someone who knows what they are doing.
3. Invest in training and building a “Center of Excellence.”  Now, a “Center of Excellence” for BizTalk may mean 20 people, or 2 people.  Either way, you want a team of people who are well trained in BizTalk and can provide advice on upcoming projects.   My first year here, I taught 8 BizTalk classes to 100+ folks, and now I can have intelligent conversations about BizTalk with project managers, business analysts, developers, architects and system administrators.  An in-house team of dedicated resources (i.e. not weekend BizTalk warriors) that can evangelize the product and guide your success is critical to stabilizing your platform.
4. Commit to, and enforce naming standards.  This is so important.  As the amount of deployed projects increase, the more critical it is that all developers and administrators use common names for artifacts and configuration items.  Any developer should be able to pick up any other developer’s BizTalk solution and be able to troubleshoot it without the aid of the Rosetta Stone.  It’s just as easy to type a good artifact name as a bad one.  Your “Center of Excellence” leaders should have the authority to halt the deployment of a project if the naming standards have been ignored.
5. Agree upon code review items and processes.  Before any project is deployed, you should require that a full BizTalk code review is executed.  Even the smartest developer benefits by having a second (or third/fourth/fifth) set of eyes on their solution.  Maybe they missed a pattern, or built something that won’t scale.  A good code review will catch that.  I posted our code review guidelines on my blog last year.
6. Set up a standard release management plan.  Let’s assume you have a BizTalk development, test and production environment.  You want clear guidelines as to how artifacts move between each set of servers.  Who does installations?  Where do we drop the installation packages?  How are differences between environments (passwords, server names) managed?  A new build of a deployed solution should have a very clear path to production that any administrator can execute.
7. Identify your disaster recovery / archive  / purge strategy.  Don’t wait until after projects get deployed to commit to platform maintenance.  Your disaster recovery plan needs to be set up right after BizTalk Server is first installed.  Are you using log shipping?  Or doing a more local backup and restore?  What is your Recovery Point Objective (RPO)?  No more than 15 minutes of data lost?  The archiving/purging jobs on the BizTalk tracking database are NOT enabled by default.  You need to consider how long to keep tracking data and get those jobs enabled before projects get deployed.  Otherwise, you end up with an increasingly slower system.
8. Define source code and server access control.  Put BizTalk artifacts in source control.  You don’t want critical project source control sitting in a zip file on a shared drive.  Figure out who needs access to BizTalk source control (which may contain bindings with passwords) and lock that group down.  Also, determine a process for adding folks to the production “BizTalk Operators” group.  At my company, we committed to distributed ownership where a central group “owns” the platform, but, divisions with BizTalk projects are set up as “Operators” and can perform basic maintenance on their own appliations.  This way, the central group only deals with critical issues, while local divisions can resume suspended messages, or turn off their ports for maintenance.
9. Establish error reporting and monitoring solutions.  My company uses Microsoft MOM for BizTalk monitoring.  If you don’t have MOM in house, then use whatever is available, but use SOMETHING.  You don’t want to find out that a particular host has been offline for 2 weeks because no one was alerted that a problem occurred.  Also, consider establishing a standard “error logging” framework for your developers.  Do you write to the Event Log with a specific string pattern?  How about a database logging system using something like Log4Net?  If you don’t do this, I’ll guarantee that you’ll end up with countless different ways that each deployed solution records their issues.
10. Stay actively in tune to hotfixes and upcoming releases.  Microsoft regularly releases hotfixes for BizTalk, and many of them address important areas.  We’ve found a number of hotfixes that solve development or environmental issues that we had been banging our heads against for days.  If web searches for your problems don’t turn up valid results, consider browsing the Microsoft BizTalk Solution Center.  Also, keep an eye on product announcements, toolkits or whitepapers that may help your team continue increase their efficiencies with the product.

So there you go.  My company learned some of those lessons above the hard way, so hopefully I can save someone else a little heartache.

For those of you who have helped establish BizTalk for your own company (or as a consultant), are there other recommendations you’d like to share?

Technorati Tags: BizTalk

A few interesting Microsoft Knowledge Base hotfixes for BizTalk Server 2006 were recently added and worthy of sharing.

• FIX: The Log Shipping feature may not restore database backup files in BizTalk Server 2006.  Really?!?  Seems kinda important.  I love hotfix titles that are all nonchalant, but upon consideration, are pretty freaky. The article says that the only way Log Shipping can restore the databases is if there is already a complete set of backups, and, none of the backups are corrupt.  I can only assume (since it isn’t stated anywhere) that this hotfix allows Log Shipping to restore any available backups, even if some are missing or corrupt.
• FIX: A receive location that uses the file adapter does not retry when a network failure occurs in BizTalk Server 2006.  Apparently even if a receive location is set up to retry on network failure, that behavior isn’t consistent and the receive location may become instantly disabled.  Good times.
• FIX: The per-instance configuration setting does not affect message processing on a computer that is running BizTalk Server 2006.  If you have a request-response receive location, the per-instance pipeline settings on the send (response) pipeline aren’t applied, even though you can see the settings.
• Four properties have been added to the ErrorReport namespace context of BizTalk Server 2006 R2.  We’ll end on a positive note.  If you’d like a few new “ErrorReport” subscription values (ErrorReport.FailureTime, ErrorReport.FailureAdapter, ErrorReport.FailureMessageID, ErrorReport.FailureInstanceID), and are running BizTalk Server 2006 R2, this is the update for you.

Technorati Tags: BizTalk

If you’re in the Los Angeles area, consider joining me at tomorrow’s Connected Systems User Group meeting.  The topic is “BizTalk Development Best Practices” and the fearless speakers are Chris Romp from Microsoft and that character Brian Loesgen from Neudesic.  Should be fun.

Technorati Tags: BizTalk