DIKW pattern - why should we adopt it?

[#1]

Oh, that's a great topic #Authors group brought to table in August - Knowledge Base. Great, but pretty complex. You could write a whole book on it and definitely it would be not enough. There are topics to cover like:

• Knowledge adoption pattern (DIKW)
• content creation
• content maintenance and gardening
• content indexing and categorization
• system integration (KB to/from)
• KB utilization (use patterns and usability)

And others. Definitely it is too much to cover in one article. And frankly, there is no topic more important than others, due to all of them together sum up to successful delivery and use of Knowledge Base. So, what should we talk about? I was thinking on it for 3 days, keeping this article in draft status (seriously). Taking different perspectives, presuming what other authors might write about, trying to get out of my experience the most interesting points. Then I found out, that I have already wrote topics here on content creation (https://community.atlassian.com/t5/Confluence-Cloud-articles/The-shortest-kickstarter-course-for-Confluence-content-creators/ba-p/1232001). And then I decided to tell You something more on DIKW pattern. Well, it is far beyond Confluence. It might start in Jira, Bitbucket, or even external systems. But still - I assume this is underestimated part of Knowledge Management and KB content.

What is DIKW?

Shortest definition - it is a pattern (flow) allowing to transform raw DATA into INFORMATION, subsequently in KNOWLEDGE giving us WISDOM. SO that is a long story short, but obviously devil is in the details. In real IT Service Management world it means gathering raw pieces of data from variety of systems, applying them informational context (what these data mean to us), understanding not only their context but also purpose or consequence.

What is important to understand is fact that data and information might come from variety of areas not necessarily even close to IT systems. Knowledge based on those might be very specific, applicable to very narrow, rare cases, but surprisingly there will be a number of cases where you will be as much surprised You did not catch some patterns earlier, and did not utilize it either in Knowledge Base, or in... delivery of fix/improvement solution. Before we jump to examples of such, I would like to give you one more point on DIKW itself. When you look at it:

• Data is 100% objective - as far as we catch all necessary data
• Information - mostly as above, as this is just adapting different perspectives and building context to raw data, the difference may be if we wrongly combine data sets into one piece, making information irrelevant
• Knowledge - due to we interpret information here - and put human factor on the top of Data/Information - like justifications, analyses, etc. - Knowledge is rather subjective factor
• Wisdom - 100% subjective, as it is based on Knowledge - therefore wisdom might be, pardon my French, totally goofy.

So if you take this perspective - some of us might wanna to work rather on Data/Information level only. But in fact - these levels are unnatural for human perception. We need information to be put against analyses, interpretation, etc. The better they are the better for audience (look at Antivaccination Movement, or Flatearthers, where regardless of available raw data and its informational context, analysis done is.. wrong), still - we are dependent on Knowledge/Wisdom levels.

How DIKW work in practice?

Let me introduce you to simplest DIKW scenario I used to work with. Pick up 2 data sets from your organization:

1. Failed logins to IT systems (authorized users)

2. Vacation/Holiday absence sheets of your employees

Well, found something interesting? Like "50-65% of your employees forget passwords after getting back from holiday or other long term leave"? Funny, isn't it? There is Your Knowledge piece. We went through DIK pattern in 2 lines of text. Well, OK, you needed to run some cross-reference between two data sheets. Still - it had been quickie, wasn't it?

OK, but what to do next? We got Knowledge - how to utilize it? This kind of Knowledge is a poor candidate for KB, as users won't log into KB before they reset passwords. So, maybe pushed actions would help:

• notification to reset password
• forced password reset and notification
• promoting specific articles and request types

And so on.

OK, that one was a simple, clean case. Mostly they are not just as simple.

Where do you take them from? Where do you take them to?

There is an activity placed in ITSM somewhere between Problem Management, Knowledge Management, and Service Measurement and Reporting (maybe because of being "between" it is not clearly assigned to any role), named Proactive Trend Analysis. What would You do?

• measure events - markup their weight (error, warning, information) of relevant systems/users activities - from monitoring, logs etc. (DATA)
• calculate volumetry, parameters, repetitions, reoccurrence etc. (DATA)
• get these data together against timeline, and other factors (INFORMATION)
• analyze, apply context, diagnose, provide feedback and potential remedial actions  (KNOWLEDGE)

Remedial actions might be various - starting from simple statements to disregard any operation, and trend is harmless to IT Services (yup, it is as well as any fix, a Knowledge piece), through variety of documentation (KB articles for Users/Support Teams - how to react against specific events or trends, improvement plans, requests for change tec.), up to specifying demand for more complex, sophisticated solutions like HW/SW replacement program (e.g. specific model of laptops contain potentially explosive batteries) or other project (due to closing date for support of ClearVision, company is switching to Jira and Bitbucket).

Effort/Effect Balance

Of course such approach is highly effort-consuming. Therefore best practice should limit this to specific cases:

• business critical services and systems
• already affected systems (there were high impact failures reported)
• common, simple, high volumetric activities, that could save resources (time, money workpower etc.) if improved/fixed

Then apart from where we apply these, it is important to understand how to document them into KB.

The whole cycle - from Data collection up to Information integration can be performed without including these into KB. However there might be some exceptions - e.g. if we have documented as KB existing issue, that has workaround, and just started further analysis, including DIKW pattern, or data and information sets are necessary to contextually understand root cause or fix.

What is important to document - is exactly these:

• cause
• context (why, when, who, how, what)
• workaround
• remedial actions
• optionally - alternatives (either alternative services to use or fixes)

Why DIKW approach is important?

Well, regardless of being effort consuming, DIKW approach might be highly effective in finding root causes for existing issues or to PREVENT issues from happening. As process is data-driven - it can be partly automated (data collection, building Information context) using native systems features (logs, monitoring) or analytical software like Splunk. That would allow to analyze massive data initially, and find trends, that are not obviously seen with bare eyes. 

Another point is the ability to react in proactive manner. If You can avoid problems to happen, it has a great value of saving time in operations, that can be utilized for other purpose.

Last, but not least - DIKW pattern is the future of any Knowledge Management solutions. Massive data, analyzed on the fly with AI algorithms, creating possible scenarios and advising decisions to be made. This is how will it work in several years. Therefore it is important to adapt the approach as soon as possible.