the Essence kernel as common ground, you can use the Essence language to describe any practices, including engineering practices, in a way that allows them to be composed seamlessly together to form methods. Figure 4 illustrates a three-layer method architecture with the kernel as the foundation, generic practices in the middle, and domain-specific practices at the top.

Starting from the bottom of the stack, the three layers are:

The Essence kernel. This provides the common ground for all practices and methods and the underlying foundation for the definition and composition of the practices.

Generic practices. These are practices that are applicable across many software engineering domains. Examples of generic practices include Scrum, use cases, user stories, test-driven development, and acceptance-test-driven development. Many engineering practices will be generic, but many of the most valuable will be domain-specific.

Domain-specific practices. These practices are explicitly targeted to a specific domain such as business intelligence, data warehousing, or telecommunications. Domain-specific practices are equally as important as generic practices, if not more so. For example, many domain-specific practices are needed to develop solutions for the Internet of Things; these practices cater to things such as asset integration architecture and different technology profiles. Just as generic practices extend the kernel to provide specific guidance, domain-specific practices are often extensions/spe-cializations of the generic practices. For example, an asset integration architecture practice could be presented as an extension to a generic agile architecture practice.

The separation of generic practices from domain-specific practices helps teams find the practices that they need and helps organizations establish common ways of organizing and tracking their work. It is not uncommon for an organization to standardize on a small set of generic practices as the foundation for all of its teams’ methods.

Liberating practices in this way is
very powerful. Once practices are codi-
fied in Essence, teams can take owner-
ship of their ways of working and start
to assemble their own methods. This
can start with even a simple library of
practices, as shown in Figure 5.
This capturing and sharing of en-
gineering practices, both generic and
domain-specific, in a way that lets
them be applied alongside popular
management practices (agile or other-
wise), provides the codified knowledge
needed to support a true software en-
gineering discipline. It is also the key
to moving away from monolithic man-
agement methods and isolated engi-
neering practices.

Sharing practice: Methods and prac-
tice libraries. It’s easy to say that teams

Figure 4. The Essence method architecture.

domain-specific
practices
extensions to the generic
practices and additional
domain-specific practices
generic practices
standard practices to support
effective team working and
sound engineering principles
common ground
the basic concepts applicable
to all captured as a kernel The Essence
Kernel

Figure 5. Three teams sharing a simple practice library.

Use Case
The
Kernel
Architecture Iterative Test-Driven
User
Story

Component

Shared Practice Library

Scrum Kanban
Use
Case
The
Kernel Architecture
Component

Team A

Use Case

Team B

Kanban The
User
Story
Component
Scrum
Kernel
Test-Driven
Iterative