Navigating Messy Enterprises - Insights from Experienced Architects

s1e30 Navigating Messy Enterprises   Insights from Experienced Architects 

This episode of The Wired Garage with Pops is a roundtable with three “recovering” enterprise architects discussing what enterprise architecture really looks like in practice over a career. They frame EA less as a job title and more as a mindset that bridges business strategy with the messy reality of technology, legacy systems, and organizational behavior. The conversation covers recognizing “messy” enterprises, saying no (or “not yet”) to cool tech like AI and new platforms, governance and decision frameworks, empathy and frontline experience, and how their beliefs and communication styles have evolved.

• EA is a mindset, not a title. You don’t stop being an architect when the job title changes; it’s a way of thinking that follows you into leadership, platform ownership, and solution delivery. Architecture is as much about people, context, timing, and decisions as it is about diagrams and standards.
• What makes an enterprise “messy”? “Messy” isn’t just lots of tech; it’s unclear decision-making, weak governance, overlapping tools, and skills spread too thin across too many platforms. Mergers, half-in/half-out cloud moves, redundant monitoring tools, and fragmented information repositories all contribute to mess over time, often from good intentions. A clean decision structure and a clear plan can coexist with temporary mess; the real danger is unmanaged complexity and poor visibility, especially for security.
• Role of the architect: giraffe, not wizard. A good architect is like a giraffe on safari: they see farther, spot danger early, and buy the organization time to choose options instead of reacting in panic. The value is in anticipating issues, proposing options (hybrid models, phased approaches), and structuring decisions so mess is prevented or at least contained.
• Saying “no” (or “how”) to cool tech. Often the right call is to say “not yet” to AI, new SaaS, or hot platforms when knowledge management, data quality, or operating models aren’t ready. The architect’s job isn’t simply “no”; it’s reframing the conversation to “how do we get there?” with a realistic path, timeline, and alignment to business priorities. Start with business outcomes and capabilities, then choose solutions and platforms last; starting from tools locks you in and reduces long-term flexibility.
• Governance, frameworks, and alignment. Using themes, epics, and idea portals helps ensure every piece of work ties back to business strategy and prevents scattered, one-off projects. Any governance framework can work, but the critical part is using it consistently so decisions are traceable and you can understand and revisit past choices. Feedback loops and organizational change management are needed early and often, so you can see how decisions play out (e.g., a 3‑day install becoming 14).
• Empathy, communication, and frontline experience. They stress empathy: everything in IT is in service to someone, and it’s easy to forget that if you never see real users. Frontline roles (help desk, service desk, customer success) are invaluable; going back periodically keeps you grounded in how people actually experience your systems. One example: a CMDB/CSDM explanation was reframed as a ballet analogy tailored to an executive’s interests, which made the concept finally stick. Great architects practice empathetic storytelling—knowing the audience, choosing the right narrative, and over-communicating during change.
• Avoiding “villain” status between business and IT. Architects often sit between business leaders demanding outcomes and IT teams building and running systems, which can make them the perceived “villain.” Transparency in how decisions are made, involving engineers early, and allowing people to see and participate in the conversation builds trust even when the answer is no. You can’t be an “Oz behind a curtain”; visible participation, feedback, and iterati

Transcript

SPEAKER_03 0:00

If you I'm stealing in an analogy here, I'm I'm meing an analogy, but it was a great one I heard the other day about a a giraffe. A good enterprise architect is like a giraffe in safari. The really tall can see really far. And when animals are in danger, or if there is danger, they look at the giraffe. If the giraffe is running, you should probably be running too because they see the danger coming. And that example that you just used there, if you are able to see that coming, if you are the giraffe, you have you're able to provide some options, or at least you have some time. And time allows you to devise some options to handle that. Do we change the architecture? Do we go with a hybrid model? What options are available to us versus if you have very limited time, or maybe it's a stressful merger, for example, very limited time, it's harder to be able to get that viewpoint, that perspective, and make those decisions and prevent that master, prevent that danger.

SPEAKER_04 1:42

So we'll unpack what the role actually looks like day to day, the responsibilities that don't show up in job descriptions, and how architects bridge business strategy with that messy reality of a complex system. Whether you're already in the role, aspiring to it, or really in our cases, have done this and work with others who are doing it today, this conversation will give you an honest look at the decisions, trade-offs, and relationships that make or break great architecture.

