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: 197

Reply to This

Replies to This Discussion

You can't say the big players aren't there yet. At least, Microsoft has been trying for years (think DSL tools and OSLO project).

 

The problem is that, because this is still unexplored territory, there is no clear path to the "right" (read, "best") MDD approach. Many are trying their own path (me and Microsoft included) and many will fail, some will succeed.

 

Anyway, big players don't need to spend money on this new ground. They will do as usual: they just let natural selection do its job, waiting for the survivors to grow and then buy them. Microsoft, being a big player, is trying because they like/try to build reality on their own terms...

Hello Rui,

 

Thanks for your feedback!

 

Well the big players have been trying yes, but did not succeed so far. The OSLO project is indeed canceled by Microsoft...

 

I am a big believer of MDD, don't get me wrong. However there are people who don't believe MDD will work and can then ask: if that's so interesting and magic, why big players don't do it? and how an unknown startup company can potentially succeed where big ones failed? This is a fair question that deserves a proper answer ...

 

I am quite sure there are reasons why the MDD tools market is a market for emerging companies (at least until a big player buy one of these small companies). I am trying to find what these reasons are. Any idea?

 

My guess is : moving to a MDD approach is a big paradigm shift that's hard to accomplish for big companies with successful development processes on place. Do you agree? can you think about other reasons?

 

 

 

 

 

 

 

"big companies with successful development processes on place"

 

Industry statistics tell a different story...

Ok fair enough :)

Said differently:

successful companies

 

No-one cares if they have a successful development process or not. What counts is if they have a successful business. And Microsoft, IBM, Google and the like are successful business wise... no matter what internal works or not

 

I think the model-driven approach will start to really grow when a company will be successful thanks to it! when businesses will really get better ROI thanks to adopting a model-driven approach. And... when the reason of this success will be made public..

 

 

 

 

And lightswitch project from microsoft

I think it is very difficult to make MDA succeed on the following grounds (but not limited to):


1. One can not model all busines processes i.e. all very low level business processes from where one can generate the code. It is also one more fact that Modeling using a Designer tool eats lots of time. In general the teams would do high level model and get onto coding. so, modeling everything would be inefficient. If everything is not modeled, generating a complete working application is close to impossible. If everything is modeled, managing that model would be too cumbersome. hence there is always a trade-off in modeling. This limits the level of code generated also.

2. Once the code / application is generated, it needs to undergo lots of changes for making it production ready i.e. with all the necessary business / functional / technical validations / rules. Not all generated code can be deployed in production immediately. I don't think that these can be generated by any tool, when they are not modeled. Could you please let me know if there are any tools that could generate the above code?

3. In general, the mostly used CRUD operations on a data model can only be generated fully or closer to 100%. Other components of the application source (such as Service Layer components, Presentation layer components, other reusable components) can not be generated fully or the % generation is very less.

4. The Software Industry is moving from Custom Developed applications to Packaged Applications (such as SAP, Siebel, etc.) to SaaS based Cloud-ed applications. With this, the need for Generated Applications is coming down. In fact the need for applications developed from scratch is growing down with the growth in packaged products. One more point is, the need for coding has significantly come down. This also impacts the success of MDA.

I think the large players would have tried it internally, encountered these issues (probably would have got more issues than mentioned above) and left it.

 

Hi Velmurugan,

 

Thanks for your feedback!

 

Here are my answers/questions:

1- Yes modeling using a designer can eat a lot of time and be ineficient. This is why to be successfull, a model-driven approach and tool MUST innovate in how to create a designer that's really helpfull and faster that directly coding

And I agree that for real-life, enterprise applications, it is hard/impossible to generate 100% of the code. Therefore to be successful, a model-driven tool must take into account the integration between a model, and hand-written code, in a smooth way, with auto-sync in both direction.

 

2- Yes, after modeling and generation of first version of an app, you need before going to production to be able to enrich/complete the application with complex, business rule, configuration settings for proper integration to the infrastructure, code for accessing external data etc. So a successful model-driven tool should allow this.

 

3- I don't fully agree with this part. There are tools that can automate close to 100% of all code including service layer and presentation components (FENOMEN is one of these tools). And same than above: the tool must then allow the addition of custom code in a smooth way.

 

4- I aggree with this point. However packaged applications like SAP for instance still require a high expertise level for concrete integration in a customer company. Deployment of such packaged solution and customization cost is high. I still think there is a space and business for a business oriented model-driven approach between custom dev on one side, and packaged solutions on the other. And even further: I think these companies like SAP would gain a lot in moving their packaged solution toward a model-driven approach, allowing an easier customization of their solution using a model-driven approach! However: huge code base to change + many developers to train..

 

Ok I get your point about why Big players might have tried it / left it. But could it be that they tried to early? I think the maturation of technologies and best practices for a successfull model driven approach is quite new...

 

