BizTalk Server

A couple of years ago, I was working on a solution for a small client who wanted to set up some automated database processing with a few banks. I read up on BizTalk. It seemed to be just the thing. After woking through a very significant learning curve and getting some parts of the application working, I have concluded the following:

BizTalk was designed to fit a very real and specific need. It would probably work well for a medium or large enterprise with a significant number of Business-To-Business interactions that need automation. Even a small enterprise might successfully use it if their main business involves significant and complex electronic interaction with several other businesses. However, it is not practical for a small business that only wants to set up a few relatively simple interactions. In the latter case, it is much easier and less expensive to just code a solution directly using .Net or some other platform. This is ultimately what I ended up doing.

The main advantage of using BizTalk over direct coding is that it provides a standardized platform for setting up and managing interactions. It will keep state on complex interactions that are pending some external event for any amount of time, even if the machine goes down or is re-booted. This represents a huge amount of infrastructure which would be a very expensive and time consuming development effort to create independently. If this level of standardization and infrastructure is needed, then it's well worth it. If not needed, it is just superfluous complexity that programmers must learn about and work with, even if the application or the customer will not benefit from it.

BizTalk can be learned through courses and books. In theory, this means that one could hire programmers who already know it. In practice, BizTalk developers are a bit difficult to find, and expensive. Therefore, a company planning to implement a BizTalk application should plan on maintaining a team of BizTalk personnel to monitor and extend their application. Training a BizTalk programmer is not a matter of giving someone a quick course or having them read a book. It is a significant skill that takes some months to really attain. Even users and administrators will require training and experience with the product.

Non-trivial BizTalk applications will also require some custom code in C# or VB.Net. Therefore, using BizTalk doesn't eliminate the need for .Net programmers.

In my initial research, I found plenty of information on what BizTalk can do and how it does it. I did not find anything to give me a sense of the magnitude of the learning curve and of the effort required to create and debug "orchestrations" (interactions between computers) that work correctly. In hindsight, maybe this should have been obvious; it wasn't at the time.

Fortunately, BizTalk is available on a "try before you buy" basis, so we did not incur any licensing costs. Unfortunately, the development cost of the effort was significantly higher than the license fee would have been.

I have noticed increasingly over the past 10 years or so, that programming has become much less a matter of coding and much more a matter of finding, learning and implementing existing code and technology. BizTalk is a perfect example of this trend.

When we developers are looking for a tool that will fit a particular application, it is helpful to know what our peers have already discovered. We seldom have enough time to read the manual for a product before deciding whether to use it. Even when we do, it's difficult to get a feel for its complexity without actually working with it for a while.

When evaluating options, it always helps to hear from others who have worked with a product, successfully or not. I hope that this entry will not only be of help to someone evaluating BizTalk, but that it will also encourage other developers to blog their experiences, good or bad, with the tools they use.