Enterprise architect vs Solutions architect vs Platform Architect: Key Differences Explained

Welcome everybody, to our special session on the differences between the Enterprise Architect, the platform architect and the solutions Architect. We're going to get started in a few minutes. Give everybody a few minutes to join in. My name is Chris Johnson. Of course, for those of you that do not know me, I'm the chief operating officer here at Go Cloud Careers. And we'll be joined by Mike Gibbs here in just a few minutes. We just finished up one of our class sessions, so, we'd like to take a few minutes in which point and just to kind of rebalance ourselves. So, yeah. So this is a joint, joint session we got, students from the program, a couple people that aren't in the program. We've got some old names. I see a guy over there, is smiling big. Yeah. It's good to see you. Yeah. How are you doing, Chris? I'm doing good. It's always good to see you when you pop in. Oh, yeah. Right. Well, this is where I was born, Chris. You know, so when I need to, upgrade, I know where to go to my home. Well, if you were not in class just a minute ago, you missed another student saying he got up, got his. Got a job at Cisco. So that was a quite an exciting experience. Hey. That's good. Well, good. Yeah. It's always, always nice when we have people come back and, share. There's, it's always a good time. So, Mike is asking me for the zoom link. Okay. I need to give Mike the zoom link. All right, well, it looks like Mike is here now, so let me let me, Mike up here, and then let me put me on the right side. Oh, it's like to be Never on the right side. All right, there we go. We are all here now. All right, well, today we're going to have some fun. And we're going to talk about the kinds of architecture roles that exist. And the reason I'm doing this is I want to add some clarity. You may hear one architect say they're doing something in their job, and then someone like David Linthicum would say, I've never heard of that in 30 years of being in architecture. And then someone else to say, I've done this. And someone like me who's been an architect for decades, will say, I don't know any architects to do that. And it all depends on what our definition of an architect us. And generally speaking, there's three categories of architects, and each one of them, for the most part, is a different job. It focuses at a different altitude, and it generally takes a bit of a different set of skills. And that's great. You know, in a hospital I need a pharmacist, I need a physical therapist, and I need a physician. All three are equally important, but they all work at a different altitude. That physical therapist gets down and dirty and to rehabbing the patient. Musculoskeletal things, soft tissue work, exercise, what have you. Where are the physicians writing the plan C physical therapy. It's a different job and it's about having the right skills for the right job. And that's why we're talking about this today. So when you're on an enterprise architect interview, which is different than a cloud solutions architect interview, you'll know how to position yourself. how to show why you're right for that role. And you'll be able to show why they need you, because you're going to prove competency. And unfortunately, if I talk about medical things all day, you're not going to think I'm a better airplane pilot. You can medical person. So that's what we're going to talk about. So first I'm going to go over an overview of these. And many of you are my students. So many of you already know these. But, I'm going to walk through the three types. I'll draw a little bit of a visual. And that's the problem. So there's this concept of what is architecture. And it's just so misguided. Confused. And the data is actually that 80% of engineers fail when they try to become architects. And yet other people would think that engineering is going to be so helpful. And guess what? They're both right. Depending upon the architecture role, in some cases, engineering can be particularly helpful. In other cases, it could be a completely different skill set where there's still things that can be gleaned over time. But that difference is really based upon the actual architect job itself.

As a rule, architecture is leadership. It is not implementation. And that is the career ceiling for many. They think of themselves as a builder when the reality is they're a designer, they're a planner. So if we look at the three roles, what we have, and this is where I typically draw them out. And today I'm going to actually get into the other solution architect roles that also exist, and which is what causes so much confusion in that. But I'm going to start primarily with the three categories. Enterprise architect, platform architect, and then solutions architect. And then we'll dive much deeper into each one. What you need to prove on an interview, what you'll be doing in each job. So if we look at the at this arc, it is, basically map of the architect roles. We have three kinds of architects. We have the enterprise architects. And what the enterprise architect is focused on is optimizing the business. The entire business that exists. Not just the tech, the whole business. Now, how do you do that? What we do and focus on is we focus as enterprise architects on making sure that the organization's business strategy is supported by the organization's technology strategy. In this role, we are focused on competitive business advantage. predominantly interfacing with executives. Our success as enterprise architects is measured in business outcomes. What was our impact on EBITA? revenue? What was our impact on productivity per employee? That's enterprise architecture. And you'll see what we do is different than others. This is an executive job. And statistically speaking, 50% of executive enterprise architects do not come from a tech background, which is interesting because it's one of the highest paid jobs. And most of many people don't come from a tech band. consulting worlds, they come from sales, they come from program management. Of course, they come from tech to 5050. Now when we get to a platform architect, it's still an executive role, but it's now focused on a domain. So the platform architect is focused on what you would call a platform. So the multi-cloud architect is responsible for the organization's cloud platforms. That means they're private clouds like the Nutanix and OpenStack clouds. That means there are clouds of stuff that's sitting in a co-location facility. That means their stuff is in AWS, Azure, and Google, the entire cloud, all of it for the Cloud Architect, security architect, again, a platform architect responsible for the entire security strategy for the organization. The organization's assets and the organization's people. That means security from the data center, security around the buildings. That means incident response procedures. That means security on all the clouds, all the data centers, everything. The platform architect, A. I. architect, which we also teach, is another platform architect responsible for the entire AI strategy for the organization. Platform architect. So at this level, we have someone that's a domain expert and a business executive, and they're there to optimize one platform to give that business competitive advantage. So for example, the cloud architects will be finding a way to use the agility of the cloud to accelerate that organization's innovation. So Enterprise Architect focused on optimizing the entire business platform architect the entire tech platform like a network architect for all the networking on the cloud, off the cloud. Why they're all now the solutions architect. Generally speaking, when we talk about an end client, normal traditional solutions architect, we're talking about a person who designs a single workload or a single project. So this person is focused on the organization is 200,000 people. This focus the security architect, is focused on security of the entire organization. The security solutions architect is focused on how do we secure this one workload, like the website. I want you to see the impact of this entire business, entire platform, single thing. Because we're going to talk about why you that's going to define your career. It's highly strategic. Strategic and wide technical. Now that solutions architect, if they're focused on one thing

we'll have to have more technology. Because they're focused on one thing. They're going to dive deeper than this person. That's the Cloud Architect that might be focused on that organization. 50,000 servers and 200,000 containers that are sitting in three cloud providers with all the networking, all the security, all the everything. And the enterprise architect is focused on the whole, on the entire business. Now, what really confuses things, because we actually have three kinds of solutions. Architects. So we typically have the end client oops end client solutions architect that we have over here. Now they're typically focused on working at a company. Let's say that you work at a hospital or bank. And let's say that you are there to focus and you're there to focus on a single project. Okay? The new network that's coming up, you work for that client, you're focused on that one particular thing. And when that project's done, you get another one. Now there's the pre-sales solutions architect, and I was a principal solutions architect in these roles for a while as well. And what we do here is we design it, we meet with clients, we figure out what the client's needs are, and we try to make a recommendation and we design a solution for them. We present it back and we sell it to them. What do you think gets you promoted here in the Pre-sales Solutions architect role? Do you think it's your technical abilities, or their ability to increase sales and bring in more deals? The difference between someone that generates a lot of sales and someone that doesn't generate sales, determines who becomes a principal architect immediately who goes up. And that's why I was a principal architect in less than two years, because I knew my job of sales, and that's what I focused on. Now here, this is a bit different. This is the Technical solutions architect. This is closer to an engineering job. This person is going to be focused on a one workload, but they're going to be deeply focused on it. And this is the kind of person you typically go to. You put him in this role because they're not really building stuff all day long anymore. Now they're making deep analytical decisions and evaluating trade offs. But they're not executive facing. This person might actually touch the tech on their job, and it would be appropriate for them to do so. This person should not they will generally won't be. This person generally won't be but could be. And those of us in these levels, these are executive roles. I also want you to understand and this is not my world. I think this is the worst thing ever. But as you get closer to the technical levels, generally speaking, your salary and your promotions go down as you go closer to the executive level, your salary typically goes up by a significant order of magnitude, but we have to do what's right for us. And all I care is that you get the job you want the job that's going to make you happy, and a job that you can enjoy, because at the end of the day, that's what matters. So at a brief description, that's what we're there now in any of these roles. What makes these roles different is the way we think, the way we act and the way we do. You know this the architecture really reminds me of practicing medicine in my youth as a nurse practitioner. And here's the reason it reminds me that way medicine is all about trade offs. When a person comes in with a problem, there's lots of treatment options. We can give this medication. This medication has these benefits because these side effects, this medication causes, these benefits and these side effects. We need this medication. But it gives us a side effect so that we give another medication to stay of that. And you see how it all spirals out of control. It's the same thing with architecture. If we make this decision, this decision will force us into this pathway, which will cost us to do business this way. This decision will make it much simpler for us, but it will make it come more complicated long term. So architecture is a decision of trade off. At each level. We focus on different tradeoffs. We'll talk about that. So architecture is optimization under constraint. I don't know if most people do this in their daily lives where every time they're going to spend a dollar, they say, should I put this dollar in an investment? education, which is an investment in me? Should I put this dollar in Bitcoin? Should I put this dollar in a cookie? What's going to happen? But that's the way businesses spend money. So what businesses do is they evaluate what an opportunity is worth for them financially. And I teach my students how to do that. That's the expected value of an opportunity. And then what they do is they compare various opportunities to see which one is going to be worth more to them financially, on which one would be more strategic, what have you. So our job is how do we optimize under constraints? Because there's always a constraint, because even if they have all the money in the world, they're going to invest it in what gives them the best return on investment.

