The Need to Focus on App Delivery Lifecycle in PaaS
Cloud is the next best thing since sliced bread, isn’t it? It increases responsiveness, gives a business agility, and it enables new business models. Well, it seems not. Nearly three-quarters (74 per cent) of UK IT managers think that cloud computing has no relevance to their business. Is it fear? Are security and privacy concerns the main barriers for cloud adoption as stems from most related surveys? Or should we ask the CEO instead of the CIO?
Apparently there is a mismatch between expectations (or promises) around cloud and how a large group of people perceive it. My conclusion? We should just stop talking about cloud. It doesn’t help your business, cloud is irrelevant! Let’s explore why.
What is “cloud”?
Before doing so we need to demystify the term “cloud” as it is used for everything but the kitchen sink nowadays. What most people agree about is that you can distinguish three main cloud layers, which I explained previously:
- Infrastructure-as-a-Service (IaaS): typically a platform virtualization environment. Instead of purchasing hardware, datacenter space, and network equipment, clients buy these infrastructures as a fully outsourced service. In principle IaaS is an abstraction layer on top of hardware.
- Platform-as-a-Service (Paas): a computing platform or solution stack provided as a service. It facilitates deployment of applications without the cost and complexity of buying and managing the underlying hardware and software layers.
- Software-as-a-Service (SaaS): a model of software deployment whereby a provider licenses an application to customers for use as a service. The software is hosted by a service provider.
Sean Ludwig recently described them much better and visualized the main layers of cloud in a nice chart, as shown in Figure 1. He also mentions some examples in his article to further clarify the distinction.
Figure 1 - An explanation of the three main layers of cloud computing (source)
Where most people disagree is where to put which service and what subcategories exist within this trichotomy. A lot can be said on this subject, I think the market needs some additional years to settle the different categories and to somehow agree on them. But let’s first analyze what a business actually needs before we start juggling and discussing all kinds of cloud related terms. In the end it’s all about business value.
What a business needs
Nowadays when people talk about cloud, be it about advantages or concerns, they mostly talk about IaaS. And yes, there are some nice examples of consumer businesses running their stuff on Amazon, thereby being able to dynamically scale their infrastructure. The question is if such a setup is relevant for the agility of an enterprise business.
I think it is of no question that business agility is relevant. For most enterprises the ability to adapt rapidly and cost efficiently in response to changes in the business environment becomes more and more important in the current competitive market. Time-to-market of new products, processes, and services is key to the survival of enterprises.
Since the level of automation in most enterprises is only increasing, almost every business change will lead to a change in the application landscape. Hence, the role of IT is an important factor in enabling business agility. An enterprise is in a huge need of apps that perfectly fit in the business. These apps need to have a short time-to-market and have to be flexible to evolve along with the business. This means the full lifecycle of such applications, from the initial idea to first deployment, and from that first deployment to long-term evolution, needs to be as agile as possible.
This is more difficult than it sounds. According to the Chaos Report 2010 by the Standish Group a staggering 68% of all new software projects are NOT successful. According to the same report the top reasons for project failure are lack of user involvement, incomplete requirements, and changing requirements.
I think the only way to successfully create applications truly fitting in the business is to create them in close collaboration with the business. The Manifesto for Agile Software Development rightfully emphasizes customer collaboration as an important pillar for better software development. We need to put more focus on business value, we need to engage with endusers, we need to collaborate with business owners. If possible we should even co-create apps with the business, put the business in the driver seat!
If a successful enterprise needs to continuously re-invent itself, thereby asking for changes in the app landscape, it is important to be able to evolve this landscape with small iterations. I am all in favor of building on top of existing capital to make new initiatives feasible from both a technical and cost perspective. Do not, for example, try to replace your ERP system with something more flexible, but use it for your commoditized processes and automate your differentiating business processes with a more flexible approach.
So, what does a business need? Apps that perfectly fit the business! Delivered by a process rooted in agility, flexibility, end-user engagement, collaboration, and co-creation... all on top of your existing systems. A nice wish list, but how to achieve it?
How a platform can deliver
We can pretend we are thinking about something new here, but delivering software in an easier, faster way by domain experts instead of highly skilled programmers has been the holy grail for ages. We have seen successful attempts to create higher-level programming languages, as well as partly successful CASE tools. The last couple of years, Model-Driven Development (or Model Driven Engineering) has received more and more attention. Model-Driven Development has a number of compelling reasons to start using it, and there is an increasing number of success stories. The use of visual models to drive app development fulfills most of our wishes for speed, flexibility, and the possibility to increase the collaboration between business and IT, as these visual models are a good communication mechanism and are automatically converted into working software.
Although I think Model-Driven Development (MDD) is a necessary ingredient to fulfil the needs of a business, it is not sufficient. I explained this last year in detail in an article titled “Why there is no future for Model-Driven Development”. Once the development of applications has been optimized with something like MDD other bottlenecks will pop up. Deploying applications and taking them in production can actually take more time than development. Additionally, translating a business problem into a model of a solution solving that problem is more often the main challenge than actual development. All this isn’t bad, don’t get me wrong, but it asks for a broader approach than just MDD.
If we want to achieve our wish list described above, we need to focus on all the phases in the life of an application. As we stated in the previous section, the full lifecycle of an application, from the initial idea to first deployment, and from that first deployment to long-term evolution, needs to be as agile as possible. This means we need a platform to enable full application lifecycle management (ALM). ALM is a continuous process of managing the life of an application through all its phases. ALM tools need to facilitate and integrate requirements and release management, development, deployment, maintenance, etc.
Figure 2 - the App Delivery Lifecycle
Figure 2 shows four important phases in the, what I would like to call, App Delivery Lifecycle. The phase at the top is about requirements capturing as a collaborative process among all stakeholders. This collaboration is continued in the next phase when the new ideas and requirements are converted into models or existing model templates are selected to fulfil the wishes of the stakeholders. In this phase the focus is on highly productive, collaborative development using visual models. These models are 1-click deployed to a runtime environment where they are executed and become real apps. The key in successful app delivery is to continue to the next phase to engage with users, listen to their feedback, and use that feedback to come up with new requirements, thereby continuing the next cycle.
I did not add numbers to the phases on purpose. I believe that the only way to really improve app delivery is to create shorter feedback cycles to increase collaboration with all stakeholders within an app delivery project. Where you start doesn’t matter, the App Delivery Lifecycle is a continuous process in which each cycle is as short as possible.
Is cloud irrelevant?
I started this article by saying that we should just stop talking about cloud as it doesn’t help your business and is irrelevant. As you probably expected this was a bit exaggerated. Cloud, whether it is IaaS, PaaS, or SaaS, is not irrelevant, neither is it a solution. Cloud is an enabler.
If we look at the App Delivery Lifecycle, IaaS can do to deployment what Model-Driven Development does to programming: raise the level of abstraction. PaaS can make collaboration easier, but can only really help a business if it takes the right approach in all phases of the App Delivery Lifecycle. SaaS is only really helping the business if it is part of an agile App Delivery Lifecycle to ensure the app evolves along with the changing business.
In my opinion the cloud should play an important role in delivering a platform facilitating the App Delivery Lifecycle as service to users and customers. Especially for collaboration across company borders and for the delivery of apps to end-users. I would like to refer to such a “cloud platform” with the term “App Delivery Platform-as-a-Service” as I see it as an important sub category of the broader term “Platform-as-a-Service”.
An App Delivery Platform-as-a-Service is not only a development platform. It is also a social platform, a deployment platform, and a user engagement platform. An App Delivery Platform-as-a-Service is all about delivering apps that perfectly fit the business, it’s about creating business value, it’s about enabling the business to be successful!
If you want to help your business you shouldn’t move to “the cloud”. You should make sure your App Delivery Lifecycle is revolutionized! I bet “the cloud” will be part of it...
About the Author
Johan den Haan is CTO at Mendix, where he leads the research and development teams as well as cloud operations. He has been with Mendix from the start and helped shaping the products and growing the R&D teams. He blogs here and tweets as @JohanDenHaan
Photo by letlovein.
Johan den Haan
I am aware of DDD as being a way to do Model-Driven Development. In fact, domain analysis is of utmost importance when designing a language to cover a certain domain. See this article about DDD based recommendations for DSL design.
I think we agree on the main message of this article: cloud is technology, an enabler. If we focus on agility by improving the different parts of the application delivery lifecycle, cloud will fit in naturally.