Balancing Reliability-X and Validity-Y

Earlier this week a Tweet from@rotkapchen (Paula Thornton) introduced me to this video of the Canadian academic Roger Martin. He talks about 'designing in hostile territory' and the tension between 'Reliability' and 'Validity' in the context of the challenge designers face in working with business and vice-versa. He hints at the dangers of measuring the things that are easy to measure and challenges McKinsey's notion the that 'Gut feel' management is dead and that “management will go from art to science” because we can now use 'algorithmic decision-making techniques' to run businesses. He contrasts that with the a designer's recent article that quotes William Blake: “I must create a system or be enslaved by another mans; I will not reason and compare: my business is to create”. (I thoroughly recommend watching his video when you have a spare 50 minutes or so).



His presentation, however, is not banging-the-designer's-drum, it is all about reducing the Business-Exec/Designer communication gap – the same subject of that Carl Bate and I tackle (between Business and IT) in 'Lost In Translation'. It reminded me of a various conversations with Carl about the challenges of being a right-brained, theory Y, innovator in a predominantly left-brained, theory X, reliability-focused corporate world. Roger Martin also reinforced for me a the importance of patterns, analogy and story-telling 'to generate quasi past data' for the X-ers around me. He also reminded me that the X-ers are 'guardians of reliability' which probably explains why the creative 'Y-ers' are best left in their labs to innovate rather than run-the-business.

All this got me thinking back to the thread of Tweets that had led up to Paula sending this link. Over recent weeks my fellow Twits and I (in particular, @Cybersal, @Chrisdpotts and @richardveryard) have been sharing views about Enterprise Architecture and the need for a broader set of lenses to fully understand the behaviour of organisations. And so this week when I saw a Tweet from complaining about the technical focus of many Enterprise Architects from Paula, it prompted me to reply “EA should be focused on business behaviour before tech drafting - good EAs provide organizational 'therapy'”. This in turn led to Paula sending me the link to Richard Martin's presentation.

So now I'm pondering the following:

• A good Enterprise Architecture must be a balance of X(Reliability - Doing-things-Right) and Y (Validity – Doing-the-right-thing) or to put another way, Industrialization and Innovation.

• We've spent to much time of methods that attempt to industrialise EA (to the point that I'm told TOGAF 9.0 runs to 800 pages)

• We need to spend more time on developing pattern-based storytelling skills in Enterprise Architects for EA bring break-through changes and allow for innovation in TO-BE models.

• Being X or Y minded is equally valid but both sides need to see the value of the other – I'm not always appreciative of my X colleagues as they 'herd' me towards on-time delivery and finished products, and I suspect they don't always see the value of my storytelling and idea-nurturing approaches.

• Recession needs to bring forth more Y-minded thinking ( with some sensible X-controls) - because doing the wrong-thing-well (repeatedly) got us into this mess!

• The world can't be fully explained or governed algorithmically (thank god!)– not while values and trust dominate the way organisations function.

Uploaded to Flickr by vaXzine (under Creative Commons license)

Thanks for thoughts about 'doing-the-right-thing' to @catuslee

Revamped Services Fabric Blog

I decided I'd spend thisn weekend tarting-up this blog and making use of the new blogger template gadets etc.I've also added more meaningful labels to make filtering on a specific topic easier (e.g. click VPEC-T below to see all VPEC-T related posts)

Other news: Richard Veryard created a Lenscraft wiki that promises to be a interesting place for developing a number of themes my Twitterati pals and I've been discussing for a while.

Photo Credit ShoZu on Flickr

The Tao of Project Management

I thought I'd do something different for Easter so I've dusted-off this short piece I wrote about 10 years ago after being asked to deliver internal project management training around the DHL Asia Pacific region (those were fun times!).Here it is...

We're all Project Managers. True, some of the projects we've managed might be nearer the gluing-autumn-leaves-in-a-scrap-book type than the launching-a-space-shuttle type, nevertheless, most of us would claim we have project management skills - after all it's just common sense, isn't it?

