How to Think Like an Architect - Mark Richards

Summary

"How to Think Like an Architect" by Mark Richards at the Developer Summit highlights the importance of adopting an architectural mindset, whether or not you hold the title of an architect. Richards emphasizes that thinking like an architect involves understanding business drivers, expanding your technical knowledge, and analyzing trade-offs. By learning these skills, even developers can enhance their decision-making processes and contribute to creating more scalable, high-performance systems. Key lessons include the necessity to translate business needs into architectural requirements and to broaden technical expertise while maintaining depth in specific areas.

Highlights

• You don't have to be an architect to think like one. Adopt an architectural perspective for better system development. 👀
• Architectural thinking involves translating business drivers into architecture characteristics such as scalability and performance. 🌐
• Developers usually focus on code efficiency, but thinking architecturally requires understanding broader implications and trade-offs. 🔄
• Expanding technical breadth while maintaining depth in certain areas is crucial for developers aiming for architectural roles. 🚀
• Resources like ThoughtWorks and InfoQ help maintain an up-to-date understanding of current technologies. 📈

Key Takeaways

• Thinking like an architect is essential, even if you're not one. It leads to more effective system building! 🏗️
• Architects translate business requirements into architectural characteristics like scalability, availability, and security. 🔄
• Expanding technical knowledge and understanding trade-offs are key to an architectural mindset! 💡
• Use resources like InfoQ, DZone, and ThoughtWorks Radar to stay informed and broaden your tech knowledge. 📚
• Take 20 minutes daily for self-development to boost your career progression! ⏰

Overview

In his keynote, Mark Richards eagerly discusses the value of thinking like an architect and how it empowers developers to build more reliable systems. He dives into the critical skills one must develop, such as translating business needs into architectural characteristics. By learning to see problems through an architect's lens, even those not in the architectural role can make more informed decisions.

Richards illustrates how technical breadth must be expanded to understand and evaluate multiple potential solutions to a problem. He introduces the triangle of knowledge concept, emphasizing the importance of knowing ‘what you don’t know’. This empowers professionals to adopt suitable technologies and frameworks efficiently, instead of sticking to familiar but potentially outdated solutions.

Furthermore, Richards advises on everyday practices and resources like InfoQ, DZone, and ThoughtWorks Radar to help professionals broaden their technical horizons. By dedicating just 20 minutes daily to personal education and career advancement, individuals can significantly boost their proficiency and readiness for more strategic roles. Thinking like an architect becomes not just a mindset but a practical daily exercise.

How to Think Like an Architect - Mark Richards Transcription