Now architecture is a lot like medicine. That is really decision making under uncertainty. Let's face it. Interest rates will change in architecture for a business potentially, and have to make that business a job to change a new law or a new regulation will make that business have to do things differently. A new technology, which could serve as a competitive advantage, may force that business to do things differently, to innovate in a new way. Unfortunately, you know, the first time I helped create one of the world's fastest AI trading systems in the world, nobody that we knew had ever done it before. Who are we going to ask for help? It was in 2000. These things were running in Sun Microsystems refrigerator computers, where we had all these PhD mathematicians that were writing algorithms. You know, we're doing it for the first time. There's not a lot of information out there. So what we did is collected information. We made decisions under uncertainty. That's architecture. Now the next two things to think about it. And it's going to help when I talk about the capabilities, what we do, how to prove success in an interview, that kind of thing is understanding that our job is about influence without authority and our architecture role. And actually let's map this out because I think this will help. And maybe expose a little more of what we actually have to do. So let's say we've got an architecture project. And we've got the we've got these, we've got the C-suite. On board. And if we're an enterprise architect, you better believe we're having conversations with these folks as part of what we need to take care of. Then what we're also going to have along the way. We're going to have all these key stakeholders that to work with. And then we're I'm going to call these business stakeholders. And then along the way we're also going to have these key technology stakeholders. We're going to have to support their needs. Now each of these teams is going to need different things. And you're going to have the different messages and different things. So what your job will ultimately become is you're going to be in a constant state of communication back and forth. Find that again, forth with the C-suite. Then key business stakeholders. key technology stakeholders. And this is all the more of the executive team. This is the enterprise architect. Now, that architect itself is going to have to need help here, because they're not going to be able to deal with all the technology things. So they're going to have their platform architects that are going to be working for them with them, which don't report to them, but they're going to have to build a team like that. Now, the platform architects will typically have some solutions, architects that are going to be working for them, or at least assisting them. And of course, those solutions architects are probably going to have some engineers that they're going to go to for things to, because the engineers are going to be more technical. So we're going to bring some engineers in, in everything we do to just running out of space here. But so let's move this stuff up a bit. Because that didn't look good. So our world here is mediating between what the executives need, finding out what the key stakeholders need, figuring tech leaders are able to do in their constraints. And then because as an enterprise architect level, we're focused on strategy. Now, we need to bring in our network architects, our security architects, our multi-cloud architects, our AI architects, and then they're going to be focused on the entire platform. So then they're going to be bringing in solutions, architects to help a little deeper. And then we might even bring in some engineering or some technical solutions. Architect that or technical experts. This is a normal thing. That's why enterprise architecture especially is a leadership job. But I promise you, if you're a cloud architect and you're over here, you won't know. Networking like the people at Cisco, you might not know network security, like the people at Palo Alto or Fortinet or Cisco. So you're going to need all those kind of experts as well.

So that's kind of the where we're at. It's this kind of influence, etc... So and before I get into it, we always have to think engineering builds the system. They implement system, they focus on which tools to use. They measure uptime. They're hands on and we need these people are great when it comes back to us. We're about strategy. We're about optimizing what we have, reducing redundancies, improving agility. We're focused on business outcomes. We're measuring our work as measured in ROI. And our work is about leading teams of people that don't even work for us, which makes our job, you know, an executive job. Okay, so let's dive into enterprise architecture for a little bit. What is well, I hate the term architecting the enterprise, but it is the strategy for the business. So for businesses to operate, what do they need? Well we'll draw out the real the main forces of business. So do we think a business is going to be very successful without people like a real business or solid business? Of course not. So we need people. What else do we need? Well. Do we think everybody. Well, naturally, in a business do their job in the best way possible? No. Do we think there's doctors that are better than other doctors? Yeah. Do we think there's some architects that are better than architects? Absolutely. What if, in many cases, it's not the person? That's the weakness between better outcomes and worse outcomes. But the way they actually do their job. So. What I mean by that is. What if we found the best way for someone to do their job? Were we removed redundant steps, we gave them the tools that they need to do their job better. Do you think most people would do their job better? Yes. In fact, you know what they used to do in the airplane industry before they'd take off the plane? Everybody had their own way of determining if the plane was safe, and then they came up with a checklist where every pilot in every airplane does the same check. And guess what? They don't miss stuff. And planes crash a whole lot less often. It's the process. So that's the second component of enterprise architecture. Find the best way for the company to do things and people to do their jobs. By the way, these are also Michael Porter's forces of business. If you if you weren't, if you come from business school, etc... Now. All right. Well. Let's talk about this. So we have the people doing their job and we have the right people just can't do much without people. Like the African proverb says, if you want to go fast, go alone. far, go together. So we need a people now. We found a way for people to do their jobs better. Let's talk about where this technology piece comes in. Which do you think is faster? You answer in the chat box to, sew a pillowcase on a sewing machine or to sew it by hand, each little stitch by hand, sewing machines a little faster. Right. Which do you think is faster to farm a field? Like in my village in Greece, where they use donkeys, where modern farm tools have big diesel power, things that can just mow through the yard like it's nothing. So the power tool. So that's technology, but that technology can be anything in auto manufacturing, a lot of the technology is robotics and various ports throughout the world. They're automated and the ports are almost automated by technology that makes less mistakes and also cost less. So the technology itself could make you better. You know, I remember many years ago where a patient would come in and I'd spend three minutes describing a three centimeter molecular popularize. Because it was language that every physician in every part of the world knew. You know what you do now, we take a picture of it with our cell phone, and we attach it to the chart. That was a better piece of technology. It is a much better indicator.

So technology is that last thing. Now could that technology be cloud computing? Sure. Could it be I sure. Now if we really want to look at the people, processes and technology piece, here's the last thing that you should be aware of. An enterprise architecture. This model is changing. And here's the change. What do we do with these folks? Agents. So, you know, some people still consider that to be technology. And some people are considering people and AI agents to be employees at this point. Not saying I agree with or don't agree with it, but if you start looking on, I think I need to. Sorry, I might need him to slide this over a little bit. So if you start looking at that, that some people consider this to be the new model of enterprise architecture, and this is where the confusion is coming in, where people think we're techie, not in this role at all. So in this particular role, since we're focused on transforming the business, changing the way the business is for the better, not changing the tech, changing the business. A hospital that once less medical ers, or an e-commerce provider that wants to sell more. That's our job. There. So if we're going to do that, who are we speaking with? Who are we working with? The executives, because only the executives know where the business is going, and they generally can't even message that to the rest of the team. So we're part of that executive team there. So when we are there as enterprise architects, what are we focused on? Fixing the business, making the business better? Does that sound like management consulting to anyone? Reducing risk, especially security architects, but even cloud architects and enterprise architects we're reducing the organization's risks. Drop some risk in the chat box while we're at it. But you can think of it exist in the business. What we're doing is enterprise architects is investment prioritization. I can't put I can't spend money twice every yes to something becomes and notice something of. That the reality. So our job is to advise I recommend we invest in this because this is going to hands this business capability the best. We might also be talking about investing and competitive differentiation. Some businesses have huge numbers of employees who make some money. Some businesses have very small number of employees and make an incredible amount of money. Some of those companies are extremely tech enabled. So we have to help that organization find ways to better compete. Sometimes as enterprise architects, we have to deal with mergers and acquisitions. One company manages another one, and we need to think about what it's going to take to connect them and how we can obtain efficiencies of scale where we reduce the redundancies. So I hope that sounds like long term strategic roadmaps to all of you. So here's what I typically start thinking when I'm in an enterprise architect. Here's what I start. These are the questions that I ask. And clearly I'm not Mr. PowerPoint even though I've used it forever. So the first thing we determine is are or are we investing in the right capabilities? To make this a little bigger so everybody can to. We're enhancing the speed and performance of the website. Do you think that makes a big difference to a hospital? We've added new cardiothoracic surgery capabilities that can drive an additional $300 million next year in surgery. That's enhancing capabilities. So we think about that. Then we think about or are we duplicating platforms? Don't put platforms. And what do I mean by that. Well. In my first tech job I went in and I asked which applications I was supposed to use for the business. And they gave me a list like 80 of them. And this is a long time ago. It's only gotten worse. And most of those applications were doing the same thing

