Sunday, November 02, 2008

VPEC-T Google Group

I've set up a Google Group for discussions and resources related to the VPEC-T Framework, Anyone can view and post to the discussions there however, non-members' posts are moderated. 

This will effectively replace the now defunct VPEC-T wiki (since Scribblewiki went to the wall!)
n.

Saturday, October 25, 2008

5D Lens (aka VPEC-T) as a Mindmap

Roy Grubb, a consultant in Hong Kong, has produced a great Mindmap of the VPEC-T framework as part of a comprehensive review of Lost In Translation and the VPEC-T approach to IS analysis.

Roy's work has reminded me to mention Mindmapping as a tool for applying VPEC-T, particularly when doing a desk exercise. The a pre-developed Mindmap or Concept Map before by a 5D Lens workshop is a great way to get the thinking started.

Thanks Roy!
n.

The Tao of Enterprise IT Episode 2

Heres the next episode in the Tao of IT webcast.



Sunday, October 19, 2008

Tao of Enterprise IT

Here's the first episode of a webcast based on a presentation I made to CIOs and IT practitioners in Hong Kong in September.



I decided to break it down to 3 or 4 episodes to make it easier to consume over the web. I hope to post the other episodes over the next ten days or so.

In the meantime, if you watched this episode and are hungry for more background to the 5D Lens (aka VPEC-T) please take a look at the original blog post here and the book website. You will also find reference scattered throughout this blog - so feel free to explore!

If you have any comments about this first episode, please feel free to post them here.

Thanks

Nigel.


Tuesday, September 16, 2008

X&Y and Enterprise 2.0

sHere are the full proceedings of the MashUp* Enterprise 2.0 event. I was prompted to post them here now following  a couple posts on the Capemini CTO blog - X&Y   and Ent 2.0 and Simplicity.

The hook for the latter is "I believe this is to be important because, this is the first t time, a strong relationship can be made between emerging business leadership practices, Web 2.0 phenomena and the practice of IS architecture".

The video's below are worth a look if you want to hear the debate about Web 2.0 applied to the Enterprise and , in my case, why I think we need to develop new thinking to get to the value.




The seems low at the start of this next video - but don't be fooled, the first speaker isn't using the mic for the first moments!








Tuesday, July 22, 2008

Business behaviour before technology

Prompted by Carl Bate's post and Andy Mulholland's post on the Capgemini CTO blog, I felt compelled to add my two-pennies-worth. Recently, I've been working on the seemingly endless challenge of describing why the VPEC-T framework helps both business and IT. To me, the points Carl and Andy make about Business and IT being fused into 'Business Technology' driven by the Web, are reasonable observations but dance around the edge of what really matters - that being behaviour. My hypothesis is that the behaviour of organisations, communities and individuals is what's really behind the 'Web' effect. And it's the examination of behaviour (including and in the context of unfolding events) that helps us understand how to make better us of information technology. Moreover, when we focus on behaviour we can look at both 'top-down', directed aspects and the bottom-up emergent aspects. So isn't a Business Architecture a simple expression of behaviour of a particular network of value (Value Network)?

Here's my attempt at explaining how VPEC-T helps uncover the behaviour of an organisation.
As always, comments and builds most welcome.

Sunday, July 06, 2008

Thinking Adaptive and Adoptive over Fish & Chips

My home village has two problems: a local bye-law prevents us form having a Fish & Chip Takeaway and, like so many other country pubs, one of the villages most important watering holes,The Cricketers is struggling to keep its business going on wet-trade alone.

Around eight weeks ago, The Cricks was taken- over by new licensee's; Andy, Colin and Debbie. Since arriving, the new management have been keen to share their ideas for revamping the pub with 'The Regulars' and very attentive to their needs and suggestions. It was their adoption of one such suggestion a couple of days ago that prompted this post.

A few of the regulars were having a moan about the lack of a Fish Chip Shop in the village, when someone suggested the pub should do take-away fish and chips. The new landlords had already decided they were going to focus more on food and said they wanted to avoid going too far down the 'Gastro-pub' route (i.e. wobbly towers of fiddled-around-with food the jus of-something-pretentious dribbled all over it), so the idea of old-fashioned fish and chip suppers wrapped in newspaper seemed to be a good fit. So a word was had with Andy and sure enough, six fish and chip suppers were sold on the first night the new kitchen opened and many more since.

Then it struck me, my new landlords were demonstrating a number of the qualities described in Dave Snowden's Havard Business Review article - 'A Leader’s Framework for Decision Making' (HBR November 2007). They were showing a willingness to experiment and the were thinking 'Complex Adaptive System' (without knowing they were!). They had come up with a set of 'light-constraints' for the new vision of the Cricks; they would focus on food but they'd keep the pub atmosphere and help the locals to adopt the new version of their pub. They listened carefully to the regulars comments, even when made in jest, and acted to try to keep the locals happy and give them a sense that 'their' pub was still theirs. In other words, they were doing 'weak-signal' detection and amplifying signals that worked within their 'light-constraints'; they were allowing the agents of the system (regular customers) affect the system operation. Andy, Colin and Debbie, also recognise that a bit of experimentation makes sense – the 'safe-fail' ( as opposed to fail-safe) trial of fish and chip take-ways seems to be a winner in just a few days. Is it reasonable to suppose that a dose of similar agility, adaptiveness, and adoption could be injected into the veins of corporate and public sector behemoths?

Visit Dave Snowden's site for podcasts that describe Complex Adaptive Systems and sense-making techniques (sorry for the indirect link via Google - got a 406 Error if I tried linking directly to www.cognitive-edge.com).





P.S. A good discussion thread based on this post is taking place at:

http://www.cognitive-edge.com/blogs/dave/2008/07/interesting_uses_of_cynefin.php

(cut and paste the above if clicking doesn't work)





Wednesday, June 25, 2008

What is an Enterprise Architect?

Ask ten IT folk and you'll get ten different job descriptions. The simplest illustration of the problem is made by Charles Edwards on his AEA site: Two EA definitions:-

  1. Enterprise Architecture (Software Developers or Project Managers (segment) (view)) = The development of a coherent set of Application Architectures for an Enterprise level system or set of Application systems. In some cases this might also involve the definition of Business processes and other business domain modeling specifically for the Application. Typically carried out by a Solutions Architect (and those) who know about Databases, Messaging, Portals, Application and Web servers, etc. This would also typically be implemented in a Programme, a Project of work or even as a Business as usual process.
  2. Enterprise Architecture (CEO, CIO (enterprise or holistic view)) = the management and definition of the Architecture of the Enterprise (set of organisations) that includes everything from the Business Strategy, to the Business Operation Architecture (static and dynamic) for the purposes of optimizing the enterprise; the Information systems (made up of Applications, Services and Data) and the Technology and Infrastructure that this runs on. EA also includes aspects such as Security, Data, People and Performance. The primary purpose of creating an enterprise architecture is to ensure that business strategy and IT investments are aligned. Enterprise architecture models allow traceability from the business strategy down to the underlying technology, in order to do impact analysis and have the ability to react to changes quickly, govern the Architecture and guide the business. To contain the Knowledge and the memory of the Enterprise (Architecture) in a single point of truth.

I definitely see EA as the latter (with the exception of the last sentence that I fundamentally disagree with - I think we EAs are the guardians of multi-POVs and therefore sense-makers of the multiple 'Truths' that exist in all organisations/communities) and from, recent conversations with Charles Edwards and Sally Bean, I seem to be in good company.

Sally and I were discussing this yesterday and agreed that the former was much closer to an Engineer's view (we decided engineers probably don't make the best EAs – although there are always exceptions – I used to write PLAN code!). I mentioned that I'd just started to qualify my 'Enterprise Architect' moniker with 'Demand-side' which seemed to resonate with Sally. I often thought of EAs as sort of 'Super-Business Analysts' (I held the BA title longer than that of SE (PLAN progemmer)- which was my saving grace!) . So maybe my BA roots help explain why this is why the 'Demand-side Enterprise Architect' label works for me. Sally simply describes herself (with appropriate Dilbert-like irreverence as “Some one who talks to people and draws pictures” which I interpret as just the same as me (what I've been known to call a 'Super-Business Analyst with a satchel full of crayons').

I suppose many would argue one or other or both or another of the above EA descriptions is THE correct definition of EA. Meanwhile, the rest-of-the-world continues to be confused about what we do and why.

So rather than search for a single version of the Truth about EA, I'm hoping that adding 'Demand-side' to my job title might just avoid some of the confusion about what I do and what I don't do within the apparently highly ambiguous label of Enterprise Architect.

