|
In recent years, application usage has evolved and grown tremendously. Unlike core IT systems (ERP, HR, etc.) that are under the close scrutiny of corporate IT, Software as a Service (SaaS) and now mobile applications come with very different requirements. What's valuable and efficient today might not be what's valued tomorrow: SaaS and mobile applications have to constantly evolve and adapt to user requirements if they are to avoid becoming legacy applications. As a consequence, developers have to be in a constant "discovery-mode" for trends in user requirements, experiment with what works or doesn't work and iteratively improve the ROI of the application.
Before we talk about the special challenges with mobile development, let's look at how IT has evolved in application delivery to Software as a Service and ultimately, to mobile.
SaaS: The Application Development Revolution
All software used to be packaged code that had to be installed, configured, patched, managed and upgraded by IT. Today more and more software is sold as a SaaS � entirely managed by the vendor providing it. While this might seem a superficial difference at first, it has radical consequences both for the consumer and provider of that service.
There are several reasons for the shift to SaaS:
�SMBs don't have the resources and competencies to support the IT burden associated with packaged software, and enterprise teams can't necessarily get the attention they need from corporate IT. Subscribing to a ready-to-consume service, hence shifting the provision/install/manage burden from internal IT to a third-party vendor, enables an organization to use necessary software without being dependent on internal IT.
�Many organizations have started to realize that what really differentiates them in the market is not how efficient they are at building data centers, installing and cabling servers or patching operating systems. They want to focus on true differentiators (revenue-generating activities) � such as developing/enhancing applications.
�As mobile devices grow in sophistication, more and more business users have started using them, too. The move to mobile changes the definition of where private data is allowed to reside. Historically, firewalls acted as the demarcation line between the inside � where data was stored � and the outside, where sensitive data wasn't allowed to flow. However, this definition is rapidly becoming a legacy definition. SaaS � and mobile � applications usually have to access data outside of the firewall.
Yesterday's Application Development
Traditional software development is clocked by release cycles lasting anywhere from months to years. The shorter the cycle, the easier it is to get new features out and remain competitive; yet, IT organizations typically do not have the bandwidth to constantly upgrade to new releases. Upgrades require analysis, data migration, beta-testing, deployment to user workstations, possibly even to subsidiaries � and all of this is costly. Many IT organizations simply skip releases and wait as long as they can afford (or as long as the vendor allows) before upgrading to new releases.
Packaged software is not only painful for IT buyers, it is also painful for vendors. Since they'll typically support older software versions in addition to the current release, they end up maintaining multiple versions. This is an expensive proposition.
Next Generation Application Development
In an -as-a-service model, it becomes the vendor's responsibility to perform all of the management, patching, monitoring and upgrade tasks. Initially, this could be perceived as an increased burden for the vendor. Yet, when looking at the big picture, the analysis becomes vastly different:
�The SaaS provider will typically only offer a single version of its software: the version that's currently running in production. It doesn't need to allocate engineering, QA and release resources to focus on babysitting legacy codebases.
�SaaS vendors will typically release new versions on a weekly basis. Frequent releases means that the feature differential between the previous and the current version is very small and much easier to QA. Also, the release to production has a significantly reduced impact � thus, lower risk.
�Since the vendor is operating the service, it is able to analyze, in real-time, how the new feature is impacting its customers. For example, is the new version of the Shopping Cart Checkout function leading to a better conversion rate? If the feature is a success, the vendor keeps it. If the feature is not a success, it can immediately be pulled back from production. Once removed, there is no need to support it for 10 years: the keep it/kill it decision can happen very fast at a very low cost � present and future.
�The SaaS provider controls the IT environment. The infrastructure variables encountered in customer installations of packaged software are endless. Huge amounts of vendor support time are devoted to resolving environment-specific issues. With SaaS applications, those issues disappear.
�The bug window is narrower in a SaaS environment. Without multiple versions and environment-specific issues to deal with, real bugs are uncovered earlier, often by unobtrusive techniques like dark- and canary-deployment, and fixes are delivered to all users more quickly than with packaged software.
�SaaS provider's technology investment can now be applied to operational efficiency and feature/function development in order to improve competitiveness, providing a competitive edge for SaaS vendors compared to packaged software vendors.
While the promise of SaaS development is appealing, SaaS development comes with its own processes, tools and practices. A vendor that aims at pushing new releases on a high-frequency basis will only be able to do it if their ability to implement, build, test (units, UI, performance, etc.), release and meter (and possibly rollback) their services can happen in a smooth/no-friction manner: traditional packaged software practices come with a high-friction cost that makes this impossible.
How to Always be Release-Ready?
In a SaaS world, the underlying philosophy is to always be release-ready. That is, the software is in a state at all times where it is ready to be released, if a business decision was made to do so. This might not be what you want to do for a variety of reasons � that's fine � but the idea is to make sure your application is as stable as it can be at all times.
The only practical way that applications can be release-ready at all times is to have all of the release processes, from code to production, fully automated and pre-integrated. If the processes have to be manually executed and maintained, the overhead cost and friction make it challenging to maintain a constant release-ready state. The mindset that frequently exists in typical packaged software environments ("Let's start integration and testing of our application three months before release date") doesn't work in the SaaS/mobile world.
To that end, two concepts are extensively used in a release-ready environment: continuous integration and continuous delivery. |
