10 ways to modernize, optimize & monetize on AWS as business grows

Good morning, everybody. Ah come on, it's Monday. We can do better than this. Good morning, everybody. Excellent, much, much better.

So you are gonna come here and ask some questions. I've got some questions for you before we kick off. Raise your hands. If you are being asked to do more with less, so you have to do the same things or more, but with a reduced budget. All scanning the room at about 77% of the room approximately.

Let me ask you another question. How many of you believe you have the right skills and more importantly, the right time to bring innovation to light? Excellent. The three people that put their hands up will come and ask you how in a minute.

Let me ask you a final question. Put your hands up if you're working for an organization that is trying to grow, whether that's revenue impact number of customers. I'd be surprised if there's anyone in the room that didn't raise their hands.

So the good news is you're in the right place. So thank you for coming over the next 45 minutes or so myself, my colleague Serena Grillo and esteemed architect from Globalization Partners, David Anderson will talk you through some of the themes that we're seeing and how you might need to adapt your organization to solve some of those problems.

So let me introduce you. I will let me introduce you to someone you all know - AWS. Now where I'm from in the UK, we don't spell it this way, but let's gloss over that. Every single customer that I speak to in my role as a business modernization lead is trying to do at least one, if not all of these three things - modernize, optimize and monetize. And the way in which you responded to those first three questions suggests that you fall into that category too.

When we're talking about modernization, what we're really talking about is how can you adopt new approaches to improve the efficiency of your organization? When we're talking about optimization, of course, we're talking about costs and optimizing the costs of your environment and your footprint. But also it's other resources, for example, time. How can you optimize to create more time for that innovation that we talked about? And finally, monetize - how can you as technologists become the growth engine for your organization? How can you diversify the revenue streams? And we'll look at ways in which you can tackle that.

So let's get stuck in, let's talk about 10 trends that we're seeing and David and Serena will provide you with some practical tips as well.

So let's start at the beginning. Number one - modernize by migrating. Now, it won't surprise anyone to hear, there has been an explosion of customers who are migrating their workloads to AWS over the last 10 years. What might surprise you though is that there are still lots of customers who have workloads that are still not in AWS - they're in on-prem locations, they're in colo locations. And there are even fewer customers who are completely all in on AWS.

So what this tells you is that there are still workloads to migrate to the public cloud, there are still workloads that you could be migrating to AWS. And what we see typically is for a first time mover, if you're moving workloads to AWS for the first time, you're probably going to do that in a lift and shift motion - by which we mean, take your existing workloads and replicate those in AWS just by way of approximation. About 70% of customers who are moving to AWS will take this approach.

And when you think about why customers are moving to AWS - a more scalable, more secure and more reliable environment - you know, the incentives are huge. So getting there quickly makes sense and this lift and shift approach also makes sense if you don't have too much cloud experience, if you are trying to minimize the amount of risk that you're bringing into your organization, you're minimizing the amount of change that you have to make. The lift and shift approach makes sense.

And typically these are the outcomes that customers who take this approach are seeing - they are seeing that improvement in time to market for their new products, they are spending less time on non-differentiating tasks like purchasing hardware, installing it, patching it, maintaining it. And of course, you're seeing the reduction in costs - you're only paying for what you use, not what you provision on a data center floor. So the results are pretty compelling.

But as I referenced earlier, lots of customers have already made that move. So what's the second trend that we're seeing? The second trend is that customers are now modernizing what they have on the cloud. And by modernizing, what we're typically talking about in this context is the adoption of cloud native services.

That could be serverless, getting away from that traditional VM installation, moving to something like Lambda for example. It could be containers, packaging up your application code, your configuration, all of the dependencies and running them as a container. That could be your modernization play.

It could be looking at breaking up that kind of monolithic database that you have that has served your purposes over the last 10 or 15 years and you're now gonna break that up and use the right tool for the right job. So there's lots of different ways in which you can look to modernize.

But here for me is the kicker - this is why it's important. Everybody who moved to AWS was typically originally doing that for cost savings. That was the primary driver. And as we're in Vegas, that for me is table stakes - like cost reduction is table stakes.

What we're seeing customers want to do now is realize that the value prop of the cloud is increased innovation, increased agility. And that's what customers are moving for.

And if you look at this chart, what you'll see is as you adopt these cloud native services, which are typically cheaper than other alternatives, not only do your costs decrease, but your overhead time, your time overhead reduces as well, which drives up your ability to innovate, to be more agile.

