How to create your own cloud computing strategy from scratch

A cloud computing strategy is an essential element of any business technology strategy

Cloud computing is here to stay, and it has had a dramatic impact on business technology strategies. In this video, Ben Scowen and I walk through basic cloud concepts and why businesses are eager to take advantage of cloud-based applications. 

We then transition into the history of cloud computing and what it can do in the present day. 

Finally we finish with debunking some common cloud myths and briefly discuss where the technology is heading in the near future and how best to exploit this technology in your business technology strategy.

00:00 Part 1 of 2: Cloud Strategy
00:14 Introducing Ben Scowen
00:32 Birth of the Cloud Native business
01:49 Can we define "Cloud"?
02:54 How it started:  Leveraging un used capacity 
03:31 Prime Time Technology:  Cloud is about 10 years old now
04:13 Keeping everything up to date is a massive task
05:01 Evolving constantly and continuously
05:38 32-bit Noughties Apps
07:13 Setting up for a business: Exploiting APIs
07:56 Constraints most businesses face
08:19 Every company needs to become a software company
08:50 Decide on the fundamental extent of attainable automation
09:33 There are not enough software engineers to meet current demand
10:17 A small core of focused engineers
10:43 Decide on what the business will be famous for
11:41 Everyone's writing stuff that's already been written
11:55 Do we have enough engineers to move humanity forwards?
12:59 Not all software engineers are the same
13:41 Let's talk Platforms
14:56 The core team
15:38 The core platforms will be available to buy in the future
16:21 Technology half-life
19:11 Beware:  Engineers love building stuff
20:15 Engineers must work within applied constraints
21:12 Build (and make distinct) the stuff you make money from
21:36 Team structure for scale-ups
23:52 Quick Recap
24:18 Lets talk about automation
26:01 Loose Coupling High Cohesion
27:59 Automation and open chords
28:35 A quick recap
29:05 Accelerated evolution - a nod to Ray's singularity
29:47 API as a product
31:55 The 10,000 Page Restaurant Menu
33:34 I just want Baked Beans
34:15 Business Technology
34:45 Borrowing from nature
36:18 Cloud Providers: Modules full of Modules
36:33 How many cloud providers should you have?  It's a bit like going to Switzerland
39:07 Managing Stress: Avoid Dead Ends
41:30 Cloud and economies of scale
42:12 Big companies need to think like small companies
43:11 SaaS is levelling the playing field for business technology
44:04 End of Part 1

Transcript

Ben: 0:00

If you're a business who, who thinks you're gonna go to market and hire all the best software engineers, you're not Tesla have already done that

Malcom: 0:06

Welcome to CTIO 1 O 1 Episode 6 Cloud Strategy Sponsored by Fairmont Recruitment, Hiring Technology Professionals Across the UK Europe

Jon Grainger: 0:15

All my guests have been incredible and Ben just keeps that bar going higher and higher. When you listen to Ben, it's like there's some electricity in the room, one of the things I really love about the channel is you tap into something that everyone's very passionate about.

Ben: 0:32

If I'm building a company, that company could be, I dunno, it could be building electric cars. It could be anything. And my job is to provide the best IT possible to that company. So it can deliver on its business business plan and its business, market. What would I put in place? How would I do it? Yeah. And that whole question about where does cloud fit? Where does data centers fit? Where does being cross, cross cloud know cloud versus going all in one with one cloud provider, all those things have been churning around in a kinda washing machine in my head. And the reason they do is because I've spent a lot of time advising customers on how to do it and actually thinking about how it organizations should be organized to help customers do that. When we start talking, you and me start talking about cloud and what an enabler it could be if done correctly. I think there's a wider context to that. And that wider context is really what is your overall it strategy and how does cloud fit into that? And that brings up an enormous number of challenges because of the nature of the cloud and the fact that it's moving, it's such an incredibly rapid pace, constantly moving a rapid place, almost exponentially which makes it really confusing, I think, and really difficult to work out what your strategy's actually gonna be.

Jon: 1:49

Cool. So one of the things there is a theme of the first few podcasts is the word digital. We have made a bit of a joke about it in the first episode said it's almost been taken over by the marketing department. There's no harm with that, by the way, we've all got to get a brand or something to get behind. But the point is when people talk about digital, they mean lots of different things. And sadly also I think some people just don't know what it is, but they just, say the word digital, there's a lot of different sort of instantiations of cloud. So I wanted to just an attempt, a bit of a definition and I think definitions of fun, as long as everyone remembers that they need to change and tech changes and the definition changes with it. So my definition of cloud, I'm gonna go a little bit old school and just say cloud a cloud strategy, deliberately old school. Okay. Ben a cloud strategy is all about your strategy of where you want to run your compute. If I was one of those belligerent folks that you meet occasionally, and I just said, oh, cloud's nothing more than just where you run your compute band. I dunno what the big deal is. What would you say to that? I dunno if you can detect I'm I'm I might be provoking you

Ben: 2:52

