"Good Enough" Architecture • Stefan Tilkov • GOTO 2019

[Music] so welcome everyone to what's probably going to be the most depressing session of his conference I thought it might make sense for us to get this over with quickly so let's get this up front most of the architectures I'll be talking about aren't good enough I tried my best to find some there were but I ended up finding so many that I found interesting that really have some problems some challenges some issues so to protect the innocent none of this of course applies to any of you right none of you have done ever done anything similar to any of the catastrophes that I'll be talking about and also try to end on a positive note with a few positive things so the thing I want to talk about is situations where architecture either was too sophisticated or not sophisticated enough where it missed hitting the sweet spot now architecture is to some people's through a little bit of an insult right if you label somebody that he's just an eye or their know mostly heat sadly he's just an architect that's like saying well he doesn't really know what he's talking about and he just you know creates big pictures that sit on some wall and only they themselves ever look at nobody else because nobody cares about what they do I don't subscribe to that view of architecture does anybody else at this room self-identify as an architect does anybody do that oh oh very slowly raising a hand okay so these days is very popular to view architecture as sort of something that everybody does and I completely agree with that and we'll get to that point the number of times during the presentation that because I wanted to start with this I have a little bit of formal stuff at the beginning which is actually actual definitions right so you can go from very very formal to kind of loose and I want to want to start with that so if you look at a very formal definition of what architecture is and actually found the ISO standard that defines this it's the elements that your system is composed of and their relationship the environment they sit in and the rules and principles of their design and evolution right that's like a very formal kind of thing but it seems intuitively to sort of make sense right it's the important stuff within yours them the important elements that are connected in some way and somehow that seems to matter a lot to a lot of people who take a look at your system and you have to use or evolve your system I also like this definition a lot by a gentleman named Grady Booch which simply says it's whatever hurts if you get it wrong all right so the the amount decisions that you better get right which does not mean that you can't change your mind about architectural things it's just much harder to change your mind about something that's part of your architecture as opposed to something that's just an implementation detail right mostly though I find that architecture is basically this right it's whatever it's whatever that person or the people who are involved with who label themselves architects consider important enough to merit their attention and that can be lots of things that shouldn't really be architectural issues like really small simply very simple or very many details about something that they that really doesn't matter that should be left to the developer in who actually does the actual work to decide as opposed to somebody who makes a big decision about this thing and in the same vein you have a lot of situations where very important things that are not being considered by anybody who does this from an architecture perspective again that doesn't have to be a person whose label an architect it can be just somebody this person today and that person tomorrow but somebody will make those decisions it's probably a good idea to to make them consciously now let me get this out of the way as well because some people still think this is the case I definitely do not think that architecture is just an it's a big design up front activity that you have to do at the beginning and then you're done right this is this is something that I don't think was ever true but these days you get you can get them you can do a majority vote and 95% the people will agree even architects even those who have architect on their business card will agree that this is the case right it's not enough from activity and a second a second statement in that in that line of thought is that architecture is not a description right architecture is the actual it is your system your system has an architect sure doesn't matter whether you want it or not it just has an architecture it may be intentional or maybe accidental but it definitely has an architecture so it's a property of the system now what's a good architecture that's a very stupid question which is sort of the idea with a title right to get you a little bit pissed off at me to start things off on a good any good way so this question what does a good architecture is similar to asking what's a good car right I mean I really don't know I mean you can it's a matter of taste from probably as well but it's also a matter of what you're going to do with that car right what is it what's the purpose that you're that you're looking for and you'll have to pick something that matches your situation and again very formally there's a quality model in some other ISO standard gives you a bunch of things that you have to think about if you look at a system and if you if you want to assess any architecture if you want to look at any architectural quality you always have to take the architecture in in relation to the actual quality aspects that you care about right you might care about performance more than about security or the other way around you might place a very high value on usability but not so much on maintainability or whatever it is you have to figure out what that is and you can see that in many cases and you can also see that people even though this is a very obvious kind of thing right this is not rocket science right this should be completely obvious people miss that all the time I use this slide a lot when I talk about scaling if you look at scaling dimensions you can you can view different axes here right you can talk about logic the complexity of the system from it from a business domain perspective and you can talk about the low the number of users that this system will have to endure right so if you look at something like this the scale for load goes from something that serves a dozen users to something that has to scale to half the planet right if you're building something like Facebook then you have completely different needs then if you build something internally and the logic goes from something that you can write an array need on a rainy Sunday afternoon to something that incorporates some aspect of German tax law so it's really a broad range that you have here right you can pick a random CMS maybe that's the easiest thing right it's very easy you could write one yourself you can use one for simple tasks and then you can sort of try to put things somewhere or not we can argue what belongs we're here I would say that Twitter is not that complex logic wise you might disagree but I think it's it doesn't do very fancy many fancy things right it just scales a lot Facebook is more I think sadly Amazon I think doesn't have the scale of Facebook but a very very high scale and a lot more complexity and then you have like whatever your typical insurance policy management system that's just a help to implement but not doesn't have to scale this so there's no good of it architecture without looking at quality attributes so with that prologue out of the way I want to look at some concrete cases threats at some examples we can see some things that went wrong when people try to apply those and the rough structure I use is that look at the context of something and I have some observations and possibly some lessons learned hopefully at least so let's look at the first one this is I've labeled this non extensible extensibility and that was really sort of an a very interesting moment for me because I noticed it's for the first time whenever going to review this particular project have small team that did that and we took a look at this particular company and they're in their systems and noticed a pattern that reappeared again and again in number situations and it went like this so the context is a global e-commerce company right a digital service provider of some kind doesn't really matter what they do but the the key thing here is the global and global customer base and their clients actually use the platform to serve their clients like a something like Shopify but it's not Shopify it's much older than that it provides a lots of a lot of features to their clients that they can use to serve their own so it's multi-tenant of course and what key aspect was that it was highly customizable that was sort of the the key idea it's so super customizable that anybody can use it to incorporate their own special needs right so you have different kinds of needs you have something from very general to very specific and you have low complexity to high complexity and you have your very or it's actually a cost in in building that related to the complexity and you have an um of different clients like you have this super strategic large customer who really want extremely specific stuff there exist they're perfectly willing to pay a ton of money but they have very very specific needs and then you have very simple clients small customers to sort of long tail customers they basically want to change the color of the login screen or maybe upload upload their logo or something right they don't have fancy needs they also are not willing to invest about the money because they don't have much money now if you look at those typical kinds of clients basically all of the clients that they had could be put in those two buckets they either were very strategic large clients with very specific needs and a lot of money or there were small customers that were in the long tail and they actually build a system that was perfect for this which is a very very sad situation that the solution was customizable it actually had its own IDE based on Eclipse right so you had to download a 150 megabytes of IDE which was a lot back then to get started and you had to learn this very specific environment to to customize the solution and then we were unhappy either because it was way too complex or because he couldn't do what he wanted to do so that was not a good solution what we actually ended up recommending what I think they implemented I'm not 100% sure is that they actually built something very specific for the very specific clients out there because they pay so much money anyway it doesn't really matter you can build an actual program surprised as opposed as opposed to configuring something you just build a program that will match their actual needs which turned out to be a much better solution for this if you attempt a design and satisfy everyone you'll end up satisfying no one that's exactly what happened to them right it matched no ones need and high the specific stuff is often much preferable to those super configurable solutions that you have somewhere my next example is what I like to call perilously fine grain it was it's a it's something that you can currently observe in a lot of systems not pointing fingers here but you know you are so there's a there's this this particular context was a large company very large multinational company building a huge huge system basically company-wide replacing many existing systems many commercial off-the-shelf systems with with newly built software but our developers I think it went up to more than 300 at some point in time developed developing in multiple teams of course now when the system started out when the when the when they started out building that particular system there was just one company and one essentially one team it had like 20 to 30 people but it was still one team and I one team had their lead architect go to a conference that pitched micro-services which was a sad thing for this particular project so what the what the architect decided to do was of course to separate everything into tiny little services services that was so small that they typically could be owned by a single person right so there were roughly maybe 3040 services for the 30 people in the team so everyone could build their own thing which felt good for the developers for a while now the problem was at some money time this had to scale they had to bring in more developers so what they ended up doing was they had these multiple teams that had access to a bunch of those services but of course as soon as they brought in more teams they found out that these things actually overlapped right you actually ended up if you wanted to build anything useful competing about who got access to that particular micro service so the initial assumption that one person could be we could be responsible simply didn't hold anymore because of the team structure of the organization essentially ruined the initial architecture which wasn't that great to begin with but became much worse once they added more people to the whole thing and one particular thing is so generic that I can now use this slide everywhere and claim it's a pattern which is this particular thing it's the entity service Panda pattern I think some of you have seen this actually I can leave it like this because it's always the order service right in any any system that has any sort of Commerce right so you have this order service thing which sounds like a good idea because it's kind of obvious like it's an order right so you've built something that manages orders the problem with that is that you'll have a bunch of other services that will depend on this particular thing so you'll end up having to manage those dependencies which is essentially another word for architecture work you'll have to manage those dependencies all the time and the problem is that this particular order service isn't a generic thing it actually has aspects of all of those things so it does many things for many different people there are aspects in an order that are related to fulfillment and aspects in order that related to support or to building or to whatever and if you aggregate all of them in this particular little entity thing then you'll end up doing something that'll hurt you a lot that's it now it's I think that it's now becoming known as a common honey pattern so if you find yourself building that then maybe reflect on whether you're doing something good now why does that happen what's the reason people end up building those super fine-grain things anybody get a good guess what's what's the main reason whose fault is it sorry oh no does this help so I I totally admire this company right I'm a big fan of Netflix I really am I use their services all the time I like them their architecture is really impressive specifically in terms of operations and you know their usage of the cloud their uses of AWS it's absolutely fascinating but almost nobody is Netflix yet almost everybody copies their architecture which is just a stupid idea unless you're building a scalable video platform through for a few hundred million users running in a in a hundred fifty kind of countries then maybe you shouldn't be using the exact architecture that they have because it's probably not gonna be a good match many companies end up with something like this right you have these you have this this bunch of services and then you have a monolithic application fronting on top of that that's actually what happened in this particular project so what we actually ended up doing or what that not only we did the other teams as well so we sweep staffed a number of teams and other companies start other teams what we ended up doing is we we took this thing and we actually modularize it in the large and separate it into multiple instances that that's not great I would like something else much better but this was actually an improvement because now each of the teams owned their own little mess and could start improving upon it but they didn't have those cross connections between teams when somebody had to access a service owned by somebody else right so this turned out to be more reasonably implemented like this which meant that this could go so you refactor from the enemy's service pattern to something that actually makes the the entities part of the of the teams and structures and architectural units that actually should own them right so as every time you violate that rule you end up with a mess so lessons small is not always beautiful refactoring within team boundaries became much easier right once they had this thing they could they had had a reasonably you know maneuverable thing again they had this little team that could actually do something on its own or each of those teams could do something on its own and actually move the whole thing forward and you can't ignore organizational parameters because that'll always hurt you no matter what you do if you can't fix them if you can't change them then you have to adhere to the existing organization and try to make things work okay my next case it's actually another old one but I loved it so much I still have to have to talk to you about it I called your system will be dynamic because that's what happened here this was an insurance company a big system actually a life insurance doesn't really matter life insurance system it used something called model driven development those of you old enough to remember what that was right we used to generate a lot of code from models they still do to this day they're more than 100 developers and that's because they don't actively develop a system anymore anymore they just maintain it so it takes a hundred people to maintain the whole thing which is completely normal in the insurance industry they managed to releases per year so very modern very agile now something that they have and have had for a long time is this development process that actually lays out how this how this year is structured right you have all of those things that are going to happen at some point in time and you can see that little thing here called modeling that's actually a two week slot once per half-year right so every six months you have a two week slot where you can actually model something that's because the model is maintained in a case tool again the only ones that you will remain rational ROS does anyone remember it's been retired like 20 years ago it's still very actively news with them maintaining its own little VM of some Windows version that still runs it so they have this modeling thing and that's basically the only chance you have to to make actual changes right because everything's generated have all the data model stuff all the connecting code that net that serializes objects through the network so they have to do that in the in those two weeks now what happens if you miss that slot right well you have to wait for at least six months if you're lucky right so if there's an important change that some business person wants the developer will have to tell them oh I can't do it and then she'll have to find another way to do it so what could we do well we have this model right I mean this is a big model this is not as simple as my name oak has like maybe a thousand tables and each of those tables has a really a ton of attributes now we don't really need all of those attributes do we so if we have a requirement for something new then maybe we can take a look at something that we don't need anymore and just change its meaning and then we'll simply maintain a list of actual meetings of things right so the column that's called tax code now actually means the region code until we change it and fix it with the next that's just complete utter madness I'm sure everybody will agree right but it's the only way they could get this thing to work because it doesn't offer any sort of generic facility anything that allows you to make those kinds of changes independently from the modeling phase so they had to find a way to do that and this of course was a complete nightmare right was an actual practice because you had to maintain this was an excel file maintained by the person doing the modeling right so don't do that my advice is don't don't copy this particular architecture centralized responsibility hurts they have this tent relized person who did the who did the modeling and that was the only chance to get it and it was in the process not in the runtime but it hurts you just as well right and you will always see people finding away it on just if the finding a way around rules that are too rigid I've seen this numerous times like when is when it's too complicated to add a new method right if a new method has to be approved or you know typically not a method but let's say a remote a remote call option right like a like a service or a service operation within some web service if that has to be approved by somebody pretty soon somebody will introduce a execute method right that'll petal be passed what actually supposed to be done as a parameter to that methods you always find you have always had been genius developers who will find a way to get around those things and one thing that really annoyed me a lot of this particular project was that everybody said or seemed to think this was completely okay right because they were so used to it well no just because you're used to it doesn't make it suck less right it's still a very very bad idea so again possibly don't do that and well read it in the same vein I have this one called freestyle architecture and that is actually from the opposite end it's a very very new project very recent project where people wanted to do everything in the right way and ended up doing things that hurt them a lot even though they were well intended so this was a very big online shop very large European retailer they build everything new from scratch again very big one hundred hundred twenty developers and they had what they called self-contained teams that's something I like a lot the whole idea is that you have teams that are autonomous that can act on their little self-contained that actually maintain systems now you might have seen me present a slide like this a few times I need needed for context so I actually believe and we actually believe that if you have if you if you increase the number of developers which is something that you should avoid whenever you can but if you have to increase the number of developers then the method that you can use to get to the desired kind of decoupling changes right you've start with something that's built by a single person then you don't need anything more than methods of procedures and then you maybe go to some kind of module system and then you maybe go to some kind of component model but that's something you believe in and then maybe you go to something like micro services right is the number of people increase you need a better method to decouple things the stronger boundary between those decouple modules and I strongly believe that at the end at some at some level you need different systems right such such a sort of a logical conclusion of this idea right you'll end up with separate systems built by separate teams because that's the strongest kind of isolation you can give them they will communicate and the same way that you would have an externally bought commercial off-the-shelf software communicate with something you build yourself so the idea here is that you go from something that that everybody can draw right this kind of you know this draw me as a diagram of your architecture and somebody draws this right it's always the same diagram everybody can reuse this in every rocket and every project there ever a tasked with doing architecture instead of this and then adding the modules on top of that we essentially move to a system of systems where each of those systems might have some sort of layered architecture internally might be a different one in next system whatever it doesn't really matter it's sort of a different a different view of the whole thing right it's building systems or making the doing system design first and then looking at the individual systems and these this particular project team did a great great job of that I think they they were really awesome and they were really happy and they actually have success stories about the whole thing and I would typically tell you where you can find out more about them but I'm going to talk badly about some of the stuff they did so I won't so um the idea here at the end is instead of that monolithic thing that I showed you before you want to end up with something like this right instead of having the monolithic thing having to integrate UI views over multiple services you end up with something where each of those vertical slices owns its own UI right each of the teams can build something end-to-end and they can deploy something into production on their own that's what people call self-contained systems and the idea of such autonomous teams I think is a very good one and that particular project well at least they claimed they couldn't have delivered the project at all if they have you followed this approach because they would have never been able to get up to speed but there are some things that really really really hurt them the first one was that they didn't bother to standardize practically anything they sort of exaggerated the autonomy aspect of the whole thing so the integration of the user interface aspects from multiple teams was pretty much pretty much ad hoc and it sucked it didn't perform well at runtime and it was held to maintain so it really really hurt them a lot that they didn't have any sort of standard that that that somebody would have had to think about up front right which was completely contrary to Ed to all of their views they had the same thing on the middle layer like vast difference is an API is style API design things like you know different formats for for exchanging similar kind of information not talking about the canonical data model kind of madness not at all Seamus you know there's not much point in using let's say collection plus Jason and hell and siren because you don't get any additional value from using everything that's out there right it makes a little sense to limit that a bit and they also ended up because they didn't have enough front end people with a centralized front end team and if you have a centralized front end team there will be a bottleneck in your runtime or development architecture you can't avoid that it's again the connection between organization architecture you'll end up with some people who are responsible for centralized aspects of your architecture in this particular system it happens so that Thea that was a small team that was the only team that knew how to efficiently build web view eyes in terms of you know front-end performance optimization like you know bundling things and minimizing and and compressing stuff so that you can deliver something that's that's minimal so that the end user experience is good which is a very very valid goal they only have the centralized team we could do that who entered up introduced a centralized tool chain for doing that and lock down the whole project every time they made an update of saqqaq so the fact that they didn't decide on some architecture did not mean that they just had that they just avoided the word it just meant that they ended up with an architecture they didn't want so if you if you know this completely then you'll end up with something like this right they they invested quite a bit into into an architectural frame with a framework but an architectural set of rules called macro architecture which is a very reasonable thing to do but they didn't invest enough and you'll have to do that too to achieve this I actually think there is a number there are a number of things related to this to this one is that there is a fine line between diversity that adds value and chaos right so having diversity in terms of the team's being able to do different things I think is a value if they have if you have the maturity then that's that's awesome because a team can pick a best to breathe solution for its own needs and another team can innovate and try out something new and then maybe tell the other teams about it and they can copy it if it's cool right so it's good to have innovation independence and great that not everybody has to do the exact same thing but you might end up with something where that doesn't add value leave the format the example was one another thing that I strongly believe is that if you want this extremely loose coupling between things then you need extremely strict rules which sounds a little stupid but it's the rules that enforce the loose coupling that I'm talking about right you want to be able to to rely on the fact that those things will never let's say have a direct database connection or we'll never make direct method calls from one from one piece of code to the other or they will not incorporate the same version of the same library or something like that right those are all rules that you need to write down somewhere because otherwise it's gonna hurt you a lot and I think that's sort of a quid pro quo deal here you can talk to you two two people can talk to each other and the people who had tasked with maintaining the rules whether you call them architect or Lee developers or something else or whether it's just a you know a bunch of the most experienced developers from all the teams whoever does that can make a deal with the rest and say well we'll own it we will only have very very few rules but we will maintain them very strictly and in return you can do whatever you like as long as you don't violate them we don't we will not tell you how to format your code or which library to use or what exact framework or whatever it is you want to do which many people still do as part of architecture work which I'm completely opposed to so my next to last one cancer is growth I found this in a recent project and I think it shows that if you if you are successful you are at risk now this is a very successful company I'm talking about say a financial service provider that has brokers at its clients so it's sort of a longtail market very interesting company provides great service to its users small has like about 30 developers and they really they really were able to build this because they knew the business domain right they were really good at the business logic aspect of the whole thing they didn't really care about other things and they have a lot of history so it's a it's a very successful company with a lot of history and back then 20 years ago it might have been 25 they started out with something that again few people will remember something called Oracle forms if you don't know what that is that's very good for you so there are many up no I'm actually I'm only talking that was actually a very reasonable solution number of 4gl tools so that was just one of them I allowed normal people to build software which is kind of cool now what happened was that they that they found out at some point in time that this might not be the solution for the next century because even though Oracle still maintains this maintain support for the thing they still don't want to do that anymore so they added and moved to a Java JavaScript web app and maintained the business logic within the Oracle DB right that's know again that's not in itself bad I mean a bit maybe but you can't build a maintainable system with those kinds of things but typically you don't now they had this on top and they thought this was this was interesting but not not interesting enough so they added a number of web services back when you when you liked web services and they built them in c-sharp because why not right so they added a bit to the mix I had now Java based prominent dotnet is or C sharp is the as a web service implementation language and that was sort of okay for a number of years and then they bought another company that other company had a completely different IT and they thought about adopting that but they decided not to they decided to move the other company onto their existing system okay why not they also found out that they couldn't because it was different so of course they copied the system and now had two of right and so they maintained the differences in the code so any change it to be done twice but that was okay because they had the brilliant idea to centralize the database right so they they decided to make the data model the superset of all the things in both companies and then have the code sit on top of that whole thing um now that became a really really interesting challenge and you can keep it whole number developers busy without adding any business value just by maintaining that particular thing now over the course of the next two years this thing grew as as you may have noticed people sort of like adding tools so they added a number databases I only could fit five in here with that size so it's actually eight I think so if there's a database they have it somewhere and they typically have it twice or once with the merged data model from both companies and one of my favorite stories is I couldn't fit that anywhere so I put it up there they have this little C++ encryption that because they decided it's a great idea to implement their own encryption algorithm so they took a standard they didn't invent a new algorithm they just implement an existing algorithm this is which is an idea that's almost as bad as building your own algorithm so the implementers algorithm and of course they made an error implementing it and when they found the error they already had encrypted a lot of data so they now can't switch the the broken one for the real one because that then they wouldn't no longer be able to decrypt the data so they're gonna be stuck with this particular thing it's written in Borland C++ and it runs in a Windows VM yeah so those things happen nobody wants them right those things happen to you I think um sometimes it's that successful systems end up with the worst kind of architecture that's kind of weird right it's because nobody ever invests in architecture because nobody really cares about it because they're successful but I mean why would they until at some point in time it feels like they're like they're you know a burning oil platform that's still getting oil from the earth right somewhere on the ocean it sits there and everybody's happily producing oil yeah at some point in time they start and then to try to figure out how to do this so it's better to start earlier with those efforts as opposed to waiting until you find out at some point unmanaged evolution will lead to complete chaos Rises the entropy right pill you have to manage it somehow yet carefully do you know don't be afraid of some architectural governance I know I said the Senate at the beginning octave is sometimes a swear word to some people but a little bit of it doesn't really hurt you and maybe you should do that now here's my last one it's slightly more positive right that's actually an improvement that I that I think is interesting because the new thing does less than the old thing and I think that's a rare situation so the context here is a bank multiple commercial off-the-shelf systems so it basically basically an integration scenario and this particular bank had an existing solution which was built by a very large vendor that's typically colored blue so a very large solution that was phased out right and it was highly proprietary and they basically just had three or four people in the world who still knew how this particular version of that system worked and they had managed to keep things running they still actually they still managed to keep part of it running part of running for a long time but they knew they had to do something else so what they wanted to do initially was replace the commercial product with some open source solution because the decision for the commercial product had been made like 15 years ago and they knew that they were now really cool things out in the market so they they they decided to look something actually hired us to help them look for something and we build a new system for them so what they had was this message broker thing right this this piece of magic that was super configurable that had its again its own ID each always a bad sign the tool brings its own IDE you should be worried so it had its own you know its own user interface and it did a lot of things right like like this is this is sort of the feature list of integration products right you have all those things the last thing should worry you a lot but because business logic really does not belong in such an integration solution but it always ends up being there once you have something that's capable of doing that so what happened was they they actually built business logic using the configuration language of the particular tool which included usual mapping thing that could map one XML structure to another now that's not something that you can unit test right or that's not that's not software development that's just a disaster so again I'm renting I didn't want to do that so what we replaced it with was something that looked a lot more like this so there was a messaging solution in the middle but it was a really really small one and had these little things that now stick close to the individual things which which the team called adapters and those adapters did a lot of the things that the original platform did within the the magic integration platform right so they they decided to move things to those adapters and those adapters had a completely different architecture they used a fancy concept called programming so if you wanted to do something you wrote a program and they actually ended up configuring do they because there was a Java shop they configured a very small tool stack based on the apache camel to actually show them how they can write something like this but they only ever intended it to be taken as a blueprint like and this is an example of how you could do it in one of those adapters but don't assume that there's a centralized instance of that right so the centralized instance here really did what a pub/sub messaging system does right it had topics or and you could subscribe subscribe to a topic and it did some error handling it did some transport reliable transport and delivery and stuff like that right so there was I think it was revenant who doesn't really matter was a standard messaging solution which worked for them and then the adapters were those little programs and they were essentially docker eyes so they had a little dock a swarm based runtime that could run those things and that's it if you want to build something if you want to integrate something you didn't fire up an IDE with a GUI that allowed you to you know do the work that you could program in ten minutes in three hours you just did the ten-minute work and wrote a script or a little Java from right so I like that solution a lot because it helped them replace a lot of what the existing system does they still both running so they've moved I think about half of the load of the old system they're gonna slowly move it within the next few years sort of the strangler pattern if you know what that is very slowly suffocating the old system and then switching over to the new one and that I think is a very good example of something that was good enough for this particular scenario okay so let's add most of those smart endpoints dump pipes that quote originally by doing weather I think is a very very good thing never put too much logic in too much intelligence into your infrastructure I know it's very tempting but it doesn't matter how cool the name is even if it's a service mesh something that I like right it's still a very stupid idea to make to give it too much power and and to risk ending up having to maintain it as as the piece for logic results there's a lot of value of specific over generic solutions right sometimes you you end up with something that's much better if you just implement something that's not as sophisticated not as generic right and I like this micro architecture with blueprints idea because I think it'll give you a lot of opportunity for showing people how to do something that you they can get they can get to speed very quickly but you don't impose something that'll that'll that that'll be enforced all the time for everyone because that does not make sense right think of this adapter scenario there are certain adapters for certain systems that are probably much better written in in c-sharp or maybe vb.net if it's a Microsoft platform based product that they have might be might make a lot more sense so why would you why would you force some poor Microsoft developer to use Apache camp well the other way around that I don't really care okay so you're my takeaways and then we can discuss a bit my first one is don't be afraid of architecture I think it's perfectly reasonable perfectly fine to make architecture something that is is discussed and that should be pragmatic and that should be reasonable right into should I'm not talking about the the traditional kind of you know we fill of you we filled shelves with with folders with paper that nobody ever reads don't do that unless you're on a government contract because then you have to um well not even then and choose the simplest thing that'll work right choose something that will fulfill the needs and and be pragmatic about the whole thing but bah also think that this stuff might need to evolve right and that if that sounds like something that's in conflict that's because it is right this whole you know it really depends on when you talk to if you if you talk to a group of people who never take any risks and who never we never think of well we might have to do this next year so that's building things this way now so that we don't have it as much word next year of course that's a risk because you're gambling that this particular thing is going to occur of course you can say well let's not do that let's just build the stuff that we need today but then you'll have to pay for adapting that later so the yakhni principle does not mean don't ever think again right make it good and conscious decision between those two things choosing the simplest thing will work I'm creating evolvable structures and once you've done that manage your systems evolution architecture is not something you can do up front your architecture will most likely suck and you will only find out after a year and that's fine because then you change it so that it doesn't suck anymore and that's just part of architectural work right you have to change your architecture within the possibilities that it originally gave you that's why I'm a big fan of architectures that have this this evolvability built in right where you build something that from scratch is designed in a way that you can change a lot of decisions without risking the whole struggle structure of the whole thing and if you are tasked with an architecture role with an architect's role that that's on your business card then do something of value right don't create roadblocks it's not your goal to you know force your personal tastes on everybody else in the company just you know do meaningful valuable work and get out of the way as fast as you can and that's what I have thanks a lot [Applause]

Channel: GOTO Conferences

Views: 199,799

Rating: 4.8748603 out of 5

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, Programming, GOTOber, GOTO Berlin, Stefan Tilkov, INNOQ, Software Architecture, GOTOoslo, GOTO Oslo

Id: PzEox3szeRc

Length: 41min 41sec (2501 seconds)

Published: Wed Apr 01 2020

Reddit Comments

[u/mto96]

This is a talk from GOTO Berlin 2019 by Stefan Tilkov, co-founder and principal consultant at INNOQ. The full talk abstract can be found below:

In this session, we’ll take a look at some of the ways we can determine whether the development efforts we’re undertaking suffer from too much or too little focus on architecture. We’ll examine a number of real-world examples that are intended to inspire either admiration or terror, and try to find some recipes of how we can get more of the former and less of the latter in our own projects.

What will the audience learn from this talk?
How to find the right balance between agile/ iterative/ incremental development, diving right into coding, up-front planning, and continuous architecture focus.

[u/openlowcode]

Thanks for this insightful talk.

I especially like non-extensible extensibility ( at 10' in the video). This is the problem I see the most often using software package, and I agree 200% that for complex projects we should sometimes go specific. I wrote a small post on this, and would love to have your advice.