Sesam migrating to the cloud – To SaaS or not to SaaS
To SaaS or not to SaaS, that is a big question for both software developers and end users. Perhaps you struggle to understand what it is about as it is just “software technology”? Well, I will give it a try and explain it with some simple examples to you.
As a software developer, you are normally driven by emerging technologies and have a tendency to disregard the value you are actually trying to add by providing new versions of your products or solutions. At the same time, it is very important that you manage to explain “added value as a result of technology choices” rather than “technology choices because they are cool and hyped”. Today, I had such a situation during a meeting with a colleague who is really good at the marketing side, but do not have that deep understanding of the underlying technologies. With “technology” in this context, we refer to specific IT-terminologies like on-premise, Amazon, AWS, C++ and more. With domains, we mean hydrodynamics, wind, waves, structural response, finite element, fatigue analysis and so on.
In DNV GL Software and Sesam we are actively pursuing the opportunities within software-as-a-service and the cloud. Here are some reasons for you as an end-user to stay curious and consider to follow our direction.
Need for speed and need for capacity
Within Computer Assisted Engineering (CAE), we see that our customers are pushing the limits. In each product release, we might offer new capabilities like faster computes, opportunity to handle more load cases or deal with bigger models, more exact finite element meshes and so on. Once we have had the product release out in the market for a period, we get support cases which contain model sizes we have never seen before or “impossible” compute problems. It can always be addressed by instructing the user how to model their assets “correctly” and become “CPU-economical”, but the best solution will always be something between this and offering unlimited scalability. The cloud, the amount of services (like Azure Batch, AWS Batch, Azure Functions and AWS Lambda) and the concept of Infrastructure-as-a-Service (IaaS) solve this very efficiently. As a developer we can, for instance, request a pool of virtual machines in the Azure D-series (just one example) with solid-state disks (SSDs), fast CPUs, and optimal CPU-to-memory configuration making them suitable for most general-purpose applications. And this is not like going to your local IT-department and requesting some servers and wait for some weeks. No, this pooling in the cloud just takes some minutes. And once you do not need it anymore, you just return it back and your running cost is close to zero again.
CEOs and CIOs are embracing the cloud and Software-as-a-Service
In the IBM Global CEO study in 2010, a total of 80% out of 1500 CEOs believed that their environment would grow much more complex in the coming years. Many organizations have invested heavily in on-premise infrastructure (servers, cables, routers and more) and established rather complex processes for deployment of new products and services. But, luckily there is help at hand in the form of cloud computing. If you do it correctly, you will reduce your investment and operational costs significantly, improve your security and become more scalable and adaptable. Most CIOs and CEOs realize this now and are already embracing new technologies like the cloud and new delivery models such as Software-as-a-Service. So do not be surprised if your CIO asks you “Is it cloud-enabled or can it run in Azure of AWS” next time you want to purchase a commercial product or solution and deploy it in your organization.
The Millenials and iGen generations want simplicity
A long time ago I used to do programming on a Commodore 64 computer. It was really cumbersome to do programming on it and the applications I made did not look that nice. I made stuff like text editors, glossary tests, games and so on….and it was hard to make and hard to use. However, I still miss my old computer-friend even though I recently found it at the Computer History Museum in Silicon Valley. Todays Millenials and iGen generations are growing up with smartphones, have a Snapchat account when they start at school and do not remember a time before the internet and the world-wide-web. When some of them turn into engineers, they will demand simplicity and great user experience. They do probably not want to download a xGB installation package, request local admin-rights, troubleshoot the setup, look for missing prerequisites like the .NET Framework, C++ runtimes or whatever. They just want to log in, spend 10 minutes looking at some examples and get going. And in some cases, they might use a desktop computer, but the BYOD-concept (Bring Your Own Device) will also apply.
If we as software developers do our SaaS-implementation right, listen to some clever user experience people and take a device agnostic approach…we will probably manage to make it both simple and provide great user experiences.
Shorter iterations and continuous delivery
Within software development, we are often referring to terms like lead time and cycle time. The term lead time means the time elapsed between the identification of a requirement and its fulfilment, i.e. when it is released and deployed to end-users. With cycle time, we normally mean the time from where we start programming it until it is tested and ready to be released. As a software developer, I have to admit that our lead times are way too long as most of our products are desktop-applications which are installed locally on your computer. Even though our users (might) have full control on which product versions they are running, we seldom have this overview from the software provider point of view. Quite often we will get support cases saying that “there is a significant performance issue or crash in v1.2 of a product” and then the answer will be that we resolved this issue some months (or years ago) and the fix is in v1.4.
With the cloud and Software-as-a-Service, we can do like many other successful software providers like Netflix, Spotify, Facebook and more….we can deliver continuously. In the software-technology, we call it continuous delivery. “Continuous” in this context must be balanced with the customer needs, i.e. it might be daily, weekly, monthly or perhaps quarterly. The trick on our side is both to have very robust test-systems (large extent of automated testing and less human interaction) and efficient roll-back processes (in case we roll out something that was supposed to work, but did not work). In any case, we know that small incremental releases have far lower risk than “big bang” releases where we have accumulated development over a long period. It is as simple as managing risk, which we talk a lot about in DNV GL. We turn risks into opportunities and your opportunities as a customer are short iterations and a more continuous delivery plan.
Try before you buy or try before it is ready
We might work hard for months for a specific release and do our best to provide a great user experience. But, quite often we learn as we go. The high priority features might not be used as we expected or there can be external factors that would make us do it differently the next time. With Software-as-a-Service and continuous delivery as mentioned above, we can easily apply methods like customer preview versions or another concept called feature toggling. Let´s say our SaaS-based Sesam-product has a new button, a new dialog, a new calculation algorithm….whatever….that we are not exactly sure about. We will, of course, do our utmost to provide high quality, but there is no fixed answer on how to provide a good user experience and make it self-explaining. In such cases, we can turn the new feature “on” (enable it) for a subset of our users that are willing to give it a try. We can collect feedback and we can improve it before we deploy it to the whole user community.
Our recurring revenue is more dependent on high customer satisfaction
In a traditional pricing-model, we will normally get revenue through “new sales” (a fixed price for a license) and a Service Level Agreement (a yearly amount). In the SLA, a software provider will normally guarantee for technical support, for support of upcoming platforms (Windows 10 and more) and for “x” releases per year. With Software-as-a-Service the pricing model will normally change as you will go from license and SLA to a subscription/consumption/transaction-based pricing model. A greater part of our business model of recurring revenue is dependent upon your constant satisfaction and usage. So that is kind of “good” for a customer and “ok, but more challenging” for a software provider.
There are of course many more arguments for migrating to Software-as-a-Service than stated above. But, I hope that you have improved your understanding a bit reading above and that your answer to the question “To SaaS or not to SaaS” has changed.