Subject matter experts own the expertise at the core of software. But too often this rich expertise is not captured in a structured way and gets lost when translating it for software developers.  With the rate of change increasing and product variability blooming, putting knowledge into software in this way is increasingly untenable. It causes delays, quality problems and frustration for everybody involved.

We advocate for putting SMEs directly in control of “their” part of the software and letting developers focus on software engineering.

Here is how we achieve it:

Empower subject matter experts to capture, understand, reason about expertise in a precise and unambiguous form

By providing them with tailored software tools that allow them to directly edit, validate, simulate, and test that knowledge without involving software engineers

Rather than expecting SMEs to juggle complex subject matter in their minds, with the limited support of poor tools like Word documents

Remove friction in the pipeline from the SMEs brains to the software product

By automating the derivation of correct software code from the captured and validated domain knowledge

Rather than forcing SMEs to wait for developers to understand everything in detail and then implement, test and deploy the code.

Focus the developers on their core skill of software engineering

By letting them build the tailored SME tools, robust execution platforms and the automation between the two

Rather than involving them in every detail of business logic development.

The Subject Matter First approach proposes a shift in mindset that tears down the obstacles between the SME’s brain and the production environment. In our experience this fosters creativity, innovation and increased value created for the business. It also separates subject matter from software technology, which allows the independent evolution of both.

Sign this manifesto to express your support

This Manifesto has been proposed by Markus Völter, Federico Tomassetti, and Sergej Koščejev. It was created based on discussions with experts who share this message. They are

Signature Form
We will contact you only if this Manifesto is ever updated.

Frequently Asked Questions

Is this in conflict with Agile? No. Tools and automation make changes faster and more reliable. Decoupling of lifecycles enables independent agility in business functionality and technical concerns.

Agile approaches that focus on interdisciplinary, end-to-end-responsible and empowered teams have become mainstream in many organizations. And sometimes a focus on tools, automation and formal descriptions is understood as contradicting agile practices and values, it is understood as driving the business and engineers apart. However, this is a false dichotomy. Precise and analysable representations of the subject matter are the perfect basis for understanding and productive collaboration between SMEs and software developers. And nothing in this approach prohibits incremental development, short release cycles and integration of feedback. To the contrary: the approach makes changes less painful, cheaper, faster, and safer. Subject Matter First increases business agility

Might this drive developers and SMEs apart? To the contrary. The structured knowledge that captures the subject matter in the tool is a great nucleus around which to organize effective collaboration and co-creation.

Our proposed approach lets everybody focus on their strong suit: SMEs spend less time trivializing their knowledge when they explain it to developers, they spend less energy on pushing things through the process. They have more time exercising, growing and operationalizing the knowledge, creating value for the organization. In our experience, many SMEs really are eager to do this, they are perfectly fine to be precise and eager to take responsibility. But currently they don’t have the tools.

On the other hand, the approach lets software engineers focus on building robust platforms and automation pipelines instead of understanding and then implementing every particular change in business logic.

So we don’t drive the two communities apart – to the contrary. The common understanding captured in the tool acts as a contract between the SMEs and software developers, clarifying responsibilities, and empowering everyone to do what they do best. Ultimately, our approach leads to increased professional satisfaction and pride for both subject matter and software engineering experts.

Are we forcing SMEs to become programmers? Not at all. Expressing knowledge in a way that is precise, analyzable and correct is not the same as programming and software engineering.

There are lots of domains in which computers and software tools are essential in the SMEs’ toolbox already. An example is CAD systems for mechanical engineers. Subject Matter First advocates a similar approach for knowledge workers in domains such as healthcare, finance, tax, public administration, biology, medicine and law. It’s not fair to expect them to keep track of (continuously evolving) subject matter with whiteboards, text documents, spreadsheets or issues in an issue tracker.

There is some overlap between the required skills of programmers and SMEs in the context of Subject Matter First. For example, both must understand notions of variables, values, arithmetic operators, as well as decisions and conditionals. But the core skills of software developers are defining new abstractions, dealing effectively with large and complex systems, managing dependencies and understanding an increasingly large number of diverse languages, libraries, frameworks and infrastructure components. None of that is necessary for SMEs to be successful with Subject Matter First.

