Now that Oslo is in a public form, I’ve taken time (as you probably noticed in earlier blog posts) to look at Oslo. While the Model Driven Development part of the stack is important and potentially game changing, I wanted to stop and look at the Domain Specific Language part of the Oslo stack.

I am not the only one though. The potential for building Domain Specific Languages has caused jeers and leers from different parts of the web including Martin Fowler, Frans Bouma, and Roger Asling. Aside from the whether “M” becomes a valid way to build Domain Specific Language, I am more interested in the idea behind Domain Specific Languages themselves.

Honestly I am not sure whether I am early or late to the party. My interest was peaked at a party where I was a fly on the wall with the likes of Don Box, Chris Sells, Ted Neward, Neil Ford (et al.) all discussing what it meant to be a DSL and why it was important. I’ve be stewing and thinking about it quietly since then to try and understand really what is means to me and the problem spaces I care about. This is what I came up with.

Business software is written to solve business problems. The people feeling the pain of the business problem are often the people running the business. The people that run a business are rarely the technical folks. Before software is written we need to understand the problem so that we can figure out how to solve the problem. That means that technical folks have to talk to the non-technical folks to understand the problem. Traditionally that is how requirements are gathered. So what happens next? Typically the requirements are written down and communicated back to the non-technical folks to see if the requirements are still correct as simply transcribing them can introduce errors in the requirements. Finally the requirements are shared with developers to implement the requirements.

This doesn’t work well as well as it should.

This problem is that the two groups involved often do not speak the same language. Language is a big deal here. Every business has its own vocabulary and unless the technical people have been in the business for a long time, they don’t understand that vocabulary. Even developers have their own vocabulary and we know that most people don’t understand what we are saying (especially our spouses), so why should it surprise us that we often do not understand the vocabulary of the business we are working with/for?

This is exacerbated by the problem that contractors are being used to a great extent these days. It used to be that developers in an enterprise would learn their domain. Part of the process of working in a company would be learning the language of the company and how they did business. To my surprise many companies are investing in contractors to teach them their domain and then cutting them loose. This means we need to have a way get domain knowledge “out of the head” of the stakeholders and into a form that can live for longer than one product cycle.

In the recent Oslo .NET Rocks Podcast, Don Box and Doug Purdy talked about the problem of coders and encoding. If you haven’t listened to the podcast yet, i’ll paraphrase. We learn from the non-technical folks how to run their business, then we write it down.  We take the written down version and ask a ‘coder’ to encode the rules in code. The essential problem here is that we can’t have the non-technical folks read the ‘encoded’ version to figure out if it matches their intent. It also assumes that the developer understands the language of the business well enough to make sense of the written down version.

The other problem is that as the business changes, the whole cycle has to repeat. Once the documented business process is encoded, changing it requires re-encoding of the change. This is problematic.

How do Domain Specific Languages fit into problem space? I think that if we can talk with the non-technical folks and create a textual DSL (or perhaps a visual DSL) that is clear enough for the non-technical folks to read it (not necessarily write it), then we can use that to document the business problems. That would allow for the developer to use that data at runtime instead of encoding it. That means that the non-technical folks can *validate* the actual business rules (not the documentation that is being encoded) so that our systems are less prone to communication confusion. In addition, this means that as the business changes, the changes to the business rules are interpreted by the system instead of being re-encoded.

This doesn’t take the developer completely out of the picture as developers still need to use the runtime information to make the system work as well as develop and maintain the DSL. Rarely will a DSL be complete. As business requirements change, the DSL will often have to change to accommodate new business rules. But that leaves the developer from having to have intimate knowledge of the business (though tertiary knowledge is still required).

At the end of the day this allows fewer points of failure between the business intent and the runtime environment.  At least that is my hope.

Of course, this is not new. We build and use Domain Specific Languages all the time on projects. Every time we build a new configuration file section, XML Schema, or use one of the plethora of  common DSLs (e.g. XSLT, XAML, CSV) we are using DSLs. The difference that I hope this brings in is the ability to have DSLs that are consumable by non-technical stakeholders in the business.

What do you think?