Domain Experts, what the use ?

I wrote this post as a reply to the post on Arjen Poutsma's Blog entry: The Quest for the Domain Expert

Arjen refers to definitions of the Domain Expert as found in the specification of EJB and BPEL, the first looks more like a technical assembly task that belongs to a deployment process and therefore still is software driven. The BPEL definition contains the same notion:
The creation of the BPEL is a developers job, attachment to services is a domain experts' job
At least that could be an explanation of the small piece of text.

The concept of the Domain Expert is also connected to Expert Systems.
If we define the Domain Expert as a professional in a more business oriented job, the separation could be more useful.

It might be that BPEL as a whole is not on the right level of abstraction for Domain Experts, still the Service Oriented Architecture and standards around web-services make it possible to grow to a situation that Domain Experts could 'compose' a solution for their needs.

There are a few conditions:

The Domain Expert should be able to learn the 'language'

Language in the broad sense of the word. For example many Financial Domain Experts are pretty handy with Excel, most of the times it ends up with a special type of programming inside spreadsheets. So, you can say that Domain Experts are able to learn a specific type of language as long as it fulfills their needs.

A more visual language like BPEL - or better BPMN - gives the possibility to master the logic behind the language.

Services should have a Business Logic Type of interface

To keep the comparison with Excel, inside excel all types of calculation and information are fixed. A webservice is much more flexible with its' responses

Web-services could very well return 3rd generation programming language types of results, like a Map with objects that need to be used to build your own decision (while loops with if then else constructions). These types of web-services make it quite impossible for Domain Experts to compose their solution as the level of abstraction moves down towards a 3rd generation programming language and requires programming thinking and skills.

Web-services are better fitted on the business interface type of level, don’t return a list of objects but work with interfaces like:

• Verify Creditcard Number


• Cancel Order


• Ship Order Via

I strongly believe in design by contract, there should not be a hard link between your web-services interface and your code

When the conditions are met, Domain exports could manage themselves by modeling their solutions and execute those. It will remain a tough task to meet the conditions though.

In the end it will not lead to improved productivity for developers but mere a division between service building (business logic type of interface) and the consumer of these interfaces, it moves work towards another type of person, that might be the Business Oriented Domain Expert.