Search
Search
Ori Saporta
May 15, 2024

SE Radio 616: Ori Saporta on the Role of the Software Architect

Ori Saporta, co-founder and Systems Architect at vFunction, joins host Jeff Doolittle for a conversation about the role of the software architect. The episode begins with Ori’s thoughts on what is typically missed or overlooked regarding this role. The conversation then explores aspects of both hard and soft skills required of software architects. Other topics include the relationship of the software architect to other roles, to design and process, and to quality. The show concludes by addressing the importance of dependency management by software architects. Brought to you by IEEE Software magazine and IEEE Computer Society.

Show Notes

From IEEE Computer Society

Related SE Radio Episodes

Transcript

Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.

Jeff Doolittle 00:00:18 Welcome to Software Engineering Radio. I’m your host Jeff Doolittle. I’m excited to invite Ori Saporta as our guest on the show today for a conversation about the role of the software architect. Ori Saporta, a co-founder of vFunction and serves as its Systems Architect. Prior to founding vFunction, Ori was the Lead Systems Architect of WatchDocs until its acquisition by Blackberry where he continued to serve in the role of distinguished systems. Architect Ori has a BS in Computer Engineering and an MS in Computer Science from Tel Aviv University. Ori, welcome to the show.

Ori Saporta 00:00:52 Thank you Jeff. Thank you for having me.

Jeff Doolittle 00:00:54 The role of software architect, that’s a pretty broad area for discussion. So let’s start with something specific. What do you feel is one of the most important aspects of the role of software architect that maybe is often misunderstood or overlooked?

Ori Saporta 00:01:09 A lot of people are under the misconception that design and the role of the architect is something that happens at the beginning of an application lifecycle. And I really can’t think of a more erroneous assumption because software is a living, breathing thing and as it changes, the design must always adapt and has to go with the flow, sort of. And so the architect must always be in there within that lifecycle to help guide and make the necessary changes into the architecture and design of the system to make sure that it can adapt and over time acquiring new features, new integrations, which is really the goal of continuing to develop an application.

Jeff Doolittle 00:02:03 So are you seeing situations where companies are trying to say the architect does some design work up front and then maybe they just move to another team or they disappear?

Ori Saporta 00:02:13 I have actually also with our current, with some of our current clients where there is a group of architects and they’ll be handed down like the DOC stage of a, new feature and they design it, they maybe do a prototype, they that hit it over and they lose any control. But it’s not only a matter of control, they don’t have actually visibility into what’s happened with that. Was it a good design? , maybe it wasn’t the best design. Maybe we need to do another iteration of the design to adapt to something that we didn’t figure out in the beginning. And it’s difficult to get everything right the first time. And that’s even with the first iteration of an implementation. And of course, things change over time and a new feature might influence an older design because it’s the right way to, it was the right way to go before and isn’t necessarily the right way to go now.

Jeff Doolittle 00:03:10 So what are the consequences when you see this happening on projects when somebody just does some design and then they sort of disappear, they’re no longer available. What is the impact on the software project that you see?

Ori Saporta 00:03:21 So I can think of the impact from two directions. One would be the software itself. I think the software becomes less organized, possibly more complex. We could talk about acquiring technical debt. I think those are all kind of synonyms, right? Complex software, software, technical debt. And from the point of view of the architect and the architect now is moving on to the next thing. Now they’re doing a new POC and I think they’re lacking that sense of accountability that you can take pride in your design and see it come to fruition and then make sure that it changes over time as is required. And you have difficulty doing that when you’re not in that flow of changes.

Jeff Doolittle 00:04:17 Do you run into architects that maybe don’t want that accountability perhaps? Is that possibly part of the problem?

Ori Saporta 00:04:24 I’m sure there are. I’m sure these exist. I have to say I don’t think that’s the problem. I mean, nobody starts as being an architect. We’re not in the construction business. So I think architects are developers and they’re developers that actually were looking for more accountability and looking to have more of a say in how things work. And they have inquisitive minds. They want to solve problems. And then when they get removed from the situation, I don’t think, I think they may do it, they say, okay, cool, I have a new problem to solve. I don’t think they necessarily want that to be the case.

Jeff Doolittle 00:05:06 Right. So what’s the cause then? Because I’ve seen this too and I imagine many of our listeners have seen this as well and maybe not every company functions this way and we’re certainly trying not to where I work, but what do you see as the cause of this? Architects do some design and POCs, they do some exploratory work and then they move on. Like where’s that coming from?

Ori Saporta 00:05:26 I have some recollection of it being different in the waterfall era.

Jeff Doolittle 00:05:31 Oh, you said the ìwî word. Okay, interesting. Well, yeah, so share your recollection because that’s kind of a straw man that often gets stood up and beat up, but okay, so it was different then.

Ori Saporta 00:05:42 I’m not saying I miss it.

Jeff Doolittle 00:05:44 . Okay.