Customers who go through this path see these typical results - so again, you're still seeing a cost reduction on top of what you were using, maybe it was running EC2. You're certainly saying faster time to resolve incidents - you're not having to worry about what patch level the server was at that you were running. So you're definitely seeing improved outcomes when you modernize.

But here's the secret and here's the typical journey that I'm seeing most customers adopt now - rather than sticking with a lift and shift and then a modernize, customers are looking at this as not a two step process but a hybrid model where they are looking to modernize first wherever they possibly can, embracing the value prop of AWS, embracing those cloud native services first. And where possible, where it makes sense, do that lift and shift.

And I want to be clear - it's not always going to be easy. This modernization play is not gonna be easy. It is more work, to be very clear, it's more work than just doing the lift and shift. But the benefits that you will receive and the benefits that you will gain will be greater if you do that work up front.

AWS has created a framework - you'll hear it quite a lot this week, it's called the Migration Acceleration Program. I actually like to call it the Modernization Acceleration Program. And this is a framework that's going to give you best practices, blueprints and AWS will make some investments for you as you go through this journey. Pretty much every use case that you might have would be a potential use case for the Migration Acceleration Program.

I want to bring in David Anderson who's pioneered throughout his career a number of these modernization plays and he's gonna give you some practical tips on how to effectively do a modernization.

David: Thank you, Matthew. I love the focus on growth around modernization. I think that's exactly how to think. My name's Dave Anderson. I'm an architect at GP Globalization Partners and I'll touch more on that in a second.

For me, the main part of growth is embracing DevOps. Any modernization journey has to embrace DevOps. Now, DevOps is not a role, it's not a team, a technology. What DevOps really is is fast flow - how quickly can you move software through your organization? That's what DevOps is. If you're calling yourself a DevOps engineer, think about the outcome of this approach.

One of the ways I like to think about it - there's a fantastic quote here from the Accelerate book from Nicole Forsgren, Jez Humble and Gene Kim. And Gene Kim pioneered a lot of the DevOps mindset and approach. There's a lot of dogma about that - false assumption that moving faster means trading off stability and performance. We either go fast or we go safe. That's not true. If you go really fast, you can be safe. That's the thing of modernization. This is a fundamental mind shift in how we've traditionally done it.

From my journey - I previously in my current role, I was with Liberty Mutual for many years and I was at the table as a technical leader around 10 years ago, when Liberty Mutual first sat down with AWS - a 100 year old insurance company moving to the public cloud. And the first thing I thought about and my concern wasn't about data or policy or networks - how do we work differently to enable fast flow for a huge enterprise? And really what I thought - how do we make a huge insurance company, an enterprise, a service first enterprise? How do we get to the point where the first thing we think about is the modern technology?

And I spent around 10 years kind of driving that modernization journey. A couple of thoughts - a really fantastic service first kind of principles and practices. I then - the next thing I did was one of the people I was working with is Adrian Cockcroft who was at AWS. Adrian was the individual who brought Netflix to the cloud - is a fantastic leader. He says, ok, write a book. So I thought, ok, let's try that. So I was very fortunate to be published by Gene Kim with the Value Flywheel Effect. And this is really my kind of handbook, my playbook for modernization, the things that I think of when any company is going through a modernization journey. And this isn't really a technology book. It's about how to drive change in your organization with the modern cloud. And it's been fantastic, the response to that book's been out for a year now.

And so another fantastic quote is a lot of companies have lifted and shifted to AWS and that's not a bad approach, but that's the first step. So first you migrate and then you go to this - if you don't modernize, you've just got a really nice data center which is AWS and even worse, you have a really nice data center that you're not allowed into. So again, you gotta take that next step.

So currently I'm at Globalization Partners or GP - it's a really interesting company. So GP have pioneered the employer of record category around 10 years ago. And what employer of record means is - so GP has almost 200 entities all over the world. So if you would like to hire someone in any of those 200 countries, we can help you do that. So if you're sitting in the US and you want to hire someone in Ireland where I'm from, I'm from Belfast, you can basically GP will help you do contract negotiations, set up contracts, payroll, benefits - everything you need to employ someone in a different country without you having to set up an entity.

So this is a fantastic new category within the globalization or HR category. Again, there's almost 200 countries, so it's massive scale. And the big piece of GP is that as we have scaled, we have realized that modern technology will be the driver of that scale. It's the only way we can scale to meet the demand of our customers. And we have a new term for this - it's called Global Growth Technology, which means we have the technology to enable you to grow globally. And that technology is all modern, AWS technology under the hood.

