Five Things Every Developer Should Know about Software Architecture • Simon Brown • GOTO 2020

[Music] really this talk is about dispelling a bunch of myths that i've seen over the past decade or so when i've been traveling the world and doing consulting and training and that sort of thing and the first myth i wanted to spell is probably the biggest one and whenever people think about software architecture they normally think about big design up front and and these two things are not the same so of course historically there has been a tendency towards big design upfront this is very predominant in the 80s and 90s and maybe the early 2000s to some extent this is the old waterfall thing kind of looks like this we've seen this a thousand times before this diagram this image actually comes from a paper written in the 1970s by winston royce and he's describing different approaches to software development and he actually says this underneath the illustration i believe in this concept but the implementation described above is risky and invites failure so what he's actually saying all those years ago is this kind of makes sense but please don't do it and if you read further what he actually talks about is what we really now know as the agile and iterative and incremental approaches to software development so a bunch of stuff happens through the 80s 90s including some of the uh the very early adore stuff and rapid application development and dsdm and things and eventually we get to 2001 and the uh creation of the agile manifesto the actual manifesto says this on the front page we value responding to change over following a plan and of course at face value this seems to throw everything we've ever known on its head and what i've seen over the past 20 years or so is that many organizations have flipped from doing big deal upfront to literally nothing at all and both of these extremes are not great and there's a great quote i'd like to use here by dave thomas and he says this big design upfront is done i agree for a whole bunch of reasons and doing no design upfront is even dumber and this really epitomizes what i've seen over the past uh couple of decades or so so the big question everybody's kind of really wanting to have answered is well how much up front design should you do now of course wall tool says do all of it and agile on the face of it anyway seems to suggest not doing any at all and the answer is well you need to figure out what it is you're doing and it depends what does it depend on sometimes you know what you're doing and sometimes you don't so if you're working in a big enterprise environment and you might be doing a system replacement you might have a fairly good fixed idea of what you want to be delivering if you are creating a startup company and putting a product out into the market for the first time you've got to do the mvp thing and get some feedback and experimentation and so on and so forth so in that situation you might need to take a slightly different approach so the general way of describing how much upfront design should you need to do is really what we need to do just enough right what does that actually mean i think the problem with upfront design is that it paints a picture of putting a perfect blueprint a perfect end goal an end state um and that's not really what we're trying to do here i i don't think we're trying to create that perfect end state or complete architecture i think we're trying to do something else instead there's a great blog post by josh kirievsky it's called evolutionary design subtitled beginning with the primitive whole and this is the thing we've seen a thousand times before as well so you put out a first version of something and then you add features get some feedback and so on and so forth the thing very few people talk about is how do we actually get to that first version so in order to do the iterative and incremental thing we need to have a good set of foundations we need to choose in this case the overall shape the starting materials potentially the extension points we think we might want to use in the future and so on and so forth so we need to put some design some thinking into that initial first version and that's really what i'm talking about here it's about adding that starting point creating that starting point why do we want to do this imagine starting out with a new software development project or product and you're sketching out some ideas on a whiteboard when you are sketching out those ideas either on your own or collaboratively and we'll talk about that later you really want to be able to answer two basic questions number one do the diagrams we are drawing do they reflect what we think we actually want to go and build and question number two how confident are we that design that solution is actually going to work and be feasible in order to get to the point of drawing diagrams on whiteboards you need to make some decisions and there's a really nice quote by grady booch where he talks about the definition of architecture or his definition of architecture and he says this architecture represents the significant decisions where significance is measured by cost of change and the reason i like this definition of software architecture is that it really says some in some design decisions are more important than others if you were to go and write down all of the decisions you've ever made on your current product or project and try to sort them by how important or significant they are what you'll find very quickly is it it's very hard to draw a line between all of this stuff up here is significant and all of this stuff down here is not significant so it's a it's a gradient of different types of decisions with different levels of significance the ones we really want to be focusing on the ones that are hard to change ultimately are things like choice of language so is this going to be a java monolith or ruby monolith you know once we've chosen our language that's kind of hard to change the overall structure of the thing we're building so if we choose to build a monolith converting that to microservices architecture is something that involves quite a lot of time and effort and of course the opposite is true so really a lot of these significant decisions revolve around technology choices major technology choices the things that become ingrained into our code bases and the way that we use these technologies in terms of the structure and the modularity one of the things to be careful of here is many teams will say it doesn't really matter about technology choices because what we're going to do is we're going to build a java monolith and we're going to use ports and adapters or uncle bob martin's clean architecture so we're going to isolate all of our business logic and make all of our tech choices deferrable and decoupled from our code base that's fine but that has a set of trade-offs and the significant decision you just made is one around structure and that has its own set of tradeoffs so what's not important curly braces white's face tabs all of that stuff don't care about i know we have all these religious debates but it really doesn't matter we can just chuck some tawning on it and fix it one might be or the other there's lots of material out there on agile architecture uh something i like is scott ambler's approach and he has a great essay on agile architecture that you can basically summarize in one sentence like this you should base your architecture on your requirements so in other words don't make decisions unless you have reason for making those decisions travel light so do the just enough thing you know be agile and make sure you prove your architecture with concrete experiments what's a concrete experiment is nothing more than these things uh proof of concept uh prototype of spiker tracer we have lots different names for the same thing the same thing is basically writing some code to prove our hypothesis and i like to include the concrete experimentation as a part of my upfront design process one of the more interesting questions here as well how do i know which concrete experiments to run how do i know which bits my system i want to prototype before i start getting into writing lots of production code something that the rational unified process said all those years ago rupp is that we should identify and mitigate our highest priority risks and i think this is a great thing to do today rupp was a risk-driven approach to building software and it front loaded all of the big risky stuff to the the start of the project life cycle there's a bit of unpacking to do here which we don't have time for but feel free feel free to ask some questions afterwards you know what's a higher priority risk versus low priority risk and also how do you identify risks in the first place one of the typical techniques we've used is we'll get the single project manager or the single architect to go write a list of all the risks that they perceive with that solution that's not particularly a good way to do it because risks much like estimates are subjective so there's a technique i created a while back it's called risk storming and it's a visual collaborative kind of game storming inspired approach to identifying risks collaborative collaboratively as the groups that's something you can go look up online to go back to the how much upfront design should we do question what we're really trying to do here is we're trying to do enough upfront design in order to put that starting point in place and set an initial direction and i do want to stress that's an initial direction so i'm quite happy for the set of decisions and the solution to change as we deliver stuff and get feedback and have real users using our software but any changes we make should be done in a structured and justified manner one of the other ways to think about offline design is well when do we stop and i think upfront design is an issue of an incremental process so it might be something you need to do um one or more times and you should stop when you can do this type of stuff so you have a good idea of what your context is what the scope the system is you're building how it fits into the world around it what the key requirements are what the key non-functional requirements are and those sorts of things so so really that's my kind of one takeaway slide about how much upfront design should we do and where should we stop so that's thing number one thing number two is that every team needs to think about all that stuff what happens if teams don't think about architecture you get a mess chaos chaos manifests itself in a whole bunch of different ways big balls of mud spaghetti code systems you know code bases are just horrible to work with code bases with an inconsistent approaches to solving the same problems so i've seen a number of codebases over the years with multiple logging frameworks and the same monolith multiple database access frameworks in the same monolith monolithic code base and so on and so forth i've seen systems that that are hard to deploy hard to look after hard to maintain logging is a problem or they don't have appropriate quality attributes like scaling and security performance so that's the category of stuff that i think doing some upfront design and architecture really helps to address and all of that stuff is applicable to every team one of the ways i like to think about software architecture is that it's about technical leadership and when you think about it that way you kind of quickly realize that actually every software development team needs some degree of technical leadership if you're a one-person team you need a small amount of technical leadership if you're a hundred two hundred thousand person team then you need a much bigger degree of technical leadership but nonetheless you need technical leadership i'm also going to say this every software system or every product also needs technical leadership and the reason i say this is because i see lots of teams these days adopting things like the spotify model where you've got squads who are working on business features and they might be given autonomy and authority to change multiple pieces of code and multiple repositories on multiple products if that scales up what i've tended to see happen is that because you've got all of these teams potentially changing the same code bases because there's no single ownership of those code bases sometimes the teams start making changes in very inconsistent ways so do also think about technical leadership from that perspective as well number three the software architecture role is about coding coaching and collaboration so this is a myth i want to dispel because again the the old-fashioned approach to software architecture is the dictatorship approach where architects work on their own they produced a huge bid document and they basically give that document to a team of developers and just tell them to go get on with it that's not how we should be doing stuff that's how we used to do stuff in the past and these architects also often used to use these documents as batons in a relay race i don't like this approach i call this approach ass it's just architecture as a service it's just a one-way stream of architecture decisions with ultimately no feedback loops and one of the things i like to tell teams is that your technical leadership should be continuous so don't think about getting an architect in for the first two or four weeks of your project lifecycle you need to have someone doing the architecture role throughout the entire life cycle that could be one person or it could be a whole bunch of people that's entirely up to you and we'll talk about that in a second different types of teams need different leadership styles so this is something i realized a few years back and royal shrove has a great book called elastic leadership that talks about this problem from a team leader perspective i think the same issue happens from a technical leadership perspective so if you've got a team of developers and they're fairly junior and they don't really know what they're doing because they don't have much experience generally telling them what to do and helping them in a much more direct way in the kind of commanding control way that makes that team go faster if you have a team of rockstar ninja 10xs or whatever silly tone we use to describe really experienced developers don't micromanage them just remove the blockers and get out of their way so different levels of maturity you know different types of teams with different levels of maturity need different leadership styles even with the immature team the inexperienced team you still need to give them some time and space so that they can start to understand and solve their own problems and therefore become more mature so that's the other thing to to kind of bear in mind here and the reason i bring left this up is because teams often ask me should we have one person doing the architectural or should we have many people you know should we share the role out amongst the entire team and it's up to you my advice and a good starting point is to do pair architecting and this is what i used to practice myself when i uh built software for consulting companies back in london all those years ago so it used to be myself and another person typically another architect but not always um you know two heads to bed and one etc etc in order to do that you need your collaboration skills and this really points to having good soft skills in general so this is an aspect to the software architectural that we don't talk about enough in the industry but really this is kind of the make or break stuff if you if you can't lead people well if you can't collaborate well if you can't influence a team well you're going to have a really hard time doing the architectural so i would urge you if especially if you're moving into your first architecture roles to put some time and effort into learning some of that soft skill stuff let's not forget the tech stuff should architects write code my opinion on this is most definitely yes and my preferred approach here is the architect's right production code this is definitely what i do as far as possible the reason i like this approach is because then you as an architect have a pulse on the code base you can see what's going on you can see that people are following the guidelines that we've all agreed to collaboratively and you can make sure the code base is going in the right direction if you're a bit more hands-off that's much much harder to do most of the good software architects i know are also good software developers so again they have a good technical background that they might be specialists in building java server side apps or dotnet apps or rubric apps or ios apps or oracle database driven apps so they have some deep specialism but they also have a broader range of design knowledge architecture knowledge knowledge about non-functional requirements and cross-cutting concerns and logging and operability and all that sort of stuff and this is super important because if you're designing software you need to understand technology in order to assess trade-offs unfortunately there's no perfect silver bullet solution to any problem so you know any decision we make is going to have us have trade-offs and if you don't have the pre-requisite technical skills again you can't answer these two questions i outlined before so the software architecture role it can be done by one or many people but it's multifaceted it requires good tech skills and good non-tech skills four my favorites uh you don't need to use uml this is one of the things that for some reason scares people off doing a software architectural when i do these talks in front of a live audience i i ask people how many people here use uml and typically it's in the kind of one out of ten ratio there are a few exceptions this varies country to country cultures culture but generally it's about one out of ten people so not a huge number of people these days using uml why i've heard every excuse you can possibly imagine um it's too complicated it's too detailed the tooling sucks you'll be seen as old-fashioned or in the case of this guy he said it's a very elaborate waste of time that might be true if you overuse uml i mean uml is just a language it's just a notation you can overuse it you can under use it it's entirely up to you what is the recommended advice these days in terms of diagramming and presenting your designs in a visual manner well the answer many people give you is just use a whiteboard and that's that's okay you know that's a decent piece of advice but unfortunately it provides absolutely no guidance so one of the things i i typically do when i'm allowed to travel and we're not in a pandemic is i get to travel around the world and i run architecture carter's architecture workshops design workshops where we get people into groups we give them some requirements and we say go away for like an hour and a half and do some design and draw some diagrams to illustrate and showcase your solution and the diagrams look like this autumnally so this is boxes and snow lines this is my favorite this is like the airline route map so that green blob is amsterdam skipple or london at the heathrow it's like a big airport lots of routes around the world this one here doesn't even tell you anything about the business domain it just says business logic in the middle well this one has no tech choices this one is a bunch of c-sharp things floating around a database of these components or modules or microservices i have no idea this one is like an adventure game start at the top go down follow the different arrows no matter which path you choose you always die and end up in the trap on the left-hand side it's rather unfortunate this one here has a couple of unlabeled users that i call stormtroopers they're just faceless anonymous clones attacking this reporting service or you get a mess now i've got gigabytes and gigabytes and thousands of photos uh kicking around on on hard disks from my workshops over the past 10 years and they all look like this and people often say well what happens if you let these groups use a tool and not pen and paper well guess what the same thing happens just in a tool and you can see this yourself if you go to google and you do a search for software architecture diagram you get the same garbage but it just looks nicer we've got nice colors and fonts and then shading things but we've got different size boxes for unknown reasons we've got acronyms unlabeled lines it's just a mess the reason i put so much focus on diagrams is because if your diagrams don't make sense you can't answer these two questions right you can't have the right conversations to even start answering these two questions so i think teams need a ubiquitous language to communicate effectively and i'm not talking about a ddd domain driven design ubiquitous language i'm talking about a visual ubiquitous language to describe software architecture now we could use uml i mean ul is a perfectly good ubiquitous language for describing architecture but nobody wants to use it for a whole bunch of reasons so something i came up with a number of years ago it's called the c4 model and it's a set of hierarchical diagrams that you can use to describe different levels of abstraction in your software systems yet c4 stands for context contains components and code and the easiest way to think about this is it's like diagrams as maps so if you go into google maps and you start a very high level you know you're flying over the landscape of 30 000 feet the lower you go the more detail you see so it's same thing with the software architecture diagrams we've got different levels of diagrams that show you different levels of detail and those different levels of diagrams allow you to therefore have different conversations and tell different stories with different audiences the c4 model does not prescribe any particular notation so it's notation independent you can use boxes and lines and that's what most people tend to do you can also use uml or csml or archimedes i do see teams occasionally do this but um typically these boxes and lines and if you're going to have boxes lines you need a diagram key that's the the most important thing here so really the c4 model is about having a common set of abstractions and a variable of varying notation you can find more information about that on c4model.com one of the questions people always ask me is what tooling do you recommend and something i was pleased to see in the thoughtworks tech radar a couple of weeks ago that the new version that came out is that diagrams as code got a mention it blips on the radar in trial as well as the techniques so this is where you're creating diagrams using a textual format uh like a domain a domain specific language or maybe actual programming language code itself so when we were in lockdown deep in like april may time because i had nothing much to do i built a domain specific language it's called the structurizer dsl and it's it was specifically designed to support the stifle model and it lets you create c4 model diagrams with quite a succinct domain specific language it also supports things like cloud architecture diagrams because lots of people seem to be wanting to draw those sorts of things these days with all the amazon icon sets and stuff like that the most powerful feature about the structurizer dsl and the structurizer dsl is accompanied with uh the structuralizer command line interface and both of these things are open source and available on github the the most powerful thing about structurizer dsl is you create a single file a single source file that contains essentially it defines a model of your software system from different levels of abstraction and then using the structurizer cli the command line interface you can then generate multiple diagrams from that single source file and you can also generate those multiple diagrams in multiple formats so you can use multiple rendering tools to essentially render those diagrams so in this slide here i've got a single source file and that's been rendered using plant uml mermaid iliograph and my own structurizer tooling so that's a really nice way to get a bunch of diagrams very quickly and try out lots of tools without actually getting locked into any of them so that's my thoughts on diagramming uh the last thing i want to very briefly talk about is that a good architecture enables and gives you agility so one of the things we've kind of heard over the past couple of decades is that you've got this agile thing you've got this architecture thing and they're somehow different and they're competing and that's actually not the case from my perspective they're actually complementary what is agile about you have a number of different ways to think about agile for some people it's about moving fast and embracing change and getting feedback and delivering value quickly and and ready for me that's the process or mechanical side of agile software development and in essence really it's just incremental and iterative development done really well and really rapidly for other people agile is more about a mindset of continuous improvement so whenever just doing stuff all the time without looking at what we've done how we can improve it and i think this is really what we we want to be kind of more aligning ourselves with from that perspective then one of the things i like to say to teams says well think about agility which is the ability to move fast as a quality attribute and think about where you need that agility do you need that level of agility across your entire code base or maybe do you only need agility in certain parts of your code base that represent particularly volatile parts of your business process for example once you have that in mind you can then figure out how to support the appropriate level of agility so do you go monolith you go microservices you go a hybrid approach maybe have most of your stuff in a monolith with some stuff around the outside of your monolith as microservices because that's more volatile and that's we need more agility maybe a good architecture buys you agility so a good architecture enables agility what do i mean by a good architecture it's kind of subjective but for me a good architecture is really it's really talking about something that's well structured and highly modular and this kind of makes sense doesn't it if you've ever worked on a code base that's a horrible big ball of mud when you change something over here all this stuff down here breaks and you're not really sure why that slows you down on the other hand if you've worked on a software system that's very well structured and when you make a change that changes isolated into a small block small unit of your code base that clean structure allows you to move much faster you don't get that characteristic for free though you don't get agility just by hacking out some code and kind of hoping for the best so you need to put some thought into this george fairbanks has a great book on software architecture called just enough software architecture and in that book he says this a good architecture rarely happens through architecture in different design what's architecture in different design it's basically just choosing a solution it's making decisions because that's what we've always done in the past so i see that a lot especially big companies or people are making decisions because of trend hype and fashion and i see this a lot these days especially with things like microservices and serverless based architectures so you're going to see a new team like we're going to build a new system and we're going to use microservices we're going to use functions as a service and we're going to stick everything else in kubernetes like why and now because why not that's not a good way to make decisions a couple of years ago a couple years ago more won that five years ago i threw this tweet out and i said if people can't belong this properly please don't adopt microservices because it's not going to help you and i still see this today i still i see large organizations and they have these legacy 10 15 year olds java co bases and they're just horrible big balls and mud the horrible monolithic applications and they think the only way to fix this is to go microservices and what they do is they they start essentially from scratch with a view to rewrite their monolith as a collection of microservices they have the same mindset and what they basically end up with is a distributed version of what they had before because they don't realize they need to take a different design approach and then at two years down the line like oh this is really slow and brittle and we have to lock that deploy everything up like i know you're thinking about this the wrong way so you need to put some thoughts into what you're doing so that tweet got a bunch of retweets which i was quite impressed with but then i got completely outclassed by the architect clippy i see you have a poorly structured monolith would you like me to convert it into poorly structured set of microservices no so again just make sure you think about these decisions before we make them you know significant decisions are the things that are hard to change so that's me five things every developer should know about software architecture thanks for listening you

Channel: GOTO Conferences

Views: 155,401

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, Programming, Software Engineering, GOTOpia, GOTOpia November, Simon Brown, Software Architecture, Architecture, C4 Model, Back-end, Culture, Agility, Agile Software Develeopment

Id: 9Az0q2XHtH8

Length: 29min 44sec (1784 seconds)

Published: Mon Jan 18 2021