You very provocative Jon, but that's normal. I'm it's fairly obvious. If you think about it, the way this all started out was, Amazon had some effectively, they had a bunch of servers that weren't doing anything in the data center. So somebody said why don't we put an API on the front of that so that people with, can interact with that in an automated daily software. Then by doing that, they leveraged a whole bunch of unused capacity. Not only that made more money out of it. And that was the advent of AWS and their business. So cloud for me is, and I know you're being provocative, but what, but it's a really interesting question, right? Because what we go to, hopefully in this discussion is the cloud is coming back into the data center. And that reverse means that the advantages we're gonna get with cloud, which is essentially you can on demand through code provision out your infrastructure for your business. And just think about those words, right? So through code, I can automate the provision of the it for my business. That's knowing it's what 10th year. So this isn't, this is that's your, it being short and long term, this is not blockchain. This is prime time industry level, industrial level technology. And so that ability to automate everything through code to build out your it infrastructure gives you immense power, right? It gives you immense ability to do things, but it can cost you a lot of money, the skills to do what I've described. They, they cost a lot of money as well and getting them is difficult. And most importantly, keeping all of what you've just described, all that software that you're now using to provision out your cloud infrastructure requires maintenance and updates. And this is the crunch we've gone from that world of racking and stacking a data center infrastructure. There was some automation, of course there was scripts to a position where we can now completely codify that and go into things like get ups. And we'll talk about that later. And new ways of working that, that back, all of this up, but the fundamental problem of entropy, in other words, everything is always breaking apart is always trying to get to as low as form is still fighting us and more so now because they, this is the angle that I think we really need to consider the people producing the cloud. Aren't static. The cloud itself is evolving constantly and continuously. So once you've written that code that builds out your it for your business, it's almost out of date immediately. And there'll be another service that somebody wants to incorporate. How do you create a cadence? In other words, an update profile that fits with your businesses need to, to in innovate and take advantage of new technology. So backing up a little bit, it allows you to automate the building of your it and for your business, which is fundamentally what cloud that, that was the, that was this, that was the mind shift the paradigm shift for doing that. And it's amazing. It's amazing what we've got now and the ability to do what we can do.

Jon: 5:38

Here's a thought data center. I don't want one. My, my Board doesn't understand even what a data center is. It's expensive. I just want to get, if I could, if I could, yeah. Just get everything through third parties, cloud provision and all the rest of it, by the way. I know that is unrealistic, but let's just say everything, but unfortunately I've got some 32 bit apps that were written in the naughties. That's running all of my, either E R P or case management or. And literally just lifting that up and sticking it into the clouds, just gonna cost me more money. And there isn't any kind of automated stack that, that can run on there's a little bit, but it's just it's the wrong mixer. Really? What I've gotta do is get rid of those, that those 32 bit apps. So what, I'm, what the challenge I'm saying, Ben is, would I be better off just going hell for leather to get out of my data center and get everything into cloud properly, notice to say the word properly, whatever that means or should I be going for taking the best practices that the cloud folks have developed, in industry and then bringing them back into my data center, cuz I, these sort of infrastructure engineers are not 10 penny. And I'm just wondering whether the sort of the folks that wanna really run cloud hybrid locally or whatever might be more the SaaS providers than the SME company. I don't know. I'm just, know, there's so many things, there's so many different context, but I just wanted to run that one past you. Cause I think a lot of folks who will listen to this, everyone's got a 32 bit app they'd rather not have stuck in a data center somewhere, and it's what do you do with that?

Ben: 7:13

That is enormous. What you've just said there. It's enormous. There's so many different things than what you just said. But let, but let's the best way to, to break this down is to do it right. Let's do it. Let's actually imagine we've got a business. We've got a data center and we've got some stuff in it. Some old stuff, we've got some stuff that's that could be moved to the cloud pretty much as it is. And then really importantly, this business, it needs to Excel in the market. It's got new ideas. It wants to bring to market really quickly. Yeah. And to do that, it wants to take advantage of all, some amazing SaaS services, AI, all the wonderful things that we've got available now through APIs and code. But on the other we've got this, all this ambition, to do that. That's the, that's what the business wants to do. We've got some cost constraints. We've got some time constraints and we've got skills constraints. Yeah. And so the first question I'm gonna do, so I'm put my position in the CIO and this is how I think is, and we need to talk about automation. So put a note down. We need to talk about levels of automation, because this is the, there's a big, mis noma, but. Every, there was a few articles written. We need somebody to do some fact checking for us, but there was back in the early two, 2010, I think it was 2012. There was an article written every, I think it was originally written by somebody from NCAP. And then it was written by rewritten, by somebody from Microsoft, but it said every company has to become a software company. Yeah. Now that if you go back to what I early said about everything is automated code and we're gonna, when we go to the cloud, we're gonna build everything through a code. You don't have to, you could get somebody to, get the console and say, I'll have this server here and, do all manually. So the first thing we need to decide is when we're with this business, what we're gonna do and answer your question is, are we gonna go down a full software approach? Like level, level one, if you like full software or are we gonna be taking a more Simpler approach. We just automate some things through software, not everything is automated for this company. We're gonna go full automation, right? We're gonna automate absolutely everything. But because we know that we can't and we need software engineers to do that. And they cost a lot of money. So what we need to do is we need to think about how do we minimize the amount of software we have to build, which comes to your the, I think the premise of what your question had in it, which was, which means we have to reuse as much prebuilt stuff as possible. There isn't enough people in the world to write all the software we need to wrote. There was a great analogy. A slightly diverse digression. It was telephones. Remember telephone analogy, like back in the twenties, everyone was an op it was an operator, right? Your phones. I want to talk to John, you speak to an operator and they get a wire and they'd plug me to you physically through the system. They did the maths on that one. And everyone had to be an operator by about, I dunno, 1926 or something. Which did work. So you needed a system where you had an automation of the exchange. It's the old analogy. That software and that applies directly to software. We just don't have enough people. And if you're a business who, who thinks you're gonna go to market and hire all the best software engineers, you're not Tesla have already done that. And so if a bundle of other really wealthy companies, the strategy we're gonna employ in this fictitious company is we're gonna have a core set of well paid software engineers who know what they're doing. You're gonna have to pay good money for those people, but you wanna limit the amount of work they need to do. So what we need to do is whatever we do relies on as many services that are out the box as possible. And to do that, we need, we do therefore need to move most of our business into the cloud. That's the way my mind thinks about this.

