Architecture Does Not Emerge - a Conversation with Tracy Bannon

Introduction

Michael Stiefel: Welcome to the Architects Podcast, where we discuss what it means to be an architect and how architects actually do their job. Today's guest is Tracy Bannon, who is senior principal at MITRE. She sees herself as a passionate software architect and change agent who also puts out the Real Technologists podcast. It's great to have you here on the podcast.

Interview

How did you become an architect? [00:52]

And I'd like to start out by asking you, were you trained as an architect? How'd you become an architect? It's not like you woke up one morning and decided, "Today I'm going to be an architect."

Tracy Bannon: Well, I am of a certain age that the term software architect didn't exist when I started my career. And what's interesting about it is that I am very, very close with my older brother, very good friends, and he's truly a building architect. And to this day, we spar about whether or not I'm actually an architect. He claims that word for his domain. But we shared a lot from a mentality perspective, always about how we approached problem solving. Both of us are techno geeks in our spare time.

So how did I get to be an architect? I grew into it along the way. I always thought about things from a big picture perspective, and I naturally graduated or evolved towards that. But no, no formal training at first until there became opportunities for training in that area. I have my SEI certifications working with the Software Engineering Institute. I did not go back to get a second degree in software architecture because you won't find one, you'll only find software engineering. So there we are, woefully uneducated as an entire people group in my opinion, which is why it's so important for us to have podcasts like this and keep reaching out to the next generation.

Michael Stiefel: Don't get me started about software engineering, whether it's engineering or not.

Tracy Bannon: We could have some fun with that.

Michael Stiefel: Yes. So as you became educated as an architect, you must have found certain resources that were useful, and at the same time you found certain problems occurring over and over again that the resources either didn't address or address only from a theoretical point of view. What were those issues? And do they still exist today? I mean, one of the things that ... I'm sure you read The Mythical Man-Month at some point in time, and he talks about, written in the 1960s, how software was late and over budget, and it's still late and over budget 50, 60 years later.

Tracy Bannon: So it's funny that you bring that up. I have it on the shelf behind me because it's one of those references that you go back to in there, little bits and quotes that are there. I'd actually assert that since that time, even before that, we've been doing a bad job of, we've been writing crappy code for 50, 60 years. We, you and I as architects, have been trying to elevate that craft, right? So things that I always found that would drive me batty were lack of repeatability. So people would be in two different rooms in the same building and solving things very differently, but unnecessarily. So as the culture of having design patterns started to emerge, Grady Booch, and all the others, I was an immediate adopter because it just made sense. It immediately made sense to me. So I love patterns and practices.

Design Patterns and Practices [03:59]

I actually have on some of my bios how much I love patterns and practices because it's not the answer, but it's a logical way to think about it and it helps us to stop talking about architecture as though it's a whole lot of art and a little bit of science. Because we're scientists at the end of the day, we are dealing with, there's a certain amount of repeatability. Yes, there's a flair of artistic creation to it. But yes, that was the big thing. When those design patterns started to come out, I would work with teams to help them identify patterns that they had that might be unique, that weren't necessarily published on the broader stage within their domains. It became super exciting time for me, super exciting. And yes, I'm geeking out talking about design patterns.

Michael Stiefel: Okay. So I mean, design patterns, I mean if you are familiar with the Addison-Wesley series on design patterns, they have domain specific patterns, enterprise application patterns, integration patterns, continuous delivery and integration patterns, it's overwhelming at some point. How do you get people to understand in this toolbox? How to pick the right tool for the right ... Because there are sort of two extremes. One is to be ignorant of the tools, but on the other hand, as the old saying is, all you have is a hammer or all you know is the hammer, all you see is the nail. I mean, it's like the people who ask, well, what's your favorite design pattern?

Mentoring [05:38]

Tracy Bannon: Oh, my gosh, don't drive me crazy with that. No, no, no. So as somebody who grew up sewing and knowing how important, I have dozens and dozens of patterns, I learned to sew from my grandmother and my mother, and you would have many, many different patterns and different ways of doing things and different ways of making decisions, but there were some core concepts that were really relevant.

So where I normally fall back to is starting with the basics so that people understand what a software quality attribute is, understanding what tactics are, understanding what trade-offs are, taking a step back. Unfortunately, a lot of our developers, we used to call them programmers, dive right into the coding in their brain. As soon as they listen to somebody describing a problem, they're off and hammering the boards like, "Whoa, you don't know if they want a marble floor or a wooden floor. Just go back and stop."

