In a world where it is increasingly important for organizations to have well-built software, why is it that the industry tends to look down on the traditional role of the software architect? Amir Rapson, co-founder and CTO of vFunction, joins Rachel Stephens to talk about the future of software architecture, how we can make the architecture role more relevant and grounded in reality, and how we can help organizations make more sound architecture decisions.

Learn more about the vFunction platform at vfunction.com, and try out the Assessment Hub to measure your own tech debt for free at app.vfunction.com.

This was a RedMonk video, sponsored by vFunction.

Rather listen to this conversation as a podcast?

 

Transcript

Rachel Stephens: Hi everyone, and welcome to RedMonk Conversations. I’m Rachel Stephens. I’m a Senior Analyst with RedMonk and today with me I have Amir Rapson. He is the CTO at a company called VFunction. Amir, would you like to introduce yourself and your company?

Amir Rapson: Hi everyone. I’m one of the founders and CTO of VFunction. What we set out to do is actually bridge the gap between cloud innovation and enterprise reality, trying to really find — there’s a lot of innovation going on, but enterprises have their own reality and especially in software, it’s very hard to leave what you have at the moment, sort of a legacy, and change everything and adopt a lot of innovation. So we wanted to bridge that gap and make sure that software engineers and managers and leaders can really quickly use innovation or maybe quickly get rid of a lot of their technical debt in order to apply a lot of innovation towards their existing software.

Rachel: And so one of the things that I have heard you talk about frequently in this world of trying to bridge legacy existing software into the world of trying to innovate and move faster, is the role of architects. And think that this is really interesting. That’s what our conversation is going to be about today, because I think architects as a concept can be a little bit misunderstood, sometimes a little bit maligned in the industry, depending on who you’re talking to. And so our talk today is going to be about that. So I’m excited. I think it’s going to be good.

Amir: Likewise, likewise.

Rachel: So I think that one of the things that’s really interesting is that there’s a little bit of a paradox, I think, sometimes in that software itself is much more important now than ever before. We have this software has eaten the world for a decade and a half or however many years it’s been. It’s been a long time. Software is increasingly important to every organization out there. We have everyone trying to figure out how to do things well in this world, and especially in the world of cloud, architecture of that software is increasingly important. I think one of my favorite quotes is from Corey Quinn, where he talks about how cost and architecture in the cloud are one and the same things. Like it’s really important to your cost structure to understand your architecture. Having reliable and available services usually depends on your architecture and how you set things up, your revenue, your customer satisfaction. All of these things are inherently tied into how your app is architected. And at the same time, we’ve seen a skepticism about the role of the architect itself and the traditional role that architecture plays in how we build software.

Rachel: So we see this push for, we want fast feedback loops and we want empowered developer teams and those are great things. But where does the architect actually fit into that and the traditional design? Because I think a lot of times, if you think about the Architectural Review Board or something like that, it’s really tied to the concept of waterfall development maybe. So I think there’s just some questions here. And generally speaking, we have a subset of people in the industry and voices in the industry who are talking about how it’s really important to have this hands on view of the world rather than the ivory tower traditional architect view of the world. And so this is just the groundwork of where I want to take this conversation, because I think that both of these things are true at the same time. And so I would love to get your thought on this. Like, how does this all come together?

Amir: I think what you said is true. In a waterfall world, I think architects — their position was a lot more meaningful because it wasn’t just planning. It wasn’t just giving guidance, but it was someone that was actually in charge of the delivery. But with agile methodologies and with increased innovation and continuous integration and continuous deployment, what happened really is that this increased rate of innovation also led to an increased rate of technical debt, and it kind of took the architects out of the process. It means that exactly like you said, developers are the ones pushing. Developers keep on shifting left. The developers do everything. They integrate and they get some planning from product managers and from architects, some guidance. But then they go off and do their thing. And as part of agile methodologies, there’s very little places where architects could say, “Wait, let’s just now review everything and let’s review the architecture. Let’s do a whole review.” And I think that with time, all of these agile methodologies kind of took away the architects’ ability to really understand the internal architecture of the applications. So developers are moving forward. They have a certain plan from an architect, but that plan doesn’t — without actually basing that plan on reality, like how the software is built, because over time the architecture changed and drifted, architects are now, at least developers treat architects as, someone who is not necessarily relevant. I mean, I think maybe the clearest way to say it is if the architect doesn’t know what the software architecture is, what is his role really?

