Hello. Happy to have you with me today. My name is Mihaelaroxana Ghidersa. I'm a software engineer and besides being passionate about software and technology, I also like to combine it with this public speaking area and more like in the area of sharing my experiences, gather, bring from other people's experiences and things like this just to shape content that I can share in presentations as I'm doing today. So I really want to take to the organizers for having me. I feel honored to be part of such an amazing lineup of speakers. First of all, I got to say that this time is not going to be so much about technical stuff. I'm not going to give you the perspective on the best architects. Actually, I think this is a toxic tree that we have sometimes because we think that it's always about the technical knowledge. We need to just stop for a minute, put aside our rules, positioning levels, never ending processes, and just look at a team and use the expertise that we have at hand and the knowledge to see the shape of the current context. Developers are real people. I know it's hard to understand it, but they are real people. So we need so much to take care of teams, dynamics and how we actually build the product in the end, how we collaborate in building that product. My feeling is that when it comes to technical matters, we find a lot of resources on the Internet, so it's easier to actually work with that part, easier than working with the way we interact at team level, the way we shape team dynamics. But before that, I want to let something very clear from the beginning, beyond delivering a presentation, I'm here to contribute to creating better teams and better project. And I'm also extremely interested in learning from you and your experience. So just join me in this discussion. So what is architecture when it comes to clearly defining what architecture is? Along the way I found many interpretations and definitions, many of them confusing abstractions. The more I gain, more knowledge I encounter also some that were more, let's say, more simple and on point. But the general feeling was that they were pretty abstract for a developer that is in the beginning of his or her career. So beside all those definitions, abstract or whatsoever, I think that architects is a base structure upon which we build. Step by step, one component after another, we create relationship between them. Of course high level, we are talking about the high level. Consider that all this structure and decisions regarding this structure are being made while taking in consideration the whole picture of the product. So when I'm talking whole picture, I'm not talking only technical matters, I'm also talking about feedback and perspective for more stakeholders. Another important aspect to discuss now that we've opened the discussion about architecture, is that in many cases it is confused with design. And this makes me think that it's another consequence of the fact that we have this tendency of defining everything in a very abstractions way from one level of experience. So, as already discussed, architects is a structure. It's a blueprint that defines our high level units, the way they interact, the way they evolve, and so on. On the other hand, system design shapes things more at code level, the way each class evolves, the propose of each element, and so on. Having a strong system design helps the development team be more efficient and organized in terms of understanding what are the responsibilities of some functions, some modules, some classes, what they can and can't do, and so on. All of this is possible by identifying a systems design so we can later decide maybe what kind of design patterns we should use in certain contexts. Extending the discussion a bit about design. Well, actually, design and architecture, I really liked how Grady Bach nicely talks about how architecture represents the significant design decisions that shape a system where significance is measured by the cost of change, how nicely put and how nicely having into consideration this cost. And we will also discuss about cost and impact. But basically, if it's just to simplify everything, significant decisions are architects, everything else is designed. His words. Later on, we will go a bit deeper also in the decision making subject. But before I just want to conclude that simply says software architecture is focused on the entire system. Software design focuses on more specific levels. Since I'm coding people, I also like this presentation from Simon Brown that he's saying that architectural decisions are the ones that you cannot reverse without a high degree of effort. You can't change an architectural decision in an afternoon. So just think about this when you make your own change in the future in the architecture, or maybe also in the code, but precisely because we can change a decision related to architecture in an afternoon, the first step in architects software is about understanding what is significant and why. Because when we focus very much on code, on how to follow some well tested approaches and just check our tasks and feel happy about the fact that we've just finished a day, well, sometimes we ignore architecture and think that it's not important. What we miss is the actual understanding that there are actually some very important benefits of getting the big picture. You get to understand how components in the system should interact. You get to understand the responsibility of the components, the impact that each component has, and very important, the cost in time of the changes that I'm going to do. Having an overview on the architectural dynamics helps answering questions like this. Above all, I really dare to say that the scalability to predict change, it's extremely important. And you know how Darwin's theory says that the species that survives the longest is not the strongest one, but the one that adapts better to change? Well, if Darwin would have worked in software development, I think that he would have stated that the system that survives longer is not the system that has the strongest banners of things like this, but the system that has an architects that is able to predict and adapt better to change. So the best solution is to build an architecture that anticipates change and evolution in a cost efficient way. And this is something that as developers we can't ignore. So just take your heads out of the ide and let's continue the discussion. So we are discussing before about how we lose perspective and just give importance to only some pieces. Other times we get stuck into the mindset that we have to just mind our own business, do our job, focus on the things that we have in the job description and not concern about things like architects. This is a very wrong way of looking at things because guess what, we are building upon that architects. And there are so many benefits to having a look from above at what you're working. I will give you my perspective in a moment that I just stepped a bit away from the id and this was because some things were not clear and I became frustrated at some point because I wasn't understand some of the things that I had to do. So I just looked up and tried to see exactly what is happening. I started asking questions and suddenly instead of just complaining about problems that we were having in the system, I started looking for solutions and trying things in order to make things work. So I was able to see where some technical guidance might be needed, where I wasn't having the knowledge to actually give an opinion or maybe to understanding what is happening in the system. But I was always also able to visualize component interactions at a high level and it changed the way I looked at things. We changed my perspective and I actually started liking my job more. If you ever had the situations like this, I'm sure you understand that you just have this drive of doing things because now everything just makes sense. I felt that. And besides this pleasure, by having this mindset switch, I was able to quit some of the teams that I've grown to believe in time, such as, okay, software architecture is inflexible and forever like someone said it in the beginning and that's it. Or the architect is not my problem, is an architect's problem. So I'm just going to go deal with my task or architecture is not about coding. Like architects just discuss business stuff and that's it. They don't look at the code, they don't care what we are doing in the code. And I'm pretty sure that at least one of this, it was part of your career, you had it at some point. But more important is to discuss them and break the toxic cycle. And as the discussion will evolve, you will see that we'll just destroy them one by one. And by being able to destroy them one by one, we have to think about this person that seems to be sometimes maybe in the traditional way of doing things, seemed to be like the God of architecture. So what is it? An architect, independently of what we are about to discuss or how often the role of an architect is pretty easy to confuse you. I really think that you don't become architect only by receiving a promotion. There is a strong need for evolution. Gradually working with some situations, growing the expertise, gaining the attitude in time, that will help you faces the role as it comes. Because this role ones both with challenges and a lot of decision making at the same time, I feel that there has been an evolution within this role, as I was saying, from a traditional way of doing things to a more like hipster style, more open and relaxed approach. So we are going to put in balance why we should implement certain approaches over others. For the longest time, as I was saying, it seemed that the architects is, besides the fact that we can define the role, we weren't able to define the role that good. It seemed also like you can't touch the architect. He's just standing in there doing very important decisions and you are just staying in front of the ide and coding. And I'm not exaggerating because I've been part of a team where I think it was my first project ever and I've been in that team for like over a year. And I don't know who the architect was. I never met him, I never interacted, I never. Nothing about the architect and also about the architecture. It was like we were so just doing things in our tasks and that's it. So you can understand that in the moment when I changed to another team and the architects was standing like the desk next to me and he was so open to discussion and always being involved without actually being part of the development team directly, and he was just open for discussion. He was there for the people that needed him, but he was building his things also, and he was just available when we needed to discuss some things that were important. So, yeah, although we have all sorts of situations like this, for me, this kind of switch helped me to actually understand the difference between a title and a role. And this is the first thing that I want to discuss, the fact that the architecture is not being built by one person only. We need to just quit this mindset that the architect architects the architecture. As I was saying, one of the myths that we are discussing before, I'm not saying that teams shouldn't have someone clearly ones a role, but somewhere in time, any team member can come with ideas and insights that can impact the current state of architects. This is what I mean by a flexible collaboration, a flexible role that stands in collaboration actually. Then of course, again, for the longest time, the feeling was that the architect has to know it all and has to own the whole stack. And I was thinking like, oh my God, every technology and every detail. That is preposterous. Why would anyone ever want to have such pressure and would ever consider taking this role? Who would ever be good enough for this role if the requirements are so unrealistic? Well, how about we usually use the technical expertise of the team while raising the teams, taking part in the development process, either by pair programming, doing some code reviews, just looking from time to time to what is happening in the code base, gives you the smallest effort, gives you an idea about whether or not your architects perspectives are grounded in reality. The sooner you have this kind of feedback, the sooner you can ensure that you work on the evolution of an architects that is actually implementable, that works with real life scenarios, and it can be implemented by real people. Then we have the third point that the architect used to in the traditional way of doing things, the architect was defining and actually taking care that the architecture stays like that. And I was thinking like, I can't believe that we need architects. Police. Is architecture something so fixed and hard to implement that it needs someone to guard it? But how about understanding the system, combining this understanding with collaboration and feedback, as we were previously discussing, and create a more grounded in reality system, a system that is understood by the team, and a system that the team is actually able to build and understand why it is important to build in a certain way, why it is important to enforce some approaches, some best practices, some patterns and things like this. So definitely architect, as we are saying, it's a flexible role. An architects uses the technical expertise of the team while also growing the team and with the team. And of course the architect understands the system, keeps high level mindset, but also looks at a developer's perspective and tries to see if his objectives and his vision is actually understood and implementable in the end. So now we can consider that some of the myths were invalidated and we will discuss later even more details to bring some light. But right now I want to go a bit and discuss about two approaches when it comes to the architect role. One is leadership over management and how we are actually placing this role. And the other one is expertise over knowing it, everything. And somehow on this part we already touched some details. If there is something that you remember from this talk about your architect and maybe something that you can just look at your architect and see if he's doing that, please make these two things. That's something. So let's discuss the first ones, which is leadership goes over management. There's a difference between management and leadership. Management is a lot about tasks, very specific steps, achieving the end goal, which is not a bad thing. On the other part though, leadership is about people, who you are, how you get to those people, how you inspire them, how open are you to those people. I really think that an architect should be a leader. A leader that has a very good overview, that has experience in a lot of areas and that can give insights both functional and nonfunctional. He actually has the responsibility to grow the team in the end. And maybe something that, again, I've seen in teams, and it seems that it's not clear, is that each member of the team has a certain level of knowledge. So as an architects, you have in the moment that you approach a team, you have to find a way, a common language in order to make sure that everyone understand what you are trying to enforce in the team. So everyone in the development teams needs to see the essence of software architecture, the consequences of not thinking about it. Before we start talking about things like, you know, the way we evaluate people and the way we evaluate performance and other things and language and things like this, we have to understand the consequences of our work. And to be honest, some recent events that I witnessed showed me that people really need to be in touch with the architects. People really need to be able to ask the architect about some of the decisions to understand what is happening. And I've seen this in one of the teams that I worked with where we barely, this is another team, it's not the first team that I was telling you about. We barely interacted with the architect. So until the moment that I just, I'm very persistent. So I just went to him and asked for explanations and things like this. Well, in the moment that I did this and the moment that we actually received some answers and things like this, the team expressed, the rest of the team also expressed the need of understanding the context and how important is and how they don't see what exactly they are building. At the end of the day, what is the result as a whole. So we don't usually talk about the soft side of being a software architect, even though it's so important. I felt it and I'm sure that a lot of you also felt it. If there are any in there that were just fine. Well, with the situation when I had for you, it means that you had a real leader in that. But in the real world, an architect's role is both worrying about the important technical decisions, but also he has to lead, give the team a direction. Collaborate coach we are basically talking about a full time leadership role. So yeah, soft skills are extremely important and I'm just going to insist on this only once more. A team with the same view and that finds it easy to collaborate, is more engaged and delivers both quality and quantity. So team dynamics are so important and the architect has a very important part in all this process. Then we discuss about the expertise of our knowing it all. We were discussing already, owning the whole stack is not possible, more like users, also the expertise of the team. And I think that the real skill of an architect is not mastering the whole stack and knowing it everything and being the best of the best and things like this. I think it needs to have some background in software development. Yes, but the most important I think is the ability to switch between code and implementation details and the architects big picture. Because yes, as an architect you should own best practices, approaches, overview and design and patterns that bring more value to some of the technologies in order to choose the right technology or in order to just go with the project in the right direction. But when it comes to keeping an eye on details, low level code, I think it's true value exists in using the technical expertise of the team. The software architectural can sometimes even for one idea, be of another team member. We just need to create trustful and a trustful environment. An environment where we can collaborate, where people can express their ideas and show their expertise, be confident enough to show what they know and learn on the process. So being an architects is challenging and takes a lot of knowledge and experience. At the same time, you dont need to be an expert in any particular area of software development to become one. It is better to have a wide understand of software development and be able to communicate your knowledge effectively while being backed up by best practices. I find it important to know that you don't have to be the God of the technology stack in order to become an architect. I find it useful to have a big picture, to have emotional intelligence and also coaching. So it's a very good combination of technical and soft skills. More specific, I really find that there are some general set of skills that embody the architect role, like being pragmatic when it comes to requirements and constraints. Being able, and this is something that is being built in time and with experience of being able to know where you can take a risk and where you can't take a risk, and be able to make some decisions regarding design. Be very careful in the moment that you have to make some decisions. If you gain some technical depth, well, how you are going to manage that technical depth, like keep track of that, because at some point it might get so hard to manage and the architectural vision might be so damaged that you can't do much about it. And also the combination with the other soft skills that we've discussed, such as keeping close with the team, be a leader, inspire people, grow, raise people, and try to be the best influence in the team and keep everyone aligned. We were talking before about taking risks, making some decisions. Well, each project that I ever worked on has evolves in time. Requirements changed because maybe of the competition. So they had to change the main features or you have to be creative because some new technologies and trends appeared. And yeah, you need to stay up to date sometimes when it brings value to your product. Maybe some stakeholders change the way they look at features and they change the perspective, they change what they wanted, they try to want to try something different, where sooner or later, depending on the context and domain, something is going to change. What we need is to actually think in terms of building tolerance to change in the system. Observe where and what kind of changes appear, iterations, and this way you can expect these kind of changes and be prepared to meet them. That's why we are doing so much analyzing, because I really liked this idea from Jane's clear, with saying no and yes and how no is a choice and yes is a responsibility. Because every time we assume a final decision, we are also saying no to some more details that we might receive in time in the future. Details that might be significant and might help us make a more informed decision that once you committed to something, you already decided how that future block of time will be spent and how the product and the architecture of structure will evolve. So be very careful in what exactly you invest. Just think about it. So making decisions concerning architectural aspects is a very sensitive aspect because those decisions have a huge impact. And one of the best practices in software development is to avoid making decisions until the very last moment. Because, yeah, especially in architecture, there is a high level of uncertainty. So a good strategy in order to be prepared to make commitment is gathering a lot of feedback. If we talk about an existing system. But yeah, dont get lost in details and accept there are some parts of the project that you are just discovering time and that is okay, but also especially for the existing products, accept when you made a bad decision in the past and just change the perspective. Accept that maybe some parts of the systems can be, you can rethink of them and give them another shape. A better strategy for delaying commitments and making decisions when developing complex is not actually delaying the commitment, but more like always build your system in terms of evolvable structures. Like always keep in mind that you need some degree of some capacity for change into the system. So keep your system open to change in the future. Now I would like to point that becoming a software architect is not something that you become automatically, as we discussed, it's a role, even though it's not easy to strictly define it, just as architecture. What a coincidence. Well, we actually can agree on the fact that the road to coding an architect is full of challenges and experiences and expertise and confidence, and we just build upon that in order to be ready for the, as I was mentioning before, the challenges and the decisions that you are about to take. So you have to be ready for the role. You can just be named an architect just like that. But from what we've discussed, maybe with some exceptions, architecture is a part of the development process, part that later is taken over and implemented. Actually in the team architects is not about forgetting about implementation details and getting drawn in abstractions, but about keeping them balanced. Sometimes maybe you put more accent in one side, sometimes maybe the accent goes on another side. I think that you become a good architect when you are able to slightly move from one to the other. And I was able to witness this and I was very inspired of an architect that did something like this. So in the end, software architecture is all about understanding how the system works as a whole. And since we are discussing in here about duties and professional duties, I think that on one side the developers should cross the line and break the rules and be curious and always check on how you ended up with doing what you're doing in the code and how your code complements the structure of the system. Then also the architect should break the rules and make more informed and reality oriented decisions. Then we are talking about, okay, but can actually every developer be an architects or what's the deal? How we are going to grow to that role? Because I've received this question before. Well, it's not an easy road and sometimes you might be thinking, okay, but if it's not something clearly defined and the collaboration with a team is so strong, couldn't we just use self organizing teams and just get it over with? This architects troll and whatever we are discussing. Well, I don't agree with that part. I think that an architects in a system that evolves and a system that in times adds up complexity, it's important to insist and have this role defined and have a person with the responsibility of the role because the team components, it changes. Every team member has a different level of engagement. You need someone that keeps things on track. You need someone that stays engaged with the product that we are building. Because if you are doing things right and you are keeping the relationship with the team and also with the other stakeholders and try to manage all this context well, the results are visible and an architects is important in the team. If we are discussing maybe a product that just needed some structure in the beginning, a product that is not that complex, that is not evolving that much, the architects can be like someone that maybe just from time to time goes into the teams, or maybe in the beginning gives a structure and that's it. If it's a very simple product that does not evolve in time, it's just fine. From my perspective whatsoever, the process of becoming an architect is not a very well defined, as I was saying, we don't have like the ten steps of becoming an architect. No, you can just look at the ones that you have near you, undertake some parts of the software architects role, architect role without actually losing the perspective that you have as a developer. Just try to contribute. Look at what maybe the closest architect is coding or the closest, most senior person that you have and try to do it step by step, even though maybe your goal is not to become an architect, it's just to become a professional with more like go to the next level. It's also okay to look at someone's journey and just go and ask, okay, what have you done to actually work in this role and what should I do? And things like this. So your evolution is your responsibility. So go ask well about this. I think we've discussed how important it is to actually change perspective, change roles from time to time. I really think that as an architect, you need to understand the concept of the application from a developer's perspective and take more informed and realistic decisions. And this way, by having clear what they are building, also the team will understand the impact and the importance of their work. And yeah, we'll trust you more, but also they will be more motivated and engaged with the product in the end because they are able to see the whole picture. So yeah, I don't think that coders should just code and the architect should be concerned only with the architecture. Sometimes it's good to just change the revolves and wear someone else's shoes just to see how we can impact their work. Although we discussed a lot about the best ways to do things, there always appears a gap between the development team and the architect. Unless the effort is mutual and both parts the effort, you can't make things work other way. Software development is a team activity and in the end even unintentional. We help each other grow. For the developers that are thinking maybe about taking the role of an architect or just wanting to step up to the next level, don't be afraid to look outside your daily task. Try to understand the context of the product. When you don't understand something, speak up. When you have maybe something to some solution idea, share it, try to get feedback on that and always ask to be involved in the decision making. If again you have a perspective and some arguments for the ideas that you are promoting. Architecture is not an esoteric concept, but it's not an easy road either. And one step at a time, you can grow in the direction that you find interesting. Always surround yourself with people that are better than you. See how they approach certain areas, read their code, look at the decision and see or think about how would you have decided in your case it then for the architect? Well, don't be so you so obsessed with your solution, except that you are also doing some bad decisions. Stay close to the team and collaborate with the team from time to time. Get your hands dirty, because when it comes to building the right architecture and for the right context, I came to learn that. Actually I came to learn this the hard way, that it's important to have the architects state engaged with a team. The value this approach brings in terms of feedback and collaboration and instant click when it comes to some solutions is incredible. On the other side is the best way to keep the team aware about the technical vision and the architects direction and you don't have to be 100% involved in the code. Do some pad programming, look a bit from time to time in the code base. Whatever works for you. Just don't get lost in abstraction. Being a developer is not easy. Right. And being an architect is definitely not easy either. What I really believe in is the amazing benefit. Benefit? Yeah, of every development teams considering architecture. Failing to do this just brings inconsistencies, integration issues, code base that is hard to understand and to extend. And yeah, just not mentioning a lot of the quality attributes that we should enforce. Just becoming harder and harder to maintaining as the system evolves. I'll finish by leaving you with two ideas for developers, think globally, understand the whole picture and try to implement in the details towards that big picture. And for the architects, we'll work on the abstractions. But please, from time to time, just give an eye to the details, to the code base, collaborate with the team and just try it. And maybe later give me a sign on LinkedIn or Twitter and tell me how it went that for you. Thank you very much. And let's see if there are any questions.