Note, this is a partial response to Sam Gentile post about ALT.NET.

One of the things that Sam said that I fully agree on is this one:

...walking into a Fortune 50 bank with 200 systems, using 20 different technologies, totally non-integrated, and listening to the business needs and using solution technologies like BizTalk, Neuron, WCF, MOSS, Sharepoint and such putting together a solution that requires me to have intimate knowledge of the business as well as single sign on, multi-domain security trust domains, asynschronous message brokering and lots more

Solving this kind of problems is non trivial and requires understand both tech and business issues. There aren't a lot of problems like this, however. In fact, most of the problems that I am dealing with aren't at all similar. Which leads me to the parts that I don't agree with:

It comes from that community's [ALT.NET] inability to see beyond the code level, something I refer to being constantly in "the weeds." They refuse to work on back-end systems as beneath them, everything "enterprisey" is beneath them. Being in the weeds means you only look at everything as code and can only see code.

No, actually, it does not. If I can solve something easier using capabilities of BizTalk out of the box, I will use that. Hell, I am using BizTalk in my current project, precisely because of that, it makes talking to non reliable sources fairly easy, so I don't have to write this code. BizTalk is not enterprisey, but a lot of the solutions that utilize it are.

There is a reason that I don't like to hear about web services, ESB, etc. I understand and even approve the basic ideas, I don't like what happens when those ideas are turn into buzz-wards. The problem then is that you start the process of understanding the problem with "Assume that we have an ESB...", simply because this is the thing to do right now.

Sam calls my approach "being in the weeds" (I don't agree, but let us get to this in a minute), the other side for that is the Architect in the White Shiny Tower, handing Architecture to the masses.

Now, let us get to the "being in the weeds" and "refuse to work on back-end systems as beneath them". My statement to this is simply:

I will refuse to work on a back end system if using it will make my life harder than using another system/library or rolling your own, period.

SSIS comes to mind very clearly in this regard. It is not a blind refusal, it is an educated one, based on (painful) experience. Yes, I do have a prejudice against big back end systems, that came from seeing all the enterprisey solutions that where built on that. After seeing so much time going down the drain making a back end system behave the way you want (which I would have think was the natural way to handle), and comparing it to the amount of effort that it would take to just do it on my own...

I believe that I have a good basis to my prejudice. That doesn't mean that I will roll such systems completely, but that I will evaluate each case independently.

What Sam calls being in the weeds I call confidence. I am confident that I know what I am doing, that I understand both the business requirements and the technical ones, and I am capable of solving the problem without taking a preconceived dependency on a back-end system.

The problem with the approach that Sam depends is that it is too often so high you never sees any of the details, ending in an enterprisey result. One too complex for the job required, and costing more than it should. I never worked with Sam, so I have no idea about how he actually work, so keep in mind, this is not about Sam. It is about seeing and hearing about quite a few designs that are totally wahonie shaped, just to fit a preconceived notion of how Things Ought To Be.

And that is the approach that I would reject.