Enter your email address:

Delivered by FeedBurner

HOAP slide deck

I have been asked by some friends at the user group to post the slide deck for the agile talk. I put them up at my new site on officelive. www.brianhprince.com. Lower right hand side. The editing tools for office live aren't even close to what SharePoint can do, and I am starting to see some of the limitations. Anyway, enjor the deck. I also included all of the hand outs, etc. Let me know if you have questions.

HOAP in Columbus

There will finally be HOAP in Columbus. I will be doing Hands on Agile Practices this Thursday (5/25/2006) at CONDG.org. It is at the Microsoft building in the Polaris area. There have been plenty of great talks on Agile/xp, and what it means. They explain the why really well. The beliefs, etc. After those though I have always wondered about the how. This talk will focus on those things that WE do. HOAPfully this will help you adapt your practices. Then, as usual, it's hoggy's afterward.


BizTalk 101 in Findaly Ohio

I have the pleasure of presenting my BizTalk 101 talk to the Findlay, Oh area .NET users group on 5/24/2006. I really like driving up there and working with them. They always have great questions. If you are in the area, you should drop by and say hi.

I will cover what this thing does, and how you can use it in your enterprise, your application, and how it can make your life better. :)


Where do business rules go?

‘Where do I put my business rules and logic? Where does validation fit in?’

I don’t know how often I hear this from clients. It is always asked in one or another during most coaching or development engagements. Sometimes it is because of BizTalk, and other times it is because of Atlas (or some other front end framework).

Our first rule of validation:
‘All validation is done on the server side.’

The business layer is responsible for validating its input. We never trust input coming from outside the business layer. This is a fundamental guideline for application security. Any validation on the web client is purely to support a great user experience. It should definitely be there, but it is just for the user’s needs, not for the system’s needs.

So, where do you put your business rules? As with many things with BizTalk, it depends. The first aspect to consider is how you are using BizTalk in your system. If you are using it as middleware to integrate several different systems (sort of an ESB approach), then your business rules should be used in the systems themselves. You can still use the BizTalk Business Rules Engine, but it should be used from your applications, and not embedded in the messaging layer of your bus.

However, if you are using BizTalk to run your application on as a platform, then there is a continuum for you to consider. The most important aspect to drive where on the line you want to be should be how often these business rules will need to be modified. The more often they change, the more cheaper and easier you want it to be to update them. Remember that a good business changes, and it's systems must support this.

On the far left side is the ‘custom code’ approach. You would bake the rules into your source code. This will give you the best speed of execution, but the worst story for maintenance and management. You will not easily be able to change the rule if you need to, and you will have the cost of moving code changes through your lifecycle (testing, qa, promotion to production, updating support documentation, etc.). This is also the most brittle solution, and will reduce your systems ability to be agile.

The other side of the continuum is to put the rules into the BizTalk Business Rules Engine (BRE) and then access those rules either through orchestrations, web services, or through the BRE API. The API is the fastest, but the web service approach can help you leverage those rules in other places. One of the best advantages to this approach is the centralization of your rules. Keeping them in one place can greatly reduce the cost of maintaining a system. Of course, if you aren't using BizTalk you can still do this, just find another rules engine to use. On our Java projects we use JRules. I wouldn't build something like this when there are so many good alternatives out there already.

In the middle of this continuum is the option to put rules in the orchestrations themselves. This is risky in my view, but an option. I only use it for trivial rules that are truly a workflow routing question. Even if the rule is simple, a tax rate for example, I know that in the future it can grow to be more complex. This approach is less expensive than maintaining code, but more expensive to maintain than the BRE based approach.

I think your decision can be made on a case by case basis as you are building your system, but sticking to one approach will make your system more consistent.

Hopefully this can act as some guidance for you as your design your system. Unfortunately there are rarely hard written rules in architecture. Most decisions come down to a choice, where you need to discuss the benefits and costs of each option. In the end, you should always strive to reduce the system brittleness, the system maintenance costs, and to inhibit ripples that changes cause in the system.


Thanks to areyn for helping with this post.


