The Model Driven Software Network

Raise your level of abstraction

The new Golden-Egg : Model-Driven Business Platforms – Why big players aren’t there yet?

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:

http://blog.walteralmeida.com/2011/01/the-new-golden-egg-model-driv...

 

Any comments most welcomed!

Views: 358

Reply to This

Replies to This Discussion

Hello Velmurugan,

 

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.

 

 

Hi Andreas,

 

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 ;)

 

 

 

Velmurugan:
> Business Rules / Logics which is very difficult for one to model...
> ...Flow Charts or Activity Diagrams? ...

Walter:
> The other part of the BL that's not easily generated ... that's really business specific! so very hard to model and generate. And yes: code is the best DSL for writing this rules!

Yes, quite true. My BL % referred simply to what is doable today from the perspective of the outcome, no matter how it came in ;-) I would not propose to draw charts etc. or to "code" in OCL just everything; except for certain special scenarios where this can be helpful - neither would I recommend to modify the generated code (too much pain, hooks, merging, semantic context, cvs/svn mess etc. etc.)

Velmurugan:
> If you could help me in achieving 90-100% BL Code generation...

We've choosen an approach of applying well defined code snippets to the model, in an organized fashion. Examples are validation expression for attributes, classes etc., or operation implementation code. But it's more than just "opening the floot gates for coding" - 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.

With "organized fashion" I want to emphasize that these properties are not just glued to the core model ("hedgehog model") with thousands of values per model element (or sticked to a generation model, which hides the problem, but does not solve it), but instead are organized into stereotypes, which can be derived from each other and can provide dynamic property values which calculate their value from the class context to which the stereotype is applied. In numbers: we have currently something around 300-400 properties, organized into about 30 "property" classes, grouped togehter ino a hierarchy of about 70 stereotypes. In a typical model, each class has 1 (or 2, or 3) stereotypes plus about 0-3 properties per class and attribute, which is a justifiable number in my opinion.

> ...it would be too far away from the developers thoughts... it is a paradigm shift...different hat while architecting...

Yes, I do think so, too. But I think this is intermangled with "substance" behind it. Of course, developers are almost always rather skeptic regarding "innovations" they did not invent themselves. Too a large extent, I'd say rightfully, since it's a complex matter. On the other hand side, developers smell good stuff miles against the wind and join the company with delight, if it's a good one. But MDx is out there for twenty (even more) years, so there must be a real problem behind.

> Not sure achieving this paradigm shift is going to be really possible.

I think it is. But we must do both things: doing marketing (e.g. "Agile Modelling") and simultaneously IMPROVE our work merciless: it does not help to betry ourselves, if the produced solutions are incomplete, they are incomplete, and the customer will discover they're incomplete. It does not help to say, this MDx, and then add that after generating you have to "fine tune" your UI when in fact you have to nearly completely code it yourself to get an acceptable result.

Regarding marketing and improving here, I'd like to take the opportunity to again point to our initiative "oomodels.org" and invite everyone to participate. This is an open model repository where we can really join forces and work on models together with all of our tools, if it works we can provide the world an impressive showcase of MDx ("wikipedia for business models, just download yours"). Don't be shy, I'd say NOONE here can show a really 100% FMD (fully model driven) solution. Let us change that.

Walter:
> ...tools using UML will have a hard time in convincing business people. Because this tools are targeted at technical people...

Uhhhh...

> ...Well at least it happens that it is the technical people who use UML...

...good you added that. I'd say it's "complexity" that invokes fear, and UML unfortunately became the psycholigical projection target of that fear.

>...can be shared between business and technical team...

Yes, much ageed.

But: it is NOT an easy thing. E.g. saying business uses BPMN and IT "translates" it into UML is (IMHO) pure nonsense.

Walter:
> 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.

mmh.. yes. So, how long has the road been, how long is it still?

> 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 think so, too, but at the same time I'm rather sure that a proprietary solution for such an editor would only be the second best choice. I know from sales people that closedness with regard to models is a major concern of customers. The first, second and third question is always "can you import/export UML".

I would really very much like to discuss this in detail, I'm seriously interested, too.

I'd throw in these things into the discussion:

- the UBPML (ubpml.org) to integrate process with classes ("BPMN and UML"), with the clear goal of being able to create unfied single source models which can be viewed from Business and IT persepctives and provide means of encapsulating details with e.g. OO techniques

- the model repository oomodels.org which could be used by us as a benchmark system to support our claims with facts; ideally we could show our generated solutions online that are based on respective models; I'm pretty sure that THAT would convince many people

Currently models are entered as text in a compact and tiny "Wiki Modelling Language" http://www.oomodels.org/index.php/Type:org/oomodels/WIML/1.0 (and yes (!), we can draw diagrams, too :-)
http://www.oomodels.org/index.php/Artefact:Diagram/net/leue/andreas... )

For developers, that might be ok, for business people it's not. So the oomodels wiki could be used as a groundbase to provide a better, more business friendly editor on top. That's just a thought and at least we plan to do this with respect to our properties and stereotypes.

