In good tradition hereby the blog overview of last year. A bit late this time, but for good reasons (see the overview of the month december).
This year I expect to write a bit more. The subjects will stay the same, and as you could sense from the posts of last year my focus will be on all phases of the application lifecycle. So, Model Driven Development will still get attention, but also cloud and Platform-as-a-Service, as well as requirements capturing, social, and agile. As my first (and only) post with video material was the second popular post last year, I will try to post more video content this year.
No, this is not a typo... I really mean Enterprise Agile, not the subject of some of my previous articles about Agile Enterprises. I hear you sigh: do you really need to put the enterprise moniker in front of everything? Although this is a fair question I think enterprise agile is not just a buzz word. Agile on a bigger scale, in a big enterprise, is different from agile in a small isolated team. I do not care if you call it enterprise agile, enterprise-class agile, agile at scale, or something else. My point is: there is a difference between an agile team in a start-up (or enterprise!), working in some sort of vacuum, and an agile team operating within the broader context of an enterprise. Let's look at some characteristics to make the difference more clear.
Companies often have more applications than the business needs. This means IT is spending resources on legacy applications instead of focusing on business innovation and growth. This years Application Landscape Report published by Capgemini concluded:
One of the top priorities of today's CIO is to build closer alignment between IT and the business. However to achieve this goal, IT first needs to deal with its own inhibitors to change. We have found that today's application landscape is often more an obstacle to successful business and IT alignment than a testament to it. As a result, first and foremost, IT needs to review its approach to the application landscape and create long-term modernization and rationalization strategies while reaping early benefits as well. Only then can a proper foundation evolve on top of which better alignment between business and IT can flourish.
If you have been wondering why I was a bit quiet lately... it was for the good cause! Today we launched the third major release of the Mendix platform, which is quite a memorable moment. My team did an awesome job and when I look at the result I can only feel proud! As I have been sharing a lot of my thoughts last years, I want to take the time to explain to you what Mendix 3.0 is all about.
If you remember one of my posts a couple of months ago, you could have seen the first glimpses of our focus with this release. In my article / presentation "Why there is no future for MDD" I tried to explain that we need more than just Model-Driven Development (MDD). What we need is an approach to the full application lifecycle, not only development. MDD is necessary (in my opinion), but not sufficient. We need Agile Application Lifecycle Management (in which MDD is one of the enablers) to solve the challenges enterprises are facing nowadays.
Mendix 3.0 (or to say it as our marketing guys like it: the version 3.0 of the Mendix Agile Business Platform) is all about supporting the agile application lifecycle, from a first idea to a working application, and from a working application to long-term business agility (i.e. the evolution of an application along with the business).
Let me take one step back and explain to you the full story of our new release. Please bear with my enthousiasm as it sometimes leads to praising my own products ;)
Model Driven Development proponents see a lot of advantages of using MDD techniques. Higher development speed, increased quality, more cost-effective, empowering less-experienced developers, just to name a few. If you look at these promises the question arises why the whole world isn't using MDD right now? Why don't we hear a lot of MDD success stories?
In a recent article I wrote about some of the main concerns which prevent people to use MDD, as mentioned in this StackExchange thread "Why aren't we all doing Model Driven Development yet?". This article triggered quite some discussion and you should definitely read the comments! I wrote this article as a warming-up for the fishbowl discussion session I hosted at Code Generation 2011 two weeks ago. In this session, titled "Making Model-Driven Software Development live up to its promise", we discussed the future of MDD in four sections, to cover subjects like popularity / marketing, creating alignment between programming and MDD, focusing on domain experts, and education. It was a great session with lively discussions and I want to share some "sound bites" with you in this post.
May 24th the first Language Workbench Competition have been held in Cambridge (UK) as a warming-up of the Code Generation conference. The idea for a language workbench competition originates from a group of people during Code Generation 2010. A lot of new initiatives in the field of language workbenches are arising to facilitate the creation of Domain Specific Languages (DSLs) and their accompanied code generators and IDEs. They all have their own strengths and weaknesses, so a competition to learn about them sounded like a great idea back in 2010... and it was!
About a month ago Kees Dijk asked a question on the programmers StackExchange titled "Why aren't we all doing model driven development yet?". He reiterates his question also as "What do you see as the biggest problems that make you not even consider model driven development?". It shouldn't be a surprise that I'm interested in these kind of questions. The answers, in this and other discussions about this subject, are interesting food for thought. Why? Because if you only read these 15 reasons why you should start doing MDD you would become curious why we aren't doing it all by now...
Let's look at some of the main concerns which prevent people to use MDD, as mentioned in this StackExchange thread.
Last year I enjoyed visiting the Code Generation conference. I presented my lessons learned in building a Model Driven Software Factory, met a lot of interesting people, and had a lot of fun. It's really interesting to share experiences with people (experts!) in the field of Model Driven Software Development. Have a look at my write-up of a Birds of a Feather (BoF) session about Code Generation vs. Model Interpretation to get an impression.
This year I will again host a session at the Code Generation conference, a Goldfish Bowl about Making Model-Driven Software Development live up to its promises:
"Business Agility", every enterprise wants to have this ability, don't they? Business Agility is the ability of an enterprise to adapt rapidly and cost efficiently in response to changes in the business environment. James McGovern stated it nicely: "Increasingly, the stability of an enterprise is rooted in its ability to be dynamic, to move fast and change quickly".
For enterprises to become agile a lot of things have to become more flexible. This doesn't only ask for changes in the structure and behaviour of an enterprise itself. As the level of automation in most enterprises is only increasing, the role of IT is an important factor in enabling business agility. However, enterprise IT isn't known for its ability to be agile...
Hence, today's question: how to build an agile enterprise?
Article highlights (for the tl;dr crowd):
- We need to simplify an enterprise to understand it, to reason about it, and to adapt it, but we shouldn't neglect its complex behaviour by linearizing it.
- We need emergent enterprise architectures focusing on the essence of the construction of an enterprise: social interaction among actors defined by transactions and rules.
- If we go down the road of emergent enterprise architectures, we will need emergent IT architectures too. Based on the definition of the parts (components with their services and events), the whole emerges.
- As changes on the service level will lead to new services or changes in the implementation of existing services, we also need agility in implementing new components and changing existing ones. To provide this agility, agile component life-cycle management is needed, rooted in model-driven techniques.
- To conclude: we need a vision on the social enterprise, focus on emergent architectures, and agile, model-driven component life-cycle management to build an agile enterprise.
Last week I visited Nantes to do an invited talk about Model Driven Development. I had a great time in France and met a lot of interesting people. The theme of my presentation was "Why there is no future for Model Driven Development", but I started my presentation by talking about the story of trying to fix a business agility problem using Model Driven Development. I also shared some lessons learned in building a Model Driven Software Factory and lessons learned in designing and growing Domain Specific Languages.
In this post I want to explain to you, using five practical examples, how I came to the conclusion that there is no future for Model Driven Development (MDD). I also included the video and slides of my presentation.
What do you think about the future of software development? Is there a future for MDD? Join the discussion in the comments!