Again, we have completely unbundled our product line so we can be there for our customers. Again, it's a very exciting journey that we can actually use the modernization principles that I'm speaking about.

So what do we mean when I say modern? So when I think of a team, an engineering team, these are the kind of the five measures that I would think of. And this is a wave of disruption and it is happening again and again -

Can your engineering team deliver on demand? If you were to ask your engineering team, can we release a feature tomorrow? Could they do that?

Can they evolve technology quickly? We're reinventing Vegas this week. There will be lots of new announcements over the next few days. If you hear a brand new service announced tomorrow, how quickly can your engineering team use that technology in anger - actually build something on that?

It should be a matter of days. Commercial responsibility do your engineers, think about the capability and the growth of the software of, of the business capability. Are they aware of the commercial impact of what they're doing for? Are the teams independent? For me, a team should own a business capability and that's what they evolve. They own a business KPI and they evolve it. They're not just following a backlog or a, or a, or a, a plan and five high quality standards, they build quality in from the start.

And speaking of high quality standards, the way, what what we do is we use the A double S well, architect, the framework which i think is one of the best frameworks i've seen. It's around 10 years old. So A double S supply, all the solution architects have got together and compare the best practices and it's distilled into a single framework, there's actually six pillars, but we use kind of five and well architect, the framework, we've kind of shorten it, the SC SCRAP which stands for security, cost optimization, operational excellence, reliability and performance.

So traditionally, some companies would think of this as like an audit like once a year AWS can audit your workload for my, for our engineering teams, we do this every single sprint. That's two weeks. We sit and go through these questions, we'll say to the team like, what are we doing for security? What improvements are we, what metrics are we? Are we improving? Uh for reliability cost optimization. We think of all these things and we let the team own these metrics and serena will deep dive into cost optimization next. And this is a fantastic. But i think this is the best if you think of all the best advice of all the solution architects in A double S distilled for every engineering team every two weeks.

So that's an example of what i would call a a kind of modern approach to how we build software at speed. Again, what i'm really describing is guardrails. So for any independent agile team on public cloud, you need to create the right environment. It's like guard rails on a motorway. Once you set up those good guardrails get out of their way. As adrian said, if you don't add an innovation to the culture, you you get out of its way. So once you create this environment, you let the teams go as fast as they need to.

So next up, i want to use uh serena to talk about cost optimization. I can drill under some of the um some of the the practical advice. Thank you. Thanks dave. Let's talk now about cost control point number four. Have you ever migrated the new project to the cloud from on prem without seeing a reduction in cost? Well, this is exactly a graphical representation of the quote that they just showed you before about simply doing a lift and shift and having a fancy data center where you really want to be is on the graph. On the right on this slide in this representation, this company has probably implemented the ecos optimization strategy.

There's no magic wand to to achieve this reward this graph. Uh but you will see uh that at the end of the pre presentation, i promise you that you will go out from this room with some practical steps to achieve this result. What is happening in this graph? Well, you see usage keeps increasing while cost stabilize or increase less. And to do that, you need to proactively rework on your fops journey.

A good fops journey starts from identifying an owner from your cloud financial management activities and establishing a good partnership across different departments such as the technology and the financial department to evaluating your cost optimization activities and educated your internal teams for continuous improvement. But also the cloud financial management is not a single action. It's a continuous journey. You can start small, continue to experiment iterate and continuously improve. You also need the right tools. And that's why in the next slide i selected for you. 14 tools from my experience talking with my customers, especially for the task that you see in the blue box here which are more operational task. You need the right tools here.

You have 14 tools that can help you in your path for establishing a budget, a forecast enable cost allocation cost, feasibility, cost optimization. We don't have the time to go through all of them. But please feel free to take a picture and go back to them in your own time. Most of them, by the way, are free of charges. So the only thing you need to do is activate them. You probably noticed that in this list, there is a tool that is a general purpose tool. Can somebody spot it? It's amazon quick site.

Why i put this tool in this slide? Well, many of you maybe don't know yet but this tool um in in 2021 aws launched cloud intelligent dashboards. The dashboards are the most comprehensive platform that we have where you can analyze and control your cost to achieve your operational excellence results. There are several benefits in using this dashboard. The first one is that they are easy to use. They have in one unique place, all the recommendation for your entire aws organization and they have actionable steps and autogenerated recommendation and they, they are ready made.