So I take them back to the basics and I walk that with them. That's always the way to go, and I'll find people who naturally understand and I'll find some who naturally don't, and I start to mentor a little bit more those who understand and naturally think more  broadly. Not everybody is meant to be an architect, and that's okay, but when I find them, I mentor them even more. It doesn't mean that you can't grow into that. It doesn't mean that you can't learn, the sciences can't apply. It doesn't mean that. But there does seem to be a natural inclination.

Michael Stiefel: I'd like to come back to that a little bit later. People should not think of architect as the next step in their development. But architects and developers are two different types. Go back to your example before with your brother, just like there are building architects and carpenters and masons and people who do kitchens, they're all respectable opportunities and jobs. So let's put that aside, but I do-

Tracy Bannon: Hold on, hold on. I would hope that we're not telling anybody, nobody is assuming that there is a job progression that says you're going to start as an entry level developer. And I'm not even going to go that whole full stack malarkey, don't get me wrong there. But then the natural thing is that you're going to be the tech lead, and then you're going to be the lead engineer, and then you're going to be the app arc, and then you're going to be the solution arc, and then you're going to be the enterprise. No, there's not a direct progression like that.

Michael Stiefel: I agree with you, but you'd be surprised how many people think there is a progression.

Tracy Bannon: Oh, I know.

Michael Stiefel: So I want to come back to that in a little bit. But since you brought up the design patterns, I want to sort of explore that in a little and bring it down to a very concrete level.

Agile Development [08:20]

One of my bugaboos is people who sort of advocate this TDD, test-driven development, or what's the other acronym for TDD? It's escaping me-

Tracy Bannon: Test driven?

Michael Stiefel: Test driven is one of them. So they say, you don't design, you develop a test. So this is my problem with it, and I'd like to see how you react to it. If you design a test, you have to have something that you're testing, which means you have a class in mind that you have to test. And that class you didn't pull out of anywhere, you actually had a design in your mind to begin with. So to say that you don't design and you let it ... It's sort of, it's fallacious.

Tracy Bannon: It is a misinterpretation of the intent of test-driven development. It's like, "Come on." This is one of the reasons that I like design patterns because they are patterns. They're not a single recipe. This is “the how you do it”.

Michael Stiefel: Right.

Tracy Bannon: Unfortunately, with a lot of other words that we have, "This is agile and this is what it means. Agile means no architecture, no documentation, everything emerges from the muck." No, that doesn't mean that at all. It's the same thing. It's the same thing that we're talking about here, is there's a lack of understanding. Test-driven development, the entire premise is that you have a good understanding of the requirements. I'm not going to say user stories, I'm going to say requirements. You understand what is necessary and you can start in engaging with the end users. I would hope the end users. You would start to gain a sense of ... And yes, it does start to reflect. It does start to reflect what the ultimate design is. So yes, you're projecting design bias into test. So there's a design bias there. However, the best tests in my experience are those that properly reflect the requirements. So I actually like the concept. It's damn hard to do. It's really, really hard.

Requirements Analysis [10:31]

Michael Stiefel: What makes it really hard to do, and you've raised a very interesting point, is how do you find out requirements? When people ask me what I do, I've basically say that I do three things in my programming career. God knows how many years I started. Oh, my god, in 19 maybe 82 in the programming business.

Tracy Bannon: Okay.

Michael Stiefel: Until this day, I say I've done three things: insert levels of indirection, trade off space and time, and three, try to get my clients to tell me what they really want. There's a great book by Weinberg and Gause called Exploring Requirements: Quality Before Design. I don't know if you've read it or not.

Tracy Bannon: No, I haven't, but it's going on my list right now.

Michael Stiefel: I think that's the correct title. The difficulty is that people try to develop a recipe for doing these things, but you can only have this recipe. I mean, I don't know if you remember when people wanted to have requirements design languages. That was a thing about 20, 30 years ago. So in the book, Jerry Weinberg always had a very humorous way of doing things. He talked about, probably a fictional story he made up, an ad in the paper for the guaranteed cockroach killer.

So you sent away five bucks or whatever it was, and you got back two blocks and an instruction sheet. One was a circular block that was larger than the other circular block, and the instruction said, "Put cockroach on smaller block, take larger block, smash on smaller block, guaranteed cockroach killer." The problem was, of course, is getting the cockroach on the block to begin with, and that's what requirements are like. Once you have some idea what the requirements are, you can proceed with TDD, you can proceed in a way, but it is an entirely different skill set and a very difficult skill set.

Tracy Bannon: It's also why I push back on some of my colleagues and friends about saying that your delivery team does it all. It does everything. They have soup to nuts from vision to fielded operations. You build it, you run it. And I'm not going to indict any of my pals, but I'm going to say that sometimes I think to myself, "No, no, no, no, no. I want to have a human factors engineer, somebody who's really good with interacting, facilitation." Sometimes that heads-down developer, coder, whatever you want to call them, him, her, it, whatever you want to call them, sometimes that's not their skill set, and that's okay. So there's room at the table for a lot of people with a lot of different kinds of capabilities. That's what's so wonderful about software engineering. That's what's so wonderful about software architecture. That's the whole thing, right? There's so much available.

