Welcome everyone. It's Mike Gibbs and I'm here today to help you build your cloud architect career or a security architect career or any other architect career for that matter. But today we're mostly focusing on cloud architecture. So the reason I do this is I remember 26 years ago when I started my architecture career, I was just confused. I didn't know where to go. Engineers were telling me one thing, architects were telling me something else. This person's telling me this and I was lost and I went in all kinds of wrong directions until I got some real good guidance. Got some guidance. Six months later I was a senior engineer at MCI WorldCom. Three months later I was a lead architect at the world's largest ISP and two years later I was a principal architect all because I knew exactly where I needed to go. And I want you to be in that same position. We've got that roadmap to become that cloud architect, enterprise architect, security architect, whatever you want. So bring me your questions so we can help you. — [gasps] — Uh before I answer your questions, I want to let you know that we have a couple of free things going on to help you right now in your architecture career. Uh tomorrow my good friend David Lethicum and I will be talking about how to become an artificial intelligence architect. We'll talk about what we do as artificial intelligence architects, the skills that you need to become an artificial intelligence architect and everything it takes to get hired and trained and along the way whether it's a career transition or not. So join me and David Lethicum tomorrow. You can sign up for that webinar in the description as well as that chat box and I hope to see you there. It'll be live on Zoom so you can ask us any kind of career questions you want. Now next month we're going to be doing free introduction to enterprise architecture boot camp and it's going to be a whole lot of fun. We're going to talk about enterprise architecture. We'll talk about the components of enterprise architecture. We may even have some architecture labs where we design some architectures together. It should be a lot of fun and if you love architecture like me, it will be a lot of fun. So please register for that free enterprise architecture training and uh my team will drop that in both the chat box and the description of this video. And while you're checking out the description of this video, there's lots of free guides in there. Guides on how to become a cloud architect for example or an artificial intelligence architect. Free guides on how to pass an architect interview and some things to help you along the way. So please sign up for some. They're free. So at this point bring me your questions so I can do whatever I can to help you and that's really why I do it cuz I know what it was like in the beginning of my architect career. Excited to be here. I'm thrilled you're here as well. You've been a solutions architect for the last 10 years. You're very technical. Everyone compliments on it. But other people have been getting promoted on over me even though I know more. What do I do? Well, I'm going to ask you some questions and I understand it's going to take some time for you to be able to respond. But my guess is from the way you're describing this, you're often the most technical person in the room. Please let me know if I'm correct. Everybody goes to you for technical advice and you are really comfortable talking with technology professionals as well as people see you as a really just great super techy. And the reason I want to confirm that is generally when this happens and quite frankly it happened to me. I was early in my career. I was a principal solutions architect. There was a much bigger architect role that opened up and I had reached out to my manager and said I'm interested in that and he said my manager said Mike, two things. One is you're too technical and uh he said the other thing is he says you're too good at your job right now. So let's see if you responded uh in that chat box so I can see where you're at. So let me try and see if I can I can see the responses you gave me if you gave me. You've been a solutions architect. I maybe have an idea. Yes, that's you. Okay. So that's you. That super techy, that person in the room. Now here's what you need to do to change. So what you've shown them is that you're very good at that solutions architecture, that focused technical design. And that's great. The bigger architectural roles whether they be the distinguished architect type, whether they be a cloud architect or a network architect or a security architect, platform architect or an enterprise architect which is the most business have a bigger function than just the technology strategy that you're so good at. In fact, when we move into the bigger architectural roles, it's much more about the amount of business knowledge you have. Because we architects as we move up into the architectural world, we're hired to create competitive business advantage. So, a big part of it is making sure you've got enough business knowledge. Now, the next part of it is actually perception. This is crazy. Because in architecture, being strongly technical is a big asset. What happens is when people see you as the techy, they typically don't see you as that executive strategist. So, that's where you need to work on changing your brand perception quite a little bit. And there's a reason for that, because if they see you as an executive, they'll promote you more as an executive. So, what you need to do when you come from this very strong, very technical, very capable background and people are penalizing you for it. Well, I'll tell you what I did. I did it 23 years ago. I did it partially with the advice of my manager and somewhat without manager. I was working at Cisco at the time and I really enjoyed what I was doing there, but I wanted to move into an enterprise architect role. Now, the first thing that I did is I started asking other enterprise architects what they actually did in their job. And much to my surprise, uh they weren't doing a lot of technical things at all. They were working with executives. They were learning the business architecture. They were mapping out the key capabilities for the business, for example. They were managing stakeholders. And very little of what they were actually doing related to technical design. Now, I saw that and then, uh I got invited to some enterprise architecture meetings with the C-suite uh in that when I was there, which I really was grateful to be part of them. And when I was there, uh this group of people, quite frankly, they were speaking another language. They were speaking in terms of EBITDA. They were speaking these financial terms and I was just a little bit lost. So, what I did is I went to my manager and my manager said, "I'm going to fund your MBA program. " So, I went and got a master's in business. I then got some sales training, executive presence training, leadership training. And I kind of held back on what I actually knew tech-wise. And for example, at the time I was there to design a voice strategy for a client. And I'd never really worked in voice before, but it was a critical client. I had worked in video, which was similar, but kind of different. And at that point, I remember saying, you know, "I'm not really the person to architect this voice solution. So, which of voice experts can I bring in to help me on this design? " I started bringing them into design. And then what is along the way, even though I knew networking, I'm like, "I'd really like to get some network architecture to check out the QoS on here. I'd really like to get this architect bring in this expert. " And what ultimately happened is the world and my company no longer saw me as that techy that was the driving factor. They saw me as the leader that had built a team. We soon had to do a And you know what? I didn't build it like the engineer like I would have in the past. And this time I led the proof of concept. I scoped it. I determined what the client deemed as success and how we needed to measure that. I managed the team. I escalated it. And the next thing I realized, I'm in a much bigger architect role that's practically double the money. So, the key is to remember is the solutions architect role, and it is a great role, is fairly narrow in focus. It's fairly specific on tech. The bigger roles are much more business. They're much more executive. They're much more leadership. They're much more stakeholder management. So, that's what you've got to show people you can do. When you add that, all those years of incredible technical knowledge become far more valuable. Cuz now you get the tech and then you'll know the business and that's really the recipe to rise to the top. Uh David Lethicum and I are going to hold an architecture webinar tomorrow. We're going to talk a lot about that actual business side of the role. So, you might want to join us, cuz I think that'll help you along the way, too. I'm going to get deeply involved in all the skills and things that can help you get promoted as David would, cuz, you know, he and I have always taken these big roles and we know what it takes to get there. So, it's free. Join us. But that's exactly what I would say and that's exactly what normally speaking I've seen over the last 25 years. Great question. Dingelman, it's great to hear from you. Hi Mike, I hope all is well. Your role has been going well, but you want to elevate your skills a bit. I'm all for that, Dingelman. During a client meeting, what is the best way to read a room and guide the conversation accordingly? So, you know, great question. So, first, I'm so proud of how far you've come. I know when we met you and I know what kind of great role you're doing as a security architect now. So, I'm thrilled for that. Moving up from where you're at, part of it is reading the room and part of it is speaking executive language. And there's two sides to that. So, one is to truly understand executive speak and what that actually means, cuz they don't necessarily say what they mean. The next side of it is actually reading the body language. What's actually going on. And I'll give you an example. You know, people tend to sit to the next to the people that they like best. So, you can almost see who's in alliance of who. And the person, if you're looking at a person in power, typically speaking to the person to the right of them, directly to the right, is the person they often value the most. Just some something to think about when you read the room. — [gasps] — Now, executives are fairly good at controlling their body language, but there are parts of the body that are harder control. For example, if someone's feet are pointing towards you and you can look under the table sometimes and see it, if it's possible, that means they're interested in you or talking to you. When someone's feet point towards someone else, it means they're interested in talking to someone else, not listening to you. And when their feet point to the door, for example, they're really trying to get out of the room. And feet tell us a lot if and when we can see them, because, you know, they're furthest from the brain. They are the hardest to hide. But if you really read those executive body language and you really look at what they're saying, you'll read it. When someone's saying, "This is going to be a big impact to us. " and they're shaking their head no, uh it'll be you'll see it. So, Dingelman, a couple of thoughts. One is a lot of this content you're actually asking me about is part of that architect program we have, you know, that you ordered from us years ago. You can go back and you can actually go look at that and I would and I think it's going to really help you. There's another book that I always enjoyed. It was from Barbara and Allan Pease and it was called Reading People. And that had some pretty good tips on how to read the room. It was one of those books that I read early in my architecture career and it really helped me. It really helped me read the room, see what other things could do and it was quite an impact to my career. So, that was a big piece. The other kind of thing is at some point, you might want to get into something like one of our executive programs or get an executive coach along the way. And here's the reason. You're really smart. I know you. You've gone really far, really fast. And the more accelerant you could put in your career, uh the faster you will grow. And uh when it comes to working years, we've got a certain number of years of growth careers. So, in your case, you're young enough. I might be focusing on that. But I would definitely focus on that reading the room. more on the communication skills. I would definitely, and yours are good, but, you know, I would definitely focus more on executive skills. And I would focus on that, cuz I think that's going to take you where you need to go based upon what I know of you and the strengths that I've seen in you, which are quite a lot. Dingelhaus, so happy to have you here. Please feel free to ask more questions. I'm always thrilled to see you. Please, if you've got some questions, ask them. I remember what it was like in the start of my career. Right? Literally had no idea what to do. I took certifications thinking they were going to get me my first job. Of course, they wouldn't, but I didn't know that at the time. Um but there are things that'll work. So, please feel free to ask anything. Not sure why you're not getting interviews? Ask me. Not sure questions about the cloud architect role? Ask me. Not sure the difference between a cloud architect and solutions architect or a platform architect and enterprise architect? Ask me. These are the things that we're really here for, cuz we really want to make sure you're you prepare. For example, you prepare for the wrong role, it doesn't get you to your goal. So, please feel free to ask your questions. Hi Mike, is demand for cloud architects growing in the EU? How valuable is the MBA for this career path and how will an MBA plus a GCP training help position someone for a cloud architect role? Okay, so, there's a couple of things going on here that we need to think about. So, the demand for cloud architects, security architects, AI architects and all architects in general is extremely high in demand and it's always growing. Now, the role of the architect is not something that can be automated away like some roles. And the reason is almost no part of our job is automatable in terms of what we do as architects. Managing stakeholders, eliciting client information, leading an architecture team, managing a set of stakeholders, creatively solving problems with limited information, evaluation of trade-offs. So, that's our work and none of it can be done by AI, which is a really, really good thing. Now, because the architect is there to create and enhance business performance, architect jobs are always demand and have always been in demand in Europe. Now, I'm not sure how it but it in a in Europe and especially all of industrialized Europe. And what I mean by that is where family lives, we have a live in a very small village in Greece with 5,000 people in it. That village doesn't have a lot of jobs for cloud architects, but if we moved over to Athens or Thessaloniki in Greece, there'd be plenty of jobs. Same thing with the rest of Europe as well. So, lots of jobs in the EU growth kind of field in the EU, great job. Now, let's talk about the second half of this question, which is realistically speaking, the difference in skills between an actual architect and someone that passed the Google Professional Cloud Architect exam. So, let's talk about what the Google Professional Cloud Architect exam is about. It is about learning the names of the Google services and it is about knowing how to configure those Google services, which is great. Now, let's be fair. An architect doesn't do any of those things. We don't configure any services as an architect. What we are hired for is to guide an organization through change. So, if I show you what we do as an architect, uh I think it'll kind of help you uh a little bit uh understand why you're going to need a different set of skills. And I'm going to invite you to the architecture webinar tomorrow with David Linthicum and I. David Linthicum is Deloitte's Chief Cloud Architect or Cloud Strategist, one of the two. Uh and he's got 35 years experience in this world. I've been an architect for 26 years. So, we'll can talk to you about that. But what do we do as architects? And I've got a slide that I put together for a lot of webinars. Let me just kind of work with that for a second. What we do as an architect is a client comes to us because they've got a business challenge they need help with. So, they call us in and say the CIO calls me and that's the executive sponsor and they say, "Mike, we have a hospital. We had two people that died due to medical errors last year. We want to use AI to reduce the risk of patient deaths in our hospital and improve patient outcomes. So, we initially meet with the client to figure out what they're trying to do, figure out the vision, figure out what's in scope, and really to figure out what we're dealing with. We also determine who the key players are. So, if this is a hospital, for example, where they want AI, we're going to have to deal with the CEO, the CFO, for example, the chief operating officer, like any organization, but we're also going to have the chief medical officer, the chief nursing informatics officer, medical informatics officer. We'll need the chief of the pharmacies, whatever, chief of surgery, because every one of them has a component in the business. So, in our world, what we first do is we speak with this executive team. Now, in enterprise architecture, really good cloud architect, the next thing we're going to really do is we're going to look at the way the organization operates today. org chart to see who's in charge, what have you. We're going to look at the way people do their jobs, for example, key business processes. And we're going to see if now that we have technology, we can find a more efficient way for people to do their jobs. We are going to be looking at the business's capabilities, whatever that business needs to do to operate, and then we're going to learn how that business actually makes money. So, these first two parts of an architecture engagement are going to take a couple of months of time. Now, the next phase in a cloud architect's job, this is where we start to get to the technical part of our role. In this part of our role, what's really going is we're going to create an architecture team and we're going to lead that architecture team to determine what the organization's data architecture is. For example, who owns what data, what is the sensitivity or the importance of the data, how do we categorize, classify determine what data we need to protect and to what protection level. We look at the data architecture. We do the same thing we look at the application architecture. Our application architectures looking at the applications, the APIs, the integration points, what have you. Then we look at the technology architecture, which is their network, their data center, their private clouds, because all enterprises for the most part are multi-cloud. And then we look and say, "Okay, here's where you're at right now. Okay, we figured out what you have. But this is what you want in the future. So, what we're really about at that point is once we know all these things and we've determined what we have and we our architecture determine determines what we know, we then create a strategy to go from what we have to what we know. We call there you call it a gap analysis on a plan. Now, once we've got our architecture finalized, then we do what's called create the solution architecture. Now, that's where we come up with the exact parts, modules we will use for the rest of our journey. And then after that, we plan the migration. And planning the migration is how do we go from where we're at to where we need to be? How many people do we need? What skill set of the people do we actually need? What level of the training of the customer need? What type of people will the customer have to hire to operate the systems that we've designed? Does this have to occur in a phased approach? And then that last part for us is making sure we create a governance structure that's going to speed things up and still create appropriate guardrails. So, that's what we're doing in our job. Now, that part, none of that is covered in the actual Google Solutions the Google Professional Cloud Architect exam. It's the name of it and how to configure it. So, you're going to have to learn architecture training there somewhere. You could learn it from us and we'd be honored to teach you, but you have to learn architecture, which is not the name of something and how to configure it. Architecture is how do we support the business? How do we go from directly from the business needs and strategy? How do we map that to a technology strategy? Architecture is meeting with clients, it's presenting clients, it's convincing the C-suite and the board to do it and that's not what's there. So, of all the skills you need, the MBA is going to help you dramatically cuz it'll give you the business acumen. But you're still going to need to learn architecture somewhere else. The way I view certifications as is follows. And here's how I train people and this is how I recommend training people. Whenever you want to transition careers, again, this is from slides that I have enough sitting around. The first thing you have to do is develop the skills for the job. A physician goes to medical school before they take their medical boards, for example. So, the first thing that you need to do really is develop the actual architect skills. The second thing you really want to be, and I'll talk about that if you want to join our webinar, is becoming what the hiring manager wants, because 89% of the people are not hired because they're not what the hiring manager wants. The third thing that you really need to do is actually do the job and build the real world portfolio to be able to prove it. And then the last things that you should really be doing are working on your resume and getting your certification. And why do I say last? Certifications, this branding stuff will get you all the interviews in the world, which is incredibly great. The certifications are very valuable. But if you don't have the skills, you're not what the hiring manager wants and you can't prove that the hiring manager you can do the job with the portfolio, you're not getting hired. So, this first, skills first, certifications last. Join David Linthicum and I tomorrow if you can, uh because you know, David's been an architect, like I said, for 35 years. He was Deloitte's Chief Cloud Architect, so heaviest hitter you can find in the world of cloud architecture. And I and tomorrow we'll be talking about enter- I'm sorry, AI architecture, but you can ask David and I about cloud architecture in depth. And we will go in depth about every skill you need and why you need it. And then you just going to have to figure out where you're going to learn those skills. But I think it'll be a great career and I know you'll love it. Please feel free to ask questions if people have them. You're confused. You hear the term cloud solutions architect and cloud architect. What's the difference? Okay. You know, it's a great question you asked. And honestly, so many people are confused between the three base basic kinds of architects, which are enterprise architects, which are platform architects and which are solutions architects. So, let me kind of show you. I've got a couple of slides. Bear with me for a minute. Let me so I can open them up. Hold on. Okay. Let me set up this OBS thing real quick. Okay, so, let me kind of look at this architect role. So, let me going to categorize the three and then I'm going to show you the focus and then I'll get into detail explaining the difference cuz there's really three kinds of roles. When it comes to architect roles, there's three types of roles. There are enterprise architect roles and I'll talk about what they do, but these are mostly business. There are platform architect roles like the cloud architect, which is an entire platform and I'll talk about what that means. And then there are solutions architect roles, which are focused on a project or something of smaller nature. So, when it comes to enterprise architecture, and I know you didn't mention this, but I'll start here for a second. We're talking about how do we make that entire enterprise, that entire global business better. And the way we do that is we work with the forces of business. organization's people to determine, you know, is there a better way for them to do their job or what kind of people do we need? We work on the way people do their jobs. Because if we can find a more efficient way for people to do their jobs where they can do more in less time or make less defects, that's going to significantly enhance the business. And then we also plan what kind of technology investments will help that business get to its end goals. And that could be robotics, it could be AI, it could be cloud, it could be networking, could be anything. So that's enterprise architecture, big picture stuff. Now, when we get to a platform architect role, we're now actually talking about a single platform like cloud computing or security networking. Uh I'm going to use cloud architecture. So, in this case, a cloud architect is focused on the entire big picture for the cloud. And when we talk big picture, we're talking about uh things like the entire organization's cloud operating strategy, the multi-cloud strategy, the uh the type of things that will properly fit inside of our platforms and even the design of our cloud platforms ourselves. So, it's not uncommon to see a cloud architect that's designing private clouds like Nutanix and OpenStack clouds especially for high-throughput, high-performance applications. Uh they have something on cloud provider A, say AWS. We've got something else on cloud provider B, say Google Cloud. You know, this is kind of normal work that we do as cloud architects. And for us, it's big picture because we're going to be deciding should we use more than one cloud provider? And if we do, what belongs in AWS, what belongs in Azure, what belongs in Google? We'll be thinking about what should we keep in the data center and why. We'll be more focused on what applications we should move to SaaS. We'll be thinking about uh what could we or should we containerize or modernize? And what if we don't even want to use the cloud at all in our particular use case? So, that's cloud architecture, you know, how do we enable application teams to move quicker? How do we reduce costs? How do we build a platform that will support the business? That's cloud architecture. Now, let's get to solutions architecture, which is very different. Solutions architecture is focused on a single workload or a single project. So, a solutions architect might be focused on migrating a single web website to a cloud provider. So, when you think solution architecture, think one workload, one migration, uh one project, one something. And it gets deeper into the technology. So, it'll be focused more on how would this workload be designed? Which compute exact compute service should we use? Which exact storage thing fits our profile? Which database are we going to use for this workload? So, much, much more specific. So, oops, that was kind of funny. Enterprise architecture, big picture. Cloud architect, platform architect, the entire cloud strategy for the enterprise. Much bigger surface area for the project, which means we need much more business skills along the way and less technical skills along the way. Solution architect role is typically the first entry-level role into architecture for many people. Very focused on a single project at a time. And there you have it. That's the difference between a cloud architect, a solutions architect, and an enterprise architect, but they all need different skills. Enterprise architect needs the most business skills to do their job. Platform architect, second. Uh third, uh solutions architect, less business skills but more tech skills. So, another way or they're all great jobs and it's not that there's one that's better than the others, but they're all different and you just have to have the right skills for the job when you get it. So, hope that helps. Uh bring me your questions. Uh we really want to do what we can to help you. Oops. How can I become an elite cloud architect engineer? You're currently a NOC trainee. You have experience in IT support, sales, contact center agent, and administration. You have a diploma in information management that you have started. Okay, so the first thing I'm going to tell you is I'm going to invite you tomorrow to come to our how to become an AI architect webinar and we're going to talk about it in depth. The second thing that we need to understand is that architecture and engineering are very different careers. If you try to become an elite cloud architect/cloud engineer, you won't be either because they are extraordinarily different in their role. The cloud architect is determining what that company should build, uh you know, what kind of landing zone design we would use for example, uh what kind of people that we need. We're assessing the organization's readiness to migrate to the cloud. We're looking at the organization's balance sheets, financial statements, what have you. So, keep that in the back of your mind and I do have the information about your background and degrees, too, which is good. So, that's the architect's focus. Now, the cloud engineer's focus is on how do I build it? So, while that cloud architect won't be touching the technology ever, they won't be coding, they won't be configuring, that cloud engineer is going to be needing to work on the cloud, which means that cloud engineer needs some deep Linux skills, they need some Python bash shell scripting skills, they need good systems administration infrastructure as code skills. So, you can see it's a completely different set of skill sets between the cloud architect and the cloud engineer. And that's the biggest reason people don't get architect jobs is they mistake them and confuse them with them. So, I really do want you to come to that architect webinar. Now, the fact that you have experience in sales, you said sales, that is really great thing and that's going to be incredibly helpful to you in your architecture career. Uh that you do you have a diploma in IT management? Great. Uh that's also good. That's also going to help you. And uh you have a bachelor of information tech and business. So, I like that. It's a good start and that's a lot of good things to know. Now, we're going to have to do is you're going to have to learn the role somehow. And the skills that are associated with the role. So, I want to make sure you understand the difference between the technical skills of an engineer versus the technical skills for the architect. Because from where you're at, what you'll need typically speaking, and if you come to the webinar tomorrow, I will actually talk to you. I can interview you and I can assess your business skills and technology and tell you where your gaps are and I'd be happy to do so. Uh that's why we do these webinars. But, where do you need to go from here? Well, it's a certain set of skills you need to be an architect, but they are different. So, that cloud engineer needs to deeply know, and that's why we have to figure this out. How do I administer Linux? How do I patch a kernel in install an application automate in Linux? I mean, that's a cloud engineering thing. For a cloud engineer, it's going to be very focused on how do I write this Terraform script? How do I automate Linux with bash? You know, that kind of thing. How do I use the cloud provider CLI? The cloud architect is focused on something different. We're not focused on how to do anything, we're focused more on what should we use or what should we not use. What should we build? build? Should we move to the cloud? If we do the move to the cloud, what should we move to the cloud? If we migrate to the cloud, what should we move? What should not be moved in the cloud? What why which workloads will perform better outside the cloud? That's more of the cloud architecture world. Which workloads will be cheaper outside the cloud? Okay, this cloud provider's got a really good cool for us. It looks pretty nice. But, if we choose this, we lose this feature, this functionality and which matters more for our business? So, as architects, we have a different version on tech. So, while that cloud engineer will need to determine uh how to configure a virtual machine, say an EC2 instance on AWS or a compute engine instance on Google or an Azure virtual machine, the cloud architect will never need to do that. But, that cloud architect will need to determine how many virtual machines do we need? What uh level of CPU should we use? How many cores are we going to need? What is the clock rate of the CPU core based upon the workload? We'll be more concerned about how much DRAM that thing actually needs along the way. We'll be more concerned about how many of these systems we have. We'll be more concerned, like I said, about sizing them, the performance of them. We'll be more concerned that you know the architectural tradeoffs and when to use a container versus virtual machine. And the same thing goes with a container. Do you understand when and where you would use a container? Do you know the strengths and weaknesses? tradeoffs? Do you know how you would orchestrate your containers to work across multiple clouds? See, that's cloud architect work. So, this is design stuff. When you can when you design your wide area network to the cloud, for example, you said NOC trainee, so this should make sense to you. Do you create your wide area network based upon a private line? Do you create your uh your wide area network to the cloud provider to their campus with a IPsec tunnel. Do you connect it with the sassy LAN or do you use a kind of an SD-WAN one? We are looking at the trade-offs where you need say guaranteed performance, I choose the private line for example, or I need something I can set up quickly. I don't need any guaranteed latency or jitter guarantees, I can use an IPsec tunnel. So, that's more of our world. So, it's a different set of things to learn. We have to learn the underlying technology, how the underlying technology works, and fits together. Which is the exact opposite of how do I build this? I kind of hope that actually helps. So, if you're a NOC trainee, and you know, one of the things you need to learn is uh networking, part of being in the NOC, instead of just learning how to go to a router and say site config T, router BGP, put in autonomous system, and a neighbor, and a network statement for example, dive deep into the BGP protocol. Really learn how that finite state machine works. Really dive into the attributes of it, the mandatory, the transitive, what have you. Really dive deep into IBGP, and that'll teach you how to think like a network architect, how we actually design, you know, IP routing for example, and it'll give you some more steps along the way. How it works versus how to build it. Great, great question. Please feel free to ask more. How do you ensure security and compliance in a cloud environment? Well, it's going to take a lot, far more than I can describe in a short period of time. In fact, I usually spend hundreds of hours teaching my cloud architect students there. But, what are the real principles that we need to look at? We have to realize that security is a global thing. Meaning, it's going to be part of everything we do in the organization. We also have to look that when we're in a cloud environment, we have a lot different risks than we used to have inside of the data center. In the data center for example, everything we had was behind a firewall. And on web-facing things for example, are in a DMZ outside of our firewall. So, we had really strong perimeters between the inside of our systems and the outside of the systems. Which enabled us to have a very hard perimeter, and inside use very strong IAM for every access to what you had. And it was pretty solid. Our internal storage was not connected to the internet, so when Billy Bob was behind their desk and they accidentally set the wrong permissions, nobody could access it outside the company. Migrate to the cloud, everything's now connected to the internet. And on the cloud, if you make a mess, you get hacked because of your own mistakes. When the cloud provider gets hacked, like when Microsoft Cosmos DB gets hacked, you can be hacked through it. So, now the cloud provider has that additional attack vector that you have. What's worse in the cloud is that you have absolutely zero control over what the cloud provider does, good, wrong, mistakes, bugs, what have you. So, you've got new risk factors. So, because of that, we kind of need to adopt to a more zero trust type perspective in the cloud and view this. And what that means is we assume everything is untrusted, everything. And in order to do that, what we use is a very strong identity and access management policy to determine who our users are. Ideally, something that's FIDO-based like a retina or a fingerprint, something that people can't really steal from you. So, we're using a multi-factor authentication and something hard like a FIDO2 token or a biometric to make sure we know. Now, at the same time, when we identify who the users are, in modern architecture identity-wise, we want to look at that user. Are they coming from the right device? Is their device healthy? Is their device patched? Is it the right time of the day for the user? And so, we want to get that context aware case. And that's one of the reasons we're not often using the cloud provider's IAM, we're federating into some more bigger, more specific systems. Because we want to be able to do that for every request. Every time one server talks to another server, we want to be able to verify it. So, strong identity, strong principle of least privilege where we've got our permissions dialed down to exactly what we need, we can add them when we need them and remove them immediately after. So, that's a component. Now, the next thing is encryption. If we assume that nothing is trusted in the world, then we you have to assume the cloud provider's untrusted in case they get hacked or their hard drives get taken away from a regulatory agency. Well, that means that we need to know that everything that's talking to everything are who they claim to be. So, that means uh let's say we have Nick and we have Angelo, and they're going to have a conversation, let's say they're two different servers. What we want to use is encryption between them cuz the encryption will authenticate that they are who they claim to be. It'll make sure that the data can't be seen or modified along the way. So, we're going to encrypt everything. Every connection's going to get encrypted. What we're going to do is we're going to micro-segment as much as we can. So, what that means is if we can divide our network into 30 different VPCs that don't need to talk to each other, we're going to divide into the 30 different VPCs and not enable VPC pairing between them. We're going to micro-segment. And inside of our VPCs, we're going to use access lists, firewalls, and we're going to use even like a host-based firewall for every workload. So, we're really going to knock it down there. Now, we also need to think about when we're kind of dealing with this kind of enterprise security piece, we have to think about our application security, our pipelines. So, we have to be very careful where our software come from, that the software is actually checked for bugs and validation very and weaknesses along the way. So, we have to make sure we're checking these kinds of things along the way. So, we need code checks, we need other people to following it. We need to make sure that our applications are following good good thing. So, what I mean by good things is we want to make sure we've got some kind of input validation so users can't put in the wrong information, some kind of output encoding to make sure that we're only the applications can only enable to release certain things. We need to get involved in physical security because if we have got one router connecting to our cloud provider, but you can plug something into that router, well, you've got a problem with that, too. So, we really start needing to think about that. And then we really need to think about what's going on in the cloud. And what I mean by that is a lot of organizations have their storage encrypted, and they've got their their so their they encrypt data on for example in storage, and they encrypt it in flight. But, what they don't typically think about is you're on a server with 100 other customers on that same server, potentially competitors of yours. And when you're on that same server, when the information comes off of the hard drive, whether it be block storage or whatever, and it goes to DRAM on the CPU, it's unencrypted. So, if data were ever be able to leaked out of memory buffers and put into another virtual machine, that's where your concern is. So, we might even need that kind of homomorphic encryption or secure compute if and whenever possible when it really matters. So, it's that, and it's also understanding that when we are in the cloud, there are some things that we can't control. And that's why various governments want to have a separate cloud from the primary cloud cuz they know that. So, we always want to think about should this workload be on the cloud at all? Cloud computing's fantastic, but not every workload demand is meant for cloud computing, especially cuz there's just so many things we can't do security-wise on the cloud cuz we don't have control of the network and hardware. But, that's generally how we do it. In today's world, it's predominantly a zero trust framework, and that's the basis of even the devices, everything gets hardened. So, that's about the basics of zero trust in a few minutes. There are more videos on this channel about uh securing your cloud environment, though. Is FinOps relevant for the cloud architect role or is it a stand architect role in its own? How can a cloud architect incorporate FinOps in their work? So, FinOps is definitely a part of cloud architecture. But, FinOps is not cloud architecture, and I'll explain the difference. Cloud architecture is much bigger and much more strategic than FinOps if you do it the right way. So, any cloud architect is responsible for designing financially efficient networks. That's FinOps. Where we can calculate and figure out what running each workload costs us. That's FinOps. Now, the reason I say FinOps is secondary is what we really need is the cloud architect to have sufficient business acumen and finance acumen. I'll explain what I mean by this. One of the questions I ask every architect, and many other architects that I know ask questions for this on a cloud architect interview to the client is, if a client's weighted average cost of capital is 8%, how would you leverage that information to determine whether you should build a private cloud like a Nutanix cloud or an OpenStack cloud versus leveraging the public cloud? And the reason we ask that is there are many use cases for example where you can buy a server from Dell for 3 to 400,000 dollars. And to finance that at 8% costs you 120,000 dollars a year, or 10,000 dollars a month. Now, that same server on the AWS cloud for the course of 4 years is about 4 million dollars. So, let's say it's 400,000 dollars to purchase it and run the electric on it. To buy it yourself or $4 million to run that same workload on the AWS cloud, the Azure cloud, the Google cloud. Now, if my architect knows finance, they're not going to move that workload to the cloud in the first place and it's going to be 10 times cheaper. So, what FinOps is, it's an answer to a bad architecture. If the architect made a bad architectural decision, FinOps is there to behind the scenes to say, "Hey, you picked an inefficient way. Let's go. " So, in my youth, I came from internal medicine before I got my first architect job 26 years ago. And in medicine, we have two options. One option is to make sure the person exercises, that we try to get them to stop smoking, eat, right? So, they don't get diabetes, heart disease, and die. That is good architecture. That is preventive medicine. The other side of medicine is when that person came to us and they've been a smoker for 30 years, they're 100 year 100 lb overweight, they don't exercise, and they've had a heart attack. How do we fix them? FinOps is like that it? And that is absolutely so critical. But a great cloud architect knows so much more about business that they're going to make the right decisions in the first place. They're going to know what should go to the cloud, what shouldn't go to the cloud. They're going to be able to look at the real business problem, figure out exactly what it takes to get to success to that business problem, and be able to build the business case that says, "Mr. employer, here's my $1 architecture that will yield $4 of incremental revenue. " And I've done billion-dollar plus architectures. So, that's the architect's job. So, if you look at the world of finance and accounting, the finance people are which are the people that make the most money. They're the people that plan portfolios and make investments. That is the architect side. We are planning a way to help that business have better financial future. Now, the exact opposite side is the accounting side, which is FinOps. The accounting side is when the may the accountant says, "Mike, you spent too much money on technology last year. You need to spend less. " That is FinOps and that is accounting. So, both are important. It helps every finance professional to know a little bit about accounting. It knows every account helps every accounting professional know a little bit about finance, but it's a different role. Architect is much much more strategic. Hope that helps. Great question, by the way. If you've got some questions, please ask them. We really do want to help. Right now, this is the last question. If there's no more, I'm going to go back to hanging out with my cat, Cindy. She's been looking at me all day, but and get her shrimp and things. But if you've got questions, we really do want to help. Last but not least, you notice that most cloud architect job descriptions tend to include infrastructure and code and Terraform. Do architects do some technical work like proof of concept? So, let's clarify the difference between an actual job and a job description in tech. And let's talk about why job descriptions in tech, they're horrible. They're meaningless, they're silly, and they're worthless. And let me tell you why. So, in tech, for the most ridiculous reason, here's what occurs. Let's say I decide that I'm going to hire a cloud architect. I work at Cisco. I want to add a cloud architect to my Well, not Cisco. They're They've got the architecture piece together, but I work at a normal company. And I say I want to hire a cloud architect. What I do is I fill out a human resources requisition form. And then human resources, who's never been an architect, has no idea what an architect actually does, creates a job description about a job that they have no idea what it is for a cloud architect. And unfortunately, that's what the company uses as a job description. So, the reality is I've never actually seen an accurate job description in my entire life as an architect. Now, the reality is I've been hired by every company that I've ever interviewed with, and I've never had more than 10% of the skills that are on a job description. I've been an architect now for 25 years. I've not touched the technology once in them. If you join David Lithicum tomorrow, I always like to ask him the same question on the on an on our architecture webinars and I said, "David, you've been an architect now for 36 years. Could you tell me the last time you touched technology? " And he said, "On my days of an engineer before I became an architect. " So, we won. So, let's do talk about what we do as technical design. And let's talk about the proof of concept. So, we architects do absolutely deliver proof of concepts. And would you like to know the difference between the way a half a million-dollar architect handles a proof of concept and a $120,000 solutions architect might handle it? And it has the biggest impact of your career. You could pretend to be the engineer and try to build the proof of concept. I've seen many entry-level solutions architects do this and it doesn't work out well for their career. Or you could do what the executive architect does. So, let's go back and find what is the real reason we're actually doing a proof of concept. We're concept so we can prove to the executives by investing in this thing, it's going to get you your desired business result. So, here's how I have handled a proof of concept for the last 23 years after I've known better. The pre- previous years than that, I just didn't know better. So, as soon as we get the company says, "I want to see it. " And I say, "Great, let's set up a proof of concept. " First thing I do is I meet with the executives. I They discuss the proof of concept and I figure out, "What do you need as a success? What is it you're looking for? Is it increased time to this? Is it the web page needs to do this? Is it this? How are you going to find a success? " And maybe it's a test website and we're going to test incremental revenue. So, first thing we have to do is define success. Then what we need to determine is who are going to be the people that need to see this proof of concept results cuz we've got to get it. Then we're going to determine what they need to see, the scope of it. How big of a proof of concept do you need? Now, that point, as we're scoping it and we're knowing the output and we're meeting with the executives, the executives see us as a peer, which is exactly what you need them to see you as. And I'll talk about that in a while. So, at this point, we now build our proof of concept team. And when you build a proof of concept team, you bring in the best. So, instead of trying to fumble your way through something, if you know there's that cloud network engineer that's got three CCIEs that's super smart, you pick that one. You need a software developer for a little bit, you go find one of the best software developers. You need a cloud engineer to write a good Terraform script, you bring in the best cloud engineer you know. You need to automate some stuff, you bring in a DevOps engineer. They build your proof of concept. Now, when they build it, they're the best of the best, so it goes off smoothly and without a hitch. And when something breaks, and it often breaks, instead of you looking like a fool in front of the customer trying to fix something that is not your area of expertise cuz most of the time you're meeting with clients, and I've seen people try to do it, it's not pretty, you're the one that escalates. You now call and you bring in more experts, specialists, you're there. You're using your corporate American Express, you're buying drinks for your client or taking them to a steakhouse, and they're seeing you as an executive. Meanwhile, the proof of concept goes off well. And now with those executives that see you as a peer, they're now very interested in moving forward with the actual architecture. Now, that's what the most successful highest-paid architects do. Now, what happens if you do it yourself? Well, I did this early in my career and I've seen other people do it. What ultimately happens is when you're doing it yourself, you don't really have the opportunity to be really working with the executives and the key stakeholders, which means you're not building the actual relationships you need to be able to do to get your project approved later. You're also not really finding out exactly what the executives care about. Now, if you're doing the proof of concept, remember, you're not going to be touching the tech almost ever in most architect jobs. So, your job is going to be focused on should we build this as opposed to how we build this. So, your expertise is going to lie in tradeoffs versus configuration cuz it's a different set of things. So, you're never going to be as good at it as the people that do it all day. You'll fumble over it. And that doesn't look professional. The worst part of doing it yourself is this. The management is going to see you as a techie. And this is really sad to me, but when you're seen as a techie, people just don't see you as the leader or the executive. So, when you do it yourself, you get labeled the techie and for the most part, your architecture career is over. Five years later, 10 years later, instead of moving into a bigger role like a platform architect or an enterprise architect, the people are still there. So, that's really the key to think about how you do your architect job. Look, there's a lot of flexibility. You can try to do it yourself. You can have somebody else do it. But, the way you're perceived, what your next job is, and the salary of your next job will be very different if you're perceived as an executive versus a techie. I love techies. They make everything possible. I like executives, too. I've played all parts of the role. But uh no, we're not really a hands-on role in these types of roles. There are some exceptions, especially when we get to the solutions architect world, there are even more exceptions, but typically speaking not for a cloud architect. Great, great questions. Are there any others? Back to Chris. Should a cloud architect know budgeting? Absolutely, you definitely have to understand an organization's financial structure, how to build a financial plan, business case, absolutely. So, you will definitely, definitely need to know budgeting. And the difference between that architect and that engineer, it goes back to that engineer determines how do I build it? Which tools do I use? And the intricate technical details. What we're really determining is will this technology, will this solution provide any value to the business? How will it help the business? What business capability will support? Can we afford it? Do we have the right kind of people? Do our people have the right skill set? What training do the users need prior to rolling it out? So, yeah, that definitely speaking budgeting is a big, big part of it. And you know what? The key is if you've come from a tech background, budgeting looks scary. business background, budgeting doesn't look scary. One great thing is that we can all learn anything we want. So, yeah, just learn it. But yeah, absolutely. Great question. Is there a relationship between data engineering and cloud architecture? A little bit. And I'll explain to you what I mean. Data engineering is typically how do I set up the data pipelines? How do we make sure we get data from one thing to another thing? How do we mine through the data? We're hands-on doing work. Cloud architecture is how do we solve a business problem with cloud technology? Now, when we get into cloud architecture, there are some technical components of the job. And if we really look what elements a cloud architect really needs to think about, they need to obviously know a lot about networking. Whether it's designing your routing, whether it's a subnetting plan, for example, or a supernetting plan, like a route aggregation plan, whether it's choosing the right kind of wide area network, what have you. Actually, here's a slide that I have that I can show you. So, that would be the kind of networking. Not how to configure the network, but how to choose. We cloud architects, enterprise architects, we need to know how applications are structured, the types of application architectures that exist, the strengths and weaknesses of each kind of of uh architecture that actually exist. How do we protect an API, for example? What are the types of APIs? What are the strengths and weaknesses of each API choice? Same thing with load balancing. We load balance between clouds, virtual machines, we load balance between containers, we load balance between block storage volumes with RAID, we load balance between GPUs and AWS. We architects are selecting compute. When do we use a bare metal server versus a virtual machine versus a container versus function as a service. Same thing with IAM, you know, what kinds of IAM do we choose? What are the strengths and weaknesses? What kinds of authentication? What kinds of authorization? What kind of cloud access security brokers? What kind of federation? Whatever. And there's data. Now, in our world, we're still going to be designing data pipelines, just not building them. We'll be thinking about ELT and ETL type tools, we just won't be touching them. We'll be looking at, you know, whether and how we could and should create a data lake, if and when that makes sense. We'll be looking at when and where we should be using a relational database versus a no SQL database versus a data warehouse versus vectors, which is a type of no SQL, or whatever. So, there's going to be a data element captioning over. But you know, in our world as a cloud architect, there's a lot of security elements, you know, how do you design the security? What components go into it? A lot of storage and a lot of disaster recovery. So, when I get someone from an engineering domain, they typically have specialty in one of them. Now, this one specialty that you have here in data is quite good. Because data is really the key driver behind any kind of meaningful AI. So, the data knowledge that you have is going to be very valuable because it is one of the many areas. Now, what's the key to remember as an architect? is I promised you the people that work at Cisco know networking better than you probably would. Kind of And let's say you know data, you're going to know data 10 times better than the average person at Cisco would, because that's your job. I can find you people to bring you in security from Cisco or Palo Alto or Fortinet or Check Point that are so good, they'll terrify you with their security knowledge. And we want that further help. At the same time, I know people at What was it? Pure Storage? I think they're called Everpure that are so knowledgeable on storage, they can help you figure things that you wouldn't even know. And that's the key in your architecture world is as architects, we're generalists on everything. But if you've got a specialty here, you'll be much more inclined to do AI forward design, so that's going to be a good thing. So, the key is to take what you've learned of that, and there's a lot of good data knowledge that you have. And the key is to take that with you, cherish it, to take the experiences that you've had in tech, watching where things have gone right, wrong. Where was it a personnel issue? Was it a timing issue? Was it the PM didn't know what was going on issue? Because you've probably seen that. And that's going to give you a lot of examples on what not to do, cuz you've seen the mistakes that are made, and you've got some deep domain expertise in an area, which is awesome. So, put it that way, you could always be a cloud data architect. Or you're a cloud architect, but you sub yeah, focus a little on data. That would be a possibility. But the reality is anything for the most part in the last 20 years had AI in it. People think AI is new. I mean, our David Lethicum, our chief AI instructor, worked on AI in 1985. In 2001, I was on Wall Street with an AI system that processed trades algorithmically. So, it's been around for a long time. And the people that have really strong knowledge in data tend to be really great in AI systems, cuz data is the source of truth for all of it. So, you'll have lots of lots and lots of great options. Good question. So, the next one is the last question unless you have some. And if you don't, I'll be playing with my cat Cynic, cuz I know she's been looking at me. But if you do, please ask. Does it make sense to take a cloud engineer job then transitioning to a cloud architecture inside the same company? Well, if you want to be a cloud architect, ideally the first job you take as a cloud architect or a cloud solutions architect. Because the job of learning a cloud engineer's job is learning someone's different. Now, here's where you're going to get in we you might get into trouble. Because an architect is seen as an executive, and an engineer is seen as a techie, sometimes it's fairly challenging for serious engineers to move into an architect role at the same company. It's kind of like in movie making, they took they call it typecast. For example, I always watched a lot of Sylvester Stallone movies, but he didn't make a lot of romantic comedies or love stories. They're all action films. Cuz everybody saw Sylvester Stallone as an action star. Now, that also happens. So, what I have had to work with a lot of people that come from both cloud and backgrounds to get them the first architect job. For example, I think Wallace, who was a sales rep, went over to JP Morgan Chase, enterprise architect for his tech job. I at the same time, I think Balwinder, stay-at-home mom, hired by Microsoft as a cloud solutions architect. Or Jordan, college student, first tech job, cloud solutions architect at AWS. So, a lot of people I've taken from roles like those. Now, I've taken other people like Harsha, who was a cloud engineer for 13 years, and it took about a year and a half in the same company to get them to see him as an architect. I had a somebody in the forum, he had about 20 years with his company, took us about a year plus year and a half to get his company to see him as the great architect that he truly was, but he did move up. In other cases, once you work as an engineer somewhere, they see you as too technical and don't move you up. So, the bigger question is do you need a job right now? Because if you have the cloud engineering skills, and you need a job right now, it's always a better position to be looking for a job when you have a job. Kind of like if you need to borrow money from the bank when you have no money, they'll never give you anything. But when you have money and don't need it, or they'll be trying to throw money at you to loan it to you, cuz they know they're going to make a lot of money on the interest paying it back. So, I'd rather see you employed if you have the opportunity. What I don't want you to do is try to develop cloud engineering skills to get a cloud engineering job with the hopes that that'll make you an architect later. Because what that really is doing is training you for a different job. If you want to be a physician, don't become a nurse. Go to medical school, not nursing school. So, that's the answer. So, it all depends on your place, where you're at. what kind of jobs you need. And uh it all depends on how great that cloud engineering offer you might have. If somebody gave you a really big cloud engineering offer and you're not in a great position now, I would take it. I would take that cloud engineering offer. I would work and develop my architect skills outside of that for about a good year, year and a half. I'd really master those skills and I'd get an architect job, probably somewhere else. But maybe at the same company. But in either case, you'll be good. So, sometimes it makes sense, sometimes it doesn't. It all depends on the company. But it's really a great question. Any other questions for me back there, Chris? That's it? Okay. Well, let me tell you about three big free things and if any questions pop in, I'll address them and otherwise we'll call it a day. But before I do, if you're having a good time, can you give the video a like? Maybe subscribe to the channel, hit the bell to be notified of new things cuz we've got a lot of good things coming your way. So, tomorrow, David Lethicum and I will be discussing how to become an artificial intelligence architect. It'll be live on Zoom. You can ask us any kind of architect career questions you want. AI architect, cloud architect, security architect, anything. We're there to help you. So, uh please uh bring in your questions and we'll do anything we can to answer them to help you build a career. At the same time, I wanted to let you know that we're going to be doing for about 4 weeks in a row. We're going to have some fun. We're going to do a free enterprise architecture boot camp. We'll talk about the different kinds of architects. We'll talk about what we do. We'll have a little bit of fun with some enterprise architecture frameworks, enterprise architecture things. Maybe we'll have an enterprise architecture project or two that I'll lead and guide along the way. Should be a lot of fun. So, it's free. Register. Hope to see you there. And of course, I wanted to remind you that in the description of this video, we've got many free guides, guides on how to become an architect, guides on how to win an interview. So much of it and it's all free. So, please check it out. Thank you so much. It was so nice to see you all today and I hope you
