Building Blocks of Knowledge Management in Service Oriented IT

I see a lot of organisations that I work with grappling with a challenge - how to capture the right kind of knowledge within retained IT organisation?

Here are a few thoughts

Let's start with basics - trying to capture knowledge without structure is usually a recipe for failure; or at the least a cumbersome, difficult to use knowledge base.

Most organisations look at knowledge base as just a series of articles which fall into two categories - Self help and Operations 'run books'. That, however, is a flawed approach and leads to missing key pieces of information. This becomes painfully apparent typically when suppliers change and transitions struggle - adding timelines, efforts and unwanted costs.

One of the first steps an IT organisation must take towards maturity is to identify the services it consumes and provides. This paves the way for structured knowledge creation, which can help the entire organisation retain it's knowledge.

Capturing this service information needs a blend of documents. In order to describe a service and its operational aspects fully, one must document following -

• Description of the Service
• Its underpinning components - applications, infrastructure components or another set of services
• The architecture of the service - Typically captured in the High/ Low Level Design documents.
• People construct - organisational structure
• Processes/ procedures - such as ITIL Framework process set, operational run-books etc.
• Tools knowledge - detailing the individual system component build/ configuration information.

Although broken down into various components it may seem a mammoth task, there are two distinct areas for which knowledge is to be captured. Focus on specific areas by the relevant groups can result in dramatic speeding up of the information capture.

Architectural function must focus on Service Layer in order to capture information specific to the Service Catalogue itself. This layer itself is further split into three strata. Remember - its a modular approach, an underpinning service should get it's own document set and is simply referred to by other service document sets. Creating a hierarchical Service Map and then creating Service Design Package for each service thus mapped out ensures all the relevant details are captured. The details in the Service Design Package then should refer to underlying application information captured in High / Low Level Design documents (HLD/LLD)

Service Delivery organisation should focus on capturing the Operational layer information, encompassing people, process, procedures and tools. Some tools information will be captured by the architectural function, but suppliers must maintain their own tool build information.

Some constructs (such as 'as a service') may mean some of these details may not be applicable to some services, since they are 'black-box'. That's okay - as long as information necessary for the organisation - such as interactions and interfaces to such services are captured.

Remember - the key is modular approach. Temptation to document details which may already be described elsewhere should be avoided at all times as doing so creates multiple versions of the truth, poses challenges in version control and introduces the risk of creating outdated pockets of information.

Knowledge is power as they say. With increasing suppliers, black box solutions, 'X as a service' constructs; retaining that power is an ever more relevant and difficult challenge, but with right focus, not an insurmountable one.