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