Last week I gave a talk about the lessons learned during the exponential growth of our company the last six years. I was invited to to talk at the Appsterdam meetup in Delft about "growing pains". In other words: what lessons did we learn when our company grew from 3 to 100 employees. I enjoyed the preparations as much as the actual talk, as it forced me to step back and think about the things we did and did not last years.
I covered lessons learned in four categories: company, culture, product development, and product evolution. Attempting to cover all these subject automatically means that you stay at a high level. However, I think I was able to share some valuable experiences from the trenches. It will be interesting to dive deeper in the separate categories in the future!
The slides:
I finished my last blog post by introducing a Platform-as-a-Service subcategory called "Application Delivery Platform-as-a-Service" as a way to distinguish platforms that focus on improving the entire application delivery lifecycle (and not just application development or deployment). I would like to clarify my views on Application Delivery and PaaS a bit more. My first attempt has been published on InfoQ yesterday.
The short summary: business agility is key, so focus on improving the app delivery lifecycle for maximum business value and cloud will fit in naturally (as well as agile software development, Model-Driven Development, and social collaboration).
Platform-as-a-Service (PaaS)... I guess you heard this term quite a bit last months. I wrote about PaaS earlier when arguing that Model-Driven Engineering is essential for the success of a PaaS and when I announced the new major release of our platform.
If you look at the industry perception of PaaS the main definition is something like: it is a public cloud platform where you put code in and get a service out. This is such a broad perception that it is no surprise that new subcategories are emerging every day. I will contribute to this movement by introducing a new one too...
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.
