Another conference, another batch of “BizTalk future” discussions. This time, it’s the Worldwide Partner Conference in Los Angeles. Microsoft’s Tony Meleg actually did an excellent job frankly discussing the future of the middle platform and their challenges of branding and cohesion. I strongly encourage you to watch that session.
I’ve avoided any discussion on the “Is BizTalk Dead” meme, but I’m feeling frisky and thought I’d provide a bit of analysis and opinion on the topic. Is the BizTalk Server product SKU going away in a few years? Likely yes. However, most integration components of BizTalk will be matured and rebuilt for the new platform over the next many years.
A Bit of History
I’m a Microsoft MVP for BizTalk Server and have been working with BizTalk since its beta release in the summer of 2000. When BizTalk was first released, it was a pretty rough piece of software but introduced capabilities not previously available in the Microsoft stack. BizTalk Server 2002 was pretty much BizTalk 2000 with a few enhancements. I submit that the release of BizTalk Server 2004 was the most transformational, innovative, rapid software release in Microsoft history. BizTalk Server 2004 introduced an entirely new underlying (pub/sub) engine, Visual Studio development, XSD schema support, new orchestration designer/engine, Human Workflow Services, Business Activity Monitoring, the Business Rules Engine, new adapter model, new Administration tooling, and more. It was a massive update and one that legitimized the product.
And … that was the end of significant innovation in the platform. To be sure, we’ve seen a number of very useful changes to the product since then in the areas of Administration, WCF support, Line of Business adapters, partner management, EDI and more. But the core engine, design experience, BRE, BAM and the like have undergone only cosmetic updates in the past seven years. Since BizTalk Server 2004, Microsoft has released products like Windows Workflow, Windows Communication Foundation, SQL Server Service Broker, Windows Azure AppFabric and a host of other products that have innovations in lightweight messaging and easy development. Not to mention the variety of interesting open-source and vendor products that make enterprise messaging simpler. BizTalk Server simply hasn’t kept up.
In my opinion, Microsoft just hasn’t known what to do with BizTalk Server for about five years now. There was the Oslo detour and the “Windows challenge” of supporting existing enterprise customers while trying to figure out how to streamline and upgrade a product. Microsoft knows that BizTalk Server is a well-built and strategic product, and while it’s the best selling integration server by a mile, it’s still fairly niche and non-integrated with the entire Microsoft stack.
Choice is a Good Thing
That said, it’s in vogue to slam BizTalk Server on places like Twitter and blogs. “It’s too complicated”, “it’s bloated”, “it causes blindness”. I will contend that for a number of use cases, and if you have people who know what they are doing, one can solve a problem in BizTalk Server faster and more efficiently than using any other product. A BizTalk expert can take a flat file, parse it, debatch it and route it to Salesforce.com and a Siebel system in 30 minutes (obviously depending on complexity). Those are real scenarios faced by organizations every day. And by the way, as soon as they deploy it they natively get reliable delivery, exception handling, message tracking, centralized management and the like.
Clearly there are numerous cases when it makes good sense to use another tool like the WCF Routing Service, nServiceBus, Tellago’s Hermes, or any number of other cool messaging solutions. But it’s not always apples to apples comparisons and equal capabilities. Sometimes I may want or need a centralized integration server instead of a distributed service bus that relies on each subscriber to grab its own messages, handle exceptions, react to duplicate or out-of-order messaging, and communicate with non-web service based systems. Anyone who says “never use this” and “only use that” is either naive or selling a product. Integration in the real world is messy and often requires creative, diverse technologies to solve problems. Virtually no company is entirely service-oriented, homogenous or running modern software. BizTalk is still the best Microsoft-sold product for reliable messaging between a wide range of systems and technologies. You’ll find a wide pool of support resources (blogs/discussion groups/developers) that is simply not matched by any other Microsoft-oriented messaging solution. Doesn’t mean BizTalk is the ONLY choice, but it’s still a VALID choice for a very large set of customers.
Where is the Platform Going
Tony Meleg said in his session that Microsoft is “only building one thing.” They are taking a cloud first model and then enabling the same capabilities for an on premises server. They are going to keep maintaining the current BizTalk Server (for years, potentially) until new on-premises server is available. But it’s going to take a while for the vision to turn into products.
I don’t think that this is a redo of the Oslo situation. The Azure AppFabric team (and make no mistake, this team is creating the new platform) has a very smart bunch of folks and a clear mission. They are building very interesting stuff and this last batch of CTPs (queues, topics, application manager) are showing what the future looks like. And I like it.
What Does This Mean to Developers?
Would I tell a developer today to invest in learning BizTalk Server from scratch and making a total living off of it? I’m not sure. That said, except for BizTalk orchestrations, you’re seeing from Tony’s session that nearly all of the BizTalk-oriented components (adapters, pipelines, EDI management, mapping, BAM, BRE) will be part of the Microsoft integration server moving forward. Investments in learning and building solutions on those components today is far from wasted and immensely relevant in the future. Not to mention that understanding integration patterns like service bus and pub/sub are critical to excelling on the future platforms.
I’d recommend diversity of skills right now. One can make a great salary being a BizTalk-only developer today. No doubt. But it makes sense to start to work with Windows Azure in order to get a sense of what your future job will hold. You may decide that you don’t like it and switch to being more WCF based, or non-Microsoft technologies entirely. Or you may move to different parts of the Microsoft stack and work with StreamInsight, SQL Server, Dynamics CRM, SharePoint, etc. Just go in with your eyes wide open.
What Does This Mean to Organizations?
Many companies will have interesting choices to make in the coming years. While Tony mentions migration tooling for BizTalk clients, I highly suspect that any move to the new integration platform will require a significant rewrite for a majority of customers. This is one reason that BizTalk skills will still be relevant for the next decade. Organizations will either migrate, stay put or switch to new platforms entirely.
I’d encourage any organization on BizTalk Server today to upgrade to BizTalk 2010 immediately. That could be the last version they ever install, and if they want to maximize their investment, they should make the move now. There very well may be 3+ more BizTalk releases in its lifetime, but for companies that only upgrade their enterprise software every 3-5 years, it would be wise to get up to date now and plan a full assessment of their strategy as the Microsoft story comes into focus.
Summary
In Tony’s session, he mentioned that the Azure AppFabric Service Bus team is responsible for building next generation messaging platform for Microsoft. I think that puts Microsoft in good hands. However, nothing is certain and we may be years from seeing a legitimate on-premises integration server from Microsoft that replaces BizTalk.
Is BizTalk dead? No. But, the product named BizTalk Server is likely not going to be available for sale in 5-10 years. Components that originated in BizTalk (like pipelines, BAM, etc) will be critical parts of the next generation integration stack from Microsoft and thus investing time to learn and build BizTalk solutions today is not wasted time. That said, just be proactive about your careers and organizational investments and consider introducing new, interesting messaging technologies into your repertoire. Deploy nServiceBus, use the WCF Routing Service, try out Hermes, start using the AppFabric Service Bus. Build an enterprise that uses the best technology for a given scenario and don’t force solutions into a single technology when it doesn’t fit.
Thoughts?
Richard Seroter's Architecture Musings 
Leave a reply to Ben Cline Cancel reply