Aggregated enterprise architecture wisdom
If enterprise-architecture is a kind of craft – part art, part science – then how do we get it to scale? Is it even possible to get it to scale? – because if not, the whole enterprise of enterprise-architecture itself…
Some notes that came up for me almost a month back, on the SCAN framework for sensemaking and decision-making, and that I hadn’t gotten round to documenting until now. I was reminded that I hadn’t posted these notes when I saw…
A strange kind of annual ritual that they did there, that subtle ‘work-to-rule’, every year that I worked at that place. Each autumn, up would come the new crop of graduates, each with their shiny new graduation-certificate and their own…
How do we work on something when we don’t know what to do? Where do we start? How do we start? How do we keep going? I had some useful first-hand experience with this earlier this week. Some while back, I’d…
A fascinating throw-away line in an article on the BBC website today, ‘Arizona: Naming the dead from the desert‘: The forensic scientists and I have a lot of faith in science, which is a belief system. It requires trust in…
In the knowledge economy, service providers often give away selected portions of their intellectual property, in the form of webinars, white papers, blogposts, free downloads or whatever. They then hope to generate revenue from other products and servi…
What is the role of principles in enterprise-architecture? What is a principle? For that matter, when is a principle not a principle? These were questions that came up in response to a post by Simplicable: ‘101 Principles of Enterprise-Architecture‘. Or…
What is chaos? What does that word mean, in practice? And how – if at all – can we use chaos in enterprise-architecture? I’ve been having a great email back-and-forth on this with Cynthia Kurtz, co-originator of Cynefin, and – probably more relevant here – originator of the Confluence…
What frameworks do we need, to link across all domains and layers of the enterprise-architecture space? How can we create such frameworks? This is the fifth and final item in this series of worked-examples of metaframeworks in practice – on how to…
What generic base-frameworks or base-metaframeworks do we need, to support sensemaking and decision-making across the full scope of enterprise-architectures? How do we create those frameworks in real-world practice? This is the fourth of five worked-examples of metaframeworks in practice – on how…
What frameworks do we need to make sense of relationships, interdependencies and dynamics across the the whole of an enterprise? This is the third of five worked-examples of metaframeworks in practice – on how to hack and ‘smoosh-together’ existing frameworks to create…
Here’s an analogy for the so-called hierarchy of Data, Information, Knowledge and Wisdom DIKW).
Note that Information isn’t made solely from Data, Knowledge isn’t made solely from Information, and Wisdom isn’t made solely from Knowledge. See also my post on the Wisdom of the Tomato.
That’s enough analogies. Let me now explain what I think is wrong with this so-called hierarchy.
Firstly, the term “hierarchy” seems to imply that there are three similar relationships.
as well as implying some logical or chronological sequence
and quantitative relationships
But my objection to DIKW is not just that it isn’t a valid hierarchy or pyramid, but it isn’t even a valid schema. It encourages people to regard Data-Information-Knowledge-Wisdom as a fairly rigid classification scheme, and to enter into debates as to whether something counts as “information” or “knowledge”. For example, people often argue that something only counts as “knowledge” if it is in someone’s head. I regard these debates as unhelpful and unproductive.
A number of writers attack the hierarchical DIKW schema, and propose alternative ways of configuring the four elements. For example, Dave Snowden says that “knowledge is the means by which we create information out of data”. Meanwhile Tom Graves suggests we regard DIKW not as ‘layers’, but as distinct dimensions in a concept-space.
But I don’t see how any of these DIKW remixes escapes the most fundamental difficulty of DIKW, which is a naive epistemology that has been discredited since the Enlightenment. You don’t simply build knowledge out of data. Knowledge develops through Judgement (Kant), Circular Epistemology and Dialectic (Hegel), Assimilation and Accommodation (Piaget), Conjecture and Refutation (Popper), Proof and Refutation (Lakatos), Languaging and Orientation (Maturana), and/or Mind (Bateson).
What all of these thinkers share is the rejection of the Aristotelian idea of “one-way traffic” from data to knowledge, and an insistance that data must be framed by knowledge. Thus we may validate knowledge by appealing to empirical evidence (data), but we only pick up data in the first place in accordance with our preconceptions and observation practices (knowledge). Among other things, this explains why organizations struggle to accommodate (and respond effectively to) weak signals, and why they persistently fail to “connect the dots”.
And if architects and engineers persist in trying to build information systems and knowledge management systems according to the DIKW schema, they will continue to fall short of supporting organizational intelligence properly.
References
Updated 8 December 2012