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