now when it was even worse, instead of having it in all one application where we would mine the data out of it easily and be able to make better decisions. Business decisions, forecast, what have you, it was all spread out in such a manner that not only did nobody get any use for it, the system for open to hacking, because there was all kinds of vulnerabilities and we got no business benefit and we paid a lot more. And guess what? We had more complexity. So every time we tried to make a change, it became even harder. So we enterprise architects are going to say, are we duplicating platforms? And if so, what can we remove? Now the next thing we need to think about is architects is as enterprise architects. And I'll show you how it's different for each architect. As an enterprise architect we're concerned. Are we exposing that company to risk? Okay. We have a new idea, the new idea and risks along the way, even though it had rewards. And if so, what are the risks and are those risks worth taking? And the enterprise architecture level, we are focused on scale. Okay. So auto scaling in a cloud where you just add capacity is not scale. Scaling a business means do we have the right people? systems in place? Do we have the right options in place? And will our technology scale? Just because the tech and scale doesn't mean the business can scale. So in our world of marrying business strategy to technology architectures, we're concerned about scale of the business. And then, you know, we start thinking, what about alignment? Are we aligned to the market? Is what we're doing going to make it better if we're talking to a hospital and then we give them something that's great for an e-commerce provider, it probably didn't help. So that's really what we're typically focused on. So if that's what we're trying to do and that's the focus of what we do when we thought I needed this. So we make sure I do it. So if that's what we're focused on, the next questions we need to do and what we actually do, our job is on that. So. We have to translate business strategy into technology strategy. Okay. We'd like to enhance EBITA by 11% this year okay. They want to increase their earnings before interest taxes and deductions. How do I do that. That's my strategy. Well do I do something to enhance revenue. that, can can cut costs along the way? How do I do it? But that's our job. A lot of it is portfolio capability mapping. So what I mean by portfolio capability mapping is being able to. Know what capabilities we're investing on. And by doing that, then we know what we're supposed to do. And honestly, this is the majority of enterprise architecture. So I have a little fun with it. And you know, most of my life I was the chief architect for many years in health care. So let's talk about, you know, what we have to think. Let's say we're building a capability map for a hospital. We would do this for every business. So if it was for the hospital, you know what? The first thing we have to do is be able to take patients in right? You know, when you go, when you either dial you when you go in the emergency department, they have to figure out or your doctor tells you to go. So I have to be able to take in patients. So this means I have to deal with things like patient registration and determine you are who you're supposed to be, and check your health insurance if it's applicable. Deal with scheduling, what have you. So you got to be able to take patients in. Now, if I'm a hospital, what do we also have to do? We have to deliver care right? And that means the nurses need to do their jobs. The physicians need to consult with their patients. Maybe we need to offer surgery, for example. And a few other things along the way. So what I want you to realize, don't you think we need systems that enhance our ability to take patients in the next? Where would we invest our money in systems that help us deliver care? Well, you know what? We've got to be able to do diagnostic services to. What do I mean by that? So it'd be really hard to know if someone had a broken bone by looking at them in most cases. But with an x ray, it's pretty easy to do.

So if I'm worried about someone having a stroke, I might do a Cat scan or an MRI of their brain immediately so that I could treat it immediately. So we have two other diagnostic services. So what does that mean? That means imaging which means slots of storage, for example. That means a whole lot of chronic health records for what have you. So wow. You know what? We need to be able to get medication to patients. So that would typically be pharmacy. And I'm going to stop here. I just want you to see the point of what we're trying to do. And why do we need pharmacy services. Because someone like me is going to prescribe the medication. A physician, a pharmacist, will dispense it. The nurse will administer it. We need to make sure we have the medication so the real key of enterprise architecture is what we're really doing is we're trying to say if these are the capabilities we need, how do we make it better? By with the right people, the right process and what technology can augment it. So that's if you look at our job, that's that capability mapping. Now we realistically speaking, have to look at the portfolio of applications and investments that we have. You may noticed a lot of people just went to the cloud many years ago. And they stuck everything in the cloud with this kind of cloud first strategy, because someone told them they were going to lose money and save money that way. And you may have noticed it got so expensive that now everybody's cloud repatriating, or 84% of the people are coming back out of the cloud. Well, that's portfolio optimization. Just because we thought we had something doesn't actually mean we are doing something. So for example, if that enterprise architect level, we're still evaluating mergers and acquisitions, we're aligning the security posture with the enterprise's risk appetite. Risk tolerance. We're talking governance framework. For example, executive steering committees. So there is no time in the enterprise architect role to ever think about touching the target or being near the target, because our role is consulting to the CIO, the CTO, representing the boards or participating in budget decisions, we're influencing capital allocation, meaning building business cases for the company knows what to do. And that's why our job is strategic planning. You may hear me talk about, business acumen for the enterprise architect. All architects, but especially the enterprise architect, because you're going to have to build financial models that show that your option is there. Things like net present value, total cost of ownership, ROI, modeling. You're going to be creating risk governance. So this is management consulting, not engineering. So that's the enterprise architect role. And 50% of us working in this space don't come from tech like I come from internal medicine. That's the enterprise architect. So now we get to the platform architect. No, generally speaking, the platform architect isn't where the architecture confusion is. The real confusion starts coming in when we start getting into solutions architects. But, let's go back to this model. So we talked about that enterprise architect. That enterprise architect is an executive strategy. And again you're just as a reminder. And I don't think it's fair the case. But just so you can plan your career as you go, this way, you start opening yourself up to more opportunities and substantially higher salaries. But there's different ways you can pivot these careers to higher salaries, too. And if you want to ask about that, I'll happily tell you as well. Now. I guess I'll give you a couple more tips. Let's say you're in an Enterprise Architect interview. What are we going to assess? We're going to assess your executive presence right. Because you have to be able to present to executives. We're going to assess your business fluency, your ability to influence your financial literacy. We're going to be evaluating your strategic thinking, your ability to reason and ration around trade offs. And your ability to align key stakeholders. I thought I probably should cover that. I didn't mention it before. Before I get into that platform, architect, let's get into that platform architect role. And I've been a platform architect. I had lots of years as a network architect, and quite frankly, I thought it was fun. I've had fun and every architect role I've ever had, truthfully. So going back to that platform architect that I showed you, this is the owner of a specific platform, for example. And David Lithium teaches AI platform architecture with us. David is teaching how you create

an AI strategy for that entire enterprise to create competitive advantage. When me and Isaac teach the Security Platform Architect program, here, we are teaching security everywhere in the cloud, off the cloud, everywhere. Because when you're dealing with the network architect, they're just not networking with Cisco routers. They're dealing with Cisco things. Juniper things are rest of things. They're dealing with wide area networking. They're dealing with cloud all of it. The entire network. So that's what we're talking about with a platform architect. Again, in this role you don't build stuff. You are way too expensive of a resource. valuable in getting information because for us, it's a platform architect level. We want to make sure we have the right platform and that the platforms are doing the right thing tuned and optimized. And most importantly, are the platforms delivering competitive advantage? Are they delivering business results? And because of that, you're going to be focused on platform optimization. We went to the cloud. Well I made this thing a microservices thing based and it cost us ten times more and we got no business value. All right. Let's take this thing back to the monolith thing. Okay. We ran this monolith that didn't work. Let's refactor this application to get it more cost efficient. So we're going to always be optimizing that platform. And how we do this, we're going to be coming up with whenever possible standardization. So reference architectures to make things simple. And what do I mean by that. Imagine in your team. So there are companies that I've worked with that have many hundreds of architects that are working for them. And just the architecture teams. And imagine if every architect decided to design their own thing, their own way. Anybody tell me how that would be managed? Can anybody think about the impact of that on a security perspective? From an operations perspective? Well, Onyeka Lyles did a great job. Imara did a perfect job. The galley did a great job and asked to see you did a great job. But, regular SoC, he sometimes misses things and he missed something. Sorry. I think of Greek names first where I come from. So you know, that's the thing. It becomes impossible. But multiple people all configured it differently. So now you've got different support and operations things. So we're typically thinking on standardization. not for example, going to being a platform architect, thinking that the AWS X environment is a perfect control plane for our Azure cloud and our data centers. We're going to say, all right, do we want to manage our own cluster? Do we use something like OpenShift that works on all clouds? Because we can't be managing multiple things in multiple places, then multiple control points in the cloud platform level. At a platform level, we're thinking about governance for the entire platform. What kind of guardrails can we put in to enable things to occur faster on pre-approved things? What kind of say a cloud landing zones can we use to optimize security from the start? Security principle same thing. What can we do to reduce the risk of the platform? For example, everybody that knows me especially well, I see some of you that are working architects. I, that I'm, that I've trained in the past, you know, we always talked about why you can't be on a single cloud and high availability. I remember initially people laughed and then they started to see that way there were control plane failures. There were security failures of the cloud. There were just configuration mistakes. The whole cloud went down. And okay, now we're on. 98% of people are multi-cloud. That's risk reduction. But some people didn't realize the risks. They didn't understand all the things that could go wrong with a single cloud. And people like me had to come in and clean it up. I've been doing that my whole life. No big deal. So again, even the platform architect, we want to make sure that our AI strategy matches the corporate needs. So here's something I always like people to think about. Let's say that you were going on a trip and I didn't tell you where. And it could be Antarctica. It could be Montego Bay, Jamaica, which would be a really nice place to spend some time right now. Or it could be in Alaska. But you don't know. And somebody else packed your bag. Do you think you're going to have the right bag? Somebody packed you for Jamaica. You've got your bathing suit, you got your shirts on like this, and all of a sudden you're in Antarctica. You're going to be cold.

