Walter Almeida's Blog

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 (having created FENOMEN) 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. An example of a company building such business oriented model-driven platforms is FENOMEN.

Here are my own thoughts, and I would be very keen on having your comments and thoughts on the matter!

Why big ISV players do not use a Model-Driven approach for their own products development?

First of all, even though we have been hearing about model-driven development for many years now, a full model-driven / model-centric process is still quite a new approach and you see only a few companies largely adopting it. And main reason is we just start to having matured enough technologies and practices to enable a really efficient model-driven approach. And it is now that model-driven tool vendors of today are competing for being the big players of tomorrow!

Today’s big ISV players like Microsoft, IBM and Google are well-established companies, with a highly technical background and spirit and with well-established and efficient development processes and methodologies. A fully model-driven approach to software development is a huge paradigm shift from a classical development process, and why (and most important: How?) would you want  to apply such a big-bang on a company that has already performed well for so many years and knows how to do it well? Well change is good, and they will probably change, but they have a huge code base and millions of engineers to train, and change management is costly. So a fast and large move is not an option and too high risk. 

Well, actually they probably already do use some model-driven tools for their own internal use. At least tools and technics that help better the productivity of the developments. However these tools remain internal to their teams and used for very specific parts of their developments. For instance Microsoft built and uses a templating and code generation engine (T4 templates), extensively used as part of Visual Studio environment and used for instance to generate code for user interfaces and web services proxies. 

 

Why big ISV players did not create model-driven tools for their customers?

 As we already said: moving from a classical, code-centric approach toward a model-driven / model-centric approach to software development is a huge paradigm shift. If a company wants to build model-driven tools, they should already have applied these new concepts to themselves. A model-driven approach is not something you can theoretically lay down on a paper without previous concrete experience. While the basic concepts can appear as simple: you create a meaningful and extensive meta-model and you generate code from the model (or interpret the model), the practical application is not that easy and you have to learn the pitfalls and best practices by actually doing it yourself.

This is the “eat your own dog food principle”, so dear to Microsoft and so essential for our matter. So: big players will be in a position to develop model-driven platforms and tools for their customers when and only when they will have made the paradigm shift themselves and become experts on the matter. This is why IMHO, the leading model-driven tools of today are developed by emerging, new companies.  Leaving an option for big players to enter the game which is to buy one of these successful companies!

A word about OSLO: the Microsoft attempt to enter the Model-Driven game

A few years back, Microsoft announced their commitment to a new set of technologies: M and the OSLO platform. 

M is known as a declarative language that provides developers with an approachable, textual format for authoring models and domain-specific languages (DSLs) for those models. In other words: M is a language for creating custom, domain-specific languages.

OSLO was initially supposed to be a platform to model and host business application, with the support of M language and a SQL Server back-end. It was therefore supposed to be a full model-driven business platform.

OSLO was then renamed SQL Server Modeling Project, changing the focus of the platform from a generic model-driven business platform targeting any kind of end-user business application, to a SQL Server specific tool for modeling databases. The target user base therefore moved from business users to… architects and developers! That was the end of OSLO as a true model-driven business platform for building business applications! Why? In my opinion, probably partly because of the reasons explained above. And also because Microsoft first business is to sell server applications, SQL Server being on of their golden eggs. So they did not miss an opportunity to refocus OSLO as an extra layer on top of SQL Server, for the benefits of their SQL Server customers base.

End 2010: Microsoft cancelled the OSLO/SQL Server Modeling project, driver for cancelling being: low anticipated market demand. My own guess being that the refocus of OSLO killed OSLO: OSLO primary goal really was to build a model-driven platform for building business applications. The refocus was maybe done because of an internal failure of implementing the full model-driven platform (reasons above). However the refocus was done on a business need that was not primarily identified as such… 

Remains: M as a language. Which is fair enough: It is part of Microsoft business to build languages and they already are successful on this market with their range of Microsoft.NET languages. So we can conclude that it is not an easy task, even for big players, to try to extend their business model to new areas…

Any comments are most welcome!

[EDIT] : I posted the same discussion on the Model Driven Software network, you can see the full discussion and many comments/feedback there:

http://www.modeldrivensoftware.net/forum/topics/the-new-goldenegg-modeldriven

And also another interesting discussion on the matter:

http://www.modeldrivensoftware.net/forum/topics/agile-business-application

