For the last few weeks, @voelter , @sergej , and I have been working on a Manifesto that we would like to share with you and discuss at the next Virtual Meetup, this Thursday.
In a few words, we have been working for years building advanced DSL solutions for all sorts of clients. While those projects have been successful the ideas we have seen working so well in those projects are still largely ignored by most developers out there.
So we would like to change that. We would like to try explaining the sense of these solutions in a new way, and start a discussion with the community on this topic.
We have shared this document with a very small number of well respected members of the Language Engineering community during last week. The feedback we received has been encouraging, but it is also clear we need to do more work on it.
Some big points remain open:
Who should we target this Manifesto to
What format the Manifesto should take: more concise, more opinionated, more detailed, more educative
How should we name this approach? The term DSL is too general, and we end up confusing people who think about internal DSLs or technical DSLs such as SQL. They are not what we are building
We hope that we can receive feedback from you and put together an improved version of this Manifesto
I could imagine this steps on SAP’s toes. At least in ye olden days, they slapped “business” on everything – their version of JSP / ASP was called BSP: Business Server Pages. And yep, that meant ABAP embedded in HTML …
I would avoid the the term “language” all together because it’s way to associated with programming and the whole thing isn’t only about the languages, it’s about building tools that allow experts to take their knowledge and work with it. This in almost all cases is much broader than “just” a language but involves integration with other parts of the overall system.
See could be a nice Acronym. I agree that we could remove the term language. I also agree that it is mostly about building tools, however, some feedback we received warned about putting too much evidence on the term “tool”, as it could be reductive and just seem an attempt to solve a problem throwing technology at it, without the underlying philosophy/methodology. I also agree that integration is key!
Reading the manifesto, I am not sure who the audience is, and without knowing that, there is no way to write the right text. Assuming that we want to target the business, I would go for a much more business oriented way of describing the various points. To explain what that would mean for this manifesto, attached is an example of how it could be rephrased. Support Business Agility by enabling subject matter experts to capture knowledge.pdf (10.0 KB)
The style of writing under Elaborations for several parts starts out rather defensive: is this contradicting agile?, Will this drive developers and subject matter experts apart?". This way the reader starts out with a negative sentiment, maybe it might work better to rephrase this in a more positive way without going (too much) into the defensive. I don’t have examples of this rephrasing, it sounds easier than it is .
Very interesting discussion yesterday!
Thank you to all the participants, to all those who shared ideas here, or by email.
It is great to see how some ideas resonate with many of you.
The feedback has been very useful. We had a good share of positive feedback and constructive criticism
I think we clarified a few points:
In short, if experts such rich knowledge, we want to enable those experts to define software products
We agreed that this Manifesto is targeted at Subject Matter Experts, not at technical people. We would expect those in the tranches, who experience the limitations of current approaches, to be the primary recipients of this Manifesto, and then secondarily to reach the other non-technical people, up to the CEO level. While technical people could more easily get it, they are not the primary target of the Manifesto
The Manifesto is about solutions that address the core domain of expertise of a company. While in any not tiny organization there are different types of expertise, there is frequently one that is a core asset for the company, impacting what the company offers. This approach focuses only on supporting those “core domains”. For example, a company producing medical applications could also have an IT security expert or a marketing expert. The approach we are proposing would ignore that ancillary expertise and focus exclusively on serving the medical expertise
This is NOT about a specific tool. While many today build these solutions using JetBrains MPS, the principles are more general. 10 or 20 years from now we may use other tools and the principles would still be valid. One could build these solutions using ANTLR, Xtext, ProjectIt, MPS, or other technical means. Also, the reverse is true: one could use MPS to build solutions that have nothing to do with the kind of solutions we want to promote in this Manifesto
We want to avoid referring to specific implementation techniques or means because those could change over time and because they could alienate our target (non-technical people). So we will not use terms such as MDE, DSL, Model, Language, Editor, Programming
We want also to avoid terms which are too vague such as Knowledge
The theme “Freedom from IT” and “Configurable platform” came up
We discussed the fact we want to offer better comunication, possibility to simulate, automate, and configurability. But there are other approaches making the same claims, so we should be more specific
We discussed Business vs Domain, we may want to avoid Business as it can be see in connection to money more than business logic
Some connections we make, could not necessarily be the same connections our target recipients would make. For example, if we talk about expertise, some of us could think about expert systems, but our target could have no idea about that term
The term Enable and Empower came up, as good ways to indicate what we do
We liked the idea of putting the experts in control, and discussed the metaphor of driving, being at the wheel, steering
We discussed the idea of co-creation involving experts and developers
We discussed the image of providing appropriate tools to experts, like architects could not do their work without CAD, so experts need their own tool
Some names proposed “Domain Specific Tools”, “Experts productivity Tools”