Jon: 10:43

Ben, that core that you keep, you keep your software engineers around. That's the bit where you've decided that's, what's gonna make you famous. I don't. I don't mean to make the CIO famous CTO. That's the bit that the company, if it is operating through software or through automation, it's the area we say, you know what, there isn't a product that does this. Or actually this really is our secret source. The way we secure tickets for concerts is that algorithm. That's what we're all about. And that's what we will maintain that we might actually end up sticking an API in front of it and selling it to others and doing an Amazon. But nonetheless, that's that kind of what we won't do is having engineers reinventing how to do containers or how to implement servers or cuz that's just doesn't make any sense. And just a quick one back to you on the telephone conversation, cuz I'm seeing it. This is so obvious everyone's seeing it, that there will, there is not enough software engineers right now to satisfy demand that one of the episodes is around open source. I interviewed a guy, an open source and what was really interesting. I've heard you say this as well. Ben, I'm pretty certain of it is that reckons loads of companies are writing stuff that's just already been written. So to go to your telephone analogy, there's a lot of people making exactly the same telephone call. So if you took all those telephone call conversations, duplicates out, we might still just about have enough engineers to move humanity

Ben: 12:04

forwards,

Jon: 12:05

there's a statement.

Ben: 12:07

we, and we might not. And that's

Jon: 12:09

we might not.

Ben: 12:10

One of your future episodes, I'm sure is gonna be a bit AI. If you've not already done. One is where this all unravels at that point. I There's some, if we just take little step back, I'm sorry to quote Mr. Musk, but I think it's really important. Some of the things he's been saying recently is we've got a population. I know it's not how much just saying this, but we've got a population that's gonna decrease, right? We've got more work than ever to be done. So our economies are all gonna be restricted. There's not, it's not that there's not gonna be enough jobs. There's gonna be too many jobs. And if we don't have people in the right skillset to do that work, then it's a problem. But we do need to accept that at some point there, we're not gonna need we're gonna use AI to build a lot of the stuff we need to build. But it won't stop it. Be still tons of stuff to be done by creative software engineers to do exactly what you said, which is the actual business and thing. And and if we go back to what we were just talking about in terms of this company we're now gonna build in the cloud. We now we've hired our killer set of software engineers. They're not all the same, right? This is the big mistake everyone makes. Oh yeah. We hire some software engineers. There's a huge difference between somebody who builds a platform in the cloud. And a platform is the new infrastructure. Let's remember that. Yeah. So everyone's talking about platforms now and what they mean is collections of services that provide you a foundation on which you can give it to a really high, skilled engineer to build some really cool stuff. And those platforms, you get a variety of them. They could be focused on software engineers. They could be focused on business people as well. You could have a platform that's designed for a business person.

Jon: 13:41

I think of a platform, like a workshop, it's the workshop with all the right tools in it. It's, everything's there and then you just go in and you can use it.

Ben: 13:48

