That’s The Cool Stuff We’ll Be Doing on the Mission Together January 14, 2008
Posted by ActiveEngine Sensei in ActiveEngine, Business Processes, Problem Solving.Tags: Domain Driven Design, Domain Specific Languages, DSL, Eric Evans
trackback
“The greatest challenge to any thinker is stating the problem in a way that will allow a solution.” – Bertrand Russell
If you head over to ProjectManagement411.com Bob has started a conversation focused on how a Project Management Office (PMO) can assist with describing your domain of problems. This got me thinking about how difficult it can be to clearly define the goals of a domain in terms that all teams involved can understand.
I went to the archives at DotNetRocks, and listened to the Eric Evans interview concerning Domain Driven Design and Domain Specific Languages. Right off the bat Eric said, and I am paraphrasing, “Developers usually bring the the mindset to the table of ‘how can I use web services or design patterns to solve this problem for my customer’. What is needed is better understanding of the customer’s problems.”
If you think about what he is saying, then Domain Specific Languages can only be produced after the development team are experts in the business unit’s subject matter. Taken further, a Domain Specific Language, or even the size of the domain that the developers are attempting to model may need to be reduced drastically, as the customers business processes may not be mature enough for such finite detail. And consider the other end of the spectrum where the problem domain is very mature, and the development team is attempting to recreate the wheel just so that the problems fits the solution paradigm.
A practitioner of ActiveEngine will chose the course that aligns the interest of the clients first. You must have mastery of the client’s subject matter FIRST, and be conversant in their language before you work your magic. Remember, if they don’t understand you, they may pay much attention.
ActiveEngine 
“..can only be produced after the development team are experts in the business unit’s subject matter..” is interesting. Applying this to most projects I’ve had experience with, I’m struck with the amount of learning that must go on before the customer and the project team (whether consisting of internal organization people or external) can really gain traction and be useful. Then compare this to the solution (software, consulting services, etc) sales environment where a level of learning about the customers problems and business processes, and/or a confidence level, must occur before the customer is willing to sign a contract. It’s very fuzzy and highly dependent on relationship building. I like to talk about “ideal” situations and then begin to chip away at the ideal with reasonable rationales for changing the process – whether it be a sales process or project process. Talking about sales of a project is important because it impacts the project, and if done properly, a project will flow naturally from sale to work.
In fact, Eric Evans is convinced that the first solution that is produced by even a competent team will not pass muster to be considered good enough for a Domain specific solution. Considered in this view it makes you consider whether so much effort is worth it. Or perhaps it is more properly stated that such expenditure requires great consideration before embarking, as you may need several attempts to realize success.