The requirements piece, I do think you do need to have people who are facilitating the conversation. Whether they're technical or not, you need to have people who are able to help facilitate the conversation to start to draw those things out. Depending on what you're doing, there's some jumpstart checklist out there. If you're doing something with ERP systems, well, first of all, I apologize and feel bad for you in life, but that's a whole other conversation. But there are things that can help to jumpstart that. But it does take somebody who is really focused on listening and not jumping ahead to design. I also think, - going back to some of the basics. You do have to understand what the business or the mission is.

If we go back to requirements analysis, if we go back to what we learned in college, that still rings true. You start with what the business or mission context is. What are those imperatives and objectives? Those come forward into the highest level of requirements. It has to be able ... This is the big vision, and that kind of hierarchical thinking still has to happen. That's the problem though with some of these interesting concepts that say we're not having architects anymore. We're not having this big upfront design. Stop, stop. Let's think somebody ultimately is paying for this thing to be built. Somebody somewhere has a vision on what they want it to be. There are humans who will eventually be using it. It needs to meet those business or mission needs. It has to start with that.

Michael Stiefel: Even Steve Jobs had an idea in mind.

Tracy Bannon: Yes.

Michael Stiefel: So what you're saying seems to say that it's a skill set where somebody has to understand the business language, somebody has to understand technology. Because very often people, and I've seen this phenomenon both at the macro and micro level, that people think that just because it's easy to express in English, it's easy to program, and conversely sometimes because it's hard to express in English, it's hard to program. There's somebody who has to understand both these things in order to facilitate that conversation.

Tracy Bannon: I think that's a really good point, and I think it's not only architects that do that, but I do think that that is one of the things that I look for in an architect, is the ability to understand. One of the things that I like about being an architect, that I love about being an architect, is actually parachuting into a new domain space, someplace I've never been before, and finding the smart person who understands that domain, and learning and getting smart and having them at my right, and having whoever is the deepest technologist that I know in this space already on the left and the right of me helping to guide this forward. That to me is the beauty of architecture. It is that collaboration and getting to that cognitive diversity at the table to make this happen.

Michael Stiefel: I think actually just to sort of close this loop about requirements is to give it a very concrete example that people may not think of, is that people think when they get requirements, they like to ask questions, especially leading questions. Do you want X or do you want Y? And the problem with that is, that leads people in the direction that they may not want to go. So even in the idea of people who think, "Oh, I know how to ask questions," there's a skill in asking appropriately, open-minded, but yet restricted types of questions, just to give a simple example of a skill that a lot of people don't have that you need to find requirements.

Tracy Bannon: This is why one of the reasons that I love the concepts of persona-based design of journey maps.

Michael Stiefel: Yes, yes.

Tracy Bannon: Some people would, "Oh, that's a touchy-feely." Oh gosh, no. I know that in my lifetime where we didn't have that, when we didn't have somebody concerned about the human, we made some really ugly stuff that was really effectively efficient to how we wanted to code those things. But understanding how people do live their lives, and when we start to look at it and apply that human lens, what a difference it makes. As much as all of our engineers are engineers, as much as all of our developers are developers, all of our technologists need to at least have some basics in these ways of thinking and at least being exposed to it. They might not be good at it, they might not be great at it, they might not want to do it, they might have to be buddied up with somebody else. That's okay. But it is a part of that design.

Michael Stiefel: You also have to think out of the box, because one of my favorite examples of this happened I think in the 1960s. Scientific American, for those who remember that magazine, had a problem that they had all kinds of subscriptions and mail coming in and requests, and they were overwhelmed. So they wanted to develop a software program to help them sort through all this. And then some genius thought of, "You don't need a software program, just have separate post office boxes for each one of the requests and you've solved your sorting problem."

Tracy Bannon: I suppose there's some truth to that, but then that would go back to how scalable does the design need to be.

Michael Stiefel: Well, in this case, it was scalable enough because in those days, the post office could scale, but that's actually a very interesting point that you bring up. But how scalable your design is?

Tracy Bannon: Right.

Michael Stiefel: What's more is, you don't always know what the scalability is going to be. I have something that I call the Wall Street Journal effect. Suppose you have a nice little chocolate shop, let's say in Switzerland, selling chocolates on the website, and then one day you get mentioned in the Wall Street Journal as having the best chocolate in the world. Well, all of a sudden you thought you had this small little website and now you just can't scale.