Second, they are free of charges, the cost that you see for them. It's related to the underlying services such as amazon s3 or amazon quick site. Anyway, we are talking about a few dollars per month depending on the company size fourth expert, they are secure because they are an aws native service. Uh so they guarantee the same level of security and four they leverage machine learning. So they have a high level of granularity and insights. But this is not just a reporting tool, it's also cost optimization tool. And here we have an example from the company dolby. They were able to spot some misfigure in their cerne cluster and they were able to cut their costs by $7000 a month. You can say now this is now one of their favorite tools.

Let's move to points number five optimized cost. If you remember the slide about the fops journey, you probably can recall that one of the points was cost optimization. But let's see now together some more practical steps for that. But first, let's do a step back. We need to understand what is cost and where it's coming from. Cost is formed by two levers. The first lever is usage and the usage is the unit describing the usage of each underlying service hours. For amazon is two instances gigabyte for uh amazon s3. And we take this usage and we multiply it by the rate which is the amount paid per unit of usage.

So if you want to reduce the cost, you need to work on the two levels first optimize the usage and use only what you need. Second, optimize the rate and pay less for what you use now that we have understood what cost is. Let's have a look at some practical actions for cost optimization. In this graph, you have some samples of them, you see they are in different colors. Because they are divided for inaction for beginner, intermediate and advanced user. Not all the cost optimization actions are the same. If you really want to have an impact on your return on investment, you need to prioritize them in the top right quadrant of this light, you see actions that have a rapid implementation and high impact on savings in the bottom left quadrant. You see actions that maybe have take more time to be implemented and have also less impact on saving but maybe they improve performance.

Let's have a look now together at one example for an action for beginner, intermediate and advanced user, the first action, the beginner and we talk about selecting the right pricing model like in every investment here. The recommendation and the suggestion is to differentiate the different purchase model and mix between on-demand savings plan, reserve instance, spot instances uh to adapt them to to your workload. You can save up to 90% with spot instances and up to 72% with reserve instance and savings plan. Since we talk about savings plan and reserve instances here there is a list of commitment based discount services. All these services are covered not only by savings plan and reserve instances but also by provision capacity. Again. Please feel free to take a picture. Many of our customers are already using a savings plan and imagine that since 2019, that here when they were launched, they helped our customers to save already more than $15 billion.

Let's dive deep a bit more. And let's use a concrete example. Um talking about generative ir services such as amazon bedrock and amazon sage maker. Uh the longer you commit and the more you commit you can get an ir discount. And we have, for instance, savings plan for sage maker that can help you to achieve up to 64% discount.

Moving to an intermediate action. We have aws intelligent tools. I have selected some tools here that you may know already. The first one is aws compute optimizer that can help you to improve performances and cost at the same time of your compute services. The second one is aws auto scaling that can help you to provision resources with precision responding in real time to changes. And the third one is amazon s3. Intelligent tearing that can help you to optimize your storage costs for non predictable workload without affecting performance.

Last but not least. Let's move to the advanced example. Uh we go back to artificial intelligence here and for those of you who are leveraging aws infrastructure for the artificial intelligence application, you can use our custom chips and optimize up to 50% using training instances and up to 40% using influential instances.

We talked about how to optimize costs. And now i leave you again with dave to talk about how to optimize time.

That's great. Thank you, serena. Um i love those uh the cost optimization dashboards, we have quick site dashboards everywhere within gp they're so useful and so powerful and actually really quick to set up. So thanks for your advice. That was brilliant.

So i think we think about optimization um like i think cost optimization is important, but i always like to optimize for time, time to value. For me. That's the big thing as we talked about for, for fast flow. And again, another quote, um one of the when the accelerated book came out a couple of years ago, this nearly knocked me off my seat. When i read it, there was a sentence in here that says, whatever the mission, how a technology organization performs can predict overall organization's performance.

So there was a time a few years ago when people would think of it as a cost center, how can we reduce cost? No, if it and technology performs well, it will progress the entire company. And this isn't just kind of a sentence someone spit out. This is, this is based on a ton of research that nicole forsman did. So i, i couldn't believe when i read this and there's a ton of research to back this up. But again, i've, i've spoke to lots of ceo s in my time and i, i, i often hear this line. If our engineers are so brilliant, why does everything take 18 months? You know, when i ask for something as a ceo everything is like, yeah, that's 18 months. So there's, there's some, there's something missing about how we can have great engineers but haven't got the capacity to optimize for time and fast delivery.

