BizTalk productivity myths

Fueled by competitive, aggressive marketing efforts and other fun reasons, I personally run into a lot of customer engagements lately that revolve around the assessment of the quality of integration architectures and the productivity of the integration team when it comes down to time-to-market of new or improved processes and composite services.

Sometimes we also run into bake-offs, where we have to complete a set of “integration tasks” or worse “build and integration between x and y” and the competitors have to do the same and then the company makes a decision based on the speed of delivery.

First of all, let me make a bold statement here: It does not matter which integration middleware you use, bare tool development productivity will be more or less the same but more importantly is often not relevant at all because it comprises such a small portion of the work to be done.

Now let me try to explain that. In order to be able to compare development productivity, a fair comparision has to be made. Apples should be compared with apples and not with pears. This proves to be quite hard in practice. Of course, the effort put in creating an XSD Schema, creating an XSLT tranformation or setting up the endpoints can be compared quite easily. The same applies to routing rules. And maybe also to orchestrations. But that’s often not how these comparisons or bake-offs are designed.

The problem most often is, that the difference lies in the integration patterns that are used. A fair comparison can only be made when comparing implementations that follow the exact same integration patterns. The familiar patterns we all know from Hohpe and Woolf (for reference: eaipatterns.com).

It is often said that the biggest competitor for BizTalk (or for that matter, any integration middleware product) is the (.Net) developer. And that’s so true. How easy is it, to integrate two systems by just creating a peer-to-peer integration based entirely on code and direct database access? Sure, it works. But can you reuse it? Can you expose the component that fetches data from one system as a reusable service? So that you can create other compositions and processes? Building a SOA?

Integration middleware like BizTalk Server guides or sometimes “forces” you to use the right integration patterns where other tools are sometimes not that strict. The main reason for adhering to proven patterns is that the middleware has to be scalable, reliable and secure. And of course we don’t want to end up with spaghetti-through-a-broker. We want an ESB pattern. It also has to be possible to bridge sync and async connections. Transactions have to be handled. Guaranteed delivery has to be possible. The 8 principles of service design have to be followed (see previous posts).

So, in short: Yes, it may occur that building an integration between two systems takes longer (or shorter) in one product compared to another, but… make sure to compare apples to apples.

My advice for companies designing integration development productivity PoC’s or bake-offs:

  1. Make sure that the parties implement the same integration patterns
  2. Make sure that the 8 principles of service design can be validated in a SMART way
  3. Make sure that the solutions they implement are supportable
  4. Always keep in mind that 75% of the effort lies in discussing and testing interfaces

Hope you find this post useful. Feel free to share and use (parts of) it when you need help in similar situations.

Cheers, Gijs

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