SPEAKER_03 2:09

Our perspective on this episode is that it's three people who have lived the enterprise architect role, stepped out of the formal title, and are still doing the work in different hats. Together, we're looking at EA less as a job description and more as a way of thinking that follows you into every leadership and solution space you touch.

SPEAKER_02 2:31

So you don't stop being an architect when a title changes.

SPEAKER_04 2:35

Architecture is as much about people, context, and timing as it is about diagrams and the standards. And the real impact shows up in how you help organizations make long-term better decisions across many domains of technology.

SPEAKER_03 2:49

Inside the EA mindset, when you walk into a messy enterprise, what do you see that others miss? Open question, whoever wants to take it.

SPEAKER_00 2:59

Well, you know, you in the intro, you talked about messy reality and you used the word messy again here. I think it's it's accurate. Maybe it's not always complimentary to the folks we worth it, we work with, but that that is the reality, right? Unless you're dealing with a completely greenfield situation, which is a very rare thing, there's always going to be uh legacy mess to drag along with, right?

SPEAKER_03 3:25

I think the the precursor to the mass is Greenfield, because eventually once you get away from Greenfield, there comes the mass.

SPEAKER_00 3:34

Exactly, exactly. And I think as as somebody that you know is coming into a a situation, working with the customer from the outside in, just that perspective alone, I think, is very helpful, right? Because when you're, you know, living inside your own reality, messy or clean as it as it is to various degrees, right? You are you you're used to it. You become accustomed to it, you do things the way you've done them because you've always done them that way and you're dragging all that stuff with you. It's part of your contextual reality, right? And when you come in with a fresher set of eyes from outside, whether you're, you know, brought in temporarily to work with a customer for duration of a project or something longer term type of relationship, I think just that that perspective allows you the ability to see things that they wouldn't have necessarily thought to mention or picked up on themselves or have grown so accustomed to that it just is, you know, is is part of the fabric of the way they've done things.

SPEAKER_04 4:37

Yeah, we've we've spoken with like David Cram on purchasing and procurement, you know, taking an approach that where you don't have a lot of redundancies, right? That's where you save your money. Right. So chasing that the the this the shiny gold thing, in a sense, in technologies will will take you into that messy situation. My my thing is I go back to is define messy. Oh, messy can be a lot of different things, but what would be a messy enterprise to you guys?

SPEAKER_03 5:09

I think being unable to define how you make your decisions, having unclear governance, unclear structure. If you were to ask someone, let's say you're you're buying software or something, and you ask them how they made that decision, and you don't get a clear, articulate answer. And then you ask them other questions how um around the same vein. That lack of clarity is not just at that level, it spreads. It spreads in requirements, it spreads to other departments that depend on that software, it spreads downstream to the folks who have to build something for it, and it goes out. It's weird. It's it's the kind of the way that I'm I'm describing it, it's kind of like a virus, which I don't know that that's what I would call it, but that lack of clarity causes ripple effects.

SPEAKER_04 6:01

You can become messy though with mergers and acquisitions, quick, right?

SPEAKER_03 6:08

You take two rooms and combine them together.

SPEAKER_04 6:11

Right.

SPEAKER_03 6:12

That's a fast track.

SPEAKER_04 6:14

That's yeah, that's one trying to get to the cloud. Maybe it isn't the best decision you try to draw back, or you're half in, half out. Sometimes it's messy, sometimes it's not. Sometimes it's clear. I do this for this reason, I don't do it for that reason. So it may seem like I'm on the fence between the two, but there's probably a business reason why. So that's not wouldn't be considered messy. I know we did if I had one of our Toby and I's former employees, we ran into a lot of we don't have enough people in that skilled technologies to serve all those. Right. We don't have enough people who can do all sorts of types of virtualization in a sense, right? Or all sorts of types of storage. We have to sort of hone in on, because that's where our skill engineers are trained today. They can't be, they won't be able to be trained to handle 10 different types, you know, and manage it appropriately. Um so I think to me that could be messy too, is a skill where you're not keeping up with the skill, you're spread too thin, things like that as well. When when you have opportunities to to, I guess, to bring it together.

SPEAKER_03 7:24

