Somehow it is a recurring theme in computer science: create a “programming” system that is easier to use and learn than the existing programming approaches. I am not just talking about better tools, like IDEs, but also new languages. It seems as if each self-respecting programmer creates his/her own language or tool-set nowadays, right?
Okay, I have to admit that not all efforts are focused on making things easier, often the focus is on productivity. However, if we, for example, look at the "programming" languages created in the Model-Driven Development there, we see quite some focus on involving domain experts in development by creating higher level, domain-specific, or sometimes even visual languages. Although there are much more reasons to do Model-Driven Development, it is the ease of use and the lower entry barrier that captures the imagination.
There is a fundamental flaw in our thinking around these approaches, though...
Much is written about lean startups, agile software development, continuous integration or even continuous deployment. All with the goal to help us understand the dynamics of successful software companies and their development teams. I am inspired by these stories, they show me what the ideal situation is like, they challenge me to improve our current way of working.
Today I want to give something back. I want to share with you our tale of developing software for the enterprise over the last 7 years at Mendix. Not to show you the "ideal situation", but to share with you the challenges we encountered in scaling our teams and in getting customers that depend their business on our App Platform. We experienced exponential growth ever since we started and much of the phases we went through are not specific for our situation, so I hope you enjoy the story and perhaps learn something from it.
It's not just IT that slows down the business. In a recent study 20% of companies reported they have NO innovation strategy and more than 50% of companies reported that their innovation strategy was mis-aligned with their business strategy and that their culture poorly supported it [1]. However, if we look at the IT side of an organization we often see the same kind of figures: 70% - 80% of IT budget is used just to run and maintain existing apps [2]. Maybe that's even explainable since starting a new IT initiative is often a bumpy road: 68% of all new software projects are NOT successful [3].
These numbers aren't new. Why do we all know them and, yet, they seem to stay the same? The interesting thing is that business nor IT is denying the current state-of-affairs. IT and business are equally frustrated about the current situation in most companies. When asked "are you happy with how IT is proactively engaging with Business Leaders to drive innovation?", 74% of the non-IT execs state they are unhappy and 70% of the IT execs [4].
It seems like it is time for change...
I think the next 3 steps will provide a way to really change these numbers...
This morning I was part of a panel at the GigaOM Structure:Europe 2012 conference in Amsterdam., titled: The Evolution of Private PaaS solutions. The abstract:
Enterprises are starting to take interest in running PaaS solutions virtually, as app developers want to focus on building apps rather than dealing with infrastructure issues. Enterprises that use PaaS solutions almost always go down the private route. In this session we focus on private PaaS offerings and look at the considerations and what will happen if one day enterprises want to use PaaS solutions in the public cloud.
The idea was to discuss private vs. public PaaS and, as it was a theme throughout the conference, the differences in adoption rates in the US vs. Europe.
I previously wrote about Enterprise Agile, not because I just want to put the "enterprise" moniker in front of everything, but because I think there are some fundamental challenges in moving to agile software development practices within enterprises, as opposed to startups.
This follow-up post is triggered by the following comment on my previous article about this subject:
Where we are struggling as an organization is the whole enterprise adopting agile. Sales and marketing expect each release to have a "big splash". Services hates the rapid iterations since they have a waterfall mindset where you accept a new release every 6 months and spent time chewing on it. I would love some pointers on resources that help move these parts of the value chain to agile. Almost everything I've read focuses on Engineering and Product management and I need to think broader.
I think this is recognizable for a lot of people. I would like to share my recent musing about this subject as I am struggling with the same kind of challenges within a fast growing company.
Earlier this year a Technet sponsored study showed that in February there were roughly 466,000 jobs in the "App Economy" in the United States. This so-called App Economy had zero jobs just 5 years ago, before the iPhone was introduced.
The term "App Economy" isn't formally defined but is often used to refer to the economy that has been created due to the development and delivery of software applications for smart-phones, tablets, and Facebook.
This App Economy was created by the introduction of new, innovative platforms. I think there are 7 ways a platform can fuel this App Economy. Not just how Facebook and the iPhone did it, but also ways to further expand this economy with new innovations in a platform or Platform-as-a-Service. Although the current App Economy is consumer-oriented, platforms for enterprise apps can and should fuel the App Economy in the same ways.
Let's jump into the 7 ways an App Platform can attract users and developers to use and build apps and therefore fuel the App Economy:
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.
