You have decided it is time to move out of your apartment or house and into another one. You are packing up your closet, and you realize there are some decisions to make. Half of the closet is filled with items you like but just don’t use. Do you take the time and energy to move those things to your new place?
Let’s take this one step further. Let’s say your new home has a “smart closet” that won’t allow you to bring along the clutter. It is designed to help you maximize your use of space by only allowing you to store items that are regularly used.
One of the benefits of the smart closet is ease and speed of access. You never have to look through shirts that never get worn to arrive at ones that do. The racks and shelves in the closet fit what you need. If you don’t wear hats, there’s no hat rack. If you mostly wear sandals and flip flops, the shelves are made shorter than a standard shoe rack. The smart closet automatically customizes itself to you and your “operational needs.” Life is a little easier with a smart closet.
It’s this same logic that goes into the development and use of cloud technologies. Insurance administration within SaaS 3.0 is all about precision in what is used, what is stored and how it is managed. As we move into the future of SaaS (software as a service), this precision will give insurers real competitive advantage. But what is SaaS 3.0? How does it differ from what we have been calling SaaS all along?
The true definition of SaaS 3.0 is everything that comes under the heading of “differentiated experiences.”
This would include things like:
- Internet of Things transformation
- Embedded insurance
- Predictive analytics
- Simplification at an infrastructure level with purpose-built databases and server-less microservices
It may help to think in terms of functionalities. SaaS 3.0 will help insurers to do more in terms of predictive underwriting models and risk stratification. These are just a few of the opportunities. The deeper insurers dig, the more they will realize what is possible.
A smarter strategy for building purpose into the product
Insurers are finding that, when it comes to technology, what they don’t need bogging down their systems are the functions, capabilities and data that they will never use.
With cloud systems, you don’t bring all of the unused items that have been sitting in the closet. You clean, pitch, start from scratch, then move what needs to be moved after it has been organized and vetted for its usefulness. It’s a fresh start that stays fresh. How does this strategy work?
See also: Why SaaS Is Key in Core Systems
Five core principles are the future of SaaS. These answer the issues inherent in yesterday’s monolithic systems. When we look at the core principles properly, we see that they make sense because they allow for customization that fits an insurer’s purposes instead of making an insurer’s operations fit into a system box. Let’s look at these five principles.
1. "Componentized" — Create loosely joined cloud-native architectures that operate as microservices.
A large insurance organization may need many or most of the capabilities that come with an entire policy administration platform. A small insurer may need far less in the way of functionality. Perhaps they only need form-intake capabilities and don’t require the rest. In a SaaS 3.0 environment, each set of services or capabilities might be easily used as simple components. So, instead of monolithic products, such as a property & casualty system or a full underwriting platform, all capabilities become available as microservices. As a part of SaaS 3.0, we need to be able to segment monolithic, “old school” ERP systems. We need to "componentize" the microservices but keep them loosely connected with each other.
2. Specialized — Each service is designed for a set of capabilities.
As a natural byproduct, these microservices are developed for a specific function. It’s like walking into a restaurant where everything is a la carte instead of paying for a full buffet where you won’t eat every dish. Each capability has its purpose, and you only select the specialized purposes that fit your experience or need.
3. Communication-ready — APIs act as a gateway to an application or point of data.
How do these capabilities engage with the larger platform? How do they talk with each other? Insurers are currently using application programming interfaces (APIs), but most aren’t coming close to what is possible. APIs are shifting from simple data exchange tools to become the primary gateway for capabilities to talk with one another. The fundamental lever for SaaS 3.0 is to use APIs as the nerve center for ID stacks. Insurers will no longer need to create point-to-point connectivity between two systems. If every system contains open APIs that can connect to any other system, insurers will be gaining communication efficiency while they reduce resource needs and integration time. Open APIs remove layers of integration. They invite collaboration, which, in turn, fosters innovation. SaaS 3.0 is an environment built for easy innovation.
4. Data-ready — Applications are designed on purpose-built databases optimized for specific workloads.
Nearly every insurer is in the midst of analyzing their customer journeys and how to use cloud technology to improve them. Many have hit a hurdle that they don’t quite understand. As they begin to unravel the issue, they come to realize what they are missing can be solved in SaaS 3.0.
Here is the issue: If you look at an application or a piece of software, it is relatively easy to understand the user experience (UX) —the piece that the customer gets to touch and feel and use. Underneath that is something we typically refer to as business integration. Underneath that is the database or data warehouse — a huge bucket that holds all the data. Below that are infrastructure items like servers, networks and security. But when we talk about SaaS or Cloud 3.0, executives and business strategists are many times focused on that top layer.
“How do we make our applications cool and unique and downloadable on iPhones?” Discussions around microservices and APIs are often restricted to the top layer and the iOS App Store and Google Play, etc. Everything below that layer, however, is potentially-restrictive to the innovations insurers could be making at the top layer. The layers below the top can hold insurers back, but some insurers are reluctant to go there. Conversations on SaaS frequently stall at the point where architecture analysts ask insurers, “What is your existing database?” It might be a SQL database or perhaps data is sitting in an Oracle data store. When discussing how data will be used or moved, insurers may back off. “Oh, we can’t do that.” There is a refusal to move.
In those cases, data’s real value is stymied by what I call data inertia. It’s too “heavy” to move. Either insurers have made a huge investment in their databases that they don’t wish to deconstruct, or they have acquired and merged so many times that numerous databases are held together with very important and fragile Band-Aids.
Cloud conversations need to percolate down to the core of how data is stored and managed. For SaaS 3.0, applications need to be designed with purpose-built databases that are optimized for specific workloads.
Consider how we use databases: There are transactional purposes. (Data A + Data B = Output C). There are reporting purposes. (Data is used to generate reports, dashboards and financials.) There are machine learning/AI purposes. (Data can improve operations and teach us something.)
If we purpose-build and purpose-use databases, then we can partition out database requirements so we have a separate stream of databases that are used purely for that particular function. Reporting won’t infringe on the transactional layer, and it won’t affect performance and methods. This is the core of what needs to happen. This proper design and use of individual databases is arguably more important than anything being done in the transaction layer because it is an enabler. The face of the organization holds more promise when the core is doing what it needs to do to support it — and only what it needs.
5. Justified — Operational impact as a key imperative.
We need to think of operational impact in the SaaS world much more differently than in the traditional technology world. When cloud computing began to grow, there was the conceptual idea that cloud brings efficiency with it. Today, though, we have to consider and measure the full realm of operational impact. We need a solid and evolving set of metrics to measure how we are progressing along parameters of performance, efficiency, operational excellence, cost optimization and scalability.
Better SaaS starts with clear insights
By keeping operational impact at the forefront of SaaS conversations, the organization can clearly justify the shift to cloud technology. The evidence that you compile in analyzing the current stack against future deployment is performance-based and not anecdotal. For those who work with Majesco, we begin with an operational impact analysis so that we can jointly review and understand all of the operational impact levers that are benefits to cloud deployment. We call them pillars. Each pillar stands on its own as a reason cloud works so well, but it’s easy to see how they jointly support best practices in the enterprise. The pillars include:
- Performance Efficiency
- Operational Excellence
- Stack Modernization
- Reliability
- Quality Optimization
- Security Standardization
- Cost Optimization
See also: The ‘Race to Zero’ in Insurance SaaS
The New Year traditionally brings with it a time for reflection and the need for fresh starts. As your organization contemplates how it will adapt and change to meet the years ahead, it may be time for you to compare your current state with the possibilities to be found in cloud technologies through the lens of SaaS 3.0.
For a high-level look at some of the great reasons that cloud adoption is on the rise, be sure to revisit Majesco’s webinar, New Normal: The Catalyst for Cloud Adoption.