And so one of the, the, the model that, that i have in the book and the value fly wheel effect is this is pretty much it a a as we lay it out. And for me, it's about that the the the goal, how do we join business and technology strategy for me? And people think like, oh the business want that there is no business. We are the business, we work for our companies. We we we are invested in that mission as much as anyone else. So why not take ownership of that? So for me, there's four very important phases. First is clarity of purpose

The first thing I will speak with any team is why are we building this? Are we clear? What's the north star? What's the, what's the needle we're trying to move as we build this thing? We're not doing technology for technology's sake.

Second, environment for success - are the engineers able to challenge? Can, can we have a different technology, a different way of working is the environment set up for psychological safety that our engineers can be confident to kind of bring themselves to work?

Three next best action, what can we do right now to maybe prove a hypothesis? Prove an experiment, figure something out. You don't want to think. Let's let's plan for a year and see what happens. Let's do something this week that we will learn from.

And then for long term value, I mean, that's basically well architected. If you build those well architected practices in from day one, there's no kind of quick and dirty builds that we throw something out, but we've got to rewrite it. Let's build the quality in so we can have those things. You know, we're, we're thinking about long term value around cost security performance all the time.

So one of the ways that we do this within GP just to kind of illustrate this. So if again, I'm a, an architect that n GP and when the teams will come to me and say, we think we have an idea for a new business capability or something we want to build. The first thing I will say is ok. So we need to build, why are we doing this? And often teams will say, I'm not sure i was asked to build this. Ok. That's, that's ok. Let's find out what's the, what's the differentiator for this build? And the odd time, people are not clear and maybe there is no justification for that build, maybe we should just rent something from, from aws or a cloud writer.

Second, once you have clarity of purpose, what you're going to build, we vend an account straight away. We have a modern account strategy, we can vend that team an aws account. So that's their path to production, then they start building, they can build quickly. And then once they have a solution that we can iterate on, they can then take that into production and we start that cycle. So this shouldn't happen in months or weeks. Imagine this could happen in days. We can get ideas to production quickly and prove, prove our theories.

And so one of the ways we do this is have a a simplified building blocks, like you almost say, maybe like lego building blocks simplify what the engineers have to do. So we start with four very simple services, an api gateway lambda for serverless. So we, we like to write a single function for a business function. Be really simple how we write our, our software, use dynamo for storage and eventbridge for an asynchronous kind of architecture. And that means that we have a very kind of decoupled decentralized architecture that our teams can build really quickly. It's a really small, powerful selection of tools that create focus and reduce that kind of um cognitive load for teams.

So part of this is work and practice. So there's a great, also a great book out from um it revolution called team topologies where each team has a has a specific type. Be it a value team enablement team or a platform team? There's also a complex subsystem team, but i won't get into that. So if you think of the value team, this is the engineering team that's building your software for your business. What i want them to focus on is we've got four basic services we want them to use. I want them to be very clear on the event or the api design. What's the, what's the design of this component, this workload we're building, let's think about the business capability and maybe go talk specifically to stakeholders and be doubly sure. Let's talk to customers. Let's be very sure what we're building and that team own the workload. They're not gonna hand it off to anyone, they own that workload. So they should actually figure out what happens when we need to, you know, when there's an incident, when we need to look at some data in production, the team need to think through the run book the operational excellence of that workload. That's the dev team.

Then there's a couple of enablement teams, these these these roles help the value team. So i probably sit in this first box around. Well, architected, i will help the teams create well architected workloads by doing our kind of scarp process will help with system correctness. Make sure help them with maybe system verification outside their workload. We'll also help them with infrastructure enablement that we can effectively automate we use um backstage as a developer portal to help teams get their uh resources really quickly and then there's your platform team.

There's a lot of um excitement at the minute about platform engineering teams, which i think is a brilliant concept. But our platform team is aws we don't need to build that team. So i mean, we can lean on a for observable for heuristics availability, network storage, compute security. A lot of that capability is offloaded to the cloud. We have a small number of infrastructure enablement engineers just making sure that our opinions are correct. On top of that, i don't believe that we should build large platform teams internally. We should offload that again. That's the service first mindset. And that's what, that's what enables our value teams to go really fast because they have less cognitive load, they're higher up the value chain.

