Bob's dilemma

I know what Bob means. BizTalk is, no doubt, a huge powerful beast which I know can be a really useful tool for traditional EAI. I suppose where it falls down is as a backbone for your entire service architecture. I don't think it was ever architected for that purpose. I think what's happening is that Bob is starting to think of things from a business-as-usual perspective. It's hard for me as a developer to think that way, but I can understand where he's coming from.

The dream of business technology architects is of this world of smooth-running, purchased off-the-shelf systems which they know will work (or be fixed) because the internals of those systems is Someone Else's Problem. As the teacher once said:

An SEP is something we can't see, or don't see, or our brain doesn't let us see, because we think that it's somebody else's problem.... The brain just edits it out, it's like a blind spot. If you look at it directly you won't see it unless you know precisely what it is. Your only hope is to catch it by surprise out of the corner of your eye.

The technology involved in making something properly invisible is so mind-bogglingly complex that 999,999,999 times out of a billion it's simpler just to take the thing away and do without it....... The "Somebody Else's Problem field" is much simpler, more effective, and "can be run for over a hundred years on a single torch battery."

This is because it relies on people's natural predisposition not to see anything they don't want to, weren't expecting, or can't explain.

I don't think this is all about wanting to avoid responsibility either. And it's not really about control. Yes, it would make things simpler to be able to control everything, but it's more than that... There's actually a sense of embarrassment or disbelief about how hard it is to get past the basics. I think these architects are really longing to do something wonderful with their technology, but they just keep getting hung up on all the detailed problems that come their way. Not least among these is the politics of dealing with all the people involved. It requires a certain amount of trusting the unreliable developers to create a custom built system and that just seems like a poor way to powerfully execute on the task at hand – it’s got way too many points of failure. Technology should be simple, sleek, solid – not flimsy and byzantine and likely to blow up if you look at it the wrong way. Technology should be built by Buddhists…

The other thing is – and an architect knows this better than most – often it’s not what inside that counts. Good solutions exist which have an amazingly sophisticated and beautiful interface, with some one inside peddling a bicycle to make it all happen. I think architects instinctively feel that in order to get a really satisfying solution, a sacrifice is required, which is to live in the knowledge that inside, everything is held together with tape….

So I understand – I really do get what he’s saying. But I suspect that he’s still way off base here. There is no way I can look at BizTalk and say, “yep – that’s the ticket to a successful enterprise. Just run everything through that box and everything will be ok.”

So what advice to give? I suspect another post is in order. The problem is pretty well described, but I still don’t see the answer. I understand why “just build it all yourself” isn’t a viable option, and I can see why “just buy it all” also doesn’t work.