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?

Tagged with: , , , , , , , ,
Posted in Business, Enterprise architecture
One comment on “Interoperability and interresponsibility
  1. Hi Tom
    Re inter operability, this usually seems to require
    some kind of shared language, syntax, vocab and
    protocol. This works at the lower levels but the
    higher levels resist this to a great extent because
    Meaning there is co determined by context rather than
    By the message itself. The intent you mentioned is, I think
    Negotiated over the duration of a conversation and where
    It is not, some shared cultural and probably social capital
    Can probably be presupposed. I think that perhaps the
    Notion of software agents and agent based system design
    Is suited to your problem. Agents are suppose to find out
    What they don’t know, remember key pieces of information
    Learn from success and failure etc. the key challenge with your
    Inter responsibility problem is I think the development of something like a
    Software culture similar to human institutions where there are many
    Standardized social transactions that our software avatars
    Will simply have to learn and internalize in the same way
    We did as we matured. Also some tolerance of nonsense and vagueness
    Would be necessary for most every day transactions.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Books by Tom Graves
Ebooks by Tom Graves
Categories
Archives