The Model Driven Software Network
Raise your level of abstraction
Competitive Advantage
Does Model Driven Software Engineering result in a true “competitive advantage” for an organisation? From what I have read of things promoting MDD/MDA the answer is supposed to be “yes”. However…..
Michael Porter in the article “What is Strategy” (Harvard Business Review, Nov-Dec. 1996) suggests that strategic competitive advantages comes from choices about what activities a company undertakes and the trade offs required in making those choices. A simple example is McDonalds chooses to make particular type of food, and then develops its business model around that. By choosing to sell mass produced hamburgers, they consciously choose not to compete for high class dinning.
Porter then makes a distinction between Operating Effectiveness and Fit of Activities. Operating Effectiveness is about doing the activities of an organisation better, faster, cheaper. He then says that for an individual activity it is usually easy for a competitor to emulate a specific practice if it is faster, or cheaper. Fit of Activity however is about making it harder to for competitors to emulate and compete, because they must make the same choices. If you want to make hamburgers, you either have to compete with McDonalds, or find a different hamburger market.
Fit of Activities, not Operating Effectiveness is at the heart of strategic competitive advantage. Operating Effectiveness is important, but not business strategy.
To my mind Model Driven Software Engineering is in the Operating Effectiveness category – it’s better, cheaper, faster. It will only temporarily give you an advantage over your competitors, as if we are very successful with it, then people will copy what we are doing. Unless you can find a way to link it to other activities, or better still reinforce other things you are doing well.
So, how do others see it?
Michael Porter in the article “What is Strategy” (Harvard Business Review, Nov-Dec. 1996) suggests that strategic competitive advantages comes from choices about what activities a company undertakes and the trade offs required in making those choices. A simple example is McDonalds chooses to make particular type of food, and then develops its business model around that. By choosing to sell mass produced hamburgers, they consciously choose not to compete for high class dinning.
Porter then makes a distinction between Operating Effectiveness and Fit of Activities. Operating Effectiveness is about doing the activities of an organisation better, faster, cheaper. He then says that for an individual activity it is usually easy for a competitor to emulate a specific practice if it is faster, or cheaper. Fit of Activity however is about making it harder to for competitors to emulate and compete, because they must make the same choices. If you want to make hamburgers, you either have to compete with McDonalds, or find a different hamburger market.
Fit of Activities, not Operating Effectiveness is at the heart of strategic competitive advantage. Operating Effectiveness is important, but not business strategy.
To my mind Model Driven Software Engineering is in the Operating Effectiveness category – it’s better, cheaper, faster. It will only temporarily give you an advantage over your competitors, as if we are very successful with it, then people will copy what we are doing. Unless you can find a way to link it to other activities, or better still reinforce other things you are doing well.
So, how do others see it?
Views: 24
Replies to This Discussion
-
Permalink Reply by Jorge Ubeda on -
It depends on your focus, in my opinion. It´s important to make a difference if your business is Software Engineering, building tools or selling consultancy. If your business is outside and is looking for better ways for building your business applications, ever will require such kind of tools and point of view. For the business world, the MDD adoption is only real for a very little part of participants, far of a clear dominance from some product.
-
Permalink Reply by Sean Kavanagh on -
A very interesting observation. It highlights the fact that using MDD simply to make a specific project more efficient or better in some way is not an end in itself. MDD only becomes a strategic advantage when a whole software department (or organisation) embraces MDD enabling reuse across all the projects within the department. However, many projects using MDD are embracing DSLs in very project specific ways which may make department wide adoption more difficult, i.e. the department may end up swimming in DSLs increasing reuse costs. My own preference is to use a generic Action Language rather than a DSL for MDD.
-
Permalink Reply by Juha-Pekka Tolvanen on -
The reason why most DSLs are not public is exactly the fit of activities as Michael described it. For the same reason we at MetaCase can only show screenshots of the languages created (as about 20 cases here: http://www.metacase.com/cases/dsm_examples.html) or make them available as simplified versions. Releasing code generators is even more difficult as that would show how data is accessed from models (metadata) and what the produced results look like. So it’s a bit like releasing your source code, architecture and the way how you are using underlying frameworks at the same time. Based on our experience this makes sense when you outsource development and give the DSL for your supplier or you have a project that is configured or extended with the DSL. In the former case the DSL is not really public and in the latter case the DSL is scoped so that it revels only what the company wants to show.
To Sean:
1. There is no need to share a DSL within the whole company, as the particular language is most likely useless in other domains within the company. So there are no things to reuse either. Instead the other project could consider defining their own DSL for the domain they are working with.
2. In my opinion the challenge with generic Action Language is that it does not raise the level of abstraction nor guide developers within the particular domain.
© 2012 Created by Mark Dalgarno.
Powered by 
.
