DSLs are relevant only to companies that build software by making developers and some kind of non-developers collaborate. This is the situation in which DSLs shine. If this is not your case then probably adopting a DSL should not be among your priorities.

Some examples:

You build software for tax calculations. You have tax specialists collaborate with developers
You build digital therapeutics software. You have healthcare practitioners collaborate with developers
You build business automation software. You have business analysts collaborate with developers
You build actuarial software. You have actuaries collaborate with developers
You build software to control engineering processes. You have engineers collaborate with developers

There are no other single factors that make a huge difference. Regarding the size of your company, if you can afford to invest tens of thousands of dollars or euros to get the DSL designed and implemented for you, then you are not too small. The field you operate in is irrelevant: there are applications of DSLs in all sorts of verticals. I can just say several examples seem to work particularly well in regulated fields, probably because those companies hire many specialists.

Why should a CEO care about DSLs?

Because:

There is a cost in making your specialists and your developers communicate. They spend a lot of time explaining what they do to each other and there are misunderstandings. DSLs can bring down those costs
Because they can help specialists do their job more efficiently. Often specialists have limited tools to check their reasoning. Many errors are found only late in the process when developers start writing code. That is terribly inefficient. When we use DSLs we can give tools to specialists that help them do their own thing and find many errors themselves, early in the process
Because it can reduce time to market. In each case we have ever seen, once you get a DSL people can do their own stuff more efficiently and more quickly. As a result, things take weeks instead of months and you can put your products out there much more quickly

Ok, what are DSLs?

In essence, think of super-smart editors that can help specialists write things down correctly.

Imagine these editors have a “reasoning spellchecker”, which points out errors.

And imagine these editors being able to generate automatically useful stuff: software, documentation, configuration files, and more.

No, there is no AI involved in the process. What makes it possible for these smart editors to be constructed are DSLs. The technology behind it is actually quite boring and reliable, but let’s keep that between you and me.

That’s great, but what could go wrong?

Now, there are challenges and risks when adopting DSLs:

DSLs designers with the right skills are rare. You may need to wait to get the right people available to get started or to scale up your project. You do not need a ton of people for creating DSLs, but you need the right ones and you cannot find them that easily
Adopting DSLs changes how things work. It does not matter that things are changed for the better, someone will be resistant to change. It could be the manager leading the testing department who all of a sudden needs fewer people, or it could be a long-time employee used to get things done in a certain way. In our experience, while people can consider themselves to be open to change, they are not always so ready to adapt their way of working, when needed
Developers may be against DSLs if they are not involved right away in the discussion. DSLs make the life of developers easier, but they frequently misinterpret the idea behind DSLs, so they may think it is not possible to achieve what DSLs promise. It should be clear that DSLs are not about getting rid of developers. It is about removing the boring back-and-forth dance to implement, correct, and revise once more details in the code based on how specialists change their minds. This is done by making the specialists become much more independent. Developers will still be very important for the development of the core platform. Typically developers, in the end, see how DSLs benefit them too, but their concerns must be addressed by involving them properly, or they could resist and even sabotage the project

Ok, this seems to make sense. How can I learn more?

You can throw some technical material to your CTO. For example, this guide.
You can read some case studies, like this one: Voluntis Case Study

And you can, of course, ask us to explain more, and more importantly discuss if and how this can work for your specific case. We could start with a 45 minutes call to discuss your case. You can book it by filling out this questionnaire. You can also write at [email protected]