So it's the same thing with architecture. We fell when the technology teams say this is a cool thing and they start building it, but they don't know what problems they're trying to solve. If you're an airplane pilot and I've never flown a plane, can I really determine what you need in that airplane? No, but I can ask a whole bunch of airplane pilots what they need, and I can ask the flight attendants what problems occur when you're running these things in the background? Where are the points? And find out from people what they need. Then I can speak to the airline executives and understand where their challenges are. Is it fuel cost? Is it this? Is it filling the plane? And then create a strategy. That's the job. So what's the platform architect going to do? Well, I'll give you the security architect. The I'll pick the, multi-cloud architect and I'll pick the network architect. So when I think a security architect, here's what I see. I see someone that creates a strategy to protect the organization, to protect the organization's assets, and people. So if I'm going to protect something, what do I need to know? I need to know what I'm protecting. Right? the value of what I'm protecting. And I need to think of what are the risks to that thing. Where are the risks? How could those recipe exploited? How would an attacker attack the system, and how would I send it up? And then I have to determine the right level of protection based upon what it is. So if in this role, one of the first thing we have to do is develop an enterprise security strategy, what's that going to be? And a strategy, for example, is not just about firewalls and IDs, IP essence. It's the way people do their jobs, the way people think about things, the way people respond to requests, the physical security in that building to make sure that we are not breached, the everything that we've got going along the way. Now, in today's world, there's when we deal with cloud computing, for example, there are just new weaknesses and new attack vectors that didn't exist in the past. So we have to secure differently because of that. You know, when I have a security architect, I need them to be very explicit and be very capable about mapping out a zero trust and a strategy to an enterprise. All the components to it, from the IAM to the segmentation to the constant encryption, they need to be able to map it out and be able to design it. I need my architect to be able to look at some form of a risk framework, understand what those assets are and understand the risks to those assets. Here's the reason why. If I were to say Chris, on my team, Chris, I want to invest in $1 million, security policy to secure against cats eating birds. I promise you, Chris is not going to say spend the money on that. No, not at all. Maybe $1,000. Yeah, exactly. Because, yeah, well, we love both love cats. But, you know, that's the thing. So it has to be relevant to what we're actually doing. So with us as the Cloud Architect, we're designing the cloud strategy. Within 98% of cases for an enterprise is multi-cloud. And in most cases, it's put the high performance, high throughput workloads in a data center where it's 3 to 5 times cheaper, if not ten times cheaper, to run the sporadic and the agile workloads in the cloud. Use each cloud provider for what it's extra good at, and that way you have the best technology and some redundancy and availability at the same time. And guess what? Doesn't cost more? To buy 50% of your eggs from one grocery store and the other 50% of their eggs from another grocery store than it does to buy them all at one. And it doesn't cost more to put 50% of your stuff in one cloud and the other the other cloud, minus any negotiated discount. But for the most part, it's the same thing. So that Cloud Architect is going to be dealing with landing zones, you know, how do you set up a pave road where everything that comes out meets all operational security requirements from the Mr... The multi-cloud architect is going to determine a workload placement strategy. For stuff that runs all the time, it's a whole lot cheaper on servers that are sitting on my data center for something where I need extraordinary performance. It's a whole lot cheaper in my data center, potentially ten times cheaper or more. Well, in an environment that's sporadic, we don't know what it is, but is. That's a good place to put it in, someplace that's going to shrink and grow on demand. And then when we figure out, we can determine where the optimal place

to put it is. But at least we can figure that out. Now it being able to look at the environment and say, I've got a latency thing, how do I minimize that latency? Being able to look at it and say for this particular data, it can't leave this geography. What should I do about it? That's that multi-cloud architect platform architect role. Now my multi-cloud architect is going to be looking at the cloud spending and saying, okay, what are we getting out of it? We've invested this much. Has it yielded this return, this return of this return? If not, what what? Why not? Is it the wrong use? cost model? Is it the wrong this? What should we change instead? That's our platform architect. To that platform architect is still a good, strong role. That's why I train people for either enterprise architect roles or platform architect roles. Because it's easy to get the solutions architect roles when you have these skills. But keep that in the back of your mind and network architecture. That was a fun job for me. Boy, I love that I got to see every part of the world in networking. One day I'm in Panama, the next day I'm in Dubai. A day after that I'm in England. Spain. I was just having a fun and that one at work architect job, especially in the days of advising ISPs on their internet service provider bill, don't. So at that point, what's that network architect responsible for the entire network strategy for the entire organization. So let's say we deal with a big business and they've got 5000 offices. That means the wide area network to all connectivity between the data centers. They have the connectivity to the clouds, remote access users. It's a big job. You can have lots of people on your team now, as a network architect, I was constantly optimizing for latency, for bandwidth, for jitter. What have I was coming up with? All kinds of ways that we could segment the nuts and the systems, optimize our routing, use traffic building to enhance security. So that's that network architect. So platform architects as a role are still hands off roles because you know, and we generally don't deploy a workload. We don't configure a firewall. pipeline, a ticket, etc. because we have a lot to do. of conversations with some key stakeholders. We have to understand that business. the C-suite. constraints. We have to understand the vendors. It's an incredible thing. So it typically takes me to lead an architecture team. Even on a platform, architectural 6 to 12 months, to even get the information we need. Now here we're going to lead patterns in this type of a role. Here we might lead a standards community. We might lead. We might be part of an architectural review board. We're here to optimize the investment. So what we're really doing is more governance leadership in that platform. bigger, but still where instead of like an enterprise architect, where the entire enterprise here we're zeroed in on using cloud as a competitive advantage or AI as a competitive advantage. More governance leadership. So what are we creating here? Well, if an enterprise architect was creating business capability maps, since that's not platform architecture, the platform architect would be creating reference architectures. Okay, here's what your cloud landing zone looks like. Okay. Here's which are your VPC peering situations are going to look like for our hub and spoke environment. Here is what our standard DMZ looks like for a web facing up. We're going to be typically dealing with some flavor of a security control frame. Or we're going to map to zero trust. nest. We're going to map to whatever. We are typically focused on standardized design patterns. We are typically at this level focused on governance policies. When changes to occur, how will they be need to occur? What kind of cultural change will have to change every time we want to change? To be a Kurt. Now here we're getting a little more technical. We're thinking about maybe technical standards, catalogs. You know what that actual technology would look like for various components of your system design. Here's another thing we do a lot of as platform architects, we create a tremendous number of architecture decision records. And if you're new, here's what an architecture decision record is. It's a single one page document. That said, here was the challenge we had. These were the architectural things that we considered, and here's what we chose and why we chose it. And that way you can look back at the history and see the decisions that were made. Why do we do this? Because if you don't, if you've never learned history, I promise you'll repeat it. And if we look at history, we can see the same things repeated again and again. But if we study history, we can not make the mistakes of the past.

So that's why we're doing good. We're creating product platform roadmaps. Okay, now we've got this here. But where we want to take it in the future. And we're doing a lot of compliance matrices. So if I'm a network architect, I'm going to be looking at the networking thing and see if they're going to meet all the compliance and rules and regulations I need. Yeah, not code. Strategy. So let's go back to this. And this is where all the architecture confusion comes from. Business strategy for the entire organization using a single platform like AI for competitive advantage. Now. The next level down. And actually a question popped in so I'll discuss that. So management consultants are what's called business architects where they architect a business enterprise. Architecture includes business architecture. But it also includes application architecture data architecture and technology architecture. So, we do business architecture, but I wouldn't exactly define it as a business architect unless you're a chief architect. And then it becomes a business architect role. So let's go back to the content. So when we talked about here the entire business and here we talked about the entire platform. Now we're talking solutions architects. And what I'm going to do first is talk about the normal traditional solutions architect role. The real one. And then I'll talk about the pre-sales one. And I'll talk about this technical architect role, which really isn't an architect role at all, but it still does some design things. And I'll talk about what they do and what distinguishes that and why these folks are still pretty darn important, and why they're going to be some of your best friends when it comes into architecture. So now that we got to the solutions architect world, we're now in a world where we're designing for a specific system, a specific product, or a specific workload. So I want you to really think about that. We've gone from the enterprise architect to everything from how the people do their jobs, to which people we should hire, to which systems we need super high altitude. They're we got to the platform architect, and we're now with cloud. We're talking about pretty much everything across a whole bunch of data centers and cloud providers. Now we've reached out solutions architect level, and we're now worried about a specific system or which specific product do we use or which workload we choose. Within our enterprise architecture and our platform guardrails. This is project level work. So what the solutions architects are going to do is they're typically going to take the business requirements that were gained by the enterprise architects and from the platform architects, and they're going to work with that. And that's why the solutions architect job is often people's first architect job, because it's fairly entry level in what it is. But, there's some extraordinarily good, solutions. Architects and I know have friends that have stayed here forever because they love it. And that's okay to but one particular thing. Now, I want you to think about this strategically. If you go from focusing on, you know, the way 200,000 employees in their business do their jobs and all the systems to support it, how deep can you get into any one thing there by yourself? A very now all of a sudden, you're focused on a single workload. That's the zoomed in part of the solutions architecture. So at the project level. So the solutions architect will be more technical. Now the primary focus of the solutions architect is to fit is to take the business capabilities that we've given them and find a way to meet it with a technical solution. They're going to translate the requirements that we've gained as other architects, and then figure that out into an actual hardware architecture. So the multi-cloud architect says we need 5000 virtual machines that need 16 cores. And 32 gigs of Ram. Those solutions architects determine which AWS EC2 instances they choose to be, or which Oracle Azure Virtual Machines, or which Google Compute Engine instance they're going to be. They're going to turn that into that one thing. The solutions architects are going to be looking