• 00:00 - 00:30 [Music] you don't have to be a software architect to think like a software architect and this gives you several advantages first a more effective and well-built system even as a developer
• 00:30 - 01:00 and also a good head start on a really fun and rewarding career path so that's what I want to show you in this Keynote you don't have to be an architect to think like an architect but what does that even mean so I want to start by showing you these clouds what are these well they're clouds but it's very fascinating that because to different people
• 01:00 - 01:30 these clouds represent different things to a meteorologist they look up at the sky at those clouds and they see all the cloud types and they know what the weather patterns and what to expect maybe as an artist you look up at those same exact clouds and you're picturing a beautiful dramatic scene of course all of us are nit so when we look up at the sky and see those clouds yeah we kind of think of
• 01:30 - 02:00 cloud-based deployments The Internet of Things what does this mean when I showed you those clouds everybody sees them with a different eye a different perspective and that's what I want to show you about architectural thinking what does it mean to think like an architect to to see a problem with an architect's eye an architect's
• 02:00 - 02:30 point of view well we're going to answer that question and that's what my keynote is all about first want to actually just show you why thinking like an architect is important regardless of your role so let's say we're in a situation where we're doing some messaging or events driven architecture and what you see here on the far right hand side is an
• 02:30 - 03:00 order placement service and it's going to send a message to payment and inventory and so once I place an order I have to pay for it and we have to decrement inventory and of course we have a database and so you have a choice to make as a developer hmm well when I send that order should I include all of that order payload all 45 different attributes or
• 03:00 - 03:30 should I only send just the key because with a full day to payload of course I insert the data I send all of that message over and payment and inventory have all the data now but I wonder I've got another Choice what about key based you see I still if I'm processing that order I still insert that order into the database but now I only send the key out in that message or
• 03:30 - 04:00 event well payments and inventory both receive that but now they have to query the database in order to get the information they need so what do we do well let's see obviously says the developer the full event payloads the right choice because we get much better scalability and performance I don't have to go to the database this is one of the ways of creating scalable systems and high performance systems
• 04:00 - 04:30 so this is the Clear Choice yeah says the architect but um but what about what sort of contract are you going to use is it going to be a strict contract with a schema or are all 45 of those attributes going to be a loose contract with just something like Json are you going to pass an object in that message um and how are you going to manage it how are you going to version it when you make changes because you don't want to break everything
• 04:30 - 05:00 oh yeah that's right yeah and what are you going to do about stamp coupling and bandwidth issues that are going to occur with this and the developer says what are you talking about stamp coupling as a form of coupling where you pass all of the information to a particular service but it only uses a few pieces of it maybe even one or two attributes that's called stamp coupling and two problems occur change and
• 05:00 - 05:30 bandwidth issues let me show you what I mean if I change this contract and change a field that payments and inventory are not using well of course I have to change but that might facilitate a change in payment and inventory as well even though I don't care about that field that's what stamp coupling is about but there's also bandwidth issues because you see that entire order is 500 KB
• 05:30 - 06:00 so 500 KB is being sent to both payment and inventory payment only needs 350 KB inventory only needs 50 KB so I'm unnecessary unnecessarily utilizing bandwidth I don't need cloud-based environments this could get quite expensive oh and there's another problem by the way
• 06:00 - 06:30 um and of course at this point the developer starts getting really frustrated but it keeps going what about multiple systems of record because if you're passing the entire payload of that message over there that means every one of you have a copy of that and you're not even looking at the database where the true system of record is so if I make changes to that order it may be everywhere you might not have the latest copy so that might produce data Integrity issues as well oh
• 06:30 - 07:00 you know so the developer says hmm you know these are really good points you know you've kind of convinced me maybe a key based event payload would be better I mean after all I wouldn't have to worry about stamp coupling it's a single name value pair so there's really no well there's still a contract but I'm never going to change that I don't have bandwidth issues I don't have stamp coupling and you're right I have a single single
• 07:00 - 07:30 system of record I get better data Integrity you know you make really good points maybe I should use the key based and what happens the developer now comes along or the architect comes along and says yeah but what are you going to do about scalability and performance now this is why thinking like an architect is important because of our first law of software architecture and that is that everything in software architecture is a trade-off
• 07:30 - 08:00 and being able to think like an architect and see things with an architect's eye allows you to better analyze these kind of trade-offs to actually make the right decision to find and seek out those pros and cons okay so let's come back to thinking like an architect what's involved in thinking like an architect being able to apply architectural thinking to your daily job
• 08:00 - 08:30 regardless of your title or role it really involves Three core things the first is regardless of your role to be able to understand the importance of those business drivers in the translation to whatever those architectural characteristics are do you need High scalability do you need High availability high performance High agility High
• 08:30 - 09:00 responsiveness what are those attributes or characteristics of the architecture that are important because we are implementing that architecture we should probably know those number two thinking like an architect is also expanding your breadth of knowledge to be able to see more solutions to the problem and also thinking like an architect is
• 09:00 - 09:30 being able to identify and analyze various trade-offs these are the three main components of actually seeing a problem with an architect's eye as opposed to a developer's eye oh you still have to see things with a developer's eye of course especially when you're faced with a particular algorithm or problem or design problem within your code but it's also seeing the problem architecturally as well let's take a look at all three of these and see how
• 09:30 - 10:00 they all work and let's take a look at what are the most foundational pieces of what it means to see things like those clouds with an architect's eye because this is what the business is concerned about regardless of the type of system that you're building the business is concerned about things like user satisfaction time to Market competitive Advantage mergers and Acquisitions Regulatory Compliance all of these things are big concerns of
• 10:00 - 10:30 theirs thinking architecturally is translating these concerns into exactly what the architecture needs to support this is our language we translate those into things like oh fault tolerance reliability recoverability responsiveness performance availability and that's what we need to build into the architecture to support those business needs
• 10:30 - 11:00 that's seeing it with the architect's eye but there's a problem here because it's a problem of being Lost in Translation you see language of an architect is talking all about fault tolerance the language of the business is talking all about user satisfaction and the problem is these two rarely meet because no one knows what anybody's talking about and this involves another aspect of
• 11:00 - 11:30 thinking architecturally that brain of an architect becomes like a translation engine so if this is that important which it is because these architectural characteristics become the foundational aspect of any system or product so if we don't know these how can we possibly build a system how can we possibly make decisions
• 11:30 - 12:00 okay so you've convinced me yeah we need to know these but how do I know which ones I mean I've never really thought about this and I'd really like to as a matter of fact on Monday when I kind of go back to work I might want to start thinking about these so where do they come from they come from one of three places a lot of times they come just from the domain I mean the business domain for example we're building a new stock trading system to buy and sell stock
• 12:00 - 12:30 well I don't need to go through a lot of analysis to know that system has to be fast high performance High data integrity so sometimes we could just extract these from the nature of our business a lot of times they're in requirements or user stories but the user story does not State we require High elasticity no the user story looks like this we have to support 20 to 200 000 concurrent users
• 12:30 - 13:00 and everything in between and it could be immediate need so those requirements or user stories are not spelling out that exact illity or architecture characteristic it's up to us to interpret and know what that is but it's interesting in almost every system or product I've worked on the most valuable place to find out what's important is actually just using your ear and listening to the
• 13:00 - 13:30 business let's actually do this this will be fun so here's an example thinking architecturally is that trans translation engine that we have in our mind so let's say that the business says oh yeah user satisfaction is absolutely the most important thing we build our company on user satisfaction so what happens we translate that to a characteristic
• 13:30 - 14:00 now this one's easy user satisfaction ability is it funny you could take any word and just add the word illity after it and all of a sudden you've got a new characteristic how about markability hmm wonder what that means well that one's easy too because I love drawing on slides I love drawing on whiteboards and so markability is the ability to like a lot of drawings there was one particular client engagement I was on where we had fun
• 14:00 - 14:30 making up architecture characteristics we would take the characteristics of somebody on the team and use their name and make an entity for example take the person on the team I mean who is the glue on the team I mean they just bring everything together so if we needed high amiability that means we need High cohesion we need this system to work together uh maybe you've got somebody um sebastiani who's maybe a a perfectionist everything has to be
• 14:30 - 15:00 absolutely perfect well that's sebastiani ability the ability to have everything absolutely the highest level of data integrity and correctness in that system it's kind of a fun exercise you should try it you can make up any word but it's not really user satisfactionability no this requirement or need comes into our translation engine and out comes all those things the architecture needs to support performance agility so that we get bug
• 15:00 - 15:30 fixes Fast Fixed fast things like scalability availability security testability so we don't introduce bugs recoverability so I don't lose my work these are all things that make users happy and if our architectures don't support these users will not be happy this is that whole thing about seeing a particular problem with an architect's perspective how about time to Market
• 15:30 - 16:00 that's the most important thing so we feed that into our little translation engine and out comes all the things that the architecture needs to support maintainability testability deployability these are things that we as not only architects but Developers need to focus on that's what we need to support let's do one more mergers and Acquisitions oh boy yes we're we're
• 16:00 - 16:30 constantly acquiring new companies okay that one's easy resume ability yes because my job will be replaced okay now like I said you can make up any word no we feed this in and what do you suppose it's interesting think about this one for a second mergers and Acquisitions undergoing very heavily in your company constantly buying up other companies merging with other companies you're an architect you're a developer what's on your mind about this let's
• 16:30 - 17:00 just Ponder this one for a little bit hmm would that matter yeah it would as a matter of fact a lot of things are we leveraging standards it's going to make it easier for us to communicate with other systems that we have to interoperability how open or closed are our systems how scalable are they because if we merge with another company we possibly have just doubled our customer base
• 17:00 - 17:30 think about that can our Systems Support that extra customer load that extra user load the capacities in our database connection pools virtual machines that's a big one on that all right so this is one of those kind of translation engines one of the reasons this is so important it's because these these characteristics when we see these help us qualify and make decisions this is the star rating
• 17:30 - 18:00 chart from our book fundamentals of software architecture and we can kind of utilize this if and only if we know our characteristics which architecture style should you use microservices of course no which of these eight should you use I I I I don't know what can I base that on oh what's important to you oh
• 18:00 - 18:30 scalability is exactly what we need we have to be highly scalable well this kind of chart using qualitative analysis allows us to kind of look for the areas that have five stars that means it's really well supported if the architecture doesn't support scalability it doesn't matter how much you do from a physical operational standpoint you won't be able to scale
• 18:30 - 19:00 so consequently we look at this chart and say huh which architectures tend to scale better than others and we find of course micro Services event driven and space-based architecture are really good choices the layered architecture with one star is not how do we know this architectural thinking being able to see a problem and this is what an architect sees I don't see class Styles I don't see
• 19:00 - 19:30 methods I don't see algorithms design patterns oh what I see floating in front of my face are all of these characteristics and those are my driving forces to make decisions now a resource that you could actually use oh and by the way yeah let's do another one let's say that's constant Simplicity we're a startup don't have a lot of money we don't want to add a lot of complexity at the very very start of our life as a
• 19:30 - 20:00 company those are our most important things we do qualitative analysis We compare the quality of one thing to another and we find hmm I'm guessing maybe we shouldn't do micro Services first maybe let's start with a monolith any one of these three and then migrate as soon as we find out if this idea is going to work and we start growing yeah these are guidelines these are guide posts so one of the tools that I could offer
• 20:00 - 20:30 you that you can use is this characteristics worksheet and this is what I use at work this is what I use on my Consulting engagements to help identify these driving forces so you can download this from my website under resources and it's in PDF PowerPoint and keynote format change it if you want to that's fine but this allows you to start looking at and by the way that there's three pages because they show definitions I show definitions
• 20:30 - 21:00 of each of these kind of core characteristics and I also have a lesson lesson 112 on my software development our software architecture Monday to show kind of how this works anyways it's a really useful tool for starting to say you know I think I'd like to start doing that I'd like to start thinking like an architect and I'm going to see if I can come up with what characteristics on the current product I'm working on are important and are we really supporting
• 21:00 - 21:30 those and do we have the right architecture in place guess what by doing those three things you know what you all are doing exactly the same thing an architect would do thinking like an architect you don't have to be an architect to think like an architect so here's the bottom line of this part one right here you cannot and this is what I maintain you cannot do this create an architecture
• 21:30 - 22:00 unless you have these otherwise how are you going to make a decision what's needed this looks like an interesting design but does it satisfy the needs of the application the domain and The Business all right that's part of thinking like an architect having those foundational aspects that drive all the rest of your decisions even at an implementation level knowing
• 22:00 - 22:30 these and knowing that scalability is that important and qualifying it will allow you to think about the designs of your code with scalability in mind as well or availability or fault tolerance okay the next part though about thinking like an architect is expanding what's known as our technical breadth the amount of things we know because as an architect you see a problem I have to see and visualize in my mind
• 22:30 - 23:00 the possible solutions but what if you only know one particular solution it might not be the right one so it turns out that this is called a triangle of knowledge and there are three types of knowledge that exist in the world let's scope it down to technology knowledge that would be a lot better um well way up here at the top is the stuff that you know these are things you do every day you know them so well that you could
• 23:00 - 23:30 actually get up on stage here and talk about them it'd be a little scary but you could but right below that is a bigger area of knowledge called the stuff that you know that you don't know this means you know or are familiar about something but you have no idea how to use it um close your programming language is a good example I'm sure most if not all of you have heard about closure it's a programming language that uh boy you
• 23:30 - 24:00 gotta love parentheses if you're going to use it it usually uses the atomic transactional memory all this kind of stuff but how many of you can code enclosure not it that's a good example of something that you've heard of that you know that you know nothing about but you're familiar with it but the biggest area of knowledge that exists is this bottom large Blue Area this is the stuff that you don't know that you don't know this is all the possible solutions tools
• 24:00 - 24:30 products patterns that would be the perfect fit perfect fit for what you're doing and you don't even know it exists so one of the well I'll call it a game of life is to take stuff that you've never ever heard of that bottom area of the triangle stuff that you don't know that you don't know and move it into the stuff that you know
• 24:30 - 25:00 you don't know how do you do this talk with people say oh I haven't heard of that before what is it and now you suddenly have it in your second level of knowledge it's going to conferences like this and challenging yourself to say well I'm a react programmer so I'm going to do all react talks now the proper way to take advantage of conferences like this is to attend a
• 25:00 - 25:30 talk of something you've never heard of it's fantastic way to learn about a possible tool a technique a solution that you may not use now but it's in your brain and you'll pull it out sometime and say wait a minute I remember I was at gids23 and I remember I was walking along in the the exposition Hall there and I was like what is this product okay that's a two or three minute conversation you have now taken something that you
• 25:30 - 26:00 didn't know that you didn't know and say oh now I know what it does okay then either something because we are all technologists that pique your interest something that you get really excited about or your boss says starting next week we shall be using closure oh that's when you take something that you know you don't know and you move it into something now that you know but there's a cautionary tale here
• 26:00 - 26:30 everybody watch out for this top part of the triangle because the stuff you know is the stuff you have to maintain and if you like working 24 hours a day if you don't have kids if you have no life and no friends don't worry about it but if you do you can't do it all because if you don't maintain that it suddenly trickles down like teardrops all the way back down
• 26:30 - 27:00 into something that now you know you don't know about 10 years ago it was mostly programming in the Scala language I started the Boston Scala users group that's all I was doing at client sites with Scala I loved it that was 10 years ago now I would be lucky to be able to start a scholar class file it's something I chose not to maintain so it dripped back down so just a cautionary tale be
• 27:00 - 27:30 careful okay well let's do an interesting exercise because of this the stuff you know is called technical depth we all need technical depth including me a seasoned architect we all need technical depth but that's stuff you know plus the stuff that you know you don't know is considered technical breadth and here's the key point
• 27:30 - 28:00 thinking like an architect starting to make more effective decisions create better software systems and start propelling your career into that Tech lead and into that architect position means to exactly Focus right here and that's hard it means focusing on technical depth with a sacrifice I'm
• 28:00 - 28:30 sorry technical breadth with a little bit of a sacrifice of technical depth start broadening your horizons okay well let's actually play this game what we're going to do is we're actually now that we understand this triangle of knowledge let's have some fun with it let's take a look at the brain of a junior developer then let's take a look inside the brain of a senior developer then we're going to take a look inside
• 28:30 - 29:00 the brain of a junior architect and finally a senior architect this is going to be an amazing journey so now that we understand that levels are trying the levels of knowledge let's open up the brain to a junior developer this is what a junior developer's knowledge triangle looks like typically notice what is the biggest part of this triangle it's the stuff that you don't know that you don't know sure I am a Java
• 29:00 - 29:30 developer what do you do Java what do you know Java okay notice my technical breadth is pretty small and that's fine that's appropriate because as a junior developer I am hired for my technical capability on that particular technology this is good this is what it should look like but what happens are you ready watch this as we move from a junior
• 29:30 - 30:00 developer to a senior developer did you notice what happened to the triangle I want to do that again because this is going to start morphing like this wait a minute let me go backwards one are you ready watch the shape of the triangle here we go Junior developer starts going into a senior developer five or six years experience and what do you notice happen the stuff you know increases multiple platforms multiple languages
• 30:00 - 30:30 multiple patterns multiple tools multiple techniques multiple Frameworks the list goes on and as a matter of fact that you notice what part of the triangle got smaller the stuff you know you didn't know that you didn't know but notice our technical breadth still not strong and that's okay because we are focused on a technology solution to a problem but you get that big break and all of a sudden now
• 30:30 - 31:00 yes your first opportunity as an architect you become a junior architect you ready I'm going to transfer now this is what your brain starts to look like did you notice what happened as you move into and step into an architect position what happened you sacrificed some of that stuff you know that expertise to broaden the stuff that you know you
• 31:00 - 31:30 don't know as an architect you're starting to look at 10 different caching Technologies not just redis for example what are the different caching tools and Technologies what do they support what are the pros what are the cons oh I may not know how to code at any of these that's fine but as an architect I know the trade-offs of each of these hey which one would probably be the most appropriate solution for our particular problem
• 31:30 - 32:00 now final Journey you start developing your careers in architect you start getting that senior architect kind of position that Enterprise architect and this is what your knowledge triangle now starts to look like notice we haven't done much with our technical depth but we've significantly broadened the stuff that we know we don't know so this is kind of one of those key tips tricks to managing
• 32:00 - 32:30 your entire career regardless of where you are in it did you just graduate from school cool focus on the technology that you're interested in that's all you should do and you could use this transition to kind of map out where you should probably be in these various knowledge pieces well Mark this is absolutely fabulous this is really cool
• 32:30 - 33:00 I wish I had as much time as you to be able to go research and do stuff and kind of learn things I don't know ah yeah no I'm stuck 12 hours a day coding Java ah let me show you how to do this so isn't it interesting if we look at the difference between a developer's head and the way they see things and an architect's head and the way they see things it's all about that middle area the more you know
• 33:00 - 33:30 about stuff you don't know the more you're going to be able to find solutions to problems that are the most appropriate solution okay so how do you do this how do you start gaining that technical depth this is exciting well what are the ways to do it is a conferences like this or just start going to some of these resources that are free
• 33:30 - 34:00 and let me show you three that I typically use the first one I go to quite often is a info queue infoq.com uh now I'm going to show you this in a little bit but every uh about two times a week I get an email with all these different things that are trending all these different Technologies um it's a really really good go-to place for architecture for all these kind of things technology you name it uh the second
• 34:00 - 34:30 place that I sometimes go to are the d-zone ref cards now not necessarily d-zone um in my experience d-zone is kind of Hit or Miss but the ref cards are really useful because I don't have a lot of time when I was in college back in the turn of the century uh I did not have time to read War and Peace or Homer's Iliad or Odyssey I had other things to do hang out with my friends just go hiking around and stuff
• 34:30 - 35:00 so what did I do I leveraged something called Cliff Notes now here's Monarch notes but these were little booklets that just gave you a summary the highlights of those epic novels yeah I could I could read that in an afternoon and so so that's what I did most of the time now I'm going back and reading all those wonderful epic novels but at the time I wasn't interested
• 35:00 - 35:30 and so those little tiny booklets Cliff Notes Monarch notes really helped me to participate in the class to really gain the understanding of those books without having all the details that I didn't really care about oh what did I just describe ref cards yeah these are two to six page cards that talk about a particular technology just the right exact level for me as an architect
• 35:30 - 36:00 say what is it why is it here what are the good things and what are the bad things about it yeah so those are those are pretty useful to gain that technical knowledge without having to go too deep oh you can study what hazelcast is all about you don't have to go and code it you can understand uh different languages you don't have to go and code them you just have to understand what they do why they're there how do they differentiate themselves from all the other 25 programming languages I could choose right now yeah another place to
• 36:00 - 36:30 go is a thoughtworks technology radar which by the way just came out Tuesday this comes out twice a year all these are free this whole stuff is all available to you and the thoughtworks technology radar twice a year are most of the luminaries in the field Neil Ford is one of those James Lewis Martin Fowler I mean these are folks who have a pulse on the industry they show you what things are trending what things aren't
• 36:30 - 37:00 it's a really great resource now here's a little test for all of you go to the thoughtworks radar you think oh I I don't need that I already know what's happening in the field I already know everything I know everything I will guarantee you they'll show 20 things that are trending in the industry I will guarantee you maybe you've heard of four of those yeah what a humbling experience it's
• 37:00 - 37:30 like this is something they're saying to adopt and I've never heard of it what is that that's something that I don't know that I don't know I probably should know it not be an expert but just know it these are three really good resources oh there's a lot of other good resources to use as well but these are just three I can offer up to you now I can go back and say huh what do these look like well let me show you the three levels of knowledge now this might be a little hard to see on the screen here but this is uh I'm going
• 37:30 - 38:00 to zoom in but this is a snapshot of my email and this is let me Zoom it in just a little bit um this is what it looks like so when I get my email it has a black a dark header line with a laundry list of buzzwords and I look at that I take a look at that and all of a sudden I start to see things like oh plastic arm what is that plastic arm is it like an actual arm it's plastic
• 38:00 - 38:30 I've never heard of that before ha something that you don't know that you don't know bottom level of the triangle it happens to be fabric based microchips for all sorts of haptic sets and all this really cool stuff okay how about this um solid.js well we can ignore that right because every day another new JavaScript framework comes out so just forget that yeah yeah never mind yeah so that that's that's Way Beyond all three
• 38:30 - 39:00 levels of knowledge that's stuff that you could throw away okay that's the trash can okay but all this other stuff Apache Pinot what does that mean the Apache Foundation is now making wine Apache Chardonnay is really good but Apache Sauvignon is also buried yeah what in the world's Pino it's there um stuff like this you know uh AWS proton oh yeah we're we're an AWS shop what's proton I I I I don't know should we be using it I don't know these are things you've
• 39:00 - 39:30 never heard of this is the value of these resources you see a buzzword that you've never heard of before spend a couple of minutes to see what it is that's all you need to do and now all of a sudden you say proton where were you six months ago oh it's been out longer than that where was I six months ago if they would have solved all our problems we could have shaved five months off our project that's the value
• 39:30 - 40:00 of architectural thinking of expanding that breadth of knowledge mark this is really cool but I don't have time for this I wish I had as much time as you to kind of just click on these and peruse these and all this well let me give you a little secret I don't either I work between 12 and 15 hours a day seven days a week
• 40:00 - 40:30 I don't have time for this so here's my technique I kind of created something called what well at least what I call the 20 minute rule and here's what I do I spend 20 minutes a day just 20 sometimes more but at least 20 minutes a day on me on my career on myself to expand my technical breadth
• 40:30 - 41:00 oh I may go to info queue I may just create a list of words I've never heard of and that's going to queue up for tomorrow which I may look at two or three of those now here's the other secret though when do you do this oh launch that'd be a good time yeah how many of us get to take lunch seriously no yeah after after work this would be a good time to do it uh-huh yeah how many of you have families
• 41:00 - 41:30 yeah you get home after a hard day and your spouse goes here I'm going out and you look at your child and go what did you do today yeah you're not going to spend 20 minutes learning about proton no here's the trick first thing in the morning now let me qualify that what's the very very first thing you do when you wake up in the morning and but by the way I'll answer that first you
• 41:30 - 42:00 get that blessed cup of coffee or tea yes okay what's the very very very next thing you do when you sit down at work whether it be at your home office or whatever email check email and your day is over you start getting involved it's like oh it's like oh no I've got a meeting in 10 minutes oh we've got a production outage right there oh yeah never okay so my day looks like this I get that
• 42:00 - 42:30 blessed cup of coffee or tea and then I spend 20 minutes enjoying that nice hot beverage well I work on me my career my architectural thinking my technical breath if I could spend 30 awesome but 20 is good most articles are designed for seven or ten minutes my videos of software architecture Monday on purpose are 10 minutes so you can do other things
• 42:30 - 43:00 during the 20-minute rule as well try it out try it out because if you can't spend 20 minutes in the morning on yourself then there's other problems that we need to discuss I'll be in the speaker's Lounge after the thing well there's one other aspect so give it a try give it a try download that architecture characteristics worksheet give it a try just see if you can start
• 43:00 - 43:30 to think about what are the characteristics that's architectural thinking um expand your technical breath these are easy things that are free okay there's one more element that we can talk about and that's analyzing trade-offs this is another thing of thinking like an architect I need to channel my friend Rich hickey who created closure and here's a quote that's quite controversial but it's quite funny and sometimes sometimes quite true and he
• 43:30 - 44:00 says this developers know the benefits of everything and the trade-offs of nothing and I've seen it I mean it's not always true I have worked with development teams and developers who do know about trade-offs but a lot of us get excited about a particular technology a framework a tool a language and we only see the good stuff we don't see the bad stuff yeah so let's see about analyzing
• 44:00 - 44:30 trade-offs because this is another way of thinking like an architect okay so here's our first law again and we keep bringing this up because it's so important everything in software architecture is a trade-off and the structural aspect of software architecture and the structural aspect of Building Systems there are no best practices how can you possibly say you should all focus on performance
• 44:30 - 45:00 oh we don't care about performance no that's not a best practice you should always use microservices yeah we're a small startup shop I mean challenge yourself Neil and I have that's how we came up with the law yeah now I qualified it to say the structural aspect because there are some best practices in architecture one of them always collaborate with your development team and stakeholders yeah if you don't it'll fail yeah that's a best practice but it's the
• 45:00 - 45:30 process part of architecture I use architecture decision records to justify my architecture decisions that's a best practice but within a structural aspect no there's none so follow-up question in our second book architecture the hard parts and that is okay then so what happens when there are no best practices this everybody is why architecture is hard
• 45:30 - 46:00 it's because we don't have that many guideposts because it's all 100 contextual so how do we make decisions this is one of the things an architect does this is architectural thinking analyzing trade-offs well not surprisingly how did them do we make a decision A or B uh I guess we could flip a coin no I have a better idea understand the business drivers first
• 46:00 - 46:30 what's important to the business and they say time to market the most important thing we've got a lot of important things but that one's way up at the ceiling all right all right so we understand that do you remember the first section what do we do with that information yeah exactly doesn't matter if you're not an architect you say huh so they need speed to Market well I wonder what that means that kind of translates to architectural characteristics about maintainability
• 46:30 - 47:00 testability the ease of incompleteness of testing and also deployability the ceremony of deploying our software the frequency and the overall risk it's all three of these that give us time to Market oh it doesn't matter how fast you can find the change and make it as a developer if it takes you six weeks to test good luck if you're wondering by the way um if you don't believe me about these three what is the fastest possible way
• 47:00 - 47:30 in the world to get your changes released to your customers fastest way in the world don't test make the change release make the change release make change release yeah is that time to Market no that's killing your company yes so the point is it's all three of these we need that ease of and completeness of testing because as we
• 47:30 - 48:00 move faster we want to make sure we're not introducing more and more and more and more bugs into the system we will lose it doesn't matter how fast we can be it's all three of these we take this information and then we do this huh I have a decision to make what do I do I look at the pros and cons and I try to boil them down and simplify them and this is what it ends up to be performance versus maintainability
• 48:00 - 48:30 that's what it boils down to single service three services single Services faster three services this is gives us better maintainability pick one it's almost like cap theorem we can't really do both of these well how do we make a choice obviously performance oh I better not get on that soapbox thank God pre-optimization of performance could even be a keynote oh boy yeah because think about it as a developer we want things to be fast that's what our primary focus is on our
• 48:30 - 49:00 mind that's seeing things with a developer's eye a developer's perspective we want fast code seeing things with an architect's eye says yeah we got to make our code fast but hold on a second what's most important to the business well if we can tie them back to the architecture characteristics we see that maintainability is actually on that list and if we tie it back to the business need we see that time to Market would be
• 49:00 - 49:30 much better if I can make maintainable code in other words break apart my services and so do you see by going backwards now I can actually make a decision and say that's why we're going to break apart our services it's going to be slower but time to Market is more important to the business that's what the architecture has to support that is modern trade-off analysis this is now seeing decisions
• 49:30 - 50:00 that you need to make with an architect's eye and architect's point of view okay well let's try this out let's actually show I want to show you a couple of tips the first pro tip is this watch out for something called the out of context trap as a matter of fact this is out of context anti-pattern when we're starting to analyze trade-offs let me show you what I mean so I'm wondering of a query I can't decide
• 50:00 - 50:30 whether I should use a shared library or a shared service for all my shared functionality this is a developer decision something a developer is probably going to make where do I put all of those calculators that are shared all of my utilities my utility.cs my utility.java my utility.py what do I do with all that code hmm well I don't know oh wait a minute I just attended gids23 and I attended this
• 50:30 - 51:00 keynote about analyzing trade-offs that would be a good start so let's actually do this so what I'm going to do is create a scorecard and I'm going to start looking at the pros and cons of each of these so heterogeneous code that's the first one which works better well heterogeneous code does not work well with shared libraries because if I've got five platforms I've got five copies of that shared Library five copies of the code
• 51:00 - 51:30 but with a shared service doesn't matter if you're even in a Mainframe call me it's in one place oh score one for shared service ah but what about high code volatility our code changes all the time well in a shared Library what's going to happen I'm going to continue to version until I reach that Max version number that's supported and all of you even if you're not using the utility are going to have to retest and redeploy and rebuild
• 51:30 - 52:00 every single week that's a lot of churn oh that's not going to work but what happens with a shared service that code changes all the time yeah it just changed the podium yeah I just changed the podium yeah you guys all just use it okay what about the ability to version things though shared library now has a check mark this gets a plus one yeah it's hard diversion runtime changes
• 52:00 - 52:30 but I converge in a dll or a jar file or a gem that's not hard actually it is fallacy number nine of distributed computing what about overall change risk yeah if I make a change to that Podium that's our shared service right there and I really messed something up I've just now broken every single one of you because it's hard to version that's a runtime change in production once I deploy that service all of a sudden boom
• 52:30 - 53:00 boom boom boom everybody's like hey why are you all leaving the uh tutorium uh oh because that change made the speaker go away and uh and also you can't hear me is or the microphone and so it's a lot more risk But Eric but with shared libraries I have backwards compatibility I have agility then cat needs a change immediately okay then cut type type type here you go version 2.3.4 done I gave that to him just now
• 53:00 - 53:30 the rest of you YouTube 2.4.2 backwards compatibility and Agility because now we have to start now all changing at some point but what about the operational characteristics things like performance things like fault tolerance scalability these are all bad in a shared service at this Podium fell to the ground no longer available neither are any of you yeah all of a sudden if all of you and I
• 53:30 - 54:00 think I did this yesterday on stage here all of a sudden ask me a question all at once I'm going to get overwhelmed and just curl up on the stage and to a ball and start crying um yeah these are the problems it's going to be slow to go all the way from the front there especially with all these Pathways to ask me a question if you want to ask me a question to communicate with me you have to actually come onto the stage and shake my hand that's going to take forever not with a shared Library
• 54:00 - 54:30 do you see a clear winner here yeah count up the check marks and we find this is why using a shared library is a best practice hopefully now you know I'm teasing because there is no such thing as a best practice this everyone is an anti-pattern avoid it like the plague this is called the out of context trap what's my
• 54:30 - 55:00 context me Mark Richards personally this is my context well we have Services written in four different languages so we're using polyglot programming and we're not really concerned about performance or scalability no our biggest issue and our product right now is managing changes to Shared functionality that occur frequently that's my problem oh what happens if we go back to the scorecard
• 55:00 - 55:30 that's plus two to zero yeah that's how we make the choice we apply the context and now a shared service is better even though it has more X's I don't care about those X's now a lot of you probably use scorecards and you do waiting so you say well this one's weighted higher than this one well go ahead and do that but if you don't care about it wait it at zero and then count it up because it has no
• 55:30 - 56:00 bearing for our context so that watch out for this kind of of of problem okay here's another Pro tip but this one's hard try to avoid not try to avoid there is no try it's do or not do avoid over evangelizing any particular technology framework solution something you found we get all excited about something oh I
• 56:00 - 56:30 found I found grpc Google's remote procedure call it's the best thing I've ever seen I could get 10 times more than 10 times better performance in our system our system's too slow I found the solution grpc oh 10 times performance increase it is it's wonderful it's exciting it's great try to avoid that why because of the first law of software architecture everything in software
• 56:30 - 57:00 architecture is a trade-off and the problem is you all get very excited about it and what have I just done by evangelizing I have just hidden all of the trade-offs and they're there no one's finds them no one sees them no one knows they're there because we're all excited because I evangelized something I got excited about it I made you excited about it this is a very dangerous thing you know
• 57:00 - 57:30 why architects are always grumpy they always have a frown they're always walking around like this because we can't get excited about anything because everything has a trade-off it's a very depressing place to be yes oh all right um so that everyone is architectural thinking that's seeing things with an architect's eye an architect's point of
• 57:30 - 58:00 view which will help you start accelerating your career into kind of that architect position because you're already acting the role you're already doing it get the practice now before all of a sudden you get handed the golden keys of architecture and say I'm not sure what I'm supposed to be doing here and now I'm way over my head practice it now but even if that's not your career aspiration
• 58:00 - 58:30 maybe you want to know what we stay a developer that's cool too but now using this stuff you can create more effective and more efficient and more correct software Solutions as a developer all right wonderful well thank you all so much thank you [Music]