Because of the COVID-19 pandemic, the cloud has become a necessity for organisations of all sizes. Standard Chartered Bank, a $14.754-billion banking and financial services company based in London is no exception. Last year, Standard Chartered partnered with Microsoft to accelerate its digital transformation via a cloud-first strategy.
At the recent Cloud Frontiers 2021 Conference, Dr Michael Gorriz, Group Chief Information Officer at Standard Chartered revealed further details about their digital transformation and the process of moving to the cloud. Gorriz participated in a panel discussion moderated by Rahul Joshi, Managing Editor of Frontier Enterprise, and talked about the bank’s experiences and challenges in the process.
You previously said that the cloud is absolutely non-negotiable for Standard Chartered. Could you expound on this?
Standard Chartered is a bank that has been around for more than 160 years. We are a British bank, but our main footprint of operations is Asia, Middle East, and Africa. We are active in 47 different markets with representations in even more.
We have two, soon-to-be three global data centres. The cloud was the natural place to go because we operate in so many markets, and we want to put our workload and compute capacity very close to our customers. These days with the number of products coming up, it’s not really predictable, therefore the decision to go through the cloud was taken with customer service and business in mind.
When we made the decision to go through the cloud, there were various ways of attacking it. We realised that manual ways of working were quite tedious, so we wanted to move to the cloud as a whole.
Gradually we realised that because the systems were so complex, we said let’s take it all to the cloud and we strategised ‘cloud first’. What this means is not everything is taken to the cloud, but we engineer our systems, we build and design our systems in the way that they are fit and proper for the cloud.
What was the primary motivation behind switching to the cloud? Was it agility, cost, convenience, or just a modernisation process?
A little bit of all. As a matter of fact – you might be surprised – the main considerations were obsolescence and cybersecurity. In today’s age there are so many threats coming from the outside. Products evolve so fast that even for us as a large organisation we have 15,000 people working only in the tech department. But even with that number of people, we are always short of talent to keep up to date.
The moment you put something in the data centre, it starts to age. Then four-five years later, you realise that you have to take it out. You also realise that this process of constant innovation is a sort of certain drag, because that’s not what we are striving for. This is compounded by the ongoing cyberthreats, so we really have to be very careful and hands-on with the latest technology.
This is quite a hefty task, and therefore we said “Okay, what’s our core? What is it that we really want to do?” Our core is to drive software for our customers or integrate software from the outside. We don’t want to deal with infrastructure services, things like databases. Obviously, we have all the databases and an engineering team that designs how these databases will be designed; but our hyperscale partners, they have a multitude of engineers only for this specific task.
I believe that they can do it much better than we can, and we can therefore focus on what will be relevant for us and for our customers.
Why did you select AWS and Microsoft Azure as your preferred cloud platforms and how does it fit into a wider multi-cloud strategy?
We started with a lot of hyperscalers but we just picked the two because we had associations with them already. With AWS, we date [our association] back to 2014, and Microsoft comes from enablement and collaborations. Therefore these two are natural partners for us. For us, it was a choice that was driven by experience and legacy.
What are your thoughts on multi-cloud?
I would not start with multi cloud upfront if I was a smaller or a mid-sized company, because going to one cloud takes a bit of effort. Although all the clouds are easy in their own way to operate, they still have subtle differences. Therefore to get into it, and train and educate your engineering team, going into the cloud has a certain upfront cost.
In our case, as a regulated industry, where you have a supervisor like the Monetary Authority of Singapore or others, they pretty much look over your shoulder, and govern what you can or can’t do.
What we are concerned about is that we have been a bank for 160 years – we’ve inherited that level of trust, and want to keep that trust. We want to keep our customers’ data secure. We have to be quite sure that this data doesn’t get tampered with.
When you talk of cloud computing, you have to differentiate between two things. The operational resilience – where if something happens like in a physical data centre, what would you do and how would you best prepare? And then there’s strategic resilience – where if something very bad would happen with a provider, even with a hyperscaler.
For strategic resilience, it’s important that you know more than one cloud. It’s like speaking a different language. Therefore, we decided upfront to go with two cloud providers and probably there’ll be a third and a fourth coming along. We have to have the capability to shift workloads.
We don’t do this in parallel because it’s very expensive to keep the workloads for two clouds, but we have the capability to adapt the workload to one of the other clouds.
In your cloud migration journey, could you talk about what sort of workload is decided to migrate first, and what are the key milestones and timelines?
Sure. When you look at a bank, there are three levels of systems. We have the systems of engagement – the mobile app that you hold in your hand and the web front end, these are for general engagement. Then you have the workflow systems which tie it all together. And then you have the backend systems.
The biggest and the most important back-end system in a bank is the core banking system. That’s where all your records are kept – how much money you transferred, all these kinds of things. You can imagine this is a very important system.
We started with engineering the engagement layer, because that’s close to the customer. But there are so many interfaces going into the back end so we said: “We also have to move our core banking system to the cloud.” In our case, we are lucky that we wrote the core banking system ourselves. The code is ours and therefore we have the ability to refactor.
That was exactly the example which I gave before. It’s an existing code that’s on a Java platform. We had adapted to a certain database but then we migrated to a standard database concept, and we were able to migrate the whole core banking system together with the database using the database services from AWS. In this case, we used Aurora.
Once we did this, it worked. But then we realised that all these interfaces are connected to core banking. We had to move all our messaging layers, our API or interface infrastructure by and large.
We had to move to the cloud as well. By doing that, we then realised that if we put these systems with the surrounding support system in the cloud, then everybody or everything can go to the cloud. In the beginning, the excuse was: “I can’t go to the cloud because I don’t have the interface to this one, I don’t have an interface to that one.” So, we said okay, let’s put the core banking to the cloud, and let’s put the whole interface layer to the cloud as well.
This is engineered in a way that our interface layer can address each and any system, whether it’s on the cloud or on premises, in a virtual and a transparent way. Once we did that, the floodgates opened and we could migrate everything.
It’s a little bit of hard work at the beginning. It took us more than a year to get everything engineered and done. Now that we are live in four countries, with three countries coming along soon, we have to say this was the right decision.
It was the core and the middleware that went together, because that’s how the core interacts with the rest. These two came as one package. Once this package was deployed and available in the cloud, this paved the way for all the other systems to go there.
By way of future plans, more than 50% of our workload is in the cloud in the next four years, which means we are heavily migrating our stuff out of the premises to the cloud.
Which are the workloads in the future that you have planned to get onto the cloud?
Well, the main workloads as I said. The whole channel layer. Then the core banking, our payment system – the payment system was a brand new, green field. It was designed for containers and messaging services, so this is deployed on the cloud and we’ll go worldwide.
Then the core banking. Following that, all the rest of the systems go as they are available for migration. We are not obsessed with putting everything in the cloud, because some of the systems have limited lifetime left, so it doesn’t make economical sense to migrate. But the systems we consider core and with a longer strategic life, obviously we migrate them to the cloud with priority.
If you were looking back, would you choose to do it the same way again? What would you choose to do differently?
That’s a good question. The very early mistake we made is we were trying to replicate our data centre in the cloud. We said okay, that’s a data centre and let’s use the cloud as an additional data centre. We were neglecting a little bit in the beginning the extra services which the cloud providers provide.
Instead of using Aurora, we thought: “No, we put our own database in there.” I would say this was a mistake. This was just an evolution, and once we realised how reliable and easy these data services are, we more and more went into the usage of services.
They say regulations are always one step behind technology. What are your thoughts on this and how can legislators and regulators catch up with technology?
This was an interesting observation, and it’s true that in the beginning, when we started conversations with our regulators in 2018, we heard a lot of scepticism about the cloud.
But I have to give kudos to regulators around the world. We worked with them and explained the concept of how we want to use a cloud and we worked with them in a good way, in a secured way how cloud can be used in a banking environment. Today, out of the 47 markets that we are in, we have unconditional approval from 22 markets, and another four where we have to give pre-notice.
We have over a half which are approved to go to the cloud. The others are still in the making. It’s not that they said no, but we are still in the approval process. We see a lot of positive momentum from the regulators towards cloud computing, and this is because they see that on-premises computing is not ideal either. You have less cyber issues, and therefore the balance is now more towards or in favour of cloud computing.
There is a lot of jurisdiction, especially in Asia, where data sovereignty is required, and all customer data is needed to be within physical boundaries. How do you deal with that?
This isn’t a contradiction to cloud computing; this is just a requirement for hyperscalers to set up regions in the countries. India is probably one of the most prominent cases.
India has recently tightened its data residency rules. India is totally fine with the cloud, they want to have the cloud, they just want the cloud to be in India. So, we picked a provider that offered us a cloud in India.
We have to differentiate between cloud computing and data residency, because these are two different pairs of shoes. As long as you comply with the cloud in the region, or in the jurisdiction they are talking about, then they are fine.