Thursday, December 24, 2015

My Point of View: Microsoft Releases Integration Roadmap

On December 24th, 2015 Microsoft provided a Christmas gift to its customers, partners and broader eco-system in the form of a highly sought after roadmap.  For several years, customers and partners have been awaiting an “official” statement from Microsoft with clear direction on where they are headed.  Competitors have used the lack of a roadmap against them in compete situations. That has all changed as of this writing.

You can find the roadmap here and BizTalk360 founder and Microsoft MVP Saravana Kumar has provided his thoughts here.

My POV:

BizTalk is not dead

The BizTalk ‘franchise’ will continue to exist.  We will see a BizTalk Server 2016 next year that will include the following features:

    • Platform Alignment (Windows Server, SQL Server, Visual Studio)
    • SQL Server 2016 support and  Always-On Availability groups which will simplify BizTalk Disaster Recovery.
    • Full support for High Availability in Azure IaaS
    • Better support for cloud based integration and SaaS connectivity.  Today we have a lot of SaaS connectivity through API Apps.  I suspect we will see BizTalk Server to tap into these API Apps rather seamlessly.
    • Bug fixes and Adapter enhancements.

We will also continue to see ‘BizTalk’ capabilities being leveraged in Logic Apps in the form of API Apps such as BizTalk Transformations, encoding/decoding, Business Rules etc.

A unified vision from Microsoft

For some outsiders this may not be abundantly clear, but the BizTalk team lives within the Azure App Service team.  Subsequently, both the Logic App and BizTalk teams are the same team. This roadmap accounts for this and represents a single vision for Integration at Microsoft. 

For people familiar with both BizTalk and Logic Apps, it is probably evident that BizTalk and Logic Apps tend to operate at different ends of the integration spectrum. With BizTalk, customers get a solid on-premises integration broker that is very robust.  It is also very feature rich with support for BAM, Business Rules, EDI, ESB, Exception Portal, Pub/Sub messaging and much more.  However, all of these capabilities, there is a price to pay in terms of complexity and technical dependencies for it all to work.  As a result agility can become a concern for some customers.  For teams with concerns about BizTalk’s agility, their concerns can often times be resolved in Logic Apps.  In Logic Apps we have IPaaS capabilities with loads of SaaS connectivity and (soon)direct integration with API Management.

I think the following image (from roadmap) does a great job of illustrating where Microsoft is headed.  The goal is clearly symmetric capabilities, but provided in a modern platform. This modern platform is not BizTalk Server, but rather building out Logic Apps to address outstanding enterprise features and deliver them in the cloud and on-premises.  A key enabler of this story is Azure Stack.  Without it we will not see the new Logic App assets running in your own data center.  Microsoft is targeting an “IPaaS” preview in Q2 2016 and GA by end of the 2016.

image_thumb[1]

Bringing more people to the party

Let’s be honest, BizTalk developers have a very niche skill set.  I have been working with BizTalk since 2004 at several different organizations.  I have seen some amazing BizTalk solutions being built that literally run a company and have enabled many business opportunities for organizations.  I have also seen what happens when you don’t have good BizTalk people working in BizTalk.  It gets messy quickly.  This especially a problem in the BizTalk 2004 and 2006 days when there was little documentation and guidance out there.  Today, there are so many resources out there provided by MVPs and the community this is becoming less of an issue. (What other ecosystem can brag about a weekly international user group meeting run by the community). However, and I am confident in saying this, there are not a lot of BizTalk experts out there and it is a steep learning curve in getting people to a place where they will be productive and not ‘paint an organization into a corner’.

While this may not be a popular statement with people who have invested a significant amount of time in BizTalk, it needs to get simpler.  Microsoft has around 10 000 BizTalk customers (give or take).  With the introduction of SaaS and mobile, and subsequently more demand for integration, how can you scale both a technology and a resource pool to meet that demand?  In my opinion, you can’t do that with BizTalk nor is it designed to excel in these ‘new’ use cases.

As a result, we will continue to hear  messages of ‘democratization of integration’ or ‘citizen developers’.  While many will scoff, the need is real.  If I need to connect a SaaS application, such as Salesforce, with an on-premises application this should take hours and not days(if you need to setup BizTalk environments).  For organizations with an existing broker or ESB, they can turn this around quicker than an organization without, but not as quick as an IPaaS platform.  At the end of the day, organization don’t do integration for the sake of integration but rather for a business opportunity and the old adage of ‘time is money’ could not be truer in today’s economy.

The biggest challenge, and common rebuttal,  in a simplification scenario is that integration can be complex.  This is true and this will not go away.  Recently, my team has been involved in a complex energy trading implementation with many complex, large interfaces with critical data.  I am very confident in saying that this was not a good use case for IPaaS, at least not at this time. 

However, I also run into scenarios such as SaaS connectivity where I don’t need the heavy broker.  So clearly I can relate to both points of the integration spectrum.  For customers, lowering the barrier of entry for building interfaces is a good thing.  Expert integrators will continue to be required to address more complex scenarios and develop the right patterns and architectures, but we will also see integration tools being made available to mobile and web developers to build interfaces in a timely and cost efficient manner.  Ultimately this will allow Microsoft to grow both the platform and the ecosystem.  A healthy ecosystem is good for all parties.

image_thumb[3]

Conclusion

I am sure everyone reading the roadmap would love a magical, cohesive platform that combines both BizTalk Server with Azure App Service yesterday.  BizTalk was not built overnight, and similarly it will take time for the convergence of these two platforms to happen.  The good news is that we have official confirmation from Microsoft on where they are headed which is a great step while we await the bits to arrive.

Take this for what it is worth, but here is how I am acting on this roadmap.

  • Continue to use BizTalk for its strengths.  If you have complex integration needs that deal with on-premises systems, or complex messaging patterns,  continue to use BizTalk for those purposes. 
  • The SQL Server Always On feature may be worth the price of an upgrade alone from a Disaster Recovery perspective.  Let’s be honest, DR with the current BizTalk version is not ideal
  • Where you have trading partner, that can leverage APIs, mobility or SaaS connectivity requirements look to the modern IpaaS platform.  I am a big fan of keeping this type of integration on the edge of my enterprise.  I don’t want to open up firewalls and manage those configurations using legacy approaches.  Very easy to do so using Azure API management and API Apps. 
  • Azure Service Bus is a great way to bridge on-premise workloads with IPaaS connectivity.  It also enables Pub-Sub for Logic Apps.
  • Vote early and vote often! The Azure App Service team is very interested in feedback.  If you think something is missing, add it on User Voice here. Back in May I created topic for allowing BizTalk to talk to API Apps in order to allow for SaaS connectivity in BizTalk.  While I cannot take credit for this featuring being included in BizTalk 2016, it does show that the team is listening.