PostHole
Compose
Login
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.
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
- 574: Chad Michel on Software as an Engineering Discipline
- 520: John Ousterhout on A Philosophy of Software Design
- 447: Michael Perry on Immutable Architecture
- 407: Juval Löwy on Righting Software
- 396: Barry O’Reilly on Antifragile Architecture
- 331: Kevin Goldsmith on Architecture and Organizational Design
- 287: Success Skills for Architects with Neil Ford
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.
[...]