Ori Saporta 00:05:45 But it was different because it was very clear what was the architect or system engineer’s role. So you had this period of time where you were the king. You’re like, okay, we’re done with requirements, now we’re in design phase. And you work in the design and you work with others on the design and at the end, like you hand the stick over to the implementation team, but then you keep working on the now, now you’re in the next cadence, right, next version. But you are already in the next version and you’re following through on the implementation and next version of the same software and over time with what is called Agile, although I’m not sure it’s called Agile for a good reason. What happened is we kind of may design something that is nice to have as opposed to a very big must in the process. And since it’s nice to have, then I don’t have to involve the architect or even the design know-how at every point of the process I invoke my own design, know-how right as a developer, as a team lead, I own everything as a team lead and it’s my responsibility, it’s nobody else’s. And then there’s the architect, he’s kind of a consultant now I like to think of it in a mob family, in the Godfather, the movies, there’s Conciliary.

Jeff Doolittle 00:07:17 Yes, .

Ori Saporta 00:07:18 He’s kind of, he’s sitting there next to the boss and he’s whispering in his ear. So okay, that’s the architect’s role, but then he doesn’t do any of the damage.

Jeff Doolittle 00:07:27 Interesting.

Ori Saporta 00:07:30 Maybe it’s a bit of a violent, but I’m thinking about movies, right? Not real.

Jeff Doolittle 00:07:36 Well back to Waterfall and Agile. So, first off, and we don’t want to go into this because isn’t the conversation about Waterfall, but it that this is one of those things too where people who didn’t experience it maybe have some false assumptions about how it actually worked. So were there shops who did all their design upfront and well, all the requirements, all the design, you were never allowed to touch it. There were some, that’s not what most people did. And we’ve gone full circle now as you’re describing Agile and of course there’s some questions about is Agile really giving us agility? Which is something we can talk about. But it reminds me of the phrase big design upfront, which is what people think waterfall was. And then it sounds like what you’re saying, the far extremists, no design upfront.

Ori Saporta 00:08:15 Or no design at all or no design ever.

Jeff Doolittle 00:08:17 Oh okay. Okay. So how do we strike the balance there between these things? Well first make a case for design. Why do we need design?

Ori Saporta 00:08:28 We need to plan and we need to give thought into what we’re doing.

Jeff Doolittle 00:08:32 We need to think, okay, that’s good ,

Ori Saporta 00:08:34 We need to think. You can call it whatever you like, right? We can call it design, but we can call it just stopping to smell the roses or just know if we go from this feature and certain components interact with each other and how they affect each other, how the new feature I’m going to write is going to affect the previous features I’ve written and the future features that I haven’t even thought about yet. We have to think about that. If we don’t, what happens is that when we get to the new next feature, we don’t know where to start and/or we just break everything all the time because we were never given anything, any thought. So there’s no like specific design methodology. I’m going to say we have to do this other than that. But you have to stop and think and plan.

Jeff Doolittle 00:09:32 I mean you don’t have to, but how’s that working for you, ?

Ori Saporta 00:09:36 I’m sure some people will say I’ve never planned and that everything is perfect. But I would think that these people are very unique individuals, and we can’t all be like that. Some people are that good, I accept that, but we’re not all like that.

Jeff Doolittle 00:09:52 Or maybe they’re just that lucky. So it sounds like your contention then is that design is an ongoing task, not a task we just do upfront and it’s not a task that we just don’t do at all. It’s an ongoing process.

Ori Saporta 00:10:09 Yes, absolutely.

Jeff Doolittle 00:10:10 And that it’s the role of the software architect to either own this process, participate in this process, what?

Ori Saporta 00:10:18 I think they own it but not own it in the sense that they’re definitely not the only ones doing it. It’s important every day. It does design. It’s important because that sense of ownership, we also want every developer to feel ownership on what they did. Otherwise they’re basically gen AI and nobody wants that. We have, and now we even have Gen AI, right? I would’ve said that two years ago without having Gen AI said they’re like robots. But now we actually have robots writing code. Nobody wants developers to be robots. They want to have ownership into what they did. And ownership comes from the ability to make decisions. Can’t have ownership if they’re just following a script.

Jeff Doolittle 00:10:59 So let’s talk about the path that most people follow to architect and then I want to explore a little bit about your path, which I understand is a little bit different. In your experience, where do most software architect or people with the title software architect. What’s the typical career path that leads them to that position in a company? And maybe if there’s any benefits to it and maybe any challenges or problems with how it typically comes about from your perspective?

Ori Saporta 00:11:27 I mostly think about software architects as individual contributors. When you start as a developer in corporation organization or just in your professional life, you start at the bottom. I think we all start at the bottom and we’re just programmers, developers, engineers. And we learn the craft and as we do, we get hopefully better at it. And then your career path either going being a better individual contributor or being a manager. And so people who have chosen to be individual contributors then have a decision to make. They can become very specialized in some methodology or some technology or they can become very good backend developers and very quick. Or they see themselves as people taking a bit of a bird’s eye view and then they would be drawn into software architecture more. So once we identify that as individuals, we would like to start to pursue that. We start reading stuff and then eventually go up to somebody and say, hey, I want the role of the software architect and voila, hopefully you get it just by asking, what it took me a couple of times.