Rachel: That’s fair. And I think the other thing on top of all this is that we just started building such more complex applications, distributed applications with lots of dependencies and intermingled dependencies. I think you referenced technical debt and architectural debt and we’ll dive into that for sure. But I think part of it is we don’t really have the clean boxes and arrows architectures anymore. It’s not something that any one person can necessarily hold in their head. So it feels like part of the problem is that the architectural tools haven’t necessarily kept up with the way that we’re building applications, right?

Amir: As the architecture role diminished, the architectural tools — I don’t know how many architecture tools were there to actually give feedback to architects — but even all the planning tools that we remember, all the umls, who does that anymore?

Rachel: Yeah, I think the uml diagrams are — we need a different set of tools to help people be successful in this world. So one of the things that you’re talking about is everything shifting left, and I think we’ve seen that in DevOps. We’ve seen security start to go that way. We’ve seen a lot of things kind of shift into the realm of the developer. And we’re saying that we want to have things happen sooner in the software development life cycle so that people can be informed, that we can figure out where problems might be sooner rather than later. All of these things are great goals. What I would love to understand is, in your vision of things shifting left, is the goal to take a traditional architecture role and get them re-involved in the development of the design of the software, like getting them involved sooner in the process, or are we asking developers to take something else on? Like how do you envision this?

Amir: I don’t have a good answer for that. Developers can still do everything, but they still need some tools and some guidance. And that guidance is the role of the architect. The developer has enough responsibility. They have a task at hand, they need to to do something. And they own the delivery of those tasks and those user stories. But someone still needs to own the overall technical debt of the application and the overall architectural technical debt of the application. And I think that that can’t be a developer because I think that creates a conflict of interest. Let’s say I want to develop as fast as possible, right? Because I want to deliver as fast as possible, for me as a developer, that’s the right thing to do. Architects need to own the architectural technical debt. They need to make sure that that was done properly.

Rachel: So a couple of times now you’ve talked about architectural debt. And I would love to understand — because I’ve definitely done some work in and around understanding technical debt overall and understanding how that adds risk into our systems. Can you help me just understand the difference in your mind between just technical debt and architectural debt? And is there overlap? Are they kind of subsets of one another? How do you think about that?

Amir: I think technical debt is can be a very wide term. Technical debt can be any piece of the software that they may want to rewrite or replace at one point or another. It could be like a library that I’m using or a framework that I’m using that their versions are getting slightly older… even the, you know, I’m using an older Java version and they need to use a new Java version. But architectural technical debt, I don’t see it as the same thing. So I have a certain part of my software and want to completely rewrite it. This is my cost of rework. This cost of rework, you can calculate that into technical debt. And cost and debt is a term that I like to use interchangeably. But architectural technical debt is really the cost of reworking all of the elements that are dependent on the part that I really want to rewrite. So if in order to rewrite a certain part of the software, I have to rewrite half the software, then that’s architectural debt.

Rachel: Kind of like that dependency daisy chain is what you’re thinking about then?

Amir: Yes, because if I change this element and it affects completely different elements in my software, that’s bad, right? I want to limit this change only to a certain part. And I think that that’s where architects need to step in to create those boundaries within the application to break those dependencies where they’re not needed to to maintain the modularity within their application. And there are ways to do that, right? I mean, you could do microservices. And microservices, when you do that, inherently microservices live in their own separate worlds, but there still could be too many dependencies by one microservice calling another service, calling a third service and that’s a dependency between them. So it’s really a mindset that needs to happen. I mean, that minimizing the amount of rework that you’ll have to do if you want to change any element of your software, or to calculate what is the average amount of rework cost that you have to pay in order to rework any element of your software: that’s your architectural technical debt.

Rachel: Yeah. I want to dive in on the microservices idea, though, because you and I have talked about this in the past, about the recent article that came out around one of the teams that moved from a microservice architecture back to a monolith just for cost reasons and reliability reasons and overall simplification. So I think one of the things that’s really challenging for everyone in this industry is that we have this variety of building block primitives to choose from, from VMs to containers to serverless. And we have Wasm now… all of these coexisting. We have patterns and practices, microservices and monoliths and how do we pick what is the best one? So when you’re talking about technical debt and architectural debt, some of these things just feel very nebulous. Do you have any sense of what is a way that an architect and/or someone who’s in charge of architecture start to make these decisions? And what kind of tools do they need to start to think about this?