Tracy Bannon: This was just in the news, that I believe it was Tesla had canceled an order for pies from this little bakery, and I don't remember what the name of the bakery was. It was like Charity Pies. It was something cute and wonderful. But it was for something like 3,000 of these personal pies. So the woman didn't really complain, but she said, "These guys canceled the order." Well, two things happened, exactly to your point. Mr. Musk or someone on his staff said, "No, we will pay you for those." The news of this got out, and so many people were touched by the idea that a small business was having a problem, that now you can't get one of those. They can't scale to the demand. They're turning down orders because it wasn't supposed to get that big that fast. So yes, that's a really great example.

Software Architecture as Risk Mitigation [21:04]

Gosh, when I talk to folks about their design choices, when we are making design choices, not just theirs but mine, you do have to be thinking about the possibility of forecasting. If you are making decisions, sometimes I make these decisions that we're going to take on this tech debt. We're doing it this way right now and this is what it's going to cost us to change this in the future. Here's what we're going to have to go through, but this will work. This will meet all of our needs and it will scale this far. And that's as far as we anticipate. That's what your business forecasts are forecasting. It's okay, but that comes back to trade-off, right? It comes back to understanding and surfacing, not going in blindly.

Michael Stiefel: Correct. What I like about what you're saying is, what bothers me is when people make implicit assumptions and don't make them explicit. So somebody can't come and say to you, "Well, you didn't think of this." No, we did think of it, but we understood at the time this is all we could do. And I think that's an excellent point because this is where people start to criticize the big upfront design and what have you. Some it's just an exercise about thinking about possibilities.

Tracy Bannon: I wish we could get rid of that. What do they call it? Big upfront design? Somebody has some acronym for it. I can't remember what it is. So no upfront design is experimentation. No upfront design ... So I had a debate. I can't remember, maybe it was with Thomas Sweet. It doesn't matter. The debate was about emergent versus evolutionary design. And I constantly push back on this emergent concept because the majority of folks are not trying to discover something new. They're not in their discovery spike. Emergent architecture is beautiful when you are truly experimenting to see the art of the possible, yes, I said art, the art of the possible, what are the capabilities? But when I'm turning and I'm looking to operationalize that, we're making some decisions upfront. Right?

Michael Stiefel: Right.

Tracy Bannon: What is part of architecture? Again, not to quote Grady Booch, but to quote the Grady Booch, or as my husband would say, the Boochie-Woochie, because I have quoted him a couple of times, "The decisions that you make upfront are the ones that," and this is paraphrasing, "the ones that are too expensive and you cannot change later."

Michael Stiefel: Right.

Tracy Bannon: That's okay. That doesn't mean that you just emergent let it happen. I've run into actual aggression, aggression with teams that are upset with me when I said, "No, we need to make these decisions upfront." No, we don't. Those are ours to make. This will emerge. No, no, that's not yours to make. This is where it gets really dicey with today's software ecosystem. We don't talk about autonomy in the right way. Decision, autonomy, go back in our way back machine.

Michael Stiefel): Yes, Sherman, where are we going?

Tracy Bannon: Thank you for referencing that. So if we go in the way back-

Michael Stiefel: I could be naughty. Where are we going today?

Tracy Bannon: That's right. Oh, my gosh, I just showed my age too. All of this makeup just to hide the age, and there you just let me have me out. So go into the way back machine, when we talk about autonomy, it's often like talking about variable scope. So where are you scoping your variable to? Is it scoped within a function? Is it scoped with at a class level?

Michael Stiefel: Is it a global variable? Right?

Tracy Bannon: Whoop, whoop, warning, warning.

Michael Stiefel: Don't you know that global variables cause cancer in a hundred percent of the laboratory rats?

Tracy Bannon: I like that. I like that. Well, it's the same thing with autonomy. There are scopes of autonomy. Every team doesn't get complete and total autonomy. And what we're not doing is, we're not having that grown up discussion about what autonomy do you get as a delivery team, what are the rights and responsibilities, and where are the limitations to those design decisions? This is where people really get angry at those architects. Especially if you use the term enterprise architect, people literally throw stones and tomatoes. They will puncture your car and key the door, your car wheels. Because there's this false sense that with agility, we all get complete and total autonomy and I get to decide what tools.

I went to a software factory. We'll come back to that term. I went to a software factory, and I found two teams that were within a stone's throw, literally peek up over the half height cubies and you could see them. They had decided on two different technologies for the front end: React and View. Why? Why? Well, because each of our teams decided that that's what we wanted to work with. It made us more comfortable and confident. Do you realize that you're going to be deploying onto the same infrastructure? And your small teams, as part of a slightly larger pool, I appreciate that you wanted to experiment, but should we have those two languages? Tell me why you picked them. They couldn't justify why they had opted to have two different things in this same small space.