And again, one of the, the sans that we think of as slow, as smooth, smooth, as fast. So this is a different way of working for many engineers. It's a different way of working for many project managers. So what i often do is even slow a team down initially to learn how this, how this system works, how you work in an event driven way, how they can work in our stack. And once they understand that, then they can move really fast. So i think it's ok to just let teams understand the environment they're in and then they can really accelerate as they build production and build again and again and again, because again, modernization, it's not worn and done. It's constantly, it's like a rocket ship.

So next up, i wanna, um, bring matthew back to talk about um growth by sas.

Ok. So one of the points that, that david just brought up was the fact that that technology is now the business and i think that's key, that's a key trans transformation that's happened over the last 10 to 15 years. And one of the ways that's happened is through sas, through software as a service. And so one of the trends, one of the, one of the conversations i'm having multiple times a week with, with uh customers is how do i become a sas organization? How do i become a sas company? And typically, that's coming from 22 particular sources.

The first is a traditional software company that used the license software box, it ship it, they're looking to transition and become a true software as a service company. There's a second type which is, they were typically a services business and a really good example of this is globalization partners. So you heard david te tell their story about 10 years ago, they figured out how to do deliver a service to a, to a, to a particular customer set. Now they're becoming a sas company. So it's a non techology organization that's becoming a technology organization. And to be honest, it's the availability of aws that's fueled a lot of that. I would say 30% of the customers i talk to are going through or looking to go through that, that form of transformation.

But i bet. And i apologize for this slide. It's a bit of a bit of an eye chart, take a picture, happy to answer questions on it later. The key point is though, if i asked all of you for a definition of what sass is, i'd get 350 different answers and that's fine. Sas is a lot of things to a lot of people and that's totally fine. There are different types of sas organizations. What i would encourage you to do is to start from what your customer needs are. Who is the customer that you're trying to serve and work backwards from that and then choose the right sas model for you.

So in the slide, you can see on the screen, the, the uh the left hand side, the managed services and the managed services with subscriptions that's typically going to be a sass model. Um if you're going to have a handful of customers that require their own dedicated uh their own dedicated environments, their own dedicated infrastructure. Again, a totally fine model, perhaps your customer base um doesn't expect to have frequent feature updates. This model. These two, these two models on the on the left hand side are exactly what you should be looking at. What you need to be careful of is as you, as you on board new customers, making sure that your costs don't increase at the same rate. That's a typical, typical issue we see with this particular model, the two on the right hand side, the traditional sas and the modern cloud sass is, is really where we see most customers trying to get to. And again, it comes, really comes back to making sure that you have a modernized architecture so that you can on board customers in a completely low friction way.

So you can on board a customer in a matter of minutes, you're probably gonna be operating in a multi-tenant environment. So that when you do acquire new companies, when you do acquire new logos, you can see they're on board, the they're on board the platform, but your costs don't rise at the same rate that your logo growth is growing. So that's sas it's a hu it's a huge part of, of uh how, how i see technology companies impacting the overall growth of their organization.

The second way is around data honestly, if i had a dollar for every time someone had said to me, oil is the n sorry. Data is the new oil, i probably wouldn't be working right now. But with that said, and with the rate of data growth that we are seeing what surprises me when i talk to talk to customers is how few actually have a data strategy in place or how few have understood how they can monetize the data that they're sitting on.

So it's imperative, you've got to think about what your data strategy might be. And one of the ways in which you should think about this, particularly when it comes to monetizing your data is that there are really two methods for doing that. Two methods for monetizing your data. There's direct methods and there's indirect methods, direct methods might be figuring out how you can sell your data to other people. Um or how you could take your data to enhance some of your existing products, which is something that, that gp have certainly looked to do.

The indirect way is probably less obvious. It's how can you use the data that's within your environment to improve your overall efficiency? Could you are there, are there some telltale signs within the data that you have that could point to new customers or point to new opportunities in your marketplace? The key point around the indirect piece is that you have to be able to measure it if you can't measure it and you can't celebrate its success, it's not gonna last very long. So do that on the direct side of things, it's a little more obvious.

And one of the ways in which aws has attempted to help here is as we do by creating a marketplace for this data that's called aw s data exchange. And you can either subscribe from, from adx amazon data exchange, take perhaps purchase perhaps third party data, use that to enhance your point of view uh on your, on your own data set and then sell that, sell that point of view back on to your customers. You could also be a provider of data. So you could be, you could have a unique data set and you could be providing that data to a wx sorry ad x for customers to uh to c for customers themselves to consume. So think of this as like marketplace for data.