That goes to the decision-making process. If you I'm stealing in an analogy here, I'm I'm mean an analogy, but it was a great one I heard the other day about a giraffe. A good enterprise architect is like a giraffe in Safari. They're really tall can see really far. And when animals are in danger, or if there is danger, they look at the giraffe. If the giraffe is running, you should probably be running too, because they see the danger coming. And that example that you just used there, if you are able to see that coming, if you are the giraffe, you have you're able to provide some options, or at least you have some time. And time allows you to devise some options to handle that. Do we change the architecture? Do we go with a hybrid model? What options are available to us? Versus if you have very limited time, or maybe it's a stressful merger, for example, very limited time, it's harder to be able to get that viewpoint, that perspective, and make those decisions and prevent that mess or prevent that danger.

SPEAKER_04 8:33

Um, you can be like you said, you can be messy, but if your decision structure is clean and you just don't have time and space to bring two disparate organizations of technology, a Novell and a Windows network, you know what I mean? To bring them together into one, it's a it's a time and effort management, but you know it's there, you have a plan for it, it's just not going to be done immediately. I think that's fine, right? It's that decision structure, it's that plan structure. And um there are a reason to messy is security nowadays. If you're messy, if you don't know, if you can't handle and manage to the nth degree all your technologies, you're open, you're susceptible. And I think that's dangerous.

SPEAKER_00 9:18

I'll tell you what, all these things make me think of that you I think that people have the best of intentions most of the time, right? And the road to messy is paved with good intentions, right? It isn't like, you know, somebody intentionally set out to create an impossible messy situation. It just happens, right? I mean, here's an example that probably resonates with the two of you and some of the listeners too, I would imagine. Think about like repositories of information, right? I think we've all been places where, you know, there's wiki A, and that gets some use. And then some other group, some Splinter group says, oh, that's not doing it for me. We're gonna build our own thing over here. And they spin up some other internet repository. And this group says, uh, well, you know, we're gonna do this one over on Fox, and we're gonna do this over here. Right now, all of a sudden you've got, you know, a half dozen repositories, none of them have everything that you need, and you're searching all over the place for something. It wasn't like the groups that thought of these things, you know, I think had horrible intentions about, you know, the mess that they were creating, but something wasn't working for them. And maybe without the giraffe overlooking them and bringing all that stuff together, you end up with this mess, right? But uh, you know, I think we need to be generous in assuming that the messes that we we may find ourselves in with our customers or in your own organizations were there because, you know, they're they're they're a result of a lot of little individual decisions over the years that uh, you know, maybe didn't take into the the entire enterprise into account when they were being made, right? What's most expedient versus what's better long term is that you know often kind of where things come down decision-wise.

SPEAKER_04 11:02

So it brings us to the next question, which I think also fits in all of our AI episodes previously. What's the emotional reality of saying no to cool tech? Because the architecture or our operating model isn't ready. And lots of times, so you've just brought up repositories. When you have disparate repositories that aren't managed for quality, for reach, for delivery, your AI isn't going to work as it tries to go sift through all that information. It's you're going to get that kind of return. So I think that's, you know, saying no to AI or saying no to a gen AI help desk, you know, repository support system because you don't have knowledge management maintained or orderly, to me, there's a reason why you say no to that. But how do you, you know, that that's emotional when you say no to people who are saying, hey, this is what everybody's doing. This is where we got to be. You know, if we don't do this, we're behind.

SPEAKER_00 12:00

Yeah. And it doesn't even have to be something as sexy as AI, right? A lot of times I think the cool tech can be something, you know, a layer or two down from whatever the hot flavor of the month is. But the lift to go from where you are now, where the customer is now, to where they think they want to be, whether or not that's the right place or not, is uh might might be too great, right? You can say, Oh, I have this fantastic greenfield destination in mind, but you know, look where I'm starting. What's your time frame? What's your driving factors to try to, you know, get off the platform you're on now onto other some other platform, right? And is it gonna be something that you can get done?

SPEAKER_04 12:42

Yeah, we see this all the time. This one, like you said, it's not just AI. We've seen this with like SaaS, Azure, we've seen it with Nutanix, right? To move to Nutanix or not, or just um just different things like that. I mean, there's a lot of tech there's a lot of technologies that cause that.

SPEAKER_03 13:03

