Automation Is Captured Knowledge – Part 1
Sometimes phrases or sentences simply resonate with you – they capture your attention when you hear them and you find yourself thinking about them long after you first heard them. Maybe it is because they were so outrageous that you can’t quite believe that someone just said that, or maybe it is because they got you to think about something in a way that you never did before.
The latter reason is why I remembered a phrase that I heard a speaker use at a Data Center Conference that I was presenting at several years ago. In fact, that phrase is the ONLY thing I remember about that conference! The speaker in question (I don’t even remember his name or the subject he was presenting on) used the phrase “Software is Captured Knowledge”. I had never heard that phrase used before and I haven’t subsequently been able to determine whether it has a well-known origin or not. In any case, “thank you” to whoever first came up with it.
We tend to forget that people create software based on knowledge that they have acquired – whether it be one person creating a piece of software or hundreds or even thousands of developers working as a team to create a huge application. Software is ALWAYS based on human knowledge that has been translated into computer code. Even Artificial Intelligence is based on rules provided by humans, based on their knowledge and experience.
That phrase describes the essence of software so perfectly and succinctly that even now, many years later, I can’t help but shake my head in admiration when I think about those words. Strangely enough, I think about them often and I think about them a lot. Even just the last two words – “Captured Knowledge” – are cause for reflection. If knowledge is not captured in some way, for example by documenting it or passing it on verbally to someone else, it has the potential to be lost.
In many instances, knowledge is acquired through a painful learning process. If the knowledge isn’t captured, the painful learning process will need to be endured a second time to reacquire that knowledge. I’m still trying to explain this to younger colleagues – “I’ve already learned lesson X, just pay attention to me and you won’t have to go through the unpleasant learning process I did”. So far, not too much luck in that regard!
In the work environment, there is a huge amount of valuable knowledge stored in employees’ heads. In IT specifically, this knowledge is typically a mixture of Technical knowledge and Business knowledge. Many people tend to discount the value of Technical knowledge because they feel that Technical knowledge can be more easily acquired than Business knowledge. While this is often true, the fact of the matter is that IT is the point in an organization where Technical knowledge and Business knowledge interface. The more efficient and effective this interface is, the more efficient and effective the organization is. BOTH types of knowledge are critical, and knowing how they need to interact with each other to most effectively meet the organizational objectives is of paramount importance.
Automation tools provide an extremely effective way to capture this knowledge – how to recognize a specific situation, business or technical, and what to do once that situation is recognized. Creating and maintaining automation rules is the software creation process of the data center. Just as business knowledge gets captured when software applications are created, IT operational knowledge needs to be captured and preserved in automation tools. If this is not done, painful learning processes will be repeated and the organization will suffer the consequences.
Knowledge within an IT organization can be broken down into two broad categories – 1) Formal Knowledge, which is documented in some way and is stored in some kind of identifiable repository, and 2) Informal Knowledge, which is either held in someone’s head or in their personal (non-corporate) repository. I will discuss these two types of knowledge and how best to ensure that their full value becomes available to the organization in parts 2 and 3 of this article.