What is the scope of the kernel?

Our first blog entry on the kernel has started to generate some great discussions!

As we look through the initial comments and read some of the published support materials (for instance Philippe Kruchten:, it becomes clear that there are a number of things that are essential to all software development efforts. Unfortunately we don’t have a widely shared vocabulary to describe those essential things.  Establishing this basic vocabulary is one of the primary goals of the kernel, so please keep adding your thoughts to the discussions.   Even the creation of a widely shared vocabulary would be a valuable output from our community.

It is also clear that although the scope of the kernel is primarily software development and software engineering, it will have to touch on other related disciplines such as teamwork, project management and perhaps process improvement.  A successful kernel will also integrate with wider concepts of engineering, first from system engineering but also from other disciplines (civil, mechanical, etc.).

Software engineering is a team effort aimed at delivering value to customers (“users”), so it is no surprise to see suggestions in the blog that these elements be included in the kernel. The trick is going to be limiting ourselves to the truly essential, and keeping ourselves focused on the needs of the software development community.

There is a temptation with any effort of this kind to start to search for some universal, unifying theory of everything. The usual result of such a search is something so abstract and generic that it doesn’t really describe anything at all, and doesn’t help unify the field.  This is not the intention of the SEMAT kernel – to be effective the kernel must be kept concrete, focused and small.

Perhaps we can focus first on what the features of the kernel ought to be. Here are few of the candidate features we consider integral to any successful kernel.

A Candidate Feature List

  • Practice Independence – the goal of SEMAT is to enable people to use whatever practices they want or need to use, regardless of the source or heritage of those practices.  At this point it is not about identifying which practices are the best practices, but enabling people to share, use and evaluate practices.  To this end the kernel must be practice independent (“agnostic”).

  • Lifecycle Independence – the vast majority of methods seem to define some sort of lifecycle concept (waterfall, iterative, etc.). Therefore the kernel must be able to support all of these divergent concepts.

  • Language Independence – again the kernel needs to be unconstrained by and independent from the programming and/or modeling languages that a team chooses to use.

  • Concise – the kernel must only focus on the small set of elements that are truly essential, that would provide the framework to align, compare and combine our practices.

  • Scalable – as a framework for assembling practices the kernel must be scalable. Although it must support the very smallest of projects – one person developing one system for one customer – it must also support the largest of projects, in which there may be systems-of-systems, teams-of-teams and projects-of-projects.

  • Extensible – as the kernel is focused on those truly essential elements central to all software development, it necessarily will only cover a subset of the concepts that are needed to develop a system. The kernel needs to be extensible in a number of ways including:

    • the ability to add practices, to add detail and extend the coverage of the kernel

    • the ability to add lifecycle management, to govern how work is undertaken when applying the kernel and a set of associated practices

    • the ability to tailor the kernel itself to be more domain-specific, or to integrate the software development work into a larger endeavor.

    • Formally Specified – in order to conform to the above requirements, and form a unifying set of concepts for the practitioner, research & academic communities, the kernel must be rigorously defined.

Are there key concepts we missed?  Other features that you consider essential?

Ivar Jacobson, Bertrand Meyer, Richard Soleya

No comments yet. Be the first.