If you have read my previous article, 23360 days old and counting, you know that I have been around the software industry for a while. In my early days, I worked for Philips Telecommunication, a global IT company in the 1980s that delivered a turnkey solution from hardware, operating system to client software for their customers. In this article, I will give a historic perspective of why SaaS has simplified software delivery and why it is the future.
1980s Turnkey Solutions
When we were doing a project, we worked closely with the hardware engineer to build the software drivers for the new hardware components like monitors, keyboards, teller displays etc. Philips provided a turnkey solution to their clients, primarily banks worldwide.
That was not a very sustainable business model, lots of things could go wrong, and we had our share of the problems. I will mention a few – I worked on the new bank teller system, which was basically the following devices such as keyboard, monitor, a bankbook printer and a customer display.
Hardware compute power
We did not have the compute power to get it to work well. When a bankbook(the passbook or bankbook is a paper book used to record bank transactions) was put into the printer, the monitor and customer display slowed down drastically. When one digit/letter was written on the printer, the cursor on display just blinked eventually. After months, we solved it by adding newer computer chips set to our devices.
Gas Station vs Subway depot
Another problem we had was related to electricity, we had worked a few months to deliver a fore-court solution to accept card payments from gas pumps and from the fore-court cash register. The customer Shell had selected a station in which we would install the proof-of-concept, we had installed all the hardware and software, everything was tested and the customer signed off on the installation.
During the first month, we were getting calls from the client, that our software crashed once in the morning and once in the afternoon, at first, it was very hard to simulate the problem, after a few days we start getting a picture when the rush hour started the software crashed, and we narrow it down to the hardware not getting enough electricity. It turned out that the gas station was located closed to one of Stockholm subway depots, and at a rush hour more subways cars were put in traffic and that took a lot of the electricity from the grid. When we knew that we could fix the problem to manage the electricity surge.
The elevator
We had just gone live with a teller solution for a bank in Sweden, we started getting a report from a bank branch that their system crashed very often during the day. We went to the branch location, to analyze what is going on and we noticed that the server or what we called at this time the branch computer crashed when the elevator on the other side of the wall passed by, when we understood the problem it was an easy fix, by just moving the location of the branch computer.
We believe that the branch computer was too close to the elevator, that a magnetic surge took place that knock the computer out, that was just a theory we had. Moving the branch computer solved the problem, we did not have any more problem at that bank branch.
1990s complexity increased
The turnkey solutions era came to an end in the early 1990s, at this time, I had to join a software startup in Toronto, Canada, named Oasis Technology. Oasis offered an electronic payment software called IST Switch, which allowed banks to connect their ATMs, merchant terminals to their backend (mainframe), and software drivers connected to payment networks, e.g. Visa, MasterCard, Amex, Diners Club.
Oasis software ran initially on Unix operating system provided with the hardware from Sun Solaris, IBM AIX, HP Unix, Stratus VOS (proprietary operating system), DEC Unix and Windows NT.
The Oasis IST Switch software required a database as payment transactions were logged primarily to manage reversals and the end-of-day payment reconciliation and reporting. We worked with Informix, Oracle, Sybase, and Microsoft SQL Server.
We allowed our customers to select the hardware and database solution, and we worked closely with our hardware and database partners. They even bundled our software so their sales arm could sell it. There were situations where our software was the solution, and each hardware vendor was competing to get a contract from a client.
Maintaining versions
Maintaining versions of the IST Switch software for each hardware/database combination was challenging. On top of that, IST Switch supported software with high availability, as our banking customers required 99.999% availability. Our closest competitor was ACI Worldwide, which runs its software on fault-tolerant hardware from Tandem Computers. Oasis fault-tolerant solution was with Stratus Technologies; our customers preferred our IST/Switch with IBM, HP, SUN.
Not only did IST Switch have to support high availability, but we also had to support an end to end payment transactions of less than 9 seconds and 100 Transactions Per Second (TPS). We spent a big part of our time benchmarking the IST Switch software with the different hardware/database combinations.
Solutions Bundel
These bundled solutions hardware, software license and database license often cost millions of dollars and were structured usually as 50% paid upfront and then 50% ongoing live (delivery), for each year after the customer was obligated to pay an additional 20 percent for support fees. This traditional pricing structure created significant financial barriers to adoption and made procurement painful and elongated.
The customers also had to experience an implementation that took 6-12 months to complete from contract signing to the go-live date. Additionally, upgrades were slow for their complexity and caused significant downtime for customers.
Oasis and their competitors like ACI and Visa, MasterCard, Amex laid the foundation of a global payment network that allowed debit or credit card holders around the world the ability to pay or withdraw cash any where in the world.
Torbjorn Zetterlund
2000 the ASP and SaaS
In 2000 I worked for a startup in Toronto named Fliogix; they had a digital solution for mortgage applications used by banks and mortgage brokers in Canada. Filogix operated as an Application Service Provider (ASP). Still, the Filogix customers had to invest in expensive computing hardware required to run the FIlogix software; Filogix managed the hardware/software solution.
Implementation was expensive as it took 3-6 months to implement with specific customer customization and dual language support. The Filogix ASP model introduced the server environments like staging, testing, production, upgrades were notorious for their complexity and caused downtime for customers. Also, the user acceptance testing took time, as the team on the customer side needed to be available to accept the new version. This limited the evolution of the software in that only one major release was completed per year, with an emergency release schedule for bug fixes.
SaaS Model
The SaaS model started to form around 2000 with salesforce.com as one of the first providers of SaaS, with a subscription-based pricing model that grow with the customer; ‘s usage. The SaaS model put the software in the browser to kill the client-server software delivery experience from the past.
The SaaS model allowed the sharing of the cost of expensive compute resources across multiple customers by leveraging a multi-tenant architecture and by removing the installation, maintenance and upgrade challenges.
That was a software delivery revolution
Torbjorn Zetterlund
2010’ish IaaS Model
Then came my favourite, the infrastructure-as-a-service (IaaS); IaaS adds value at a layer deeper than SaaS, providing the raw building blocks rather than the end product.
IaaS was an opening for SaaS providers to rent cloud computing, storage and network capacity and access computing resources by the hour. Freed up from significant upfront capital investments or managing complex customer installations, new SaaS providers flooded the market with subscription pricing for many flavours of software and services.
The IaaS model has made running the software cheap on computing environments in the cloud; installing and upgrading software has become automated with continuous integration and deployment (CI/CD) and configuration-management tools.
I recently built a data pipeline for the hourly electricity rate; it took me 4 hours to write the Cloud Function code, deploy the Cloud Function, Cloud Schedule using Terraform and create the Data Studio Dashboard. The deployment time has shortened tremendously, and I feel so good about what can be done with IaaS.
You can take legacy software, package them in a set of Docker containers orchestrated by Kubernetes, for example, that can be installed pretty much anywhere and be live in minutes.
Not everything is fantastic
Individuals and small teams within large companies now drive software adoption by selecting the tools (e.g. GitLab, Slack, Dropbox), often SaaS, that best meet their needs. The burden on IT is to make the decision to either restrict network access to shadow IT or pursue an enterprise license for those services.
Shadow IT
Shadow IT has created an entirely new category called cloud access security providers, which is another vendor that needs to be paid, an additional layer of complexity, and another avenue for potential problems. One way to solve this is to manage local versions of these shadow applications to bring the control back to IT.
Data Breach
Using software hosted in another country or managed by a third party exposes companies to legal issues. The European Union’s GDPR law, for example, exposes SaaS companies to more potential liability with each piece of EU-citizen data they store and puts enterprises on the hook for how their SaaS providers manage data.
A data breach is a big concern with the exposure to cybercrime companies face as they build out their SaaS footprints. All it takes is one employee at a SaaS provider clicking on the wrong link or installing the wrong Chrome extension to expose that provider’s customers’ data to criminals. If the average large business uses 50+ SaaS applications and each of those vendors averages 100 employees, that is an additional 5,000 possible entry points for an attacker.
So what is next
I get closer to retirement for sure, and I will develop all my software features as microservices as it is cost-efficient and low maintenance. I do not have an enterprise problem as my IT footprint is relatively small. I wish that companies built their multi-tenant software solutions for their business needs with microservices; that is what I would do. That is me; what really will happen is in my view.
Cloud First Applications
We will see more cloud-first applications, applications built using technologies (such as containers) that can help replicate the deployment of those applications onto any infrastructure. With cloud-native computing, the same complex applications you can sign up to use in a multi-tenant cloud environment also can be deployed into a private data center or VPC much more accessible than previously possible.
IT in control
The cloud-native approach will be prominent in the future as IT will claim back some access to shadow SaaS applications.
Second Wave
The first wave of SaaS providers is facing a similar future to what took place to the legacy software providers that they once displaced. Many of today’s SaaS vendors are burdened by some serious technical and cultural debt, so they need to act.
If they fail to make the necessary transition, a new generation of SaaS companies that are agnostic toward where their applications are deployed and who apply the pre-built automation that simplifies management will put more control in the hands of the end customers will win.
Leave a Reply