Richard Seroter has a great article entitled You’ve Just Bought BizTalk Server. Congrats. Now What? over on his blog, in which he lists his top ten recommendations for organizations getting started with BizTalk. He highlights some important points – which I wholeheartedly endorse – including: committing to, and enforce naming standards; setting-up a standard release management plan; defining source code and server access control; identifing your disaster recovery / archive / purge strategy.
However, I’d like to add a few more to this list (I know it was meant to be a ‘top 10′ but I believe these are equally important):
- Invest in a good quality infrastructure – Even though this will probably blow your departmental budget, invest in a good quality infrastructure for your BizTalk environment: ensure you have SQL Server clustered in (at least) an active/passive configuration, active/active if you can handle some performance degradation in the event of a node failure and cluster your Enterprise SSO environment; A good quality underlying SAN (ensuring that your BizTalk SQL Server data and log files reside on separate LUNs); and sufficient BizTalk servers to accommodate a receive tier, processing tier (orchestrations) and send tier, which will mean 6 BizTalk servers minimum in a good enterprise setup. When buying servers always purchase hardware with extra capacity (even if it is initially unused) such as additional CPU sockets, giving you the option of a quick-win when you need to scale up your existing hardware, before starting to scale-out. Given that BizTalk 2006, BizTalk 2006 R2 and SQL Server 2005 can run almost natively on 64-bit hardware, go for 64-bit CPU’s. Finally, invest in good quality sys-admins who know what they are doing with all this expensive kit.
- Invest in smoke, test and staging environments – Don’t deploy from your dev environment straight into live. Investing in smoke, test and staging environments is worth the cost incurred when compared to the cost of your live environment going down, because the latest solution release or hotfix introduced some unexpected bug or configuration error. Furthermore, these environments don’t have to be expensive: using virtualisation such as VMWare’s ESX server or Microsoft Virtual Server 2005, environments can be provisioned relatively cheaply and on demand – several environments can run on the same hardware for example.
- Get your DBA’s involved in the project – BizTalk has SQL Server at its core and this environment needs to be performing well to ensure QoS for your BizTalk environment. Richard touched on this point in his article, however it can’t be stressed enough: although BizTalk to a great extent is a ‘black-box’, DBA’s need to ensure that the SQL Server jobs are correctly running, databases (such as the tracking database) are regularly archived or purged, and valid backups are being correctly created, logs are shipped to your DR site and successfully restored. One tip I have learned the hard way: engage your DBA’s early, otherwise they will become disillusioned and the dev team will end up nursing your databases.
- Read the BizTalk blogs and newsgroups – There are now more than 60 active BizTalk bloggers who have either solved, or who can offer advice on a number of BizTalk development, deployment and operational problems that you will encounter during the life of a BizTalk solution. You can download my OPML file listing 60+ active BizTalk bloggers, or go to the BizTalk Community Blogs via Syndication on the BizTalk Gurus website. If these resources don’t offer the information you need, try posting to the BizTalk Newsgroups; if your an MSDN subscriber, your also entitled to use the managed newsgroups which (I believe) are guaranteed a response from Microsoft.
