I have spent much of my IT career working with Microsoft technologies. I have also found myself dealing with integrating the Microsoft stack with applications built in many other technologies.

In the dim and distant past, integrating applications built in Microsoft technologies with something else was a significant challenge. Put simply Microsoft technology didn’t play nicely. I remember when being able to connect a Microsoft application to an Oracle database was a big deal. That opened the door to sharing data between Microsoft and none Microsoft applications via a database intermediary. This shared database integration solved many technical challenges at the time but it is now considered to be an anti-pattern.

The next significant event on the Microsoft integration roadmap was the release of BizTalk Server. This product grew its capabilities over a couple of releases but a fundamental architectural change suddenly put it on many organisation’s radars. The product was capable and Microsoft priced it aggressively to ensure many people looked up and took notice.

Whilst the product was capable it was complex. Setting it up took much effort and getting it tuned for what you were asking it to do took a lot of expertise. If you could accept this initial setup cost, you ended up with a product that acted as a message broker and process manager and had adapters that allow data to be extracted or pushed into systems that you might have never thought possible before.

However, there was another problem. Microsoft had built a mature integration product. The nature of integration made it challenging for average Microsoft developers of the time to build integration solutions. You have to understand the Microsoft walled garden made developers very productive because there was only so many ways to skin a cat. Most problems had clear and obvious solutions. This way of working didn’t scale up when you were dealing with Integrating with an AS400 system or having to get your head around compensating for a partial failure of a long running transaction. So this meant getting good BizTalk developers was hard. It was not a natural progression for a Microsoft developer, and people who did have the right mindset were most often to be found working in lucrative positions on other stacks.

I was recently taken through Microsoft’s current Integration roadmap and technology offerings. I was surprised that BizTalk is still a primary product. In the latest release you’ll be able to run the BizTalk product on premise or using VMs on the Azure IaaS offering. There is also a PaaS service called Azure Logic Apps that enable some of the integration patterns supported by BizTalk without the need to be running your own BizTalk infrastructure whether that be on premise or IaaS on Azure.

What I have seen with projects more recently is that they will take the path of least resistance to solve problems. So when project teams encounter an Integration challenge for the first time I can picture them reaching for Azure Logic Apps. There will be costs associated with that action but they are unlikely to be huge. The team will build on this until they find something that cannot be solved with Azure Logic Apps.

Microsoft’s answer to this is that they should use BizTalk. However, I struggle to swallow that. Even in its modern incarnation BizTalk requires some effort to stand up, run and develop solutions for. There will be a not insignificant setup cost and all the historic challenges of finding BizTalk developers have not gone away. Also I can’t see how Azure Logic Apps could be ported to BizTalk so you’ll end up with two Integration solutions.

Would it be even possible to build a case to implement BizTalk for a small number of Integration scenarios? If you spot these potential problems early and decide that BizTalk is the better solution for all your Integration needs from the outset, I can see many people being unconvinced that the solution couldn’t be delivered on Azure logic applications. On the other hand, if you are incrementally building your solution and suddenly find you need BizTalk later during delivery it is not very Agile to wait while you source good BizTalk developers, build a BizTalk environment and change your support model.

So the approach feels a bit disjointed for me.

If you have an existing investment in BizTalk you can get more from it and you can move it to the cloud if you want to. You can use the other capabilities in Azure and decide on a case by case basis whether to build in BizTalk or in Azure Logic applications.

However, if you don’t already have that investment, the case for starting from scratch with BizTalk is reducing. So if you want to use Microsoft you will use Logic applications. Which means when you find things that it doesn’t do the natural alternative will be to code around the problem. How hard can it be? Well in my experience the answer is “easy when you start and becoming extremely hard when you least want it to”.

I am not sure what will be added to the PaaS stack but I would be surprised if it wasn’t brought even closer to what BizTalk does, making BizTalk the solution that offers the more control vs Azure Logic Apps: the solution that offers the most productivity.  At least the current situation is likely to keep people like me busy.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s