at a whole lot closer at that one thing that they're focused on. So if I've got a solutions architect that's going to be designing a website workload, they're going to be much closer focused on the cost side of that single workload resume. Then that's their goal. That's their job. Now they're they want to make sure that the actual architecture adheres to the enterprise's standards that we, Platform architects and enterprise Architects created. And because those solutions architects are more technical and they're less of the business executive and they're less focused on on enterprise capabilities and roadmap, they're going to be more focused on spending time with engineers. So in my enterprise architect job, I may not get to spend a lot of time with engineers, though I might spend time with engineering, management and other architects and some principal engineers, but not that many. That solutions architect may spend a lot of time talking to technical professionals because they're going to work with them, and they need to make sure those professionals can do it, do what needs to be done. And they might be a better expert for them to help them. So the solutions architects are gaining. I'm telling you, no business requirements like what's the availability performance of this thing. Solutions architects are also leading a solution workshop. Maybe you work for a vendor and they want to say, here's how we're going to design this thing of the future. And you bring people in for marketing purposes here. They're designing an architecture diagram, which looks a whole lot less like an enterprise architecture diagram or a cloud architecture diagram. Here's where you see a diagram that actually lists the exact model, the exact service that you're using from the cloud, the exact router number, the exact type of a circuit, and the solutions architect more focused on solution based trade offs. So well, we enterprise architects could be focused on the market. There's the opportunity the people they're typically focused on the trade offs just of do we use, do we use Apache Cassandra? Do we use Mongo DB those types of tradeoffs. And they're typically there to lead design reviews, design nonfunctional requirements. So again that group also designs. And let's talk let's break it down into these three sets of jobs. And of that we go back to. So I'm going to break down the three solutions architect jobs into the end, client solutions architect, the pre-sales solutions architect and the technical solutions architect. So let's take here here's the traditional solutions architect. Traditional. This person like we said, is focused on workload design. They are focused on optimizing the workload. They are I. They're focused on the exact service or tech selection. That's where they're typically focused on. Now this person is going to get into some pretty deep technical depth, and they're going to be having a lot of conversations with people because they're focused on one thing. That's your traditional. Now, depending upon how this person in this role hinders their career will determine what their impact is and what I mean by that. In that traditional solutions architect role, if you start giving presentations to your management and you start, speaking with more key stakeholders and you start leading more initiatives, when there's a proof of concept, you scope the determine the resources that are necessary to staff it. You determine, for example, what the capabilities are of the people that need to be at that proof of concept. You're an escalation point. So when you're engineers building the proof of concept struggle, you could bring it to the next level in that job. That's typically the way you excel on those jobs. And I'll tell you, I've had a lot of solutions. Architects. We trained them for those roles. They had those roles. They immediately got promoted. They did very well. Now, if you're not careful in this role and you start doing engineering in that traditional solutions architect role, which some people can do, and they'll do it if they're comfortable with it. Here's what happens. The engineers will love you. They will love you. You will maintain extremely good technical, hands on skills. Unfortunately, the leadership will see you as technical. They will not perceive you as the business leader. And you typically that's typically where people get stuck in that traditional solutions. Architect career.

I've had many people have done it in the past. There's there. So keep that in the back of your mind in that role. Because in that role, you're still a strategist. Let's take the next role. And this is one of the most fun solutions architect roles out there. It is I it is it is, it is just, it is terrific. And this one can pay fairly well. So this is the Pre-sell solutions architect. Oh, this is a fun job. This is really fun. So. So this is where you work at a house, you work at Microsoft, you work at Cisco, you work at IBM, for example. And you were there to help solve client's problems. And you'll meet with the client. They'll have an issue. They have an initiative, and you'll go there to consult to them. You'll be part of the sales process. And this particular role, you'll go with the sales rep multiple times back and forth to the client. You'll take the clients to dinner to get the clients to. Lunch is very similar to a sales engineer role, which is a very fun role as well. And in this role, you are there for design. But I want you to realize this in this kind of a particular role. Let's say you're at a company like IBM, IBM's and everything. You're not going to know everything. Let's say you're in Cisco. Cisco is in everything. They're in AI, they're in data center compute. They're in security. They're in routing, they're switching. They're in there. And everything. So you're not going to be able to know everything. If you're at Microsoft. They're in everything from video games to I think even phones. If you're at AWS, they're at a lot of different things. So what the job here is, is you're aligned with the sales rep. So what you need to be able to do in this role is to be able to come up to speed fast on a new thing. For example, all of a sudden you found out your client's working invoice. You got to learn a little bit about a voice so you can work with your client. But you know what you really need to do now. You need to find the experts at your company. And there's a lot of them. And you need to build out a team of these experts. So if you are in Cisco, they all have consulting systems engineers and technical solutions architects that can help you with, say, port security for that example. Or somebody else would be an expert on, you know, pushing layer two security versus layer three security. So that's your role in here. Now what I call this job I call it design. And so. Because everything we do in this job is related to designing a solution. Have a dialog with the customer and then selling them back to the solution. So we figure out what they need. We lead a design team. We design something, we give presentations, we respond to RFP is over here, and then we get involved in sales presentations for that is the Pre-sales Solutions architect. And guess what. What do you think as you promoted here? You being a person that does a whole bunch of proof of concepts, hands on, or you bringing in experts to do the proof of concept and you focusing on your sales skills and your business skills, and you triple yourselves, you triple your sales because you're paid in a sales position. The people that I've seen that have killed their careers in these pre-sales commissions are the people that forget that they're in a sales job, and then they focus on the ten. The tech is an asset, but your ad job in there sells. So for the majority, every job that we've talked about in architecture, we don't touch the technology yet. Now let's get into the technical solutions architect, which is that job that confuses everybody with other engineering, with other architectural things. What have we done in every architectural role so far? We've interfaced with the executive team, right. We've interfaced with key management stakeholders. We've determined the processes the way people should do their job, governance on various platforms, strategy now, 50% of all enterprise architect don't come from a tech background because it's very hard to find strategist. So. What does the architect do? The architect with the MBA that's been an enterprise architect that's never worked as an engineer in his life. The architects that have been architects for decades, that haven't touched the technology since they left engineering 20 years ago or never worked in engineering in the first place.

And the solutions architects that are paid by design, present and sell from their sales things. Anybody see a gap here? There's a gap. There's a gap in that level of tech experts that are there from a design perspective. So some companies also hold what they call technical architects or technical solutions architects. Unfortunately, they're more paid as engineers. I wish it wasn't the case. I love these folks. They're fantastic. But these folks are technical experts. And what we used to call them is design engineers. And these are engineers that will get into the deep nitty gritty. They will understand every protocol that they're going to be using, everything that protocols do, how those little protocols work, the idiosyncrasies of those things. And they are as good as you possibly can ever imagine. That's solving the issues. So if we go back to that diagram that I had drawn earlier, and it was very sloppy when I drew it, the key to see is, you know, as that enterprise architect, we are all over the place with the C-suite, the business stakeholders, the key technology leaders. Now we're working with a group of platform architects, and they have their solutions architects. We might still have those. We might have those technical architects or engineers at this level. And they are really good to have. So if you work at a big vendor like a Cisco or an IBM or anybody that's serious, they will also have technical solutions architects, because they're the people that still can talk to a customer, although they're not usually at the C-suite, but are super deep and super technical. It's a great role to kind of hybridize halfway between engineering and halfway between architecture. Now, that role engineering is a huge asset because there's a direct carry over from the technical architect to the engineer. There's little carryover from the engineer to the enterprise architect. Even though enterprise architect can do it, there's much more carryover from consulting to an enterprise architecture. And that platform architecture sort of in the middle. And that's where people get themselves confused. So. If you're really thinking about what the solutions architects are doing, and it's more of the solution architecture diagrams and the logical and physical designs and the integration diagrams and more cost estimates and migration plans, that's where they're focused. So what does that solutions Architect need to convey in an interview. And then I'll summarize the interviews for all of them differently. The solutions architect still needs to be able to understand that they can translate a business need to a technology solution that Solutions Architect needs to present very well on trade off reasoning. We're choosing the Palo Alto next generation firewall over the AWS WAF solution because of behavioral anomaly detection, which gives us X, Y, z benefit. Or we've chosen the AWS WAF over this one because it gives us a little more simplicity, a little more that whatever, whatever the choices. But it's the trade off reasoning for the solutions architect, especially the pre-sell solutions architect. Hiring on communication ability You can't sell, can't communicate. You also can't get the requirements that you need. For the solutions architect I want to see can you elicit or get the requirements? I'm going to see if you've got some kind of cost or financial awareness. I'm going to be concerned. Can you simplify complexity? And can you give a presentation to an executive team? If I'm a needed. All right. So let's go through those three things. On the difference of what I really want to focus on. What you want to convey in an interview to really summarize things. Now that you understand the various roles. So when we're dealing with that enterprise architect, we're going to be in that interview. zeroed in on your executive presence. The people see you do they feel you when they walk in the room for that enterprise architect, we're going to be focused on your ability to influence without direct authority for that enterprise architect. I'm going to be zoned in on your financial literacy, your ability of strategic thinking strategically, your ability to lead a transformation, your ability to align stakeholders, your ability to manage a portfolio.