Fenomen's brand new Web Site is now available!

We are proud and happy to annouce the public availability of our brand new Web Site : http://www.fenomen.pro, available in french and english.

Feel free to visit our Web Site to find more about FENOMEN and our innovative approach for building connected business applications following a full modeling and generation approach.

via blog.fenomen.pro

Model Driven Development: Code Generation or Model Interpretation?

During Code Generation 2010, I was part of a Birds of a Feather (BoF) session about Code Generation versus Model Interpretation. You can read the feedback from Johan den Haan here:

Model Driven Development: Code Generation or Model Interpretation

Followed by an interresting online discussion on the subject.

The case for Model Driven Software Development (Part 2) Developing high quality, well designed software applications is hard and expensive – MDSD can help!

In the first part of this series, I gave a quick introduction of the MDSD approach. Let's now enter in more details. I will explain here one of the main motivations of going for the model driven paradigm shift or: how a model driven approach can dramatically help make developing high quality software faster and easier. 

Part 1: Toward generative programming? The case for Model Driven Software Development: A quick overview of the MDSD approach

Part 2: The case for Model Driven Software Development - Developing high quality, well designed software applications is hard and expensive – MDSD can help!

Developing high quality, well designed software applications is hard and expensive 

The benefits of designing and implementing applications using a proper layered architecture approach, good separation of concerns, relevant design patterns to make the solution flexible, extensible and maintainable are not to be proven anymore and is a common understanding in the industry. However designing and implementing high quality software this way does take time and is expensive. And this will NOT help you deliver faster. YES you will produce better quality software but it will not necessarily make you more productive, at least not in the short term. It does not mean you should develop bad quality software and YES developing quality software with good design practices will in the medium/long term range be VERY profitable and even open windows for extra evolutions you did not even thought of up-front. But it can prove very difficult to sell quality practices for short projects where the extra cost and time involved for doing a state of the art design up-front will be overkill. And not only the design but also the implementation phase on a highly engineered application can cost you extra resources and time. If you indeed have a layered architecture, then implementing a new functionality will most probably involve writing code in all layers. And if you have designed your application using design patterns, then you will probably have to regularly create a set of new classes for any new feature in your application. A good example is the MVP pattern: for any new user interface you want to include, you have to create not one but at least three classes for that matter.

   

Maintaining a software application is expensive

Many studies state that the TCO (Total Cost of ownership) of a software application for a big part due to maintenance and evolution AFTER deployment to production! This means that what is expensive is not so much the development of an application but its exploitation and maintenance over time.

Implementing a well-designed, state-of-the-art application requires validation and any new development should go through a full validation process, may it be manual (peer reviews), automatic, or both. Don't do that and you can be sure that your quality will degrade rather quickly with time, and inconsistency and hacks will be introduced in your design. And the more engineered your software application is, the more difficult will it be to keep it this way and not introduce bad practices or hacks in the design, which could prove disastrous in the long term. Yes you can document your technical architecture and design principles but it means that it is again extra cost involved, thus increasing the TCO of your application. Moreover you need to find a way to keep the knowledge and know-how in the company and make sure that any person leaving the company does not do so before a proper knowledge transfer inside the company…

On the other hand, a poorly designed software application will most probably cost even more to maintain and evolve. And maintenance and evolution of such an application can to some extend become so difficult that no-one dares touching too much the code base, thus decreasing the ability for the application to evolve and decreasing the application users' satisfaction.

The case for the model driven approach: make quality easy and cost effective

YES it is very frustrating when a client tells you that he understands where you come from with your idea of writing state of the art, well engineered solutions, but that unfortunately for his project he just wants something delivered fast and at a reasonable price. And unfortunately this scenario is not uncommon. So what to do? Forget your dreams to create great designs and develop applications as they should be? Forget about the benefits of well designed quality software solutions for your clients with low budget or working with tough time constraints?

