Knowledge Driven Development (KDD) supplements DevOps with its contextual knowledge management proposition. Creation of an output typically consists of two sets of activities as depicted in the figure below.

Gaining an understanding of the contextual knowledge about the output being built is important. Based on that, a set of execution activities result into creation of the output. Some of the examples are:
• Detailed building drawings and blueprints are contextual knowledge and constructing a building based on it is an output.
• Recipe is contextual knowledge and the food prepared based on it is an output.
Software development also follows the same pattern. Contextual knowledge along-with execution (development, testing and deployment) activities result into a working software. Let’s understand it in more detail.

Contextual knowledge:

The two well-known software development methodologies – Waterfall and Agile – deal with contextual knowledge. Waterfall methodology has a scientific approach to capturing contextual knowledge via specification documents in each of the knowledge intensive phases – requirement analysis, solution design, application design and test design. However, as the knowledge is in the document format, it is difficult to be kept updated with the dynamic project delivery environment. Agile has speeded the project delivery and uses ‘User Stories’ and ‘Acceptance Criteria’ primarily as contextual knowledge which is significantly less in coverage when compared to Waterfall, increasing reliance on subject matter experts and therefore being more vulnerable to any possible attrition in the project.

I have evolved a new project delivery methodology named ‘Knowledge Driven Development’ (KDD). KDD scopes the contextual knowledge in (typical) 18 building blocks across all the four knowledge intensive phases of software development. Each phase represents complete knowledge from their perspective and hence there is a relationship between them as seen in the figure below.

Contextual knowledge in these building blocks is specified in the inventory and relationship format. This representation computes lack of relationship (i.e. A specific requirement is not linked to any test case), a potential defect assisting quality of the knowledge. Manual review further strengthens the quality of knowledge. The figure below illustrates this.

An example of the contextual knowledge output for a project is depicted in the figure below.

KDD essentially replaces the document format of knowledge with the inventory and relationship format that I have termed as digitisation of knowledge. It is not difficult to visualise now, that the resulting extreme quantification of the contextual knowledge in KDD is better than the alternatives provided by Waterfall and Agile. Whereas there are many models for contextual knowledge capture such as ‘Use Case’ that can manage multiple building blocks (Application, Process, Process Step, Business Rule, Business Data, Scenario), KDD has extended it significantly by managing 18 building blocks.

Execution activities:

Build, testing and deployment are the execution activities in software development. Advancement in technology has led to optimisation and automation of these activities. This closely relates to DevOps that optimises delivery and maintenance of the software. Whereas DevOps is very good at the execution activities via the use of various tools, it has no differentiating proposition for contextual knowledge. DevOps, when supplemented by KDD for contextual knowledge management can cover end to end project delivery.

KDD gels well with the DevOps culture by establishing a close relationship between the three teams of DevOps namely Development, Quality Assurance and Service Management. The figure below illustrates how KDD fits into the DevOps culture.

Details of KDD can be found in my book, Knowledge Driven Development – Bridging Waterfall and Agile Methodology.