Re:Role | The Architect And The Toolbox

  |  Compiler Team  
Développement professionnel

Compiler • • The Architect And The Toolbox | Compiler: Re:Role

The Architect And The Toolbox | Compiler: Re:Role

About the episode

There are many kinds of architects in the tech industry. While they don’t draw building schematics, they do put together blueprints for programs, systems, networks. What does it take to effectively build solutions to technical problems? And how do you learn those skills?

Grabbing tools out of a box and assembling them into a working whole is the starting point. Architects consider a customer’s needs and how those are affected by the particular combinations. And as it turns out, keeping an eye on available tools has some pivotal advantages.

The company, its business activities and its employees depicted in this podcast are fictional and are not intended to represent or depict any current or former business organization or any individuals living or dead. Any resemblance to any individual or organization is purely coincidental.

Compiler team Red Hat original show

S'abonner

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transcription

Welcome back to Compiler Re:Role. Let's see how our start-up is doing, now that our founder has partnered with the CTO, to get the gears going on developing a financial technology app. They're building an application that will help people transfer money much more quickly than what current banks and payment institutions offer. The CTO and their small team of developers are hacking away at the application, but the developers keep coming back to the CTO with questions about tool choices for parts of the stack they're unfamiliar with. Which database should we use? Which front end framework would provide the best user experience? How are we setting up the operating system? Our CTO has hit the limit of their expertise. They don't know whether the choices they're making are the right ones. In their next check-in with the CEO, our CTO decides it's time to do something about it. The CEO is a little confused: "Aren't you the tech expert?" The CTO explains that they can't keep up with such a broad set of tools and have the depth of knowledge needed to lead development of the application. For someone with a broader view who can put the best stack together, they're going to need to hire an architect. But what does an architect bring that's different from the team of developers? And how do they affect the development of the end product? This is Compiler, an original podcast from Red Hat. I'm Kim Huang. I'm Angela Andrews. I'm Johan Philippine. We're following a fictional start-up as they grow their business. Any resemblance to real companies is purely coincidental and unintentional. As it grows, our start-up realizes it needs to fill new roles. Today's episode: The Architect. If you'd like to listen from the start of the series, check out our episode on the CTO. Producer Johan Philippine is here to get us started. Johan, walk me through this a little bit. Why does the CTO say that they need an architect? Well, our CEO is a little confused, right? I mean, didn't they hire the CTO to handle the technical direction of the company? What does an architect do that the CTO can't handle? I spoke to Redbeard. Tell me more about this Redbeard. Well, he's grown out what he calls a Unix beard. It's really long, and it's become his identifier in the open source community. Yeah, what did he have to say, Johan? He's currently a strategist for the office of the CTO, here at Red Hat, but he's previously been an architect in several different companies. You can be a software architect, network architect, solutions architect, and the vast majority of roles that have an architect title attached to it inside of Red Hat, are really focused on the experience totally of an end user and less, per se, on the design of the software itself. What that means, is that there are definitely lots of different types of opportunities to engage in the practice of architecture around software. He continued to explain that the essentials across these different types of architect roles are, 1. knowing the tools and components available to you, and 2. knowing how to put them together in the most effective way to solve a problem. Kind of like having a box of Legos and imagining the different ways of putting them together to build a specific model. That's a good analogy. Now the thing about the box of Legos is a lot of the times you've got this big box with a lot of tiny pieces. It's not an easy job to do at all, let alone to do it well. Before rejoining Red Hat, he was the chief architect at a start-up. I was involved in a lot of the high level design of various tools. We were building much like, we would have an architect design a building. They're going to be involved in both aesthetic decisions as well as engineering decisions and kind of making sure that everything has a high degree of polish at the end. So, I was the chief user. There's actually some folks remember that after one of the early releases of Tectonic, I just smashed a keyboard, because it was so infuriating to install. And if I feel like an idiot, users of that piece of software are certainly not going to feel like at least more empowered. It's one thing to put something together that technically works, but as everyone knows and as everyone has encountered, there are instances where technically functional software is a nightmare to install, to use, to keep it running. It's within an architect's power to make sure that the user's experience is better than the bare minimum. Now, the first thing to do is figure out exactly what the user needs from their software. From there, the architect and the development team can start to build something that will help them solve their problems. Makes sense. That requires some pretty broad knowledge of the tools available. Something that we learned from last episode that a CTO may not have the time to familiarize themselves with or to keep up with, especially when software solutions need to change depending on the customer. Yeah, that's not an easy feat, especially with the sheer number of tools out there to try to build a solution that kind of puts it together with all the stuff that's out there. I mean, I'm sure this is not an easy role for someone in a start-up because you are the one that's making all the decisions. Exactly. I think that the last episode where we talked about the CTO, we made it very clear that there is a pressure for them to know everything about everything. Exactly. Exactly. But it's impossible, right? You can't have one person be the entire knowledge base of a company. That knowledge has to be distributed in some way. Right. Think about the architect. The pressure of having to be the person that has to know a little bit more about all the things. Mm-hmm. You know what I mean? Yeah. That is just in some context, it's just not possible, just like it's not possible for the CTO. Mm-hmm. What does an architect do in this respect? How do you figure this out? Right I asked Redbeard how he likes to learn and keep up to date, and he told me it involves play. Having an environment available where he can experiment and try things out, where if something goes wrong, it's no big deal to clean the slate and start over again. But beyond that, he explained to me how that allows him to take his job farther. You can build a system that just checks the check boxes, but that's different from thinking about more than just the software. It's the how the software affects people and the systems around people, the other software systems in some cases, that makes the distinction between just someone who is building software and somebody who is engaged in getting folks to a different place, getting folks to a better place. He's really making... drawing the line between the folks who are building the software. They have their task and they have their marching orders, and the architect is trying to take that tool and empower users. 08:13 — Johan Philippine Mm-hmm. He or she is trying to make sure that this software, yes, does what it's expected, but the folks who are using this software are really understanding the tool and they're getting the most out of the tool and they're empowered to use the tool. Just because you build software doesn't mean folks are going to have a good experience with it. Right. We can just liken back to his keyboard fiasco. There has to be this bridge, and it seems as if he's saying that architects take it that step further. They are that bridge. Is that what I'm hearing? That's what I'm hearing. Yeah. Okay. Yeah. I'm not sure if I understand the distinction 100%, but I'm ready to hear more. Yes. Well, I asked him what it takes to take people to that better place, and his answer had a lot to do with, surprise, curiosity. If you have very linear thinking and are not willing to just pull on the threads to see where they go and follow them, you don't really see what's good and just as importantly, what's not good. When I was talking about that moment with Tectonic earlier, where I smashed a keyboard, that was actually a great moment, because I was able to very, very quickly identify a bunch of things not to do. I was able to say, "Hey, when you develop something, or when you made the workflow do X and Y and Z, this was the effect on me as a user. This is what it made me feel. This is how it stymied the outcome I was trying to get to. This is why it was confusing." It's learning to understand what it is about the software that is causing those sorts of reactions that really leads to different outcomes than just the average individual doing it. Let's talk about this for a second. All right. Mm-hmm. He's really talking about you having software and the usability of it. What does that workflow do for me exactly? Mm-hmm. As a software developer, you're probably not 100% concerned. That's a part of your concern, but you are trying to write the software. There have to be people that are around you, that's the voice of the user. They have to be QC-ing this software and reading and writing the documentation that makes it much more approachable. We've all had the experience where we're using and installing new software and we are ready to scream. We've all had that experience. Yes. Again, in his respect, he's saying that we need to make sure that people don't have that type of experience. Is that just the architect's job? It sounds like there are multiple roles involved with this. What do you think? Yeah. Of course. I think so. For me, after hearing Redbeard talk about his experiences, I feel like the job of an architect is to bring all of those different people who are more concerned with whether or not it's up, whether or not it's maintained, whether or not the code is good. An architect's job is to have a holistic view and bring everyone to that level of shared understanding about what happens when a user runs into a problem. Or alternatively, what happens when they have a good experience. I feel like that's part of their job. Johan, what do you think? Let's do a little recap of what Redbeard has told us so far. Okay. There are many different kinds of architects, but they have essentially the same function. Right? Okay. They talk to customers, figure out what they need, and put together a solution from an array of available tools. That includes keeping in mind things like the potential downsides of certain combinations of components, as well as the upsides. Right? Ah, okay. That's what, when we think the word architect in terms of building, and we're thinking of putting the design of something together so that they can then be built. Right. Yeah. They're building a solution. Exactly. We say solution architect, and that term can be so broad, but in this respect, we're talking about building a complete solution. Exactly. Made of disparate parts and components and services and tools, and being able to deliver that product to our customers in a very clear and usable fashion. Now, this helps me understand a little bit about what an architect does. It's not just the set of tools or the types of technology that are involved in putting together a solution, it's also... It's not just what works, but also what doesn't work. Exactly. They are looking at that from a holistic point of view. Exactly. Okay, I get it now. As a solution architect, we have to do a lot of listening. Okay. We have to listen to what our end users are trying to accomplish. Sometimes there is not a perfect tool for a job. We have to make sure that we find something that meets them where they are, and it could be multiple tools. Building a fully fleshed-out solution starts with listening, as are most things in life, as we probably already know. But definitely being a solution architect, listening and doing the discovery and understanding the why, is a huge part of an architect's job. Mm-hmm. It seems to me like being able to do that requires a lot of knowledge. Right? Mm-hmm. Sometimes you can get that by playing around with software for a while. Yeah. Sometimes it comes with a career's worth of experience. Our next guest had some unexpectedly useful experience to lean back on. Now we know what an architect does, what they do, who they are. Mm-hmm. What else do you have for us? Well, I've got a little bit more about how an architect fits in an overall organization, especially in a start-up. We spoke to Bob Kozdemba. He's a principal solutions architect here at Red Hat, but he was recently part of a small start-up. Now, before we get to that, we're going to give a little background. He started his career testing circuit boards, and along the way, he did some work on GPUs, on hardware for graphical processing units. Now, many years later, he joined a start-up in the UK, specializing in machine learning. His experience with the relevant hardware was a really big help. When I joined, they were still in the series A funding in early stages, and primarily they were just moving from, now I have a minimum viable product, which is a new acronym that I learned. They had that viable product and they have a few interested customers. Now, the next phase of convincing your investors to invest more, is to prove that you can sell that product. The company was in the process of really hiring and developing their sales organization, both in Europe and the US. What was exciting about that, as I said, "Well, I'm getting in here on the ground level, this is a great opportunity." He's highlighting something here that I thought was important, is that in a start-up, you're not just convincing potential customers or future employees that you're onto something. Right? That's right. You have to convince the investors, too. Indeed. The architects can play a really big role in solidifying that vision, especially early on. In one aspect, you're highly visible. Anything you do, everyone knows. There's a little bit of risk in that. However, on the opposite end, is if you make a difference, then everyone knows about it, so you can make easily make an impact. It just occurred to me, during that meeting, I said, "Wow, every product marketing is here, and product management is here, and sales is here, and the CEO is here, the leadership is here. I think I can really get things done here." That's what I found was really a positive about working for a start-up, is that not only was this organization very transparent, there were very few obstacles in the way to get answers and to get your work done. That's something that I hear a lot from people who work in start-ups, is that while you are expected to, and then here's that term, "Wear many hats" in an organization, you will also have a lot of opportunities to really stand out, just because of all of the eyes that are on what you're working on. Whatever you're doing has a direct effect on the bottom line. It has a direct effect on what the company's vision is, and you get a lot of attention that way. It's kind of one of the selling points for working for a start-up. That's how I understand it. Mm-hmm. Yeah, there is a lot of transparency, because there's not a lot of hierarchy to wade yourself through. Right. It doesn't sound outside of the realm of possibility that everyone is at the table. Everyone has a seat at the table and they have a voice, because you are helping the company be successful. There aren't those roadblocks that you have to run into, or could run into in a larger company. Right. Yes, you have to work on, "We're trying to make this successful and we're trying to impress our investors, but we have the advantage here, because we are all right here, vision locked and loaded, and we are working on this together." I've never worked for a start-up and that I always found that kind of attractive. Yep. Because you don't have the hierarchy that a lot of companies do. If you have a question to ask of product marketing, or engineering, or the business unit, whatever, you're probably down the hall or just a chat away, because it's only a few of you and you really do have to work together. Yeah. The second thing I wanted to touch on, is the very last bit that Bob was talking about, where not only is the organization transparent, but there are very few obstacles in the way of getting your answers and getting the work done right. You're making sure that the solutions you're putting together are the right fit for the customer. In a team with limited resources, that means making sure that your software is a good fit for your potential customers. Now, what that means in a start-up, is that you're probably going to be turning away customers whose software that's not going to be a good fit for. We know that this customer has money, but really, this is the right solution for this customer. That's where the role of the solutions architect comes into play, is how can I understand what the customer is trying to accomplish? What are their challenges? Then given what I know about our products, how can I map our products into solving their problems? That's really the role of a solutions architect. He nailed it. That's literally what our job is. As a solution architect, we have to qualify their use case, because there's not every use case out there that will fit every one of our products. As a solution architect, we have to understand that, because there are times where our product isn't the best solution. We have to be honest enough to say that we're not in the business of selling software just to sell software. That's not how this works. Our role is to be an advocate for our customers. Right?We are supposed to understand their challenges and know enough about our products to see where we fit into their use case. But we also have to again, advocate for our customers, and say, "You know what? This might not be the tool that you're looking for. Let's work together. Let's keep having these conversations." It's not a small feat to be able to say, "This software doesn't work for you." You have to say it with your chest and mean it, because your customer is listening to you and they respect your opinions about these things. I'm so glad he said that, because that's what we do. It's nice to hear someone put it in such eloquent words, because people ask you all the time, "What's a solution architect do?" I'm like, "Whatever they tell us to do." It's a little bit more nuanced than that. Right. Something that keeps coming back to me, something you said before, Johan. Mm-hmm. It also means turning away customers, the possibility of turning away customers. In what scenario would it be advantageous for a start-up, especially if one's looking for funding, or they're looking for investors, to turn away potential customers? You want to just satisfy everyone's needs, just to grow your business? Well, I mean, if you're selling hammers and some of the customers have nails that they need to put in the wall, then yeah. You want to get as many of those customers as you can. But, if they've got a whole bunch of screws, you try to sell them a hammer and they're going to have a bad time with your software. The other thing that Bob was telling me, is that because the start-ups have really limited resources, they have to make every deal really count. If they make some of these deals that end up not working out, that's a potential deal that they could have had a better time with and that their customer could have had a better time with, that they didn't have the resources to commit to. That's not just a net loss of an account, it's a net loss of two accounts or even more. Right? Depending, because you're trying to make it work for that other customer and in the end, you're just losing a lot of time and a lot of effort and energy trying to make it work for that one, where it's just not going to be a good solution for them. That's just a bad experience for everyone. Right. It seems like the word of the day here is adaptability. Mm-hmm. Now, sometimes the role ends up being about what you could deliver with the tools that have already been put together, but you aren't doing that yet. What we're talking about here is the infamous pivot. Our next guest had a front row seat to a start-up in the midst of a big pivot. Johan. Mm-hmm. Let's find out more about this pivot. Well, we spoke to Sam Richman. He is a senior solutions architect here at Red Hat, and he was part of a start-up that decided they could better use their network analysis tools in the guise of network security. There was a lot of network data that they were collecting, but not using and just tossing that into the bit bucket. But how did they figure out that they were throwing out valuable information? Do tell. You know what's funny, is I've been a sales engineer or a solution architect in probably four or five places. It varies a little, but the one consistent theme around it is understanding and positioning technology as it solves customer problems. While Sam joined, while the pivot was already planned and a little bit underway, he still had a lot of work to do as an architect to put it all together for potential customers. Now, he attributes success in an architect role on two things. To get the opportunity to work with a lot of different teams and interact with them and kind of connect the dots, I think that helps me here, because that is something that's pretty valuable. We sell literally everything. Being able to have those good effective conversations with other teams and kind of build a solution that may kind of overlap and run over a bunch of different focus areas is helpful here. I think that helped me do that. The other aspect: talking to the problem at that other role, I had to start a sort of sell to and position to the "why" of the product. I love how he used the word, "We get an opportunity." Mm-hmm. We don't have to do it. We are lucky enough to have these very unique experiences, when we're dealing with our customers. I really wanted to mention that, because it's really all an opportunity. How you look at it, how your perspective is in each and every interaction really shows that you're having this growth mindset and you're willing to work inside of a pivot, because it's all about growth and an opportunity. I thought that was a really nice turn to phrase. Mm-hmm. Let's see if I'm understanding this correctly. For an architect, sometimes identifying challenges, or maybe areas where there's not a lot of attention being paid, maybe there's a misconception, or a disconnect with the customer about what is really useful and what is not really useful. Here we have a situation where an architect is the kind of person that comes in and identifies that as an opportunity, rather than as a kind of missed chance or a mistake. I think what happened here, is that they had this really powerful tool that was effective at this network analysis. Right. They looked at it and said, "Huh, this tool is also very useful for something that is more in the security realm," where you're able to not only analyze what's going on the network, but there's all this traffic data, there's all this other data that you could use to figure out if information is moving around in a way that it shouldn't be, right? It takes knowledge of not only these tools and what it is that you're gathering, but the context in which you put that information and the context in which you put that tool and in what market you put it in and to figure out, "How can this be useful to my customer," not just in the problems that we were initially talking about, but with these other problems as well that they might not even be aware of. I imagine that being able to do that requires, as they say, a certain set of skills. Getting a good perspective on the industry, and maybe not moving around as much as perhaps I did, but I think by doing that, I learned a lot about a lot. That helped me get to this kind of role, because it is that kind of broad visibility and perspective that helps you get to be an architect position. I think as much of that as someone can do, whether it's staying in one company and attending conferences, or talking to everyone they can possibly get their hands on and really learning about the problem set in the industry. However you can get your hands on that information, that broad deep information can help you get to architect. He nailed it! Lots of nails going around let's just smash keyboards, hammers, nails, tools. Yeah. He's so correct. He got his broad visibility and perspective by jumping around to different companies. That is definitely one way to do it, because it takes you outside of your little sphere. But there are other ways. Going to conferences, going to meetups, watching seminars and talking to people and learning the thing. This is definitely how we stay abreast. This is how we stay informed. The more information that you have, the much more valuable you are to your customers, because they get access to all of that goodness. I think having that perspective on the industry as a whole, and however you get it, from jobs, or roles, or reading, or conferences, however you get that, that just helps you do your job that much better. Mm-hmm. And again, CTOs can do that job, but they may not have the capacity or the bandwidth to do all of that. They need help. That comes in the form of an architect. Mm-hmm. Now, moving around exposes you to that breadth of information, but there's also some sales skills to consider. Right? Uh-huh. I've been repeating this phrase over a few years and I'll say it and I'll kind of finish on that: If you want to learn to be a sales engineer, go work for a small company that sells a product that no one knows they need. That was well refined over the years, but it speaks a lot, because it trains you to really talk about the technology, to understand it, to position it to a why, because customers don't know who you are. You don't have the laurels to lean on. No one should really lean on laurels, but at least, "Hey, I'm Microsoft, you know me. You know what I sell. I'm badass," or "I'm Red Hat. We're out in the industry. You know who we are." You don't have that crutch to lean on. You're going in there, you're exposed. You kind of have to build both your brand and your company's brand. I think for me, that was a really both humbling and educating experience. What a gem. Yeah. That's a lot stuff to unpack there. Oh, yeah. What a gem. First, he starts off by saying, "Go work for someone small work for a start-up," MM-hmm. Mm-hmm. Because you have to hustle. Yeah. That's where you're going to learn your sales chops and your hustle chops, because no one knows who you are. You cannot use the name recognition, the name cred and say, "Oh, I'm X, Y, Z. You know me." You really have to know the technology inside and out. You have to know how to sell. You have to know how to hustle. I think that is such an interesting perspective. I've always been scared to work at start-ups, because it's like, you don't want to... What if it fails? You have a family, you're really thinking about these things. But the way that this spin on it, if you've never been in sales before and having to really sell, sell yourself, sell the product, man, that's a clinic. That is definitely a clinic on how to get good at selling your products and services. When I hear the word sales, sales comes off as a four-letter word and I- Cringe. Yeah. Yes. I feel like we need to unpack that a little bit. How is it that you can make your career path, whether it takes you into the realm of architect, or somewhere along those lines, how can we make that agree or align with a sales mindset? You're right. When people hear or see, "Oh, a salesperson," they automatically put their defenses up, because you're trying to make me part with my money. Right? Of course. That's that feeling that we have, but I think what architects do is a little bit different. Okay. Because usually how we get to a conversation, is because you said you had a need for something. It's almost... you kind of came to us and what we're going to do here is try to talk to you to find out and listen, because this is, listening is a huge part of the job. "What exactly do you need? What are you trying to accomplish? What is your end goal?" When you're in a listening mode and you're not necessarily selling anything, you're letting the customer drive the conversation, you're asking those leading questions, you're trying to find out more, but it feels more of like a conversation as opposed to a transaction. You'd be surprised. Even customers are more comfortable talking to architects than they are to sales reps, because architects aren't necessarily there to sell. I mean, let's be clear, we're selling, that's exactly what we're doing, but we're doing so much more. We're counseling. We're listening. We're advising. Our role is so much bigger, and if our jobs are done effectively, they're going to buy the product. Why? Because you've removed all doubt. You've made them comfortable, you've explained away a lot of their concerns, you've answered their questions, you've enabled them. They feel empowered to now move forward and say, "Yeah, I'm going to go with this product." It's almost as if I'm coming to your aid. "What can I do to help you?" More of that and less of, "How much you got to spend". Now, one of the big things that we spoke about over the course of this episode is figuring out the progression of what does the customer need, and how does the software solution help them accomplish or solve that problem? Right? Right. Now, the architects and the CTO and developers, they do this from the software side of things. That's right. Next episode, we're going to talk to the person who helps do it from more of the design and the visual and the flow of things. Right? Okay. We're going to talk to the UX and UI designers out there. Oh, so, so important. They're really unsung heroes. They really are. I'm looking forward to it. Well, let's start singing. Well, this was the episode on the architect in the Re:Role series. We want to hear about what does an architect look like to you. We really want to hear more about what you think about this role. Tweet us @RedHat. You can find us there. Use the hashtag #CompilerPodcast. We would love to hear about all the different architect roles, and we want to hear if you have any questions about the architect role. That's right. I get that a lot. I would love to hear those as well. Hit us up. That does it for this episode of Compiler Re:Role. Today's episode was produced by Johan Philippine, Caroline Creaghead, and Kim Huang. Victoria Lawton never smashes keyboards. She is a picture of grace and poise, always. Always. Our audio engineer is Christian Prohom. Special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta. Thank you to our guests; Redbeard, Sam Richman, and Bob Kozdemba. Our audio team includes Leigh Day, Stephanie Wonderlick, Mike Esser, Brent Simoneaux, Nick Burns, Aaron Williamson, Karen King, Jared Oats, Rachel Ertel, Devin Pope, Matthias Fondus, Mike Compton, Ocean Matthews, and Alex Traboulsi. If you liked today's episode, please follow the show, rate the show, leave a review, share it with someone you know, because it really helps us out. It sure does. Thank you so much, everybody. We'll see you next time.

More about professional development

Keeping up with changes in technology requires training and and engagement with learning opportunities—either in a traditional setting, or individually.

Article de blog

Friday Five — August 15, 2025 | Red Hat

15 août 2025  |  Red Hat Corporate Communications

...

Article de blog

Developing a standard AI OS: Unlocking production-grade AI at enterprise scale

14 août 2025  |  Brian Stevens

...

AI inference

About the show

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.