In this article, we're demonstrating how business knowledge can be turned into an explicit asset of your business. A key asset of your business is the knowledge you have built up. This knowledge is present in various forms. Such forms include business rules, financial calculations, data structures, mappings or queries, validations, scientific processes and contracts.
This post will teach you three things:
- why business knowledge should be captured
- why prose text and code are not sufficient for that
- how you could manage knowledge in a more suitable way
Let's start with looking at what it means to know something as an organization.
What is knowledge
What is knowledge, from the perspective of an organization? Here's how I would define it. The world is full of information, data and stories about almost every imaginable domain. But if a company wants to develop software in that domain, they have to make sense of all of this stuff. They have to scope the domain (define what's in and out for their purposes). They have to structure in some systematic way and make it accessible to the people in the organization. They have to evolve it over time, and ultimately, they have to do something with it. Typically encode it into software as part of their products. So:
Knowledge is an organization's understanding of relevant information and data that is available in the world or built proprietarily by the organization.
Let's look at a few examples. If you develop payroll software, you have to be aware and understand all the laws and regulations that concern payroll in your target markets. If you are the government agency that calculates taxes for your citizens, you have to make sense of the laws and regulations that represent the governments decisions relative to taxes, and probably lots of court rulings as well.
If you're a healthcare company that develops digital therapeutics apps, you have to distill the medical expertise that governs a certain therapy or medication into a repeatable and deterministic algorithm.
In most cases, all the data and information you need is out there. In some cases you have to built it yourself. But always the question is: how do you capture this knowledge in your company to make it actionable, knowledge that you can package into your products and sell to your customers?
Representing Knowledge as Text and Code
Of course, you will employ a bunch of experts, people who have experience in the respective domain. Often they are called analysts, and their job is to build up knowledge from data and information, with the help of their own skills and domain expertise. But again: what is their work product?
The traditional approach is to write things down as prose, with a couple of explanatory diagrams, sometimes formulas, and often lots of tables full of numbers. You will also find the occasional decision table or decision tree, but mostly the relevant knowledge is encoded as text.
Text is useful because it can be consumed by anyone – at least superficially, because you need experience in the domain to make sense of the writing. But a prose representation does not let you do anything with the knowledge. You cannot check it for completeness or consistency (which is why many texts become a mess after they have been evolved and changed a number of times), you cannot transform it into different representations, and of course you cannot execute it. You can only display, print and read.
There is a second mainstream approach. It encodes the knowledge directly in (programming language) source code. Of course this lets you execute it, and by writing tests, you have a way of cross-checking the encoding. Tests also help with evolution because they provide a safety net that makes changes less risky. But once you have encoded knowledge in source code, execution is pretty much the only thing you can do with it.
It is very hard to reverse engineer the domain-level semantics, which makes meaningful analysis hard. Source code is also not very understandable to non-programmers such as your analysts and domain experts. They might revert back to writing text – now called requirements – which is hopefully understood correctly by programmers so they can encode it.
It also requires a lot of discipline to not accidentally mix your domain-knowledge-as-code with code for the technical concerns required to make it run. And it is effectively hopeless to try to extract the knowledge from program text and transform it into a different representation, such as source code in a different programming language. Really, encoding knowledge in source code effectively buries it there.
Encoding Knowledge in DSL Models
Domain-specific languages combine the best of both worlds. Knowledge encoded as DSL models can be executed through interpretation or code generation. It is also completely independent of the actual execution technology, so porting to another technology is easy. It is even possible to port the models to a language implemented on a different language workbench.
Well designed DSLs supports analysis relevant to the domain. And while a DSL is not as trivially approachable as prose (to the degree technical prose is), a good one can be very much learned and used by non-programmers. Simulators, and other ways of bringing the knowledge to life directly in the DSL Workbench also help a lot.
But, you might ask, do I really have to build my own language? Can't I just encode my domain knowledge with an existing modeling language? Maybe you can. There is a long tradition of "analysis modeling" (at least in books and academia; haven't seen too many in the real world). But you absolutely need a well-defined language, otherwise the semantics are unclear and you can't execute it. Using UML, for example, in a way that is precise enough for execution, is cumbersome (but possible if you try hard).
Think about it: every domain, has its own jargon, its own conventions, and often its own notations. Math and chemistry come to mind. You don't want to encode it in jargon-free English. Similarly for models: you want a language that fits the things you want to express.
In addition, the process of building the language is itself extremely useful. Because it helps you understand the jargon, conventions and notations for the domain, and it forces you to nail down a precise meaning. In some sense, the DSL definition is meta-knowledge, knowledge that is relevant to the whole of your domain. In fact, it can be seen as the authoritative definition of your domain. Don't risk that benefit by trying to shoehorn your knowledge into a semi-formal and imprecise general-purpose modeling language.
The DSL definition itself is valuable meta-knowledge of your domain.
Maintaining Core Business Knowledge with DSLs
Now you know that modeling in a DSL is a great way to capture the knowledge in your organization. However we didn't tell you much about what a DSL is and how to go for it.
Domain specific languages are a very particular approach to tackle a problem. Xtext and MPS are typical tools for that. However, as with every approach, it is not just the tools and rules, but also takes a bit of experience to know how to maneuver this in your organization.
At itemis, we regularly guide companies through such process. Also technically, we are the experts, considering that we are maintaining Xtext and several platform features of MPS. If you are interested in learning more, just contact us and we will be glad to support you in figuring out what to do next.
Comments