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.
Posts
5 comments:
I'm interested in the ideas here - we are currently working with the AGILE community to use Cynefin in respect of system design and this seems linked.
hello dave,
I agree, I've watched/listened to your podcasts and our thinking is very much aligned. Let's hope we can arrange a face-to-face soon.
Hi. There was some interesting theoretical work on this kind of thing at the University of Newcastle ten years ago. You might want to take a look at some working papers on distributed systems architecture and the philosophy of language by Mike Martin and John Dobson.
Enterprise Modelling and Architectural Discourse
There are some familiar names in this discussion ... John Dobson was once part of the ANSA project which provided the foundations for the RM-ODP work (ISO 10745), IMO the most suitable architecture for dealing with distributed systems. Newcastle did some valuable work in this area, including also that done by Santosh Shrivastava on Arjuna, a distributed transaction infrastructure.
Nigel,
This discussion reminds of the the following paper The Atoms, Molecules and Fibers of Organizations. A rather apt title given the name of this blog!
The paper explores the role of communication as fundamental to the theory of human organisations and goes on to develop a framework called DEMO. Although, the foundations of the framework look promising, I observed that it is missing the contextual elements of trust, contract and reward! Does this sound familiar?
Returning to your comments on our much earlier conversation, I've observed that depending on background, IT people look at system interactions as either a protocol or function calls. The former tends to be comms people whereas I'm guessing the latter is due to the procedural nature of most programming languages. In support of your basic proposition I think the protocol view yields a richer understanding of what is going on between elements/components of a system, whereas the function call is rather one sided (caller or callee) and maybe reinforces synchronous thinking? As Hugh alludes I think there is much mileage in exploring the principles on which effective distributed systems are founded in this discussion. This includes starting with the assumption of asynchronous rather than synchronous communication.
Post a Comment