I recently had a conversation with the vFunction where the team spoke frequently about the software architect as one of their core personae. This slightly incongruous with some of the sound bites and discussion I had seen taking place elsewhere in the industry, so I invited vFunction CTO Amir Rapson to come record a conversation with me and make the case for the software architect.

Here’s a quick recap of some of the architecture discussion that has been happening online. (I don’t know if I trust the longevity of Twitter’s embeds anymore, so I’m including the tweets as a screenshot. Text and links also included below.)

^{Charity Majors: I don’t know if this is a troll or not, but with all apologies to my many wonderful, highly skilled “Architect” friends, I tend to think it’s a bullshit role. 🙃
I believe that only the people building software systems get to have opinions on how those systems get built.
Gergely Orosz: Why does it feel that the concept of “architect” is avoided across most Big Tech and startups?
The places I observed this role are orgs that feel more “traditional” & definitely hierarchical.
Is this just perception? Or reality? Do these roles exist with empowered eng teams?
Dare Obasanjo: Architect is an unfavorable title at big tech companies because the stereotype of a software architect — a person who issues edicts about how the code should be written while not writing code in the codebase — is a role they want to avoid.}

What Rapson brought to the conversation was not a hot take or a position that in opposition to the statements above, but rather we had a pragmatic discussion about the complicated role of architecture in today’s software ecosystem.

I recommend you watch the entire video, but here are some of my favorite excerpts from the conversation.

On Agile’s impact on the architect

Rapson: “In a waterfall world, I think architects’ position was a lot more meaningful because it wasn’t just planning and it wasn’t just giving guidance; it was someone that was actually in charge of the delivery.

With Agile methodologies and with increased innovation and continuous integration and continuous deployment, what happened 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.

I think that with time, all of these Agile methodologies took away the architects’ ability to really understand the internal architecture of the applications.

I think maybe the clearest way to say it is if the architect doesn’t know what the software architecture is, what is their role really?”

On developers and architects

Stephens: “In your vision of architecture 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?”

Rapson: “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, 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.”

On architectural debt vs. technical debt

Rapson: “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.

But architectural technical debt, I don’t see it as the same thing.

I have a certain part of my software and want to completely rewrite it. 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.”

Rapson: “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 maintain the modularity within their application.”

On monoliths and microservices

Rapson: “If you think about 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 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.

On common patterns

One of my favorite parts was asking Amir what patterns he's seen, and the pattern he noted was how architects with are inevitably surprised by the state of their application when they have the tooling to inspect it. pic.twitter.com/bvkN3bIhti

— Rachel Stephens (@rstephensme) July 27, 2023

I hope you watch the full video: Shifting Architecture Left

---

Disclaimer: vFunction is a RedMonk client. The video discussed here was sponsored by vFunction (but this post was not sponsored by any entity).