Jeff Doolittle 00:12:45 So you reached this point and most of what you described sounds to me like technical leadership, but is software architecture just the dev who’s been doing it longer or, I mean it’s kind of a leading question, but like distinguish a little bit in your mind. Because I think you’re saying there’s more to it than just, well I’ve been a developer for 20 years and I’ve read some things and now I suddenly am just made software architect, which may happen, but maybe there’s some problems with that too.

Ori Saporta 00:13:14 I think it’s a matter of choice of what you’re interested in because if you’re just interested in the technology then it wouldn’t appeal to you or it shouldn’t appeal to you. I would say you should be interested in the machinations of a system and complex systems and it really comes down to what do you care about? What is your passion? My passion was to see how everything works together and to help drive integrations between components and systems and people and third-party software and first party software and everything coming together. And to be able to give feedback to the product and break down product requirements and all of that is not something that comes with being a good developer, but I think it is a baseline. You have to be a good developer, but you have to have the passion for that system engineering way of thinking, the architecture way of thinking. Like you should be able to go from 30,000 feet to ground level and if you don’t, I’m not sure that’s the role for you, you should want to.

Jeff Doolittle 00:14:34 Yeah. So basically the architect has a more comprehensive view of how things fit together, how things can integrate, how they should integrate at a high level. They need to understand the technology, but then they also need to have the bigger picture. That’s a broad summary, but is that effectively the general concept that you’re describing?

Ori Saporta 00:14:53 Yeah, I think we’re getting a bit into what is the role and what’s it made of. I think architects eventually are decision makers and they’re decision makers. You can say that everybody’s a decision maker and it’s the, just a matter of what type of decisions they make. But their decision makers on the level of solving problems, they’re presented with a problem by someone who is usually less technical than they are and they need to break down that problem. And breaking down that problem is into some sort of technical language. I think we’re familiar with that. How and what kind of recursion, right? Cascading waterfall of how and what. So I would think of the software architect as the first person that hears the how, which is the what? Sorry, that’s not technical and breaks down into a how that is technical. Then there are others who hear the what as maybe less technical, but even more technical details. So the details change, but there is a switch between being on the user side, which what’s the product? And then the technical side, the architect.

Jeff Doolittle 00:16:12 Yeah. So you made a distinction there that I want to highlight for the listeners between the what and the how. And I actually talk a lot when I give talks on these topics about avoiding jumping to how, so that was interesting. You just talked about the what being the non-technical and then the how being the technical, and if I heard you right, you said the architect is the first one who takes the bridge from the non-technical. What, which of course I’m sure you’ll say they’re also involved in helping find the non-technical what and then mapping that to the technical. How is that? Did I hear that correctly?

Ori Saporta 00:16:46 Yeah, I think the architect is off the bridge. They really belong in both worlds. They really need to understand both worlds. If an architect doesn’t understand the business side of it or the product side of it, they won’t be able to ask the right questions. So they will make the jump to how. So we all, as humans, I think we have tendencies to offer the solution. So when you talk to someone, you tell them what you want them to do and not what problem you want them to solve.

Ori Saporta 00:17:18 It’s a standard thing, right? And then when I have, often conversations with product people and it’s not saying anything about them, it’s just that they would say, okay, so let’s just do 1, 2, 3 and problem solve and get, go back, wait, what is the problem we’re trying to solve? And you have to understand that problem because the solution might be completely different, might be the same, might be completely different. You won’t have any way of knowing without understanding the problem. So I think that really is the bridge.

Jeff Doolittle 00:17:50 Yeah. In a prior conversation you said something I thought was interesting, your statement was ìArchitects are the first response to productî. Can you unpack that a little bit?

Ori Saporta 00:17:59 So from that understanding comes the ability to arbitrate and mitigate product requirements and whether they’re coming from a product professional or maybe they’re coming from, customers, clients, or executives, as it often happens in a startup environment. So if you have that understanding of both sides, you can be a good arbitrator and you’ll understand both sides. You’ll say this is not exactly what you’re looking for. I know you said you want to add that feature, but I have a better proposition for you. I have another feature that I think will solve your underlying problem that you’re trying to solve. And in that sense, that buffer between developers and non-technical people, if it’s not there, then I think a lot of work becomes, I don’t know if unnecessary, but I would say definitely twisted in a sense that it is defined not by requirements and not by the problem, but by the solution.

Jeff Doolittle 00:19:18 Absolutely. In fact, solutions coupled to implementations in my experience is what makes a lot of systems struggle. Because if requirements change and your design is coupled to requirements, then every time requirements change, your design blows up. .

Ori Saporta 00:19:36 Yeah, of course requirements do change.

Jeff Doolittle 00:19:38 And that’s a good thing. That’s called job security . But we complain about it because our systems don’t know how to respond to change.

Ori Saporta 00:19:46 It’s also kind of human to respond poorly to change. Of course I say, I’ve worked on this for six months, why are you changing it now? Or this is the way we’ve always done it. Why do we need to change it? And proudly, if this is the way you’ve always done this, itís the best indication that you do need to change it.

Jeff Doolittle 00:20:06 Weíll see. And now again, this is the role of the architect too, where the architect is not just arbitrating the technical decisions, but the architect is also, and maybe mediating is maybe a better word because arbitrating sounds a little bit adversarial or facilitating maybe also, but also the personal side. So there’s an architecture role on a technical side. But talk a little bit more about like the old thing from the movie office space, right? I just, I’m the product guy, I take the requirements from the customer to the developer because I’m a people person. Notice the role that’s missing. There’s the architect. So let’s.