Can’t we just use off-the-shelf tools such as Excel or a low-code platform? No. Off-the-shelf tools are by definition generic, so they will not lead to the same improvements as custom tools tailored for your domain.

There’s a superficial similarity of our proposal with low-code platforms. However, off-the-shelf low code platforms do not address the specific subject matter of an oganizations, but instead enable non-professionals to build ad-hoc solutions to ancillary IT and data management problems. Most of these tools are essentially Microsoft Access in the cloud. Business rule engines and BPMN are a step in the right direction, because they also try to empower business analysts. But just like business process modeling tools, they are generic. In contrast, we advocate toolifying the core of a domain with tailored tools, the part that makes you successful as a business and that distinguishes you from your competitors. In this sense, the approach proposed in this manifesto is also different from the notion of end-user programming and citizen developers, although there is some overlap in terms of tools and technologies that apply.

We aren’t supposed to build tools! Yes, you are! Many successful businesses develop their own infrastructure, tools and processes, they just don’t talk much about it.

An objection we hear often relates to the development of tools: “Our company builds XYZ, we’re not a tool building company”. This is in sharp contrast to many businesses that thrive because of their effective development tools and manufacturing process. Often these tools are custom-developed for the particular product the tools are supposed to help build. Mechanical engineering companies have departments full of people who plan and develop manufacturing lines.

There are more important conclusions we can draw from the analogy to manufacturing. The first is that tools are usually not built from scratch either. They rely on tool platforms and tools for building tools. There are many such tool-building-tools in software in the space of modeling, language engineering, business rules engines or knowledge engineering. The second conclusion is that the investment in custom tools only pays off if there is some notion of economy of scale, i.e., if they can be used for building lots of products. However, this is very much true for many organizations. We will cover this in the next FAQ.

Which domains are suitable for this approach? Large, complicated domains with internal variety, evolution over time and longevity.

Building the tools and the automation requires an initial investment. For this to pay off, the domain has to have the following characteristics. Their subject matter must be sufficiently large and complicated, there are experts who specialize in that subject matter, there must be regular change in that subject matter and the domain must be sufficiently long-lived. We have seen this in insurance (product definition), healthcare (treatment algorithms), public administration and the services around it (tax, public benefits) as well as law (executable contracts).

Why should software engineers care? Because they can focus on their core skills — building platforms and automation — as opposed to understanding every little detail of the subject matter.

One of the most important foundations of software engineering is separation of concerns. It means that you shouldn’t put stuff that doesn’t belong together in the same place — don’t mix apples and oranges. In our opinion the most important concerns to separate is subject matter and all the technical engineering needed to execute the subject matter as software. Because once they are mixed, you can’t untangle the two later when you want to change one of the two.

Keeping the sources of the two separate — and mixing them only as a transient artifact — is crucial because it allows for the empowerment of SMEs as described in this manifesto. But it also means that you can change and evolve the technical platform without affecting the subject matter itself. The two lifecycles are largely decoupled, as they should be. Considering today’s fast technology cycles, this is absolutely crucial for keeping your software stack up to date.

In the end, the approach minimizes the legacy trap, which we’d describe as having buried all your subject matter in the details of technical code.

Does this actually work? Where are the examples? Check out the signatories of this manifesto. The links associated with each signee are supposed to point to examples of the approach.

We have decided against collecting case studies and examples on this site, because this would require that somebody decides which case studies qualify. This will inevitably create problems within the community. Which is why we have decided to put the burden on the reader to check out the links provided by the signatories and judge for themselves.

While collecting case studies is a noble and important goal, and it shares similarities with the goals of the Manifesto, this is outside its scope.

Who is behind this manifesto?

This manifesto has grown out of years of work in the space of domain specific languages. Federico, Markus and Sergej have driven the initiative, but the contents and wording were discussed in various meetings of the Strumenta community and also in personal dialogs with members of the community.