Taoists, of course, would agree - projects should be run simply, honestly, holistically and with a sense of fun.

A few thoughts that you are unlikely to come across on a Project Management training course:

Creating and managing projects is as much an art as a science. That is not to say that we should abandon tried and tested methodologies and techniques - just that balance is required - a 'Whole-Brain' approach to project management.

Taoist teachings emphasize the need for balance and unity - yin and yang.

Engineering and organisation alone do not guarantee success. I've witnessed well engineered and administered projects fail - the most significant of which ran to more than US$500 million before it was stopped - with very little to show!

The key to success is in the softer issues of business vision, people and flow. Much has been written about left and right brain and more recently 'whole brain' thinking. I suppose that's what I'm talking about. The most common representation of this thinking is the yin and yang symbol. Two opposites live together in a circle: one feminine/ right brain and the other masculine/left brain.

Projects are about people. People respond best to a balance of left and right brain - so projects are best run with a 'Whole Brain' approach.

Here are some key words that might help to stimulate a 'Whole Brain' approach …

Deliver	Communicate
Structure	Empathize
Standardise	Relate
Procedure	Share
Administer	Unify
Analyze	Include
Engineer	Simplify

Given that you believe like I that people are the primary concern of the Project Manager, Communicate must be at the top of his list next to Deliver. I leave the reader to judge the relative importance of the rest of the list.

Tao teaches us that neither side is more important. Balance and harmony matter most.


Thanks to http://www.chebucto.ns.ca/Philosophy/Taichi/lao.html for the image

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.

Why Do I Find Twitter So Useful?

Maybe its my background in Tracking & Tracing systems that leads me to see event-centric patterns in almost everything - and Twitter is no exception. But what's intriguing to me, is how Twitter seems to be the result of the coming together of a number of design patterns. I find this makes Twitter a usefully addictive, relationship-building and idea-stimulation tool.


But the thing that I find really intriguing, is how it seems to illustrate the value of separation of 'content' from 'event'. That is, a tangible value from broadcasting and receiving short/short-lived messages (signals) that describe what you're doing or perhaps, more importantly, what your thinking independently of, but with reference to, the full text, dialogue, or any other expression of an idea or perspective (the content). This combined with the ability to choose who you follow and who follows you, creates trust-building relationships across a network of like-minded brains. These snippets of information shared, referenced and re-referenced (Re-Tweeted), by those I follow and those who follow me, have become a great reference source and provide regular source of thought-provoking ideas.

Twitter illustrates how much can be achieved with some very simple patterns, without top-down control or grand-design. IMO its success is due to its ease-of-adoption and the simplicity of its policies and protocol. In some ways its similar to internal email groups I subscribe to, but the big difference is the ability to explore the endless chain of Follower/Followee synapses, find like-minds and then follow urls to content that I wouldn't normally discover.

What does strike me as I write this, is that I suspect people have very different experiences with Twitter depending on what interests you and therefore who you connect to and what you talk about.

I know a number of my colleagues are not convinced of the value and will probably remain unconvinced after reading this post. I wonder how much our, life circumstances, personalities and philosophies affect the value we get from Twitter?

http://twitter.com/taoofit

Why Service Orientation should start with Systems and not (always) end in systems

In publishing this I'm throwing caution to the wind (and ignoring, in part, the good advice of a respected friend!). Chris Bird, suggested that I should avoid talking about Systems Thinking, Service-oriented Architecture and other such consultantese. But I've decide I will talk about Systems Thinking and SOA as they relate to a broader world-view of services (given the focus of this blog).

To start the discussion, however, I'd like to quote Chris: “ SOA starts in the wrong place. The tools are tools and not grand strategies. I don't look at the screwdriver in my hand and say, "Cool, now what projects can I undertake?" I think about what needs fixing in my house and what tools I need (aside - the checkbook is my favorite tool)”.