- maybe interesting is the stereotype mechanism mentioned above; I cannot share all details of that, since it's not par of open source (yet), but some of the more general properties might be worth a discussion since this materials should become open and standardized, for sure


Hi Andreas,

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!


 

Hi Walter,

> ...big catalog of model elements...
> The tough part ... expose these elements ... proper designers... proper way to extend...

If the goal is not to build the one-size-fits-all-sorrow-free-business-tool (which is impossible, anyway), it need not be too difficult. 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. That could be made more userfriendly by e.g. using icons, images or alike per stereotype. The names have to be choosen carefully (project specific, DSL mindset). This would be a kind of "Business Lego Level".

The second (business/IT communication role) might be "stereotype customizing", i.e. associating the pictures (partially project specific) to property bundles. Required skills would comprise understanding of business as well as IT. After stereotypes become more and more mature, the job of this role might become less amountful.

Finally the IT role is to make of the enrich model a good application. That's what we do with MDx today anyway.

If you like, I can share more details of our extended stereotype based approach.

> ...proper tooling support ... write and integrate these 5% of [dirty BL] code...

At present, we allow to inject snippets defined in the model into the resulting code. We provide a little preprocessing magic to shield the modeller from too deep details (optionally). 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.

> > ...oomodels.org...
> ...suspicious that standardization will work...

Well, I do understand these concerns very much. It simply didn't work so far.

> ...standardization that made the UML initiative lead to a complex system...

I think UML is an unlucky example, since there wasn't actually much innovation in the last years, it just became a large collection of "everything", poorly unified (in the beginning that was quite different). That's why most projects only use these 15% UML from the early phase (class diagrams, state machines, not much more). Plain combination just for the sake of having any standard does not make a good standard.

But look at SAP. They have tens of thousands of predefined tables and live very well from selling them plus customization. If you ask any MDx provider, you look into black empty space. Oh yes, we have, err, 2 predefined models, user management and, errm, a blog app demo. Maybe that's exaggerated, but it points to a significiant difference between both worlds.

Tenthousand open model classes to be usable as a start for our projects would certainly alone be enough.

Plus: is it really true we can't do better?

Why is it so hard to reuse models? I dare to say: because reusage-technology is still insufficient, partially because people quitted believing in it. Around '95 POET, one of the few object-oriented database providers then, had a feature to extend schemas by just defining derived schemas, making uncompromised use of object oriented principles. How cool was that? The customer could take an application from some provider in binary form, and extend it at his wish. Where are we today? The eclipselink ORM (eclipse's JPA implementation) does not even allow to combine multiple schemas at runtime at all, not to speak of binary extending, all mappings need to be defined within one file!

How does it come, that in '95 technology is there which in 2010 gets forgotten? My guess: that feature alone is just of no use to the customer if the other tools he has to work with aren't equally capable. And they mostly still aren't. A half solution is no solution to the customer.

So that is the reason why we have to:

> ...“reusable standard” models are here to be changed...
> ...start from existing... in most cases have to change/adapt it...

and why it is difficult to:

> ...keep in sync ...with... original model?

With MDx technology, we have a fresh new opportunity to address this problem again. Even if the runtime does not support all of our wishes, our MDx can do so. We can refer to a basic model and then derive the specific parts from it. No need to sync, no need to adapt. A dream? Counter question: did you try it?

> ... efficient model-driven tooling [vs.] standardization of models ...
> ... very specific/limited kind of applications? And broaden later? ...

For once, I'd like to quote Dilbert's boss: Let's do both! ;-)

> ...will convince ...: working applications that rocks with proof of why using a model-driven approach was amazing.

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. Technically that works already (if someone is interested I am pleased to arrange a private demo), our major problems are (unsurprisingly) error handling and server misuse.

> ...marketing issue... Any new idea after our talks?

My summary would be: improve and proof.

Concerning your "business tool" idea: what would be your conrete plans?

Hi Andreas!

 

> 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.

 

Makes sense?

 


> > ... 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.

Hi Andreas,

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"...

Very insightful and honest response, Rui.
> ...believe in our own research...

The existence of the whole forum is a counterexample. What separates ABSE from EM/OS is not ivory tower mentality, but the .net/Java-gap - conceptually there'd be very practical synergies possible. We favor an open source and open standards based, component oriented approach, giving the customer a real choice between different approaches, the freedom to kick us out of the window in favor of a competitor, and to combine solutions at his wish.

> I think we can only truly measure interest if it's coming from the "outside"...

But to get interest from the "big" outside, the market needs to be sufficiently mature. Signs of maturity are the existence of (ideally open) (quasi) standards or if only one competitor is left with a winning solution. The second is at present far out of reach (if desirable at all), the first is an option we can work on.

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:

http://www.webratio.com/portal/newsPage/en/News%20Archive/3032?alt7...

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

RSS

Badge

Loading…

© 2018   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service