Ori Saporta 00:20:37 Yeah, yeah, yeah,

Jeff Doolittle 00:20:38 Let’s talk. Not that that would’ve solved the problem of the office and office space, but , what is the role of architect from the personal standpoint a little bit as far as navigating that transition from customer to requirements to development?

Ori Saporta 00:20:52 It’s a great question. Personally, I think you need the ability to make people see your point, but in a non-adversarial way.

Ori Saporta 00:21:02 If you’re adversarial, then product won’t be able to work with you and it’ll go around you and then you’re basically useless. I’m sure there are those architects who are just in it for jumping. I think you kind of alluded to that in the beginning, just like jumping from one thing to the other, they don’t really want the accountability as I said before, I don’t think that’s really the common use case.

Jeff Doolittle 00:21:30 I agree. Most architects are architects because they care.

Ori Saporta 00:21:32 Exactly. And if you care, you have to. So some people care too much at certain points in my career I’ve cared too much and I was like, I thought of myself maybe as a gatekeeper instead of a mediator. Okay. And I think what you said mediator, which is great, there’s a difference between being a gatekeeper and a mediator. I think some, I thought of myself as a gatekeeper, meaning I should keep bad requirements away. And as a mediator you don’t, I don’t think it’s your role to keep that requirement. It’s your role to help whoever made those requirements understand what are the right requirements. It’s a good way to put these requirements.

Jeff Doolittle 00:22:16 What’s brilliant about that too is if something’s a good idea, but the other person doesn’t, if you try to force it on them, they might resist. But if they’re convinced that it was their ideaÖ

Ori Saporta 00:22:26 Absolutely , I think what you really meant is that’s how you lead them to it, right? You say, I heard you, we can think about that, but I think what you really meant was, and go to the core of the issue.

Jeff Doolittle 00:22:41 Or have you thought about it this way?

Ori Saporta 00:22:43 Oh, have you thought about it this way? And let’s figure out together. Basically what we’re all saying is let’s figure out together what is the problem, but it has to be together, right? So if you are the kind of person that really doesn’t want any interaction with other people or with non-technical people, and I don’t, I’m not judging, maybe that’s not the role you need to be in.

Jeff Doolittle 00:23:07 Well, and that’s a good point. So, we started with the technical aspects, which we of course have some time to dive into a little bit more and I want to, on the technical side, but now we’re kind of talking more about the personal side, which you could say is the soft skills side, right? There’s the hard skills of being an architect, the technical and the design skills. Then there’s the soft skills side, the process, and the people skills. And so, we talk about the path of an architect, and you mentioned it before, right? They tend to be the developer who maybe wants a broader perspective or the engineer who sees the bigger picture and they want to like lean into that a little bit. But none of that has given you soft skills training. So in your experience, where did you and where are successful architects getting, by the way soft skills are not hard . Yeah. Right. So where are they getting that experience to be successful on the peoples and process side of things? Because they’re often not trained in that, in my experience at least maybe yours is different.

Ori Saporta 00:24:02 I have mentioned it on our previous conversation is that I came in without the hard skills.

Jeff Doolittle 00:24:08 You came in without the hard skills.

Ori Saporta 00:24:10 Yes. I came in without the hard skills. I came in with the soft skills and I was learning on the go learning the technical side of it on the go. I was always interested in technology, but I started actually as a system architect, system engineer. Having come from the product side, from the business side of things. And I was a caring and a passionate user and I was interested in technology and that made me a good candidate to be that bridge and come the soft skills come from first they come from caring. So if we’re talking about a specific domain, a specific business domain, then it may be something that you’re really passionate about and you’ve experienced it as a user and then you are able to explain your passion and to talk to your passion with others. And you can talk to your passion with others that are technical and others that are nontechnical. And when you do, they both understand because you’ve given a lot of thought yourself. And then I think I’m the wrong person to ask how to be a people person. I’m not sure I have a people person, but it’s about knowing that that’s definitely something you need, right? If you understand that you need to be that person that everybody comes to from the technical side and from the non-technical side. And if you want to be that person, you’ll be that person.

Jeff Doolittle 00:25:45 Yeah. And I guess part of the challenge here is you and I both came at this from the, and maybe soft skills isn’t the only part of, but from the business side and then the technical came later. So that could be, that’s true for me as well. But we both know a lot of software architects as well. And I’m curious about your experience. In my experience that’s the less common route. The more common route that I tend to see is people come up through the technical side and then they have to shore up or learn the soft skills. Is that true for you as well most of the time?

Ori Saporta 00:26:12 Yeah, absolutely. And they often struggle with that.

Jeff Doolittle 00:26:16 There you go. So now let’s talk about that a little bit because, I’m sure you spend a lot of time mentoring, I do as well. So what do you do or what do you think a software architect needs to do and can do to shore up that side of their ability to facilitate the interaction between the business side and the technical side?