Mindful of Chris's words and a client's SOA-related organisational challenges in mind, I thought it was about time I added my two-pennies-worth to the SOA-doesn't-work debate. My observation is that many SOA projects start in the wrong place - that being in the technology weeds i.e. Conversations around ESBs, WS*, Registries, EJB, XML et al. I believe the first step towards 'service orienting' a business is taken by applying Systems Thinking (that is Systems in an ecosystem sense) rather than thinking about Services per se and certainly before technology view of SOA). Most importantly, the notion that a business is comprised of multiple, interacting, 'Systems' of people, processes and technologies (agents of the system) that cannot be viewed in isolation one from another but accepts each system/sub-system works within a unique set of values.

Taking a fresh Systems Thinking (capital 'S' Systems from now on) perspective helps to breakdown the more traditional organisational and process bounded views of the business and that the complexity of the behaviour of the business is best tackled by examining the interactions between 'Systems' that often span traditional boundaries. This then helps layout the organisation as a set of 'System' behaviours that can, for example, be examined as core or context to the business operation/strategy/well-being. I've found that with this approach, its possible to evolve certain 'Systems' into 'Services' by defining the Consumers, the Policies/Contracts that apply, the Events that trigger action and the Content being exchanged (physical and/or informational). This 'Big Services' (Systems)view allows the business to see how to chunk-up aspects of the operation in new ways that helps with business problems such as: simplifying post M&A situations, executing major transitions, outsourcing. And, from an IT perspective, where/how to apply SOA, COTS packages or SaaS for that matter.

I've been accused of being too idealistic when I say Service Orientation starts in the boardroom not the IT department. I agree, it's often hard, if not impossible, to get SO on the business agenda but if your SOA is being 'sold' as a way to achieve 'business relevant' efficiencies and associated cost reductions through service reuse, then board members must be the sponsors. This becomes most obvious when organisations realise they must change the way they fund software development and/or procurement projects to realise the desired sharing and reuse.

So how can 'Systems Thinking' be introduced to the CxOs without appearing to be too academic?
The rule is to avoid talking about Systems Thinking and, for that matter, SOA. Instead, the discussion is focused on delivering business value around a topic that is front-of-mind for the board: Compliance, Profitability, Green-agenda or Strategy execution might be such topics. Then the trick is to use simple 'Systems Thinking' techniques and tools (akin to S.W.O.T. or Forcefield and Mindmaps or PowerPoint) to start to describe the emergent services.

As Chris points out, it's important to be looking at the cross-cutting concerns of the enterprise (and the extended enterprise - but extended from a business sense, not an IT sense). I believe that getting the CxOs to buy-in to SOA via Syetms Thinking - (without necessarily trying to teach them the Theory!) - is the way to make SOA work, and for that matter, improve many aspects of their business operations and strategy execution with or without SOA or with or without IT systems.

To bring to a close, I'd like to paraphrase Chris again:

“We must focus on what the enterprise wants to achieve. There are many ways of getting "it done". Goldblatt in "The Goal" makes some useful analogies. The goal in manufacturing isn't about keeping the machines busy, it is about increasing value - converting raw materials into products at the optimal rate for making profits (even if you have to underutalize resources). In the SOA world, the corporate goal is not to maximize the use of IT tools, (to suborn everything to the technical services oriented architecture), but to look for services that deal with the Events that the business has to deal with. I think we have to get the very loose coupling done first before thinking about SOA in companies. Until the businesses think in terms of hand-offs instead of commands, they won't get any of the benefits possible anyway”.

I believe subtly applied Systems Thinking will help us put controls where controls are needed, don't control what doesn't matter and help us answer the question; “How do you focus on what is important, and at the same time not miss the critical details?”

The Cynefin framework and 5D lens are both tools that can help introduce Systems Thinking to broader audiences.

As always, I welcome your comments.