Automation is Captured Knowledge – Part 3
In my final post on this subject I will talk about what is probably the least discussed organizational IT asset – Informal Knowledge.
Informal Knowledge is the knowledge that is held by members of an organization (and sometimes by partners or customers of the organization) that could be of benefit to that organization. This knowledge could be written down in personal notebooks or hidden in emails. It might be an electronic document stored on a personal or organization-owned device or, most likely, it could simply be held in someone’s memory. No matter where it may be stored, it is an asset that has a high potential to be lost unless it is turned into Formal Knowledge and, hopefully, entered into an automation tool along with the organization-owned Formal Knowledge.
Many organizations have systems and applications that have been in production for 20 years or more. These are typically back-end applications that have had their end-user interfaces upgraded and modernized several times over as delivery mechanisms have changed. Applications written in COBOL (Assembler maybe?) and the systems on which they are running (mainframes, mid-range systems, etc.) are still with us, are still critical to the organization and will probably still be with us for many years to come.
However, the KNOWLEDGE about those systems and applications might NOT be with us for several years to come – the people that have the deepest understanding of those applications and systems are rapidly aging out of the workforce. That generation of IT workers – the ones in their 50s and 60s – spent their formative IT years at a time when the focus was on just getting things done. No matter how long it took, how many hours of overtime were required – things got done. Along with this attitude towards work, there was the implicit understanding that they were always on-call and were always available. Few worried about documenting what each did to fix a problem. If the problem happened again, they would just be called to fix it again. That was frequently the normal way things got done. As a result, a huge amount of Informal Knowledge is held by individuals who, in the near future, may no longer be available to the organization.
This knowledge is very often along the lines of ‘if X happens, then we need to do A, B and C to fix the problem’. This is exactly the type of knowledge that can be very effectively stored and preserved in an automation tool. Also, just as was the case with Formal Knowledge, the very act of defining the trigger event and the subsequent automated actions ensures that the captured knowledge is complete.
The trigger event could be calendar-based (“last workday of every month except December”, “every Wednesday at 3pm”) or it could be based on the existence of a file in a specific location. It could be based on an operator action or on the status of an application such as a transaction rate above a specified limit. Defining these events or combinations of events and defining the workflows that should execute when those events or combinations of events occur in an automation tool requires a degree of accuracy and completeness that cannot be enforced using traditional documentation methods. A strong automation solution won’t validate incomplete definitions or illogical flows – both of which might easily slip into textual documentation.
Automation systems capture the knowledge of the people that best know how to run an IT organization. The time to capture that knowledge is now – before it disappears into retirement on a sandy beach somewhere!