Jun 142007

I recently received an email from an anonymous blog reader asking why the recent posts about the minor discrepancies in the BizTalk product and how it would help them with resolving issues.

This is a perfect intro into the reason why I maintain a few blogs.

  1. These are my personal blogs, I don’t get any $ from MS for providing this information (however my wife thinks I should), so it is a lot of my rants.
  2. A reminder of the mistakes I have made, as before I had this blog, I would make the same mistakes over and over, and I finally realized that I needed to keep a record of all of my mistakes and how I fixed them so I wouldn’t need to re invent the wheel (so now you know that I am very proficient at making mistakes (the cat is out of the bag)!)
  3. Hopefully assist others from having to be as frustrated with the things that I have come across.
  4. Have a venue to present to a larger audience things I think could be improved so that the MS products in the dot releases or major releases are better, making my life easier (which is what I am all about (laziness)). By having a larger audience, MS listens to the masses a lot more than they do a single guy screaming of its deficiencies.

Since there are some of you that actually care about what I blog about, THANK YOU.

Could I ask a favor of you all who are my blog readers?

Could you tell me what you would like me to blog about, be it BizTalk issues, rants about the product, what you spend your time on, how you think the product (I don’t care which product) could be better, or the documentation better, or even my blog style.

I want thank Eric Battalio for suggesting that for my entries should be a little more ‘buildup’ to the answer, explaining how someone could get into situations where I provide the answer on how to resolve it. I am trying to give a little more background on the issues, instead of just the answer with no context.


Hope to hear from you

  • You could tell your wife that your blog is appreciated…

    One thing that I would like to ear more about is all the problems and best practices related to a full development cycle, including moving to stage and prod.

    We often see information on development, but far more less on deployment (or re-deployment) for Biztalk (including BRE, BAM, etc.)


  • Yes Chris, I hear you. A significant amount of time is spent on the development of the new software, but if there was as much on the testing and support the documentation would be very beneficial.