I think it's just being clinical or as clinical as possible to lay out that foundation of if you can't, here's why, here's how you mitigate, and here's the prioritization of it. To your point, the flavor of the month really popular. The other thing to balance that out with, besides that clinical path, is that alignment to priority of the business. And if it is a threat to the business, yeah to it's again be as clinical as possible. Is this something that we should be prioritizing because it is going to change things for us? Or is it just the flavor of the month?

SPEAKER_04 13:43

Well, that's the execution of the system architect, right? Is to say business, what is the business need? Here are the technologies that are entering our arena. And it's not saying no, we're not ready for it. It is how are we going to get there? And and enterprising that strategy or developing that strategy and plan to be able to convert, to bring it in and consume it so the business can take advantage of it. So that's the challenge for the architect is I'm not saying no, I'm saying how, you know, and and and looking at that way, I guess. I don't know.

SPEAKER_00 14:15

Yeah, I I think that's right. A lot of times, you know, if you're thinking about maybe as the architect, as somebody that is sitting, you know, in some respects between the rest of IT that's got to build it and run it and the business that is demanding it, you know, they're they're they're hearing from both sides. And I think something that has the tendency to happen is that folks inside the IT organization can make demands that are, you know, coming at it from a product or a solution standpoint first, right? I need this tool to do this thing, right? Rather than starting at the other end and saying, well, you know, these tools exist for what? They exist to solve a problem, a business problem, right? So start with the business problem first. What's the challenge you're trying to solve? What capabilities do I need to implement in order to solve that business problem? And then what solution and what platform are like the last two things you should think about, right? And because, you know, if you're not starting with the business outcome first sort of mentality, you're probably not going to be very happy with what you end up with, number one. And number two, you're going to lack some of the, I think, flexibility that, you know, if you do that kind of business outcomes, capabilities, solutions, and then platforms sort of flow, you're able to adjust more quickly, right? You can build something that solves that business need via those capabilities that you can deploy on-prem. And maybe later when cloud becomes, you know, something that you want to leverage, you can move it there too. And vice versa, right? You know, there's a lot of push these days with uh with some customers to bring some stuff back inside. You want to have that flexibility. And if you start with the platform first instead of the business outcome, you know, you've kind of locked yourself in or made it a lot harder to be flexible down the road.

SPEAKER_04 16:10

I know I know mine isn't my job today as an enterprise architecture as far as all the hardware and everything. But with ServiceNow, you know, we get into hardware asset management, software asset management, ITOM with event management, things like that. And what I'm finding and uncovering is when as I try to discover all these assets, what tool am I taking advantage of that's out there? And kind of exposes some redundant tools, like we'll talk about how we're going to get laptop information in or something like that. What tools are out there? Or the server one. We have Logic Monitor, we got Ovic or whatever, you know, systems that for each team might do well, but overall they do the same thing.

unknown 16:52

Right?

SPEAKER_04 16:52

But they came they came over years through to time or whatever. So I think those are some areas that I work with. And I know in our development we have themes. So themes and epics. So every story has to fit our theme and epic. And our themes and epics are built and approved by my senior leadership. So that allows me to every story we do, it's easy for me to go to my the development team and say, what epic does this fit in? You know, if it doesn't fit in an epic, it goes into the idea portal, idea chamber, in a sense, and we find out where it does fit. But we can do work if it fits our business strategies of these themes and epics that are out there. So that's only in service not development, but that's how I took my lit my learning of how to try to pool things, that's how I'm doing it. So that's my governance, I guess.

SPEAKER_03 17:46

Are you sticking to that story?

SPEAKER_04 17:48

I tell myself this stuff all the time. So yeah.

SPEAKER_00 17:52

Well, whether you use that framework or some other framework, I think, you know, and there are a lot of them.

SPEAKER_04 17:57

Yeah.

SPEAKER_00 17:57

There is. Having a having a framework to base those decisions on the is the yeah, that's the important thing, right? Otherwise, you know, you've got group A, B, and C just doing things willy-nilly and you'll end up with a big mess.

SPEAKER_03 18:10

So the earlier point, you can go back and see the decisions that were made because you have them documented. And even if it becomes a mess later because strategy, capability, something has changed, direction has changed, you at least have those breadcrumbs and that path to trace back to see why something was done a certain way and figure out do you need to do it again that way or change it, etc. But I think that was great. Aligning the outcomes and what you need to do, aligning to that first, and then finding what the right capability is and then how you solution for that. I think is a great way to be really clinical about how you're solving these things.

SPEAKER_04 18:49

You gotta be okay with moving and adjusting.

SPEAKER_02 18:51

Yeah, for sure.

SPEAKER_03 18:52

Change change is is how we get to the future. How do you bal uh trademark and T on that? How do you balance being the bridge between business strategy and tech execution without becoming the villain? So business strategy, tech execution without becoming the villain. I I think that's a tricky one. You can be just so popular on every on both sides. And I think to the point that was just mentioned, if you're able to articulate the outcome at various different levels so that your executive leadership understands how it is helping them get what they need, the folks who have to build it or if you're buying it, implementing, etc., understand that vision as it relates to them. I think that helps. Even if you have to tell people no on certain things. If you had to say no to that really cool tech, for example, and those folks were real excited to implement it, articulating it in a very clear, this is how the decision was made. This is why. Yeah, we can come back and revisit this, or we are not coming back to revisit this, but this is the decision that we're we're disagreeing, but we're moving forward and we're committing. And just being as clinical, transparent, A to Z as possible helps. I don't think it is always going to be a solution, but at the very least, you're you're putting it on the table so that folks can ask questions. They can kind of chew on it, digest it, understand why. On Monday and Tuesday, they don't like you. On Wednesday, they still don't like you, but they'll at least look at you. Maybe by Friday, they'll they'll send you an email with questions and then you can answer those. But I I think it is also a function of time to never please everybody. It's impossible.

SPEAKER_04 20:53

I think I think you're right. But I think if you, as any leader, you get participation from the ground up, and everyone feels like they're a part. None of them are steering, maybe leadership is, but you know, but at least at least all the engineers and those affected, it can't be us, right? You can't whisper through a window, wait three days, and you get your answer. There's no one takes that nowadays, right? So you need to be in the participation of and see the conversation to understand why. You don't have to give the two great lengths of that, but if you start doing that in the beginning, then I think they trust you in those hard times, you know, that okay, I didn't get this, but I understand where Brian or Toby or Steele's coming from. And a day-to-day decision making, that's what they apply. And I think it's easier that way. Yeah, they may be a little miffed by it because they don't understand you, but I think in the greater scheme of things, they understand. I think as long as you're participating, I think everyone sort of evens out.

SPEAKER_00 21:56

Yeah. I think a a challenge that I I've seen. And it can happen in larger organizations where larger IT organizations where, you know, there's not a lot perhaps as much cohesity uh or knowledge at the project level about what's going on. You may be brought in by group A and you're working on something with them, and then it gets a little, you know, it gets far down the road. And then group B will say, oh, well, I didn't know what was going on. So now you got to bring me in, and now we gotta, you know, we got to take care of my piece, which is, you know, whatever it is, networking or security or storage or what have you. I I think the way to mitigate that is to make sure when you get started that you're talking to all the right people that you need to be talking to. So you're not, you know, working on something in a silo with a group that's, you know, you know, can only take it so far, right?

SPEAKER_04 22:52

That's that's uh Yeah, you you need feedback effect, right? You need feedback of what this decision caused, you know, and what the implications were. Is it now too difficult? It went from a three-day install to a 14-day install, you know, either because of the learning curve and or how complex it became. Well, as a systems architect, I think you need to come back and look at it and say, wait a minute, I need to, I need to I need to reduce the complexity, right? Because that doesn't help anyone. But I just think this the feedback, the participation back and forth. I think you're right. It's just in a big organization, the only way they're going to survive it is like a knowledge base, a feedback loop, something like that that helps people tell a story of this is what your decision looks like in the end.

unknown 23:43

Yeah.

SPEAKER_03 23:44

Some type of OCM or organizational change management.

SPEAKER_02 23:48

Yep.

SPEAKER_03 23:48

Early, early. And if if folks aren't getting it, then often, as often as possible, overcommunicate. Um so what's kind of kind of moving on here, and I I think this also part lays into that last one. What did frontline service or customer success roles teach you about what or or has made you a better architect? Kind of be it on the front lines.

SPEAKER_00 24:14

Sure. Uh that's a great question. I think and have thought for a long time that any role in IT, whether you're really frontline help desk sort of person or desktop support, or you're a developer, you exist. You're there to do a job for a reason, and it isn't for technology's sake. You're there to support something that does a job for somebody else. Right? You are the the printer doesn't care if it's broken, the application doesn't care if it has an error, the server doesn't care if it crashes. The people that need those tools to do their job do. And I think that it's easy to lose sight of that, especially when you aren't face to face interacting with customers. You're the guy building the, you know, building the application. You know, maybe you don't have the touch points with the customers that you should. So how do you fix that? I think it's important for the people that are in IT to understand what it is they're building and who it is they're building it for and why they're building it, right? We uh where where I work, we have a we have a program to bring our developers in front of our customers, right? They're they spend, you know, all this time building these products, but you know, we want to put them in front of the customers face to face so that they can hear firsthand. Well, this is what it's like to use your product that you've been building, right? I'm having challenges with this. This works great. Wouldn't it be excellent if this thing was a little bit better? And that and the developers really get a lot from it. It's it's a two-way street, right? We we hate we we try to set up these meetings, have these recurring touch points so they can hear firsthand how people are using the thing that they're building. And I think it's it's really important.

SPEAKER_04 26:05

The mindset of the developer is so much different than the user in the way they think and you know, and and they really need to be more empathetic or at least understanding of that. And I think a sitting in help desk, sitting in service desk is something that someone not only has should do in their career, but probably should go back to periodically and watch and look and see how the users are reacting to it. Law firms, people would make fun of law firms because we it took us forever to leave WordPerfect. And no, this the dark story, the dark story of that though is Microsoft Word wasn't ready for law firms. You know, when a document is your widget, a document is your business, and all the things that WordPerfect could do and has gained over the time, Word wasn't ready for that. And finally it did, or the tooling, third-party tooling came in and helped to get there. But it took forever just because the effect on legal assistants and professionals and what they knew and how six-minute increments of time is the world to them. And when you take eighteen make 18 more minutes to do a document than you did before, it's that's dramatic. And I think that just learning that, what the floor is doing, how it, you know, it's five clicks. Oh my gosh, I can't believe you have to do five clicks, but you go look if I gotta do five clicks a hundred times, that's a that's something you know that can be measurable. Which I think help desk is something everyone should do and or go back to and listen to.

SPEAKER_00 27:37

Yeah, for sure. Okay, OG quiz. Who remembers what the function key is to reveal codes in WordPerfect? See, I couldn't. F11.

SPEAKER_02 27:47

I supported it for so long, but yeah, I couldn't go back there.

SPEAKER_00 27:52

Oh, you're absolutely right. You gotta you gotta get that frontline experience and get back to it, I think, as as well.

SPEAKER_04 27:58

I mean, I guess that that yeah, empathy exactly. One of my mentors, the first thing they taught me when I first got into law firms was how to be empathetic and and listen to users and and what you say is what you mean and what you do. And those things are just professional things, those are just human things. And I think that was that was this that that helped me through my career, knowing those.

SPEAKER_03 28:20

So go ahead. Yeah, just I don't have too much to add to that, other than plus one to everything you both said there. You have to interface with the folks who are using your products, using your tools, understand pain points from their perspective, and it's real difficult, I'd say impossible to get that perspective unless you're them in their shoes. And so spending that time understanding how what you're doing is solving things or not solving things for them is crucial. And yeah, I I agree. I think there should be some amount of time, even if you don't go back into the role, where you're at least reviewing and keeping some kind of touch point or pulse on how your customers are doing, is crucial.

SPEAKER_00 29:09

And beyond, the last thing I'll say on this is beyond just how they are how they are experiencing the technology that you may be, you know, putting in front of them, whether you're the developer or you're the sales guy that sold them the thing, ask them, how is it like dealing with us as an organization, right? Because a lot of times, you know, we we we go in there if we're part of a you know a software or hardware vendor and we're trying to sell the customer something. But oftentimes, you know, hearing how it is to work with us as a vendor is really important, right? You know, it's difficult to work with you guys sometimes. Your support people, you know, they take four hours to acknowledge a case, or why can't I get a demo when I, you know, asked for it five days ago, or this, that, or the other thing, right? You know, these aren't anything having to do with the technology you're selling them, it's how they are dealing with you as an organization, right? It's a it's a customer service job, right? And you can't forget that.

SPEAKER_03 30:07

Yeah, I think everything we do is in service to somebody, and it's just never forgetting who that somebody is.

SPEAKER_04 30:16