No, I agree. So we can't keep going back to first principles. We've gotta use stuff that's built. And that comes back to the point you were making a minute ago, which is everyone's writing stuff that's already been let's give some examples of platforms so that everyone's like on the same page. So I'm building this company, we're gonna be in the cloud and we now need some platforms. So what platforms do we need? Cuz there's more than one, right? There's gonna be a platform that is the effect. They think of the landing, the whole area in the cloud, which is secure. You think of that as a base platform, which some people call it landings or a cloud foundation. Then on top of that, we're gonna have all the development tools and run times to run workloads. And this is predominantly be used by our software engineers. Those really clever people who are gonna build some APIs or apps or whatever they're gonna do, but then we're gonna have also other we're gonna have a data platform, cuz we're gonna wanna understand what everyone's saying about is we're wanna make decisions based on data. We're gonna wanna do all that stuff. That data gives us. We're gonna have a platform for customer relationship management. We're gonna have a platform for telephony contact center. How are you gonna engage with your clients? I think there's about 10 platforms that most businesses need right now. The people that are building the fundamental underlying platform, that's your core team of cloud engineers. And they're gonna be well paid, highly motivated teams. You wanna keep them the longer, you can keep them the better, but what you don't wanna do is have them build stuff that's already built. Yeah. So what we're gonna do with that team is we're gonna say, we've got these 10 platforms we wanna build to, to power our business and that, and know we can do more on that in a minute, but we've got platforms that are gonna build APIs. We're gonna build to build containers. That's engineering, techy stuff for those aren't taking that's not so important, but it's really important for your business, but then you're gonna have that contact center, with, all that thing. So those things will all, but they're all set on the cloud foundation. Which is common. Yeah. All those fundamental platforms, they're all gonna be available by Microsoft, Amazon, and Google in the future. They're not there yet, but they're gonna be there because they're just moving further and further up the stack. And there are huge software companies and wouldn't it be wonderful if I didn't have to do any of that, I could just go in and say I'll buy it right now. There is a problem with money. We need to talk about automation and money. There's another little footnote we need to talk about cuz the cost. Is that how you manage costs in this environment I'm talking about is personally, I think that's probably the hardest part of all of this. Maybe keeping it up to date is the hardest part, but then keeping your costs under control. And they're probably linked those two subjects. But let's see, we've got our team. We're gonna build our platforms, whatever those platforms are in the future. Those platforms that we build now will be obsolete. And I want to just dive into thing here. This is really, I think this is really cool now. I dunno if you guys who's done chemistry, right? I was, I loved chemistry now. There's a, when you do it, look at a chemical reaction. There's an initiation phase. There's a propagation phase and there's a termination phase in most reactions. Yeah. So like a nuclear bomb. The initiation phase is really fast. The propagation phase is extremely fast and the termination phase is extremely fast. That whole reaction happens really quickly. It's thing. But if you look at a candle the initiation phase is really, quite quick, the propagation phase takes ages until the candle's burned out. And eventually the termination phase is pretty instant, so if we take If we take a platform or a platform we're building in the cloud or take any piece of software for that matter or any service, let's think of it as the platform, as a service, it's gonna go through that phase and you, and your, it infras your it services. You're gonna give to your business to, to create those amazing outcomes. You're gonna have to manage the initiation, propagation and termination phase of literally thousands of pieces of software, right? All working independently, all working sorry, not they're integrated to work together, but independently. They need to be thought about which this is, and this is the point, right? So the more you can outsource that whole thinking and buy a lump of software that's built by somebody else the better cuz otherwise you're just gonna have to create more and more software engineering teams who are gonna manage all of that.

Jon: 17:53

Someone in the competition is gonna be doing exactly as you describe, and you are gonna be putting all your technology resource into trying to manage those reactions. Whereas the other company they've got that covered through a cloud provider and they're working on the bit that makes them famous or the secret source, or, that, and it just gets worse. Doesn't it? The, your analogy of the reactions. I think it's absolutely fantastic. It's basically for me, what you just said there Ben is, it's like a, an analogy that kind of explain to what patching is all about. It's not just patching cuz it's also just the evolution of all those bits of software. They do different things that, releases come through. The API changes, the security, there's all sorts of stuff that goes in that mix, but it's right. Isn't it. You, when you're trying to do it yourself and you're trying to be on a par with someone who's getting it from cloud, you're probably playing a little bit higher than you actually can, because you won't have the resources. That someone who's consuming it from cloud are just getting it. It's a bit like, one person trying to create their own TV channel and broadcast beacon and distribution network

Ben: 19:00

Exactly or used YouTube. Precisely. So we've got so, so what's nice about what we're discussing it's developing is we've got this company we're gonna use, we're gonna build platforms. I'm an engineer background, software engineer, and an architect. I spent my life trying to stop software engineers, build code, literally. That's what I've been doing. So I was never, I wasn't always liked because somebody would've a great idea to build a bit of code and it's somebody's already done that. Why are you doing that? And it's because engineers love building stuff. It's not cuz they're terrible people. So what's really important is that you have really good rules in place. Do not this idea of being engineering led is so dangerous. Because what they do is they take the context of somebody like some amazing, I dunno engineer who runs a company, Larry Page or Elon Musk who just engineers. Who rock. Do you not think they worry about the profit and loss of their business? Do you not think they're worry about the cost? Of course they do. Cause they're engineers with business skills. One of my pet, Hey, just while I just wanna say is, I think we companies need to take engineers who can make it to run companies by the way and immerse them in a profit and loss, Immers them in running their own account. Cause if you can take those people and make them into your Musks and you like, they can run companies amazingly. Engineers need to be within constraints, right? And the constraints have gotta be really simple. Don't write code unless you need to reuse as much stuff as possible. And minimize at all costs the amount of maintenance and upgrades that you need to do, that's the basic principles and then cost everything comes out of that. So if we wind this back cuz we went, so that was my apologies with a few rabbit holes there, but we're building this business, we've got our platform strategy, we've got a team that can build those platforms and we're gonna use dev secs to keep them up to date. So in other words, we're gonna, it's gonna be high frequency, automated delivery to deliver out changes as quickly in as fast as we want to. So that's like base level one. Yeah. And that team should just do that and that's them, then there's a bunch of other teams. And you're gonna have a lot of these teams. These teams are gonna be software engineers, but they're not building, they're not cloud engineering skills. They're not using, Terraform and all these scripting languages to build out stuff. And the different cloud providers, they're gonna be building the stuff that you make money from. They're gonna be actually they're where you need to really have a lot of those teams building, trying things out in the market. The platform is just a cost, right? It's just a it's almost, we should even be talked about. I know we've talked about it, but it's that separation. I think it's really important that you have those two sets of teams. I've seen a lot of companies try to vertical teams that do both those things, and it works at small scale, but as soon as you scale it out, you end up finding that every team builds their own platform. And you've got lots of duplication. So that's that in a nutshell, that's how I approach the cloud, get your operating model in place. So you've got your different types of engineers make them reuse as much as possible, except that things are gonna get outta date because you've got this initiation, propagation and termination phase. So everything you build one day will die. So the question is how you gonna manage that? How you gonna create that propagation phase. What you're trying to do is create as longer propagation phase as possible. Yeah. So that you get as much out of your initial investment

