August 15, 2023
Season 1, Episode 20
In this episode, Jay engages in a deep conversation with Richard Simon from T-Systems. They discuss the challenges and intricacies of cloud migration, the importance of having a clear strategy, and the evolution of cloud technologies.
Guest Introduction:
Richard Simon is a seasoned professional with T-Systems International, a subsidiary of Deutsche Telecom, the German Telco giant. With over 30 years in the IT sector, Richard has worn many hats, from technical presales and architecture to consulting. He currently focuses on cloud migration, helping clients transition smoothly to the cloud. Richard’s passion for technology is evident, and he brings a wealth of knowledge and experience to the table.
In This Episode, You Will Learn:
Themes Covered in the Podcast:
Quick Takeaways:
Follow for more:
Jon Shanks: LinkedIn
Jay Keshur: LinkedIn
Jon & Jay’s startup: Appvia
[00:00:00] Jay: Thanks rich for joining us on cloud unplugs. Great to have you here. Pleasure. Give us a bit of an intro. Who are you? What do you do? How do you end up in this cloud and Des
[00:00:07] Richard: World? It’s crazy. Cloud DeVos. Yes, I’m Richard Simon works a CT Fort Systems International T Systems is part of Deutsche telecom, the German Telco giant. Yeah. So my role is really kind of working in the migration space so we help customers really migrate to cloud and kind of all the things that go along with that personally. I’ve been in it for over 30 years, so I don’t look in time. Yeah, a bit of an expert, I guess on various things and, yeah, I mean, I’ve come really sort of, you know, the kind of always had really a passion for technology. So if anybody’s actually seeing my t-shirt and probably, maybe you should do a competition kind of tell what that t-shirt
[00:00:48] Jay: is, right? Won’t give it away too much then. No,
[00:00:50] Richard: let’s not do that. You may want to do that later. But yeah, well, maybe it’s a competition or something. But anyway, yeah. So I’ve, yeah, I’ve always kind of been in, it’s been a really a passion of mine and I’ve really kind of enjoyed doing different types of roles as well. So I’ve done everything from sort of technical presales, architecture and more kind of recently consulting approach and obviously now kind of focusing more on the sort of the sea level, so
[00:01:14] Jay: always copying a customer rather than sort of internal teams deliver on an outcome.
[00:01:19] Richard: Yeah. So, and there is a sort of a clear distinction there between sort of doing it for a particular enterprise where you’re kind of part of an I T team or an I T department versus actually working in the, let’s say vendor space or the consulting space. Yeah,
[00:01:35] Jay: I guess in the, you know, internally you’re kind of just doing the role, right? You’re doing the job getting the outcome. Whereas when you’re in a consultancy, it’s, uh, it feels a little bit like you have to have another string to your bow, which is how to work with a customer when you’re, you know, when you’re a vendor and naturally, you know, as kind of human psychology, you are an other, you are someone other than the actual company that’s wanting the outcome. So navigating that challenge as well as doing the role is always a bit tough, but it sounds like you’ve been ring a little bit. So that’s cool.
[00:02:09] Richard: Yeah, I mean, I think for me has actually been a role that I’ve always gone back to, you know, time and again, because I’ve actually enjoyed, you know, being at that sort of, you know, cutting edge of the technology that’s coming in. So I have to learn that, but also the thrill of, you know, winning a new sale, winning a new, you know, bid or something like that with a customer, that’s always good, fun
[00:02:28] Jay: as well. And what type of projects do you typically kind of get involved in? Is it just all migration to the cloud? And is it always like public cloud? What types of things do you do you guys like to get involved in?
[00:02:40] Richard: Yeah, I mean, it’s predominantly helping customers really migrate to public cloud and whatever that entails, it may end up being a hybrid cloud or a multi cloud of some kind. Or as you said that I learned recently poly cloud
[00:02:53] Jay: poly? Wow. OK.
[00:02:56] Richard: We set another compensation for
[00:03:01] Jay: multi poly hybrid cloud nice. Uh What does poly cloud mean?
[00:03:06] Richard: So apparently, and I was speaking to a very good friend of mine who actually in a a research company, the idea is that you effectively use a small number of applications but they are running in multiple clouds. So for example, you might want your analytics stuff to be in Google’s cloud, for example, and maybe your sort of development and things like that might be. Isn’t that just multi cloud? Well, it kind of is, but the distinction I think is that you’re kind of using, you know, a small number of applications, let’s say not your default cloud, for example. So multi cloud would be kind of, you know, all in on Azure and all in on Aws, let’s say. So, you know, whereas multi cloud is kind of OK, so we, you know, we’re going to do our analytics and Google because perhaps their tooling is better going to do our development aws. And then maybe our production stuff might be in a or something like that. So, yeah, I joked about it and I said, so it’s an, it’s an A S 400 in the cloud basically, you know, a small number of applications, you know, and that’s all that your system is running. So, yeah, there you go.
[00:04:10] Jay: Wonderful terminology there. Brilliant. OK. And I guess the types of organizations that you’ve kind of probably seen in some of these migrations that you’ve done or been involved in historically. Um Can you talk a little bit about, you know, what you’ve learned in the sort of large enterprises? So if you’ve got, I don’t know, more than say, 500 developers or something like that working in cloud and you’ve come from a traditional sort of on prem operating model and ways of working. What types of things have you typically seen people do and what should they stop doing and move to? Yeah, I
[00:04:44] Richard: think everybody, you know, has been struggling to a degree with how to really use cloud properly and how to utilize cloud technologies and, and obviously how to get there, how to migrate to cloud. You know, what’s kind of the initial steps? Why
[00:04:59] Jay: do you think that is because obviously we’re, you know, being technologists, you know, I guess keeping up with pace of to move and stuff, it’s difficult, right? Why do you think, you know, there’s lots of kind of stuff innovation going on with the cloud vendors themselves to try and make things easier. But why do you think people struggle going
[00:05:14] Richard: to cloud? I think it’s the, you know, as we said earlier, you have as an it person working for an enterprise, you have your work cut out for you in most cases, you know, those teams are firefighting, there’s a lot of stuff in front of your face that needs to be done and there isn’t enough time to go and research a lot of that, you know, sort of innovation that’s happening and, you know, the churning out of cloud services that every reinvent from AWS, for example, you just can’t keep up really with all of that sort of innovation. So, although it’s there, it’s difficult to really go and spend time on it unless you’re structured in a way that you can, you can do that. There is somebody who is actually going to look at those things and then see if that will be applicable to the business processes and the way that your business works and see if that’s something that can be done and it can be utilized. So I think it’s things like, you know, lack of resources, time to spend on it. Maybe the, like I said, the structure of the organization is not really designed for that. It has just been something that facilitates and not innovate as well for the business. So it’s, you know, I want my office, I want my email, you know, and I want a database and, you know, can you just make that available place, you know, and that’s pretty much it,
[00:06:23] Jay: it’s always been kind of like an operations hub or something like that, more so than an innovation kind of thing. Right. So, and then I guess how that’s looked at both financially and then culturally within the business is just go and do a thing rather than, oh, there’s capability to look at other potential avenues of, you know, making money or being better in terms of operations or whatever.
[00:06:44] Richard: Yeah. And I think also sometimes because of those decisions that get made at some point, then you kind of settle for those decisions and you stay and stick with those decisions maybe for longer than you ought to perhaps. So that’s where you end up using or having a corporate database. And one of the recent sort of things that I found talking to a lot of database vendors as I do sometimes and actually, this is from my experience as well in the past when I used to go and install software for customers. And I’d say to them, well, by the way, this application has a built in database, it’s gonna install a small database and they would insist that that shouldn’t happen, that my app should point to their corporate database. And I say, but guys, it doesn’t need oracle, it doesn’t need SQL server, it doesn’t need DB two or whatever you have and they would still insist on it because that’s the corporate standard. So I thought, ok, so if that’s the case, how many apps out there are actually on all these, you know, lovely, you know, hugely licensed, you know, corporate databases that actually don’t really need to be in there. They don’t need the capabilities of those, you know, of those platforms.
[00:07:50] Jay: It’s insane like in this day and age that stuff like that still happens. You know, it’s like saying, oh, I need to do some work in my house. And the only tool that I’m ever gonna need is a, that’s the only thing, you know, no matter what you’re doing, putting up some tiles,
[00:08:05] Richard: you know, funny you should mention that because I’m actually having work being done on my asset. Well,
[00:08:10] Jay: can I sell you this hammer? Because this is the
[00:08:12] Richard: one you need. Ironically yesterday I was there because we’re not actually living there anymore. And honestly, I was there and I did see multiple tools. So I’m relieved they haven’t tied you
[00:08:20] Jay: into a single
[00:08:21] Richard: tool. Yes, it’s not. Everything’s done with a hammer. Thank goodness. Yes, I think those are kind of, you know, potentially reasons. And then as I said, there’s just no enough strategy space there, you know, for innovation and to be looking at the things as you go forward. But obviously, that’s the idea of, you know, if you are going to innovate is, you know, you need somebody like a partner consultancy, partner is going to kind of help you with that journey
[00:08:43] Jay: into the cloud. Let’s go with a few kind of scenarios here, right? So let’s say you’re not necessarily going with a consultancy and you’re trying to do it yourself and you’re on prem, you know, you’ve got an on prem footprint, that’s how you’ve operated and the traditional kind of teams that come with that. So infrastructure, you know, service management and the whole way of operating, right? So let’s say that’s your starting place and you a data center is being decommissioned or that’s about to, you have to get out of, of on prem and you’re not gonna hire a consultancy. What do you think the first kind of place to start is in terms of looking at how you’re gonna try and adopt this, make this change to
[00:09:22] Richard: cloud? Well, I think you would need to have a, you know, first, what kind of a change in your charter in your IT chart or strategy. If you like in terms of, you know, saying, you know, people kind of tend to migrate to cloud for the wrong reasons and we’ve seen all the Gardner charts and whatever for that. So you’d want to kind of want to do that for a good reason. You need to have good reasons. They need to have like a chart or a strategy to say, I’m going to look at the cloud and see what we can use in cloud in the motor has to be there. But then you need really a team that can start looking at that and you need to empower that team so they can make decisions and those decisions need to be endorsed by the sea level as well in your organization. So a good example of that is like a cloud center of excellence and that’s something obviously that we kind of do with our customers, but certainly customers can have, I think the initial steps of starting that themselves and that gives them the space and the freedom to be able to go and research a lot of things. And you know, look at the cloud and the services and technologies that they can hopefully be able to leverage
[00:10:25] Jay: nice. So they’re not in cloud, they understand their kind of, you know, business reasons if you will for taking this massive leap into operating in that different operating model. And then you requisite some skills into that team that are vaguely aligned with something to do with cloud cloud strategy, cloud transformation, et cetera, call it a center of excellence. And I guess how long before that team might start? Like, how do they start? Right. So it’s like, ok, I’ve got an understanding of why I’m doing this. I know what has to be done in terms of the outcome. You know, my data center is being decommissioned. I have 100 apps or so that need to move over. Like what happens next because it seems like there is probably stages to this, but it’s not waterfall, right? It’s not like design and plan and do all of these things and then you do, there’s like a chunk of time where you do and then you move on. But what would I guess be the kind of different levels of maturity and how they might move? Well,
[00:11:20] Richard: yes, I mean, I think there’s multiple threads to that. So the requisition, as you said, of the right people is important. So if you don’t have the skills in house, then you know, you may want to bring in a CTO or somebody at that sort of enterprise architecture level that that experience. So that person kind of drive that strategy forward and help the CCO to kind of put things into motion. Obviously, as we said, you know, a partner is another way to do that to help you with kind of really setting up the, the CCO and driving that and then the, you know, having the right motivation to migrate to cloud. And I think some of the reasons you’re listed is actually kind of more the desperation of, you know, we need to, the lease is coming to an end in our data center and we need our CEO cio said we’re not renewing. So we need to get out Microsoft is really doesn’t want to support SQL version 1997 or 2002, whatever it is that you know, that we have. And they’re saying even the extended support is now finished, please migrate Mr customer. So we got, you know, 200 SQL instances or something and we need to migrate. So that’s again, you know, sort of a more of a desperation. So you want to kind of try and avoid those sort of things and kind of preempt some of that by, you know, putting this kind of strategy, you know, into place and then it’s really looking at. OK. So how do we migrate? We certainly need to migrate in stages. It’s not going to be kind of on one terraform script and it’s all in the cloud tomorrow. So we need to kind of understand how can we not just migrate but learn from the process of migration as well. So we can scale up, give our it teams the opportunity to go and certify and train and learn from the process and things like that as well. It’s a gradual sort of program. And again, it depends if there are differences between a digital transformation of somebody versus a cloud migration or an app migration, you know, those are all different things. So, and it also depends on what kind of an enterprise you are. What kind of an organization are you. So if you’re kind of more of an established sort of organization, then you have obviously a lot of heritage from the data center that you need to bring with you or you need to make decisions whether that gets retained and you just sweat those assets in either in your own data center, if you’re not leaving the data center completely or in a colo situation of some kind. So that all of that is part of the decision process and then obviously you look at things like data. So again, do we just continue doing the same corporate database? But now in the cloud or do we look at some alternative options and things like that? So all of those need to be considerations. So once you’ve kind of done the old charter and the reasons why you kind of look at those and then it’s really down to OK. So let’s actually now look at migrating some applications or utilizing the cloud for certain services are already there. And if you’re a startup, it’s great because, you know, I’ve seen before kind of success stories where, you know, a company jumps straight into doing servers, you know, and their website, which was taking orders from customers up and running within 90 days all in servers. And this was actually a true life thing. So, so, yeah, so if you don’t have any of that sort of, you know, legacy and in heritage perhaps, and you’re a startup or something, I think you guys mentioned that kind of scenario in our previous talk as well. And that’s easier for you because you’ve got no assets, you don’t have to worry about, you know, sort of that sort of heritage and so on. But yeah, otherwise it’s a gradual process. You look at kind of the low hanging fruits of what you can migrate and you go from there really. And that would be kind of maybe the first sort of phase of the migration and then the more difficult applications or the ones that really cannot be moved for potentially security reasons or regulatory reasons or something, then you have to make a different decision for those.
[00:14:56] Jay: And what are your thoughts on? Like, you know, I guess there’s low hanging fruit which is, you know, quick wins, things that you can kind of migrate quickly. And then the other kind of end of the spectrum is like the really hard stuff and which one to bite off first because the hard thing is going to prove something right is proving the fact that this ridiculously complicated application and all of its components can be moved. And therefore because that is a combination of all your potential patterns or whatever of apps, then you’re pretty much doing the work there and implying that everything else that you do will become easier or kind of starting, you know, at the bottom of the rung, something that you can kind of quickly and easily migrate and get to kind of buy in and move that way. Yeah. What your kind of thought? Yeah.
[00:15:41] Richard: So I think for that is down to the skills and the capability that your team has at the moment. So if they are a little bit more sort of, you know, cloud savvy and aware and they have some experience or they’ve just come into the organization. So a little bit more kind of, you know, from that background, then you could potentially look at that slightly more complicated application and move that as a service into the cloud. But otherwise I think if you’re really starting from scratch and so on, it’s the low hanging fruits are the easier applications that you need to migrate. And the good thing I think about that as well is that obviously there’s less risk of doing that because the other application is more complex beast to migrate and then you have to really get that right. And you’ve got sort of user acceptance testing and all the other stuff to go behind that. But the simpler applications are also the way that you would take that success to other stakeholders, those who are looking after those more complex applications and actually use those success stories that you’ve had from those initial migrations as oppose to child for convincing other stakeholders within the organization. And like I said before, I think people underestimate the experience that you get from just doing that and doing maybe things like, you know, hackathons with your partner or whatever that you’re working with as well. I think all of that builds confidence, you know, in, in your I T
[00:17:04] Jay: team. Yeah. Nice. Yeah, because I guess no matter what, you know, if you’ve got a partner doing it, you’re doing it yourself, a migration in, you know, company A is going to differ massively from company B because everything around it does, right, the systems that they use, the people that you have the operating model or, or whatever it is, that’s in your existing organization, how people talk to each other, those communication flows, etcetera. So it makes absolute sense to kind of start off small and learn and grow and, and do more and more kind of riskier things if you will but kind of grow your capability with the risk that
[00:17:37] Richard: you’re taking, correct. And I think also where you end up in the cloud is important. So you need to have a goal of, you know, which part of the cloud if you’re going to end up in. So, I mean, I break it down into kind of four stages really. So this is based on this standard six hours. It’s not anything revolutionary really. But I prior to the pandemic, I used to whiteboard this with customers and it kind of really worked very well because it used to help them appreciate and understand where they are and what does it take to go into the cloud and where they’re going to potentially end up and so on. So the four stages is the kind of lift and shift. So you’re just kind of moving what you have in your data center, potentially a virtual machine into somebody else’s virtual essentially. And then the second is kind of where you do containerize the application, but it’s the same old monolithic app that you had with a few modifications essentially. So that’s a kind of a lift and reshape if you like a stage two and stage three is where it gets really kind of tough and where you start looking at things like cultural shifts. So things like DEV ops comes in and there you’re really looking at if you are development heavy, for example, you have a lot of developers or whatever, you’re not a kind of an off the shelf. Stage three is really all about breaking up those monolithic applications into at least modules. And if not dare, I say micro services of some kind. So that’s where you really are redesigning or ref factoring your applications. That’s kind of stage three. And then stage four is a complete re architecture of what you have. So that’s where you go wild on things like serverless and function as a service and policy as code and bring in things like G S and stuff like that and do S R for you for the support and so on. So yes, so that’s our rearchitect.
[00:19:16] Jay: So do you think that the end state for all things running should be serverless because it feels like, I mean, that is one way of operating, right? It’s, you know, kind of implying a few things, I guess they’re serverless. You’re not maintaining, you don’t have any kind of oversight or insight into the infrastructure that’s running, you’ve got no operational concerns and then there’s things like event driven, architecture and functions and services and all that kind of stuff, right. So are you saying that I just making sure that you’re not looking after the infrastructure should be the direction for everyone or do you reckon it kind of depends on the organization and the type that they are and what they want to
[00:19:54] Richard: do. I think it’s probably actually dependent on their strategy and ambitions rather than the organization or the tech. So, you know, everybody should be able to and could achieve that. But whether it can be done or whether you kind of want to do that and whether it’s possible to do that So sometimes, like I said, you’re, you know, you’re restricted by regulations in your industry or something like that. So there are certain types of workloads, you just can’t really move or you can’t move that far into the cloud. And that kind of, you know, line gets, you know, kind of goes more solid as you kind of go towards servers and all that kind of stage four kind of in the lifted shifts are slightly more. It’s not, it’s not as solid when it comes to cloud native as you’re moving on that journey. So I think it’s possible and organizations should try and aim for that if they can, if it’s feasible within what they’re doing and their markets, but it’s not completely 100% by tomorrow afternoon. You know, we’re going to be servers. I don’t think that’s kind of the right approach. It’s
[00:20:51] Jay: a journey, right. And I guess there’s that journey costs some thing in that you might have a team that’s skilled up in doing one thing. And now you’re kind of saying make the necessary moves if it makes sense to target this type of thing, kind of like, you know, aim for the moon and you might reach or aim for the stars and you might reach the moon or you know, that one of those typical kind of saying here, it’s like if you’re kind of aiming to get somewhere and you end up putting in all other kind of practices and things along the way, then you’ve succeeded in at least what the business needs, which is to kind of function in a more operationally efficient
[00:21:28] Richard: way. Yeah, I mean, I think you still need to, your aim needs to be, you know, realistic and it needs to be in response to what the business needs. So it does need to kind of have that in mind at all times and you shouldn’t be kind of saying, well, let’s just go us and do stage four because that’s their latest tech and, and whatever. And I kind of fancy playing with all those technologies, it needs to be responsive to what the business requirements are. So whether that’s, you know, innovation competition within the new market or maybe expansion acquisitions who might have acquired somebody else and they are more advanced in terms of their tech than you are or less advanced than you are. How do you bring the two together? And, you know, I had that example, you know, quite recently where, you know, customers acquired somebody else and one is in a, in a like, OK, wait, what? Exactly. Yeah, exactly. So how do we do that as a one strategy? How do we bring those services together? So I think it needs to be for the right reasons.
[00:22:31] Jay: So let’s say you’re kind of aiming there, maybe you’re starting with sort of the lift Tinker shift, you know, containerization or something like that. Maybe you know, re architect at some stage, there’s this concept nowadays with like platform engineering, like DEV OPS and then platform engineering, what do you make of that? And you know, how do you think it’s a good idea for organizations to adopt platform engineering? What does platform engineering even mean to
[00:22:53] Richard: you? Yeah, I mean, I think there seems to be, you know, we kind of started with DEV OPS, let’s say on that sort of space of, you know, moving away from the old way of kind of developing applications, we kind of broke them up and applied their G methodologies and so on. We had all these tools we came up with with pipelines and then he had this kind of the growth of CD vendors and that space offering more or less kind of the same thing. So that’s fine. And I think what has happened a few times in the cloud and cloud native space is that we’ve run away with an idea and kind of really got excited by it. And then we’ve gone, ah we forgot to do X Y Z or halfway along the way, this is getting really complicated. We need to go back to the drawing board and separate things out or rethink something. So a typical example was DEV ops and then it went to DEV set ups. So we kind of OK, we didn’t actually put any security in any of that source code that we downloaded from somewhere, you know, and so we need to actually really kind of scan for that and scan for vulnerabilities. So, so we need to change DEV OPS to DEV set ups. And then now I think the split with platform engineering is that we’re saying, you know, platform engineering takes care of the establishment of those tools and platforms to actually do development. Then the DEV OPS comes in and actually does the development aspect of it and make use of those tools. So we’re kind of splitting what platform, how do you set up your sort of devops platform, Verus, actually, how you use essentially your devops platform? And I think that’s fine. It’s kind of removes the burden from the developers to figure out all these tools and their pipeline and stuff like that. Some may resist that and may actually want to do it themselves because that’s kind of all part of their sort of world and others might be quite open to it today. And it just me to develop stuff I can hit the commit button and then I don’t have to worry about it. This kind of moves on, you know, from that stage of the pipeline to the next,
[00:24:45] Jay: would you say it’s more kind of a centralized because you talked about sort of platform teams and then, you know, devs people still using the platform tool, if you like to help the applications, teams get their apps deployed, etcetera. Would you say that they work hand in hand in that way, or that sort of platform teams are a kind of centralization of that of the sort of de methodology in that instead of getting all of these teams to individually create their own patterns, you’ve now got simple ways of operating and maintaining patterns and they are just consumers of those patterns,
[00:25:19] Richard: right? They can be, but I think a lot of developers tend to be quite opinionated, right? So the whole sort of DEV and ops was to kind of bring those together. So I wouldn’t necessarily want to separate things again and have DEV ops over there and platform engineering over here and kind of the two are not talking to each other and that kind of reestablished that wall that used to be between development and operations. So I certainly want them proactively involved and engaged in that because after all, they are the consumers of it, as you said, and if they’re not happy with what they’re consuming, they’re not going to consume it basically. So I think it’s important that yes, they are involved in that process to whatever degree that’s down to the teams to make that decision really. And
[00:25:59] Jay: then where does the kind of cloud center of excellence fit in all of this?
[00:26:03] Richard: So is still the overarching umbrella really for all of that. So it’s encompassing a lot of these decisions. It it’s facilitating this cooperation and collaboration between all these different teams, it’s defining the standards for that and it’s bringing in the correct people into the CCO so that we can utilize their expertise and knowledge and experience in those areas. So they can contribute to the cloud strategy and the cloud operating model if you like. So, you know, it’s part of the whole sort of approach to how we’re going to do this stage three, which is kind of essentially what we’re talking about and how that’s going to really work, you know, for us in terms of how we develop applications, you know, going forward as well as obviously other things like, you know, cultural change and change of process change of, you know, sort of skills of the people, the whole sort of, you know, P P T kind of approach to it. C C O is still the overarching sort of, you know, team and you know, driving that strategy implement entering things like devops and platform
[00:27:04] Jay: engineering. There’s a bit of an overlap between kind of C C O E and a platform team because I guess a platform team, they’re a team and their user is developer or, you know, not like someone that is trying to iterate on an application and take it to production and they have to have a relationship to the users, right? So that kind of product manager or user developer experience, person or whatever is like is interviewing is keeping that relationship quite tight and that feedback loop quite tight. But then the center of excellence is maybe doing that same thing from a different approach, you know, slightly different mindset, I guess. How do you see that overlap working? Have you seen that in many orgs? Like having both of those teams operate in sort of
[00:27:43] Richard: tandem? I think the main struggle for people tend to be actually just setting up something that will work. So that kind of putting that C ce together. So I think there’s less kind of that occurrence. But like I said, I think for me, the C C should be encompassing all of it because the entity within the organization that’s been empowered to go and make these decisions and it needs to bring in if you have a platform engineering team, then they need to be part of that. They need to be contributing that if you have, like I say, if you’re development heavy in your organization, the DEV team needs to be there as well as your SRE Cyber engineering team, if you have one or your cloud ops, if you want to call it that or whatever. So I think all of that needs to be all needs to be contributing and having their say really. All
[00:28:26] Jay: right. So we’ve got the kind of big banner of AC C O E A bunch of different kind of teams or people kind of responsible for those teams in, in C C O E. We’ve got a bunch of apps that are kind of almost, you know, migrating in whichever one of these different four different kind of operating or target operating models. I don’t know what to call it. The four that you described,
[00:28:46] Richard: those are just kind of the stages of the journey. But your, yeah, your C C A will still need to have a target operating model, a cloud operating model of some kind.
[00:28:55] Jay: That’s how you do it. What are the kind of common mistakes of setting up a kind of CCO that you’ve seen?
[00:29:00] Richard: Yes, I mean, probably and this is, I think across the board, I think all three leading cloud providers agree on it and are kind of having read their sort of white papers on that as well and understood that as being their sort of stance as well. You know, it’s things like not having the endorsement of the, of the board, the sea level, the sea essentially and the cio not being empowered so they can actually make the decisions and then organizations or other departments kind of dragging their feet to follow the CCO and what the CCO is said to be the way forward to adopting cloud. So those can be certainly part of it. And then the other one is not really understanding what the CCO is supposed to be doing and maybe getting too involved in the technical bits and pieces of something. And that’s actually not what you’re supposed to be necessarily doing sure we can sit down and do a proof of concept and decide on whether we go with cloud A or cloud B. But that’s something that we kind of decide based on a number of criteria that shouldn’t be encompassing and engulfing the whole of, you know, the C C O E and everybody’s doing
[00:30:06] Jay: that. Yeah, that makes sense. All right. So, you know, we’ve got a way to kind of build that team, the types of things that that team is kind of responsible for. I think that pretty much, I mean, we’ve spoken about a hell of a lot there. Um Anything else that you want to kind of cover in the C C O E area?
[00:30:21] Richard: No, I think that’s kind of like I said, I think the difficulty for organizations is again having that time to understand the CCO so obviously a shortcut way of doing that is to have a partner to help you to do that because they would come in and help you to establish that at least kind of the beginning and then later on when you’re sort of way down the line and you’ve had some experience of migrating applications into the cloud and so on. You know, I mean, for us, we would expect the customer then to take over really and kind of it would be made up more of the customer team than our team potentially. Yeah.
[00:30:52] Jay: Yeah, that’s the goal, right, I guess is to in the end. Sure that the customer has the right tools and skills to kind of deliver. Great. No, I mean, this has been fantastic. Obviously, thanks for coming and talking to us. How can people find you if they want to hear
[00:31:04] Richard: more? Well, they can certainly connect with me on linkedin. So I’m more than happy to connect with people. One of the things I really enjoy doing is kind of, you know, being a cloud native citizen as I call it and kind of, you know, connecting with people who are kind of enthusiastic in the same way as I am about cloud and so on and you know, kind of being in that sort of community really. Uh the other place of course is to check out my youtube channel called the Cloud Therapist. So if you just type in cloud therapist on youtube or I think they have the at Cloud Therapist now you can have as well. Uh So yeah, Cloud Therapist is a youtube channel where I do lots of cloud native talks various different people. So good, fun. And have you got any talks coming up? Well, I just released one quite recently about E K s anywhere with Aws. So that was a good, good and I mean, there’s different type of sort of segments on the channel that I do as a monthly one, which is kind of a longer discussion. We just pick on sort of three topics myself and my friend from a research company and we just discuss those sort of three topics and have a bit of a rant as we call. It was good fun to do. And, yeah, and then there’s another segment which kind of focuses on sort of talks that are 15 minutes or less. So, you know, anybody who’s kind of described or as watching one of those knows that that’s going to be a 15 minute, easily digestible, kind of easy to watch type of talk. But, yeah, I mean, it’s good fun. I enjoy doing it and it kind of really started as a way for me to learn from other people, which is great because you learn so much from doing that and kind of researching things and then just letting them talk and learning from the sort of things that they are talking about and it gives you different ideas and it’s also, I think allows me to kind of, you know, as somebody put it recently to me paying it forward, they said you pay it forward, which is really good. And I enjoy doing that. I have a lot of, you know, a big passion for STEM and stuff like that as well. I do that with schools and universities. I go out and talk to them about careers in I T and, and things like that. Yeah. So a really good fun. I enjoy doing that and obviously it gives me connections within that community, which is also brilliant. Cool.
[00:33:00] Jay: All right. Well, again, thanks for coming on board. Pleasure, cheers.
Part of the Appvia family.