My name is Mia Grea. I'm a software engineer. And besides this uh passion for technology and uh you know, everything that has to do with uh with tech, um I also enjoy uh presenting uh and preparing content for sessions like this.So I'm very happy to, to be here today uh being part of such an amazing lineup of speakers a bit about me. As I was saying, I'm a software engineer also uh I like through the uh Community Act activities that I had to also uh have the opportunity to, to be a Microsoft MVP. And when I'm not coding or speaking, I like to do all sorts of things in the, in the, you know, nature or if it's uh not a good thing, period for uh for nature things. So maybe just read and uh blog a bit. Well, the discussion that I want to propose to you today, it's not supposed to, you know, revolve your world around with technical concept. Actually, today, I'm a bit, although passionate about this part, I'm a bit um let's say, looking from the other side. So let's say that for technical things, when you want to learn something. It's pretty easy to, you know, just go, uh, find some training, find some tutorial, uh, ask someone maybe.

But we, we have some pre predefined uh scenario that we can go with or someone somewhere already had this issue. So we just go maybe and the open uh a forum and find some answers. But when it comes to team dynamics, when it comes to tackling risk, uh when it comes to dealing with difficult situations. So when it comes to actually uh checking, if the team is engaged with the product that we are building, it's, it's a bit harder because, you know, you don't find uh a solution or a way to do. There is no perfect way of doing this. There is no, you know, people um are so different and uh teams are so different and products are so different. So there are a lot of situations where we can go uh with. So it's a bit difficult to prede find this and it seems that we are just sometimes we are just ignoring this part and just going with the technical things, you know, like uh OK, we are just going to focus on, especially in our domain on being very smart and knowing a lot of information.

And yeah, we kind of uh ignore this uh this side of the story. So today I want to discuss about in the context of the team about what is architecture and along the way actually, while searching uh for definitions, you know, preparing this presentation and trying to see exactly what is the overview, I think to see that actually something that uh is not really uh very well defined.

And although there are a lot of definitions and a lot of uh um let's say uh ways of seeing this, well, there is not really something that developers can understand. So basically, my conclusion is that uh uh we use very abstract definitions for things like this like architecture.

So this is why it seems that it is not approachable most of the time for developers. So just to make it a bit uh simpler, let's think about architecture at like some base of structure that we start with and that we be able upon. Yeah, that can change in time. It can evolve, it can change also but is a structure that helps us understand exactly how our components are interacting with each other. Yeah, high level components and how exactly they are evolving in relationship with each other. So basically, this is where we are, where we are actually trying to, to think about this. And we were discussing about um about high level uh components and we were discussing about uh let's say, OK, if it's high level and if we are discussing architecture must be something important, must be something that we have to be very sure of in the moment that we are making decision about it.

And it's true. But at the same time as we are discussing, this is something that evolves in time. So we can think about it as something that is very fixed and the decision that I'm making in the beginning, it's just going to stuck with me for the rest of uh this product's life. And since we're discussing importance and uh high level uh component, I would like to just see a bit what is defining what is significant and why is significant in a product. So how exactly do we see? OK, this is something that um it's high level of things that I have to be very sure of. Uh when I'm thinking that in thinking of in the beginning, because it's something that it will take a lot of involvement and a lot of resources to change later. And what is not so much. And the thing that I have is I always look around me. So yeah, you know, when we are discussing architecture, it's inevitable, you know, to just look at building architecture and see exactly how they are doing things because a lot of the patterns and the concept that we are using in software architecture are coming somewhere from that side.

And I found very interesting this uh concept of sharing layers when it comes to change because you know how it's working in uh architecture they are thinking about, OK. I'm just going to define exactly what are the things that are harder to, to change. So I have to make a very informed decision about that and things that can be changed in time and the effort of doing so is not that big. So for example, in architecture, we have OK, the site, well, if I'm deciding to uh do a house in a certain place or the site is pretty important. Yeah, I can't change the site, you know, overnight. So it's a pretty important thing then we are discussing about the structure. Yeah, that might be easier at some point to, and in some context to, to change. But still it's not, uh, it's not something that I can do, uh, you know, easily. And so, um, we are going to the skin and the services and space plan and in the end we are just discussing about stuff, uh, inside the house that, yeah, if I want to, uh, move my coffee machine from one side to the other of the kitchen or if I want to, um, do something in the, in my bedroom, you know, change something in the, in the, um, design that I have.

Yeah, I want to change some curtains or things like this. I can easily do it if I have, you know, some, uh, money and some time to do so. And, um, yeah, if I'm told enough to actually grab it. But I guess you, you understood the, the point where going a bit, uh, back into our technical thing, we can apply the same concept to, to architecture, to software architecture. Why is that? Because we can think, OK, let's just define a bit. What are the things that are harder to, to change in relationship with the things that are easier to change? So I don't have to put a lot of effort for now to uh make it very, very stable. So yeah, if it's to uh just compare a bit, let's say that for us, I don't know, the site might be the platform that I'm using. If I'm starting to work with.net and I uh working with this product a lot. Yeah, I have already uh uh an in place pro uh product. Well, it's a bit harder for me to just go overnight and say, OK, I want to change this whole product to, I don't know, I want to use no Js or something like this. So this is difficult and then step by step, we go into uh layers that are easier to, to change. So let's say that I don't know.

