In this RedMonk conversation, Ori Saporta, VP of Engineering & Co-Founder of vFunction, speaks with Kate Holterhoff, senior analyst at RedMonk, about the evolving role of software architects in modern development practices. They discuss Ori’s experiences at BlackBerry, the importance of architectural observability, and the disconnect between architectural intent and implementation. Ori emphasizes the need for architects to reclaim their role in ensuring scalable and resilient systems, especially in the face of increasing complexity and the influence of AI in software development.
This RedMonk conversation is sponsored by vFunction.
Links
Transcript
Kate Holterhoff (00:12)
Hello and welcome to this Redmonk conversation. My name is Kate Holterhoff, Senior Analyst at Redmonk and with me today is Ori Saporta, VP of Engineering and co-founder of vFunction. Ori, thanks so much for joining me on the MonkCast.
Ori Saporta (00:24)
Thank you so much for having me.
Kate Holterhoff (00:26)
I am excited to have Ori join me here today to discuss his recent post, Reclaiming the Architect’s Role in the SDLC, which digs into what the folks at vFunction call architectural observability. So looking forward to digging in with you here. I just want to begin by chatting about your background. I understand that you are a systems architect at BlackBerry. How did this experience influence your thoughts on the role of the architect?
Ori Saporta (00:49)
Well, so my previous experience in my two previous positions, were BlackBerry and WatchDox, which was acquired by BlackBerry, even before that, as a systems engineer and systems architect at the Israeli army, they showed me a lot of different perspective of what an architect role could be.
In my first two positions, I was really involved in the process from start to finish. My first job was really a project-oriented job which was very waterfall, like old school waterfall base. So I had a period of…
maybe a month or two at a time of planning and designing and creating documentation and then following up on all of that during the development cycle, which was also several months at a time, development and then validation cycles. After that, at WatchDox, we were a lot more agile. We were not practicing waterfall in any way.
But still, I was heavily involved in the entire process, specifically in those first parts of a requirement coming in from the field or from product, and trying to understand the business problem, and really focusing on the what before we get to the how, which is, I think, a key issue in understanding where design work and architecture work really needs to be focused on.
That is kind of way I carved the role for myself. I was the only architect at WatchDox before it was acquired by BlackBerry. Once the acquisition happened, I joined a very large cadre of architects at BlackBerry. And we had a forum. We had a lot of other companies that were acquired at the same time being brought in together into kind of a newly formed business unit. And within that business unit, we tried to get a lot of integration done as fast as possible, which is expected from that scenario. And that time I really found a different breed of architect. It was…
a lot more focused on the early stages of planning and POC, specifically for integrations or new technologies, and then a lot less focused on following up and really bringing those plans to fruition through development. So there was a lot of disconnect, the way I experienced it at least,
The way I saw it was really being kind of a guiding force throughout the process from product requirements to validation. And I saw a lot of my peers really only focused on the first part or even not that, just doing whatever they think is cool and kind of doing prototyping for cool new technologies. And…really not even being on the same level as the people actually developing the product. And it bothered me. You can probably see that. It bothered me, made me think that…
there is a problem there because their teams needed the architect. They needed those guidelines and those definitions and that follow through and it was missing. And they themselves, I felt like they were letting themselves off the hook, right? Doing whatever is cool, whatever is sexy, but not really doing the hard work and making sure that there is follow through.
Kate Holterhoff (03:49)
I love that story. Anytime I speak to people who’ve been in the trenches and have seen how these things work in real life and not just on a whiteboard, I think it really gives an excellent perspective on the sort of challenges that folks are actually going to be encountering in the real world with a brownfield project, right?
Ori Saporta (04:22)
We had a lot of Brownfield projects, right, coming together at the same time trying to create both Greenfield projects and also that chimera of, I’m not sure what it was exactly, we were trying to do of that integration between everything. It’s not Greenfield, it’s not Brownfield, I don’t know what it was and it never happened. At least not while I was there and I don’t think it happened afterwards either.
Kate Holterhoff (04:47)
wow. All right. So let’s chat a little bit about your article here. So in your article, you suggest that the role of the architect, I guess, is in crisis. That’s the sort of the impression that I got. And in order to underscore that point, you contrast the architect’s role in the waterfall versus the agile models, what would you say is the most crucial lesson from the waterfall era that should be brought back into modern agile practices?
Ori Saporta (05:11)
That’s a great question and I don’t want it to sound like I’m advocating for Waterfall. I really am not. I am though advocating for more responsibility, accountability, ownership of the design part of the process, whatever the process may be. I think what we have seen in the past, I guess, decade and a half or so is the developers taking
Kate Holterhoff (05:16)
haha
Ori Saporta (05:34)
a larger chunk of the design work, which is not wrong in itself, but there is still a lot of high-level work to do that nobody is really doing. Because developers and engineers are often, they’re measured based on their ability to deliver and deliver fast. And without a person that is assigned that role of having that high-level view.
making sure that we play by a certain set of rules and we stick to some standards, not because they are written somewhere, because they make the application more scalable and more secure and also easier to innovate on in future iterations, right? Because we’re not in the, at least in the last 15 years, so I haven’t been in the project world. It’s not writing a piece of software
then on to the next project. We are constantly iterating over the same product and we want to deliver new features, want to deliver bug fixes, we want to do it fast. The only way to do it is keep the architecture in mind. Really just have an architecture, have an idea of how things should be.
so you can work on them that way. And that is, I feel, very much missing from the quick and dirty iterative world that a lot of people are experiencing.
Kate Holterhoff (07:01)
That all sounds reasonable to me. And I’m interested in another sort fundamental tension that you address in this article, which is between the individual contributor software developers and the architects themselves. So talk to me about where this friction comes from and what organizations can do to address it.
Ori Saporta (07:18)
Well, I believe that friction comes from several sources and of course we’re not the first to be talking about this. There have been articles written on this subject for years. The idea is that it’s a good thing everybody wants to own more of the process. They want to take more on themselves. They want to be accountable, which is definitely a good thing.
Still, different roles are required, which I just mentioned, is different roles are required because they require different point of views and all those point of views are necessary to get a good healthy application. You need the bottom up point of view, you need the top down point of view.
If you’re down in the trenches and you’re working, you’re coding all day, and you have mostly the bottom-up view, but you don’t necessarily realize that. And you won’t necessarily understand that you need someone else to give you the other context, the other point of view. And I think that is definitely where some of the friction comes from.
The other part of it, there’s definitely some ego there because when you say design, when you say architecture, those are kind of sexy words. People like say, I’m an architect and not I’m a developer. If people ask me my job, it’s always been I’m a programmer, right? So because at the end of the day, I think that’s what everybody that really writes code is, but there is definitely a…
There is a difference between a programmer, a developer, an engineer, an architect, not necessarily in their qualifications, although sometimes that is required, but in their role, in their point of view, there has to be a difference. So you put all this together, the workload, which not always allows us to see
the whole picture along with a bit of ego and the fact that we all want to say that we’re doing everything and all the best things in design and architecture and I think that is where some of that friction or that friction comes from. And what I think organization needs to do to resolve it is first of all to address it.
Right, say there are these roles and we need these roles. And here’s the reason. Because we have a very complex application. We have hundreds of thousands or millions of lines of code.
split between different teams, seven teams, eight teams. Each team is in charge of three services, four services. This is the world we’re living in. We’re not living in a world of a single kind of software that gets pushed, sent in a DVD somewhere, which is where I started from.
but we’re definitely not there anymore. And these are very complex applications and we need people to have that bird’s eye point of view. And the organizations need to be clear about that. And to make sure that it doesn’t mean that design work is purely something that an architect does. Nobody wants that because an architect can’t design, 150 services.
It’s not possible. Even a team of architects, that’s not what they are supposed to do. So it’s not about taking the interesting work away from the developers and the engineers. It is definitely about making sure that work is done within a context that is helpful to everyone in the organization. And just attacking this problem head on, think is plenty to resolve these tensions.
Kate Holterhoff (10:45)
All right, that’s really helpful. Okay, and you emphasize the importance of architectural observability, but I suspect many folks are unfamiliar with this term. How is it different from traditional observability and why is it crucial for modern software development?
Ori Saporta (11:00)
So I just touched on it just a minute ago about the complexity of modern software. And it is very complex and it is changing rapidly. And when that happens, we start seeing, like we have these documentations that we create and the week after they’re created, they’re completely irrelevant. And we have
these discussions that we have with each other and we figure out a solution to a problem and then a week later we have to tackle another problem which is almost the same but it’s slightly different. And how do we do that? So traditional observability tools are really focused on performance. They are local in their analysis both in the time dimension and in the…
place dimensions, right? So you focus, you see a performance issue, a slowdown in one service. But a root cause of that slowdown may be in a completely different service. If I had a service, a checkout service that needs to send the invoice service a message, and I see that the checkout service performance is degraded,
But I won’t necessarily see that. It’s because a change happened in the invoice service that made it slower just slightly. Because these are complex systems, slight change in one service can cause a much larger change in another service. We won’t even know that. So that is something you’ll have a hard time getting from a traditional observability platform.
architectural observability platform really focuses on you’ll see where the user made a request and then it could travel through multiple services before reaching database, going back to the user and somewhere along the way, something changed from last week, which caused degraded performance, may have caused an error. Any of those things, those drifts that occur, architectural observability platforms, identify those in the context of the whole.
And that is only part of it. So it is not all about looking for issues, right? It is also about documentation and for example, bringing on new engineers. So if you want to onboard a new engineer, you want to show them the first thing I do whenever I bring on new engineers, show them kind of an architectural diagram of the entire product.
and let the engineer know this part of the product does, for example, invoicing, that part of the database does product registry and then eventually I’ll let them know this is where you’re focused on. You’ll be working on the UI, whatever.
But those diagrams, as we said, change so often that… maintaining them has become very, very difficult, almost impossible, right? We have seen clients with 200 plus services and new services being deployed every day. So you have to have something automatic to help you generate that documentation so you can onboard new people, so you can go through security reviews and threat assessments.
All of these are dependent on you having good understanding and good documentation of what it is your system does and how it’s built. Which is something that, without architectural observability platform, is, I think, completely impossible.
Kate Holterhoff (14:29)
So vFunction just published the 2025 architecture and software development report. I’m interested in why vFunction sponsored this report. Can you talk at all about who the respondents would have been and what were you hoping to learn?
Ori Saporta (14:43)
Absolutely. So we launched this research in order to understand where companies truly stand in their view of architecture, in their practice of architecture, how they’re architectural work into their everyday development work. Respondents were mainly IT leaders, CTOs,
engineering vice presidents, tech leaders from various companies, various industries and various sizes. from companies with a hundred million yearly revenue streams to billions in yearly revenue and from financial markets to software to automotive and really
trying to shuffle it everywhere we can so we get really a full picture of the way people see architectural work. And we saw a lot of different responses coming from different functions higher up in the chain, like executives felt differently than engineers or tech leads lower in the… in the management chain and so executives may think they’re actually putting more effort into architectural work than actually is happening down in the trenches as you said.
We saw that larger companies tend to give architectural work more emphasis than the smaller companies, which is expected because that level of complexity becomes so obvious at some point that you say, we need somebody to own this, to own the complexity. And we need to put resources into owning that complexity. And that really is where the architectural work comes in.
Kate Holterhoff (16:19)
Yeah, I was extremely interested in the report. I thought it had a number of interesting findings, but I thought it was particularly interesting that it highlights a significant disconnect between architectural intent and implementation reality, where 93 % of respondents experience negative outcomes. What’s the biggest contributing factor to this misalignment?
Ori Saporta (16:39)
So we at vFunction feel, and we have been advocating this for a long time, that there is that disconnect between the executives and the actual developers and engineers in the field. Because there’s a sense of what is important and then what is urgent.
And for the executive, they know it’s important, but then the entire organization often just only has time to deal with the urgent. And so often the architectural work isn’t the urgent. Everybody agrees. Nobody will ever say it’s not important. But when you have to prioritize it now,
You have to prioritize some refactoring to solve an architectural problem that will make life easier in the next version. Definitely. It’s work now, it’s paying off debt, right? It’s architectural, technical debt. You have to pay off the debt. It will make everything easier in the next version. But in this version, we still want to fix that bug and issue that feature. And so we won’t do that refactoring. We won’t pay back that technical debt. And we just accumulate more of it.
And eventually, although there is that perception that we are working on architecture all the time, we talk about it and we know we need to solve these issues and we know we have to work on it, continuously work on it to make it better, which we don’t ever get to actually do. Because there’s always that decision and we have to do something else that is more urgent.
Kate Holterhoff (18:14)
the report also suggests that AI could both simplify and complicate architecture. How can organizations leverage AI to improve architecture without increasing risks and complexity?
Ori Saporta (18:25)
So AI means so many different things to different people. And in this context, it really is, I think, very different things. So when we talk about AI, at least in the last, I guess, couple of years, we often mean generative AI and large language models and the way they help us to generate code.
Kate Holterhoff (18:29)
Good point.
Ori Saporta (18:45)
It is one of those things that we have really gotten used to in the past couple of years and they’re just increasing with more and more features and now agentic AI becoming ever-present. And when that happens, first thing that happens is a lot more code gets generated. So it’s like having almost limitless
coding resources. So I have like a thousand new junior developers in my team. And I’m exaggerating, but it is kind of like that. And in that sense, GenAI is really akin to a junior developer because it has a limited point of view, a limited understanding of the product as a whole. It doesn’t actually understand. It lives off of immediate context.
and when it does that it may generate code and a lot of it and that code may very well be solving a local problem very well but it definitely lacks that high level point of view and with more code being generated like that means that you need more resources to go over that and find
duplications and find the same problem being solved multiple times by different generative AI outputs and I have all of them in my product now. And what am I going to do? I need to consolidate them. So somebody needs to notice that this happened and somebody needs to do the work. And then once you get to doing that work,
you can use GenAI to help remediate that. So the first thing is GenAI just generating a ton of new code. And then the last part of it is using GenAI to remediate that. But in the middle, there has to be some person and probably some kind of architectural platform to understand that this happened and that you need to take action. So that architectural platform might again be using AI, maybe not generative AI,
maybe just using old school neural networks to understand the way the code is built. then, so it’s still AI, it’s not generative AI, but to understand it in a different way and to pinpoint where issues are. So it’s AI everywhere, right? It’s helping cause the problem, it’s helping identify the problem, it’s helping maybe resolve the problem. There still has to be a person in there to make sense of it all.
Kate Holterhoff (21:08)
And looking ahead, what do you see as the future of the software architect? And do you anticipate that tools and practices are going to need to evolve in order to meet those challenges? You have a wonderful quote in there that you’re going to reclaim the architect’s role for scalable, resilient systems. How are we going to get there?
Ori Saporta (21:26)
Well, I think I’ve kind of been hinting at it throughout this conversation is that we really need three-pronged approach. First of all, we need to properly define these roles as the more code gets generated, as the…
architecture and product becomes more complex, we need to define the role of the architect as that person, persons, depending on the size, that are in charge of that high level view and the standards and making sure that going forward things happen the way they should. The second part of it is they need the right tools to do that. And those tools,
didn’t exist until a few years ago because systems weren’t as complex and it takes time. By the time you realize systems have gotten so complex, you understand there is a problem. Now it takes a while to create a solution, but the solutions are out there right now and they’re starting to be available in different shapes and forms.
The idea in all of them is to understand architecture of complex systems better. And those complex systems may be huge monoliths they may be huge microservice applications and any combination of those.
And the third part of it is really making the effort and assigning the right resources to resolve issues, to repay technical debt once you realize you’ve accumulated it.
Kate Holterhoff (22:53)
So we are about out of time. Before we go, how can folks hear more from you? What are your preferred social channels? Yeah, how can folks stay in touch?
Ori Saporta (23:01)
So follow me and vFunction on LinkedIn. We put everything there. We publish things on LinkedIn multiple times a day usually. We have events planned with AWS in May, in June in London and Manchester.
We call them our modernization workshops. We plan to bring those to the states, New York and San Francisco later this year. And like everything else, they’ll be published ahead of time in our LinkedIn.
Kate Holterhoff (23:28)
Fantastic. I’ve really enjoyed speaking with you, Ori. Again, my name is Kate Holterhoff, Senior Analyst at RedMonk. If you enjoyed this conversation, please like, subscribe, and review the MonkCast on your podcast platform of choice. If you’re watching us on RedMonk’s YouTube channel, please like, subscribe, and engage with us in the comments.
No Comments