Amen. So uh what's one belief that each of you have had firm in your mindset that's probably changed or evolved in the last five years?

SPEAKER_03 30:28

I have to think about that one. I'm sure there's many five years. So it's 2021. Yeah. I think my entire brain is different to to be uh to be fair there. I I think everything has changed.

SPEAKER_00 30:40

Yeah, I'm gonna have to think on that one. I'm trying to think of it from a technology standpoint, from a customer service standpoint. And I honestly don't think too much has changed there for me in either of those areas, right? Like we were talking about, I still think of it as a as a customer service job. Technology has changed, of course. AI is changing a lot, but you know, there have been other technological shifts. But again, technology exists to help people solve problems and do work, and I don't think that's changed a lot over the last year.

SPEAKER_03 31:08

I think the biggest thing for me is my approach to communication. We talked about empathy previously, and I think there is empathy in communication that is really difficult to do, that really good storytellers seem very masterful at. Uh Simon I'm his last name, Cynic. Yeah, direct to the point is at that level is able to essentially bring everybody along for the ride. I think if you can get into a room, you know your audience ahead of time, and you're able to present the narrative, tell a story in a way that they understand, that they relate to even better if they can relate to it, that drives the understanding of it and keeps it crisp. That has changed the most for me. And that is also something that I've been purposefully practicing and focusing on in my interactions with leaders, with customers, with folks at all different levels. I've found that it does not really matter how much you've researched, how much you know, you could have the right answer to absolutely everything. But if nobody understands you, if they can't understand it the way they need to understand it, you could lose them. You won't get the right decision. They might could take longer to make a decision. There's nuance in that. And just working on that has been an exhausting exercise that I is taking years. I'm definitely not perfect at it. I I still work on it every day in some small way. That's the thing that has changed the most for me is just how can I be empathetic in my storytelling so I can help other folks understand and bring them along for the ride. I'll just give you one example and then I'll turn it over. I spent probably the a day before I had to give a presentation and explain it. It was ad hoc. I incurred this on myself, but had to explain CMDB to an executive leader. Uh and everybody thinks they understand CMDB. I think I understand CMDB, and that stuff, CSEM.

SPEAKER_04 33:23

There's only two people in the world who would.

SPEAKER_03 33:25

But you asked two, you asked to your point, you asked two different people the same question, you'll get a different answer. And so I explained it. I I re I just recalled a fact of something they liked. And I I know this is gonna sound real cheesy, but they they liked the ballet. So I worked the night before and I came up with an entire CSDM CMDB analogy that liked likens all the components to the ballet. That's how you do it, and it stuck. Yeah. And not and I learned from that. I I use there's some analogies I go back to all the time. It also helped me increase my own understanding and my awareness of that empathy. Yeah. I put effort in to meet them where they could understand it, and I put effort into thinking about what would have the most impact instead of going to canned examples that I had that I thought I understood. And so it was showing empathy in that communication and and knowing something about the person to meet them there. It was just an exercise that I had, I'm sure I've done things similar, but never to that degree. And so that really stuck with me.

SPEAKER_04 34:37

It opened your eyes up a little bit on that. Yeah.

SPEAKER_03 34:39

Yeah.

SPEAKER_04 34:40

So I grew up, like I became IT manager in the late 90s, CIO shortly thereafter. So I sat at that role for a while. So it was easier for me to say, okay, we got this huge project. I need to find out how to sell these attorneys on these partners on it, you know, on the investment, on the returns, things like that. So that big push to bring it in. What I failed at is something. Have you guys watched the pit? So in that emergency room.

SPEAKER_03 35:11

I'm on season two.

SPEAKER_04 35:12

So in the emergency room, there are like in one patient, there's five, six, seven people talking, communicating a lot of, you know, code, but still boom, boom, boom. And it's and it's it's required. And I think that's where I don't do well. Is in the middle, I can prep, I can I can clean it up afterwards, but in the middle of it all, I don't think I get involved or communicate enough in that set. That's where I'm missing. If I was to pick a growth area, I think that's the part I miss is in that triage, reactive, you know, this is happening, communicate back and forth, give updates so everyone knows where everything is. Um, yes, I said we're going to do it in this four-week sprint, but I'll talk to them about it until four weeks from now. That doesn't do well. They need to sometimes they need to know where you are in this process. And I think that's something I need to work on. But I think that's inherently required nowadays. Um, just like the pit, you know, they wouldn't patients would not survive if the doctors didn't communicate in that manner.

