Tuesday, 20 November 2012

How I explained SOA to my wife


Wife: We don't spend enough quality time together.

Me: Uhuh...

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)

Wife: What?

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?