the design and sustainability of the
systems produced. This is not to say
the former isn’t important. Indeed, it
is crucial to the success of any development organization. As the integration of software into the fabric of our
daily lives grows, however, the need
for proven, reusable engineering
practices grows as well.
Practices are needed that help
teams engineer their software: practices for working with requirements,
such as use cases, features, and stories; for developing components and
services; for applying an appropriate
pattern or framework; for testing complex, distributed systems; that encourage reuse; and that help engineers
code with confidence. In particular,
practices are needed for dealing with
architectural concerns such as concurrency, security, user experience,
microservices, and data protection, as
well as for addressing broader architectural concerns such as enterprise
architecture, product-line architecture, service-oriented architecture,
and the architecture of systems. Many
of these practices already exist codified in the Essence language (see the
section “Sharing practice: Methods
and practice libraries”).
These engineering practices need
to be streamlined (lean), agile, and,
most importantly, composable into
complete methods to provide guidelines for teams working with a multitude of practices for complex systems.
They are needed to help deal with the
complexities of modern software engineering. They need to be available
to all engineers whether they are working alone, in small teams, or in larger
teams of teams, regardless of the style
of team working or work-management
practices adopted.
Globally, we want a robust and flexible library of codified professional
engineering practices that reflect the
multidimensional nature of software
development and that can be used to
support the many different types of
software being developed today and in
the future.
These practices can only come from
engineering teams working on the cutting edge of technology, and these teams
need a better way to capture, communicate, and share their practices.
A new method architecture. With
ed by such a theory is the capability to
be predictive.
A construction engineer can use
material science and the theory of
structures to understand at an early
stage whether a proposed building is
likely to stand or fall. Similarly, using
Essence, one can understand whether
a proposed method is well constructed, whether or not there are any gaps
or overlaps in its practices, and if
there are gaps or overlaps, how to resolve them.
The kernel has many mechanisms
for method analysis, the simplest of
which is provided by its high-level activity map. This is a set of 12 activity spaces
organized into three areas of concern.
An activity space is a generic placehold-er for method-specific activities. These
activity spaces, as shown in Figure 3,
can be used to assess the spread of the
team’s activities. In this example, the
team has added notes to the map to indicate their activities and red circular
markers to highlight the danger areas.
Note: Without understanding the
meaning of the Essence language, the
symbol of a pointed arrow to repre-
sent an activity space can make them
appear sequential, which is not the in-
tended meaning. The activity spaces
and the activities that they contain
can of course be applied iteratively,
concurrently, or in any order the prac-
tices require.
These are just a few simple exam-
ples of the kernel’s capabilities, but
they illustrate the many ways it can
help teams and organizations assess
the effectiveness of their methods.
Codifying and capturing engineer-
ing practices. In addition to the kernel,
Essence provides a language for creat-
ing practices on top of the kernel and
then composing methods from those
practices. This is extremely important
for moving from craft to engineering.
As discussed previously, most
current practices are embedded in
monolithic methods that aggres-
sively compete with one another.
Rather than admit that they share
practices and encourage reuse and
cross-pollination, they willfully slan-
der and steal from one another. Even
worse, from an engineering perspec-
tive, they are all concerned with the
design and sustainability of the de-
velopment organization rather than
The terms used in the method space are often ill-defined or confused. For example,
what is the difference between a method and a methodology? A practice and a process?
Composition: The process of merging practices into practices and methods. It is
important to understand that practices are separate concerns composed through a
merge operation and not components interacting through messages.
Essence kernel: An actionable reference model of software engineering that provides a
framework for the definition of practices and the assembly of methods.
Essentialization: The process of rendering a method or practice down to its essence and
capturing it using the Essence language.
Method: The documentation of a team’s way of working. A method may or may not be
documented using Essence. If it is documented in Essence, then it is the composition
of the Essence kernel and a set of practices to fulfill a specific purpose. A method could
belong to a single team or be shared among teams.
Methodology: A collection of practices known to share a common set of values and work
well together. It’s a form of practice library.
Practice: A repeatable approach to doing something with a specific objective in mind.
Practice library: A collection of potentially competing practices. For example, a
requirements management practice library could contain many different competing
practices such as declarative requirements, use cases, and user stories.
Starter pack: A partially built, often incomplete method that a team can use as a
framework to seed their own method.
Way of working: This is what a team actually does. It may or may not match their method.
Some Definitions