Does BizTalk have man-boobs?
June 9th, 2008I’ve just finished watching this webcast from QCon 2008 with Martin Fowler and Jim Webber. It’s basically their view on how integration middleware is used today and how we plan and implement our SOA and ESB project.
Their main point is that we use much to bloated middleware (BizTalk is mentioned as an example here) and that we should have a more agile approach to implement SOA and ESBs. They’ve used all the agile ideas (testing, isolated testable functionality, deliver small and often, continuous builds etc, etc) and applied them to integration – fair enough. I totally agree that trying to convert your complete enterprise architecture into a SOA architecture is a guaranteed failure. This is also something we heard for a while now from others as well.
I do also agree that BizTalk is a huge platform and that it isn’t perfect in all aspects. IMHO it does however give us some important advantages compared to a custom coded message bus and services. I’ll try and list a few of them below.
- Fixed architecture
We don’t have invent the wheel every time. BizTalk is a product with an architecture that one have to learn and use. There are times when this is a pain (did I hear low latency and BizTalk persistence points?) but it’s also a huge kick start to all projects once you learnt it. Once you figured out how you use the products you’ll actually have something up and running in no time.Isn’t an early delivery that we can test something good? I’m sure I can deliver a BizTalk based integration faster that some can using custom code when starting from scratch.
- Drag-and-drop
There is a learning curve to BizTalk and all it’s tools but once one gotten over this one can move really fast, even without a deep understanding of .NET and software development (there are of course both pros and cons to this). I’ve seen projects with 50+ integration processes (to me that’s a big, complex project) where we actually used people fresh out of school, spent two weeks to teach them basic BizTalk and had them deliver critical parts of the projects. I’d like to see that happen custom coded ESB project with thousands lines of code …You probably get a nice design and implementation if you can hire 10 top developers and a couple of architects, but that isn’t always possible.
- Tools
Does a custom code, lean approach, really scale in this scenario? Do you take the time to pause and build that management and configuration tool that you don’t get with a custom code project? I don’t say that we got the perfect view and control of our processes and messages in BizTalk but at least we got some control. At least I got the BizTalk Administration Console to let me see how my different application are doing, what messages and process etc that got suspended. At least I got the BAM framework where I can configure a tracking and monitoring in no time (usually …) etc, etc.
- It works
Say your implementing a process that receives purchase orders and that these orders might contain orders for a couple of millions dollars. Do you want to be developer that tells you boss that you think you might have lost a message due to a exception in your custom code? Of course you have 90% test coverage and continuous integration but you never tested for this exception case … I don’t want to be that developer/architect.
I don’t say don’t test. I’m very pro testing and I really feel that agile is the right approach. I’m just saying I need something tested and safe to build this super critical solutions on. Something that I know works and that I can be really productive on and start solving business cases from minute one.
What do you think? Does BizTalk have man-bobs and is that only a bad thing? And does Martin Fowler really have leather pants on?
October 18th, 2008 at 2:24 am
Your four points made are extremely pertinent to small scale projects where scale and throughput are not large concerns in particular. Your example where you site the developer whom wears responsibility for the code that “lost a message” and I would like to refine that idea a little. Messages in an SOA that include BTS in it’s architecture wont necessarily always include BTS at every endpoint. Often enough some process whether it be a long running service hosted in a workflow of some a custom executable, will need to make sure that it’s messages are managed in a durable way and not simply lost on the transport for example. Frameworks like NServiceBus handle this very well.
Curiously, yes Fowler is wearing leather pants – oh my, what does he think he’s doing?
October 21st, 2008 at 6:52 am
@Simon: Thanks for your post.
I do agree that not all integration in a project necessarily has to be solves using BizTalk. I have however not seen a project where one would use both BizTalk and NServiceBus i combination (I’m not sure that’s what you saying either) … And sure I also a agree that when solving these edge cases that lives outside BizTalk you’ll need more experience developers.
I still however think that my point on BizTalk development vs. custom development are valid.
February 23rd, 2009 at 10:38 pm
Richard, Spot on. I agree with these points. It’s also rather ironic that the very ‘agilists’ who want to write all this code ‘test first’, will then stress the importance of pre-built frameworks and good reliable tools, and will then be selective about what they mean (for example, NHibernate, yes, oh yes!! its open source..it must be divine , but BizTalk, no way too big !!! and its from MS.. it has to be evil ) Sometimes all I want to say, is “bah! humbug!!”
February 23rd, 2009 at 11:14 pm
[...] on this issue. I was just doing some final prep for my VBUG talk tomorrow and came across Richard Hallgren’s oddly titled post. Richard writes about a QCon webcast of a session done by Martin Fowler and Jim Webber and [...]
May 22nd, 2009 at 1:46 pm
actually, only points 1 & 4 are the only reasons to use BizTalk…and for one other reason: EXPANDABILITY
what BizTalk gives you over other custom architecture, is that it provides you an underlying fail-safe and scalable archictecture without having to write code. you got the transactions, built-in queueing, retries, suspended message monitoring and even throttling if the system is suddenly overwhelmed with messages. these are the things that most developers are taking for granted and don’t even realize that it’s very difficult to implement.
it’s funny, because we started with BizTalk 2004 (moved to 2006 shortly) and some other group were laughing at us and they decided to write their own. Guess what? years later, the BizTalk 2006 systems are still chugging and the home-growned EAI app got replaced after a few years of headaches.
now over to EXPANDABILITY, once you get to know how BizTalk works, 2 & 3 are hardly a reason. The tools are just enough, but not that compelling anymore when you find the shortcomings. For example, BizTalk maps are EASY, but very limited…Fortunately, you CAN reference an XSLT in your BizTalk map, which opens a whole lot of other options. Also, BizTalk has a number of Adapters and Pipeline components, but the beauty of this is Microsoft has a supported set of APIs and SDKs so you can easily roll your own Adapters and plug-ins! Microsoft could have easily decided to make this a black box, but they didn’t…and that was an awesome decision.
Now, having that said…BizTalk tech is on its last legs…since MS developed a better tech in the form of Workflows…and with “Dublin” coming, and WF 4.0 incorporating more BizTalk-like features (like correlation), BizTalk is getting less and less attention…especially with that price tag.