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

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.

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.

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.

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.

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).

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.

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.

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.