Adopting DSLs in your Organization


Whatever you decide to do, realize that languages and tools have to go together with a suitable development process and must be justified by a business case.


 
 


A more detailed process about how to adopt a DSL is sketched in the slides at the end of this page. Here is a summary of the main aspects:

Language Prototyping Workshop

After discussing some of the things mentioned on the previous page I almost always start with a prototyping workshop that lasts between 2 and 5 days, depending on the domain. The goals are to get a grasp of the essential complexities of the domain, to explore ideas of how they might be addressed with a DSL and to demo how language implementation works. The workshop is a mix of discussions about the domain, sketching ideas on the flipchart as well as live, interactive language implementation sprints.

Even if we stopped everything after this prototype, it was worth it. It has taught us so much about our domain we didn't really know! Language development is a great catalyst for understanding!    —   A Customer

Prototype Evaluation

Next, we'll do an evaluation of the prototype. To the degree we can tell after the workshop, does this approach have the potential to solve the challenges in our organization? Is the future language potentially usable for its intended users? We might even ask a few of them. What do we think about the tool? Assuming we used MPS for the prototype, is it an option for the full-scale development? What alternatives exist? Can we make an initial estimate about the effort for developing the language?


Big Picture: Process and Integration

Assuming the evaluation in the previous step is positive, we now sketch out the integration of the DSL and its IDE into the existing tool and data landscape — no tool stands alone! We will also explore consequences for the development process: which roles have to change? How will responsibilities shift? Did we ask the affected people whether they are up for this?


Business Case and Stakeholders

As we are getting closer and closer to a "real" project, let's revisit the business case. What is the increase in efficiency we might gain with the DSL? Can we make it concrete in terms of "amount of money per year"? Who are the stakeholders that benefit most? Who is a champion for the approach? Are there stakeholders who might perceive the DSL as a problem or even a threat? What can we do to get them onboard?


Setup of Agile Development Project

Now we're at the stage of launching an actual development project. We'll organize it like any other modern development project: Scrum, sprints, automated tests, version control, feature branches, integration server, build-and-run-tests on commit. We'll make sure we have a few competent future users on hand to help ask questions about the domain — we will intertwine a domain analysis with the development of the language — and we will make sure this person and their colleagues will evaluate the language and its evolution regularly.

Knowledge transfer from me to you will also be a major part of this project, because we want to make sure your organzation builds the knowledge and skills to maintain the language, generators, interpreters and IDE for the long term.



 
Contact me to chat about whether a DSL is suitable for you and to plan out how we could go ahead with exploring the possibilities.
 


Introducing DSLs into an Organization
A slide deck for not-so-technical people