Training with Udi Dahan - it's all about business

I know it’s been a while since I wrote my last post but in my defence :) I went to SEA for over 5 weeks and on purpose disconnected from the whole IT-related online world. It was great :).
Anyway, back to the topic. A couple weeks ago I went for a week long training(Advanced Distributed System Design with SOA & DDD) with Udi Dahan. It was, in a positive way, a mind blowing exercise. I already knew about messaging and how it helps to fight different types of coupling but only listening to Udi made me understand those concepts in depth.
From what I observed the topic that caused most of the confusion among the attendees was Command-Query Responsibility Segregation pattern. I have to admit that I’m still wrestling a bit with this topic myself but I’ve learnt the hard way that using the same channel/model/approach for both queries and commands simply doesn’t scale and will bite you sooner or later.
But today I want to talk about something else that Udi mentioned a few times. Namely, one of the most common mistakes that IT people  make is trying to solve business problems with technology. Yes, you read it correctly :).  Let me give you an example that should explain what I mean. I suppose everybody saw at least one implementation of WCF smart proxy. One of the reasons people write it is to transparently handle exceptions and make sure that developers that write business logic don’t have to deal with them. One of the implementations I’ve seen catches a few WCF exceptions and then re-tries the failed call. The implementation assumes that the call didn’t succeed on the server side. Obviously that’s a wrong assumption and this code can cause a lot of damage. Would you send a customer 2 or more laptops(depends on the number of re-tries) whereas he/she ordered just one? In this case a developer tries very hard to solve a business problem(what happens if a call to a shipping service fails) with a technology (WCF smart proxy). Maybe the code shouldn’t try the same shipping service again but move on and call a different one or maybe it should notify the system administrator that there is a problem that needs to be handled manually. This question needs to be answered by the business and then based on the business input a technology-based (or not) solution can be implemented.
Someone could still argue that it’s a technology problem because the communication channel is not reliable enough. Well, the fact that a company uses web services (and not phone calls) to place shipment requests was a business decision. On one hand in this way you can ship goods faster to the customers but on the other hand you have to deal with a new type of problems. Unfortunately, in real life nothing comes for free.
Again what’s the role of IT? I believe our role is to implement solutions provided by the business. This doesn’t mean though that there is only one-way relationship between business and IT and IT always does what it’s told to do. As IT we can and should give feedback to the business whenever we see anything that might have impact on it but at the end of the day it’s up to the business to make the final call.