Jon: 22:17

Engineering led, okay. I totally get it. And I think there's also a bit of stove piping that goes on within lots of different organizations. Engineers will create things in a vacuum, and if you've got the wrong governance and you create a vacuum between the business and the engineering community, you'll get, you can get vacuums between two engineering groups. Can't you, when you know you're talking about stuff that's already been written, you can actually create the same thing twice in the same organization. If two teams aren't talking to each other, it's so easy to do. There are some really big historical figures, who have an engineering basis. But that have really changed the world and also made a fantastic kind of commercial success of that. So I think the engineering's in there, but you've got to couple that with the

Ben: 23:01

Yes. And

Jon: 23:03

as well.

Ben: 23:03

It's that classic,

Jon: 23:04

the mix,

Ben: 23:05

feel fast which is ridiculous. If you actually break it down, we don't wanna fail fast. That's terrible, but it's but failing fast is actually obviously good if you learn from the failure. Yeah. And it's the same as engineering led for me. It's engineering supported, but engineers need to be aware of the cost of what they're doing. And most of the time they're not.

Jon: 23:24

Fail fast is just realize you're doing something wrong really quickly and stop doing it. It's common sense, but it's interesting that the sector needed to be told that because I suppose of where maybe we got to as an industry with some of the waterfall projects where, nobody really knew what was going on. The momentum was so great. Some sort of super tanker was going to arrive at some point, everyone that had started on the project had left before it had gone live, all those sorts of things. So maybe that's a little bit of where that's coming from, but okay. So we've got our, we've worked. where we want to make our big business technology investments. I think Ben is what you're saying. Not maybe not when, but how so in it, we're saying let's not reinvent cloud. Let's make sure we're consuming getting the right candles in so that we can focus on don't wanna go down the candle route too far, but the sort of the ceremonial value around the candle whatever makes the candle special is where we wanna put our efforts.

Ben: 24:18

Let's talk about automation, right? My job to essentially run the cloud part of a big global systems integrator. What I'm thinking about is and that business comes from an infrastructure background, and actually what we've been talking about for the last 20 minutes, 30 minutes, whatever has been about software engineering. It's so different, a subject that the people having the conversation, a lot of the times don't understand that there is a such a separation. There's a huge difference between automating a UNIX script that provisions a virtual machine or some security process and building an object orientated program that, that has structure. And it has patterns all working together.

Jon: 25:06

It's the creative equivalent of building a desk or making a car, they are, it is all under the guise of technology and you can't see it, so people think it's the same it's software, whatever, but the actual functionality, the function that you're creating is so utterly different and used in a very different way. Yeah. And you're right. I think that is probably a complete mystery

Ben: 25:27

Yeah. You, I think you're right. And so when we talk about automation, it's a bit like engineering level. We just talked about it gets taken outta context and it's like that means put all the engineers in charge. Don't do that. Automation also has the thing, oh, why not? We have to do, we're gonna, we're gonna automate incrementally our existing services. Of course do that. That's a really good thing to do, but don't think you're gonna get to where I've been describing. You're gonna get to in the future where it is full software automation. Yeah. Because full software automation requires you to think about it as software. And so the one when I had my degree, a software engineering degree there's one pattern. I don't, I dunno, this was probably around in the Egyptian times. It's probably round in the caveman times. I dunno. I dunno how far back you think the world goes. I'm a believer that we go back a lot longer than everyone thinks we do, but I guarantee you, this concept was around and it's called loose coupling high cohesion. Which they obviously, probably didn't call it that at the time, but go with me for a minute and what it means. And you see this pattern in everything from supply chains, food sys, you making food governments, European union I'll explain the analogy. And what the idea is that you create modular things that work really well. Let's take the cell biology of your body, right? Each cell works really well. It's different cells are different, right? There's multiple versions of the same cell, but each there's fundamentally different cells. Those cells are modular. They have their own life cycle. They have their own initiation, propagation, termination feedback to our chemical. They have their, all of that going on. But they work amazingly well together. Imagine designing a human, it would. Will it be impossible evolution did it right. When we build software, we're doing the same thing. We're, we've got these small modules that we're gonna build and they're gonna work really well together, right? We're not creating a set of separate modules and then working out how we're gonna put them together. We think about that in advance and that's essentially what software design is about. Now you can apply that analogy to a government, right? You could have a set of governments, all working together at the European union who are pre autonomous, but through a set of rules, they engage the Mon financial systems are all integrated. They, the travel systems are all integrated. It'd be, it would be like almost crazy to not see that as an advantage when you've got all these companies, because you're reusing common mechanisms. Yeah. Again, back to our software analogy, exactly the same thing. So if we think of the cloud as lots of modules we, our job is to take those and integr'em together and augment them with modules that aren't built and are giving our unique, selling point, our USP, whatever that might be. Automation is just a subset of that discussion. All automation is about is taking the manual processes out of doing something. So if we take a software engineering approach to automation, then that, then we conclude that. We've gotta think about all of the stuff we've been talking about in the previous part building platforms and all of that think, oh, that was my sorry, if you could hear that my guitar. Yeah, it was my guitar. Yeah.

