There’s a major healthcare company in the Midwest — I won’t say which one — that made a major commitment to Microsoft’s BizTalk systems integration platform about five years ago. They bought a lot of 2006R2 licenses, with the intent of rebuilding their EDI systems (which were substantial) on BizTalk, reducing costs and gaining finer control of their B2B document exchange.

I taught several classes there, and years later, I found myself doing some contract work for them. During the latter gig, I learned that a moratorium had been placed on BizTalk development work. Why? Because everyone in IT development had gone BizTalk crazy, once they had their hands on the product, and started doing everything in BizTalk. It didn’t go well: the servers were brought to their knees, nothing worked as intended, maintenance was a romp in hell. Moratorium, indeed.

BizTalk in Azure IaaS

I’m a long-time BizTalk fan, I’ll readily admit, so I’m not the guy to complain to when it comes to the monumental difficulties in deploying a BTS platform on-premises. It’s expensive (licensing- and hardware-wise), time-consuming (configuration- and integration-wise), and generally requires dedicated specialty skills to maintain — all of which wipe out the benefits of its wicked-cool visual development interfaces.

All the same, for all its market share, the problems above have been implementation barriers for countless organizations. The burden of establishing an on-premises services platform are huge by their very nature. And the fact that BizTalk presents the appearance of a distributed platform, when it is in fact a centralized, server-centric platform, can’t be circumnavigated on premises.

Azure to the rescue?

With the 2010R2 release (also referred to as 2013), BizTalk can now be deployed rapidly on Azure virtual servers – in the Microsoft cloud, making it a truly services-oriented deployment. A number of benefits accrue from this immediately: the burden of hardware acquisition/repurposing is eliminated, with all of its expense and lead time; the cost of environmental setup goes away; the burden of maintenance all but vanishes.

The real rabbit that an Azure deployment pulls out of the hat is one that can’t be achieved on-premises. It’s not end points and ports, which can be scattered to the wind; it’s not the Message Box(es), which likewise can be strategically placed.

It’s those wicked-cool development interfaces. The heavy lifting of BizTalk is the integrated transformation of data (mapping) and the embedding of rule-driven business processes (orchestration) within the data integration process, offloading those burdens from the systems being integrated – BizTalk’s leading selling point. It’s very true that data transforms and embedded processes can be developed in BizTalk in a fraction of the time it would take to code them by hand; but that’s because code generation is taking over, and generated code is always more expensive than home-grown code.

Economies of scale

Azure-based BizTalk is the answer to this conundrum we’ve wrestled with for years now: how to offset the processor-gobbling effects of transforms and business rules in BizTalk applications? SharePoint allows us to offload the processing overhead of enterprise search to a scalable middle tier; we can’t do that wholesale in an on-premises BizTalk deployment.

But Microsoft can, in the cloud – and that’s a difference that makes a difference. The Azure platform is built around the concept of a multi-tenant BTS deployment built on a scalable enterprise service bus — BizTalk as it was always meant to be. Economies of scale are leveraged to handle the extra processing. The bottlenecks have already been compensated for, and continuous optimization is already in place.

All of this puts the in-house burden back where it belongs: designing a good integration app in the first place. This is no less important than it’s ever been in the BizTalk realm, but the developer is now free to concentrate on what matters.