Well this is where proper tooling and especially the model driven approach can help in this direction. Because a properly targeted DSL and associated tools can eliminate the extra effort required to develop a highly engineered solution by automating the creation of all the classes, components and other artifacts required to full-fill the application design. Of course what requires (a lot of) time is the writing of the DSLs and associated tools that you need. However this work will then be reusable for all the features of the application, for the evolutions of the application and for future projects. This makes the initial investment very profitable, not only long-term on the initial project, but even short term for the actual project and for any new project starting. One way to overpass the extra cost involved in writing the DSLs and tools is to find on the market existing DSLs or at least existing tools that can help you quick-start the writing of your own DSLs. Finding already existing functional DSLs that suit your business is hard as any business has its own specificities and rules. However finding a technical DSL is easier as they are reusable horizontally across domains. And I will again give the example of a now very common and well known DSL: the ORM tools. But other more advanced tools exist to generate more than just the database access and persistence part of the application.

   

The case for the model driven approach: reduce the TCO by reducing maintenance costs  

One more benefit of using a DSL approach is also the following: when you are using a DSL to model and generate parts or all of your application, then evolutions of the application will be implemented by changing the model and re-generating the application. Therefore you (almost) don't have the risk to degrade your design quality by not respecting the architectural rules. And you don't need the extra validation step to make sure the evolutions are implemented respectful of the original design principals of your architecture. This is because the design rules are enforced by the DSL itself and the code generation process! Therefore a successful model driven strategy will also result in reducing the total cost of ownership by dramatically reducing the cost of maintenance and evolutions and even further: enforce the software quality in the long term.

We therefore talked about what I consider being the main motivation for adopting the model driven software development approach: the MDSD approach enables the cost effective implementation of high quality, highly engineered software applications while dramatically reducing the maintenance and evolution costs and enforcing the application quality and stability in the long term.

I will keep writing more on the model driven approach, so stay in touch if you like the topic and enjoyed the reading!

Toward generative programming? The case for Model Driven Software Development (Part 1): A quick overview of the MDSD approach.

I am starting now a series of posts on the Model Driven Software Development (MDSD) approach. The reason is that I strongly believe it is a very powerful approach and I will invest time and efforts in 2009 in this direction. There are already tools that are following this approach and probably one of the most compelling success stories is the ORM tools. There are also things going on in the industry and for instance Microsoft is planning to follow the model driven path with its OSLO platform and the M language, so I will also be talking about this.    

The first post of the series is a quick overview of the MDSD approach. The objective here is not to do a full presentation of this software development paradigm but introduce the subject, key terms and overall principles. I will in further posts analyze and foresee what benefits could bring MDSD to the software industry and what place this might have in the future.

Part 1: Toward generative programming? The case for Model Driven Software Development: A quick overview of the MDSD approach

Part 2: The case for Model Driven Software Development - Developing high quality, well designed software applications is hard and expensive – MDSD can help!

 

MDA versus MDSD   

In order to briefly explain what the model driven approach is, it is interesting to start explaining what the Model Driven Architecture (MDA) approach is and how it differs with a more permissive and flexible MDSD (Model Driven Software Development) approach.       

The MDA approach is an initiative of the Object Management Group (OMG), and is a natural evolution after the introduction of the UML language and its relatively wide adoption on the market. The MDA approach aims at providing a generic, model oriented, tools friendly language that could be used to automate the generation of software applications through the creation of platform independent models and diagrams. This generative implementation is supposed to be done through MDA tools, able to parse the platform independent MDA model and generate code and artifacts for the targeted platform.     

One primary objective of the MDA approach is the platform independence and a universal generic language to describe systems, the same way UML was designed to be generic enough to be usable to describe the different architectural views of a software system, and even potentially apply beyond software systems.     

While this generic MDA approach has the definite benefit of the universality of a language that anyone, and any tool could understand and exploit, it also has its drawbacks. The main drawback being that a too generic and universal language can be too much abstracted from the real system and its specificities. Extensions of the UML language such as stereotypes were invented to solve this problem but make the whole exercise of precisely diagramming a system very difficult to achieve. And the precision and level of details required for a generative approach is of crucial importance, much more than for creating diagrams for the sole purpose of communication and documentation.   

I personally am a big believer of more pragmatic approaches that aim at giving a clearer, less abstracted vision, but closer to the reality of the system. After all, the primary objective is to build systems that work and is not to have a generic description of systems for just the sake of purity. This is for me the reason why the MDA approach was not as successful and broadly used as expected and the driving force why a more permissive and flexible MDSD approach has a much better chance to succeed and convince the community and the market. 

From now on, we will talk about the Model Driven Software Development (MDSD) approach as a generic term that applies to any solution, tools or processes that follow the model driven concept of modeling an application for the purpose of automating its implementation. The MDA approach in this perspective is a MDSD approach that has the specificity of being tightly coupled to, and constrained by the UML language.

