Serious About Play and Comics

This morning I watched Dr. Stuart Brown talking about the importance of play. He makes a number of compelling points about the role of play in the development of trust, innovation and social interaction. More specifically, Dr. Brown reminds us that stories and storytelling provide "the unit of intelligibility in our brains" (how we make-sense of stuff).

Dr. Stuart Brown: "The basis of human trust is through play-signals"

This reminded me of an article I wrote for IASA where I talk about my experience of importance of storytelling skills to Enterprise Architects. Here's a couple of things I said:

"Enterprise Architects should be convincing and credible storytellers....We architects must learn to become comfortable with the journalists’ technique of ‘Simplifying and Exaggerating’. It’s much more important to convey a highly simplified message about a complex problem to the business stakeholders than it is to demonstrate our grasp of the complex and the obscure. We must become proud of our ability to distill and communicate the important opportunities – and the barriers to change.”

and

“Cartoons and other visual media are a powerful way of communicating often quite complex, and sometimes contentious issues, simply".

Building on the value of play and storytelling in communicating sophisticated ideas, another TED video from Scott McCloud got me thinking more about the value of comics & cartoons.

Architects are comfortable with the idea of creating visual maps and blueprints. They seem less inclined, however, to see the value in 'less scientific' visual expressions. Scott McCloud does a great job of resolving this science v. arts  discomfort. He uses a number of phrases that rung-a-IS-architecture-bell for me – he talks about “watching for patterns” and explains the journey from "visual iconography to language" and creating “temporal maps” - this is the stuff of IS architecture.

Finally, he talks about creating “durable mutations” of the comic medium that create window's back into our world. And as these mutations develop they will “provide people with multiple ways of re-entering the world through different windows and when they do that it allows them to triangulate the world that the live in and see its shape".

Could one of these “durable mutations” be a new way to express Enterprise Architecture to 'the business'? And is this idea more generally applicable to how we communicate our values and build trust - independent of practice or discipline?

The Great Granularity Debate

Events of the past week have led me back to the "Great Granularity Debate" that goes hand-in-glove with Service Orientation. I was discussing this with some colleagues last night - I described the problem I was dealing with as a 'nano-Lego' problem. This problem seems to come about when technically-focused architects define a 'SOA' without binding it to business drivers and objectives - this results in a plethora of  fine-grained 'architecture-for-architecture-sake-services-for-god's-sake technical services that look suspiciously like re-usable 'OO' objects (they didn't get reused either did they?).

In this particular case, the business would like to move away from their old monoliths to more granular architecture that would allow for more efficient change. They don't seem to be bothered about reuse and put performance much higher on the list. They also recognise that they're not experienced in doing things a 'Service Oriented' way and can see some of the problems in funding cross-project service development. 

All this tells me that the most appropriate SOA for these guys would be a coarse-grained and business focused. Finer grained services might be developed later as their maturity in things service oriented develops.

So my message to the techies - put the tweezers away and find some heavy lifting-gear to put those chunky business services in place first.

A Question of Meaning

A flurry of emails, tweets and posts that took place after Richard Varyard posted a question that asked how 'meaning' is addressed in VPEC-T (the main points of which are captured in this thread).

The reaction from VPEC-T practitioners & supporters was interesting in that they were quick to defend the simplicity and ubiquitous & 'Agile' nature of VPEC-T due to that simplicity. A view I share with them.

To quote my colleague, John Schlesinger, “Meaning is a sky hook for VPEC-T” ( and by implication not a missing dimension per se) and Peter Evans-Greenwood suggested: “Light-weight, user and business centric approaches (such as VPEC-T) provide us with a way to remain relevant and a more dynamic and light weight business world”.

The table below is my interpretation of Chris Bird's email that described VPEC-T as columns and an open list of 'Cross Cutting Concerns' that shape meaning across the five VPEC-T dimensions.

Full size image here.

From my point of view, this discussion helped me with a 'writer's block' problem I was having with where and how to take VPEC-T forward. It became very clear to me that I need to start to build an 'Open' repository of VPEC-T Use Patterns. These patterns will make VPEC-T more 'real' through description of how the dimensions are applied in particular situations and to tackle the sort of 'Cross-cutting Concern' that Chris mentions.

I hope to start work on the repository soon and plan to host it at vpec-t.org (I'll post on this blog when I get something worth looking at up).

Here's the concept map I used to order my thoughts following the stream of emails, tweets and posts.