Michael Stiefel: Maybe some just read a magazine article the day before.

Tracy Bannon: Well, that's exactly what it was, but it takes me back to something that you kind of triggered me earlier, but you didn't know it. One of the things that drives me crazy is the common sensicality of writing things down. And I'm not talking about these TOGAF, DODAF. I'm not talking about that. But I'm talking about when you make a decision, write it down, make an architectural decision record. It can be itty bitty, itty bitty. But just Tracy made this decision today. Context, we don't have a license for that and it's going to take eight months to get the new license or acquisition or whatever else. This is why that decision was made. Or sometimes the decision is made outside your sphere of influence. It came from four-star mucky-muck.

Michael Stiefel: It may be stupid, but you got to do it.

Tracy Bannon: Just write it down.

Michael Stiefel: I think what you're also saying, tell me if I'm putting words in your mouth or not, but it seems that what's missing from a lot of people's understanding is risk and probability. So in other words, those decisions you have to make upfront deal with the unknowns and the high risk. If you think of software, I think Barry Boehm came up with this idea, that you view software development as trying to minimize the risk of failure as you progress. And that's what you're trying to do. So what you do upfront is the things that have the highest probability of derailing the project and you have autonomy in the small probability things.

Tracy Bannon: Yes. I think it's a really good way to put it. I've often described architecture to folks as risk mitigation. I'm always ... My day consists of trade-offs, every day all the time. And at the bottom of that, what is that trade-off? Yes, there's an element of risk to all of this, and I'm helping people understand if we're balancing things. We don't put everything and saying, "You get security, but you don't get performance." No, we're balancing those off, right?

When we're trading off on the ilities and figuring these things out, what are our tactics that we're going to use, it's risk. And I like the way that you phrased it. So how do we help the next gen? Assuming there will be a next gen. We'll see what happens with AI. That's another conversation for another day, But how do we help them to understand that trade-off analysis is a good thing. Developers don't spend a hundred percent of their day writing code. That's not what a developer does. If that's what you want to do, you need to be a small shop guy all off your own, and that's fine. You go do that. But that's not what it means to build it in the context of delivering within an organization. It can be a small organization, but any organization, that's not what a developer does all day.

Michael Stiefel: The other thing that struck me about your example about the people doing the two front ends, and I'm going to use this to loop back into the conversation about developers and architects, is that they don't understand, or appear not to understand, that in the global perspective, by picking two different UI designs, you've made the programmer hiring decision harder.

In other words, one of the risk factors is to find the people to do the project. And if you pick two technologies, instead of, let's say eight people to deal with the user interface, you only have four. People get sick, people leave, technologies advance, and you have to become an expert. These are all kinds of very subtle risk factors that people who demand autonomy don't very often understand.

Architects as Mentors [31:17]

Tracy Bannon: Well, so two pieces of that. One, if they don't understand, you and I probably need to fall on our swords and take some responsibility for it because part of being an architect is being a mentor.

Michael Stiefel: Yes.

Tracy Bannon: Even if you are an architect in a big organization, you have to bring people in your wake. If you are taking on an architectural role and you're blending that with your day-to-day coding, that's fine. There's wonderful blends of these things. But ultimately, you better be mentoring those around you and helping them to understand this. So I think there's a little bit of history has hit us. As we heard Agile, the cry for Agile emergent design, we were also hit on the head many times to say we don't need enough stinking architects. I was actually told by somebody two years ago, we're laying out.

Michael Stiefel: I have a whole talk on that. We Don't Need No Stinkin’ Architects... If you go on the Infoq site, it's recorded. I did it many, many years ago.

Tracy Bannon: Well, it's coming back. It's coming to haunt us because what happened was, for a better part of a decade, better part of a decade, even longer than that, folks said, "We're not hiring that. We're just hiring software engineers, just hiring software engineers. We need engineers more than architects." We could have a debate on another day on the difference between an engineer and an architect, because I can tell you that I sit on both sides of that fence.

Michael Stiefel: Well, that's why I want to get back to this whole idea of the different skill sets between developers and architects, that you need both. And one is not the career succession path of the other and one is not the boss of the other.

Tracy Bannon: No, no. I'm a mentor, I'm a facilitator. I am an expert coming in to provide pragmatic guidance. I don't write the code day in and day out with the team. I'm not making all of the nuanced decisions that they're making day in and day out. Now, I'd like to think that I could sit there and do that. I'm going to be slower than they are at this point, because I'm not cranking that code on a daily basis, but do I still crank the code? Yes, I have to. In my opinion, this is Bannon's opinion. I've had a lot of contentious conversations with folks who say, "I'm a solution architect." Well, what technologies do you dabble with? Well, I haven’t  touched code in about 20 years.