So the generic MDSD approach we describe here differs from the MDA approach in that there is not such a thing as a ready to use, generic MDSD approach and associated languages that you can use out of the box on your projects. The MDSD approach is more of a concept, a guidance and new way/philosophy to see software development. So where there is only one MDA standardized set of languages, there are not only one but as many different MDSD tools and processes as vendors or individuals will invest on creating.

   

Domain Specific Languages (DSL) and MDSD 

Let's now have a word on the Domain Specific Language (DSL) terminology. The DSL acronym is often misleadingly used for describing a full model driven approach. However a domain specific language is not really a model driven approach on its own but only a part of a full MDSD approach. The MDSD approach is more than just languages, it is a full set of languages (and more specifically DSLs), tools, runtime frameworks, code generators and/or language interpreters (more on compiled versus interpreted DSL later), on potentially more.    

Therefore DSLs are a major part of (and only a part of) the model driven approach. A DSL is an abstracted language that aims at describing a system or part of a system that we want to model in the most convenient and natural way for the targeted domain. A DSL can take any form as best suited for the targeted domain, can be textual, graphical or both or even take another exotic form.   

A DSL can be architecture oriented of functional oriented. An architecture oriented DSL aims at describing technical layers or architecture centric components and services of your application. A very common example of an architecture oriented DSL are the Object Relational Mapping tools (see the description of Llblgen for an example of such a tool). An architecture oriented DSL can be used horizontally across different functional domains. A functional DSL is a DSL that is explicitly dedicated for a given functional domain and an example can be FpML, used to model financial instruments. Functional DSLs provide business analysts with a proper abstraction level to describe their very specific domain that can then translate to code (the dream of having analysts or business specialists designing applications with no more need for developers...), or more realistically functional DSLs provide developers with a language that can help then translate functional models to applications and code.      

And finally DSLs can be interpreted or compiled. A model written in an interpreted DSL is used "as is" in the real production application, hosted by a runtime (interpreter) able to understand the model and execute operations. In my very basic understanding the M Language (Microsoft OSLO) can partly be used as such an interpreted DSL (more on OSLO on a later post). On the other hand, for compiled DSL, a model has to go through a compilation phase for transformation of the model to a lower level language, such as C# for the Microsoft platform. An example of such a compiled DSL again is the Llblgen ORM tool. It is pretty clear that compiled and interpreted DSL are very different in nature and imply very different constraints.   

In the model driven approach, the DSL or set of DSLs is the way to describe the model of the application you are aiming at implementing. Defining the model of your application is the first step in the model driven approach, followed by the generation activity, or interpretation of the model (more later on compiled versus interpreted DSLs).

   

Generators and Interpreters

The second brick of the model driven approach is the generator(s) and/or interpreter(s). The generators responsibility is to generate from the model anything you need for your specific domain. Artifacts that are useful to be generated range from code to configuration files though user manual, or anything you might dream of automating. Generation can be based on text templates that are useful to customize or extend the content of the generation. On the other hand, interpreters don't generate anything but rather interpret at runtime the models to deliver the required application functionality. A model driven approach can make use of a runtime framework. The final application will then use at runtime the support libraries that make up the framework. This is especially true and mandatory for the interpreted approach but also true for the generative approach. It indeed often proves useful to generate code and classes that are depending and built on top of a well designed and fully featured framework rather than generate the full application code base. This runtime support framework is the third brick of the MDSD approach.   

The fourth brick on a full MDSD approach would be the SDK that allows users of the DSL and generators/interpreters to extend or automate the DSL and generators/interpreters, from instantiation of a model to generation of the application, through integration with other DSLs. I will in a later post talk about DSLs composition and DSL integration with other approaches and tools, to bring the model driven approach even further.

    

That's enough for this quick introduction. Hope it was clear enough, and I will enter in more details in further posts. I will talk more in next posts on the motivations behind the model driven approach and why MDSD is good for you!

And here are a few links to resources related to the model driven approach:

MDA web site: http://www.omg.org/mda/

Microsoft OSLO web site: http://www.microsoft.com/soa/products/oslo.aspx

Podcasts related to the model driven approach:

Software Engineering radio shows on MDSD

Software Engineering radio shows on DSLs