I wanna bring david back and i wanna give, give him, get him to give some insights into how gp are going about creating some of their products.

Great. Thank you. Thanks very much. So again, a as matthew said in, in gp, we're on, we're on that kind of journey to, to kind of the, the evolution of the sas. And for me, what that's really about as part of modernization to be really clear on your differentiators as a business, not as a technology team, as a business. I've talked about the kind of the people element, the technology element. This is purely the kind of the, the, the, the, the strategy element. And again, i love this steve jobs. quote, man's the top line, your strategy, your people, your products and the bottom line will follow. I've always not liked the idea of we need to reduce costs. So let's focus on growth and where we're going and everything else will, will, will kind of follow. I think that's really important. I always think about what's the top line growth and we should also as good hygiene

Worry about the bottom line. One of the ways that I think about this is this is called a domain map. So again, it's, it's a bit, looks a bit crazy but, but bear with me, if you think about model complexity on the vertical from low to high and business differentiation, you've got core supporting and generic ideas.

If you think of a GP, do we hire people that we employ people? So employment is a key capability. It's a key IP of GP. So we want to evolve that to be high differentiation. So we're thinking of that, that's where we plot it, we want to evolve it for to keep, keep improving something like building the ability to pay people globally in many different countries in a very flexible way. Again, that's something where we wanna reduce complexity and also evolve another capability.

We obviously have lots of documents, payslips, documents agreements, you name it. But like we don't need to build a docket management system. So we want um lower the business differentiation. So that's, that's uh like I would say a commodity thing. So it's one way of thinking about what are the, the business capabilities and and what do we need to build and what do we need to rent? And this is super important to have this clarified because sometimes people maybe aren't aware what technology can do for you to be super clear what we're about and what we, we can, we can kind of rent again.

I i talked about our idea of global growth technology. What we've effectively done is unbundled our main product into many smaller products, which is our GP Meridian suite. And as you can see what we're going towards is using a SaaS model. You'll help me employ someone, help me pay someone, help me get insights, help me with the marketplace. So it's about effectively, if you, if you think of our architectural strategy of unbundling to uh a a service first, well architected event driven system, this is exactly the same from from the company's perspective. So this is how we're starting to kind of we and we just launched this new category over the past couple of months. So again, i wanna give you an example. This is the technique that I've been using for many years. This is a, a worldly map. So bear with me here.

The book. One of the things about the book, there's a lot of about half of the book is about this technique. This is the technique that i use for modernization. If you think of the value chain from our customer and GP. So their customer is a company. So the company who want to hire someone, right? That's our kind of need. So I'll explain the um how this is structured on the vertical, that's a value chain. Ok.

So things at the top are visible to the customer, things at the bottom are less visible or maybe even invisible. And the, and the horizontal axis is the evolutionary axis, every capability and technology evolves. So you've got genesis, this is something that's brand new. It's like, you know, we've never heard of it. It's almost magical custom, which is, we sort of understand, but we're still trying to figure it out product, we understand it, we can build it. Well, there's customer need and commodity. It's the cost of doing business. You think about how computers have evolved? There used to be newspaper articles about, about a comp a company buying a computer. When it was genesis custom, there was many different standards products. The, the time of the, the pc on a commodity in cloud, you can get computers really easy.

So if i think of this value chain so that the key customer need there is to hire a professional that depends on employment and the ability to do employment. Say in a country that depends on compliance, being compliant within that country for, for uh labor laws, et cetera, that depends on operations, having the operations to do that and that depends on infrastructure.

So i, when i think of this value chain, some of those lower capabilities are less visible to our customer. So when i think of our modernization, i look at how do we evolve these things? So what do we need to evolve to the right? And that's all the things along the bottom. So we evolve our infrastructure via modernization and automation by leveraging a double s, we evolve our operations by automation and by you know, doing like maybe business process analysis and maybe even using some a i to to figure out how we can do better, we evolve our compliance by using some data techniques, they have better compliance. So that's we evolve the things on the bottom so we can focus on the things on the top.

Again, this is not a technology conversation. It's how do we think about business capability and, and one way to translate that is we don't want having tons of teams building custom, compli custom infrastructure. There's no, there's no ip differentiator for gp. So it's, again, it's a way of thinking about our value chain. What i would love, i love this quote as well. There's no business strategy without a cloud strategy. It's how it's, how do we really make technology work for us? It's about understanding the services and applying them in the right place. And so with that, i want to bring back matthew you talk about um leadership alignment.

