Artifacts of Shared Understanding


 

It’s become apparent to me over the past 24 months that my practice has gravitated more and more towards tools and in particular tools that support information exchange. There is a common characteristic shared by these tools which is that they are all based on models that drive shared understanding of a problem, information, decision or opportunity space. I think of them broadly as Artifacts of Shared Understanding (ASU).

 

 

In any large complex organisation where information is being passed there tends to be a huge amount of friction. The information producer structures and shapes the information in a way that suits there work practice and tends to ignore the information consumers needs. This I believe happens as the producer is creating information for their own use and as part of their own work. The resulting informational artifact is neither fish nor fowl and tends to be bloated and filled with irrelevancies. The problem is more pronounced as at the edges of domains where expectations of counterparts knowledge and expertise are challenged. ASUs are particularly helpful for domain-bridging.

 

Guidelines for good ASUs

To be a good ASU you should conform to the following guidelines.

  1. Can be co-created with relevant stakeholders including the information consumers in a 1-on-1 or workshop format
  2. Is simple enough to be captured on a single page (A5, A4, A3 or large format A0 in the case of a workshop)
  3. Is clear about it’s limitations i.e. what opinions does it have, what limitations does it impose
  4. Is understandable to (appropriate level of detail, appropriate language use) and useful to the information consumer(s)
  5. Has clear usage guidelines e.g. how do I use, how do I know when I’m done, what questions should I ask etc etc

There are any number of existing examples that could be used as examples to illustrate how ASUs work e.g. Business Model Canvas, Customer Journey Maps, Empathy Maps etc etc. I’m assuming if you are reading this that these are familiar to you and need no explanation. So I’ll introduce a new model that I’m playing with.

ASU 1: Service Interface Design Canvas

First off YAC (yet another canvas) really. I think that we are missing some useful ones. I’ve been playing around with this canvas and sharing it with colleagues and IASA training participants over the past few months. I haven’t gotten around to writing up and releasing so this is the abridged version.

Service Interface Design Canvas V0.1 (PDF download)

Purpose: Design a Service Interface

Use: Everyone seems to be designing APIs these days so think of it in terms of designing an API. This is an ASU for API designers and API consumers (business & development consumers). It follows the conventions of Business Model Canvas with the Customer (consumer) on the left-hand-side, front-stage and back-stage.

Inspiration: Business Model Canvas and CBDI-Everware Rich Service Specification

Audience: API Developers, Business Architects, API Consumers (business), API consumers (developers)

Usage Scenario(s):

  • S1: Intra-organisation API development
  • S2: Inter-organisation API development (partners/customers)
  • S3: Platform Business Model Design (consumers, producers, partners)
  • S4: Industry Service Specification e.g. BIAN

Warning(s): This is V0.1 and the bottom left hand corner is currently a dumping ground for stuff. As it’s an early version it complies with most of the guidelines except the clear usage, but that’s experimental anyway at this point.

Takeaways

I believe that this is the way forward, each conversation and exchange we have as architects guided and supported by ASUs.

  • ASUs guide are the product of a conversation and information exchange
  • ASUs are useful to the producer and the consumer of the ASU to crystalise understanding
  • ASUs are there already but we are probably missing a few

More ASUs to come.