I have setup a site for myself at www.brianhprince.com. I am keeping my blog here. I setup the site with MS Office Live. I wanted to get the domain name for free, and have an easy place to host files or stuff that I reference in my blog.

I also wanted to try out the new service. It isn't bad for a beta. There are some significant features missing though. I can't get rid of the lame border around linked images, nor can I use custom HTML/CSS to place my own content. Even the content web part for Sharepoint can do that.


TechEd 2006 Schedule

I am getting very excited about going to TechEd 2006. Not only do I get to go, but I get to present. This will be great.

I will be attending the second half of the MVP Engagement Event Sunday afternoon, and the influencer's party on Wednesday.

Keith and I were just told that our session has been booked for that Thursday (6/15) at 8:00am! So, it looks like I won't be partying too much at the Influencer's Ball.

Our session is :

CON329 - BizTalk Server Solution Lifecycle: Planning and Design (Part 1)
Level: 300
Part one of a three-part series of sessions covering the design, implementation and management of a BizTalk Server solution. The first session covers the common scenarios where BizTalk is an appropriate solution and what questions you should be asking to develop appropriate timelines, resource plans and deliverables. This session provides experienced IT project managers, who may not have previously worked with BizTalk Server, the background needed to successful launch a BizTalk Server project.

Timeslot: 6/15/2006 8:00 - 9:15

Our's is the first of three related sessions. Please let me know of any requests for our topic, I hope to see you there!


Simplicty bites

I am a big fan of simplicity, which is an unusual trait for us architects. But sometimes, it can waste some of your time.

In BizTalk 2004, while using VS2003, if you wanted to push up your solution to the server to test it, you had to (chant with me now) RE-build, RE-GAC, RE-start [the host]. This can be a huge hassle, and slows down your momentum during development. To the point that you almost avoid it as long as you can. This always caused problems for me, since I would be tempted to break the 'change one thing at a time rule.' This just led to more frustration on my part.

With the new BizTalk 2006 developer tools that plug into VS2005 they made this so much more simpler. You now right click the project, and choose 'deploy.' And that's it. It's all handled for you under the covers.

VS will rebuild (if needed), upload, regac, etc. to get you new code running. Very cool. It made huge increases in my productivity, and has made it easier for new BizTalk developers to get familiar with BTS. The old way was a huge barrier to someone learning this on their own.

The new process has worked for me just fine for a while now. But I generally stick to content based routing, and do as much as I can with pipelines/maps instead of orchestrations, at least with the stuff I happen to have been working on in BTS06. I have been working heavily withthe SQL adapter, and was doing tests on calling stored procs, updategrams, and debatching responses, so I had no need for orchestrations.

Then I was trying to do a quick and dirty orchestration one evening. I got the basic version up and running with no problems. I tend to develop my orch's in baby steps, with multiple short circuits to see what is happening. When I went to test the next baby step version, the new shapes in the orch weren't firing. The orch would just stop on the last shape the old version ran. HAT would step through just the old shapes, and ignore the new ones, even with break points! At the time I didn't recognize the true behavior that was going on, and it led to at least half hour of cursing. Eventually I went back to basics and re-started the host that the orch was running in. That fixed everything. My excuse, of course, was the I was tired from playing Oblivian. :)

[Side note: This also reinforces my rule number 8 of development: "The size of the root cause of your problem is directly proportional to the length of time to find it." Meaning, a major problem can be found quickly, and small problem, like a missing semicolon would take hours. ]

Of course, knowing about the orch's and assemblies, etc. this makes perfect sense, and I am ashamed this even happened to me. But I became dependant on the new simplicity in VS2005, and forgot a little of what was happening under the covers. The orch's assembly was loaded, and even though a new one was published to the gac/server, it didn't matter.

So, sometimes, simplicity can bite you. Sometimes it makes you forget the underlying 'stuff'.' Sometimes it causes you to take for granted what is happening. For Shame. :(

Ayway, I learned my lesson. I did find a new property on BizTalk projects in VS05 that allows you to have the host auto-restart. More Simplicity! I didn't turn it on, becuase there is a delay in deployment while studio waits for the host to restart. But it's nice that it's there. You can also set which BTS application your project is deployed too, which can be important.