Service Oriented Architecture

Every so often, I feel the need to peek behind the curtain to see what the IT guys are up to. I generally regret having done so, as the technology behind the screen has very little to do with the user's experience of interacting with a Web site. Even when I get a sense of what's going on back there, I feel none the wiser for it. And this is no exception: having just read the Service Oriented Architecture Field Guide, I'm left with an overwhelming sense of "so what?"

It's not that the book wasn't well written or failed to explain SOA in terms a layman can understand - it's actually quite good in both regards - just that I don't see that it matters at all whether the information systems that drive the functionality are cantankerous juggernauts with redundant capabilities or nimble services that enable the developers to patch together applications from mix-and-match components. If it works, it works, and I don't need to know the reasons why.

If I were to try to salvage some value from the time invested, I'd say that it's another reminder of one of the basic principles of user experience: that the user approaches a device with the desire to accomplish a task or fill a need, an they are not particularly interested in the nuts-and-bolts of how the value is delivered. But the more I think on it, the more it seems to be that few Web sites do that anymore, and that's a Good Thing.