That's what I need to see in that enterprise Architect interview, because that's the job. And I need to feel you have those capabilities to be able to do it. Now, when I get to that platform architect interview, I need to see some domain depth. Well, that enterprise architect may not dive deep into anything. My security architect better be able to dive deep in security. My eye into. I. Now, when I deal with a platform architect, I want to be able to balance risk with agility so you can stay. It's still business. I'm going to be concerned about their ability to create a governance and be leadership there. I'm going to be concerned about their executive communication. I'm going to be concerned in their cost optimization knowledge, their financial modeling, and I'm going to be able to think about their way. They think across the enterprise. Can they find the root of the problem? Can they understand the scope of the challenge? I'm going to be looking for their influence, skills. Now that solutions architecture again, I'm going to be focused more on do they actually have the skill? Do they have the business translation skills? technology knowledge? Do they have that trade off reasoning? Can they communicate well? Can they really get the requirements well? Can they analyze risks, for example, and figure out what they can do about it, or they cost to where can they simplify complexity. And it's and can I give an executive presentation or a presentation to multiple audiences. So it's the role that's different. And different is what determines you need to do. So if you're in the solutions architect role and you want to start moving up, start having more executive level conversations, start getting outside the workload, start moving into meetings. Develop your business acumen. Develop your executive presence. It will change the way we think. You you act in the next. And you'll be one step closer. Likewise, if you're going to a Solutions Architect interview and you try to act like an enterprise architect along the way, you will lack that technical depth and your answers will not be the same. I hope this gives some people some clarity on, you know why people are so confused by these roles? Why are people like me and David? We've been architect forever and we don't touch the technology. Well, most of the presales people do it. And then all of a sudden you run into someone and they say they do. And that's why because there's all architectural, different kinds of roles for all kinds of different architectural needs. And of course, there's just some jobs where nobody knows what to call them and they just make up a title, which I've also had in the past, but that's needed. Let's take some questions about these types of architectural roles. Right. So my favorite question, as always, came in earlier. So one asked, you can tell me, Mike, if you'd like to go first or if you'd like me to go first, he said, I think that there's confusion in the market about the responsibilities of each one of these architects. Same many positions for solutions, architect. But when you read the descriptions, there are more technical architects or cloud architects. I'm a pre-sales architect, and it's somehow difficult to find the right opportunities for the role. Let me start that. And then I want you to give your HR perspective. I'm going to give you the hiring manager perspective. So here's the problem. Me as a hiring manager, I'm now the VP of architecture. And I want to hire an architect. So what I do is I reach out to HR, I fill in my online requisition. Now someone in HR which may know what I should pay may know you know how, how much work you can output, you can get out of an employee and what you have to pay them is now I'm going to write a job description about a job they don't know about. Anybody see a problem with that? If you don't, I'm going to ask all of you to either write a job description for a cardiothoracic surgeon, a neurosurgeon, or an electrophysiologist cardiologist, or I promise you, it'll look just as bad as any job description you see in tech, because you'll be like HR writing about a job you don't know. So ultimately, what happens is I've never seen an accurate job description for an architect job in my entire life. What? I'm also going to tell you this I've never had more than 10% of the skills listed on any job description, and I've never been on an interview where I didn't get a job. So the key is you actually have to know what the job actually is. How bad is this problem and how long has this problem actually existed? What ultimately happens is I need to hire someone. HR writes a job description about a job. They have no idea what it is, and then what ultimately happens is we start getting people that were screened out by HR that we interview, and as soon as we interview these people, they have zero capability to do our job

because they have a fake resume, which they match to a fake job description. So after spending about eight weeks interviewing people and not having any person that actually is matched to the job, what we then do is we call our favorite recruiter, and then we pay 20% of that person's first year's salary as a company to that recruiter to then find me someone that I can call someone like Christina marino at it, Excel and say, I need a smart person, I need a fungible person, and I need someone that has serious knowledge of networking this, this and this. And that's all I want. And then Christina will find it and then we'll pay her for that. And honestly, that's how I've got most of my jobs. Because of that, I built an executive recruiter network. I have a resume on what I can do. It matches exactly what the employers are actually looking for, and I use recruiters. The other thing that I would say is we teach our students how to create content. If you have the right resume and LinkedIn profile and you start creating the right content, managers and recruiters are going to come to you. The key is, do you have that brand? Do you know how to build that brand? And that's really the thing that you, realistically speaking, need to do. And that's where and that's why I'll have it. But I've never worried about a job description in my entire life. I've never met anything on the job description, but I would recommend. And by recommend I mean and I would seriously master every required skill for that job so that when you go in that interview and guess what? I want you to have all the attributes that hiring managers want, every last one of them. When you finally get that interview and, I don't have a lot of time to talk about it, but I'll show you what they generally want. When someone interviews an architect, they're typically looking for this. for someone that can actually do the architect job. That's the key thing. That's about 50%. But they're going to be assessing your communication skills. attitude. They're going to assess your energy, your enthusiasm and your competitiveness because they want to see what you're going to do. In fact, I have a friend here. We trained them. He's not working as an enterprise architect in England on this webinar. And, you know, he came to me and he was configuring our servers. He was learning everything. I was a student. And, you know, he's been promoted many times because of that energy, enthusiasm and edge that we're really looking for. We're going to be looking at person's presence. Can we feel you? Well, we take you seriously at the C-suite level. Can you communicate in things that the C-suite cares about? We're going to be looking at your leadership skills. Can you lead that architecture team? We're going to be concerned whether we can trust you and your resume and what you can speak to. It will determine that we're going to be determined. We're going to be checking your emotional intelligence, and strategic nature. That's what we want. In fact, realistically speaking, that's pretty much the job description of almost every job out there is someone that can do the job. And then it's just the competency for those jobs. So we'll happily help you. But I wouldn't worry about an HR job description. All right. So I guess we'll move to the next Mike. Mike covered that one pretty good. Share. Okay, Mr. Gibbs, I don't know if, you talked about this because I had to step away for a little while, but, and if you have, I can go back and watch the tape. One of the things that I wanted to find out is if you could elaborate on the responsibilities and requirements for, I architect. Well. Yeah, absolutely. So an AI architect is going to be a platform architect like any of the other platform architects. So that means what you're really going to be doing is going to be determining what type of AI strategy will give that business a competitive advantage. So that means you're going to be looking, from an AI perspective. What are we trying to solve? Because if you don't know what we're trying to solve or we're trying to enhance revenue, or are we trying to enhance quality, or we're trying to tune customer service, so you have to figure out what business problem you're actually trying to solve in that role, and then you're going to be looking out there at all of your options and choices. So part of that role would be assessing does the organization have the data. They have part of that they need to do. Do they need to clean the data, collect the data prior to being able to do anything. Part of that would be evaluating their infrastructure. Do they have the network performance to do it? support managers evaluating their compute? Do they have it? Do they not have it? Okay, where should this workload run? Could it be something that runs on a CPU? Does it need to run on a GPU? Can it be run on an FPGA