Amir: So. If you think about like a perfectly written software, it doesn’t really matter if it’s in a monolithic application, if it’s modular, if it’s microservices. The only thing is that over time, software stops being perfect and becomes and slowly becomes a big ball of mud. And with microservices, you think that it will take you longer to get to that big ball of mud because those services are small, because it’s very easy to control specific services because you know exactly what’s in them. But these applications get very complex. And even thinking about the monolithic application at first and splitting it into services or just even starting off with a microservice approach… it’s very easy to get religious about microservices, building too many microservices, making these microservices too small and changing the complexity from a complexity of code to complexity of the entire system. So now it’s it’s a very complex distributed system that’s very hard to operate. So in terms of the DevOps around it, the maintenance around it, the measuring, the performance within it, all the observability that you need in order to really understand what’s going on there, it can really become a mess. And you have to do it in a very practical way if you want to take it from a monolith to microservices in order to make sure that you’re making sound decisions, that are also good looking into the future. So not future safing it really, but just making longer term decisions. What we are talking about now is kind of bringing back their ability to control what’s going on, making sure that an architect can actually see the architecture within the monolith and control that and somehow bring some order to what was previously very much chaotic.

Rachel: So one of my questions is, we kind of talked about how uml diagrams are not something that necessarily helps so much in this day and age. But then you also just now said helping architects kind of visualize the system. So what is the tool that is — what does it look like to help an architect understand what’s happening in a code based view of the world rather than a diagram based view of the world?

Amir: So architects, when they look at the differences between what’s in their mind or on their whiteboards, this domain driven design and the reality, they see all of these dependencies that became between two different domains over time. They could do one of two things. They can either ask to rework it, to re-architect it, to split it up into services, or you could just accept it. Okay, this is the reality. That’s fine. These are modules that actually don’t change as much. Let’s call it one big module that encompasses two domains, but now let’s maintain it. So, how do you take that and say, okay, I accept the architecture as it is. I don’t have the budget to do any rework now, but how can I make sure that it doesn’t go any further than that? How do I make sure that the whole thing doesn’t turn into a big ball of mud? So that’s the question to ask.

Rachel: And it really feels like this pragmatic view of trying to understand the application as it is and the application in its ideal state and how do we marry these worlds in a way that works for both the people who are in the application every day and the people who have these strategic visions around how they want the systems to operate. I think that’s a pragmatic approach to things. So I think where we’ve landed then is we’ve seen that there’s probably no one best architecture because it’s going to depend on who you are and your legacy and what you’re trying to accomplish. It doesn’t feel like there’s going to be a best thing that we can leave everyone with as a takeaway. But are you seeing any patterns of people who have been successful either in the industry overall or in your customers in terms of trying to get their hands around how to think about architecture and especially around re-architecture?

Amir: So, I have to say no. Actually I see across the board that architects think that they know a lot about their applications, but they don’t really do. I mean, when you tell them or when you show them the reality, if you go with them through a process of using the platform that’s being developed and show them all the interdependencies and show them the differences between their mental model of what their architecture is and what the code really looks like, there’s a lot of aha moments like, “Hm, I didn’t know that.” Or “Oh, okay, that actually makes sense” because they know that every time we change that, that piece breaks. And we see that often, we see very often that architects get surprised that they kind of realize that they lost control over the architecture. And I don’t remember too many cases, or even one, where architects were not surprised by what the application looks like. And obviously, especially when you look at like not 100,000 lines of code, but a million lines of code, it’s impossible to really understand the architecture when you think about the monolith or if you’re not talking about five different services, but even 20 or 30 different services, to understand that system is also a little bit too complex to maintain that view in one’s mind.

Rachel: Gotcha. So the commonality is maintain a willingness to be surprised. Be willing to learn. I like it. Well, Amir, thank you so much for your time today. I really enjoyed this conversation and I learned a lot and really had a great time chatting with you. And you talked about the platform you all are building. If any of our listeners want to learn more about this, where should they go?

Amir: Vfunction.com or just LinkedIn me or send me an email at [email protected].

Rachel: Wonderful. Well Amir, thank you so much and have a great day.

Amir: Thank you, Rachel.