Michael Stiefel: Your intuition has gone.

Tracy Bannon: Exactly, right. Is it Gregor Hohpe who came up with the elevator architect? I love his analogy here. It's, if you're going to be an architect and have that mindset, you need to be able to go from the boiler room to the boardroom. You need to be able to communicate, but it also means that in order to be trusted, you have to bring your chops to the table. So if I have somebody that's showing me, if I have the boxes and lines person, and that happens, tell me how this looks good.

Michael Stiefel: Don't you know architects only speak UML?

Tracy Bannon: If that, they speak. They don't even speak Vizio. They speak PowerPoint.

Michael Stiefel: Yes. Well, don't you know there's a compiler now to go from PowerPoint to code?

Tracy Bannon: We will see some pretty incredible stuff on the horizon that will be able to take some version of intermediate language diagrams and turn it into code. But-

I have a bias on that, but another discussion for another time. Before we move on to the questions that I like to ask all my architects, is there anything else that you want to bring up, that thoughts occur to you about the SDLC pipeline, or anything that really bothers you on a day-to-day basis?

Software Development Lifecycle [35:05]

Tracy Bannon: Let's see. There are probably quite a number of different things that are frustrating. I think lack of taxonomy is probably one of the killers in any organization. You and I don't agree on what that word means. And with that comes so much nuance and with that comes muscle memory and process issues. That's something that just drives me crazy on a daily basis.

The other thing is probably around people. When they talk about DevOps and DevSecOps, there's a big divide over what that really means. Is it from code commit across an automated pipeline into production? Or does it include, does it go back to vision? Does it include design? Does it include all the other aspects? I would say that if we're elevating our conversation, that DevOps is a set of principles that is under the big umbrella of digital engineering, and we need to start speaking at that broader level and understand the flow of value. So I am a real junkie when it comes to people talking about how processes don't work. Well, let's have an hour conversation. Let's map out how it's actually working. I'm not talking about Lean Six Sigma values. I'm talking about, let's find the waste.

Michael Stiefel: Or let's look at our particular problem and figure out what the appropriate, using some of these ideas from other places, what makes sense here. But you also said something that I just want to expand a little bit on because it has to do with architectures. One of the constraints on architecting a system is to make something deliverable. In other words, you want to think about ... Even if you don't design what we used to call a big ball of mud, if you want to make incremental improvements, you have to think about how to partition the architecture in a way that it's incrementally improvable. What made me think about this is, when you talk about DevOps is a system of principles that you have to translate into a particular context and a particular situation.

Tracy Bannon: Oh, absolutely. I don't know how many groups I've gone into and they said, "But yes, we want to do DevOps." Okay, you want to do DevOps, and they have the proverbial monolith. Well, you can't put a steel girder through a wood chipper. So we have to talk about, what are you trying to accomplish from this? Oh, we want to go fast. Well, let's talk about that. Or do you need to improve quality? Well, okay, is it Greenfield or is it Brownfield? Or is it like, I like to say Olive because it's, I've got an existing system, but I'm trying to bolt on and integrate some new things. One of the things that I would have people to  take away is the need to constantly be considering how you can decouple or loosely couple things, because that aids in the longevity. If you think about even electronics and things that you bought in your house, the big integrated front of your dishwasher, I now have to replace the entire dishwasher. When it used to be that I just had a more analog lever, that worked because they've been too tightly coupled.

Michael Stiefel: Well, because it's a dishwasher example. But anyway, we bought some new appliances. Anyway, but you also raise another concept, which is something that for another time to explore in depth but I think it's worth mentioning: the difference between loose and essential coupling.

Because there is some essential coupling that you have to have an application, because otherwise you have no application. But how to determine what is essential coupling that you want to have and the inessential coupling that you want to avoid? And that is a skill in and of itself.

Tracy Bannon: Well, so let's say some things that really get people riled up.

Michael Stiefel: Okay.

Tracy Bannon: So containers are not the answer to everything. They might hang up, they might turn off this podcast at that point.

Michael Stiefel: Well, we're 40 minutes in so it's too late.

Tracy Bannon: Okay, that's too late now. The containers are not the answer to everything. And there are times where coupling isn't essential. When we think about some of the decisions that we need to make from a trade-off perspective, if I'm not talking about a business system where I want to constantly be making changes, I'm talking about a weapons system and I'm talking about embedded software, it's a whole different thing. Oh, there's a whole another story.. We could have an entire podcast just talking about archetype.

