After my last post on this topic Alan Smith left a comment on my blog.

His comment was a good point and is worthy republishing here, to round out the topic.

Here it is verbatim:

"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."

 

It never occurred to me that a non developer would look at BizTalk as a way to dev work with out code. Thats never gonna work. BizTalk is well and truly a developer technology.

posted on Thursday, April 19, 2007 11:30 AM | Print

Comments

Gravatar
# re: The BizTalk development paradigm Part II
Posted by Mike on 4/22/2007 4:33 AM



In my opinion i wouldnt employ a BizTalk developer who wasnt also strong
in a .net language. In addition to the points discussed by Alan, my reasons
for this are as follows:

1. In the solution it is likely i will be wanting to stub some of the
external applications which BizTalk will communicate with, this is
quite often done with .net code

2. If any custom C# code is written for the project i want it to be good
quality so i will want someone who has experience of unit testing. One
of my pet hates is when someone writes a helper method in C# and wonders
why it isnt working correctly when called from their orchestration, but
actually they havent even bothered testing if it works on its own

3. A good .net back ground usually indicates they have decent debugging skills.
i think is very important for BizTalk development. In my experience i often
find one of the causes of people writing unnecessary C# code is that they encounter
a problem but cant find its cause in a relatively short period of time so end up
coming up with a completely different way of tackling the problem

4. It is quite common to develop tools and build tasks which compliment the
BizTalk project and help it become a quality solution. I prefer a BizTalk
Developer to be capable of doing these things rather than having to employ
an additional person.

Love to know anyones thoughts on this

Mike
Gravatar
# re: The BizTalk development paradigm Part II
Posted by Mike on 4/22/2007 4:33 AM



In my opinion i wouldnt employ a BizTalk developer who wasnt also strong
in a .net language. In addition to the points discussed by Alan, my reasons
for this are as follows:

1. In the solution it is likely i will be wanting to stub some of the
external applications which BizTalk will communicate with, this is
quite often done with .net code

2. If any custom C# code is written for the project i want it to be good
quality so i will want someone who has experience of unit testing. One
of my pet hates is when someone writes a helper method in C# and wonders
why it isnt working correctly when called from their orchestration, but
actually they havent even bothered testing if it works on its own

3. A good .net back ground usually indicates they have decent debugging skills.
i think is very important for BizTalk development. In my experience i often
find one of the causes of people writing unnecessary C# code is that they encounter
a problem but cant find its cause in a relatively short period of time so end up
coming up with a completely different way of tackling the problem

4. It is quite common to develop tools and build tasks which compliment the
BizTalk project and help it become a quality solution. I prefer a BizTalk
Developer to be capable of doing these things rather than having to employ
an additional person.

Love to know anyones thoughts on this

Mike
Post Comment
Title *  
Name *  
Email
Url
Comment *  
Please add 5 and 5 and type the answer here: