I recently participated in a really fun roundtable discussion with Tom Hollingsworth, Calvin Hendryx-Parker, and Andrew Wertkin, Chief Strategy Officer at sponsoring company, BlueCat. We covered a lot of ground, so I highly recommend that you watch the whole video below.
One thing that really stood out to me was the underlying idea that we must document and embed tacit knowledge in our automation. I’m now calling that idea Institutional Knowledge as Code (IKaC). If anyone out there already coined that term, I’d love you to leave a comment and let me know! Regardless of who first said the words, I’ll be spending the rest of this post digging into what it means, what it’s good for, and a bit of how BlueCat is paving the way as well.
Institutional Knowledge
In order to talk about IKaC, the first thing we need to do is define “institutional knowledge.” There are a few different definitions out there, but they all revolve around key organizational/operational information that isn’t formally documented. In many cases, this is also “tacit knowledge;” meaning information gained through experience and context – like learning to cook by watching grandma in the kitchen with no cookbooks or measuring cups.
In terms of IT, these are the unwritten rules, shortcuts, and gotchas that we all pick up on the job. It’s the list of steps you take to add a new VLAN that no one has ever written down. It’s where to find that spreadsheet you’re using for IPAM – and which entries in it are wrong but were never fixed. Or, which aspects of the “as-built” documentation are left-over from the planning phase and never actually represented reality. Sometimes institutional knowledge is just knowing who to ask to find the information you need, rather than the information itself.
Institutional Knowledge versus Automation
It turns out that this tacit, institutional knowledge is actually instrumental to successful IT automation. Of course, that makes sense, since this same “tribal” knowledge is key to manual IT operations already. What may be less obvious is that the same institutional knowledge that enables manual operations can be a blocker to automation.
Hold up, how can that be? Well, there are two primary stages or types of automation, and their requirements are very different. When you write a script for yourself, to automate some manual task away, your institutional knowledge is an advantage. Let’s say you get a lot of “add VLAN” tickets and you’re tired of going switch by switch for each one, every time. You know (or know how to find out) what VLANs and IPs are in use, which switch ports are trunks, etc. You can provide all of these parameters to pass to your script or API. But what happens when you want to take yourself out of the loop completely? Or when you want to go beyond automating your response to the ticket and instead automate that ticket away completely?
Adaptive Automation
That question brings us to the next stage of automation: automating for others. And this is where that institutional knowledge can become a blocker. The big difference here is that the person (or application) calling your script/API doesn’t have the same level of tacit knowledge about the environment that you do. They don’t have the data for all those parameters, and they don’t know where to find them. Frankly, they shouldn’t have to.
So, how do we overcome the hurdles of institutional knowledge to create automation that empowers the business and frees you up to innovate, architect, and build more agile and dynamic infrastructure? We embed the institutional knowledge into the system. We make tacit knowledge explicit. In short, we create Institutional Knowledge as Code.
The first step is a solid, single source of truth for your DNS, DHCP, and IPAM (DDI). No more searching for spreadsheets or asking “Bob.” And if you paid attention to the examples that Andrew Wertkin laid out during our roundtable discussion, you can probably guess that BlueCat is taking that a step further. They’ve built “DDI for a complex, hybrid cloud world” with automation, APIs, and application enablement in mind. They call it Adaptive DNS and it can both increase resilience and agility. In fact, they have an entire adaptive catalog with applications, plugins, and community offerings to get you started.
The Bottom Line
At this point, roughly halfway through 2021, every IT practitioner should be embracing automation. We know that it allows us and our teams to meet the ever-increasing demands of the modern, cloud-native, digitally transformed enterprise. What’s less common is knowing how to take the next step: automating for others.
We all need to enable and empower developers and their applications to operate dynamically, providing needed IT resources on-demand. To do this, we must make tacit knowledge explicit by documenting institutional knowledge as code and then use that IKaC to abstract proprietary and protocol complexities away from the users of our automation. BlueCat’s Adaptive DNS is a great example and an excellent starting place.
