Interoperability and interresponsibility

(This one’s somewhat exploratory, so perhaps pardon me if I ramble a bit more even than usual here?)

Reading Dion Hinchcliffe’s excellent post ‘Enterprise Social Networks Need Open Standards‘ left me pondering on the whole thorny issue of interoperability, and the way in which at present the mobile-app scene especially is devolving into a scrambled mess of of sandboxed silos – exactly the opposite of what we need in social-business.

Sure, sandboxes a la Apple do in principle support better security – but at a huge cost in terms of interoperability and information-sharing. A simple customer-journey assessment would show that sandboxing will only work well from the user’s perspective if the app does absolutely everything that the user might need – which just doesn’t happen in the real world.

Dion makes several great points in his post, and I do like the Jive !App concept he describes there, as one way out of the mess at the technical level and, in some ways, at the user-experience level too. I’m wondering, though, whether the focus on interoperability is enough: what we really need to be looking for is interresponsibility.

What do I mean by ‘interresponsibility’? Something that would include all of this, and probably more:

• connects seamlessly at the IT-protocol level (as OpenSocial and so on seem to aim to do, as per Dion’s post
• cconnects seamlessly at the identity level (as OAuth and so seem to aim to do, again as per Dion’s post)
• connects seamlessly at the information-exchange level (as XML schemas and so on sort-of do)
• connects seamlessly at the user-experience level (of which Apple-style sandboxing explicitly does not do, and Jive’s !App model sort-of does, if in a still very clunky way)
• seamlessly maintains the flow of responsibility from one person to the next (as in Sigurd Rinde’s brilliant Thingamy model, or collaboration-systems such as Trello)
• seamlessly maintains awareness of and adherence to overall intent and purpose at a ‘big-picture’ level (which I haven’t seen any tool or toolset do as yet)

The first four points cover everything from a single user’s perspective, where there’s either no transfer of responsibility from one person to another within the app-space – which kind of goes against the whole object of social-business – or else is handled entirely in a transaction-layer above the organisation’s systems-of-record – which traps us in the classically-inefficient hub-and-spoke style of collaboration. In other words, definitely good, but only good as far as it goes: ‘necessary but not sufficient’.

So-called ‘workflow-systems’ would probably claim to do the fifth point, about flow of responsibility – but most do so only with predefined structured sequences, which is not much help in dealing with real-world complexities that stubbornly refuse to fit the workflow-designer’s expectations and rules. Free-form tools such as Trello are probably better for real-world applications, but often a bit too free-form, in that they give little or no guidance as to what most needs to be done next, and by whom. Thingamy is the only tool I’ve seen that gets the balance pretty much right, but for the most part it only works within the Thingamy space itself – which again brings us back to the interoperability problem.

That last bullet-point is going to be the most difficult one, because it means taking interoperability-standards to a whole new level. It’s not just about the one app, or the one person, but the overall intent – much the same theme as the military concept of Commander’s Intent. It’s about adhering not just to business-rules, but also to more blurry business-principles that guide decision-making in ambiguous contexts – which is where strategic and enterprise-architecture concepts about enterprise-vision and the like become extremely important.

At a practical level, consider the, uh, joys of spamming. Spam-blocking is an interresponsibility issue: spammers are (very obviously) not adhering to the users’ intent and purpose for the app and its channels. The whole point there is that a spam-email or spam-comment (or, for most of us, most advertising…) is that it’s identified as valid at the technical level, the transaction level, but not at the intent level. So when we block and filter for spam, what we’re doing is checking whether the transaction aligns with the intent – which is fine, but we really should have checked for that before we allowed the spam to waste any transaction-resources at all, because it literally has no business to be there.

Okay, best stop there for now – but that gives some sense of the overall idea, I hope?

To make this work, there’s obviously a whole load more depth that we’d need to go into for this, and I know I can’t (and shouldn’t!) do it on my own. But I hope there’s enough there to play with for now – over to you, if you would?