What Software Architecture Should Look Like • Dave Farley • GOTO 2022

[Music] wikipedia defines software architecture as the functional structures of a software system and the discipline of creating such structures and systems well you can kind of see what they mean but it's a pretty dry definition and it raises as many questions as it really answers after all what does fundamental mean anyway and for that matter what does structure mean in this context too the last bit is really only saying architecture is produced by a disciplined approach to architecting things to be fair to wikipedia this is a difficult idea to nail down even though i think that most of us would agree that it's an important one in some way so here is my take on software architecture what does it mean and what does it take to do a good job of it hi i'm dave farley of continuous delivery welcome to my channel if you haven't been here before please do hit subscribe and if you enjoy the content today hit like as well my thinking on software development design and architecture is deeply informed by what i think of as an engineering approach i described this generally applicable approach in my new book modern software engineering it's doing rather well in the rankings on amazon at the moment and he's collecting some very nice reviews so do check it out there's a link to that in the description below too i think of myself as a software developer probably more accurately these days i'm a consultant first than a developer second but i also spent a considerable part of my career being called a software architect in one form or another i couldn't then and can't now tell you any significant difference in my focus between the times when i was called a developer and the times when i was called an architect ultimately i think this is about design maybe it's about design at different scales but i confess that i'm rather skeptical of that the slippery nature of defining architecture as design on a bigger scale is that designing information systems is kind of fractal there are things that matter at all levels of detail and there are tiny details that would will invalidate grand assumptions and there are grand assumptions that can prevent effective progress at the level of tiny detail a popular description of software architecture comes from grady booch who says architecture represents the significant design decisions that shape a system where significance is measured by cost of change i don't disagree with this definition but i don't like it very much it implies that these are the details that we need to get right at the start to succeed it makes some sense if we're looking retrospectively at a system but it's a pretty poor guide to building one be omniscient for something this complex that simply isn't going to happen for me there's only one approach to architecture that makes any sense at all it has to be an evolutionary process we will guide the design of our system by modifying the constraints that we apply to that design these constraints or rules of the road are what we think makes sense at any given point these form an important aspect of our architecture we create a kind of tourist map of the system that we can use as a tool to guide design choices here's the tourist map from one of my systems this map guides the evolution of the system in the direction of the outcomes that we aim to achieve if we're doing a good job we'll discover our inevitable mistakes and update our tourist map as our understanding deepens let's try and walk into this problem a little bit more carefully one great definition of software architecture is it's the stuff that we wish we'd got right at the start of a project perhaps a little more helpfully it's the shared understanding that the expert developed developers have of the system design both of these definitions come from ralph johnson i'd add a couple of words to the second it's a snapshot of the shared understanding of the expert developers you hope it doesn't change too often but you should expect it to change i think that in combination these definitions get something rather important right at the start of any project we don't yet know the answers but we still need to make some guesses about what may work in order to begin if we're going to be creating this system as part of a team we need a way to discuss design ideas to communicate with each other about the system and think about where different behaviours of the system will be handled our tourist map will help a lot with these conversations debating new features in front of the tourist map can we can explore the implications of our design choices and maybe spot improvements or mistakes in the map i like ralph johnson's focus on the stuff we wish we got right rather than a focus on the stuff we must get right we focus on the stuff that worry us i like it because we almost certainly won't get it right first time but it is important stuff that aligns very nicely with my thinking and my approach to development in general really which is significantly focused on maintaining my freedom to get things wrong that probably sounds a bit weird but i want the freedom to make a mistake and the ability to learn and recover from it for that we need the ability to contain the complexity and to manage it fundamentally the architecture of our system is realized in the shapes that we make with our code all software has an architecture in some of them though it happened by accident in others it was worked on with great care and grew to be something good good architecture allows us to isolate one part of the problem from another this could be functional let's create services aligned with bounded context so that they can change more independently of one another or it could be in the jargon of architects non-functional let's share the data in our system so that it can scale linearly as demand rises more formal approaches to architecture often discuss architectural measures of quality this is the list from iso i can see how talking about the ilities of a system can help but in reality i don't really buy into the idea of non-functional requirements very much inside every non-functional requirement is a feature of the system that users care about if not why are we doing it at all even something as seemingly self-centered as making our code maintainable is really about ensuring our ability to continue to deliver value to our users in the future these things security performance scalability testability deployability resilience and so on are behaviors of our system as much as taking payment with a credit card we have to design the system to exhibit these behaviors if we are sensible we will design our system to manage the complexity of these things by compartmentalizing them from other behaviors where we can the reason that people get worried about these kinds of qualities of a system and try to keep them somewhat differently is that they tend to have a broader impact than many features you can't usually fix security or scalability or resilience in a single place in your system these are often referred to as cross-cutting concerns but that doesn't mean that these things are architectural concerns and other things are not these are just behaviours that people often forget about while chasing other kinds of features whether you call yourself an architect or not and whether you work in a big team or alone for any given piece of software you need to decide how it should behave and that means how you process credit cards or what color your buttons are as well as is it okay to leak money to attackers or fall over when there are more than three people using it this is our responsibility as software developers for some types of systems some of these problems are genuinely difficult and it helps a lot when you have smart experienced people on the team who have seen ways to cope before but that doesn't mean that architecture is somebody else's problem whether you are in your first day on the job or a grizzled veteran your decisions may impact on the architecture of the system this is another of those slippery aspects of software there is very little distance between what looks like a small change and that small change having a massive impact in fact the only things between that being true are look or a good working design and architecture that we understand and can use to guide our fine-grained decisions so that gives us another step forward in understanding this complex concept a little better the architecture of our software is the collection of constraints that we agree to adopt and maintain that will provide us some protection from making dumb mistakes my preference is to engage every developer whatever their experience in architectural discussions allowing everyone to develop their own understanding of the architecture and to contribute to it as development proceeds architect as a job description has seen a bit of a decline in recent years this is mostly in response to agile development's reaction against big upfront design the problem with this is as dave thomas famously said big upfront design is dumb no upfront design is dumber so we need to start somewhere but where the real answer is that you make a guess based on your understanding of the problem so far and your experience if you're any good at this kind of thing you try to treat this guess as an experiment how could you show that your guess is wrong try that working incrementally whether in fine-grained design or big picture architecture is essential to doing a good job of anything complex there's a caveat to this but as ever you need to understand the trade-offs if the problem that you are solving is pretty common then you could adopt a tried and tested architectural approach and off the peg architecture if you like this is a good idea as long as you understand the constraints and the fit of that architecture to your problem because the other big problem with software architecture as an idea is that there's no one size fits all there's no such thing as a generically good architecture rather it's a matter of whether a particular architecture fits the needs of the system one of the most successful widely applicable architectures was a layered system backed up by a relational database something like this a ui some logic and a database for systems with a moderate number of users and relatively simple crud style features this was a very good choice i think that one of the reasons it was a good choice though is quite informative i think a principal reason that the clever but slow idea of transactions in relational databases took hold was because it allowed programmers to write multi-user systems without worrying too much about the horrible complexity of concurrency if you open a transaction read some data change it and write it out again the database will block any other access to that data while you're dealing with it and as long as as long as your transaction lasts it locks access to the data this was very good if this architecture fit your problem it kept the programming model simple it's still good if it fits your problem today and it fits quite a lot of problems quite well however as the web grew in influence and massive scale computing became more common having a relational database management system as a synchronization point to your data a source of truth simply didn't scale so people started experimenting with other approaches i was once asked to consult on a huge project they had decided to use a nosql database as their primary data store which is fine but they'd forgotten or didn't realize the importance of the protection that transactions that they were more accustomed to had given them this nosql database wasn't transactional so data was shared by multiple processes and written to by multiple processes and the results were essentially random whoever wrote last got to store their changes everyone else would lose theirs and without any indication of the loss it made me feel a bit queasy just to think about this big system with all the data shared and no protection or coordination between concurrent processes this was a problem of not really thinking about the architecture of the system but only the tools that's not the same thing a collection of tools alone doesn't make a software architecture this team had seen one of the big web companies develop this great looking nosql database to help them scale up and it did that but only in the context of a whole raft of other choices and constraints that this team hadn't thought to apply there is another somewhat similar very common mistake that probably is a little closer to your own software microservices were invented to decouple development they're intended to be independently deployable freeing teams to work separately from other teams which means you don't get to test them together before you release if you are netflix or amazon this is fantastic if you are a small development shop with a handful of developers it's almost certainly overkill and so pretty inefficient and worse than that most teams that i see that claim to practice microservice approach aren't they don't have independently deployable services which means that they have to test them all together before they feel confident to release them this is in fact a distributed monolith which is a rather complex choice good for some things but never simple i think that software is more complicated than we often think so the sensible thing is to approach it with a little bit more caution i don't mean that we should agonize for weeks or months before taking the first step completely the opposite in fact but we should work on the assumption that our best guess so far is almost certainly wrong so architect our systems to allow us to recover when we learn more and find out where it's wrong this takes skill certainly but it is realistically the only sensible choice in my opinion architecting a complex system is not something that someone in an ivory tower does at the start of a project it's also only partly intentional like more fine-grained design decisions it's an iterative incremental exercise in a kind of guided evolutionary process this is not terribly precise and sometimes even despite cleverness expertise and experience people get things wrong that is i am afraid an inevitable consequence of dealing with something as tricky and complex as software a few years ago a performance optimization strategy in intel processors meant that encryption could be broken obviating all of the clever security architecture features in the web cloud on-premises systems even mobile devices and on pretty much every operating system that is a salutary lesson in how fragile architecture and design can be to tiny things a good way to approach this is to think about the things that you are unsure of i was chatting to my friend kevin henny a few days ago and we were talking about design he said as soon as someone says i don't know there's a seam in the design that's quite a good way to think start the design of your system with your best guesses based on what you know so far and be on the lookout for the things that you don't know or are unsure about you don't have to do a depth first exploration of these things in fact you shouldn't but you do think about how to insulate the stuff that you do understand from the things that you don't crude sketches in code of those things that you don't yet understand an abstraction can act as placeholders while you make progress and grow your understanding for the bits of the code that you do know don't build word world-class security into the first sketches of your system don't take on the burden of making your system perfectly scalable from day one but do design your system as best as you can imagine so that you will be able to enhance security without undoing the progress that you've already made and that you can take advantage of your great work so far and allocate it differently so that it does scale up if that's a demand insulate the parts of the system that you understand well from those that you don't yet these kinds of design approaches are at the heart of what i describe in my modern software engineering book using the techniques to manage complexity to give you a chance to go back and enhance or even correct architecture missteps when you discover them when we built our exchange at lmax we had three different fundamental attempts at the basic architecture of our system but because we'd taken an incremental approach to its design only a small part of our effort was lost on each change my final piece of advice on software architecture is to aim to be intentionally a little bit vague about the detail architecture should guide our decisions with constraints but in great architecture there are actually relatively few constraints but those that are there are pretty rigidly enforced thank you very much for watching you

Channel: GOTO Conferences

Views: 30,399

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, Programming, Software Engineering, GOTOpia, Tech, Software Development, Tech Channel, GOTO x Dave Farley, Dave Farley, Software Architecture, DevOps

Id: Eg_dapdKCHU

Length: 19min 25sec (1165 seconds)

Published: Fri May 06 2022