Michael Stiefel: Yes. Well, maybe sometimes.

Tracy Bannon: Who knows?

Michael Stiefel: The other thing that struck me when you were speaking about skill sets and DevOps is the fact that the world looks different from the point of view of a human factors engineer and from the point of view of a back end developer, because the back end developer says, "Oh, we have, let's say the API, we've solved the problem. Who needs these damn humans? They only get in the way." And then the front end people of an entirely different skill set say, "This API doesn't correspond to the way how people actually work." And there's very often a big disconnect between those two points of view.

Tracy Bannon: Another entire session should be spent talking about front end developers versus back end developers versus the full stack.

Michael Stiefel: Yes.

Tracy Bannon: If you come at me and tell me that you're full stack, I know exactly how old you are. Because back in my day, full stack meant you are actually worth your salt. It means you understood the technology within your ecosystem, but that's a conversation for another day.

Michael Stiefel: So we have a whole list of future podcasts.

Tracy Bannon: Oh, my gosh. Well, you can take them. You can take them and bring other folks in and have wonderful conversations.

Michael Stiefel: Or maybe I'll have you and somebody else on the same podcast and watch the smoke come out of the computer console.

Tracy Bannon: There you go.

The Architect’s Questionnaire [41:13]

Michael Stiefel: So anyway, I've asked you a couple of questions about being an architect in general, and now I like to get a little more personal and ask you what I like to call the architect's questionnaire, which I like to ask everybody who appears on the podcast.

What is your favorite part of being an architect?

What is your favorite part of being an architect?

Tracy Bannon: For me, it is absolutely that parachuting in that I talked about earlier. I love to parachute in, get situational awareness, and just try to figure things out. I get really jazzed with that.

What is your least favorite part of being an architect? [41:47]

Michael Stiefel: What is your least favorite part of being an architect?

Tracy Bannon: Oh, gosh. Being called into a dumpster fire when people are aggressive and knowing that I can help them if they settle down. 

Is there anything creative, spiritual, or emotional about architecture or being an architect? [41:59]

Michael Stiefel:  Is there anything creative, spiritual, or emotional about architecture or being an architect?

Tracy Bannon: I studied building architecture as well in college. My father retired from being a school superintendent and bought an architecture firm, and my brother became an architect. So it was the whole creation process for me. As much as people make fun of the analogy between building architecture and software architecture, there is a mix of form and function. There's a mix of that. And I just love that my mother was an art teacher, my dad was ... So I had the left brain and the right brain. So for me, architecture is very fulfilling because I get to be both creative and deep dive technical at the same time.

Michael Stiefel: I mean, sometimes you look at a piece of software and say, that's beautiful. It just feels right.

Tracy Bannon: It's elegant, it's simple, it's sophisticated. Yes.

So what turns you off about architecture or being an architect? [42:58]

Michael Stiefel: So what turns you off about architecture or being an architect?

Tracy Bannon: Having served in an enterprise architecture role and having had all of this baggage thrown at me because of the ivory tower effects that can happen with enterprise architecture done poorly. That's what turns me off about architecture, is when folks focus on review of other people's things as a gate, as a phase gate, and not getting involved upfront to help. If you're an enterprise architect, you need to be the urban planner and understanding everything that's going on, but you need to go out and talk to the guy who runs the subway and talk to the guy who's putting in the HVAC and talk to the guy who's running the electric power and talk to the folks who are programming the way that the streetlights change, not hang out in your room and have people come to you once every six or nine months. So I think that that would be the thing that turns me off about architecture, is that there's a genre of architecture that is really dogmatic. It's Machiavellian, just Draconian.

Michael Stiefel: In fact, when you were speaking, you reminded me of a book I once read. The title of the book was something like “How a City Looks to a Thief”. In other words, a thief looks for break-in points, entry points. It's a whole entirely different way of looking at a city than the point of view of somebody who's, as you said, runs a subway or has to-

Tracy Bannon: You're going to take a quick tangent. A quick tangent is that in order for our technologists, our developers to do a better job writing secure software, teach them how to be breakers. We also have to teach, you have to give a little bit of the security folks have to understand a little bit of the builder's mindset. So yes, there's a little bit of crossover there.

Do you have any favorite technologies that when you have the opportunity to use them, you really love it? [44:54]

Michael Stiefel: Do you have any favorite technologies that when you have the opportunity to use them, you really love it?

