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 WorkshopAfter 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 estimated complexity of 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 EvaluationNext, we'll do an evaluation of the protoype. To the degree we can tell after the workshop, does this approach have the potential to solve the challenges set out for it? Is the language potentially usable for future users, the domain experts? 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 IntegrationAssuming 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 do reponsibilities shift? Did we ask these them whether they are up for this?
Business Case and StakeholdersAs 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 competent future user on hand to help ask questions about the domain — there will be many, we have to "materialize" the domain into 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.