Raise your level of abstraction
There is a big fuzz around model driven development and all the goodness about it, its promises of a high level of agility, cut down of prices, reduction of technical risks etc. etc. Many including myself think that the model-centric approach is the future of software development, and several companies are doing their business of it and build the next generation platforms and tools for creating agile business applications.
So, why on earth is it that big ISV players like Microsoft, Sun, IBM did not clearly entered the game and just let emerging companies share the cake? If it is so much a golden egg, such big companies should have given it a try and invest a few million on it?
For information: I exclude here IBM MDA tools (Rational tools) from the discussion, as I am talking here about tools targeting business users, and functional modeling + generation of ready to use business applications. The Rational tools are modeling tools but targeting technical users.
My thoughts there:
Any comments most welcomed!
I somehow agree with you for BL. However BL can be splitted in two:
- One part of the BL is the domain object model itself. Usually being the object oriented view of the database, and usually 90-100% generated using ORM tools. In the Microsoft world, a leading tool is LLBLGEN (http://www.llblgen.com), allowing you to do that and even customize what's generated through templates. Since LLBLGEN is the tool I know, I'll tell a bit more: it is a model-driven tool that allows the design of your business model and generation of database + BL and its mapping to the database (database aware object oriented entity model). See http://blog.walteralmeida.com/2010/12/introducing-my-favorite-orm-t... for more info
- The other part of the BL that's not easily generated (unless I agree, by using cumbersome designers), is the part that includes all the complex, business specific, business rules. And: that's really business specific! so very hard to model and generate. And yes: code is the best DSL for writing this rules!
But let's imagine a world where the only code you write is the pure business code. And no more databases to create, no more data access code, no more web services, no more user interfaces. All designed and generated + pure business code automatically integrated? This, I believe, is possible. And will dramatically help in raising the productivity, quality, manageability of software applications. I think several companies are trying to achieve this goal, probably several succeed in some means. This is something we achieved with our first version of our Fenomen tool. Of course such tools will allow you to model/generate a given kind of applications, which I will call business applications. If for instance you want to develop a technical tool like a new Eclipse or a PhotoShop like application, then a full model-driven approach generating 90% of the whole will not work or will be much harder.
But yes I agree with you: big paradigm shift! And that's a hard part: teach to the people how to work a different way. But that's a matter of presenting it right and make them understand it will help them in big ways! when that's done, they'll never move back!
IMHO, MDA tools using UML will have a hard time in convincing business people. Because this tools are targeted at technical people. Well at least it happens that it is the technical people who use UML. Business people maybe see UML as a good communication support, but will never create UML diagrams themselves. What you need is a tool, designer that's usable by business people and that can be shared between business and technical team. It is, in my opinion, the key to success of model-driven development -> let the business people become a active actor of the process, and potentially the designers, and testers and architects. You need a tool that's usable by the whole team. And them you don't have to wear a different hat: everyone works at his position but just using a common tool.
Thanks for your insightful comments!
Yes it is always a matter of compromises, and maintaining a model-driven approach, while making sure that model and code are properly and always in sync can be a hard work. Evolving a model to keep it always expressive enough to cover as much as possible of the final product, and finding a way to safely customize the result with hand-written code is not an easy task and in some cases can end up being a real pain, with lose of all initial benefits of the whole approach. + always hard on a project to ensure everyone will follow the rules and to train the new guys to do the same...
So there were bad experiences in the past restraining people to believe in this approach anymore...
But we have done a long path already. We know what does not work, we've experience the pitfalls. It is now a matter to propose a better solution and do the proper evangelism to convince again people, technical and business people.
I think we need tool support to constrain the way we do model-driven development. I mean: a developer should not have to ask himself: OK how and where do I add my business code to make the whole thing work and to make sure I won't break everything! And yes: you never can generate 100%, so we need tools that makes it very easy, straightforward and safe to add custom code, without additional cost compare to traditional development.
We should have a tool that's usable by business people, at least for the first prototype. Ideally in all iterations, for defining/modelling evolutions of the application. I think giving a business orientation of the tool is key to success!
Yes I agree with you that many of us keep doing it because we know this is the right way, and logical evolution of the software industry. It is a difficult and long path... But we should keep doing it until success ;)
Thanks for this big feedback!!
Here are my thoughts:
> We've choosen an approach of applying well defined code snippets to the model, in an organized fashion… With "organized fashion" I want to emphasize that these properties are not just glued to the core model ("hedgehog model") … but instead are organized into stereotypes, which can be derived from each other and can provide dynamic property values…
Well I cannot more agree with you. I don’t how you implement this, but yes, the concept is key: in order to model and generate the widest part of a business application and be close as possible to a 100% generation, you should have a big catalog of model elements, code snippets and maybe other artifacts that could be used and composed to create a new application. If you already have around 300-400 properties them it seems that you’ve done quite some work alreadyJ And these elements should be “intelligent” and adaptative to the context and consuming other metadata to produce the final result. The tough part being to write the tool able to expose these elements and provide the proper designers to compose them into working applications, and provide a proper way to extend the modeling elements and create new ones…
> … without having counted in detail I'd say of the amount of a traditional business layer there's about 40% infrastructure code derivable from the plain object model, another 40% derivable from additional meaningful and well defined model properties (enumerations to choose from), another 15% "injectable code" within a well defined context (like validations in class scope) and, yes, still 5% of "dirty" coding, we can live with…
Yes agreed. The challenge being to have proper tooling support to have easy way to write and integrate these 5% of code. And by the way it is no more “dirty code” because it is then pure business code, with no technical code pollutionJ We have to create these tools!
>I think it is [possible to achieve the paradigm shift]. But we must do both things: doing marketing (e.g. "Agile Modelling") and simultaneously IMPROVE our work merciless…
Totally agree. We are technical guys, but we should able to talk to business people and convince. We should market our approach.
> .. Regarding marketing and improving here, I'd like to take the opportunity to again point to our initiative "oomodels.org" …
Thanks for link, will go and have a look. However I am unfortunately a bit suspicious that standardization will work. It is the main goal of standardization that made the UML initiative lead to a complex system that’s no easy to manage and properly use, and very difficult to use for business oriented people… I think the “reusable standard” models are here to be changed: yes you can start from an existing model element, but you will in most cases have to change/adapt it, breaking right after first use the benefit of standardization (how do you them keep in sync your modified model element with changes to original model?).
IMHO what we need is proper, efficient tooling, and not necessarily standardization of the models. Tooling is key, models will come after. I think we need to be pragmatic; maybe start with model-driven tooling and platform that address a very specific/limited kind of applications? And broaden later?
And for sure: We quickly need concrete examples of applications that were done successfully using a model-driven approach. And ideally these applications should be web applications that people can try online! And that is what will convince business people (and investors): working applications that rocks with proof of why using a model-driven approach was amazing. let them play with an application and them give figures about it: how much it did cost and how long it took to create such an application. They then can do the math to see if that was interesting.
For the marketing issue, Back to initial question: why big players aren’t there yet? And why emerging companies can take the lead on the model-driven initiative? We need to have a realistic answer that can convince people that: YES what you are doing is worth it and makes sense, and YES we understand why big players don’t enter (yet) the game, and YES we want to invest on this. Any new idea after our talks?
> I would really very much like to discuss this in detail [Common business tool shared between Business and Technical teams] , I'm seriously interested, too.
I would be very happy to discuss this with you. Maybe we have the chance to meet at CG2011 if you’ll be there!
> A tool could consist of three levels (and thereby user roles): …
.. The first (business user role) might be "stereotype tagging" of an ordinary class model. … The second (business/IT communication role) might be "stereotype customizing", i.e. associating the pictures (partially project specific) to property bundles. … Finally the IT role is to make of the enrich model a good application…
Seems good, provided that you can iterate as many times as required, while always keeping consistency. I think having such a common tool for all actors or a software development project is essential and the best ever way to have good and efficient communication between teams. However it feels like it is just a dream, or very hard to put in place until today (for what I have personally seen, I understand that there are several successful projects in this direction but not the majority), so let’s change this J One very important point for success is: for the business users, the tool should be very easy to use and... not technical at all! Just business oriented. Otherwise they won’t use it, maybe dare looking at diagrams/models, but never (rarely) create the models themselves, voiding one of the main benefit of the approach
> What we would like to have is tool support to 1) generate the target code from the model without snippets, 2) tracking all relations between model snippet and code location and then 3) on-the-fly-compilation of snippets within their target context under the hood and thereby providing the modeller with immediate feedback on what he's modelling. That'll be cool.
Yes, this is a big part of the challenge for such a tool but essential for success: smooth, controlled and safe integration/sync of model + code
Agree for all your points about standardization and UML and why it has trouble in succeeding.
> Counter question: did you try it?
I must admit: No...
> Our specific plan regarding demo is to offer a service where customers can use an existing oomodels model or create one themselves, and press a button and the app is ready-made.
Yes that’s great and best way to convince. OK For demo, I am interested in seeing it!
> My summary would be: improve and proof.
> Concerning your "business tool" idea: what would be your conrete plans?
Yes absolutely. Improve and proof. And most important being: proof
IMHO, a key to success of model-driven approaches is to sell to business users, not technical users. You will probably find 10 thousands technical guys convinced by the approach. However it will be much harder to convince business owners… And without business owners convinced, the technical guys you convinced will have a hard time finding a project on which they can apply the approach… Back to starting point…
Mainly because you can’t directly sell to business owners a model-driven approach and talks to them about UML, DSL, stereotypes, reusable elements etc… they simply won’t buy it! You need to sell them a product, and promises of great ROI, and you need to be able to do a 1 hour no more demo to prove them they have interest in working with your product. And they just don’t care whatever you internally use to make your tool do its job, it could pure technical crap and spaghetti code, they’ll buy if it actually does make them earn money short term.
That’s what we are trying with our FENOMEN product. Have a look at the web-site: http://www.fenomen.pro. You’ll see it is a really business oriented presentation. No big technical words or anything that can frighten. However the Fenomen tool is internally highly technical, using a full model-driven approach and a concentration of innovations. But that’s our own little secret: the customers don’t even want or are interested in knowing more about it…
And… when several such tools perform well on the market, then can we start to give more information about how it is internally done and promote the model-driven approach.
> > ... tool ... three levels...
> Seems good, provided that you can iterate as many times as required, while always keeping consistency
Oh, these levels are not referring to phases or so, they refer to different places of "customization" in one and the same single model. So "iteration" and "consistency" is no issue - if you make a mistake somewhere, the system just stops working ;-) (and your testsuite rings the alarm siren)
> ... not technical at all! Just business oriented.
I do agree, largely. The problem is, "technical" is partially used as a synonym for "complicated" or "detailed", and "business" for "easy, simple & everyone can do it". But that's impossible. I mean, it's ok to write on the frontpage of a marketing brochure "totally easy - even your hamster can become an enterprise architect", but at the presentation meeting there should be some honesty. IT marketing has promised so much in the past and customers became totally bored and rightfully sceptic.
But maybe that was your intent anyway and to you it's a matter of course, since with an appropriate understanding (!) "business oriented" is actually the right term.
> ... need to sell [business] a product, and promises of great ROI, and you need to be able to do a 1 hour no more demo...
see detailed answer here
>...http://www.fenomen.pro. You’ll see it is a really business oriented presentation...
> No big technical words or anything that can frighten...
That's why I stopped reading ;-) ;-)
I'd like to learn more of your approach, maybe we can exchange a little in direct contact.
I've replied in your new discussion thread
And yes we can continue in direct contact. I'll send you an email. We can maybe arrange a first meeting, demos, using WebEx
"I must say I was rather disappointed by the low resonance, it should give quite some material for long discussions."
One reason for the low resonance, IMHO, is that most of us around here are MDx researchers. Therefore, we tend to only believe in our own research. I believe in ABSE, not in EM/OS. You believe in EM/OS, not in ABSE.
And because I'm too busy, like everybody else around here, I do not take time to study other approaches.
I think we can only truly measure interest if it's coming from the "outside"...
I think that percentages strongly depend on the DSL you adopt.
Anyway, it's not a matter of percentage you cover with complete code generation. The real issue is that a good MDD practitioner should know that NO MANUAL AFTERWORK should be allowed, otherwise this breaks the virtuous cycle of model-driven generation.
There are some tricks to avoid this. For instance, simplifying so much the DSL extension mechanism that it becomes convenient to add all the customization at the model level (or at the model transformation level).
We are doing this extensively with WebML (http://www.webml.org) within the webratio toolsuite (http://www.webratio.com) and the approach is quite successful. We basically get 100% code generation ALWAYS, with appalling results in terms of app quality. See only our last success story for instance:
but you may also have a look at http://www.acer.com . All 100% generated.
To Velmurugan: And it's not because there is no business logic involved. We have also several enterprise intranets/extranets and large business process implementation experiences. It's just a matter of how and where you encode the logic