or a piece of hardware like a TPU in the Google Data Center, when we might get it a little cheaper than if it needs to be on a GPU? For example, then we're going to be looking at. Okay, so in order to create strategy, what do we need to do? How are we going to train that model? What kind of data do we need to collect for that model. Should we use a pre-built model? Does it make sense to use the compute capacity of an Lstm or like a large language model? Should we create a small language model? How do we make it more accurate? That's the kind of thing that AI architect is going to be focusing on. How do we create that pure AI strategy for that business? Then where do we host that? I or what's the what would be the most efficient way to work? Should we build it? Should we buy it? Should we rent it should do. Is that workload going to cost less to run if we build it internally, but cheaper to train if we train the model on the cloud with somebody else's GPUs, that's what we're doing. It's that strategy. So great question, Sean. Okay. Thank you. And do you find that you've seen a lot of and this is probably for the ones that are out there actively, in the job market that define a lot of companies. More like doubling down on different roles, but they're combining it together. So say, for instance, like an engineer with, architectural well and calling it something, but in actuality, let me speak to that. My I've been talking with a lot of people over the past 3 or 4 months. So one of the things that I've been seeing and hearing and what I say, I've been talking with a lot of people talk about people like, that have been through the program, people that are out there that are that now hiring people, that have gone to the program. And so. There are literally hundreds of different variations of architect jobs. titles of architect adjacent. Are architects similar? I see they say, Ian, that over there he's like, yeah, yeah. They're, they're, they're literally at hundreds of, of titles and job descriptions. So aside from the fact of the job descriptions just being completely crazy that the titles are crazy. Yeah. And not crazy like, like not based in reality. They're based on that company's reality. that company's needs and that company's goals, that company's desires. So that's why there's literally hundreds of, of these, of these variations of, of this role. The architect role is not like a hotel general manager or a nurse practitioner. A nurse practitioner is that nurse practitioner is a nurse practitioner. Yeah. A hotel general manager is a hotel general manager. It's the same year it's time. Oh, and same role at the same time. Responsibility. But the architect role and architect adjacent roles like technical account managers, customer success managers, sound engineers. Like I'm just that data for that have the same scope that and probably have about 7,580% of that overlap and responsibilities. But then you go to this company and so about 20% overlap in the responsibilities. But in that company it's about 100% of exactly what you're doing over here. So. Short answer. There's a lot of chaos in the descriptions and the responsibilities and the roles. But there's also a lot of continuity between it. Yeah. And that continuity is what we focus on. Yeah. That overlap on the, the chaos or edge cases. And there's just literally so many edge cases. Yeah. There's entire companies that are an edge case. And so the short answer is yes. There's a lot of. There's companies out there that are going to try and hire people to do everything. There's companies that are out there that are going to hire people to do just this, and they're going to pay them $408,000 a year plus bonus to do this singular thing. And I use that exact number because there's an exact example of an exact student that is doing that right now and just getting paid exactly that to do only this and nothing else. And then there's so there's, there's so much and pay off might not be the right word, but there's so much noise and there's and so that's why it's, it's

there is no absolute like this is what a cloud architect does all the time, everywhere, in every situation. And I think that's what Mike that's what I'm glad. Mike. Really, when Mike came up with the idea that we do a session on this, I was like, great, let's talk about every. And then I started thinking, I'm like, well, we can't talk about every, you know, architect. But I'm glad that he did this. To talk about the differences between at least the top five types of right and that. And that's why I wanted to break down those solutions, architect roles, because that's where it usually gets confusing, because there's a couple of things that happen. One thing that actually happens is they want to pay an engineer more and they don't know what to do with it. And that actually happened to me early in my career. I had two offers. I had an opportunity to be a principal architected Comcast and another company that was based out of South Africa that was a big Cisco Gold partner, offered me an incredible amount of money to be a solutions architect. I got on in the first day and they said, just to let you know, I we only called you an architect so we could pay you in architects Pay, we want you to be an engineer. And I said it was very nice to meet you. I walked out the door and took the job at Comcast. It paid less, but I was totally happy to be there and I did that. So, you know, there was that. And but the key to remember is what you do and where you spend your time determines what you're actually doing in the role. I know principal engineers that spend time speaking to executives and evaluating trade offs all day and start building roadmaps. They're doing architecture. But the second you touch the technology, the real thing to remember as you're getting out of architecture. And here's the reason why. The second you're not learning what your business capabilities are and you're not mapping out business processes, and you're not getting stakeholder information, buy in and cultural support, everything you focused on became tech. And in that role, everything you focused on, becomes an engineering job. And unfortunately, what happens is those jobs also pay a lot less. They shouldn't because the people with that kind of technology are there. So there are some. But then at the same time, you have engineer jobs that never do engineering and get paid the amount of money as an architect and their title, this engineers and their job description looks really, really confusing. My and I'm just thinking are they looking given the economy that we're in and all of that stuff, are they looking for things for the price of no one. No, no. And I'll tell you what that well, that is a company specific thing. The company that is going to do that is always over 50 years. They're never it's not companies, they're not going to do that type of thing. And here's why. Yeah, here's why. I didn't mean to cut Chris off. But here's the reason. So you're now there as a cloud architect, and they're paying you $100 an hour. They're developers in India. Cost them $15 an hour. Which means if they ask you to do the work, they're going to need ten of you to do what you could have done individually by yourself while they spend $15 an hour to outsource that. And they got developers for $15 an hour that were so good, they would create things that would cost $200,000 a year in America. The second thing is they want you focused on architecture. Your manager knows that the second you start coding, you're no longer focused on strategy. That's why your managers typically are focused on managing people and not doing the people's job, unless it's a startup or something like that. And the opposite of everything that Mike just said is the company that is trying to make somebody do everything. Yeah. So they're there are but they're not going, yeah, they're not going to do it because of the economy now are they economy then. Are they. They're just that's just their operating model. They're always going to try and get blood out of a turnip or water from a stone or whatever. The, the saying is, yeah. Now you may, you may have a individual manager that individually decides, okay, I'm going to be cheap because things are going downward right now, but it's not going to be an entire role. They're just going to eliminate the role. Like they're not going to, it's just it's to complicated of a thing for, for companies to do that like that. And I also want you to think deep, deeper. The companies in the cloud, they're spending $40 million a year on the cloud

which is more efficient over your $250,000 pay package for you to find $1 million that they couldn't spend and save, or for you to do $50,000 of engineering work that year. To create that new competitive advantage that's worth millions or billions, or to be that engineering resource. So, you know, in any job, you can take it any direction you want. But the majority of these roles are more executive roles. I will also say that, your interview is going to tell you what the role actually is, not the job description. The way that they ask questions, respond to the answers that they that you give, and then the way that they answer the questions that you ask them. That's where you're going to find out what, what the role actually is. So, and to be in a position where sometimes they put these different responsibilities with the intention of maybe because they have two roles open up and they try to see where they went. Once they interview you, they can see which one of those roles you will be more qualified for. Now. No, that requires too much thought or a job description. And I'm not putting that much thought into a job description. Yeah. And that requires, that requires me to be a mastermind at the, at the job descriptions. And if these people were masterminds, the job descriptions and the hiring process, then the hiring process would be broken. Yeah. So now I like, I, I wish that they put that much thought into it because then it would be a better system out there. But no, they don't put that much thought into it. They can't. And a lot of it takes, you know, working with it. I can tell you, Arun, for example, was in canon, and he kept saying, Mike, we got all these techie job interviews and I don't know what's going on. And I said, can I fix your resume? And then he got three offers where they were all business executives. Another person on this call, I see him and I hear he was I would like to get to his question. You got a great question in the chat box. Okay. So. Well, that's, maybe I could. That's why I can't continue. Yeah. Well, and then maybe I'll ask him. I can remember in particular when he went on the interviews, he said, the recruiters are looking for a DevOps engineer. And I said, you're going to have to work with those recruiters until you have exactly what he wanted. And then, poof, he got a real architect job and did real, real well. So, okay, let's go to the next one. All right. So since I'm going in order, I will not go to him next because I'm trying to go in order and do things properly. So sorry. And I've also asked says I think there's a gap in the architectural operating model. And most companies it's a fair assumption. Maybe not the architectural operating model, but just the people model. Various architects jump on each other's toes and confuse their role and often end up in conflicts. How do we navigate office politics like, this is a job. Yeah, this is a job of emotional intelligence. controlling your emotions. This is a job of managing other's emotions. This is your job of, you know, facilitating meetings. of knowing how to navigate politics. Chris did a really good class on that. I think you're our student. I would watch that class. And for those of you that want to submit crazy job descriptions, please go on slack. I can't keep up with this. What does it mean? Not just. I mean, some of these job descriptions of work. They are a company. Otherwise they will will disappear. Because I do not get to chat after this. All right. Okay. So, next one. Yeah. Would you like to come off mute? There we are. Good to see you in. Likewise. So this way, before I continue. And would you be comfortable if we put you up on the screen? Yeah. Of course. All right. Let me find you here. Oh, there we go. All right. Hey, there he is. Right, right. Okay, well, let me just tell everybody who I am. I came across Mike in 2001. No, 2021, actually, I was going to say we're. We yet been on the sideline.

