Back in the early days of the internet, there weren’t many internet applications. Instead, applications were overwhelmingly written for the Windows, Linux, and Macintosh operating systems. “Software delivery” often meant copying a binary to a server or building a blue-screen Windows installer and making that available on a CD-ROM to be sold in physical stores. (I remember when you had to pay extra to get your product delivered on 25 floppy disks instead of that CD-ROM.)
Releases were done very infrequently—just yearly or even longer. Development cycles were measured in weeks at best, and the time between finding a bug and delivering a fix was often measured in months. Releases were monolithic. A release had to be as close to perfect as possible, because the opportunities to deliver bug fixes were infrequent and hard to manage.
Things move a little faster today, thanks largely to software-as-a-service (SaaS) applications, which make up a significant portion of development done today. SaaS applications typically have a JSON-based, back-end API that communicates with a browser of some sort. They might also communicate with native applications on Apple and Android phones, but more and more, the device that an application runs on is becoming irrelevant.
Whatever the front end, the whole approach is a dramatic change from the classically distributed Windows or Mac application. SaaS applications can be fixed, updated, and deployed in minutes instead of months. SaaS has fundamentally changed how software is developed and delivered.
So why did SaaS applications become so desirable and successful?
There are four reasons that I can see:
- Development teams control all of the code execution.
- The code runs in a strictly defined, highly controlled environment.
- Delivery can be immediate and frequent.
- Teams can observe how their customers are using the software.
All your code are belong to us
In the client/server world, we wrote and compiled code inside the company, but then we released that code out into the wild, where it was executed on who knows what machines, operating systems, and configurations. Sure, everything ran on Windows and the Mac, but those machines were all different, and we had little control over how the code was executed or how the application was configured. If you had many application settings, users could set up the application in ways that you never considered or even thought possible.
With the advent of SaaS, none of the code is released into the wild. The back end of a SaaS application runs totally under our control and in environments we configure, regulate, and even alter as needed. The front-end code resides on our servers as well, delivered upon request and executed in a limited number of web browsers.
A strictly defined environment
Yes, there are many browsers out there, but the number is finite, and browsers are for the most part a known and testable environment. SaaS applications encounter only a limited number of execution environments, and this enables development teams to do a more thorough job of testing than they could in the classic distribution model.
Problems still exist with the variety of Android phones out there, but more and more, developers are delivering their application in browser-based solutions, reducing the concern about the multitude of different physical devices running many different versions of your software.
And now that Internet Explorer has finally been put out of our misery, the remaining browsers do a pretty good job of implementing the standards that make developing web applications easier every day.
Immediate and frequent delivery
SaaS applications end the fear of delivering an unknown, showstopper bug to customers, without any way to fix it for weeks or months. The days of delivering a patch to an installed product have gone by the wayside. Instead, if a catastrophic bug does wend its way through the development pipeline and into production, you can know about it as soon as it strikes. You can take immediate action—roll back to a known good state or flip off a feature flag—practically before any of your customers even notice. Often, you can fix the bug and deploy the fix in a matter of minutes instead of months.
And it’s not just bugs. You no longer have to hold new features as “inventory,” waiting for the next major release. It used to be that if you built a new feature in the first few weeks after a major release, that feature would have to wait potentially months before being made available to customers. Now, a SaaS application can deliver a new feature immediately to customers whenever the team says it is ready.
Totally observable
Because a SasS application runs in a limited set of browsers, it is much easier to observe what is going on within the execution environment. Tools like Datadog and Dynatrace enable you to observe and track everything that happens inside your application. Error monitoring with tools like Rollbar can report problems and issues from the client as they happen, dramatically reducing your mean time to awareness.
Observability thus becomes, in effect, a real-time thing rather than something that happens indirectly when customers report problems. Applications are running on internet-connected devices, whether they be a computer with a browser or a mobile device, and thus can easily report back problems, how the application is being used, and what the application is up to.
Know thy customer
In the client/server world, traditional software companies struggled to know who their customers were, much less what they were doing with the software and how often they were using it. You could literally buy software, install it, and use it without anyone else knowing that you were doing so.
SaaS applications let us see pretty much everything that our customers are doing with the software. Their data is stored on our servers, and we can see what they are doing now and the history of what they have done in the past. This isn’t Big Brother watching, or a threat to customers’ privacy. SaaS applications don’t make a habit of storing personally identifiable information. Rather, monitoring customer behavior enables SaaS businesses to partner more closely with customers and to work to help them see the real value of our products by examining their usage patterns and data.
As a result, we can aggregate customer activity and focus development in areas that show high use. We can see how customers are and are not using the product. We can help them use the product better. We can point out where they are using best practices and where they are not. We can tailor our efforts to customers who need help and spend our time in more productive ways.
Knowing who your customers are and how they are using your product is solid gold information, and SaaS applications let you do that. This leads to better outcomes for your business and your customers. SaaS is not only a better way to deliver software, but a way to build software that better meets your customer’s needs.
Copyright © 2022 IDG Communications, Inc.