Uh maybe in the U I, it's easier to change some colors or to change the theme at some point or maybe to, you know, just change some components or use some components in some areas. So this is the way we can define actually what is important and why it's important. But also we can predict a bit about uh we can just think about the risk of something changes what it might happen. So we can not really define the architecture from the start, but more like um see exactly, OK, where exactly have to pay more attention in the eventuality of something changing and going a bit back, you might be asking, OK. But why is this important for, for the team? Because Miela, it seems like these are a lot of concepts that we are uh supposed to think about in the beginning of the product or yeah, in the start or at some point, we have to, to make some uh you know, some decisions about the platform that you we are using and the frameworks and the uh components and so on.

Well, I'm going to give you my perspective and my um my experience in the moment when I was working, uh I joined a new product, I was working on something trying to understand what is happening in there. And always, I felt very frustrated related to the fact that I did not understood why some things were happening. We are discussing about the uh big product uh where we were just working and integrating from areas that uh we are we not developing. But more like uh there was another team that was developing that part. So basically, uh we were like, oh I was like, OK, I can sleep like this. I'm either going to put a bit more effort into understanding what I'm building or I'm just going to leave the team. So in the moment that I chose the part where I put a bit more effort and I try, I tried to reach the architect which is not very pleasant at the moment, but I try to understand why it's happening and try to see exactly why is my uh some of my changes are uh uh relevant and impactful and step by step.

I just created this mindset switch where from complaining and always thinking about, oh my God, who is doing these decisions? And why is this happening? I started coming up with solutions, trying to discuss with people, trying to learn more to see exactly how we can create this product better. So it's very useful for the team to understand the high level parts of uh the product, how they are working together, what is happening in there, what are the main components of the system, how they evolve, how some changes that I'm going to make at some point are going to uh interfere with uh the entire ecosystem.

And by doing this mind to switch that I uh I've mentioned, I also had the opportunity to just uh invalidate some myths that I have about the architecture. And I'm guessing that this is something general because I've um started believing these myths or uh encounter these myths in my career while working with other people. And they were telling me all sorts of things about the architecture. So the first one is OK. Architecture is inflexible forever like no one is going to change it to just stay like this. The third one, the second one is architecture is an architect problem. You as an uh developer, you don't have to deal with this. It's OK. Just you know, code, code, code, you don't think about anything else but your task at hand. And then architecture is not about coding. Although if we think of it, we are architecting. Uh we are coding what the architect uh uh you know, so created the uh thought of. So we are going to invalidate step by step uh each of this uh of this um myths. But how could we invalidate this myth without discussing what is an architect? And I really think that an architect, although it's hard to, to withdraw, it's hard to define because it depends also on the context of the product and the organization where we are working with and uh the methodologies that we are uh working with and the, you know, uh hierarchy that we have in the, in the organization.

So it's a bit hard. But I really think that despite this, uh you know, things that can change an architect. So or the architectural, it's something that needs to grow. Uh you know, you have to grow into, you have to become an architect to actually be able to face the challenges to have all the experience or at least as much experience as possible in order to tackle some risk to work with very, you know, stressful and challenging situations and to actually see exactly what uh uh what each situation needs as a solution.

So, yeah, we need to grow into, into this. So maybe better than defining what is an architect is to define what is not an architect. Maybe it would be easier for us to know exactly where we are a bit wrong in the, in the way. So the first thing is, you know, for a lot of time, at least again, I'm talk discussing about my experience and the experience of uh the ones that I have uh near me in time, the role of an architect is actually a title and it's someone that, you know, at some point, uh it was a very good developer uh that was promoted and right now is not, you know, interacting with the team uh anymore because as an architect, you have to think about very complex uh things.

And uh yeah, you don't want to actually have to do with the details. Well, there is a lot of value in actually uh knowing what is happening in the code base, first of all and second, more than just the title. Yeah, that you gain overnight maybe or at some point, the architect job or the architect is a role, is not just the title is a role in itself. So as having the role we have a lot of responsibility. You have to make sure that everyone in the team is on the same page with you. You have to actually keep close to the team and not uh you know, uh distance because the team is actually implementing what you are, uh what you are architecting. So it's important to make sure that you make decisions that are easy to or at least approachable in a reality. Then there was this idea that OK, the architect is the god of the whole tech stack. And I'm thinking like for each technology, for each framework and like knowing everything this is preposterous who would ever want to have a role like this, it's a big responsibility. It's, it's a lot for a single person. I know uh jokes aside, I know that uh uh they are saying that uh tech uh people don't have really um social life, but still architects need to have a life also. So how about more like use the expertise of the team, collaborate with the team?

