Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Do Not Create a Domain Specific Language for Your Customer

DZone's Guide to

Do Not Create a Domain Specific Language for Your Customer

Considering creating a Domain Specific Language (DSL) solution for your customers? Think again.

· Integration Zone
Free Resource

Modernize your application architectures with microservices and APIs with best practices from this free virtual summit series. Brought to you in partnership with CA Technologies.

Domain Specific Language (DSL) solutions are many times created with the intent to give a tool to the hands of the customer representatives (business people) to do the configuration of the application on their own. Most of these attempts fail miserably: the DSL usually ends up only being used by developers. Why can’t customers or business people use your DSL?

That is because of customers' programming inexperience vs. "the customer is always right."

Both of these ideas have some background and can be true to some degree no matter how contradicting they are.

If you are a mechanic your customers do not know about the injectors and the valve settings. They just want the car running from A to B. If you are plumber your customers just want to have a shower and drink fresh water but they are not really interested nor knowledgable about fittings. If you are electrician your customers just want light and wiring is an unavoidable nuisance.

Customers are not stupid. They just see the world from a different angle and they do not know your profession. (And this is very good, otherwise you would be jobless.)

On the other side of the scale customers are not entirely right all the times. It is just the fact that they have the money you want to work for and if they are not satisfied they will not pay.

Customers pay for the value they get and not for the work you do.

Generally: you have to find a job where you can create great value with minimal work. Some people are good at it some are not that good.

You can fix their cars but it has to be a value for them. If you just refill the window washer fluid: that is not a huge value as compared to the effort. They could do it themselves and usually today they do. Likewise if you are a plumber your service is not requested each time the client wants the water to run. Similarly there is no need for an electrician to switch the light on and off.

This is the idea of DSL. A switch on the wall is a DSL. Does it work?

Why do most of the DSL projects fail then?

What I see is that most of these project implement first the switch on the wall and the outlet to plug in the TV, washing machine and so on but then they start to go on and try to invent other tools that would support the reorganization of the wiring. Someting like a cross connection table at the electric center of the house where the customer can plug in wires to have 12V direct current in some of the outlets, 120V alternating current in other outlets and 220V in the guest room when visitors come from Europe.

Very soon these DSL solutions become just too complex for the customers. First it starts off with a simple text file. Later on it is an Excell table. Then a whole buch of sheets with many columns. Even later somehow scripts emerge that help the editing and the conistency maintenance of the data. And it all supposed to be maintained by the customer.

So what is the right way to do it? Are DSLs doomed and should not be created?

The fact is that you can create DSL for the customer but they have to be as simple as a light switch or a water faucet. You can build a DSL that is more complex but do not expect a customer to use it. Layer the tasks, and separate who can do what so that everybody is working on tasks where he/she can have the most added value.

Yes, this is a simple advice that is hard to execute. But we can try.

The Integration Zone is proudly sponsored by CA Technologies. Learn from expert microservices and API presentations at the Modernizing Application Architectures Virtual Summit Series.

Topics:
domain specific languages ,customer self service ,service design

Published at DZone with permission of Peter Verhas, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}