Ori Saporta 00:26:36 I think often the first thing they need is confidence. Because if you’re used to being part of a larger team and you’re an individual contributor, but you are within a very well-defined boundaries, and then as an architect, those boundaries kind of fade away and you talk to a lot more people and then if you are not confident, you might get overwhelmed and then you might get pushed back down into where you feel comfortable, where you feel comfortable might be just writing code and you won’t be providing that service of being that bridge to discuss being that mediator. So I spent time with, when I’m mentoring, is building conferencing, just this, both sides, you’ve been at this long enough and you care about it enough and have enough passion about it to be able to talk about the subject with anyone. And with that confidence, the shyness or the apprehension fades away. I think that confidence really is key.

Jeff Doolittle 00:27:47 And by the way, the psychology tells us one of the best ways to build confidence is to act confident because you get the feedback loop. Because when you act confident, people perceive you as confident and then you perceive them perceiving you as confident, then you become confident. Of course the opposite is true. If you don’t appear confident, people perceive you as not confident, you perceive that they perceive you as not confident and then you’re not confident.

Ori Saporta 00:28:09 And then you withdraw.

Jeff Doolittle 00:28:10 Yeah. And that’s a simplistic way of looking at it, but that’s part of the equation. So building confidence, but what else? Because there are those occasional architects too who are incredibly confident and they’re really good at like beating people down with their strong technical opinions. So, and I know you’re not saying that and let’s not really go too much there, but I just want to tell listeners that’s not what we’re saying. You’re not saying be confident like that person, you’re saying reasonable confidence in somebody who the confidence will benefit them and it’ll benefit others. Not because they’re trying to browbeat people, but because they do have good contributions to make. And if they’re not confident, then they’re not going to be able to participate.

Ori Saporta 00:28:45 I don’t want to get too deep into psychology because I’m not a professional, but I don’t consider these people actually confident people who need to browbeat because it doesn’t come from a place of confidence.

Jeff Doolittle 00:28:57 Yeah. Like bullies are actually afraid a lot of times, right?

Ori Saporta 00:29:01 Yeah, I think so. I mean it takes a lot more confidence and self-assurance to listen than to yell at others and force your opinion than others.

Jeff Doolittle 00:29:11 That’s what I was looking for. Exactly. That’s a great summary of that. So let’s move off of confidence for a minute. What else? Like, so I have confidence that’s like an attribute, but are there any specific skills from a soft skills side that you find that software architects benefit from when they have these particular kinds of skills? From the personal and the process side? The people side.

Ori Saporta 00:29:33 I just kind of touched on that without even noticing anything. You have to be a good listener because you need to listen to the problems people bring. I think people come to the architect from both sides, as we said before, people from the technical side, people from the business side. And then you have to listen to all of them because you don’t know the questions or the answers better than anyone, you might be the best at translating them. That would be another skill. So the ability to translate between technical and non-technical and translate between people. I’ve often been in that scenario where I have a non-technical person and a developer on a call, and they really don’t understand each other and they’re both good people. But you have to listen, you have to understand that they’re not understanding each other, and you have to be the mediator and speak a common language. And speaking common language is very difficult, soft skill to master. I’m not sure anybody ever master it all the way because it changes based on your business, if you switch from one business to the other. But there are some commonalities. And I think the one thing that you notice regardless of what business you’re in is that two other people are not speaking the same language. And once you do, that’s the first step into getting them to speak the same language.

Jeff Doolittle 00:31:06 Or at least you translating between them so that they can.

Ori Saporta 00:31:10 Yeah that’s fine, that’s fine. Hopefully you don’t have to translate everything. You can facilitate it; you can start the conversation and then they will understand each other.

Jeff Doolittle 00:31:20 Well, and it’s tough too because you point out, if you notice they don’t understand each other, the reality is they may think they understand each other and then you have to show them that they don’t .

Ori Saporta 00:31:30 Oh yeah and you have to do it gently.

Jeff Doolittle 00:31:32 Yes.

Ori Saporta 00:31:33 You have to make them see it without spelling it out because then people become uncomfortable and then they become withdrawn and then they feel misunderstood and people don’t like feeling misunderstood.

Jeff Doolittle 00:31:45 That’s true. Switching gears a little bit, I feel like we’re getting a broad picture. There are some soft skills, there’s some hard skills, technical people skills, these kinds of things for a software architect. But give us just briefly a broad picture of what does a successful software architect look like? And then let’s talk about what are the challenges that keep architects from feeling like they’re able to have that consistent success in their role? What’s maybe holding them back either in themselves or in the systems that they’re working in.

Ori Saporta 00:32:18 If we assume that the architect in question is the type of architect that does want to take accountability over software design throughout the lifecycle of an application, then a successful architect would be one that can maintain a vision of what architecture should be and what design should be and influence how it is done over time.

Jeff Doolittle 00:32:46 So the design vision is consistent over time.

Ori Saporta 00:32:50 Oh, consistent sounds kind of strict. Like it shouldn’t change. It can change, it should adapt, but it should be done through the architect’s eyes from top down and not from bottom up.

Jeff Doolittle 00:33:02 So maybe it’s the design vision is consistently curated over time.

Ori Saporta 00:33:08 Oh yeah, I like that.