Tracy Bannon: Oh gosh, there's so many. Can I tell you my dirty little secret of something that I just found? People are going to laugh, but I'm going to admit it. On my personal phone, I have loaded the ChatGPT app. And I'm going to tell you this because it's such a hoot. It has the ability that you can just go speech-only with it. So you're not typing anything in. When it answers you, it actually includes the uhs and the ums, it's not in the transcript. So that's my little kitschy favorite thing, is to ask it a question so I could hear it go, "You know, uh ..." Honest to goodness, try it out, I'm not joking you. But as far as other tech, oh gosh, I deal with so many different pieces and parts. I've been looking at CodeQL and how we can leverage that for more complex code reviews. That's been something that's been fun lately. I'm doing a lot right now with AI, but I don't want to turn this into the AI conversation.

Michael Stiefel: Well, personally, I hate it when people anthropomorphize technology, but that's my bugaboo.

Tracy Bannon: Well, the first time I thought it was maybe a glitch in the wireless. I thought maybe it was ... I'm like, "No." So I tried it a couple of times, and yes, it's a thing.

So what about architecture do you love? [46:24]

Michael Stiefel: So what about architecture do you love?

Tracy Bannon: I love the puzzle. I love looking at things and trying to frame it in ways from my contextual understanding right now. But I love how it stretches me. Because man, wait, there's a whole new way to do this? Oh. So not being closed-minded, the ability to constantly learn, and I mean really learn from all kinds of different folks, different perspectives, better in different ways. My way is not always the right way. Don't let anybody hear that, but it's true. So architecture stretches me. I would say that it's that piece of it. 

What about architecture do you hate? [47:00]

Michael Stiefel:  What about architecture do you hate?

Tracy Bannon: I don't know. There are sometimes where I know the right thing to do is to make sure that something is noted down when I need to put it into a model. There are sometimes where doing the right thing is a little long in the tooth. I would say that those are the things that I hate, but I also know it's necessary. So it's like being an athlete. You know that you can take off Saturdays and have some carbs then, but during the week you're not carb loading. So I think it's kind of the same thing as there are some things that are long in the tooth that you got to do.

Michael Stiefel: You just have to do because you have to do them

Tracy Bannon: You got to do them, and it's the right thing to do.

What profession, other than being an architect, would you like to attempt? [47:45]

Michael Stiefel: What profession, other than being an architect, would you like to attempt?

Tracy Bannon: It's actually tangential. I love to help people. And one of the ways that I'm starting to do that is what you and I are doing right now, getting out there and telling stories. So it's a flavor of teaching. So I don't think I'll ever become an in-classroom educator, but I think I would do more of that. I would do more sharing. I would do more podcasting. I would do ... Whether for money or for not, it's just so enjoyable to have conversations with folks and help other people get smart through those.

Michael Stiefel: I mean, it might be interesting to do a podcast, in front of other people, let them ask questions at the end of the podcast.

Tracy Bannon: Ooh, challenge accepted.

Do you ever see yourself not being an architect anymore? [48:31]

Michael Stiefel: Do you ever see yourself not being an architect anymore?

Tracy Bannon: No, because it's so much a part of who I am, whether I'm building software or not. That was not the question, just to dissect that just a little bit. My kids, I drive them batty, but they'll ask me a question. They'll say, "We already thought about the risk, mom." Well, yes, I'm glad. So you thought about the risk, tell me about it. So I think it's a natural part of who I am. So no, I don't think I'll never not be an architect. It'll be to what degree am I practicing it based on somebody else's definition.

When a project is done, what do you like to hear from the client or team? [49:07]

Michael Stiefel: When a project is done, what do you like to hear from the client or team?

Tracy Bannon: A sincere thank you. I want to hear their delight. I want to hear something that I know that I brought value. I don't just want it to be the dollar. I don't just want it to be the throughput. There's something to be said about something, somebody looking you in the face and going, "Yes, thank you. You got it right."

Wrap-Up [49:35]

Michael Stiefel: Well, this was wonderful. Is there anything else you feel I should ask or anything else you want to bring up before we-

Tracy Bannon: I am decades old with many things to talk about and I don't have any particular platform to bring forward other than we do need to be cognizant of other people. We do need to be aware of cognitive diversity. It means something. And I'm just going to leave it at that because for me, it all comes down to cognitive diversity. I don't care. All those other platforms and other things, I'm not talking about that. I'm talking about the ability to have a conversation and to learn from that conversation. Do it, people. Talk to other people.

Michael Stiefel: Well, thank you very much. I think we have to do this again sometime, but it was wonderful, and thank you very much for being on the podcast.

Tracy Bannon: You betcha. Thank you for the invite.

Mentioned

Books

• The Mythical Man-Month by Fred Brooks
• A Burglar's Guide to the City by Geoff Manaugh
• Exploring Requirements: Quality Before Design by Donald C. Gause and Gerald M. Weinberg

Articles

• A spiral model of software development and enhancement by Barry Boehm