Any comments on my answers?

 

 

 

 

 

One can not model all busines processes i.e. all very low level business processes from where one can generate the code.

I'd say if you can't do that, MDD is not worthwhile. Heck, I'd say it is not even MDD. If important things like business logic behaviour can't go in your models, how are models driving your development?

It is also one more fact that Modeling using a Designer tool eats lots of time.

Maybe do not use a graphical designer, but a textual notation? Graphical notations don't scale to detailed specifications, so you are going to have to use text for that aspect anyways.

Once the code / application is generated, it needs to undergo lots of changes for making it production ready i.e. with all the necessary business / functional / technical validations / rules.

Don't do that. Either model or code, don't do both. That kind of approach is what makes MDD look bad.

Could you please let me know if there are any tools that could generate the above code?

Look for executable UML tools. Check out Metacase MetaEdit+ for a DSM approach. Or check out this comment I made on another thread.

One more point is, the need for coding has significantly come down. This also impacts the success of MDA.

That is possibly true. I wrote elsewhere that RAD tools take some of the productivity edge promised by MDD away. There are still other areas MDD shines (separation of dev. time concerns from runtime concerns, targetting multiple target platforms, obsolescence-proof solutions).

Well,

 

If the idea is to use appropriate DSL for defining all aspects of a given application, then one should chose the best fit for every concern , and for writing some business rules, it can be that actual code is the proper DSL and best fit for the purpose!

 

I don't see a problem to use a mix of graphical/textual DSLs AND code. And code can somehow then be seen as a proper DSL, it is all a matter of levels of abstraction and the need for them. Idea being to be pragmatic and use what makes more sense/is more efficient for every case.  Makes senses?

 

And yes the challenge then becomes: how to properly and smoothly mix all these approaches and languages?

To Velmurugan: agree with #4. It has become common for large shops to delegate its applications definition and development to external and well known software providers, shortening its work to configurate and customize large and generic packages. In this way, it seems that "commoditizing" software has become a real option for shops whose business is not software production. Personally, I can´t belive that those elephantic software packages actually be a solution, and a return to custom development will happen, and MDD will get its place.

 

I think big players as well as customers as well as many more people can't see the benefits of MDx. And they're just right: the user sums up:

 

+ gain by speeding through automated generation

- effort to maintain tools and model

- effort to manually do the afterwork the generator could not do

 

Most often, this calculation is simply negative. Why are small and brave companies still fighting for MDx? Why do they do it for twenty years now? (1990 CASE, 2000 MDA, with ups and downs inbetween)

 

Because all brave developers know that it is just the RIGHT thing to do, no matter how long it takes. Today it looks something like this:

 

- generation of BL: 90-100%

- generation of DB: 70-90% (improved with ORMs lately)

- generaion of UI: 10-30% (CRUD at most)

- handling of transformation process: very complex, project-within-project-scenarios

- handling of model extensions (additional properties for complete app): very complex

- standardisation of model extensions: at present next to none

- integration of process/workflow (BPM): at present next to none

 

 It might be a workaround to use tools to improve the manual afterwork, but that's not the solution of the problem, it just eases the pain a bit. There's no other way than to solve all of these issues.

 

I'm sure that more or less conscious we all know that named state of he art, to such an extent, that it's hard to convince people of progress anymore, specifically customers with bad experiences with CG in the past. But even here in the MDSD network: when I joined this community a while ago I posted a description of our own efforts in this field ( http://www.modeldrivensoftware.net/forum/topics/introducing-emos ). I must say I was rather disappointed by the low resonance, it should give quite some material for long discussions. At least it might explain the behaviour of the large companies a little. If even WE here seem to have lost all enthusiasm.... ;-)

I would agree with the % of Generation in layers like DB, UI, etc.

I could not agree for BL. BL contains all the Business Rules / Logics which is very difficult for one to model which can be used to generate the code, unless you write a flow chart or activity diagrams and then use the MDx to generate code based on that. However, how many projects really develop Flow Charts or Activity Diagrams? We will limit modeling to a level that depicts the business better yet manageable. So, this level would not help in generation of teh code that can be deployed in production immediately (of course after testing).

 

If you could help me in achieving 90-100% BL Code generation, that would be really great. Looking forward to your response earnestly.

 

in case of teh other areas, i am sure we can achieve anywhere between 10-20% if we understand the underlying coding pattern and model that. however, it would be too far away from the developers thoughts.

 

The critical aspect of MDD is that, it is a paradigm shift in Sw development and needs people to wear a different hat while architecting / designing / programming and while even testing.

 

Not sure achieving this paradigm shift is going to be really possible. Can you share your thoughts in achieving this? Is there any means of Marking MDx properly?

RSS

Badge

Loading…

© 2014   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service