Perspectives on DSLs:
Production Knowledge
Another perspective on the knowledge in a domain
Manufacturing Telescope
Mirrors
Modern optical astronomy
relies on huge telescopes such as the LBT or the VLT , because the light gathering power and resolution
of a telescope are more or less directly related to the diameter of the mirror.
To ensure image quality and avoid optical aberrations, the surface of these
mirrors has to be very precisely ground and polished, down to the scale of
micrometers. In addition, this precisely-shaped surface may not be bent or
otherwise distorted by temperature effects. So the material from which these
mirrors are made is hugely important. In particular, it must have a very low
temperature expansion coefficient.
The German company Schott is a leader in
this area. They have a ceramic glass called Zerodur, which has a much lower temperature coefficient
than competing materials. In terms of domain knowledge, the ingredients for
this material are key for Schott — which is why the details are secret.
But it is not just about the
ingredients. The production process is just as important. How do you process
these ingredients to produce 8 meter mirrors with a homogeneous level of
quality? What is the size of the granulates before melting? What temperature do
you heat to? How quickly do you cool down? How does the cooling rate depend on
the size of the chunk? What kind of diagnostics are meaningful to control the
quality of the glass body without destroying it?
With the upcoming Extremely
Large Telescope and its monstrous 39 meter mirror, Schott faces
another challenge. The 39 meter mirror is made of 798 separate segments which
are actively aligned during an observation. After handcrafting very small
numbers of large mirrors over decades, Schott is now tasked to produce 798
mirrors of 1.4 meter each. How do you produce hundreds of mirrors with the same
quality? How do you do that with the existing production facilities? How do you
orchestrate the production steps in order to minimize unnecessary handling —
after all it’s still glass that might break when handled badly.
If you want to know the
answers to all of these questions secret you should check out episode 335 of the omega tau podcast or read the
respective section of chapter 6 in this book. We’ll now look at the connection to language
engineering and knowledge management. In addition to owning an actionable
representation of the domain knowledge (in the form of DSL models), it is also
crucial to master the process with which you build your product from the
knowledge. Let’s explore this idea.
Architecture, Patterns and
Technology
To “execute our knowledge” we
have to transform it into software, expressed with various programming
languages, frameworks, and libraries, taking into account various
non-functional concerns such as safety, security, performance and scalability.
This mapping — from domain constructs to architecture and technology — is very
often based on proven patterns or idioms. Instead of manually re-implementing
this mapping over and over again, we can put it into generators. To everybody
who has ever spent five minutes on DSLs and model driven software development,
this is obvious. It is one of the major drivers for using these techniques in
the first place. Automation makes sense because — assuming the automation
itself has no errors — product development becomes faster and it is easier to
maintain quality throughout a large code base.
External Process
Requirements
But there is much more than
code generation. Many domains require extensive documentation of a software
product and/or quality metrics and/or the production process. For example,
there are extensive requirements regarding the documentation of software products
in healthcare if you want it to be cleared by the FDA (which you have to,
otherwise you won’t sell it). Creating all these artifacts manually is time
consuming, repetitive and error-prone. By automating the development process,
you can generate many of those artifacts automatically, which can drive huge
reductions in development effort, as these examples from space and digital
therapeuticsdemonstrate.
You have to build tools!
However, you can only
leverage these advantages if you invest into domain-specific tools, both for
representing domain knowledge and for automating the production of your
products. This is really not surprising, because many other industries,
especially those who produce large numbers of similar or related products,
invest seriously into optimizing the manufacturing process. The obvious example
are car manufacturers. They have whole departments that deal with designing and
building efficient production lines and the associated logistics. To become
productive, the software industry has to do the same: build knowledge about
domain-specific production processes.
The analogy to cars carries
further: Daimler or BMW do not build presses, welding robots or automated high
bay warehouses; they buy those. But assembling them into product-specific
manufacturing facilities is knowledge they own and treasure. In the software
industry the analogy to robots and presses are compilers, language workbenches,
code generation engines and stuff like that: we buy those or use open source
software. But assembling those into domain-specific software production
pipelines should be a core asset for every organization that develops lots of
products in a particular domain.
If we do not invest
into domain-specific production facilities, the only opportunities for
automation are generic: compile, build, package, test and collecting metrics.
All of these are useful, but they fall short of what’s possible.
Manufacturability
We can milk the car
manufacturing analogy even more. As an engineer, when you design a part of a
car, you might have to make certain compromises to make sure the part can be
manufactured. For example, if you know that the part will be milled from a
solid block of raw material, you know that, depending on the milling machine,
only certain shapes are possible. In an ideal world, the product and its
manufacturing strategy are independent. In reality they are not (quite).
Transferred to the software industry, this means that if you want to
automatically derive certain documents, domain-specific metrics or other
externally required artifacts, you might have to change your modeling language
a little bit or annotate your models in particular ways. If you are in control
of the language — as you are when you build you own DSL — this is not a problem
at all.
Wrap up
There is an unfortunate
prejudice in the software industry that can be summarized by the following
statement that I have heard in many companies:
We build XYZ, we’re not tool builders.
This is an unfortunate
attitude, since it prevents our industry from significant increases in both
efficiency and quality. It is crucial to understand that domain expertise also
includes production and process knowledge. Other industries, like those car
manufacturers and Schott understand this very well. So should we.