01/16/10 :: [MDE] Solution vs Problem Abstractions, does it matter? [permalink]
As Google just launched a "new" general purpose programming language (what for?) more and more people are asking about and somewhat demanding better abstractions. The question is should they be problem or solution side abstractions or possibly both?
Udi recently complained about solution side abstractions:
If we want our architecture to be stable, we need to base it on stable abstractions. The only thing is that there aren’t any inherently stable abstractions in the solution domain (as we’ve had the chance to witness). That really only leaves one other place to look for them – in the problem domain, also known as the functional requirements.
Udi believes that the solution is on the problem side :-):
If we could find a way to capture those stable elements and represent them as core elements in our architectural structure, and then balance the non-functional requirements within those functional contexts, maybe, just maybe, our architecture will stand the test of time.
His position is quite ironic as the BPM punditocracy interprets the current wave of acquisition of the BPM space as a "the end of BPM" as we know it. This particular rash of BPM products built their business on the fallacy that you could somehow build solutions directly from "problem-side abstractions", i.e. BPMN. Ten years later, we are still waiting for large enterprise deployments where all business processes are somehow implemented from problem-side definitions. These vendors have for long claimed victory, this is somewhat of a Phyrric victory for our industry. Sincerely, I am glad they are going away. They have taken away tremendous resources, delivered hardly anything, and prevented the right solution-side abstractions to emerge. I have had some discussions with Keith and Scott on that topic after Keith detailed the "process trends" he saw unfolding in the last 20 years.
These "process trends" are precisely the problem you are going to face if you go find your abstractions in the problem space: you will never succeed at converting problem side analysts that can achieve the level of rigor necessary to build a solution and because you will adopt their language, you will have less than optimal abstractions to build the solutions and you'll end up, like BPM, catering to different groups when the solution-side is in fact common. The little known secret of "BPM" is that once you quickly pass the pretty (process) pictures, when you look under the hood, you see all kinds of ugly scripting language dropped wherever possible. Scott thinks that JavaScript is the "ideal" complement of BPMN. Anyone who has written more than 10 lines of JavaScript understands what I mean, and JavaScript is possibly one of the better ones I have seen over there.
So Udi, I am sorry, but starting on the the problem side has been tried and it's a mess. Developers will never be able to design abstractions that make business analysts comfortable, they need freedom and fuzziness. They want the solution side to build the solution, not them. Hence, the problem-side needs a) as fewer abstraction as possible and b) (what is the most important) whatever runs in production (once the problem has been solved) must be "visualizable" by the business analysts. That is the most important direction: solution->problem, not the other way around. So far, the problem->solution is just a pipe dream, an immense distraction for our industry and a general failure.
There is a more fundamental reason, for why abstractions (problem or solution side) cannot emerge. If you spend some time exploring Ecore in EMF (or MOF in UML) and if you look at EMF's M3 layer (i.e. Ecore):
You can see that, the center is the "EClass". Just like in OMF, the M3 layer is OO based. OO is the enemy, sorry, I can't find another word. There is nothing abstract about OO and there is nothing architectural about OO. OO is a tiny little pattern which success is out of control. Actually, I am a bit unfair. I teach mathematics to my kids using UML. So, yes OO, provides a generic modeling capability to describe systems statically, or static abstractions. At a certain level, everything is a bag of attributes with relations to other things. But you can't efficiently describe dynamic systems in OO, the behavior is an after thought in Ecore and MOF, well beyond the OO cave.
Udi, look no further for why solution-side abstractions don't work: static solution-side abstractions are not very common. Once the modeler realizes that he or she needs behavior, that's when he or she starts throwing a scripting language into the mix and everything becomes ugly, impossible to dissociate from the underlying architecture (the script has to run somewhere, call some APIs...). Microsoft abuses "code behind" models, for the same result: once your abstraction is tied into an architecture, you know what happens next. I have raised this concern with some of the fathers of MDA but I always a distant glare and no response. I may be wrong, but IMHO, MDA is built on the wrong foundation, OO. It is going to be hard for them or for the OMG to change course, but there has been enough surges in that direction to think the solution to MDE would be more OO.
I like textual-DSLs because they are conducive to modeling behavior in addition to the abstraction. You tend to create your own programming language along-side the abstractions. This is why I was generally excited about SSM and things like MService. Note that some people understand the problem, some people have shown how to extend Ecore to model "code" as well. But I think OO IS-THE problem, abstractions need to exist completely outside the OO cave. This is why I suggest to adopt a Metamodel Oriented Programming approach.
I am certain that the question you raise will be solved in the next 10 years and that the abstractions will be more on the solution side, completely outside the OO space.
