Dynamic Domain Knowledge referencing

Question

Hello! I am trying to brainstorm the best way to utilize Confluence in setting up some sort of Domain Knowledge hub for our IT department that is more than just documentation. Our application is somewhat complex and we have many individuals who are experts in specific areas of the application, but we need a way for this knowledge to be accessed and communicated department wide and easily searched for specific questions. There are many nuances to the workflows and functions of our application that are very difficult to fully document in comprehensive way, and that coupled with the fact that these functions and workflows are constantly being revised and enhanced leads me to seek out a dynamic forum-style information space that is searchable, editable by the qualified users, and conducive to getting immediate answers to new questions. Any suggestions would be much appreciated!

James Bullock · Answer

Kudos to you for noticing your impediment by folklore. Many people never do.

Here are three hacks that each helped and work well together, when putting a wiki-hosted K-base (not Confluence, because reasons) under engineering (SW, mainly) for a sophisticated internetworking product, with characteristics like you describe:

Pull -- use "pull" from events to draw creation of your content.

We hooked baselining authoritative truth in ThatOtherWiki to tier-3 support, and engineering change workflow; both repairs and new features. Simply "If it gets to tier-3, you answer from the authoritative baseline: if there isn't one, make one." Also "Every candidate change to the release-candidate branch goes through this here review. Maybe record the review package in the KMS." ("Review package" was links to stuff *they were claiming they were already doing as good engineering practice*, so minimum additional work. Let management -- me -- provide high cover for actually doing things right, under time pressure. Other benefits based on how this was done, like building the K-base as work progressed.)

Domain Dictionary -- if you do a domain model for your engineering / product subject, you'll find a few fundamental entities. (Domain Driven Design, the book. Get it. Read it. Be it.) Every time you refer to one, fill in the dictionary entry.

We aimed for the nouns that kept coming up vs. workflows or official entities. If there's a thing you keep having to talk about, give it a name, make a page with that name, and record what you keep having to remember. This is very emergent and bottom up. Myself, I'd use thinking hard before you start to come up with a couple (like no more than 3) entities, with minimum structure. Trying to make a fully consistent domain entity model off the bat is very, very hard, and a semi-structured repository tool (Confluence) doesn't help.

Not Stuff You Do or Events -- start with description of the state of things, like your product workflows, components, whatever. Capture state that models part of your world vs. automating state change.

Those factoids and entities you keep having to refer to to do your stuff: capture those as you do things. We ended up with sort of "header" pages for events or instances that went through our processes, tied out to workflow in other systems.

You can see how the three of these reinforce, nearly being different ways to say the same thing. Doing it this way bypasses a lot of the social impedance as well.

A mentor of mine would give me all kinds of grief for offering free help, especially that's this specific. Let's see: That's a problem you have. I think I can help with these notions. How about a like or up-vote if this was useful? (I'm a bargain.)

James Dellow · Answer

Some general tips, if you want to use Confluence for something more than technical documentation or free form collaboration:

* Think carefully about your Confluence information architecture before you start, although think of it as an iterative process (see next point)
* Building on your initial information architecture, co-create with your users
* Don't go crazy with add-ons - start with out of the box, prototype to prove people will use what you have setup, then identify gaps or add-ons that could make the requirements better/easier/sustainable
* Remember, its not just about technology, but culture and technology adoption
* Get some help

There are a few ideas in this old presentation of mine from Summit 2012 that you might find useful:

https://www.atlassian.com/company/events/summit-us/watch-sessions/2012/archives/collaboration/kick-ass-collaboration