Jeff Doolittle 00:33:09 Okay, I like that. Okay. So a successful architect is able to consistently curate the design and the design vision over the lifecycle of the project.

Ori Saporta 00:33:18 Even more than that, I think what I would be liked to be measured on as an architect is my ability through that design, through that vision to facilitate software development, to facilitate, to enable the creations of new features, new integrations and the right ones, right? Not just new for the sake of new but the right features and integrations.

Jeff Doolittle 00:33:42 Okay, so let’s try this. So a successful software architect helps developers successfully deliver on the actual requirements. Something like that maybe.

Ori Saporta 00:33:55 Yeah, that’s good. On the requirements that are based on the root problems, the core issues we’re trying to resolve,

Jeff Doolittle 00:34:02 Right. Real requirements.

Ori Saporta 00:34:03 Real requirements.

Jeff Doolittle 00:34:04 Yeah. Yes. Okay. So that’s a successful software architect and I love that because we help make everybody better, right? We help the developers be better, we help the product be better, we help them solve the problems, we understand the real problems and we provide real solutions that solve the actual real problem. Great. What’s holding us back? ?

Ori Saporta 00:34:24 Well, I think there are things holding us back on multiple levels. There’s the organizational level that sometimes it looks like the design phase or the lack of is a good thing. We don’t need, it’s just we are spending time on design. Why are we spending time on design? We should just go and write solutions.

Jeff Doolittle 00:34:46 Start iterating .

Ori Saporta 00:34:48 Yeah, and I get Dilbert in my head, right? We all know the Dilbert type manager. And I’m not saying that all executives are like that. Absolutely not. I’ve worked with amazing executives, I actually never worked with executive like that, but it’s still kind of their job saying, let’s get this done as fast as we can. And you need to understand as an architect and convince others that as fast as we can, at least over time does mean with good design and the proper amount of time spent on. And that’s a difficult thing to do. It’s difficult to, as they say, talk truth to power. And its difficult people that are measured on time delivery, why something could take 10% or 15% longer now, but over time, even if everything takes 15% longer, it won’t get delayed a 100% in the next iteration, right?

Ori Saporta 00:35:57 We won’t get stuck because we didn’t think it over, we didn’t plan ahead. So that’s a real difficult task and I think that’s one reason why architects are struggling. Another reason would be coming from the technical side is that with a lot of ownership moving down to team leaders over time, which I think is a good thing, then it became kind of contentious into who is the owner and why are you telling me what to do? And of course, in a good relationship, right, nobody is telling anybody what to do, but it’s not often the case. And so from the executive side, maybe say we don’t need this phase, it just takes time from the technical side, they might say, well I’m doing the design, you’re getting in my way. But that team lead has a very much narrower scope and they’re maybe doing good design, but on their narrow scope.

Ori Saporta 00:37:03 And then the architect, which should have the broader scope, he doesn’t have the backing from the executives and he doesn’t have the team leader going up to him saying, I need your help. And if, and neither of these things happen, then they can’t be successful. And then on top of that, the architect’s role, I think throughout at least my history has been very much tied into documentation. And I don’t mean comments in the code necessarily, but documentation generally is writing documents and drawing diagrams and then maintaining those over time. And you spend a lot of time on maintaining. I used to spend, I used to have a spreadsheet with a huge, huge database specification like S to L database, relational database specification with every public key and foreign key documented. And it would take half my time just to manage that with change requirements. And it doesn’t have the ability to impose that on the actual implementation, nor does it get updated with the actual implementation. So you’re just doing documentation kind of for your sake. And so with everything else being automated and we don’t have those tools yet, and it feels kind of a cake in some way.

Jeff Doolittle 00:38:39 It does. An analogy that comes to my mind that I use a lot is if my water heater breaks and I need to call a technician and they show up and the water heater itself doesn’t have a document attached inside it or they can’t go online and find a document for the specification, they are going to struggle to figure out how to fix this water heater because there’s no specification of how the thing is intended to work and how it does in fact work or washing machine or figure anything out. And yet with software we often just say, well just look at it . It’s like, yeah, but looking at it doesn’t tell you the intent of the purpose and the design and these kinds of things, right?

Ori Saporta 00:39:19 Right. And so we have to resolve the conflict between what we designed and what we document and what is actually happening. And we have to keep doing that all the time. And that just takes a lot of our time and often also becomes a reason for conflict. You’ll go to developers saying, wait, we designed it like this, why did you implement like that? And then there’s a lot of contention.

Jeff Doolittle 00:39:51 Well, and that’s where I think coming up from documentation for a minute, you said something before you said, how do we, you didn’t use these exact same words, but instead of quick and dirty, it was how do we do quick and clean? Like how do we maintain that consistently? And I put documentation that category of, and somebody asked what’s the right amount of documentation? I said, well there it is. It’s the answer that we can keep going quick and clean. We’re not slowing down because we don’t know what the heck we built, right? And then there’s other things you mentioned too, I think you didn’t use the word, but you’re also talking about constraints. You sort of harken to that idea of constraints. So talk a little bit about, you’re a systems engineer as well, so constraints like triggers a whole bunch of thoughts I’m sure in your mind. Talk a little bit about the software architect’s role as it pertains to constraints within the software system and the human systems around it.

