Go to search feature Go to content

SEB Cloud Platform - The saga begins

Welcome to the first post regarding the Cloud Journey that SEB is doing!

Since SEB now has been working in the cloud for a while we thought that it would be interesting to share a little of what we do, how we do it, what we have learned, errors we've done along the way etc. Our goal is to be a bit techie in this blog but let us first give you a little bit of background just to set the scene.

The cloud journey started already in 2015 and then the intent was to increase cloud awareness among employees and prepare the company to the foreseen move to cloud environments. A number of proof of concepts were done but the final conclusion was that the cloud market, and the legislation governing the financial industry, still were too immature.

Then in 2018, inspired by startups, an initiative came to create a new bank within SEB which would be named SEBx. Since cloud technology now felt more mature it was also decided that this new bank was going to be hosted in cloud and Google Cloud Platform was the provider chosen for it. But for SEB this new initiative was only one of many interesting use-cases that could be hosted in cloud so to help SEBx get going faster, and to help make a foundation that the rest of SEB could use in the cloud adoption to come, a cloud core team was created. Together the core team and SEBx set a number of principles that the cloud journey should follow or achieve like for example:

  • Cloud native principles and best practices should primarily be used
  • Security is a concern and responsibility for everybody
  • Updates to acceptance and production are done via infrastructure-as-code (we mainly use Terraform)
  • A team working in cloud should be as self-sufficient, cross-functional and autonomous as possible
  • A team should be able to deploy when they want and need
  • Teams should use the 4-eyes principle (via merge/pull requests) to always have another person looking at the code before it goes to production
  • Compliance should be "built in" and available as code
  • Auditors should be able to trace who has deployed a cloud resources, when and why
  • Knowledge, findings and best practices should be easily shared among teams


This was an important step because it then gave all some guiding stars to work towards. Then of course you have to start somewhere so not all of those principles were that easy to implement from the get-go. For example we ended up needing to set up our own source control and ci/cd so it took a little time to get Terraform deploys going in the beginning so the things we created were done manually. And even though we tried to plan things like our folder and project structure, cloud identity groups, vpc's in advance by the use of documents like best practices for enterprise organizations, we ended up changing them several times afterwards before feeling happy about our structure.

And if there is one thing that we have learned after a few years of working in a cloud environment it is that you should never assume and expect that you are done. Instead always expect things to change...always!

That it is for our first post, stay tuned for more.

Team leader, Solution architecture

Kristina Westman

Team leader, Solution architecture

Kristina Westman


Cloud Enabler

Tonni Hult

Cloud Enabler

Tonni Hult