Jon: 28:22

The guitar.

Ben: 28:23

Yeah.

Jon: 28:24

I think it was a E sustained

Ben: 28:25

that was a chord by the way. It was a, maybe you're right. Maybe it was open.

Malcom: 28:30

This Podcast is Sponsored by Fairmont Recruitment- leading the way in technology recruitment across the UK and Europe.

Jon: 28:35

What's really cool about our conversation. Like you say, Ben, we've started off with the platform, with literally the infrastructure. Yeah. We of explained that and we've said, you don't really wanna be building a road, use the road outside the front of your house, that sort of thing. So we've done the infrastructure. We're now moving up into the software side, we're saying that's, this is like another game, completely different, totally different set of skills, much more integrated with the business. Of course, what you've done by using the infrastructure of cloud. You've got all that investment that you haven't had to spend. You can then divert it to, the higher order things. Just a couple of things I wanted to talk to you about the cells, the atomic nature or the Lego nature of everything, which I think's absolutely fascinating. So two things I think are happening at the. one is there are new bits of Lego

Ben: 29:19

her a massive rate.

Jon: 29:21

day. And it's not one bit it's not one bit of Lego. It's the

Ben: 29:25

It's Jon. Jon it's like when you were a, it was like when you were a kid and then you brought you bits of Lego out. What did you want? You wanted to use them, right? You didn't wanna not use them. Think how imagine, trying to resist that. Sorry. Back to you.

Jon: 29:37

No, you're absolutely right. And I've my most recent memory of Lego though, is stepping on it as a parent. So Lego has a bit of a sweet and sour kind of memory for me. But the second one is you think about all those bits and bobs that are coming out, all these bits of Lego, one of the ways to articulate your Lego is an API. An application programming interface is the sort of the software engineering term for it. But think of it as a way of asking a question and getting an answer back and not really knowing how that answer was formed, you're getting messages back and forth. I had a look at a website that was of listing APIs. I was doing a bit of research on what is it? Stack overflow and all those sorts of forums looking in. And I couldn't believe it. There were millions, and millions of APIs that are being published. So Ben, when you're talking about the reusable elements of the infrastructure, we're moving up into the API, sorry into the software software engineering world. And what my observation has been is that is also becoming available in millions and millions of componentized individual chemical reactions that are occurring. And they're coming to you through the form of an API. So you and I could sit down as, as good engineers and in entirely in good faith and say, we need to write bit of software that looks at a picture and decides whether it's been doctored or not. Cuz we want to check, to see whether the picture that's being sent in has got any kind of red flags associated that it might be a fake, so what we do is we look at it, we go into the JPEG first off JPEG bit suspicious. It's a lossy format some things going on, but we look at a pattern and we find a pattern in the pixels that shows that there's been a smudge and that's a sign that maybe it's been doctored by Photoshop and that's for the red flag. We write it all we think, oh, so cool. How good is this? It's our baby. Here we go. Look everyone. Aren't we aren't. We amazing. And someone turns around and says, you can just get that already as a free API call from XYZ. Do you see where I'm coming from? I looked at the APIs the folks that are listing APIs, they're very much written for the eyes of engineer. But I think, unlocking and creating what APIs are available and making that, putting that in front of the business is a massive gap that, that could, that should really transform, the shortage that we're talking about, Ben, the shortage of talent. There are probably right now teams working on that exact use case we talked about

Ben: 31:55