Uh OK, keep an overview on the practices and everything. So yeah, we are discussing about that experience that we mentioned before, that's valuable and important, but you don't have to be the master of everything. It's OK if you have in the team, people that are experienced in uh various areas that can help you that you can get feedback from that you can discuss with. So it's important to use the experience and the knowledge of the team while raising the team. And then third, the architect is someone that defines and gus the architecture and having into consideration what we've already discussed is the architecture, something so inflexible and forever that we need to guard it. It's like architecture police, we already mentioned that we discussed a lot about change, but definitely not. And actually an analogy that I really like to, to do is uh you know, d theory. Well, I really think that uh uh if Darwin would have been uh a software developer or an architect maybe or just someone living in our era in the, in our ears and being in this um the se he would be like, OK, uh the strongest system is not the one that uh uh or maybe the system that lives longer is not the strongest but more like uh the system that lives longer is the one that adapt better to change.

So this is something that we have to focus on when it comes to, to architecture. So basically, if it's to sum up the role of an architect is about knowledge experience, yes, it's about working with the team, working in the team. It's about having an understanding of uh a lot of, of uh technical matters and an overview but not really, you know, own every detail. And it's about someone that can predict and can understand the risk that come with a certain change. So if it is to just go with something from uh from this presentation, it would be two main ideas. One is that when it comes to architecture and an architectural also, leadership weighs more than management because management is more about, you know, very specific stuff, very specific deadlines, uh having results that is leadership. On the other side, it's more about being there for people, helping people grow, uh become professionals that you can work with later and that you can be sure that uh you know, if you have to, I don't know, you have to go and leave for two weeks, your team will be there to keep the system.

And uh the fact that you are leaving is not going to uh you know, just end up with a call up in the team in the, in the system. So it's important to be there for people to raise them. And as an architect, actually, you have to be sure you have to own communication and the interactions in that way that you make sure that each team member despite of the knowledge that they have understand what they are building. So it's important to, to be there for, for your people and work with them. Then the second uh idea is expertise over. Now, we all we already discussed about the fact that as an architect, you don't need to own each and every single detail. But it's important to have that over uh overview for example, if you have uh uh in the team, people that you can count on, you can give them ownership on certain features. So don't misunderstand me as a um as an architect, you need to more than just, you know, knowing that everything in the keeping track of everything true value is actually switching from the high level to those details in order to see how your decisions are being implemented.

And if your team, it's in the same on the same track or if your decisions were actually informed decisions, and if you have to uh maybe change something in your perspective. So we discussed about the fact that OK, uh we need a lot of evolution into this role. And as a developer, you can grow into, into becoming an an architect that is every uh every developer at some point going to go to this part of architecting or being in the role of an architect. Well, in here depends in the in the evolution of age, but also in what you want from your career while working in the team. It's important to know that as an architect, uh actually as a as a developer, the fact that you have an architect in in the team does not make you responsibility free of what is happening, you know, when the system is failing. So you can just say, OK, uh I know I wrote some bad code but I have an architect so he should answer for uh uh should answer for uh for the damage. There is a thing of ownership. And since we are discussing ownership, another thing to, to understand, important to understand is the fact that being part of the architecture does not make you an architect.

So just because you at some point to work with your architect and um yeah, you gave some ideas and you collaborated and was nice. Uh The result was uh was OK, does not make you an architect. There is some work to do in there. You have to be, you know, humble in order to, to grow into, into the role. Then is this question that I want to ask you? OK. Are developers just going to code an architect going to architect? Well, no. And even though I understand that I had a lot of discussions on this, on this matter while doing this presentation in time, people are saying, OK, but as an architect, I have a lot of meetings and uh a big responsibility. So, you know, I can't really uh also stay in code. There are a lot of ways in which you can actually contract. So you can either do um architecting, you know, try to do some knowledge sharing from your site or do some pair programming with someone at some point. If you have some time, some knowledge sharing again, you have to see exactly what suits you better, your uh your team dynamics and your way of doing things.

You can also create some uh architectural uh cas you know, where you discuss with people and see exactly how they would see the architecture of the system. Or you can uh maybe at some point, put someone uh have more o more ownership, you know, some uh developer that has more experience and you can, you trust to just give them the opportunity to uh have some ownership on the a certain feature just to see exactly how the things are working.

So there are a lot of ways which you can as an architect, keep track of what is happening in the code and keep close to, to the team. You don't have to write code, you just have to find ways and there are a lot of ways that you can uh work with it. In the end, I would like to no to, to let you know that uh from what I've seen in order to create this amazing the dynamic and to be able to uh work and create amazing products, it's important to have effort from the, from both sides, the team on one side to be engaged with what they are uh building, to ask questions to uh you know, want to, to grow into the real professionals and uh become better in their work.

But also the architect has to come with, you know, come to, to the team as a leader to have maybe more uh initiative in this part and uh try to see exactly uh where are things uh where things need to uh to be improved. So, just collaborate, create amazing products together and never forget to have as much fun as possible. Thank you very much. And uh let's see if we have any questions. Thank you. Um If whatsoever, maybe you'll have questions later or you just want to uh you know, share some uh some of your experience. Uh I'll be uh in the conference for the, for the rest of the day. But also you can find me on Twitter or you can find me on team, we can connect and, you know, just share some uh some knowledge, so stay great and have a, have an amazing day in the conference today.