Software developers write code. By definition. Sure a lot of folks who are involved in the software making business don't write code, but these people generally have job titles like "architect" or "program manager" or "tester". And so, for instance, when a .Net developer moves into a BizTalk project for the first time they're gonna expect to write code. Because that's what they do. But here's the thing: BizTalk development doesn't need code. It is entirely possible to build an enterprise scale BizTalk application with either no custom code at all or very very little. Every .Net developer who read that just went "say what!?" But its true. With BizTalk development you have to have a very good reason to drop into code, and it takes time to understand when that is. And that's the crux of the BizTalk development paradigm.

I'll bet you that the first thing the majority of developers do when encountering BizTalk for the first time is go for the Expression Shape. Its the natural reaction. And there's nothing wrong with that, but if you're learning BizTalk and you don't spend the time to understand when and why you should write code and have helper classes etc and when and why you shouldn't, then you're not really a BizTalk developer. You're a .Net developer who can use BizTalk (sort of). If you take the time to understand the purpose of BizTalk, the way the MessageBox works, the way all the moving parts interact, then you're a BizTalk developer who can also do .Net development.

Let me put it this way: if I was a tech lead of a BizTalk development team and I was onboarding a new guy, as part of his wax on wax off training to become a BizTalk developer, I'd disallow him from writing code for the first couple of weeks (maybe a month). Only after you've learned to build stuff in BizTalk without code, can you learn to do stuff in BizTalk with code.

I'd be interested to hear comments/feedback on this if you find it provocative.


posted on Tuesday, March 13, 2007 3:30 PM | Print


# re: The BizTalk development paradigm
Posted by Alan Smith on 3/29/2007 1:52 AM
I'd agree with you there that quite a few .net ppl will try to solve problems with C#, rather than learning the correct way to solve things in BizTalk. I spent my first few weeks thinking "I can do this in 2 hours in C#, why does it take me 2 days in BIzTalk?". As you get your head aroud how BizTalk works, you do things in BizTalk in 2 hours that would take 2 days (or 2 weeks) to do in C#.

But there's also a catch 22 here, if I was hiring a BIzTak guy, i'd pick someone who was a good .net (or java) developer. Even though you don't 'usually' write much code, there are situations when you need to, and you need to have good programming skills to do so. Custom pipeline components, custom functoids, and C# utilities to call from orchestrations are usually required (ok, maybe not functoids) on most BizTalk projects, and the code for these component needs to be solid.

Along with the dangers of having .net ppl solving everyting with C#, you also have the danger of ppl who are scared of programming jumping into BizTalk development because thay think it's easy, and think they can build apps by drawing things.

# re: The BizTalk development paradigm
Posted by dvs on 1/23/2008 7:26 AM
I am totally new to Biztalk and want to learn it very quickly as there is a project requirement, I have good .net experience so can you suggest some gud book which i can pick and learn biztalk 2006.
# BizTalk Development
Posted by HectorOlsen on 11/21/2012 9:59 PM
The BizTalk upgrade also features documentation for deploying enterprise service buses.
Post Comment
Title *  
Name *  
Comment *  
Please add 2 and 3 and type the answer here: