# Architectural Strategy in the AI Era

**Podcast:** The InfoQ Podcast
**Published:** 2026-11-02

## Transcript

Get a fresh perspective on your engineering decisions with InfoQ's online certification programs.
Work alongside an experienced practitioner and senior peers from other companies, applying what you learn to your own work.
You'll leave with new approaches or greater confidence in the direction you're taking.
Topics span architecture, AI engineering, and team leadership.
Four hours of live sessions weekly for five weeks.
Explore certification.qconferences.com.
Welcome to the Architects Podcast, where we discuss what it means to be an architect and how architects actually do their job.
Today's guest is Luca Mezzalira, who has spent over 20 years helping engineering organizations make architectural decisions that shape how their teams work and systems scale for years to come.
At DAZN, as Vice President of Architecture, He led the migration to microservices and microfrogens at streaming scale.
At AWS, he worked directly with some of the world's largest organizations as their architecture expert, running the EMEA go-to-market strategy for serverless, delivering over a dozen talks at reInvent, and leading whiteboard sessions.
Event storming and distributed systems design course retail, travel, finance, insurance, media, energy, healthcare, and the public sector.
Many years were spent developing micro frontends from a nascent idea into a discipline through research, experimentation, leading up to an O'Reilly book aimed at serious teams.
Hundreds of organizations worldwide were aided in modernizing and scaling their web and mobile applications with micro frontends because of his efforts.
He has delivered over 350 sessions at many conferences throughout the world.
Currently, he facilitates the QCon InfoQ architecture cohorts.
where practitioners learn how to navigate modern architecture.
He is the voice behind the Token by Token newsletter, the Dear Architects podcast, and the Microfrontends newsletter.
His obsession, to use his own words, is taking the hardest architecture concepts and making them impossible to misunderstand.
It's great to have you here on the podcast, and I'd like to start out by asking you, were you trained as an architect?
How did you become an architect?
It's not like you decided one morning, you got up, you got out of bed and said, today I'm going to be an architect.
Yeah, absolutely.
So first of all, thank you very much for the introduction.
And thank you for having me in this podcast.
Definitely, you don't wake up and you became an architect, despite I wish it was that easy.
I think it's a natural evolution of the engineering role, at least in my time.
We didn't have, let's say, all these different titles, fancy titles that are nowadays in the tech industry.
Therefore, the path was fairly well-defined.
Either you move into management or you sharpen your soul and you became better and better and better and start to obstruct yourself and start to see more problems, more challenges, and so on and so forth.
I decided to go with the latter, despite a good chunk of my career was also in management, but with always keeping an eye on the tech side.
Because even when I was VP of architecture in the zone, I was very clear with my CTO saying, listen, I'm still designing things.
I'm still working with the engineers.
And in fact, I spent a lot of time even doing pair programming back in the days with engineers, despite I was VP of architecture.
The reality is I like solving problems.
It doesn't matter at which level the problem is.
If I can help out and quickly, let's say, pull all my experience to move the needle, I would do that.
So therefore, for me, it was important.
So how I became an architect.
What I realized during the years is that the part that I love the most while I was an engineer...
It was the refactoring part, mainly because I like a lot, let's say, understanding how people implemented something, trying to crystallize in my head if that was a good decision for the situation we were at the very moment, more than six or a month ago or a year later or a year ago.
And then I loved at the beginning of a Greenfield project, spending time designing, understanding the business problem, understanding the context where I was operating.
And then I discovered over the years, reading a lot of books, that that wasn't, let's say, something accidental that I was doing.
It was, let's say, a clear path towards, let's say, architecture and designing systems that slowly but steadily became my profession.
But with some bumps, I would say, because as you can imagine, there is a...
period of your time where you are not an architect, you would like to be an architect, but you are not in the right rooms and you're not talking with the right people.
And therefore I created this approach where I was designing by my own and try to solve the problems that other teams have and trying to see if my ideas were, let's say, similar to what the architects were doing back in the days, but also being invited or basically asking, begging the architects to be invited in their meetings.
to understand how they were talking, how they were thinking, basically stealing their secrets to a certain extent.
And that helped because obviously after several months, I started to give my two cents.
People started to pick it up.
And so I said, you know, it's not a bad idea what you're saying.
It's a good perspective.
And slowly but steadily, I enter in that role of architects.
But I have to say, I don't believe...
I needed the title for doing the job because even before as a principal engineer, I designed a lot of systems.
I designed a massive modernization of a gambling company where I was working on.
I was a tech leader of a real money gambling department with hundreds of people.
in a company called Gamesys that was acquired in the last few years in London.
And there, basically, I was able to convince the CTO and the architect and my colleagues to migrate to a more, let's say, simpler framework for building gambling games.
So we moved from nine months to three months for each single game.
The morale of the team started to raise a lot.
They started to push a lot.
There were a lot of benefit of this approach.
And that was a very nice...
challenge that I face from the social technical aspect.
Because before that, I spent a lot of time as consultant at a company in Italy, was a CTO.
And there basically, we helped companies to simplify their integration with ERPs and with crazy projects like working on a Ducati motorbike dashboard or working on a soda dispenser display, stuff like that.
So we had like these two things that we were pretty good at, P integrations.
And also, let's say, embedded devices that were kind of unique deals back in the days in Italy.
That's interesting for two reasons.
One, when you mention stealing ideas, you recall to me the famous quote of Picasso that says, mediocre artists copy, great artists steal.
Absolutely.
That's my mantra.
This also brings to mind is because in order to steal something, as opposed to just copy something, You actually really have to understand.
One of the things I found that there are many people who are developers and have this idea that the next natural place to go is architecture, which can be false because as we know, there are many other paths.
But also the personality of the architect is very different than the personality of the developer.
Developers very often have to be very, very careful.
You build a table.
If one of the legs on the table is not strong, you can still use the table.
But in a software analogy, if one of those legs is not strong enough, you can get into a lot of trouble.
How do you sort of change your personality or develop a more broader perspective when you move from developer to architect?
To be honest, there was a big realization for me that architecture wasn't mainly being the most technical person in the room.
More than that being the person that tried to balance the discussion and the decisions that we were making inside the social technical system.
I try to stress out this idea of social technical system because I think the main community that is currently talking about this is the domain-driven design community more than others.
Because we realize that we are not designing architecture for the sake of, let's say, technical reason.
We are designing for the organization communication structure.
as the Conway's law suggested.
The challenge in general is that when you are a developer, you can go very vertical.
And remember back in the days that we didn't have the fancy titles like Distinguished Engineers.
There were other principal engineers in some companies, senior.
And there you can find amazing minds.
But some of them, they were extremely good on their craft.
writing code.
They didn't want to go around the company, speak with products, speak with developers, speak with other teams.
They were masters of their craft and they were capable to write the most impressive C program that works like a charm in any device or they were capable to do things that other human beings didn't even expect that they were capable to do that.
While this role was more looking holistically...
on the problem space that is not merely the technical one, but also is the social one.
For me, that realization completely changed the way how I...
see technology.
Back in the days, I tried to be the most technical one.
I really deep dive in several things.
Let's say at the very low level, I was doing things that other engineers were incapable because working in embedded systems is not a walk in the park.
Every byte counts, every line of code counts.
So you need to put a lot of theft forward and try and try and errors.
While as an architect, I found extremely fascinating this idea of speeding up things.
So how can I design a system that enables others to succeed and to become a better version of themselves?
And that was, for me, very interesting because behind that, there was a challenge that lies behind, if you want, bureaucracy, different line of business and different layers inside an organization.
And I found extremely fascinating this part because no one wanted to do that, let's say.
bothering all these people in order to align them and having a thing.
I thought, you know what, if I know what I want to express technically, I cannot express because probably people either don't understand or don't know that these things could be interesting.
Then many people, every time that I did big things in architecture, they always told me, well, why are you bothered?
Like at the end of the day, they are paying you no matter what.
But for me, you know, it was the challenge that was very interesting, not the technical implementation or whatever, the challenge of convincing everyone and aligning everyone that we might be in a better place if we do X, Y, Z.
And that for me was the reason why I became an architect slowly but steadily and spent a lot of time studying because, as you know, the reason, let's say...
a proper training for architects.
I mean, yes, there are Togaf and all the other different certifications, but it's not that they are telling you how to be an architect in terms of communication, tweaking your language based on the audience that you have, decentralize yourself, understanding that, yes, everything is always on fire, so you need to pick the right fire, and all the things that you learn in the trenches over the years, because when you take an architectural decision, it's not materializing next week.
or next month is something that you decide today.
And if you are lucky and you work on a product, it will materialize probably in a year time or even longer in certain cases.
Therefore, if you are capable to create something bulletproof for the future, because you cannot predict the future, but you apply the right modularization in certain areas of your system for enabling the business to evolve no matter what is the direction of travel that they're taking.
I think there, there is a lot of novelty and creativity that you can apply on top of your technical skills.
Obviously, in order to do that, you need to convince people that your idea makes sense and you need to receive positive and negative feedback.
And to be frank, what I learned over the years is that the feedback, no matter what it is, if it's, let's say, sometimes, let's say that the communication is not a strangle of some people and they don't smooth every corner, but no matter how they are delivering a message, I learned over the years that It's important that I decouple the information from the form of how a person expresses himself.
or ourselves.
And I think it's very, very important to learn that I, again, over the years, and it enables me over the years even to understand that in reality, there is always something that I can improve, no matter how harsh a comment is or how positive a comment is.
In general, you know, feedback for me is a gift, and I want to make the most out of it, despite it's negative or positive, because the negative part is just a step.
closer to improving your solution.
And therefore, if we start to think with this mindset, any kind of feedback is extremely important.
And I have seen that it became a very contagious mindset over the years inside companies, because then people started to behave differently if you don't overreact and you instead try to understand the point of view, put yourself inside the shoes of the other person and trying to make a step towards them more than moving on the other side.
So I think this part of where communication back in the days was a soft skill, I always refer as a core skill, no matter if you are an architect with a title or a developer nowadays, especially with AI, where, let's say, we start to have slightly more time for implementing features because the creation of code becomes, let's say, you know, kind of say a commodity, but becomes, let's say, easier to a certain extent compared to what was in the past.
And therefore, I believe that this...
architectural mindset that covers not only the technical part, but also the social part, will be extremely beneficial for any single tech person that is navigating this AI era.
I am very sympathetic to that socio-technical view of architecture because in my career, I found sometimes the biggest obstacle to going forward is people's inherent dislike of change.
And also the fear, and this is very interesting listening to talk about feedback, that people very often don't give feedback because they're afraid of the managerial repercussions of the feedback.
So I think you're right on when you say that this is a core competency.
It's not a nice to have.
It's an actual core competency.
And especially now that you've raised the specter.
or the benefit, however you want to look at it, of AI, where you're communicating in natural language and you have to be very precise in how you write your prompts.
So communication sort of rises from a secondary skill to a primary skill.
How do you see the education of an architect in the age of AI, especially when we do not fully understand the technology or where will it go?
I have to say...
a very pragmatic take on the education side.
I believe that no matter what is your title, you need to have these skills.
I'm witnessing a decentralization approach on architectural practices across the industry.
Not every single company, but there are certain industries.
especially in more modern companies that they were born in the SaaS era, I would say, they started to decentralize a lot towards developer science.
But the reason, let's say, formal education is like literally, okay, now you need to take care also about that because we don't have architects anymore.
There isn't anything is provided to them.
Also because I don't believe architecture can be only taught with lectures or, let's say, frontal education.
I think it has to be collaborative.
You need to learn the skills on communicating.
I think you need to properly design, think that behind an arrow, there is a lot that is hidden and you need to go in different level of depth.
Therefore, even the most technical developer could find some benefit of talking or thinking like an architect because they can...
better understand the problems of other teams and the company itself.
When I think about education for architects, I want to have something that is in its own, like Catas.
I know, for instance, Neil Ford is a big fan of Catas, and even Mark Richards, they're talking a lot about them.
We worked together for O'Reilly back in the days for the first edition of O'Reilly Catas, where multiple teams all over the world, they submitted their...
projects based on a scenario.
It was quite fascinating listening to them on how they are thinking about the architecture characteristics and analyzing the other proposals was extremely helpful for me.
But in general, you need to...
to think more holistically on the complexity you need to handle that is not merely writing performant code or writing beautiful code at the end of the day.
Code is good for reading for people.
And if we think about all the levels of abstraction we have done, probably sometimes we risk to be not even the most performant inside the program.
But, you know, it is what it is, I would say.
In general...
The education should be, let's say, and so on should be with case studies that we can see how other people have tackled a specific problem.
We need also to understand the context.
Very often, I've seen in conferences, very interesting behavior from speakers where they were saying, oh, we move from microservices to monolith because microservices are evil.
And once I did an exercise after this talk about moving from microservices to monolith, and I went to the speaker in private and said, listen, can you tell me a bit more about your team structure?
And she was telling me, oh yeah, because before we were five teams and we have 10 microservices, and now we are just one team and we have a monolith.
I said, okay, but that was an important detail to describe inside the talk.
If you avoid that, it seems that the architecture itself, no matter what is the context, will drive negative impact.
And I think these kind of scenarios are extremely important for developers to try always look holistically about the context and what people are saying, because behind an absolute statement, there are always nuances and there are other things that they might not be facing in a conversation or in a talk or in a book.
So I always tend to understand first the context because I know probably you are quite familiar with the statement, oh yeah, we are using a squad like Spotify and many companies are talking about that despite Spotify never implemented that model, the conceptual model that they had.
And when you think about this, you say, okay, so, but then what was that?
It was a scam.
No, it's not a scam.
They aim for a shoot for the North Star and they arrive halfway through and it was good enough.
Or they understood that the effort for putting in place everything like they designed, it was too high.
But at the same time, they have a specific engineering culture.
It's not like...
There are too many Spotify's in the world.
What works is Spotify works is Spotify because Spotify has a certain way to interpret the life of an engineer similar to what is happening in Google, in Amazon, or wherever it is.
So I think context should drive certain decision.
And I understood that best practices or patterns and anti-patterns sometimes can be leveraged.
No matter if we think it was written in a book, Black and White, that is bad for a system or extremely good, you might decide to avoid for a strong reason.
And very often, you know, it's good knowing that there are certain things available, but not necessarily embrace every single best practice because it might not fit inside their context.
For example, you mentioned Spotify or Netflix or Google.
If you have risk adverse engineers, because that's their personality, That's just as much a constraint in many respects as how many CPUs you have or what your network bandwidth is.
This is what I find fascinating about when you talk about context.
People have to think of these dimensions as well.
But I also want to get back something that you said before about decentralizing things.
Because one of the things to me that's important to an architect is They are responsible for the things that no one else is thinking about.
In other words, you can't write a use case that says, make the system scalable or make the system safe.
And if you decentralize and you don't understand what the AI is doing, the abstractions can leak all over the place.
I know you're interested in this particular problem.
So what kind of advice would you give to people in this world where the AI is doing a lot of stuff, but the AI doesn't know where the abstractions leak?
To be honest with you, I strongly believe that architects in the current term of the role should evolve into a sort of enablement team.
Like we think about in topologies, if we want, like security.
For me, the example of security is quite crystal and clear.
Usually think about how many security people you have or how large is the security teams inside an organization.
It's probably one security architect, 20 developers, something like that.
So therefore, scaling that part is complicated.
Now, in architecture, though, I tried in the past, and I think it worked decently well, but obviously I could push even further.
It's the idea of helping developers to take architectural decision.
Andrew Harman Lodo discussed very well this part on the advice process where you decentralize, everyone can design something, but then you need to create some guardrails.
And from Andrew's book, I fully agree on the fact that there should be a committee that is composed by who is going to consume the API and, let's say, some people that have...
expertise that should review the design of a specific area of the system.
And this basically group of people, it is more fluid than a formal architecture team, should, let's say, decide the direction of travel.
And I really like this democratization of designing architecture in general, because I believe it's not sustainable.
You can't have, let's say, one architect every two teams, because the cost will surge drastically.
But thinking about being an architect as a coach where you, on one side, you help people to ask the right questions and to have the right mindset when you are designing something.
On the other side, though, I think also there is a problem or a challenge in general on fully decentralizing every single feature that is basically that classic feature that's spun across multiple domains.
And it happens every single time.
It's like two or three or five per year that you need to tackle.
The problem is that there is bias if you are inside the team, right?
So I try to make the best in my team in order to succeed.
The gamification of promotions in general in every single company is...
It's trying that the best person will succeed and therefore deliver most for the company.
And so you deserve a promotion.
For me, that leads sometimes in the wrong behaviors inside the organization.
Therefore, having someone that is super parties that can look holistically on the problem and not designing, but helping to rationalize, asking the right questions that are not, let's say, too...
coupled with a specific domain, but they understand the business because they spend more time with the business.
They understand the tech because they spend time with engineering teams and so on.
Having these kind of figures, I think will help a ton in companies that have, I don't know, 50, 100 people.
Because no matter what, having someone that looks holistically on that would be helpful.
But also...
could be the one that provides guardrails for the entire system.
We were discussing before on how engineers can become an architect.
So sometimes there are certain things that you don't have time to, no matter if you're AI or not.
Like, okay, I want to create some fitness function that makes sure that my system behaves in a certain architecturally behaving in a certain way.
And I think this is the part that architects can contribute, can own the holistic view of the system, can provide the guardrails, can also surface patterns that are happening inside a specific team for all over the organization.
There are a lot of things that, in my opinion, an architect can still do inside the company, but I would say the time of, oh, you just designed.
let's say at nine in the morning, you start your job, you design the architecture, and then you go and just talk with people, it's shifting a bit.
I feel that we need to do more than just design architecture.
Usually at my team in the zone, seven years ago, I was saying 70% of your role is being empathic with the people that you need to work with.
And 30% is being technical, not being the most technical one.
but be technical and understand what's going on inside the system.
And the empathic part for me is going across the organization, understand what's coming, trying to fit this information into the team so they will be able.
to take the right decision.
And if someone is taking a decision, you can raise these things, say, oh, by the way, you know that in two months time, we need to implement this specific feature and we'll invalidate this specific decision for this reason, that reason, that reason.
Because at the end of the day, developers with this shift left movement that we have seen in the last few years.
They have a lot on their plate.
Now, maybe with AI, we can delegate a bit of the code creation, but still, we shift left for the DevOps part.
We shift left to security.
We shift left on architecture.
We shift left on writing code, obviously.
And if you think about early 2000, you were writing code, you write the test, and then you're thrown on the other side of the fence for someone in the DevOps team that you didn't even know the name of the person that will basically pushing your code in production.
That is a completely different world now.
What you're saying, maybe I'm pushing the analogy too far, but sort of in academia, when you're doing your research, learning to be a PhD, you have a thesis advisor.
And the role of the thesis advisor is to ask the right questions.
In other words, to look at what you're doing, see the weak points, and ask the right questions.
They don't do the work for you.
They don't do the research for you.
They don't do the development for you.
They don't even do the architecture for you.
But they're there to say, did you think of this?
Did you think of that?
Do you realize the business people are thinking of this in two years?
And that is, I think, what you're saying about the role of an architect.
They almost become a super mentor.
They still need their technical chops.
But there's sort of the super mentor, which then raises the question, and I know you've talked about this before.
If you're using AI agents, you have the difference between knowledge and purpose or wisdom.
What do you think of that statement?
I think agents are a very interesting tool.
And for certain use cases, I would say that might be pertinent.
Would they replace fully architects?
Depends from the project.
So there are small projects that, to be honest, they don't need much design.
If you have like, I don't know, 10 requests per second, you can write the worst code in the world.
You can show everything inside the virtual machine or container because of the traffic, because nowadays we are operating in amazing machines.
It's very unlikely that it's going to fail miserably.
And then we might argue that my...
lack of resilience, in my lack of scalability, and so on and so forth.
But there are certain projects that don't need any of those.
Obviously, we're talking about small projects, so this is probably the long tail of software.
But when you are in mid-size, large organizations, there is a lot of context that is hidden over the years.
Sometimes in documents, sometimes in people ahead, it's complicated.
So facing the...
The context is very complicated.
There is also a systemic problem on all of these that obviously we have a limit on tokens.
We have a limit on context window.
We have a limit on summarization.
We have a probabilistic system that majority of the time might recommend the right things to do, but not all the time.
There are a lot of things that are inside of this agentic revolution.
And not, let's say, against them.
I think they can help drastically.
But I think still it's very important that tech and product and business took together in order to understand what we are building.
Because if we don't understand what we are building, then we kind of feed agents or whatever else with the ideas.
And on top of that, if you see the evolution of this revolution, we started with the MCP that didn't have any authentication.
Now, I don't recall any grain changer APIs that we or technique that...
forget completely about security.
We are seeing multiple attacks in different ways on, I don't know, packages that are deployed on OpenSUSE project, people that are installing agents in their computer, giving them access to their credit card, their email, wherever it is.
So I think we are exploring a lot that is great, but sometimes we forget about the fundamentals of software.
That is a bit of a shame because, yes, we need to stress out these things and see where we land with that.
But there are certain things that now is a baseline.
You have a baseline on how secure it should be a system.
If a system leaks credit card, it's basically instantaneously in all the newspapers in the world.
There are a lot of things that we need to take into account.
And that's why I believe that architects or human beings in general are still very valuable in the software chain.
It's not that we'll be fully replaced.
They augment the capacity for them and also having more time for thinking, in my opinion.
But I don't believe that every single role will be fully replaced by AI today.
So if you can think of a specific example, if one comes to mind, because the change is happening almost so fast that humans can't understand what's happening.
I mean, this is the problem with the regulatory framework.
As Donald Rumsfeld...
famously said, it's the unknown unknowns that kill you.
Do we even know as humans where we have to be in this chain of reigning in the probabilistic AI agents?
I think currently we are testing out.
If you go to conferences nowadays, you see different approaches.
It was very interesting for me to listen during QCon London, two different approaches.
One was more, let's delegate everything to AI.
And let's focus on input and output.
While the other one was augmenting the software development lifecycle with AI.
Both of them claim incredible results.
Both of them provide some trade-offs that you need to embrace.
One is obviously trust on the first example.
The other one is more, okay, we move the needle, not 10x, but maybe 2x.
And I think this is a very interesting moment where even during the keynote, one sentence that stuck with me was, we are all juniors in this new revolution, despite what is your level of expertise or experience.
And it really resigned with me because if I think that nowadays about where we are in AI, so in the last few months, just in the last few months, in the software development lifecycle, it became AI DLC that was proposed by AWS.
claiming that how we designed the software development lifecycle over the years was mainly for human beings.
Now we need to, let's say, challenge certain practices that we had, like Scrum or Two Week Sprint, stuff like that.
And they proposed this idea of bolts, let's say, a different approach and more tailored for AI.
We have seen a gas town that made a lot of noise, where basically it's just an orchestrator for agents and is self-healing and doing.
whatever it needs to do for building software, burning I don't know how many tokens.
The creator claimed that he never seen a line of code of what was produced by AI because sometimes if there is a bug, it tries two, three times, maybe the bug reappears, but it's fine because the speed trumped the perfection.
And I would argue, you know, we start to see some glitches.
I don't know if you have a similar experience in very well-known applications recently.
There's some bugs that never...
were exposed before.
Nowadays, we start to see some more glitches.
So I believe we are trying to still figure out where is the role of humans?
I have a mental model that I'm currently using.
And it seems that, at least for me, makes sense that it's basically leveraging domain-driven design subdomains type in order to decide how much human-in-the-loop I want to have.
So if it's a core domain, it should be heavy on the human-in-the-loop parts.
Let's take Netflix as an example.
Netflix, for instance, has the video player and the catalog as a core domain because the reason why Netflix exists is that you can watch your favorite movie or series on any device at any given time and it's completely up to you to decide when and what you want to use to watch this content.
So that part, maybe you need to be more careful in my experience, especially when we talk about the broadcasting and streaming.
It's not a walk in the park.
There are...
many, let's say, information out there.
So you need to test different things, especially with live content.
And therefore, you need to have a human in the loop and you need to think and try and try on different devices.
There are a lot of unknowns that you need to figure out.
Well, when you move, let's say, further down the line, you can have supporting domains like personalization.
Personalization is nice.
It's great to have.
Everyone expects that.
But I don't think anyone will scream if they see exactly the same.
movies from the day before if personalization service is down.
So that means you already provide different architectural characteristics to this domain.
And also you can apply different AI characteristics.
You can delegate slightly more to AI maybe than before.
It doesn't mean that you should apply a mild code review approach, but you can be more flexible.
While generic domains think is something that you need to do, and even if they are not perfect, you might be happy with that.
classic example in Netflix could be payments.
You need to pay in order to watch the content, but payment itself is not, let's say, the reason why Netflix exists.
There is no key differentiator compared to Prime Video or The Zone or wherever else.
In that case, if it's integration and is basically taking the Stripe SDK or wherever other...
I don't know, Zuora's SDK or other payment SDK, and you need to integrate inside your code, there is no much novelty there, right?
So you just need to take some data, integrate your SDK, retrieve the receipt ID of a credit card that paid for a subscription, and send that to the rest of the system.
If I start to use this model with AI, you can see clearly that as I use it for architecture where I can apply different characteristics and in the team topology side where I can have, let's say, the strongest developer, most experienced developer on the core domain, and maybe having some of them spread on the others, I can do the same on AI.
I can start to say, by the way, maybe on these domains here, even if they're not...
perfectly written and there is maybe, I don't know, a bit of lack of tests or whatever, but they seem to work and they don't harm anyone, I might be able to be more indulgent and provide more delegation to AI.
While on the core side, I want to have full control.
I want to understand how the things are evolving.
This is probably a high rate of change.
So code volatility is important.
These kinds of things usually are top of mind for me at the moment when I'm thinking about where human will sit.
in this world.
And if you see also on the AI side, what we are trying to replace as soon as possible, we are talking about HR in large organizations.
We are talking about customer support.
And even with them, we need to keep some of them because there are some critical things that the AI cannot do as good as human beings.
When you start to look into the social aspect, even in large organization, they cut basically the smallest departments, not even the one that is the key one.
So that probably Towsier already where he's the mind still or the C-suite at the moment.
You don't actually want to have an AI agent lay people off, at least not yet.
What do you think of the idea from a governance perspective?
Every time you have an agent, the agent must check into a table to make sure it's not been turned off.
In other words, if you have a rogue agent, you should always be able to shut that agent off at any time.
And so there has to be obviously some element of governance in here, whether the human is in the loop or not.
Yeah, completely.
So this is a question I've asked a lot of people and no one has a really good answer for it.
So I'm not expecting any revelatory flash.
But an AI is doing all these easy tasks.
And these are the tasks that developers used to become apprentices on.
How are we going to train the next generation of developers and how are they going to develop their intuition to understand what could work, where the abstractions break down?
Because this is what bothers me.
I'm with you on this one.
The best answer I heard so far is from Kent Beck.
We were talking about pair programming for ages and mob programming for ages.
And now it's more important than ever.
Exactly for this reason.
Obviously, every single team is very unlikely that will be composed only by senior engineers or distinguished engineers.
There is always, let's say, a variety of titles and experience in the team.
Therefore, considering that the code generation is becoming faster because we don't have to write every line of code, we need to, let's say, review the code that is produced by AI.
That means we have some time to let people grow inside these things.
So if, for instance, in the past...
In every company I worked at when I was an engineer, we always have this rule that two people should review a PR.
And I think this is even more important now because if we do that, the more junior person usually provides this feedback on the code generated by AI and the more senior person as well.
So you can learn asynchronously on that part.
At the same time, you can use peer programming and mob programming to understand certain things.
I remember vividly my times as a principal when we were organizing mob programming with the tech leaders of every single team.
And we were like a dozen of people more or less in the room.
And the discussion you might think is like, oh yeah, but it's just a waste of an hour of everyone.
But the discussion was so deep and so interesting overall.
moving from, I don't know, shall we integrate generators inside the system or shall we do X, Y, Z and analyzing all the trade-off and all the other things.
And that is where you really start to learn things, having these experiences that nowadays you can call a community of practices or any other, let's say, office hours.
There are plenty of names or occasions to have regular cadence of this kind of discussion.
And I think we need to continue to do this because at the end of the day, We are doing all of this not only for delivery shipping features.
We need to deploy production.
We need to understand observability.
We need to know that when at 3 a.m.
we wake up following the run book, we know exactly how to solve a specific problem.
So there is way more that is not just code generation that we need to think about.
And the AI can help in all of that.
And I think we can potentially even accelerate.
the learnings for people.
Because if you start to chat with AI and you provide, let's say, some decent rag system on how we are used to work on a specific product, I think people can learn and onboard faster than it was before.
But at the same time, we need to remember that architecture always thought that is an enabler for an organization.
Therefore, when you choose microservices over monolith or vice versa, or distributed modular monolith, you are signaling that you want to see certain characteristics inside the social technical system.
If I think about this, it means that even with agents, the architecture we are going to choose matters.
And it will help people to think about if it's a microservice, we provide all the bells and whistles inside the microservice with, I don't know, retries, exponential backoff, and gracefully degrade the system, all these nice things that very often people don't have time to build.
We will be able to fail even in production, but not impacting the system.
And I think these kind of things...
help people to gain their battle scars in the trenches and then learn from them, despite they didn't write every single line of code.
Because in the past, we were used to write a portion of the code, but we didn't write every single line of code.
Because in a team, I take a task, someone else take another task.
I'm comfortable to read the other person's code because we try to keep the same style.
In general, I believe...
Yes, it's a challenge, but I don't believe we should be desperate straight away.
I think the community will figure out the best way to handle that.
And the companies, to be honest, I've seen many that are still hiring juniors, and I'm extremely happy to hear that because the reality, this is, let's say, the future of our society.
So we basically live with everything that is digital.
I don't remember the last time I went to a bank, probably 20 years ago.
Nowadays, for me, everything is an app.
and my bank is in an app.
Well, your safe deposit box is not quite an app yet.
But I remember there was a study where developers tried to use AI to help them understand.
And there was another control group that didn't use the AI to understand.
The two groups essentially learned at the same pace.
There's no physical difference from them.
But testing afterwards their recollection.
Those who learned with the AI had significantly less retention.
Of course.
So I think what you describe, there is evidence that this is the way you have to go.
Not only you should go, but you have to go.
Of course, because obviously it's a more shallow way to implementing a feature.
You provide, let's say, some specs.
And if you don't check the code and how it's written.
You just accept blindly what is behind that.
You cannot master it.
The mastering part is trying, making an error, let's say start to bang your head on the wall, try to figure out if there is a better way to do specific things.
That's why at the beginning I said I love refactoring because refactoring is exactly that.
Give me something chunky and complex and I will unwind it for you.
And that process is extremely important.
I strongly believe that AI should be an accelerator and a companion.
But we need still to improve our craft, no matter what.
Otherwise, it's very difficult for anyone to think, oh, but this is just code.
It's not just code.
There is way more behind that.
There is the optimization on specific things that will drive the behavior inside the browser.
Or there is an abstraction that helps you to, let's say, integrate in new systems very quickly.
There are a lot of...
ideas that people have that are difficult to express just with a business process.
Because unless you are there and you say, okay, so I know that I need to have code portability, so let's try to figure out what is the best way.
Should I apply an adapter here?
Should I use an hexagonal architecture there?
Should I decouple the environment from the business logic?
How I'm going to do that?
How I can create the portability?
How can I apply?
date, a library when there is a change of multiple systems.
So there are a lot of questions that still developers need to answer that are not merely, oh, this is the spec of implementing a feature.
Therefore, I think it's still a valid concern and we need to learn how to do these things properly.
Just to pick an example that I remember more than once in my career, paradoxically, the optimal thing to do is actually to de-optimize.
And that only comes with experience and understanding exactly what's going on.
Completely.
I remember vividly when my CTO told me, I remember everything is on fire.
You just need to pick your fire.
And in this large system, I was handling like 550 people in the tech department.
It cannot be as stretched to cover everything in different locations and so on.
So you pick your bottle.
So you decide that certain areas of the system deserve your attention, certain areas.
People are good enough for handling that situation by their own.
You just need to check that everything is fine.
And the worst case scenario, you create a system that either is self-healing or hide gracefully inside the trenches.
Even integration with system we were designing in a way that if something that we don't understand because it was a third party that we integrated failed, we just hide it.
And we create all this logic for enabling people to move on, but not compromising the platform.
And I think these kinds of discussions are extremely important.
And I honestly value a lot of discussion.
That's why architecture for me is very interesting because there are experience from other people coming from other industries that can provide you a completely different angle that you didn't think about because you weren't exposed to.
And that's part that I love the most.
Now's the time when I like to get to the architect's questionnaire.
It's always interesting to me to talk to.
people have experience in the architecture area and get their take on the more, I don't want to say softer side, the more human side.
What's your favorite part of being an architect?
So in the last five years in AWS, basically, I work as sort of a consultant, if you want, where I go to customers where they have a problem.
I try to figure out and understand the problem and then apply architectural wisdom in order to solve the problem and then line it up with AWS services.
That's basically what to do.
I found extremely interesting this context discovery.
So understanding the dichotomy of teams and the balance that they have, and they have, let's say, a set of questions that develop over the years that helped me a lot, especially because I go in a meeting and I might not know what the company is building, right?
So I start to understand how many...
teams that are and are involved in that specific project or feature.
I try to understand the resilience stand that they have.
I try to understand the SLAs and CELOs or the other things.
And this discovery of the context is very interesting because you start showing the customer or the team the holds that they have or they didn't think thoroughly on something.
And sometimes you discover that in reality, they are optimizing for something that no one asked for.
And that creates an enormous complexity that is easily solved without adding any configuration of a project, reducing the stress towards the architecture and the lowering the bar to something that is more accommodating, if you want.
Very often, you know, when I hear, oh, we need to do near real-time data.
It's near.
It's one minute.
30 minutes is one hour.
There are customers that one hour, it would be already a huge win.
Customer that with one minute, they start saying, it's not too fast for what we need to do.
Then I apply, let's say, techniques like event storming, worldly mapping, and all the other things that for me, going to a customer, I have no clue what they're doing, how they operate.
Running an event storming session was mind-blowing because in one day, I had...
I know exactly how the things are working high level and I know how the system could be designed or could be break it apart and I can start to stress it out and start to layer up some of the technology that they are using.
What is your least favorite part of being an architect?
So there are certain design back in the days that I couldn't bother much.
I mean, either because they were too simple or because they were too skewed towards a specific area that...
wasn't, let's say, super strong or whatever.
I remember, for instance, the authentication part, authorization part.
When you have done the first time, you're excited.
It's the first time you do that.
The second time, okay, yeah, I apply what I learned.
Great.
But after the seventh time that you're doing that, I can authentication authorization.
Can I delegate something?
These kinds of things are becoming a bit tedious after a while if you have multiple systems and if you move between companies as well.
So that part is becoming a bit tedious.
So yes, I know that this is important, but can someone else do that?
Is there anything creatively, spiritually, or emotionally satisfying about architecture or being an architect?
I think emotionally, it's one of the most amazing jobs that I've done in my life because when you are capable with a decision or making, let's say, the right call and you discover again over years, enabling the company to grow.
Obviously, you are just a cog in a large system, right?
But still, you know that that decision was your decision.
You say, okay, yeah, we should go in that direction.
And you see the feature that is going there or the system is going there live.
It's working.
The customer loves it.
Everyone that did a great job and whatever.
You become extremely proud of your work.
Remember...
Very, very vividly, a couple of years ago, when I already left my previous company, The Zone, for a while, the principal engineers from Amsterdam met me in a conference that was telling me, look, I have to tell you these things.
It's eight years that we're doing micro front ends.
It didn't change anything about your architecture because it's still enabling us to have the right level of flexibility, maintaining a solid standing that everyone understands.
That for me is the most rewarding sentence that I have.
for ages because having an architecture that lasts for that long, like eight years, obviously in the past was different, but nowadays it's mind-blowing, especially because it was extremely cutting edge.
No one did the scale that we operated, that specific architecture.
I have to create patterns, anti-partners, the vocabulary of the architecture and everything.
And having someone that is experienced like this person that have worked in multiple companies.
And saying, hey, you know, after eight years, he's still there.
He's still delivering what was the idea.
And still remember that moment.
So on the flip side of that, what turns you off about being an architect?
So we know that communication is important, right?
Yes.
There are, although certain people in a certain organization, I think it's more cultural sometimes, that they hide behind titles.
I don't know.
It's probably a me mindset.
I'm not saying that other people has the same thing.
Maybe they do.
I don't know.
But I don't care about the titles.
For me, we are all human beings.
We have a brain and you have experience and expertise no matter what.
Using that leverage for not fighting on the same table, fighting is like discussing on the same table and just, let's say, using your title to shut off the discussion is not something I appreciate.
I totally agree with you.
This is one of the reasons why, for example, I have a PhD, but I never put that on my business card.
I know people have PhDs and they're on their business card as it says, I don't want it to be on my business card.
I either know what I'm talking about or I don't know what I'm talking about.
And the fact that I have a degree has nothing to do with that.
I agree.
And there are splendid people that I met over my 20 years in the career, obviously.
Sometimes it's very cultural because they didn't expect that I was able to develop or programming or do impair programming.
And for me, it was, okay, but I'm one of you.
I'm working in the same company.
I want to achieve a specific goal that is exactly the same goal that you have.
If I can, and I have time, I will cut my arm in order to succeed in specific things because I have this sense of community.
You have a degree, I don't.
I left school when I was 16.
So I learned with the community.
I worked in a factory for a while, but then I studied overnight and not in my language because in Italian, there weren't many back books back in the days.
So therefore I have to order from Amazon.com my books and learn English.
I didn't know anything in English.
So for reading a book, it took a month or more and slowly but steadily then apply this stuff and these learnings.
I learned in this way.
I learned with the community where social weren't there or video courses weren't there.
You just open a request on a forum, hoping that someone will reply to you.
And because obviously it was everything in Italian, you have like a subset of the world that can reply to you.
So that stick with me till now.
For me, I try to do in the beginning, when you introduced me, you have seen that I did like public speaking and newsletters, podcasts, et cetera, because I still believe that there is somewhere, someone.
that is waiting for that content like I was doing back in the days and try to cut through the noise and figure out if my content lands in somehow, because I feel lucky that I've seen a lot of stuff in my career and I don't want to hold it, honestly.
I think it deserved to go out and maybe I learned something new, maybe someone else learning something new.
Either case is a win for me.
This is why I enjoy doing this podcast.
I don't need to do this.
It doesn't really benefit me much personally.
Except psychologically and emotionally, I feel that I want this knowledge from different practitioners to be spread throughout the community.
Because as you said, there's book learning and there's actually being in the trenches with the battle scars.
And that's where the real knowledge happens.
Do you have any favorite technologies?
Yes.
I do, obviously, as everyone.
But at the same time, I tend to be balanced when I decide what to go with.
But in general, a combination that I found myself working pretty well is definitely JavaScript with serverless, especially people complaining about working at scale with serverless might be a challenge.
Nowadays, I would say that that problem is, I cannot say, solved for everything.
for a good chunk of use cases is solved.
I remember my previous system, we started in 2015 to work on that.
We moved from VMs to serverless using Lambda on AWS.
And we were one of the largest companies doing that in EMEA.
And that was like mind-blowing, to be honest, because it was just Lambda.
DynamoDB didn't have global tables.
They didn't have many other things.
And slowly but steadily, I grew with this thing and more I was using.
And more I realized that I was able to express my architectural thoughts better than just having a container orchestrator here and there.
Because spinning up a queue was a breeze.
And I want a broker, I want an orchestrator.
Do I need to communicate asynchronously for a chunk of my domain and another part of the synchronous?
I can.
I think this flexibility for me was mind-blowing with honestly little.
effort for spinning up stuff because it was infrastructure managed by someone else.
Obviously, with this at the beginning, especially with their limits, but when there are limits, usually creativity starts to kick in.
So you start to overcome these limits in different ways.
At the end of the day, we were dealing with a platform of three, four millions.
customers.
So it was like a small platform that you can find, let's say, that doesn't work.
And we have like huge spikes of traffic.
So designing things was challenging, no matter what we were using, even probably with serverless sometimes is slightly more.
But we used a very nice combination of serverless and, let's say, containers through Fargate in that case.
And it was like quite a nice combo.
What about architecture do you love?
I think it's solving problems.
That's the part that I love the most about architecture because I was an engineer at the beginning of my career.
So I saw a lot of problems through code and I love working on unconventional places like embedded system, for instance.
You have like some quirkiness that you didn't expect.
Then moving to mobile when iPhone and Android came out were extremely interesting.
I remember when we were working in gambling, some games.
didn't work as expected inside certain Android browsers, especially with Android 2, Android 1, because the browser were so fragmented that even a simple CSS implementation like onload the CSS didn't work because it wasn't implemented in the browser.
So you start to have this fragmentation, that kind of problems that I had in engineer.
Now I translate into architecture and it's even more challenging because now there isn't one dimension like...
Oh, the browser doesn't work.
My feedback loop is very fast.
Here, the feedback loop is way longer.
And therefore, experience, trial and errors, learning from others, this chatting with other people, try to figure out the different ideas, see which one sticks better, maybe running a POC, document this thing, understand why a certain decision was made in a certain period of time.
All these kinds of things for me are extremely fascinating.
I found a lot of pride on doing this job.
Conversely, What about architecture do you hate?
I would say people thinking that the architecture is a problem, while it's not that the architecture is problem, it's just signaling certain things inside the social technical system.
Probably you have experienced something similar.
You work in a company when the first problem arrives inside the trenches is, oh, the architecture is wrong.
Without even thinking about, okay, did we analyze if it's, I don't know, the commit that was wrong, the code was wrong.
Are we structured properly for enabling this architecture?
So I think, let's say, it's the most visible thing compared to people, engineers or product, et cetera.
Are we structured correctly?
I mean, if I choose to go with Elixir, for instance, and I have, let's say, a bunch of people that are coming out from university, and probably I need to figure out something that is less complicated.
To start with, obviously, if I work on a very complex system and an elixir is needed, or I want to use, I don't know, ACCA with an actor model implementation, I need to adapt this architecture for a specific context.
So in my opinion, architecture is just there for sort of facing good and bad things.
Friction, I always interpret as a gift because it's a feedback that architecture provides you.
It's telling you something doesn't work.
And that's something that might not be in the architecture space.
It could be that maybe we designed one thing that was working in the past, but now suddenly the team grows so much or they split in a way, but the code is still needed to be collocated.
And therefore the friction arise because probably we over-index on the teams, we should redesign the teams in order to have better things.
Not necessarily the architecture is wrong.
or distributed system are wrong, or monolith are wrong.
I think architecture, all of them are still useful nowadays.
There are some of them maybe less than others, but I still believe that having these people that immediately put their things, oh, this is too complicated, I don't want to even see, it's not something that honestly turns me off.
And sometimes it's some people don't appreciate that there was a trade-off that was made.
Yes, we consciously made this case not to be optimal because we had to achieve.
something else.
It's that same lack of perspective.
Exactly.
Thinking about holistically on the system is the other challenge that happens very often.
I think it comes with maturity and experience.
It's not, let's say, that you have for free.
I probably was similar to those people at the beginning of my career because I didn't see holistically on the problem.
What profession, other than being an architect, would you like to attempt?
The first one, I would like to do street food, Italian street food in London.
That's definitely a plan C for me.
I was always interested that I think overlaps with the skillset of an architect to a certain extent.
Is this idea of advocate or let's say developer advocate or evangelist or stuff like that?
Because I really love taking complex ideas and trying to unwind in a way that are bulletproof.
And I think...
It's a skill.
It's not something that everyone can do.
You need really to go deep into that specific problem, understand deeply and remove all the noise, cutting through the most bare minimum implementation that you build on top of that.
This is something that I really enjoy because recently I just published my second edition of Building Microfrontends book.
And the feedback that I have most recurrently this time is I cannot...
think something that is more clear on how you have written this book.
Everything that is there is simple.
And I don't get why people don't get it.
But in order to be simple, it's 10 years that I'm working on that.
Yes, yes.
Sometimes it takes you 10 years to get to simplicity.
Because to achieve simplicity, you have to learn what really has to be there and what is not necessary.
And sometimes you only see that with experience.
Yes.
And you need to try and try and try.
You are bored of hearing your voice.
Yes.
Yes.
Do you ever see yourself not being an architect anymore?
I don't know.
I would say the industry will decide.
It's not up to me.
I can continue till the end of my life, to be honest, because I really love what I'm doing.
It's the most interesting things that honestly I have seen.
I have an opportunity after being VP to move towards more ministerial.
career path, the people of engineering or director or CTO, et cetera.
I ditched those opportunities mainly because I think I still have something to do and to say on the architectural space.
And, you know, I didn't expect AI back in the days when I took that decision.
But I believe now it's even more important that what I've learned, what other people have learned there in the trenches can help.
new joiners in the industry as well as experienced people to rationalize better what's going on with AI and how much to trust.
I've seen this more balanced approach of the architectural community compared to the fanboy approach that other companies or communities are doing.
We can do everything with AI.
Absolutely.
You can do everything with anything, but it doesn't mean that because you can, you should.
And I think it's important that this message lands properly.
I started to write a few articles recently on this kind of discussions that I did at conferences or watching online content.
And they land very well with a few people that reach me out saying, oh, finally, a point of view that is not indexing too much on one side or the other one.
It's a balanced approach and it highlights the trade-offs.
When a project is done, what do you like to hear from the clients or your team?
First of all, when a project is done, we should cheer about that.
No matter if it's like perfect or not, it doesn't really matter.
We achieve something is a milestone.
Personally, I don't expect a thank you or anything.
It's not because I feel that it's perfect.
I've just done my job.
And therefore, I'm more interested to wait six months, one year and see if we have done our job properly.
Therefore, my gut tells me that I'm still nervous.
even after the release.
And not because I'm not confident, it's because I know that that is one part of the game.
In previous companies, I spent, you have no idea how much of my time and during the weekend, especially going to the war rooms in different companies to see how the platform behaves live.
because I found extremely interesting that experience.
They were, let's say, watching, because it was like sports company, the previous one.
They were watching the matches and keeping an eye on the dashboard.
I was watching the dashboard and keeping an eye on the matches.
Even if your favorite team was playing.
Exactly.
It doesn't matter.
I just saw the New Relic or the dashboard and said, oh yeah, there is a spike here.
What does it mean?
We need to check on Monday.
Stuff like that.
Never mind the winning goal was just caused.
And that caused a spike.
It's not a problem.
Someone has to win, someone has to lose.
That's fine.
Well, thank you very much for appearing on the podcast.
I enjoyed this conversation very much.
I think we touched on several important things for the future as well as the present.
So I would like to thank you.
Thank you.
Thank you for having me.
I hope that this conversation was helpful also for all our listeners.
Yes.
Thank you very much.