Sunday, November 02, 2008
Saturday, October 25, 2008
Sunday, October 19, 2008
Tuesday, September 16, 2008
Tuesday, July 22, 2008
Here's my attempt at explaining how VPEC-T helps uncover the behaviour of an organisation.
Sunday, July 06, 2008
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:
(cut and paste the above if clicking doesn't work)
Wednesday, June 25, 2008
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.
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
"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.
Tuesday, June 17, 2008
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.
Sunday, February 17, 2008
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?