Is BizTalk Server Going Away At Some Point? Yes. Dead? Nope.

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?

Author: Richard Seroter

Richard Seroter is Director of Developer Relations and Outbound Product Management at Google Cloud. He’s also an instructor at Pluralsight, a frequent public speaker, the author of multiple books on software design and development, and a former InfoQ.com editor plus former 12-time Microsoft MVP for cloud. As Director of Developer Relations and Outbound Product Management, Richard leads an organization of Google Cloud developer advocates, engineers, platform builders, and outbound product managers that help customers find success in their cloud journey. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

48 thoughts

    1. How is the market for Biztalk ? Does anyone know how I can start Biztalk training online ? Any good websites to learn..?? Any suggestion

  1. Agreed. Tony did a fantastic job explaining the roadmap and the strategy that Microsoft is taking to execute.

  2. My response could be – “Why I’m nervous to leverage Microsoft technology as an enterprise platform”

    Ok, so you are the VP of technology at a company whose ESB is based on BizTalk. You know that it took 5+ years to migrate from your previous ESB to BizTalk. Now, you read/intuit/think that MS is hitching its wagon to the cloud bus and using that tail to wag the dog and doesn’t seem committed to BizTalk as an enterprise backbone, but rather inventing something new, on the cloud first (to drive business to their hosting business) which may make it back into an on-premise product eventually.

    What do you do as the VP of technology (other than upgrade to BizTalk 2010). Do you start planning your next ESB migration? And if so, to what?

    1. Very legit question and I can’t *imagine* what company you are talking about 😉

      The MS integration story is undergoing a necessary evolution. Difference is that it’s starting in the cloud before coming back on-prem. But the only enterprise-scale product to purchase today, and probably 2-3 more years, is BizTalk Server. Support will exist for another 15 years.

      If (when?) I’m the VP, I’d make a bet on a stable technology and realize that at some point, every tech is replatformed and I have to consider upgrade/migration. But if I start with a stable, well-supported product, I’ve bought myself 5-10 years of reliable software that solves my problems. In the meantime, by business itself may change and I need to embrace new technologies well before my platform technologies undergo the changes I need.

      1. Agree. SKUs will come and go, but the key is to stay focused on the capabilities at a platform level as opposed to a given product.

        Certainly, at some point, today you must pull the trigger on shrink wrap, but the reality is that this is nothing new compared to other competitive vendors, except instead of evolving the platform via acquisitions (which result in 30 loosely discombobulated modules stitched together (or not at all) that VPs and CxOs are sold on as being one “product”) the platform capabilities are both evolving organically and going through a much needed unification phase.

        At the end of the day, customers don’t buy technology. They buy solutions to their business problems. As technologists, it is our job to understand the problem, map it to the right capabilities and provide a solution that drives the desired business outcome. Sometimes these capabilities might map well to BizTalk. Other times WF Services and Windows AppFabric, Azure AppFabric, hybrid or all of the above, but what I am seeing more and more is that no one size fits all, and when you look at it from a platform capabilities perspective, it makes more and more sense to be able to pick and choose the capabilities you need as opposed to having to go all in.

  3. I could not agree more on what you have described. I myself believe product will around for while (more than 10000 customers world wide) and high demand still for BizTalk professionals and they need to look into azure technology now to be in business after 5-10 years time.I witnessed the introduction in 2008 of Azure, which is successful until now, and Oslo deception. I agree that Azure team will not let us down and create a robust, stable, innovative platform for us.

  4. Seems the Windows Server AppFabric will be not the same technology as Azure AppFabric. Keeping an Azure available only for the Microsoft data centers will assure this.
    Richard, are there any plans to make Azure available on the market?

  5. Nice one.

    MS is moving away from it’s last but one on-premises product to cloud. Only Windows will be pending. So, what we’re going to see is less hardware/software in our systems in future, increase in internet bandwidth..!

  6. nice article richard..

    i think one thing often over looked with BizTalk around its maturity is the question of what would you really want in a future version of biztalk anyway. The things that you may want you would tend to prefer if they were not tied to biztalk so you could use them in a hybrid solution or also entirely out side of biztalk.

    i think the one mistake microsoft is making is around the brand of biztalk. by creating the question about potentially biztalk being around or not they have created this lack of confidence in the market but i think they should have from the outset said “today biztalk is a product”, “in the future biztalk will be our business transaction focused costing model around integration solutions in azure/app fabric”. If that was the position then they could have completely changed the technology stack but kept the brand and i think everyone would have been really excited about that.

    I dont think any VP would have questioned their organisations commitment to biztalk and viewed the new stuff as making things simpler for them but at the same time giving them more innovation and value for moey

    Microsoft is really let down by poor marketing strategy at times

  7. I think the most important aspect of this is that all these features that have been locked in BizTalk for years will now be available across the entire Microsoft platform. Frankly I think everything amazing Microsoft has been making for nearly a decade has been from the same foundations that made BizTalk, the different is 10 years ago clouds where things you saw in the sky and the most massive Windows server groups were still quite weak. Today the landscape has changed and Microsoft is moving forward rather than fighting to sustain what is now becoming legacy.
    It has never been a better time to know BizTalk and the underlying patterns.
    Great article Richard! Well said.

  8. Very interesting seeing the skepticism about AppFabric as the next step forward. I agree it seems like the technology replacement may not be on prem for a while. I agree too it is good to cast your net wide on the tech skills, diversify to remain fluent.

    Definitely the BizTalk brand as we know it is going to be changing. Were there any partner ecosystem type details from what was said in the session? It sounds like just a general roadmap session.

  9. Nice article. You brought up very good point by mentioning that, there have not been major enhancements to the core engine since BizTalk 2004. I often felt this whenever there was new version of BIzTalk Server announced/released. As Rick mentioned, it is capabilities that matter rather than the brand names/SKUs. I remember few instances this has happened in the past in Microsoft stack and there has not been any negative impact due to this, MS Conent Management Server 2002 is merged with Sharepoint Server strack and WCF services has conveniently replaced .NET Remoting/ASMX services. I am sure, there would be some more like this.

  10. Yes, yes and yes I agree with most of your thoughts… but from an organizational point of view if the choice is to implement a Biztalk platform or stay with the current “spaghetti-integration” the answer is simple… implement. Maybe not from a technical point of view because Biztalk “supports” global error handling, logging etc… The most important for an organizational is to solve the “spaghetti” and mature as a more modern organization with a robust architecture that enables the move into the cloud in the future when Microsoft has the right technical solution in place.
    The implementation of a Biztalk platform is one step that will help the organization to take the next step.

  11. My only convern is compliance related issues based with any cloud based environments , I can bet out of the 10,000 odd BizTalk clients majority would not be able to move their integration services to the cloud due to compliance issues..I am not sure this point was given due consideration by MS but is huge from a practical perspective.

  12. Biz-talk is an integration solution. So, all other systems and parties believed and dependent on that brainy-coordinator. It is difficult to open the hands as you say after 15 years .The Biz-talk server should keep on go for easy migration and future, even after cloud. I know Biz-talk only 5%. But, I know what I am talking about. Since integration is a never-ending process, Biz-talk should count the experience with the same name. My feeling is, Integration Product is the challenging one out of all IT products… on-premises or After Cloud doesn’t matter. The company should think how can i integrate billions of people’s day to day activities with versatile input and output with Artificial Intelligent manner. That is future. The best integrator will have BIG TEAMs and if it is doing well, the team will be stay and grow by context. Have a think the cloud will go for the real purpose.

    1. How is the market for Biztalk ? Does anyone know how I can start Biztalk training online ? Any good websites to learn..?? Any suggestion ?

      1. Rafa, it’s improving now that Microsoft has re-committed to the platform. If you can afford it, the Pluralsight training for BizTalk is excellent. Otherwise, the MSDN site has lots of tutorials for free.

  13. Hi Richard,

    I am working with BizTalk since almost 5 years, Recently I’m hearing that BizTalk is going down and replacing with IBM BPM in all enterprise company’s, as developer I’m still in a confusion to decide to stick with BizTalk or learn IBM BPM, Could you please share your thoughts on this, which one has the best future IBM BPM VS BIZTALK.

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 )

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.