A footnote: Sally and I also identified another perhaps more sinister type of EA – which I'll call the 'Religious Fundamentalist Enterprise Architect'. These EAs seemed to be more bothered about their chosen methodology (EA frameworks & processes) than the business outcomes and the underlying philosophical and abstract reasons for EA that simply resolve to qualitatively better information systems and more useful and cost effective IT.

Sunday, June 22, 2008

CADS part II

I just finished writing an email to to my friend Roy Grubb in Hong Kong. I've inclued an excerpt from this email as I think it adds a bit more about where I'm coming from on CADS (Context Aware Dialogue Systems - see earlier post):

"The seed of a follow-on idea to VPEC-T is germinating here this might resonate more with KM discussions. My hypothesis is to take some of the great work of folk like Brenda Dervin and others (perhaps Martin and Dobson - cited in the comments) and combined with VPEC-T come up with a practical (easy-to-grasp) way to describe information systems behavior and therefore help promote simplicity, agility, adoption and usefulness in IT projects (of any type) and, indeed, the efficacy of non-IT information systems. All this in the context of the Web Science thinking (best summed up for me in The Machine is Us )"

I've only glanced at the and the Mike Martin and John Dobson paper referenced, but it does seem to align well. Does anyone know where their research took them and if there is any practical (non-academic) outcome I could learn about?

I mention Brenda Dervin (her work introduced to me by Dave Snowden) not because I've been a long time devotee of her work (although I suspect I will be now!), but because I've just listened to a podcast of one of her lectures and realise we seem to be stumbling into a world that has some fascinating concepts that fit hand-in-glove with where Carl and I had come to with the range 'communication' problems within IT.

Here's a link to some earlier and ongoing brainstorming around CADS.

n.

Tuesday, June 17, 2008

Context Aware Dialogue Systems

I've been having a number of really interesting discussions with a broad range of IS architects, Systems Thinkers and other luminaries in the art of understanding the true nature of Information Systems. Part of this discussion was the feedback Carl and I got from Chris Yapp on 'Lost In Translation'. In summary, he feels that we didn't cover enough on the 'I' or IS and that while he likes the VPEC-T framework, he would like us to tackle the knotty problem of making sense of the data/information/knowledge/wisdom 'stack'. In our defence, we did think about this and decided it was too hard-a-nut-to-crack when we wrote LiT - we also felt we might go into concept overload in the first book!

Well, I guess I've decided a new idea has firmed-up enough in my mind to give it an airing – the working name of this concept is Context Aware Dialogue Systems (CADS). The idea is to provide an antidote to Six Sigma Dogma and Ever-Decreasing-Ontologies (Taxonomy-wolves dressed-up as Ontology-lambs – the IT world having grabbed and a corrupted yet another word!). The basic idea is that all social (human) information systems are better described as dialogues regardless of how or if or what type of technology is used. CADS are plastic and elastic in nature – they are often highly unpredictable but not necessarily. The thing is that the CADS concept can be applied to ordered and predictable and the more organic and adaptive systems of dialogue (see the Cynefin framework).

It's a bit like something Adrian Apthorp said to me when we were debating asynchronous versus synchronous architectures several years ago. Adrian argued that an asynchronous approach was better starting point than synchronous even if aspects of the architecture would be implemented using a synchronous design because synchronous could always be implemented over asynchronous but never the other way around. So my hypothesis is that to think of all information systems and any information technology solutions as CADS at the outset would help us better understand the nature of the 'requirement' (desired outcome) and inform the solution design. Even if the solution is a configured package or service (actually I'd argue CADS analysis is even more important in such cases).

To go back to the Data-to-Wisdom stack, my hunch is the dialogue-centric nature of CADS would help focus attention on the various types of 'protocol' (and therefore use) as we work up the stack (a bit like the old OSI Model but applied to people, software and hardware). CADS would give us a consistent way to model any type of information exchange between people. One last thought for this first CADS post, CADS and VPEC-T are sibling concepts. CADS is a Dialogue Description framework and VPEC-T is an IS Thinking framework.

This concept is a way off being fully-baked. Your early reactions, thoughts and challenges, as always, welcome.

n.

Sunday, February 17, 2008

An Information Systems ‘face’ on System Thinking (x-post)

Firstly, I'm suffering from limted bandwidth for blogging, so please forgive this cross-post.

I would like to get Services Fabric reader's feedback on the relationship between IS focused techniques versus business change techniques. So can I ask you take a look here?

Nigel.