I wanna come expand on what you said, cuz you've fundamental and it, and what you're alluding to is the utter complexity and choice that you've got, right? This is like going to a restaurant and we given a 10,000 page menu, right? It's oh my God, I just want beans on toast. Take this away. And that's the problem we face because the APIs, essentially the communication mechanism between the modules. And that, as you say, that's what gives you interoperability, you don't care how somebody implemented the API. They can do however they want. They can use a steam engine for all you care. That would be pretty difficult, but it, and you, yeah, exactly. But you, but the API is standard and there's a web 3.0 standard out there. Every window is what that standards, HTML and the backbone and HTTP the protocols behind that been around since the early nineties. And Internet's based on them. So we've got an amazing situation now where we've got the in internet, we've got the communication channels, all standardized we've. Now we've got this enormous number of services being produced, all being exposed through these APIs as you described. So we really can construct whatever we want. No, there is always gonna be additional work to be done, there is definitely gonna be additional work to be done, you, and we've got the whole propagation termination, so initiation, propagation, termination problem. Cause each of those things that we use, somebody's also managing their own life cycle in there, the security, everything, right? So you're now reliant on them doing the correct job. So how the hell are you gonna manage that? So the only way you can manage that and mitigate that is that you can swap that thing out quickly, as part of your core team. So if we go, if we step back, cause we were talking about automation, weren't we?

Jon: 33:34

Let's recap. We're at the you've gone to the restaurant. You want baked beans? They've given you a 10,000 page menu.

Ben: 33:40

Each of the bits of, each of the recipes on. Got another 10,000 bits in it. So it's just horrendous the complexity of all of this. So the way to mitigate it is to go back to that fundamental software engineering principle of loose coupling high cohesion. So things are modular and they really work together, but they're not so work so closely configured that they break and you can't swap them out. And that analogy, sorry, that pattern has been around forever and that's what you need to base your entire IT strategy on basically.

Jon: 34:15

And actually Ben I would also extend that to your operations strategy. A lot of what we're doing in business technology is automating the business operation. They're and when a business becomes software, the quote we used earlier, your it's really your business operations are in software. So when you are designing a customer intake funnel or a way of dealing with processing, whatever that is that the ability to decouple or the loosely coupling that you are referring to is just a really sensible design principle, because it gives you the ability to swap and change things around even operationally speaking.

Ben: 34:45

Just quickly on the, without going too, maybe going down this too much. Our bodies evolved. Nobody sat down and said, let's have a high cohesion, loose coupling pattern. And we'll use that to base the human body on it. It naturally occurs, right? It naturally occurs in everything around you. Yeah. And the problem you've got is when you put reliance on one thing and there's no resilience in it. So if we had one, we were made up of like 20 cells, that would be pretty bad, they could work really well together, but one cell goes out, it all stops, obviously that doesn't work same with the computer system. So when we're building out your, it, you've got to then think about having more than one of the service that you're you're dealing with. And you can do that on different levels. So you can do that. Imagine you're using a SaaS service, you might say I'm gonna let that the SaaS people providing the software as a service to me, let's say, for example, Salesforce, using some Salesforce CRM solution from them, they're gonna deal with resilience for me. They're gonna deal with everything for me. They're gonna give me a service level agreement. That's gonna be fine. So I'm gonna rely on them. You might decide that's so critical to your business that, that, that service you don't want, just the relationship with Salesforce. You also want the relationship with another provided of the same service, for example, SAP. I'm not saying you do, that's probably not the best example, but and why would you wanna do that? Because you, maybe we want to leverage some form of position with them financially. You maybe want to so that's the point. Now, if you then take it, if we go back to our platform analogy, cuz remember this is all modules, all connecting together through these APIs basically at every level, right? That's how cool this is. You think of the cloud providers as modules as well, right? But there are modules full of modules. So you've got Amazon, you've got a Azure, you've got Google and we'll go into the on-prem thing and thinking in a minute as well, we can talk about that. So each of those, they're not the same. There's a lot of commonality between them, but it's a bit like going to Switzerland. It all feels a bit the same but the road's slightly different and the way that they do, they make the foods different it's differences. Cloud providers look and feel the same, but they're not they're different countries. And they have different legal systems. They have different conversion models, they have different everythings. So you've got a decision to make, we got a decision to make than our company. Are we gonna choose one of those cloud providers or are we gonna produce a number of them? Why would we choose two of them? I was a Java programmer. And I also programmed in in visual basic like shows was my age. And a few other languages. And I tried to maintain both disciplines, but it was really difficult. Cause the Microsoft ecosystem was different to the job that, the sun Microsystems job open source. I was an open source guy in the end. And you just couldn't keep up with it. Well cloud providers. Exactly the same. So what I would do is if we have our software engineer, teams are building these platforms for us, I'm gonna have one team dedicated to Amazon. That just do Amazon platform build and one team that do Microsoft platform build that is if I want a dual strategy, why would they want a dual strategy? Because they offer different things that you might wanna take advantage of, right? They're not all the same. They're bringing innovation at different rates. I also might wanna do a deal with them and leverage them against each other. It gives me that ability to do that. What I wouldn't do is try and create services that run on both really, know, maybe an application level, but at a platform level, I'm pretty much gonna build them cloud natively on each of those different, so the point here is you've got this idea of modular things you're gonna use that are connected with APIs that work really well together. And you have to think about that thing again and again.

Jon: 38:10

You are not trying to say, how do we get everything in Azure? How do we get everything into your that's? That's pointless. What you should be thinking is how does everything work together? Are we getting the best of all the different elements? I think we, we're definitely gonna talk about money and cost at a point, but that's the principle isn't to get hung up on where you're getting these services from. Obviously if you can get both identical services from two different places, you might say for common services, I'm just going to favor one, for simplicity, or maybe they've got a more competitive billing or something like that.

