Educating an Architect: A Conversation with Luca Mezzalira Transcript, AI Summary & Key Points

00:00 Get a fresh perspective on your engineering decisions with InfoQu's online servitation 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.

00:26 Four hours of live sessions weekly for five weeks. Explore certification.conferences.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 Mezaler, 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.

00:59 At DAZN as vice president of architecture, he led the migration to microservices and microrends 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, eventtorming, and distributed systems design course retail, travel, finance, insurance, media, energy, healthcare, and the public sector.

01:29 Many years were spent developing microrends from a nent 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 microrends because of his efforts. He has delivered over 350 sessions at many conferences throughout the world.

01:54 Currently he facilitates the qcon infroQ 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 microrends newsletter. His obsession to use his own words is taking the hardest architecture concepts and making them impossible to misunderstand.

02:22 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 and 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.

02:42 Definitely, you don't wake up and you became an architect despite I wish uh it was that easy. I think it's a natural evolution that of the engineering role at least in uh my time we didn't have let's say all these different titles fancy titles there are uh 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 abstract yourself and start to see more problems more challenges and so on and

03:17 so forth. So I decided to go with the ladder despite a good chunk of my career was also in in management but with always keeping an eye on on the tech side because uh 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 spend a lot of time even doing pair programming back in the days with engineers despite that was B of architecture because the reality is I like solving problems and doesn't matter which

03:47 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 was uh important so how I became an architect what I realized during the the years is that the part that I love the most while I was an engineer it was the refactoring part mainly because uh I like a lot let's say understanding how people implemented something trying to crystallize in my head if that was a a good decision for the situation we were at the very moment more than six or

04:24 month ago or a year later or a year ago and then I love the at the beginning of a green field project spending time designing understanding the business problem understanding the context where I was operating and then I I discover over the years reading a lot of books that that wasn't let's say something accidental I was doing it was let's say a clear path towards let's architecture and designing systems that slowly but steadily became my profession but with some bumps I would say because um as you can imagine there is

04:54 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 uh this approach where I was designing by my own and try to solve the problems that other teams have and trying to see if uh my ideas were uh let's say sim similar to what uh 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

05:25 understand how they were talking how they were thinking basically stealing their secrets to 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 say you know it's not a bad idea what you're saying it's a good perspective and uh 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 as a principal engineer I design a lot of system I design

05:56 a massive say modernization of a gambling company where I was working on I was a tech leader of real money gambling department with hundred of people in a company called games that then was acquired uh in the last few years in London and uh and there basically I was able to convince the CTO and the architect and my colleagues to migrate to a more uh let's say simpler framework for building gambling games.

06:23 So we move from nine months uh 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. uh was a CTO and there basically uh we help companies to simplify their integration with ERPs and uh with the crazy project like working on a Ducati motorbike dashboard or

06:58 working on a sort of 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.

07:20 Great artists steal. >> Absolutely. That's my mantra. >> This also brings to mind 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.

07:55 The developers very often have to be very very careful. You know, you build a table. If one of the legs on the table is not strong, you can still use the table. But in the 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?

08:20 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 uh the person that tried to balance the discussion and the decisions that uh 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 uh currently talking about this is the domain driven design community more than others because we realize that we are not designing architecture for

08:51 the sake of let's say technical reason we are designing for the organization uh communication structure as the conway law uh 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 like amazing minds but some of them they were extremely good on their craft that was writing code that didn't want to go

09:23 around the company speak with product speak with developers speak with other teams. They were master 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 was that they were capable to do that. While this role was more looking holistically on uh the problem space that is not merely the technical one but also is the social one.

09:54 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 capable because working in embedded systems is not a walk in the park. Every bite count, every line of code count.

10:17 So uh you need to to put a lot of effort and try and trial 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 to succeed and to become a better version of themselves? And that was for me very interesting because uh behind that there was a challenge that lies behind if you want bureaucracy different uh uh line of business and different layers inside an organization and I found extremely fascinating this part because no one

10:56 wanted to do that let's say bothering all these people in order to align them and having 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 is could be interesting then many people every time that I I did big things in in in architecture they always told me oh why you bother like at the end of the day they are paying you no matter what but for me you know it wasn't it was the the the challenge that it was

11:23 uh very interesting not the technical implementation whatever the challenge of convincing everyone and aligning everyone that we might be in a better place if we do xyz and that for me was the the reason why I became an archet slowly but steadily and they spend a lot of time studying because as you know there isn't let's say a proper training for architects I mean yes there are toaf and all the other different certifications but it's not that they are telling you how to be an architect in terms of communication

11:54 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 trench changes over the years because when you take an architectural decision, it's not materializing next week or next month. It's 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 or even longer in certain cases.

12:22 Therefore, if you are capable to create something bulletproof for the future because you cannot predict the future, but you create 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.

12:46 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 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 strength of some people and they don't smooth every corner.

13:05 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 express himself or herselves. And I think it's very very important learned that I gained over the years and enables me over over the years even to understand that in reality there is always something that I can improve no matter how harsh a comet is or how positive a comet is in general you know feedback for me is a gift and uh I want to make the most out of it

13:39 despite is negative or positive because the negative part is just a step closer to improving your uh solution and therefore if you start to think with this mindset any kind of feedback is extremely important and uh I have seen that it became a very contagious mindset over the 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 the shoes of the other person and trying to make a step towards them

14:10 more than uh moving on the other side so I think u this part of the where communication back in the days was a soft skill I always refer as as a a core skill no matter if you are an architect with the title or a developer nowadays especially with AI where let's say we start to have a slightly more time for uh implementing uh features because the creation of code becomes let's say you know canot say a commodity but becomes let's say easier to certain extent compared to what was in the past and therefore I believe that

14:42 this architectural mindset that covers not only the technical part but also the social part uh will be extremely beneficial for any single tech person that is navigating this AI era. I am very sympathetic to that sociote techchnical 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 it was this is very interesting listening to you talk about feedback that people very often don't give feedback because they're

15:21 afraid of the managerial repercussions of the feedback. So I 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 then you've raised the spectre uh 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.

15:48 So communication sort of becomes 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 let's say a very pragmatic take on the education side. I believe that no matter what what is your title you need to have these skills.

16:15 I'm witnessing a decentralization approach on architectural practices across the industry. Not every single company but there are certain industries uh especially in more modern companies that they were born in uh the SAS era I would say they started to decentralize a lot towards developer sense but there isn't let's say a 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 uh is provided to them also because I don't believe

16:45 architecture can be only taught with lectures or uh let's a uh frontal education. I think it has to be collaborative. You need to learn the skills on on communicating. I think you need to properly design. Think that the narrow behind the narrow there is a lot that is hidden and you need to go in different level of depth. Therefore, even the uh let's say the most technical developer could find some benefit of talking or thinking like an architect because uh they can better understand the problems of other teams and the

17:22 company itself. When I think about education for architects, I want to have something that isn't on like Katas. I know for instance Neil Ford is a big fan of of Katas 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 Katas where multiple teams in all over the world they submitted their projects based on a scenario.

17:43 It was quite fascinating listening to them on how they are thinking about uh the architecture characteristics and analyzing the other proposals was extremely helpful for me. But in general, you know, you need to think more holistically on 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 for reading for people.

18:10 Then 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. Uh 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 uh that we can uh see how other people have taken a specific problem. We need also to understand the context.

18:32 Very often I've seen in conferences a very interesting behavior from uh from speakers where they were saying oh we move from microservices to monolith because microservices are evil. And I once I did an exercise after this talk about uh moving from microservices to to monolith and I went to the speaker in private and said listen can you tell me a bit more about uh your uh team structure and she was telling me oh yeah because before we are we were five teams and we have 10 microservices and now we are just one team and

19:00 we have a monolith. I said okay but that was an important detail to 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 for developers to try always look holistically about uh 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 surface in a conversation or in a talk

19:31 or a book. So uh I I always um tend to understand first the context because I know probably you are quite familiar with the statement oh yeah we are using 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 they say okay so but but then what was that was a scam no it's not a scam they aim for they shoot for the northstar and they arrive halfway through and it was good enough or they understood that the

20:01 effort for putting in place everything like they design it was too high but at the same time they have a specific engineering culture it's not like there are too many Spotify in the world what works in Spotify works in Spotify because Spotify has a certain way to interpret the life of an engineer similar to what is happening Google in Amazon or wherever it is so I think is is context should drive certain decision and I understood that best practices or patterns and antiatterns sometimes can leverage.

20:32 No matter if we think it's written in a book black and white that is bad for 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 uh it might not fit inside their context. For example, you mentioned Spotify or Netflix or Google.

20:54 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 things that no one else is thinking about.

21:33 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?

21:58 To be honest with you, I strongly believe that architects uh in uh the current term of uh of the role should evolve into a sort of enablement team like we think about in topologies if you want like security. For me the example of security is is quite crystal clear. Usually think about how many security people you have or how large is a security teams inside an organization is probably one security architect 20 developers something like that.

22:28 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 uh I could push even further. It's the idea of uh helping developers to take architectural decision. Andrea Harlo discussed very well this part on the advice process where you decentralize everyone can design something but then you need to create some guarders 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

23:02 consume the API and let's say some people that have a expertise that should review the design of of a specific area of the system and this basically group of people is more fluid than a formal architecture team should uh let's say uh decide the direction of travel and I really like this democratization of uh uh designing architecture in general because I believe it's not sustainable you cannot have let's say one architect every two teams because you know the cost will surge like drastically but thinking about being an

23:35 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 span across multiple domains and it happens every single time it's like two or three or five per years that you need to take a problem is that there is biases if you are inside the team right so I try to

24:08 make the best in my team in order to succeed the the gamification of promotions in general in uh in every single company is trying that the the best person will succeed and therefore deliver most for the company and so you are you deserve a promotion for me you know 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 question that are not let's say too

24:39 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 this kind of figures I think will help a ton in company that have uh I don't know 50 100 people because no matter what having someone that looks solistically on that would be helpful but also could be the one that provides guard rails for the entire system.

25:02 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 AI or not like uh okay I want to create some fitness function that make sure that my system behave in a certain architecturally behaving in a certain way and I think this is the part that architect can contribute can own the holistic view of the system can provide guard rates can also surface patterns that are happening inside a specific team for all over the the

25:36 organization there 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 design let's say at 9 in the morning you start your job you design the architecture and then you go and just talk with people is shifting a bit I feel that we need to do more than just design architecture usually at my team in 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 be the

26:06 most technical one, but be technical and understand what's going on inside the system. And the emphatic 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 this thing say by the way you know that in two months time we need to implement this specific feature and we'll invalidate your this specific decision for this reason that reason reason because at the end

26:34 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 the code creation but still we need to we shift left for the DevOps part. We shift left for security. We shift left on on architecture. We shift left on on writing code obviously. And if you think about at early 2000 you were writing code.

26:58 You write the test and then you thrown on the other side of the fence for someone in the DevOps team that you didn't even know the name of 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.

27:25 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 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?"

27:47 And that is, I think, what you're saying about the role of an architect. They almost become a supermentor. They still need their technical chops, but they're sort of the super mentor, which then raises the question, and I and I know you've talked about this before. If you're using AI agents, you have to differentiate between knowledge and purpose or wisdom.

28:16 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.

28:40 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 is going to fail miserably. And we might argue that my lack of resilience, in my lack of scalability and so on so forth, but you know there are certain projects that don't need any of those.

29:04 Obviously we are talking about small projects. So this is probably the long tale of software. But when you are in in midsize large organizations there is a lot of context that is hidden over the years. Sometimes in documents, sometimes in people ahead it's complicated. surfacing the the context is 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 probabilistic system that majority

29:36 of the time might recommend that the right things to do but not all the time. There are a lot of things that are inside 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 talk together in order to understand what we are building because if we don't understand what we are building then we cannot feed agents or whatever else with the ideas and on top of that if you see the evolution of this uh revolution we

30:12 started with the MCP that didn't have any authentication now I don't recall any game 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 open source project people that are installing agents in their computer giving them access to their credit card or their email or whatever it is.

30:36 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 security should be a system if a system leaks credit card is basically instantaneously in all the newspapers in the world.

31:02 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 for thinking in my opinion. But I don't believe that every single role will be fully replaced by AI today.

31:24 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 raming in the proistic AI agents?

31:55 I think uh currently we are testing out if you go to conferences nowadays you see different approaches was uh very interesting for me to listen during cucon London two different approaches one was more let's delegate everything to AI and uh let's focus on on input and output while the other one was augmenting the software development life cycle with AI both of them claim incredible results both of them provide some uh trade-off that you need to embrace.

32:28 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 very interesting moment where even at during the the the keynote uh 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 nowadays about where we are in AI so in the last few months just in the last few months in the software development life cycle it became AIDLC

33:03 that was proposed by AWS claiming that how we designed the software development life cycle over the years was mainly for human beings now we need to let's say challenge certain practices that we we had like scrum or two week sprint stuff like that uh 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 he needs to do for for building

33:37 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 reappear but it's fine because the speed trump the the perfection and I would argue you know we start to see some glitches I don't know if you have similar experience in very well-known applications Recently there's some bugs that never were exposed before.

34:02 Nowadays we started to see some some more glitches. So I believe we are trying to still to figuring 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 makes sense that is basically leveraging domain driven design subdomains type in order to decide how much human in the loop I want to have.

34:24 So if it's a core domain, it should be heavy on the the human in the loop parts. Let's take Netflix as an example. Netflix for instance has a the video player and the catalog as 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 uh it's completely up to you to decide when and and what you want to use to watch this content.

34:50 So that part maybe you need to be more careful in my experience especially when when we talk about the broadcasting and streaming is now 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.

35:10 There are a lot of unknowns that you need to figure out. Well, when you move, let's say uh further down the line, you can have supporting domains like personalization. Personalization is nice to it's great to have everyone expect 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.

35:30 So that means you already provide different architecture 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're not perfect, you might be happy with that.

35:54 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 or the zone or whatever else. In that case, if it's integration and it's basically taking the stripe SDK or whatever other I don't know Zora's SDK or other payment SDK and you need to integrate inside your your code, there is no much novelty there, right?

36:23 So you just need to take some data, they integrate your SDK, retrieve the receipt ID of of a credit card that that paid for a subscription and send that to the the rest of the system. So 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.

36:53 I can do the same on AI. I can start to say by the way uh maybe on these domains here even if they're not perfectly written and there are there is maybe I don't know a bit of lack of test or whatever but they seems to work and they don't harm anyone I might be able to be more indulgent and provide more delegation to AI while on 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 kind of things usually

37:25 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 eye side what we are trying to replace as soon as possible we are talking about HR in large organizations we're 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 don't

37:56 even the one the visa the the the key ones. So that probably tells you already where is the mind or the seauite 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.

38:20 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. on on not expecting any revoly flash.

38:44 But in 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. Well, I'm with you on this one. The best answer I heard so far is from Kent Beck.

39:15 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 engineer. There is always let's say 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 I that means we

39:41 we have some time to let people grow inside these things. So if for instance in the past in every company I work when I was 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 I and the more senior person as well.

40:06 So you can learn a synchronously on that part at the same time you can use pair programming and mo programming to understand certain things. I remember vividly my times as a principal when we were organizing more programming with the tech leaders or every single team and we were like a dozen of people more or less inside 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 were so deep and so interesting overall moving from I don't know shall we

40:37 integrate generators inside the system or shall we do xyz and analyzing all the tradeoff and all the other things and that is where you really start to learn things having these experiences that nowadays you can call 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 deliver shipping features we need to deploy

41:06 production we need to understand observability we need to know that when at 3:00 a.m. We wake up following the RAM 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 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 on

41:38 board faster than was before but at the same time we need to remember that architecture always thought that is an enabler for an organization ization. Therefore, when you choose microservices over monolith or vice versa, 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 mothers and it will help people to to think about if it's a micros service we

42:07 provide all the bells and whistle inside the microser with I don't know retries exponential off 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

42:39 every single line of code because in a team you know I take a task someone else take another task I'm comfortable to read the other person code because we try to keep the same style in general I believe yes it's it's a challenge but I don't believe we should be desperate it 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

43:09 society so we basically live with everything that is digital I 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 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.

43:41 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

44:19 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 who there is a better way to do a 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.

44:40 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 has that are

45:12 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 it out what is the best way should I apply an adapter here should I use an exagonal architecture there should I decouple the environment from the business logic how I'm going to do that how again create the portability how can I update a library when there is a change of multiple systems so there are a lot of questions that still developers needs to answer

45:43 that are not merely oh this is the spec of implementing a feature therefore I think is 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 deoptimize 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.

46:15 You just need to pick your fire and in a since large system I was handling like 550 people in the tech department. I cannot be as stretched to cover everything in different location 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.

46:38 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 trench is even integration with system we were designing in a way that if something that we don't understand because was a third party that we integrated failed we just hide it and we created all these logic for enabling people to move on but not compromising the platform and I think these kind of of discussions are extremely important and I honestly value a lot of

47:07 the 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 completely different angle that you didn't think about because you didn't you weren't exposed to and that's the part that I love the most. Now is the time when I like to get to the architect's questionnaire.

47:26 It's always interesting to me to talk to people of 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.

47:47 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. But that's basically what I do. I found extremely interesting this context discovery. So understanding the dichotomy of teams and the balance that they have and they have like say a set of questions that develop over the years that help me a lot especially because I go in in a meeting and I might not know what the company is building right so I start to understand how

48:20 many teams there 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 soloso all the other things and this discovery of the context It's very interesting because you start showing the customer or the team the holes 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 create an enormous complexity that is easily

48:54 solved without adding any configuration of a product. 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 realtime data is near 1 minute is 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 even storming worldly mapping and all the

49:24 other for me you know going to a customer I have no clue what they're doing, how they operate. Running an even stormy 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.

49:47 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 are done the first time you're excited first time you do that.

50:13 The second time okay yeah I apply what I learned great but after the seventh time that you're doing that oh again authentication authorization can I delegate some this kind of things is becoming a bit tedious after a while if you have multiple system 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.

50:50 I think emotionally it's one of the most amazing job that I have 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 See it's everyone that did a

51:21 great job and wherever you become extremely proud of your work. I 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 and was telling me look I have to tell you these things it's eight years that we're doing microphone tense we didn't change anything about your architecture because it's still enabling us to have the right level of flexibility but maintaining a solid standing that everyone understands

51:53 that for me is the most rewarding standards 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 was extremely cutting edge no one did that the scale that we operated that specific architecture I have to create patterns antipatterns the vocabulary of the architecture and everything and having someone that is experienced like this person that have worked in multiple companies and saying yeah you

52:23 know after eight years is still they still deliver 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 this certain organization, I think it's more cultural sometimes that they hide behind titles.

52:48 I don't know. It's probably a me mindset. I'm not saying that other people has the same thing. Maybe 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 uh 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 that I appreciate.

53:18 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 a scientist. 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.

53:39 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 they was able to develop or programming or doing 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 like cut my harm in order to succeed in specific things because I have this sense of community you have a degree I

54:10 don't I left school when I was 16 so I learn with a community I working in a factory for a while but then I study overnight and not in my language because in Italian there weren't many black 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 month or or more and slowly but sadly then apply this stuff and these learnings.

54:32 I learn in this way I learn with the community where social wen'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 I try to do in that beginning when you introduced me you have seen that I did like public speaking and newsletters podcast etc because I still believe that there is somewhere someone that is waiting

