"I work for a PaaS company" I answered him. "Ah, okay, great", and he moved to another subject. It was a cold winter day on a hipster cloud conference. He wasn't the only one that directly knew what my company did. Most people there knew the difference between Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) and therefore knew exactly what a PaaS company did, right?
Well, not exactly... Nowadays, it's almost as broad as saying "I work for a software company". What is your point of reference when you hear the term PaaS? Heroku? Google App Engine? Force.com? Mendix? I think the popular wisdom that cloud comes in three flavors (IaaS, PaaS, SaaS) is not providing a realistic picture of the current landscape. The lines between these categories are blurring and within these categories there are numerous subcategories that describe a whole range of different approaches. I think it's time to have a closer look at the cloud landscape, to really understand what IaaS, PaaS, and SaaS are (and are not), and distinguish the different categories within. I would like to propose a framework to categorize the different approaches seen on the market today.
I'm just back from a great, relax holiday. Apart from having good quality time with my family, holiday is also a great time to immerse myself in some books. Instead of the quick information gathering I normally do by scanning my twitter timeline, quick-reading blog posts, and some more in-depth articles from time to time, I really focused on a single book for a couple of hours. Reading books really helps me to practice my ability to focus (which is necessary in today's distraction culture - being offline helps a lot by the way) and, if I read the right books, is very interesting and inspiring.
In this post I just want to share two of the books I read during my holiday, they are very different, but both interesting and inspiring in their own way.
As I briefly described in my tale of a 7 year journey in developing software for the enterprise, at Mendix every month we give employees the chance to work on anything they like and deliver it in 24 hours. We call these 24 hour hackathons “FedEx days”: build it and ship it in one day.
We normally start on Thursdays at 4pm with a kickoff during which people will team up. Dinner is arranged for everyone who wants to stay during the evening. Friday 4pm it’s time for beer and to demo the result to each other.
I really love these days. If you walk around in the office during a FedEx day you feel the vibe and during the demo’s I’m always amazed by the things that have been built. It’s energizing to see what talented people can do in just 24 hours, not just the size of a feature, but also the creativity behind it.
Let me give you 10 reasons why you should organize these FedEx days yourself (or to convince your boss to do so).
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:
