Tuesday, 20 November 2012
How I explained SOA to my wife
Wife: We don't spend enough quality time together.
Wife (taking the keyboard away): You're not listening to me.
Me (taking the keyboard back): I am.
Wife: What's that you're doing anyway?
Me: My SOA blog. Look.
Wife: Soap Robe?
Me: No, that's SOA Probe. Probing the depth and breadth of SOA. Like it?
Wife: Looks like Soap to me.
Me: It isn't.
Wife: Well OK then, no need to get huffy. So what is SOA?
Me: Service-oriented architecture. It's a way of structuring software so that functionality exists as remotely reusable bits of software called services. Or, if you want to get formal, a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. (Yes, I recite this OASIS definition as part of my morning meditations)
Me: Which bit didn't you get?
Wife: All of it.
Me: Ok, let's see ... when you're paying for shopping online, does each store have its own payment method or something else?
Wife: Well, the websites all feel slightly different, but it's all Visa, Paypal or whatever underneath.
Me: Exactly. The stores use standard, shared payment services. That's SOA in essence: the ability to re-use in a standard way a shared service that may be half-way across the world. The alternative is that each store would have to build their own payment mechanism, which would be expensive and not core to their business. Right?
Wife: That's very exciting.
Me: Isn't it?
Wife: Not really. Have you fixed the upstairs light yet?