Ori Saporta 00:40:39 Well, I think it’s all constraints because if there were any constraints we could all just wish a software would do something. Would magically do that.

Jeff Doolittle 00:40:49 That’d be amazing. .

Ori Saporta 00:40:50 Yeah. And even with Gen AI, we’re very far from that. I think that the constraints come in all levels. So there are constraints on the availability of engineers and the availability of the engineering knowhow. And then of course there are constraints on performance and so if you will build a very, your design, a very different application. If you have a requirement to deliver responses within a minute or a second or a millisecond. And that is often a very hard constraint because no person is an island and no software is an island. Definitely not, you’re always getting information from other softwareís and possibly producing information for others. And then you might just be getting a million bytes, a million megabytes per second, terabyte per second, a petabyte per second. Petabyte might be extended too much, but you might be getting terabytes per minute.

Ori Saporta 00:41:55 And then that’s a real constraint. There’s nothing you can’t negotiate there, you have to work with it. And then on the other side, you need to provide something to the user, but you can do that within a minute. And then you have all that time in the middle to figure out whatís the right thing to do. So these are the parameters of the problems you’re solving, the constrain of the parameters, everything is an optimization problem, right? It’s just the constraint is what you optimized. Without that, as an architect I don’t know where to start, right? Without somebody telling me the parameters of a problem, where would I start with a solution?

Jeff Doolittle 00:42:34 Absolutely. And you mentioned what you optimize for is the constraint. And for those who aren’t familiar with that phrase, that’s straight out of systems engineering. So another area that I think often holds software architects in the systems that we designed back is quality. We’ve talked about constraints, we’ve talked about some other aspects of this. But if you will speak some to how quality relates to the role of software architect in your experience.

Ori Saporta 00:42:57 Well that’s actually, it’s written right here in my notes how it’s one of the roles of the architect. I wanted to discuss because I think quality means a lot of things to a lot of people. And the word quality, you have quality assurance. And I don’t think that’s not that type of quality. You have code quality. And I actually don’t think that’s that either. I think there is an engineering quality or maybe the quality of an application, of the design of the software. It’s its own thing. And quality is the ability to understand something for it to make sense in a way that you can then continue working on it, right? If the quality isn’t there, then you don’t have anything to build on. So if you want to, if you have, imagine a brick house, you stack bricks one top the other, and if the bricks are from poor quality, at some point with some amount of weight, it will crumble and then everything goes down.

Ori Saporta 00:44:07 So quality is the basis of what you’re building up. And if the software quality is something that is through good practices, something we can achieve, right? Something we can actively work on and improve. It’s not a binary thing, it’s not a zero one, but it’s something we can always improve so that when you get started, you make the right decisions in your, also in your practices, if you, the right decision may be to make sure that everybody has a CICD that includes testing, for example, right? You might not think of, that’s not the first thing you think about as a role of an architect, but I think it really is something that the architect should care about, about how people interact with their software, right? With their, if I’m a team lead and I’m very technical person, I just want to write code and more features and more features and somebody has to tell me, wait, wait a minute, stop. Let’s make sure that the new feature you wrote didn’t break everything else. So it’s not as much a design decision, it’s a decision to make sure that there is something to build on.

Jeff Doolittle 00:45:31 It’s another design constraint. Really you’re constrained by the quality of your system and if you want to get past those constraints, you may need higher quality in some cases.

Ori Saporta 00:45:41 You have to manage quality and you have to do that. And it could be something that an engineering executive does, especially if they are passionate engineers themselves, but it might not be. And I think it’s definitely part of the role to make sure that these kind of standards and practices are met. So you have something to build on.

Jeff Doolittle 00:46:06 Yeah. And if you go back to Edward Deming, who, I’ll put some notes in the show notes about Edward Deming, who’s the father of total quality management. You mentioned quality management. And for those of you who are involved in things like lean, if you haven’t read about Edward Deming and the Toyota Miracle from the 1950s, you absolutely owe it to yourself to do that. Because while quality, as you’re saying is part of the software architect’s job, as you learn about TQM, it’s everybody’s job. It’s just an architect has a specific part and role to play in that. What other aspects of the software architect’s role did you have in mind that you want to make sure we cover in the time we have left? Anything else you wanted to highlight?

Ori Saporta 00:46:44 So maybe one thing we haven’t really discussed is being the facilitator of change and being open for change. Maybe we’ve kind of talked around it. But being open minded and making sure that you don’t just say no, it’s a very guttural response or somebody asking you something, you just say, ìNo, that’s not what it should, how it should be, or that’s not how we do itî. And I think you need to be, as an architect, if you own the design and if the design is good, it needs to be very dynamic. Static design will break. They say that the bridge that collapses is the bridge that doesn’t move with the wind? So I think that’s exactly the case. If you own the design and the design isn’t dynamic, then it’ll break. You won’t be able to build on it and you have to do that. So you need to actively seek change. You need to actively see how you can improve. If you’ve designed something a year ago and you are the owner of the design of that application, you have to revisit what the application does today. You have to revisit what the software requirements are and how they’ve changed. And the design you made a year ago, which may have been correct a year ago, it might not be the right design now.