SPEAKER_03 36:19

Yeah. Well, you need a BIPAP stat.

SPEAKER_04 36:22

Yeah. But it it was, it, I just, I mean, I've watched these other shows and I think I and I learned, I think, and one day I just looked at it and said, that's what I don't do. In the middle of the battle, I don't get in there and communicate well enough to keep us moving forward faster, more effective. You know, and it's not that I don't have empathy for them. I do. I just don't get involved as much as I should, or listen or watch, or monitor for signs just so I can help, you know, things like that. So I don't know.

SPEAKER_00 36:55

That's give yourself some grace, Brian. That's not for not everybody can be an ER doctor.

SPEAKER_04 37:01

No, no, you're right. But I'm always looking at something, what I could do better, what I could learn better, how, you know, it and and um I just think that's, you know, watching my grandkids, I I try to look at it from their eyes for, you know, raising three girls. I had to learn how three girls in the household with my wife and the dog is also female. I'm the only guy in the house. You know, just the life changes there. It changes you, but you look at things differently at work too. I I learn how to communicate better. I learn how to be more empathetic, understanding, try to watch my tone, try to watch my facial expressions. I think we did one and Steele was telling me, you look mad. Why you, you know, smile a little bit, you know. It's just it's my rusting bitch face, you know, whatever it is, you know. And then I still tell people, I really don't like people much. And someone, oh my gosh, I can't believe you don't like people. Well, I know I need to communicate with them and I know I value them, but people more than not have disappointed me or failed, you know, and so I have this negative feeling, but I still know every day I it takes other people with me, it takes a team just to be successful. So anyway, get off that.

SPEAKER_03 38:10

The folks are listening to this. Brian is the most peep biggest people person you've ever seen. You'll find a random person at a bar and they'll be best friends. It's so weird to hear. But I think to your point, it it takes practice, it takes concerted effort, and we're always practicing, we're always getting better. Nobody is word perfect, it's just muscles that we have to keep working on. And it it changes too. What what works today for communication and resonates might be different. Folks are moving away from email and going into Slack. Drives me crazy sometimes. That that always instant on. Um folks expect that communication channel. They as one of the channels. So it's just practicing that muscle and practicing empathy in everything that you do.

SPEAKER_04 38:58

Yeah, I think as a system enterprise architect, to me, the theme is yes, you can set the architecture in place, but you can't then just say, there it is, now now use it. You have to be involved every day to ensure it's working and it changes. I think I think that's that's what our theme is, right? Is the architect isn't it's not the right term, it's a solutionist, an enterprise solutionist. Right? Because an architect to me does the blueprints, waits for feedback to make the adjustments, but doesn't really get involved. He doesn't know how the house is wired, he just knows where the plates go. So an architect to some degree isn't the right term for what we're trying to roll this as. I think it's more of a solutionist. It's the enterprise solutionist, I guess. I don't I maybe not, maybe I'm wrong.

SPEAKER_03 39:48

One of my uh Catman is one of my mentors. He doesn't he doesn't know, but uh they said that as an architect, your job is people. And I I think that's so true. And that goes back into the empathy, into the communication, helping folks understand, bring them on for the ride, agree, disagree, be clinical, and not to appear to be the villain, but it it's I think it is people, first and foremost.

SPEAKER_04 40:13

Can't be odd.

SPEAKER_03 40:14

Having that, yeah, having that ability to communicate, share the vision, share the architecture. Because to your point, if you could just have an architecture out there and you didn't have to well, so many things would just work, but uh, that's not the world we live in.

SPEAKER_04 40:28

Right. It's all right, Toby. Thanks for pulling back the curtain on Withis and uh what it really means to live as an enterprise architect, not just frameworks diagrams, but the trade-offs, the scars, the wins, and the easy to miss from that are easy to miss from the outside. If you're listening and you're in this role, um, I hope you've heard a little bit of your own story here. And and if you're aspiring to it, I hope this gave you a clearer, more honest picture of the road ahead and probably and didn't scare you off. It's an amazing role. I think it's a rewarding role, but you have to bring a lot of pieces together and it's challenging. As always, if this episode resonated with you, share with share it with someone who's in the thick of these decisions every day. And we'll catch you next time. Cheers. Thank you.