Thank you. It's, it's quite the workout, this thing walking up that stage every time. So what we've talked about so far are really transformations, you know, again, it doesn't, it, it might not always might not always be easy but one theme, one thing i wanna leave you with um is andy's slide. Andy jessie's slide from 2019, reinvented. You're going through this transformation. The only way to do that is with senior top down leadership conviction. And i can't, i can't stress that enough. You've got to, you've got to have that, that top down direction, top down, uh top down belief, top down sponsorship.

But i also want to point out the third bullet point there, you know, the whole modernization journey is going to take some, some, some reskilling. It's gonna take changing the culture of your organization, potentially, it's certainly gonna be about learning new skills. So when you're going through any form of this transformation, the most imperative thing is that you train your organization, which is partly probably why you're all here this week. Um so I'm kind of preaching to the converted. Um but, you know, that's my view on it.

David does this for a, you know, does this kind of transformation for a day job, david. Yep, that's what i, i mean, i, i can't, i think those three points are brilliant. Um but what i think the most important thing is to have that leadership, leadership vision. And here's a quote by uh nicole sahan, she's the founder and ceo of gp. And she actually, i love this quote, enabling everyone everywhere to have access to the greatest jobs for the digital economy. is good for everyone. It's that ability that you can hire anyone anywhere. So that's, that's effectively the, the north star of gp. So to me and again, this, this, this all happened before i ever joined the company. That's that north star of the organization. The need for modernization was in supporting this. Everything else just cascades down, which i think is perfect to drive that modernization journey. And what we've talked about today is the structure of how to get that moving.

Perfect. Thank you, David. So just wanna wrap up with a few conclusions, you might have deduced that we like fly wheels, we like fly wheels. They wrote a book about fly wheels. Um i think that mum itself, modernization, optimization and monetization is its own flywheel. They all in some way, shape or form lead to lead to more, the more more you optimize the more resources you have to go do innovation to potentially monetize, bring new products to market and monetize and the modernization can fuel both of both of those two things. So think of it as like a flywheel. I encourage you to do that, David. Do you want to talk about modernization?

Yes. So like i say the, the the value flywheel effect came out um almost a year ago on it revolution. It's published in the us. Um again, it's really a handbook for how you get that, get that flywheel turning. Uh the link there is a qr code where you can actually see more about the book. Um i'd highly recommend cos again, we're putting a structure in place to how to drive this. It's not about technology, it's that structure you put in place with lots of things we've talked about today. So what i would do is think long and hard about how you can do this and, and, and get that flight w turning. And again, a as matthew said earlier, the modernization uh program are, are are brilliant for kind of helping us along well.

For the optimization point, we have seen that there are several benefits and the only benefits is not just cost reduction and cost saving, but it's also performance improvements. Uh and uh predictable budgets. The call to action that i have for you today is first to activate the management tools that we have seen together and second reach out to you aws dedicated teams. There's plenty of teams in aws like mine, a customer optimization and acceleration team that focuses on helping you in having customizable analysis for c optimization. If you don't have an aws dedicated team yet, please feel free to scan the qr code and fill in a form to request support.

Perfect. And then finally, on the monetization point, the qr code there will take you to a link that will tell you more about the migration acceleration program. So if that's something you're interested in, check out that link and go and find out some more information there. What i want to point out though is, you know, thinking about both having a data strategy and then and therefore monetizing that data. And also if you're on that sas transformation journey, there are programs and there are experts at aws that can help you with that, help you define what that data strategy looks like. Help you on that sas transformation journey. If you have either of those requirements, either reach out to your account manager or grab me outside, i'll be in the hallway.

Um, two final slides very quickly. If you're playing the snb game, if you're playing the snb treasure hunt, some of some of you will not know what i'm talking about. Um, and that's fine. But if you're playing the snb treasure hunt, your keyword from this session is mum, mom. So i record that and you'll, you'll, you'll win prizes, no doubt.

Um we all want to thank you for your time. We'd love your feedback. We'd love what we could do better. We'd love your feedback. Please do fill in the survey link, uh, that you see right there. Uh and again, we're, we're close to time. So if anyone does have any questions, we'll be outside, please feel free to grab us. Thanks.