55:01 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 deserve to go out and maybe I learned something new maybe someone else learning something new either case is a we 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

55:35 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 completely. >> 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 as definitely JavaScript with serverless especially at you

56:11 know 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 but for a good chunk of use cases is solved I remember my previous system we started in 2015 15 to work on that. We moved from VMs to serverless using lambda on AWS and we were one of the largest company doing that in AMIA and that was like mind-blowing to be honest because it was just lambda dynamob didn't have global tables didn't have many of the things and

56:41 slowly but sadly 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 uh containers 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 synchronous?

57:05 I can. I think this flexibility for me was mind-blowing with honestly little effort for spinning up stuff because was infrastructure managed by someone else. Obviously with this at the beginning especially with their limits but when there are limits usually creativity start to kicks 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.

57:31 So, it's wasn't 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 serless 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.

57:53 >> What did that architecture do you love? I think is solving problems. That's the part that I I love the most about architecture because I was an engineer at the beginning of my career. So I solve a lot of problems through code and I love working on unconventional places like an edit system for instance you have like some quirkiness that you didn't expect.

58:15 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 one, 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.

58:42 So you start to have this fragmentation that kind of problems that I had in in engineer now I 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 PC document this thing understand why a certain

59:13 decision was made in a certain period of time. All these kind of things for me are extremely fascinating. I found a lot of pride on doing this this job. Conversely, what architecture do you hate? I would say people thinking that the architecture is a problem while it's not that the architecture is problem is just signaling certain things inside the social technical system.

59:39 Probably you have experienced something similar. you work in a company when the first problem arise 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 commits that 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 etc are we structured correctly I mean if I choose to go with big year for instance and I have let's say

01:00:13 a bunch of people that are coming out from university then probably I need to figure out something that is less complicated to start with obviously if I work on a very complex system and elixir is needed or I want to use I don't know aka with an actor model implementation I need to adapt this architecture for a specific context so in my opinion architecture is just there for surfacing good and bad things friction I always interpret as a gift because it's a feedback that architecture provides you it's telling you

01:00:42 something doesn't work and that something it 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 grow 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 overindex 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 or monolith are wrong I think architecture

01:01:11 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 on. >> And sometimes it's some people don't appreciate that there was a tradeoff that was made.

01:01:27 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.

01:01:54 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 pen C for me. I was always interested that I think overlaps with the skill set of an architect 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.

01:02:27 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. Then you build on top of that. This is something that I really enjoy because recently I just published my second edition of building microphone dance 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.

01:03:02 Everything that is there is simple and I don't get why people don't get it. But in order to be simple is 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.

01:03:27 >> Yes. And you need to try and try and try till you are bored of hearing your voice. >> Yes. Yes. Do you ever see yourself not being an architect anymore? >> I don't know. Uh I I would say that 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.

01:03:49 I have an opportunity after being VP to move towards more managerial career path VP of engineering or director or CTO etc. I ditched those opportunities mainly because I think I still have something to do and to say on the architecture space and you know I didn't expect AI back in the days when I took that decision but I believe now is 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

01:04:25 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 than other companies or communities are doing where oh we can do everything with I absolutely you can do everything with anything but doesn't mean that because you can you should and I think it's important that this message lands properly I started to write few articles recently on this kind of discussions that I did at conferences or watching online content and they land

01:05:00 very well with 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 balance 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.

01:05:22 We achieved something as 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 6 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.

01:05:51 In previous companies I spend, 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. I they were let's say watching because it was like sport company the previous one they were watching the matches and keeping an eye on the dashboard.

01:06:14 I was watching the dashboard and keeping an eye on on on matches >> even if your favorite team was playing. >> Exactly. It doesn't matter. Just saw the new relic or or the dashboard and oh yeah, there is a spike here. What does it mean is we need to check on Monday. Stuff like that. I can't >> never mind the winning goal was just that caused the spike.

01:06:36 >> It's not a problem. Someone has to win, someone has to lose. So 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.