Becoming a Better Software Architect

[Music] [Music] [Music] [Music] welcome to today's webcast on becoming a better software architect my name is Rebecca sky and I will be your facilitator today I'm a technical director at Carnegie Mellon University software engineering Institute the sei my current work includes developing techniques for engineering AI ml systems and improving software evolution efficiency with an emphasis on software architecture software economics and managing technical debt for more than two decades Carnegie Mellon University's software engineering Institute has been instrumental in creation and the development of the field of software architecture we have previously done two webinars what makes a good software architect in 2016 and what makes a good software architect edition 2019 in these webinars we explored architects challenges of working in an environment with rapidly evolving technology all of the architect in agile environments and how the range of skills and knowledge is change we know this could be daunting and my favorite analogy comes from Craig Rafi Gregor Xavier describes an architect's roles and responsibilities as riding an elevator he calls it the architects elevator excuse me and he suggests that a good architect should be able to ride the elevator of a high-rise being able to get off at any level either at the CEO level or at the developer level or at the plumbing sometimes and that can be daunting for architects and that's actually what we will explore today I would like to introduce my colleagues who we picked from a range of our skill sets from the team we have and they're going to be bringing their different perspectives to the journeys that they've lived let me start with Keegan hi everyone my name is Keegan Williams I've been at the sei for the last five years I am also working on a master's in the computer science field today I want to focus on a few points the main one being that everyone on a team benefits from you becoming a better software architect improvements to yourself help your team members become a stronger and more cohesive group and they help improve your designs on your projects and things like that I also want to emphasize the importance of starting right now learning how to be a better software architect I think the sooner that you begin learning the faster you're more of a help to your team and finally I want to emphasize that being a better architect were results in you also just being a better software engineer so coming from a more development heavy background and learning about software architecture and improving myself I feel that I've become a stronger engineer in general thanks you good and let's go to my next colleague FLE Phil Bianca hello everyone hi thanks for joining us for the webinar today and so I've been at the sei for 15 years now working in the architecture group and I picked up a few things and so we're here to talk about becoming a better architect and one of the things I learned early was connecting with my stakeholders you know and working with them and learning and making them part of the problem rather than or not the problem part of defining the problem rather than defining it on your own and then realizing later that you missed a lot of their pain points and then we tried the sei when we talked about architecture in our group we focus on what we call fundamentals and techniques and so everything starts with business goals things that are important to the organization and then those leads you to quality attributes and then quality attributes drive your design and so from there then we have a set of techniques that we use and they're all based on a fundamental thing called the quality attribute scenario and that helps you precisely define what you mean rather than talking vaguely about qualities and then from there you can find a bunch of different analysis techniques and design techniques to use using those your scenarios as your key criteria and so you have to remember that you can't have everything being important all the time you have to have a set of drivers that you define and then probably one other thing that's amazingly important as avoiding the the opinion based design and so always have a set of criteria it's clear and you know you don't want to go to a design review and be frustrated when someone hits you with performance when that's something that you have a pretty good handle on already and you want to talk about security and interoperability so staying focused on those drivers and getting people to focus on those drivers and so becoming an architect is challenging it's not something that I believe you can do just studying you have to have experience as well and so if you're young and you're picking a program or picking classes I'd recommend looking for classes that have hands-on things that you can do on you know little toy problems that so that you can learn how to architect and then when you go back to work you know you want to work with the architects don't sit in your cube don't wait for people to come and discover you you know you the architects going to affect you in your development of the system and so you want to ask intelligent questions and understand the architecture start building that relationship then you can start doing prototypes and things to answer questions for the architect and then hopefully start being part of the design and I was lucky when I started at the sei I had a lot of trouble with abstraction I was a detail-oriented guy and I find a good mentor and so that was really helpful for me and then the last thing don't hide in your cube don't be afraid to show your work to people that's the beauty of Engineers in architects when you work with them you buy them a pizza and a few sodas they'll come to a room and give you an hour of their time and they will help you find the risk and the problems with what you're doing so again don't try to be perfect before you let things know and look forward to the rest of the talk thank you and last but not least James hello I'm James Ivers I've been working in software architecture for about 25 years and currently the lead of the sei software architecture group my own journey has been a little bit eclectic I've done a lot of research and software architecture I've worked with a lot of large organizations and helping them with architecture challenges and I've also been the architect in a start-up environment so that gives me a nice little breadth that I hope will add today's conversation but in preparing for today's talk I had a couple of thoughts that I thought might be good to open with first of all I was thinking about of all the architects I worked with over the years what are the characteristics that really set them apart as is Zek architects to be emulated or admired and really the ability to maintain kind of situational awareness is really important the ability to step back and to know what's important to focus on at an important time is this the right decision to be focusing on right now am I going into too much detail Mirai focusing on the right abstractions that will help me help the team make progress really quickly these sorts of things really come down to getting past the the basics of architecture we're really understanding the fundamentals why things work the way they do why good practices are effective as Phil is saying working with stakeholders really really important and often the best architects I've worked with have an ability to translate between different concerns against similar to what APEC said with the elevator metaphor a good architect can help management understand a really important technical decision and why it's important it can help technical stakeholders understand why this matters to the business and the delivery cadence that they're trying to meet and good architects can bounce back and forth and maintain consistency between all those stakeholders interests and use the key abstractions to really make that happen so so these are some things that I've noticed some really really effective architects but as Phil said you've got to practice and building these skills building this kind of judgment does take time some of this you will get naturally in the course of your job as you work on larger projects and you take on more responsibilities you make more design decisions but there's lots of things that you can do to go along that effectively in my mind come to developing a questioning nature a curious nature always reflecting on what you're doing why am i working on this right now is this the right thing should I be talking to other stakeholders whose voices haven't been heard and these sorts of thing can really help you seek out the kind of feedback that help you grow your own skill set and get feedback on the things that you've done and how well they've worked out thank you and I think one of the common things that we're hearing that it takes time it takes practice and it takes patience so my first question will be what is something that you learned you wished look you wish you had learned earlier I don't know Tegan you want to get us started again so I think one of the biggest things about being a Software Architect is just having communication and that's something that I think I kind of learned maybe a little slowly because I grew up or I started in more of a classroom classroom environment so I'm being told things taught things that sort of thing but as soon as I got out into kind of working with other teams and other groups and working on a project the early constant communication is just super critical and I I think that's really really important next sure so one of the things I learned and I you know I would fall in love with my own design a lot when I would do them and when people would criticize them I take it way too personally and so one of the things I learned was to take a step back and realize they were challenging design and most of the people I've worked with over the years they're genuine and they really want to help you and so I learned not to take it personally and actually to think rather than trying to rule over them there were a couple of times when I was a younger professional that I made mistakes luckily they didn't kill us but but I did learn that sometimes people were right and they they they really have you know your best interests at heart in the organization's so in my case it wasn't so much something I wish I'd learned earlier but something I wish I'd internalized earlier so you know I learned through formal education good principles of architecture the importance of stakeholders and going after goals but I was once on a team when I was in architecture role gathering you know all the developers in the organization small startup environment and there was one particular technical issue we were just butting heads day after day after day and we were arguing back and forth and at the time it seems so strange to me I didn't understand what was going on because no one was saying anything wrong and yet we just ranking we're not making any progress it occurred to me in a few days a few weeks later what was really going on in that conversation is we were really disagreeing about what was important what was the goals that we were trying to achieve but weren't making that explicit and making that explicit really does help and the textbooks say that the lectures say that but going through the the consequences of not doing that see the time that you waste because no one had anything ill intentions in mind people were all making good-faith arguments they just weren't talking the same thing similar experience when one of the courses that I was teaching two individuals were arguing over flexibility they meant completely different things but they were trying to agree they were both importance they didn't realize that they were naming it with the same quality attribute rather than the different ones so we have actually a great question from the audience and I'm going to take that next what happens when you cannot start an architecture from scratch this is a very good one I'll take a start that I think that's pretty much the de facto these days right I mean it happens for lots of reasons many many of the organizations that we're working with are working with legacy systems and they're trying to add features or improvements or do some sort of more radical modernization and so part of what they have to do is to acknowledge the constraints of what they can change and what they can't and there's usually a discovery process to figure out what is changing on what is not but even cases with new projects you're still constrained these days we build so much on top of frameworks where so much of the architectures are you given to us and it's not so much about making whole scale design changes on a plate piece of paper it's choosing an appropriate framework for our needs it's configuring that framework for our needs and that comes from understanding the context that we're in and and sometimes those constraints are technical sometimes they're just pragmatic my organization has this skill set so I don't want to retrain all my developers on new technology sometimes its regulatory there are certain rules that we have to follow and so architecture always works within constraints and so one of things that you can do is to really understand where those constraints come from and how hard are they have to deal with their existing architectures do you have any advice yeah I mean you have you have to start and figure out where you are I mean that's that's typically my first step is so I hope they have some documentation but if they don't I have to run tools on it you have to run tools like I understand or Latics to figure out what the key dependencies are and how things are broken down I mean you have to you know dig into the code a little bit that that's one of the important things is understanding okay how are how are things statically you know allocated and then you would run some tools on there and you know to to figure out okay what are the challenges and then you also have to find out okay where do they want to go you know so to to understand that you have to kind of create you know what is the map qualities what are they trying to achieve after you do all the reconstruction which is really an art it's it's not an easy thing to do it's it's a it's a labor-intensive activity but when you get that then you figure out and then you also have to assess the organization there are lots of times when I work with organizations and I realize you know that they're not going to go for the big grand refactoring you have to find things that are actually achievable based on their budgets schedules whatever they have going forward and so you have to be realistic in your approach from getting to where they are to where they want to be and that's often figuring out a set of migration steps so if I summarize both perspectives I might say a better architect is able to actually find the information dig in and see where they are and where they want to go and use some of the tools and techniques out there effectively Phil brought up a lot of good points often an architect has an opportunity in this setting right so some things are hard constraints some are just they seem like they're constraints and if an architect can dig in and make a good case that this is a better technical solution maybe it's going to take a little bit to refactor it now but if a good architect can connect that to here's the business value that you'll achieve by doing that by connecting it to the concerns that other stakeholders have not just a better technical solution then that can have a lot of a lot of traction so you've talked about kind of the discovery process a little bit what happens if you don't initially find one of these constraints or requirements like how how do you handle something new popping up in the middle of it so just down to the framework that you're running or like let's say for example you you discover like a constraint that you need to bring into the architecture but it happens two months into your architecture planning how do you normally adapt to that kind of thing well hopefully when it's when it's early in the in the lifecycle I mean we're not talking about then migration so you know one of the things as if I found out I'm hoping it's it's a technology family that I've already planned for you know so if I'm told I need to use an Oracle relational database in system but I was planning on using something no no SQL related piece of software or a big data solution you know then that's a much harder problem there and so those constraints come but you have to again like James said you have to push back you know are is this a real constraint for me and and why to some extent I would treat it like a requirements change and by that I mean you know requirements are going to change no requirements document is static and more and more organizations are getting smarter about doing architecture incrementally so there's some some awareness you have to build the judgment I was talking about earlier what are the critical decisions to make early how do you identifies those to all those stakeholders so that the the foundation that you're laying everyone knows the implications are getting this wrong right doesn't mean you're not going to change it later but but you do your best in terms of raising awareness to your organization here's the consequences these decisions and I still think it's the right thing to do but on the back end you know things are going to change right you can predict some things with reasonable accuracy but sometimes things will come at you that you weren't counting on like the the gdpr thing in Europe right data privacy had all kinds of ripple effects through systems that no one was really planning for for business value but that's a good example of a constraint that came in later that was just not optional you can actually your question with some of the questions I'm seeing here come popping up how does a j'l an architecture coming together how do you do evolutionary architecture how do you actually dive into it it's very similar as James said you have to plan for iterative and incremental process and I think that's one of the mistakes that not-so-good architects make things won't will change you have to assume for change and dive into it whether you're starting with a greenfield architecture or you have to deal with the architecture that you have in head so there are lots of good questions coming in and I can't keep up with that but one of the things so we'll figure out what to do with this but we appreciate that but I'm going to change gears a little bit and talk about how organizations career paths and they're also responsibilities of the architect changes because some organizations do have the architect career path so you can go from junior to senior or to lead others don't but that doesn't mean architecture is not as important so what is your advice for someone who might be working in an organization that does not have the career path but wants to develop the skills and responsibilities of an architect versus someone who might have that are the career paths in an organization is there any differences are there any advice that we can offer based on all the different organizations that we work with so yeah so I I would recommend if the organization isn't architecture savvy or they don't have the architecture practices in there I would think you're gonna have a high learning curve and you would probably want to start a small pilot project that's probably not on the critical path and I would recommend starting there and applying the techniques on that and showing value and then you can move and if you're successful you can move to another project and as you do a few of these pilot projects with the architecture work there and it goes back to what I described earlier about the fundamentals and techniques you know you want to rely probably more heavily on process when you're there and have a set a checklist that you go through and and you know a set of wastes you know to get the requirements because that's one of the big problems I see in organizations when you go out there and they don't have the architecture practices you have the quality attribute requirements just jammed in a spreadsheet with 1,200 other requirements and I think you want to tease those out make those first class citizens and then start showing that you can go downstream and start designing applying patterns and tactics like I described on the previous slide known solutions using those also to choose technologies and things like that and again get away from opinion based discussions they waste times as I described and so that's how I would recommend starting yeah I think Phil had echoed this in his opening statement but for me it's really just been about getting experience with small things like personally I have a few personal side projects that I've used as kind of maybe I'll just make all these quality attributes for this project or like pick and choose with one or two things if even if you can't get it within your own organization just do it on things that you personally are interested in and that helps you a pursue it because you're passionate about it and B helps you get the experience that maybe you can use either in your current job or even in your next oh I've seen well like most things architectural depends a little bit on the context right so in a large organization with hundreds of staff on a team there probably is someone who has an architect's responsibility and so getting to know that person offering to review content getting the side discussions can be one way to to grow into that role smaller organizations can be little more challenging if you've got a team of 10 developers there's there's no way architect as a designated role most likely but that doesn't mean that architectural issues aren't important so things that you can do is when you're grooming the backlog you can insert some architectural stories right this is an important decision I think will affect the next few iterations I think we should dedicate some time to it and offer to do that another interesting thing that I've seen practice occasionally even in larger organizations is it's a challenge sometimes when there's no designated role for architecture there's no time set aside for documentation which unfortunately still seeing organizations but I recall one organization where there was a stealth grassroots effort at architecture there's a team of engineers who got together at lunch a few times a week and said that the way we're doing this is crazy we're working too hard we need to design this in a more coherent way and they did it on their own and they built it up and kind of surprised management is just how effective it was so I think what I'm hearing is you have to take ownership you have to take ownership and responsibility and I think if you're committed to it whether there's a career path or not you actually go about it and I think because the good architecture is essential to a good product you will definitely find support when you get there so this next question actually is somewhat related and screams your name James because the question is how rigorous and architecture process should be in a startup environment in a startup environment and I think that's similar to the organization yeah yeah so startup environments are fun so architecture in a lot of ways is about getting a team on the same page and buying down technical risk and buying down organizational risk and all the core principles that we talk about in terms of understanding what's important plays just as well in in a startup environment but the qualities that you are concerned about might actually be kind of different generating buzz might be a really interesting thing and so architectural strategies that help you scale to to broad publicity and things like that might make a difference but in terms of how formal to be I that's interesting one thing I learned from from being a startup is you've got to fit with the startup culture if you want to force things to be too formal you know you can ostracize yourself to some extent you need to demonstrate value and get buy-in from your peers not just your management one thing that was actually kind of interesting in our environment is the the architecture work that we did was actually pretty pretty insightful to the venture capitalist who are funding us they found that that gave us technical credibility we weren't just throwing out demos we actually had a plan for how to grow the business and so there can be that kind of that kind of insight but I think in terms of how formal as with any organization you've got to be speaking the same language as your peers you can't be doing UML when no one else in your team understands UML you've got to find that common common communication medium and you've got to tackle the high priority issue so that you're not perceived as wasting anyone's time you're demonstrating value and how this helps the company grow so I want to bring it back to the knowledge and skills and maybe this might be something even you might comment on as a recent graduate we always get asked the question can a recent graduate from a computer science department or something related call themselves an architect so what does it take to get started as an architect so what are your experiences and opinions on it yeah so I think that a recent college graduate can can be a considering architect with the caveat of as we've kind of a mentioning experience is pretty important so I personally think that given coursework given the kind of personal experiences that you've had just even doing smaller projects or side projects things like that usually you're doing some form of architecture and them you're not just going willy-nilly into development but real experience and all that James or Phil talked about this more real experience in the field doing grounded practice practices is really you can't can't go without it yeah so I I maybe go a little more to the other extreme is a little bit of skepticism for a fresh graduate calling his him or herself an architect I think Keegan's right I mean you actually get started you could absolutely find these problems start to build some skills but one of things that I looked at is a hiring manager is how long have you been doing it what's your real insight and and really important and harder to get as a student is what kind of feedback loops do you have when I talk to architects I typically one know some interesting design challenges they've dealt with and I know how they worked out a year later and that's harder because that gives you the judgment okay this seemed like a good idea at the time but did it really work out now I know there are a lot of opportunities and things like open source community big practicalness that you can get in some graduate programs and undergraduate programs even and I would encourage big exercises right where you have a team of more than a dozen people and so your your decisions have more impact than just on yourself because that gets you feedback from other parties can really help grow your skill set so we have an architects elevator question how should architects own products quality or test strategy so that's interesting I you look like you might have some to add but but I'll start maybe so there are different over the years there have been different papers and columns that they say what is the role of the architect is the architect the dictator is the architect the mediator if the architect the coach and I tend to favor that the notion that software engineering is a team sport and you've got to work together so your architects should absolutely be talking to people who are doing tests strategy should your architect own that I don't know maybe it's a more collaborative relationship I'm not not so hard over on that in terms of product quality again I don't know about owning it but the architect has to be well-informed they have to be talking to two users or proxy users they have to be talking to business stakeholders and if you have a product owner who isn't the architect that's great they should talk to each other a lot yes so I you know I'd probably come down a little harder and say they shouldn't own it but they should be working strongly with the testers and the people that own that and my job as an architect is to find out you know where where they need observation and where they need control points and that's one of the reasons why I like event phase systems everybody will tease me sometimes and say every system you design is an event based system but that's one of the things I like about it you know because you can optimize it and and it's not really that much of a performance hit but your control and observation points are right there for you and it's very simple going forward and so I don't think they should own it but they should support it and work with and maybe a piece of guidance we can offer is it comes back to the quality attributes right testable that is a key quality attribute that we are actually enforcement to the extent that they can emphasize some of the architectural attributes as quality attribute scenarios then the architect could actually have an entry point in terms of how they can own on how they can collaborate with all the different stakeholders right it may be just to build on that for for learning architecture one of the things that you need to learn is the the array of stakeholders across your organization and what they care about and so just getting to know the test people getting to know the people who do training for your product getting to know these stakeholders and just chatting about what's important to them helps you understand the breadth of concerns that are really important to a system ok I'm smiling as I'm looking at the questions but so Keegan I'm going to put you on the spot and start with you on this question and then I know fuel and James will have a lot to say as well because you're reacting currently one of the projects that we're working on and the question is comes from Alex who asks please speak to the art of documenting in architecture so obviously documentation is a huge part of architecture and the system we're currently building for example we've been walking through the team who's maybe not as involved through a lot of our decisions and kind of will write them down maybe informally in a document walk them through get some feedback even just getting feedback from from somebody who maybe doesn't have the same classical training but being able to like it they're they're more on the development side getting the feedback from them on a development side is pretty important because that helps you kind of align with them on on what sort of what they're thinking on that so having that first informal take and then what we've been doing after that is going into a more formal form of the documentation keeping it all up on a on a wiki that way everyone on the team can still see it and you can have revisions all that sort of thing maybe that sort of answers the question but I think I'd read on the question also there's a good architect how does a good architect or a better architect relate to the documenting of the software architecture as well I know James is chuckling but you get the last word Phil okay any comment so obviously you know we talk about stakeholders all the time so you have to ask yourself what am i documenting and why so how does it allow me to communicate with people and then what analysis does it allow me to do so I think every architecture needs you know runtime component connector views the static uses and packages relationships there and then also deployment I think it needs deployment and then I'm a big sequence diagram person because I think it really helps people understand what's going on in the system and at different levels of abstraction I can run you through you can understand if I'm worried about performance I can give time slices and then after that you know it's it's really dependent upon what you're trying to communicate and what you're trying to analyze now I'm not a big formal notation person unless I have to translate it into some modeling and sim otherwise I like to use Visio and and I'd like to create my own key and produce things that everyone can understand cuz as James said earlier you use UML or sysml a lot of people look at it and they don't really know what it means even though those are standards that you use and since James was an author of the book I'll give him the laughs yeah so so documentation is is I think more important than most organizations give it credit for dedicate resources to and the sei had a big project which Evans alluding to we spent about three years with a bunch of architects hashing out the essentials of documentation and Phil rightly said you know documentation is for communication and analysis there are other purposes but keeping that at the forefront of your mind is really important because what the sei certainly doesn't want to recommend what I don't want to recommend is producing binders full of documentation you want to focus on the essential information to write down not a whole lot more than that you want to use means that are easy to update easy to communicate with people your architecture or your documentation serves a purpose it's not an end unto itself and so that you know working within that space you document what you need to talk to people understands when to document absolutely document for right it is careful not to get carried away all right thank err fulness to get carried away so as we are speaking some of our listeners are also chiming in for example in terms of being a good architect and the experience the feedback from Salem says being software architect needs a real-life experience with big size projects minimum 10 years of experience in other of our listeners say well this is really an experience pace 5 years experience so where I think all on the same page but I will connect this to one of the questions that we got several times if it takes the experience but how do we really create a credited program are there certificate programs out there what are some of the ways that people who want to get become an architect can get some of these skills and knowledge in addition to their own efforts is we definitely we have one that like we want to you teach some of our courses feel you want to get started with some of the education approaches opportunities out there and what might be other things that we can offer so I mean there there there are obviously your master's programs out there and again like I I described when I talked to earlier I prefer any program that's hands-on and that's one of the things you know not to plug one of our programs but Carnegie Mellon has a hands-on where you do a project for a real company for 16 months that to me was infinitely valuable when I was coming up because I knew that it was a safe space for me to learn and try these things that I was learning in in in the textbooks going forward and then we we actually when we tried to do you know the certification even just you know we have our architecture trade-off analysis method it was problematic when we were trying to certify people with that because there was such a cost to doing it it wasn't something you had to have a real problem as selim had said on online it has to be a significantly large problem so you have to observe them for a long period of time I don't think that there's any test because everything is so context specific I think that's why you don't see a lot of them personally yeah so I mean that there's a growing body of literature out there in software architecture books blogs the webinar series like we're contributing to right now the sei has a few small case studies in addition to to documentation of methods that you can apply in terms of formal coursework I think Phil's right yeah application to to real problems is important but that pretty much requires you're in a team-based exercise because again if it's too small a problem you're not really getting the the magnitude of the problem necessarily I think there's a combination of study and practice it just has to go hand in hand whether it's through a training program like the sei does have some certificate programs to teach some fundamental skills but by themselves without practice and application and without more reading into the fundamentals they're not going to get you all the way there you have to do it and some organizations also have their own internal certificate programs in going architects but again these are internal and we can all find you some advice just to beat the same point home over and over again being in the middle of the program that phil was talking about right now where I'm in the middle of the first half of the final project for this program it's it's really almost enlightening to be taking all the things that I've learned and then applying them hands-on and I've always been a person that appreciates the hands-on thing but just being able to kind of have that mentor aspect of I have to start up certified mentors for my team and we meet with them every week we go over what we've done just getting that immediate feedback is is critical so there's a question which I'm going to refer to our previous webinars but I want to put it out there software architecture influences cost cost versus technical that any tips on managing how how this can be managed in both of our previous webinars we actually tackle this subject so please go watch them but if the question still exists we will definitely answer that so my next question is how do you stay up-to-date because one of the challenges we have as technology changes very quickly technology drives some of the architectural decisions yesterday it was saw microservices today I enabled systems tomorrow it will be something else so any tips on that so so one thing I would recommend is keep challenging yourself get out of your comfort zone so for instance if you're an organization that only builds real-time embedded systems your day to day work experience is going to be focused on patterns tactics and architectures that support that environment you could be missing useful insights from other systems so you can go out and look for examples of published architectures you can go find an open-source system that's different than the kind of system usually built and trying to understand why they did things the way that they do but to push yourself in terms of different domains as one way to push the architecture fundamentals another thing that you can do is to take a look at a design that you are working on and say okay this seems like the right design if I change this requirement or this constraint would it still work just keep pushing at those fundamentals and I guess the the other thing in terms of technologies and maybe Phil you want to tackle this more but there is something to be said in terms of keeping up to date with with new technologies but as an architect especially if you have a dedicate a role of an architect the level of detail that you need is maybe different than that of a developer but if you want to yes it was funny I'll bring up a personal situation a couple of years ago James had brought me a project I won't say the customer don't worry but it was a domain that I had never been involved in a bunch of technologies that I really didn't know and and I was really upset about it I was like I don't think I'm the right person for this and he challenged me to get out of my comfort zone and get in there and I realized with a lot of the fundamentals and techniques that I had already known and applied in other situations yeah it was intense yes it was a lot of reading and yes there were days where I was like this is the wrong job for me but I but I did you know get through there and that's the idea is to you know as he said stay out of your comfort zone get involved in new technologies and we have a concept when we do a Thames and we push people to come up with what we call exploratory scenarios so this isn't anything that you would expect to be required today but we would like you to run the architecture through it you know so changing from you know one technology or you know AI NML how would you integrate an ml into your system and look and see what kind of stress that puts on it and what goes on and you can learn a lot about AI and ml and maybe you're never going to use it maybe it's not right for your problem but you could test your architecture do those because I'm hoping in any organization you have at least you have some time for professional development to do those kind of what-ifs and if you don't maybe you're in the wrong place so it's like you know a time is architecture tative analysis methods that we used to review architectures you can find all that information on our website but James you had another point that occurred to me is that there are community events right there there are webinars like this there are people who are explaining how a new technology they're using was helpful for their system tune into those events read those blog posts and understand why what they did was appropriate in their environment and how it might apply or might not in your own environment but again just to keep looking for sort of new new threads of information I also want to plug talking to your developers some more oh yeah I think you might get as an architect you might start to without doing a lot of you think things yourself you could get a big lead on what new technologies are out there that sort of thing just by talking to someone who's closer to the code I mean I think that most developers are usually no knowledgeable about what's at the forefront what's bleeding edge and this kind of another question I have for both of you but in my opinion it seems like you don't always want to be at the very forefront of the technology as that has a lot of risk with it right you might have bad documentation or bugs or various other things that you wouldn't have in a more mature technology so kind of carries from you to where where you think you should fall in terms of technology usage in a current system so my my thoughts are it's it's an always an it's it depends you know how critical is it I mean if it's the only thing like say you're doing something new and bleeding-edge there may only be one or two technology choices there so you don't have the luxury to pick other ones but a lot of times I try to stick to you know technologies that are well proven that have good support that are well-known if I can I you know and I don't want to use anything that obviously no one else is using and so yeah it's that middle sweet spot that that's really hard but sometimes you have to use the bleeding edge and that's that was the project that I alluded to with with that James got me on the hook for and so you know you just have to make the best decisions you can try to isolate it I guess so you said something that I use a lot when I'm talking about architecture to young architectures which is it depends and then of course like what does it depend on how can we give any guidance in terms of how to resolve that it depends the architecture 101 hurts I think that probably is one of the most common answers you'll get from an architect is this a good architecture well it depends what is the architecture supposed to do what is your what are your business goals what is your deployment environment look like and it depends comes up in so many contexts that any clarification depends on the context coming to a question that the sei gets a lot is this a good architecture for what I'm trying to do there's a discovery process we have to go through to answer that and good architects won't stop with it depends I'll tell you what it depends on it depends on your business goals depends on your timeline it depends on what your starting point is and what your your budget your resources might be depends yeah I think there's a lot of you know context is everything and so it's kind of interesting because your experience is part of your context and so you could assign James a design problem and give him the exact same requirements and he's going to come up with a different design than I would mine will be better no I'm kidding they'll they'll both probably meet your needs but they will be different in many ways and so I think that's what people need to understand that's why we we think that there really is no cookbook and you know a few years ago I guess LuAnn um it's more than a few now I'm getting old but when we started working on a tool which was the architecture expert we realized in a in a hurry that we needed to have a design assistant not an expert and it still needed interaction with the architect because of all the context and things and one thing I might caution against that I found myself doing in the past is falling into the same kind of technologies or footholds that you use on a different project just because you're comfortable with it and that's something that James talked about of getting outside of your comfort boundary so that you don't do that and yeah I think it's very important and also question yourself okay I used this last time and it made sense does it make sense to use it again what what assumptions might be different here it's a good that's probably a very good segue to one of the other questions as we get what are some of the common pitfalls experience of knots that you see architects falling into I think that is a great example of one just using so when you get comfortable with something you end up like applying it everything so I find that is especially true with development and true with architecture as well but one thing that I used to fall into as a developer it was like oh I use this language uncomfortable with it boom go do it I mean you'll find developers that are different some are like oh I want to learn a new language with everything and that's also an issue too right because if you're trying to use something new every single time it could not be right right like you could be so yeah yeah it depends the defense one of the things that I've seen in a lot of new architects coming coming out of development going into architecture is just this habit of chasing down every little detail and just getting into the technical weeds on every little question and not being able to step back and focus on the key issues that will help the other development teams get going because if your architect is doing using an architectural runway they're trying to facilitate the advancement of the whole team towards a towards a better solution than getting into a kind of a big upfront design and chasing down every little detail because it's interesting and we're all problem solvers at heart that's sort of the engineering mindset and so that's a really easy trap to fall into so so I think my biggest pitfall I see working with external customers is this falling in love with reuse ok reuse is important but you have to remember there's a cost to generalize things there's a cost to you know it's typically I think the numbers I see is triple and so you fall in love and then everything is all of a sudden the common service or a micro service and that may not may not apply because people look at that and they say well I can't use that solution that you came up with and if you don't reuse it at least three times if it's triple the cost and that makes that makes it very difficult so that's the pitfall I see and that comes back to what you said earlier about making data informed decisions not going with your gut not going with what seems like the right thing to do if I may add one ILC often is assuming that the architecture will not change there will not be the good architecture a couple years from now it will not be the architecture a decade from then that's if your system is successful it's gonna last another decade and that means tons of requirements changes deployment changes technology yeah absolutely architecture is a living and it's an evolving artifact of the system and not recognizing that that gets you on too technical that that gets you to the cost that gets you to all of the issues that you see down the line so that isn't yeah look at what the smart grid dead to power companies when that started coming up they had common system plans that they had for 20 30 years and then the smart grid changed the way that they operate and so that's something to be you know cognizant of the things you don't that aren't possible now will be possible in 10 or 20 years so good question this is also related to to the extent architects to do development and what other activities how much that a soft architect know about other closed areas like software development testing and should they be concerned about keeping up to date with those areas as well this again goes back to the daunting amount of skills and how actually connect to those any advice so so I believe in in the architect as part of a team not not the the director from on high and so understanding what your peers are dealing with and thinking of them as peers and getting a feedback as Keegan was saying earlier is really important understanding that there are certain things you can do in the architecture that makes it easier to inject tests to inject sample data to extract information on the health of the system over time that's really good to know and that's going to make those testers lives a lot easier but having that ongoing conversation is important you maybe don't need to know the ins and outs of all the tools that they're using but understanding their concerns and what things are costing them time and effort and just making it impossible to do their job that's the insights you want to go after yeah yeah you look at that laughs you know I don't need to understand every nuts-and-bolts detail of every continuous integration server that's out there but I do need to understand how I can help them you know whether it's with deployment and having rolling deployment strategies or blue/green deployment where we have two production servers that allow them to deploy things in a safe way that they can always roll back and things like that I think that's important so how can I help those people downstream and so that's like the elevator you know how much do I need to know you know about lingerie if I just want to buy it or something in that department if I go down it no I think it also goes the other direction too and I may be alluded to this in my opening statement but developers and testers should also know a little bit about architecture and if you can get I mean if your developer listening you should learn but if you can get them to take some time while you're also taking time to learn about what they're doing I think it just helps with the whole team like just it's a big team cohesion together yeah common vocabulary making each other's lives easier and it helps with your communication with them too because you can start getting into some of the more formal tools and things like that you actually on a very important point you can there's the software architecture career path becoming an architect and there's the architectural skill set that I think I agree any software engineering the team should not similar to any software engineer in the team should know a little bit off the testing they have ups or whatever is really relevant to that related to it there's actually another interesting question which goes to the large systems that we need to develop there are other domain experts yes and how do you bring those domain experts off to speed systems engineers or other engineers that you'd rely on what they may not appreciate software architecture or some of the aspects of the quality attributes or whatever that goes into that any experiences because we work with a lot of different domains as well so that's yeah so so one of the things that we we did was we had when we tried to do system a Tam's which is the architecture trade-off analysis at a higher level with this system we realized that we needed a lot more from domain experts you can not understand a lot about domain but you can understand a lot about software patterns and technologies and you can analyze things but we needed them in there I'm not an electrical engineer by and so we developed you know where we started training them to think architectural II and we use scenarios at that level as well and we're able to get their expertise in to look more in system and things like that and a lot of times you know I I have a lot of trouble with the system architects because they'll only give me so many resources and so finding that I feel almost like probably the developers feel when I constrain them and try I try to empathize and James sent me to consulting skills workshop a couple of years ago and you started to learn ok what's you know you have to figure out what's important to the other people you know and work with them in that way I think I think part of what made that work is starting with their concerns the quality actress what what is important to you what are the issues that are difficult for you to manage and how does that interrelate with the kinds of decisions I need to wrestle with so since we're putting James on the spot and he says he hires architect the question is but you've been interviewing as well so if you're interviewing an architect what are some of the questions that you might ask and it might be some of our listeners yeah might actually be going after some of these businesses true so so I care a lot about I care a lot about experience and I care about insight beyond the basics right so there's generally a theme of questions that I go after and I ask an architect candidate to tell me about an interesting design problem that they faced I'm fishing for something where if I do it this way I get this but I lose that if I do it that way it's a different trade-off but essentially it's not an obvious decision I want to find those examples I want to ask how did you recognize you were in that position how did you resolve that and and maybe most importantly and something a lot of candidates don't do nearly as well is how did that work out six months or a year later what did you learn from that to change your practices and essentially I'm really trying to get to more than I know the styles I know the typical architectures but I know why I know how to to reason about new constraints new requirements and adapt as I need to to a particular context and that's why I go not for particular questions but more a style of interviewing and I read an article probably 10 or 15 years ago the first time our old director London or throw had asked me to do an interview and I was really nervous and so I read an article when it said you should on a problem with them and rather than asking a particular question don't give them a blank whiteboard and say hey designed me this but have a few design snippets up there and a few scenarios and then say hey we have to change this design here are the problems I see with it and then work through those problems with them and because I truly believe I want to hire people rather than people that know something about one particular technology I want to hire smart people to use rationale and make decisions and work collaboratively with others and I think I can get a lot of insight that way so I try to avoid one question because I could ask them a question to make you completely bomb and get nervous but doing that problem but the article I remember said do not give them a blank slate they most people will panic when they're given so if you do that type of thing have a well thought out problem before you start and add on to that oh I I mean how often would you face a blank slate in real life yeah you're always going to be working with something or using something that's already been there that sort of thing like it's hardly ever Oh list me out the pros and cons of this certain thing it's usually like oh well we could use this and you would just have to know the pros and cons and you can kind of get that by working through a problem with somebody yeah a candidate who can very technically and in detail can answer the question of the it depends on how you go about that is probably good off so this is probably a good point to put a shameless plug our team is actually hiring both in software architecture researchers and software architects go look at our website and I have another very good question that comes from John Reese he asks as an architect we often become a hub among many stakeholders across many projects and the inflow of communication can be vast what is your technique to manage that if we manage this right so the interesting part of that to me is across many projects and in their number of organizations that do this they have a core architecture team that helps a number of projects to to concentrate that skillset and make it available across lots of projects in terms of managing the influx of things hire more architects that's that's the easy answer right I don't know I don't know that architecture makes that problem any more or less difficult than any other problem of dealing with a huge huge portions of incoming data I mean there are the obvious things what what's the essential what's the noise are there some rules that I can generate to do this am i involving myself and more things than I need to they're they're more detailed discussions that I can actually step back from and just wait for the conclusion as opposed to being involved at every stage it gets tough because anytime you give up something you're giving up knowledge right if you have another way to acquire that knowledge then you've got a good backstop yeah I believe you break down a system for a reason and that's so you can divide it and give parts of it to other people to work on and so maybe you know you try as an architect not to own all those team meetings there but the results of what they're doing and you give them a set of constraints and you give them a set of requirements for a particular piece of a system and then you coordinate those pieces going together and the integration points is what you would try to focus on at least I would especially if I was working across multiple systems because that's the whole idea and it's the same way when you go downstream you know you use that same breakdown to divide it into teams and have people work together and the integration points is where they come together so the other thing that can be helpful is to use this as a mentoring opportunity to grow new architects you find those talented developers who show a curiosity and an interest in this kind of domain and you groom them to help out all those of you who might be familiar with our software engineering Institute architecture techniques they're all stakeholder based and I've we've heard over the years some of the organizations use them to actually balance that communication when you have the quality attributes workshop that have brings different stakeholders you hear their perspective and that can also provide a lot of good information to the architect to rely on going forward so one question that's actually interesting now we're going back to some of the things that we've already discussed but role asks why an architect being hands-on what do you mean do we be encoding what does hands-on architect really mean so I often don't get involved in the actual writing of code but I do get involved in static analysis going through the code you know trying to figure out if it you know doesn't have you know certain code smells and things like that you know like like code used in many places and I'll also do some peer review or I'll look over people's shoulders because I want to still understand the technology and be involved I plan on working another 15 years so I can't you know stay away from code completely and so I do that but I generally it's not a responsibility I have I have so many other things that I'm already working on but but hands-on means you're doing those things and you're doing verification and you're really understanding what's going on I might have a different perspective just due to my day to day I end up do do developing all the time but that comes with the size of our team the project size that sort of thing so I'm working on a smaller team where I'm actually expected to contribute code to these things while also leading architecture with other developers that sort of thing so on bigger projects that's probably not going to apply or even in bigger bigger groups anything like that but on smaller teams I think you you might even be expected to know or at least like be able to break down line by line a piece of code and just different perspectives scale yes depending on scale so we're slowly coming to the end of our session I save this question as the last question so take your time what should someone who wants to be an architect know what are your top three to five suggested topics that's if they're getting nude into this and they want to become a software architect what what is the knowledge that you would expect what should they know that's an interesting question I mean it's it's a hard one I'll go with something that James and I have talked about the other day and often times when I go out on the web and I start looking for you know patterns or design help yeah I often would struggle and when you realize I talked about patterns and tactics earlier you know a lot of times when you look at different patterns you know you'll see 10 different variants of MVC and understanding and breaking those down in a way using tactics which are smaller transformations you can see that you have the MVC and then maybe something like mvvm is you know basically they're just decoupling things a little further and applying a couple of tactics and so that can help you go a long way so you don't get scared when you look and see 10 or 15 patterns I think that's a valuable skill mm-hmm I think knowing where to look for resources is a good one obviously books is a huge one online lectures things like that from leading leading architects it done more but I think just finding a good solid resource for what you're doing and kind of diving deep on that really helps and I would suggest for me what might be the key is to stretch beyond the technical to understand that architect is in the middle of not just technical concerns but business concerns and project management concerns and really getting to know how the context you're operating in your users your management your timelines your budget all of these things all of these constraints and forces that kind of shape the design understand how they do shape the design and how there's often not one the best architecture but it needs to accommodate that context and really learning that by by talking to more people in the organization understanding why things happen that can really help with the fundamentals yeah and if I might add to those I would probably also say are someone who wants to be an architect should be comfortable with understanding quality attributes quality attributes and how they relate to the tactics and patterns and the technology as well as where you bring those from different perspectives is one of the key skills that that they should definitely develop how to answer to summarize some of our previous conversations what it depends on and you find that so that's probably was another aspect so any last remarks that you want to leave our audience with in terms of how to become a better architect like we've probably is a summary statement and well hopefully we haven't scared anyone away well I can be daunting are a lot of things it's also incredibly rewarding so I would encourage you to keep at it and get started today I mean there's plenty of resources around just look online look at our books yeah and the earlier you start the the faster you will be useful yeah yeah it's it's collaboration and working with others I mean that's that's just an amazing skill making people feel ownership of what you're doing it gets buying because inevitably you're gonna have a situation where an important stakeholders not going to get what they want and so if you everyone has a sense of ownership and they understand the perspectives of others it can be a much easier and that takes us to the end of the hour I thank all what everyone who was online and who kept me busy here I couldn't catch all the comments and questions but we will definitely go back to them and I hope it was worth your time thanks a lot thank you thank you [Music] you you

Channel: Software Engineering Institute | Carnegie Mellon University

Views: 4,924

Rating: 4.8878503 out of 5

Keywords: Software Architecture, Software Architects, Software Development, Software Engineering

Id: VK_tDNtiAT4

Length: 62min 0sec (3720 seconds)

Published: Wed Mar 11 2020