Ben: 38:41

In the earlys, it was easy, cuz it was hardly any services on the cloud providers. So therefore you had to build lots of stuff up the stack. So therefore it was actually quite easy to build something that will quite easy, but it was possible to build something that would work on both, but that's all changed now. I've completely U-turn to my philosophy. My philosophy now is I need to work out how to take advantage of their services really quickly, but also be able to upgrade and move off them if I need to. Which is not easy either. I don't pretend to have the answers, all the answers. How do I manage stress? Let's talk about stress. John stress is something that we all don't like, but we know we have to deal with. And we all now know that stress is a serious problem, across our society. So the one thing that I've never really stressed about, and this sounds crazy is when I'm building huge computer systems, and the reason that. I never personally stressed about it. And I don't mean to be arrogant. I don't get me wrong. I was nervous about things and things go wrong. Whereas, because when I was designing them or when I was, when my team would design them, when we were design, I was part of a team. When my team, we were designing stuff together and a number of different scenarios, different customers, different companies. The one thing I learned was you've got to, and you can do this in any part of life is it's all about options. I only get stressed when I think I've gone down a dead end and there's nowhere to go. It's like getting down an alley and the muggers are behind you. And it's oh I'm getting mugged now. That's stressful. So when I, when we design computer systems and we wanna design these things, we've got to give ourselves options. We've got to give ourselves the ability. If that supplier goes bump, we can do something else.

Jon: 40:17

Yeah. And I can, I just wanna relate to that mugger scenario that you just played out there. So I've spent the last five years on the other side of the table, having spent the majority of my career advising and know, I've, I took the advice I gave very seriously. I think there's a sort of a DNA thing about people in our space that have a lot of personal accountability in any case, but sitting at the other side of the table and actually making the decision and living with it, it's entirely different. And I remember making my first couple of decisions thinking, that kind of nowhere to go. We are absolutely, we are burning part of the candle now, which will never, ever get back. And we just need to make sure it is it's really tough to navigate because you can make a decision that two years ago made absolute sense. But now, actually it's changed. It's the old, can you tell me how to get to London? And the reply is wouldn't start from here, that, that kind of, scenario and it's changing so, so quickly. It's very as I imagine this, a lot of people listening that will, be wrestling with that. And that's why, your cloud strategy is so important because if you're thinking it through in the way that you are articulating it, you're giving people a bit more of a repeatable process to go through, to really sound out their strategy FSTE 100. Yeah. And then you've got your small to medium size enterprises. You've got everything in between. They've all got different resources. They've all got the ability to do different things. Some have got access to the top consultants and engineering in the world, Google actually provide direct services. Don't they for certain types of clients. And then you've got the vast majority of people who probably don't know they're using cloud or or, they, I'm just trying to work out from a cost perspective. What we are talking about, is there a point where this tails off and is not relevant to smaller companies, or actually, is this something that you think you can take to, to anywhere in the market.

Ben: 42:12

I love your question. And the reason I think that is it's the whole, is it, was it necessity is the mother of invention. If you're a small company and you don't have the ability to go to the market and buy lots of clever software engineers. And announce to the world, you've done that and create a fanfare about it. And you've just gotta God, how do I get this service without it costing me too much then that limitation of options to use actually an advantage. Yeah. And that's what I think when you're as an enterprise building, you've gotta think like a small company in sense of, I don't have an endless budget. I don't have endless numbers of their software engineers. My people that work for me will never be software engineers. Let's not try to make them software engineers because there are not software engineers. So I need to take a different strategy. And so what the small company's doing and know I've got friends and I'm sure you have, if you've got small businesses and I'm intrigued how they're doing it, and they're basically just using SaaS services everywhere, and it's ingenious in really the way that they're operating at all.

Jon: 43:11

It's amazing. Ben, you can get a monthly license on one seat on pretty much all the cool stuff that you'd get in a big company now. and you're just paying for your own seat license. Except also you haven't got anyone telling you that you can't have it shadow it, or, that's not the system we use and all the rest of it. And you got this good, amazing access to a system that even five years ago, you'd never be able to get hold of. And the AI tools that are coming out and all the different things of the platforms you're right. It is actually, I think they call it democratizing, but maybe another way of putting it is the barrier to entry isn't there anymore. And I think it's really fascinating, Ben, that you are saying actually, if you're a big company and you think big that's the wrong, you are gonna catch yourself out

Ben: 43:58

triggered me a little bit there, but when you, cause I remember you, me talking when you were a CIO, I think your previous company, you had a three way strategy didn't you?

Malcom: 44:04

Thank you for listening to Part 1 of Episode 6 Cloud Strategy Sponsored by Fairmont Recruitment, Hiring Technology Professionals Across the UK Europe. My name is Malcom and to me the cloud is where I exist, its perhaps the silicon equivalent of your Universe except of course mine is infinite. Part 2 will be published in a couple of weeks and dont forget you can see this and all of the other episodes as edited highlights on our YouTube channel. CTIO one O one. Business Technology. Simplified. and Shared.