2021. And so that was before Covid. And, we have a very small team that Gary and, attended many of the training sessions. I think it was about five a week I was attending, you know, configuring servers, speaking to the newcomers, you know, given the motivation and, more importantly, gleaming the knowledge that Mike has. What Mike has, honestly, is a wealth of knowledge. And then Chris came on board and I remember Chris, I think he drove straight to my test meeting here and he said, you want to be part of this? Oh yeah. So when you say when you see something and you can, you know, like you just when you, when you see the, the value on something like that. Yeah. I literally just drove straight across state that. All right. Here's what you got. And Mike said what I said Mike what's going to happen when you get I can't remember what number I said. I said, what's going to happen when you get to like 100 people or 500 people? And he said, I'm not even going to get to 50 people as a majority of 50 people. So anyway, yeah. So yeah, I drove across the state. Yeah, yeah. You see, you see the beauty about Mike? Mike's the hands off is the architecture work. Chris is the governance and the cost optimization specialist. So he went hand in hand. So anyhow, after four months on the course training program, Mike said it's you're almost ready now to start sending out your resume, which, you know, data science, tourism, ISO and I only had three interviews, but the first two, they wanted to they didn't recognize me as an architect. They wanted to do was Mike Lee to where do you want DevOps and ask me about clipart? I actually control the meeting management. Stop. I'm an architect, so I don't want to waste your time on one time. So I think you need to, you know, go back to the HR and start again. The following day, I then had a call from, a recruiter who was actually looking for architects. But I quizzed the recruiter first. Okay, so what will I be doing? Blah blah blah. I said, okay, now you have my permission to send my resume. So my resume. I then went forward to a global consultancy. They interviewed me, and it was really I put it down to my emotional intelligence. You know, when they ask your question, give a pause, give an in-depth answer. And the recruiter tried to prepare me for the meeting and mentioned that the meeting would last about 45 minutes, 20 minutes in my case, because if it was answered and clarified and then the settle, somebody will get back to you within two weeks. That two weeks turned out to be two days. And I was speaking with the principal architects. That meeting lasted half an hour. We sat and then the same again. Somebody will get back to you another two weeks. But 24 hours afterwards they got back to me with another great. I went into the company and after six months, still doing the program with Mike Rand, I realized that actually in the workplace environment, there was a lack of knowledge, extreme lack of knowledge, the governance is just awful. And for me, it was like a needle in a haystack. So once you actually position yourself in an organization, you take on a project. And being an architect is not just all technical, because what might lead to anyone, it's developing relationships with the stakeholders. And I came across some, other architects who were saying, well, how come you've extracted that knowledge from the stakeholder and I've been on this account for three years, and I don't know about the applications of it. You know, you don't. I might get, you know, and so everything what Mike's taught me, honestly, I've just applied it and applied it to the point where after two and a half years, I became lead architect on certain accounts. And, you know, there was people who'd been there ten years who they wanted to put the knife in my back. But, you just get on with it. Really. And when they see that you're knowledgeable and then you help them along as well. It's a holistic approach because there's more clarity. You need developers, you need your project managers, you need your, security people, people as well. You know, you see how you communicate with people overall. And then when you're called upon to do a presentation, you have to deliver that presentation. So awesome that

you've answered the questions before they ask the questions. So you might be asking, why am I here? I'm here now because I'm going to go back to my master. It's because I want to go on to the, platform side, because I've already been told that there's no more room for me in the enterprise architecture unless I become a practice. Practice manager, where I would then have to step back to put people in positions. Give them a French hell. No, that's not me. I'm not doing that. And now the companies want to hear 1 billion pound project with Google, and they're looking to create a sovereign state. So that's an opening I recognize. So I'm calling on my architecture family to say, yeah, help me said, yeah. and you know, it's interesting because usually when you reach the enterprise architect, you also get either the offer or like you have either a chief architect or like that managing director, or where now all of a sudden you're managing a group of people and you're not that architect anymore. Okay. So in that particular case, because you want to stay close to it, and I did something similar because I loved it. Pick a domain, pick a platform. So she's into that. And by platform I don't mean a vendor. I mean, either AI or security. And really invest in that. So either be the AI strategist. And that's a great place to have. You have a see HQ I can't wait. We can't see it. It's so sorry. It's the vertex AI. I'm looking at the global vertex AI. But yeah. So I mean I in general. But you have a okay don't you. Oh I haven't used that funnily. Yeah there are but I'm thinking like but yeah so is you're interested in security. Is that like is that something that interests you. Yeah. But it's the, it's the AI which I've got to move on to. Okay. But and the reason I was going to say is when I say platform architect, I think security architect, I think I architect, I think network architect, I think cloud, generally speaking, I'm most excited about the security platform architect role for most people. And here's the reason no one has any idea how to secure anything. And the gaping shortage is so bad that for me personally, I'm a supply and demand curve person. I always look at the supply and demand. Now with your level of business knowledge. I could be pretty cool for you. And here's the reason why. Because you already have that architect, that chief architect, all that stuff under your belt. So if you took a platform architect job, like a security architect or an AI architect, you'd come in more of the way David Linthicum or I would be when David Lythgoe was Deloitte's chief cloud strategist. You know, he's still focused on all cloud providers, not a single cloud provider focused one eye on the cloud I like here. So it was that big thing. So what I would do is I would take an enterprise architect focus two year platform architect job and then I would pick one. Now security for you. Just to be fair, that background you have that would put you at a level that, you'd already be walking into the top 1 or 2%. And I'm not from all that other security background that you have, and you understand every level of operational security already. And then when you'd map that out to the cybersecurity, that would probably be the biggest place where there's the easiest hit for you. But you're smart and I've seen you and I've watched how fast you learn. And, you know, my philosophy is we can learn anything we want as long as it's exciting and interesting to me. So I would be a really good role as well for you. Yeah. Thank you for that. Michael may not other speaking to a colleague and he mentioned there may be a gap in the market with AI and security. Yep. There is. Yep. So that's there is that's your that for you. Yeah. Now of course remember everybody you all know this about us. If you don't now you do. We are very unique feedback to each person. We're not going to give one size fits all. But this is our feedback to Ian. That is Ian's opportunity. Yeah that that AI security that's your opportunity. Now don't get too blinded by that specific specificity of it. If something in the eye pops that up and take that opportunity something and security pops up in an interest, you take that opportunity, make that pivot that you, you want to make. But those that's your that's your, your direction.

Absolutely. Yeah. That's my seal team. Yeah. Yes. Exactly. That's your being and that's your being in sales. That's so, so we've got we got two more questions. I want to make sure we get to Ian. Did you have anything else that you wanted to I just want to say thank you guys. And for the people who, whether you're in the program or not, honestly, it's like a family. I mean, I haven't spoken to Mike for about good nine months now. Michael haven't spoken to him. Well, I'm always checking in now and again. And you still welcome. And I just got to say, their experience. share this testimony because before I had my first, job, I've come out of a terrible marriage. I was heavily in debt. I was living in different accommodations. And, because of Mike and Chris, my life changed around change. In eight months. The house, the car, the money, the holidays. But the mindset. Mike believed in me because before he accepted me, he said, I want you to make a video of yourself. Honestly, you guys, you're in a gold mine. You've just got to apply what you've been taught and believe it. You can spend your time watching soccer, football, whatever it is, but that won't change your life. These guys do change the lives of people, and for me, they'll get an Oscar anytime. Thanks again. Ian, thank you, thank you. That's me. All right. Okay. So let's, All right, we got two more. I know, we gotta we gotta heart stop at four. I'm going to try and squeeze these in. Yeah. Where did we go? Where do we get. Where do we go? Okay. So Melissa asks, what role that is focused on the a I architect, a on the architecture of the HR tech stack and systems to be considered a platform architect, where the domain is HR and people systems. Is that a thing? So the reality is there's all kinds of specialty solutions, architects that are out there. And if you're really focused on just a specific type of software, that's typically solutions architecture. What kind of solutions could we create for an HR team is typically solutions architecture. And guess what? There are solutions architects that work for electronic health vendors chip vendors, solutions architects that work for server vendors, and pretty much anything out there. So yeah, there are solutions, architect jobs like that. They may not be called solutions architect jobs. And that's the thing with architecture jobs. They could be called consultants, strategies. They could be called anything. I even had an offer for a Customer success director that was there for a chief health care enterprise architecture. I don't know how they thought of it. All right. Okay. And so our last one, from Troy. And so, so how do I recalibrate to focus on business driven solution architect and not fall into the engineering rabbit hole? I can relate to my summary because I've been bit by it. So the key is to learn the business. I was in that rabbit hole and that's what I do it I have I had a manager many, many years ago. It was 2003 and he pulled me in and he said, first year, you're not like the rest of my team. I was like, okay, Greg, this is going to start off bad. And he said, do you want to know the difference between the super high paid executive architects and where you're at now? And I said, tell me. And he said, Mike, it's your business knowledge. He said, you're focused on the tech. If you learn more business, you'll be there. Now. That's why I created this program where I teach these kind of businesses. But I didn't have that. So I went and got an MBA. But that really gave me that kind of business acumen. And I also had the opportunity, even though I was an architect, to work with some really good enterprise architect across Cisco that could sort of mentor me and to show me what they were doing. I actually got a job as a business architect at Cisco after my MBA, after the executive presence training, and that taught me a lot more. And then from there I was able to apply it and then instantly it was there. We would be honored to train you if that's something you're interested in. If you don't want to train with us, I would say get some business school training. It really made a big difference because once you start to learn business and you start understanding how businesses are operate and how businesses are, are architected

you start knowing where you're levers are to change the business. And then when you combine that kind of deep tech knowledge and be able to solve problems with it, oh, that's a magical place to be in. And I really would love to see that for you. All right. So that is it. We actually finished on time, Mike. So I guess I will let you wrap it up. And for the day. So thank you all for coming, to our, you know, discussion on platform architects, enterprise architects Solutions architects, where we broke it down into all of them because there's just so much confusion on the role. I mean, so you if somebody applies to be an enterprise architect and they act like a solutions architect, they won't be hired. Likewise, if you want that pre-sales solutions architect job and I have friends that are enterprise architects that want them, they can't act like an enterprise architect on a solutions architect job because it's a different job. So I hope this was helpful to everyone. I really, was so thrilled to see everyone and, thank you all. And I see so many of you soon. I thank you everybody. Thank you. Thanks, Bob. Thanks, Chris. Thanks.