Monday, June 11, 2012

Not just a BizTalk Anti-Pattern

This is a follow up to my last BizTalk Anti-Pattern post

This is primarily for the Technical Recruiter.

My last contract was mutually terminated. I had worked for this client architecting their BizTalk 2006 R2 / ESB 1.0 EAI implementation.  I was contracted to architect their migration to BizTalk 2010.

There was a disconnect between what the client expected and what a BizTalk Architect role does.

After I completed their 2006 R2 / ESB implementation, the client had cloned the ESB 1.0 and deployed it on web servers. Not only did they duplicate the Itinerary functionality, but they customized it. They created their own custom core components and pipeline components.  

I won’t go into the details (saving these for the Anti-Pattern List). One of my tasks was to help the developers migrate their custom ESB Web Application to ESB 2.1.  All their tests were failing.  I was expected to help their developers. 

It would benefit everyone if you would ask the client for explicit details on what they expect of a role.  The client would rely on you more often to find the right person for the job..

A good source that describes the BizTalk Architect Role can be found on the TechNet Wiki.http://social.technet.microsoft.com/wiki/contents/articles/6243.biztalk-roles.aspx#BizTalk_Architect

If you search the TechNet Wiki http://social.technet.microsoft.com/wiki/, you should be able to details on other roles.

Tuesday, June 5, 2012

More BizTalk Anti-Patterns

Just assuming is also a BizTalk Anti-Pattern

About a month ago I accepted a contract as a BizTalk Developer for a major care product service provider. The project was to incorporate United Parcel Services mapping and routing services into existing BizTalk 2009 Applications. This was a major project with a fairly large budget. They were willing to pay a fairly high rate.

Part of the scope of the project was to incorporate the Windows Azure Service Bus.

Unfortunately I did not ask any questions about their current environment.  I just assumed….

  • It wasn’t until I started that I found out they were using BizTalk 2009 Standard.

  • They were not using Maps, WCF-Lob Adapters, Pipeline Components, or the ESB Toolkit. The only had a few schemas

  • They did everything in .Net code and WCF Services and called these services from Expression Shapes in Orchestrations

I was told that the were only using BizTalk for Guaranteed Delivery.

I demonstrated how they could easily develop this application in BizTalk without the need to write a lot of code.

 

They had no interest in changing their use of BizTalk. Nor were they interested in upgrading to Enterprise.