Cloud native fintech or merely a hosted software solution? Five keys questions to determine the difference

By Neil Smyth | 9 November 2017

Cloud computing is changing the way we all consume and interact with technology. Whether this is at home with Netflix, or with devices such as Amazon Alexa, or at work, with cloud-based services like Office365, Salesforce or other specialist enterprise applications. In business, cloud computing is an enabler; it creates strategic change in the way businesses of all sizes work with technology. In short a real cloud native service will make your life easier, more efficient and less expensive.

With all the benefits and hype that has come along with the word ‘cloud’, many companies claim to have “cloud” solutions when in fact they are merely hosted software services. How can you be sure that you will receive all the benefits of cloud computing, such as lower cost of ownership, zero maintenance, frequent product updates, endless and elastic computing power and more?


It’s important to know the difference between real, designed for the cloud applications we call ‘cloud native’, versus quick fix migrations of legacy code that are called ‘cloud wrapped’. In the rush for new clients, many vendors in the financial technology market skipped the hard work of re-building their applications and simply created crude web front-ends attached to legacy application architectures.

So, what are the key questions you need to ask to find out if a solution is the real deal when it comes to the cloud?

How many versions of the solution are in production with clients?

The answer should be one. Why? Cloud native applications are built as a collection of services on one platform that can be shared by many clients. By having only one version, the cloud service provider can ensure you receive a much better service. If each client has their own installation, it is much more expensive to maintain for your supplier, so you end up paying more. Having multiple versions to support slows down application development and innovation. More cost for the clients to support. Cloud native applications can scale to any number of clients using the single installation and version. The more clients, the more efficient, the lower the cost. If the service is not multi-tenant, it is not a cloud native service and you will not get the benefits you are looking for.

Does the solution use elastic cloud computing for scalability?

You’re looking for a yes. Why? Old software solutions work off a fixed amount of computing power. You can add servers to increase capacity, but this takes time, money and effort. Once you have added your extra servers, you then keep the servers even when you are not using them. An elastic cloud is where the software can order more servers for one or more hours and then stop using them when they’re no longer needed. This way, you match computer-processing capacity with the workload you have. Let’s say you want to process all your portfolios in less than one hour every day, the service can summon up exactly the number of servers required to process your workload in that time. Thereafter, for the next 23 hours, the capacity goes back to the minimum requirement. This will reduce your IT costs by 10 times. Only cloud native solutions can do this. Traditional software cannot do this even if it is put into a cloud wrapper. To see elastic cloud scalability in action, watch this 4-minute video demonstration.

How many updates are made available each year?

The beauty of a cloud native solution is that the supplier can issue frequent updates to their service. We do so six times a year. What is more, all clients are updated at once – there are no special versions. One of the main issues with traditional on-premise and cloud wrapped software is the upgrade cycle. It’s a painful and costly process. With large annual releases, many things must be tested, versions must run in parallel, IT need to get involved and you will have to pay for internal and external consulting. Traditional software, even if it is cloud wrapped, needs individual upgrades per installation, with one installation per client. A true cloud native service costs nothing to upgrade and it just happens invisibly. Smaller, more manageable updates means lower operational risk. It also means rapid and agile progress can be made within the application. It allows for the vendor to react to client and market demands.

Is the solution secure? Has it been externally audited?

You need a big yes. It may sound counter-intuitive, but cloud native applications are more secure than traditional on-premise software and certainly more secure than traditional software that has been wrapped in the cloud. Why is this? Application and data security is not normally part of the development process with traditional software. Security is something that is added afterwards once the application has been built. Like adding a burglar alarm to a house. With cloud native applications, data security is designed integrally from the start, not as an afterthought. Because the application is shared between clients, you must have a secure method of managing client data. This approach results in a more secure software architecture. It’s like building a bank vault with safety deposit boxes. Making sure the application security has been externally audited to recognised standards is also important. Standards such as ISO27001, SSAE18 and the STAR certification from the Cloud Security Alliance are all good indicators of a vendor’s commitment to data security.

How does the service interact with other applications, including my on-premise software?

This needs to be via an API. Why? You’re not going to find a software solution that can do everything you need across your business on its own. Applications need to collaborate with each other and fit into your existing processes. During your migration to the cloud, you’re going to have many critical services running on local systems. Data management is a critical part of any IT strategy. On-premise and cloud wrapped systems create data silos because they typically exchange data by file transfer. This causes very high levels of maintenance and complexity, leading to extremely manual processes. With data warehouses and now data lakes, a modern data strategy needs applications to participate as publishers and subscribers of data. The value in data is information you can act upon. This comes when multiple sources of data are combined with each other. To do this, you need applications that allow for native extraction of data programmatically through an API and not manual data exports in fixed file formats. The way cloud native applications do this is via open Web APIs. These allow for seamless, programmatic access to data at any point. Cloud wrapped software is often batch driven and not dynamic. Data can only be extracted at certain times in inflexible formats that must go through additional processing to be useful anywhere else. Web APIs knit applications together so data can be joined up and made available to other applications that need it. They are the essential smart plumbing of any modern data management strategy.

While there are other important areas to uncover, these five questions will help you to tell the difference between cloud native applications that come with many business benefits, and cloud wrapped imposters that come with many of the issues of legacy on-premise software. In the end, it is less to do with the functionality of a service and more about the technology. Will the technology help you achieve your strategic goals or will it bog you down in endless complexity?

Become a bobsguide member to access the following

1. Unrestricted access to bobsguide
2. Send a proposal request
3. Insights delivered daily to your inbox
4. Career development