Jeff Doolittle 00:48:13 Yeah, last year I’ll put a link in the show notes to a prior episode with Chad Michael from Don’t Panic Labs, and the title was Software as an Engineering Discipline. But in his book on the topic, he has a phrase that I really appreciate. It’s designed for change. In fact, I think I even said it earlier in the episode, so now I’m just giving credit where credit is due. And so that’s really the Holy Grail, right? Where we can design for change and we know our designs might change, but if they keep changing constantly, fundamentally in their because, it’s interesting you mentioned the bridge. Well the reason the bridge is dynamic and can stand up to the wind is because of how the bridge was designed. Yes. So it’s, it’s good design that lets you accommodate change.

Ori Saporta 00:48:53 Absolutely. It’s good design that lets you accommodate change. So you can think of the bridge analogy as both sides, the wind being the change requirements and the design being the actual design.

Jeff Doolittle 00:49:08 Yeah. Similar to buildings, right? If you want a building to stand up in an earthquake, old school thinking would’ve been, it doesn’t move. It’s immovable. And now if you, if you look at the dynamics of how buildings it can tolerate, earthquakes are, they’re extremely flexible and dynamic. It’s amazing.

Ori Saporta 00:49:24 So the design is flexible because the wind will come, if I close my eyes and close my ears and the wind won’t come.

Ori Saporta 00:49:32 It’ll come, right? It won’t help.

Jeff Doolittle 00:49:36 Bury your heads in the sand and just hope.

Ori Saporta 00:49:38 Yeah, that won’t help.

Jeff Doolittle 00:49:39 You can do that if you’re a software architect. I hope that’s not what you’re doing .

Ori Saporta 00:49:43 Exactly.

Jeff Doolittle 00:49:45 So in the time we have left, I know that you work for a company called vFunction and there are some things that your company provides that are intended to help architects be better at doing their jobs. So talk a little bit about vFunction and what you guys do to help make software architects lives better.

Ori Saporta 00:50:01 Great. So we provide architectural observability to basically provide insights into complex software. And we enable developers, engineers, and especially architects to understand the architecture of the software, enabling them to continuously manage their technical debt and modernize their application and modernize, continuously modernize the application, which is exactly what I was alluding before, to before having the design, being a living, breathing thing that needs to be updated as the application changes that requires this change.

Jeff Doolittle 00:50:39 You said something interesting as you were describing vFunction and what it provides. You’ve called it architecture observability. So since this is an audio only show and we can’t show pictures to the listeners, if you can try to paint a picture for us about what could somebody expect if they had a solution that provides them architecture observability?

Ori Saporta 00:51:00 Well, I think a lot of it goes down to dependency management and dependencies could be between classes in a software or between database tables or code and database. And then external services could be some cloud provider service. And really anything could be dependent on pretty much anything else within the software system. Complex system is a system where these dependencies are complex, right? And there may be circular and there may be some dependencies are shared very liberally throughout, well others very localized, which is often the best case, right? Localized. We like localized dependencies. Localized dependencies, hint at modularity, which is something we aspire to. And so the first thing we do is we visualize these dependencies and visualizing these dependencies with the context and the context being the domains, the business domains within a software, application within an application. And then allowing you to make decisions on which of these dependencies belong and are correct and which of these dependencies are once you really want to get rid of?

Ori Saporta 00:52:21 And then over time really showing you when new dependencies are added and any specific areas of interest, right? Because there are two aspects here. One is visualizing and then there’s prioritizing because you don’t want to get overwhelmed, you need to be prepared. So you, some input may be coming from user, user saying, I’m interested in this part of the software right now. I’m going to put effort into making it better because it’s really hurting me. I’m feeling the pain from trying to develop new features within a certain domain. So let’s focus on that. And it could be coming from the system saying, this glass is gone. It’s in God mode, right? It’s a God class. We don’t want that. It’s every time you touch anything, you need to change this glass. So we need to fix it. And so visualizing these dependencies and pointing them out to the architect and prioritizing them, that’s really what the observability is.

Jeff Doolittle 00:53:23 Identifying them, visualizing them, prioritizing them. Well, Ori, it’s been great having you on the show. Is there anything else you want to cover in the time we have left before we wrap it up?

Ori Saporta 00:53:35 No, I’d really like to thank you, Jeff. Really like spending this time with you talking about software architecture.

Jeff Doolittle 00:53:42 Yeah, it was great having you on the show. If listeners want to find out more about what you’re up to, where can they go online?

Ori Saporta 00:53:49 Well, they can go to, they can find me on LinkedIn and they can go to vFunction.com.

Jeff Doolittle 00:53:55 vFunction.com. That’s the word ìFunctionî with the ìvî in front .com. Yes. Fantastic. Well, Ori, thank you so much for being a guest on Software Engineering Radio.

Ori Saporta 00:54:04 Thank you, Jeff.

Jeff Doolittle 00:54:05 This is Jeff Doolittle, thanks for joining us. See you later.

[End of Audio]

Tagged as:
Join the discussion

More from this show

Menu

Recent posts