Composing practices into methods.
In the past, different methods have primarily been described as isolated, conceptual islands. Every method is basically a unique phenomenon, described
in its own language and vocabulary and
not standing on any widely accepted
common ground. Any method, however, may be considered to be composed
from a number of practices.
For example, the agile method
of extreme programming (XP) is
described as having 12 practices,
including pair programming, test-driven development, and continuous integration. Scrum, on the other
hand, introduces practices such as
maintaining a backlog, daily scrums,
and sprints. Scrum is not really a complete method, though; it is a composite practice built from a number of
other practices designed to work together. Scrum can itself be composed
with other practices from, say, XP,
to form the method used by an agile
team. This composition is typically
done tacitly, as Scrum and XP are not
provided in a format that allows them
to be explicitly composed.
As discussed previously, Essence
provides a framework and language for
describing and composing practices.
This framework provides a practice architecture where, as shown in Figure
2, both generic and domain-specific
practices are described and assembled
on top of the Essence kernel.
Now individual practices can be described using Essence. A practice can
be expressed by extending the kernel
with practice-specific elements, by
describing the activities used to progress the work and the work products
produced, and by describing the specific competencies needed to carry out
Liberating practices in this way is
very powerful. Once practices are codified in Essence, teams can take ownership of their way of working and start to
assemble their own methods. This can
start with even a simple library of practices, as shown in Figure 3.
This capturing and sharing of practices, both generic and domain-specific, in a way that lets them be applied
alongside popular management practices (agile or otherwise), provides the
raw materials that teams need to compose their own ways of working.
number of proven practices while continuing to innovate and rise to the new
challenges that they face every day?
These are issues that particularly affect
companies moving into the Io T, as they
will need a variety of methods.
What is needed is some concrete
common ground that the practices
can share, providing both a shared vocabulary for practice definition and a
framework for the assembly and analysis of methods.
This will allow organizations to
prepare a library of practices suitable
for their industry/domain—practices
that teams can easily share, adapt,
and plug and play to create the innovative ways of working that they need
to excel and improve.
This common ground has already
been prepared in the form of the Es-
sence kernel, part of the new OMG
Essence provides the following:
˲ A kernel of elements that establishes a common ground for carrying
out software engineering endeavors
and assembling methods
˲ A simple, easy-to-understand, vi-
sual, intuitive language for describ-
ing practices that can be used both to
represent the kernel and to describe
practices and methods in terms of
By combining these capabilities, Es-
sence provides a common framework
for describing all practices and then
composing them into many methods.
The power of Essence in addressing the method complexity inherent in
developing software for the Io T comes
from its ability to enable the composition of practices into methods; help
clearly define life cycles and checkpoints, enabling practice-independent
governance; and support the creation
of practice libraries from which practices can be selected to be composed
Let’s now look at each of these in
Figure 2. The essence practice architecture.
Essence Kernel: Method Agnostic
Figure 3. Three teams sharing a simple practice library.
Kernel Architecture Iterative Test Driven
Shared Practice Library
Case Kernel Architecture