Architecture: The Stuff That's Hard to Change - Dylan Beattie

Good morning, how are you all doing? Hands up, anyone with a party hangover. That's great. We should celebrate software, coding and development and be all together this way. I'm going to talk to you now for about an hour about

architecture

and all that.

hard

to

change

, this is me, Dylan, by the way, I'm CTO at Skills Matter in London. I am a Microsoft MVP with Visual Studio software and development tools. I run the dotnet user group in London. I created a programming language called Rockstar so that everyone can I will be a Rockstar developer and I have some Rockstar to give away that I don't want to take home, so come and get it at the end.

About five or six years ago, the company I worked for hired some consultants to restructure things and one of them had a long series of interviews with me and they said, "We think you would be better suited as a system architect," so What I received this email, dear Dylan, this is to confirm your job

change

as a systems architect for which you are now responsible.

architecture

architecture doing architect things systems architecture and systems architecture congratulations, so I go back to my desk, sit down and say, hey, I'm an architect, now I don't feel any different visual studio, it still doesn't load very fast, you know? and that started me on this journey, you know, it's like I'm going to do this job, I want to do it right, so I want to understand what architecture is, actually, what it looks like when you do it right, what the role of an architect is. on a good team and I started doing a little bit of research into the words that we use because we have all these words that we use in software that we steal from other places, as you know, we talk about pythons and mice and people say, yeah.

I have a Python in my house. I feed my sister like no, no. Python mice are different and we have buses and we have pipes and we talk about launching and crashing and you know, these are all English words. which means something else and we've taken them and gone no no no no no, we're going to use them to mean something completely different and this language can be a really powerful way of understanding people's approach to the problems that exist. there is some controversy in the world so put your hand up if you are a developer you call salford developer keep your hand up if you call yourself hacker coder architect front end back end engineer the word engineer is this controversial term we have let's talk of software engineering now there are some countries in the world where you are not allowed to do that in Canada you are not allowed to be an engineer unless you have an engineering license from the Canadian government in New Zealand you can be an engineer if you have a bachelor's degree in engineering of software, but no, if you have a degree in software development or computer science, you must have engineering in your degree and I live in the UK and a couple of weeks ago the cable TV went off and my house and they sent an Engineer to fix it like me.

I don't think this person has an engineering degree, but we have these ideas about architecture and engineering. My first job years ago. I worked for Arab, which is a large construction company and has architects. and they have engineers and I started doing a little research on where these roles come from and the distinction that makes sense to me, let's think about construction for a minute, we have these two things here, the little barbecue on the left that is a hack so probably the person who designed it built it themselves or they got a couple of friends and helped them.

The thing on the right is the Brooklyn Bridge. The guy who designed the Brooklyn Bridge didn't just build it now and this is what I did. I think it's an interesting distinction, you know, architecture is maybe the point where you're involved in designing software that you're not actually going to write like you're coming up with the designs and the interfaces and the structures, but you're not going to to be. the person who actually writes the code and in building architecture we have these amazing examples that we celebrate and people travel all over the world to go and look at these kinds of things and in software architecture we were a little bit behind the curve.

On that note, what was the last time you showed someone a codebase? When you look at this, it is absolutely beautiful. Now come and look at it from this side. Take a photo. You know, maybe the architecture and software are not exactly the same as the rest. what the world thinks of architecture is and it's just software and buildings that have architects, they're on airplanes Architects, there are no race car architects or plumbing architects, you know, let's dig a little deeper because the first person to use the term software engineering was this lady, does anyone know who she is, she should be awesome Margaret Hamilton, she was the lead engineer for the Apollo 11 guidance systems and she was the first person to talk about software engineering and what she called taking a systems view. how the software works. it with all the other components in a system that in this case was the system that took Neil Armstrong and Buzz Aldrin and took them to the moon.

She was the first person to talk about software as an engineering discipline, it's not something you do after the site. by itself is something that has to fit with all the other processes, machinery and systems that are happening for this project to work. The first person to use the term architecture about computer systems was Fred Brooks, he wrote the mythical month of man with I'm sure some of you have read a very influential engineer and scientist and back in the 1960s, 1962, he was working on a system for IBM called stretch and in the prelude it has this quote: Computer architecture, like other architecture, is the art of determining the needs of the user of a structure and then designing to meet those needs as effectively as possible within the economic and technological limitations.

The first time the word architecture was applied to computer systems, back in the 60s, 70s and 80s, computer architecture almost always meant

hard

ware because hardware was what was expensive to change, if you decided to change the way a computer worked. code snippet, you just wrote new code and submitted it and you were fine, but there are fundamental decisions, one of the decisions that Fred Brooks made in the IBM expansion project was to use eight bits in a byte instead of six and Basically, you can trace almost every computer since then. The 8-bit byte convention we all use can be traced back to this decision.

Now imagine changing that decision halfway through. building a computer system is fine, that's it, throw away the processors, throw away the motherboards, throw away the buses, throw away the factories that we have built to create the motherboards and processors, we have to start all over again, it is expensive to change the software. It was always cheap as a percentage of the total cost of building a system. Two things happened around the 1990s that began to change the way we think about this. The first was that enterprise software became mainstream companies that knew they had never had computers before.

All of a sudden, they had computers and they were getting people to write software for them in Visual Basic and you know, little flower companies and little hotels and car wash places would hire someone to write them a little software and they would set it up and run it and It would be great and they could print their invoices and

stuff

and then a couple of weeks later they'd say, "Oh, it doesn't do this thing we need, we have to change it," how much and all of a sudden the cost of making changes to a software .

The system became a significant proportion of the investment for many of these companies, so we started thinking about how much it will cost to change the software we've already built. The other thing that happened was the world wide web. Up to this point, practically all software. ran on a computer and if it had any output it was a screen or a printer, we didn't really send email, we certainly didn't make apps, APIs, uploads and so on, the World Wide Web came along and suddenly instead of building software that was would run on a beige box in an office, we're building things that run on thousands of machines around the world, clients, servers, gateways and all these components, and now there are companies for whom the cost of changing software is almost their own.

The entire operating budget, you know, they have a couple of janitors and some HR people, but almost the entire payroll is made up of people who change code all day, every day, and for those companies, if those changes are cheap, they are profitable, if those changes are expensive. We're in trouble and so we're focused on this idea that architecture is something that's hard to change because everything else is just coding correctly. The first kind of formal treatment of software architecture was this book by Mary Sean David Garland, published in 1995. And one of the things I love about this is that they called it an attempt to formalize substantial folklore about systems design. .

There are all these people around the world who have good ideas about how to build bigger systems, faster systems, modular computing systems, but no. one had ever put all these thoughts together and gone, let's try to find some words about this so we can have conversations about how to make all of this better. I want to dig a little deeper into Fred Brooks' definition because I like this and I want to break this down into three things so that architecture determines the needs of a user, designs to meet those needs within economic and technological constraints. Now one of the big revelations for me in my journey to becoming an architect was realizing who the users are.

They were because we built computer systems correctly and we thought that the user is the person on the other end who drags and drops and fills out forms and all that kind of

stuff

when you are an architect, who are your users? They are the developers on the team, Your job is to meet the needs of the people who will build and ship the systems you're working on, and it's not just the people who are on your team today, but the people you'll hire next. year or the people who will be working on their open source projects three or four years from now, so their role is to think about how can I serve people we don't know yet and create software we haven't written yet to sell. things we haven't thought of yet for clients we don't have yet and make it easier and happier.

We're probably going to need a plan now. The plans have had a bit of a difficult time when it comes to software engineering because of this wonderful thing called the agile manifesto that everyone took advantage of and read and when this is brilliant now not many people know about it, but they deny, they understood that the philosopher french was actually an agile consultant when he wasn't doing philosophy and one day he's working with a client and he says to them, you know, the agile manifesto says we should respond to change instead of following a plan and the docile one says oh, that's right. brilliant, we don't have a plan and they cut your salary.

Blah, if you don't have a plan, how can you choose not to follow it? It is not a valid choice. There is a difference between saying this is our plan but circumstances have changed. The plan is no longer exact and just going on, we haven't planned it. Whatever, let's make it up as we go and see what happens. What the authors of the Agile Manifesto had observed time and time again: their team was deliberately doing the wrong thing because that's what the plan said and that's what they were trying to address when they wrote this, we're discovering better ways to develop software. through this work.

We have come to value responding to change more than following a plan. While there is value in the items on the right, we value the items on the left more, you need a plan, but the plan is not guaranteed to be accurate. The plan is a living document. You, as an architect, should have some idea of ​​what you are going to try to do and how those things fit together. There's another detail in the agile manifesto or one of the principles behind this that I just wanted to mention: We follow these principles, the best requirements and architecture designs emerge from self-organizing teams.

Now the point they are trying to make here if you have a team of people who are working well together and are coming up with their own way of doing things step back and let it happen, don't hire people and go there, go there and They self-organize and then they come back in a month and ask themselves: where is the project and they're like we organized in the bar across the street, what do you want us to do now? You know, be prepared for this to happen because high-functioning teams will click and start this positive feedback loop, but if your team comes to you and says we could use some help, you know we're not sure how to approach this. , we don't know how to collaborate on this, you need a better answer as an architect than to go and self-organize, okay, you need that. to give them thesupport to allow these things to arise, let's talk about restrictions, here are the rules, no new hires, no JavaScript, no open source, no microsoft, no cookies, this I believe is the engineering principles of Oracle Corporation , we are not going to work here.

It would suck, but everything you do will have limitations, there will be things you just can't do. You know, we still can't transmit solid objects around the world. If someone comes to you and says: Can we build a teleporter for shrimp? be like no, that's not a thing sometimes they have to come to you and they leave can we do high definition video calls like in real time without using cables and for a long time you will say no, no, no, and then a day be like in Actually maybe yes for a long time everyone believed that a touch screen phone was going to be a disaster because all the touch screens anyone had ever seen were those plastic things at the airport that don't work and click in the wrong place and there there was. a team of people working at Apple who were working on all these different things, different types of glass, different types of touch screens, multi-touch and they were the people everyone else was using a touch screen phone it's impossible, the limitations are too much big and not really, now it's possible, now we can do it and they released the iPhone and within a year everyone was going, yeah, of course, everyone wants a touchscreen phone, you know, we'll make one, we'll make one at Google, they made one , Android made one, all of them. of these different things converged sometimes, as an architect, your job is to be attentive to everything that is happening so that you can sit at the table and go to what we thought was impossible, maybe now is the time for one of the things of this job that is difficult is to communicate those limitations to the developers, all your developers go to NDC and go back to work and use shiny new JavaScript frameworks that will solve all our problems and you are the one who has to say sorry, we have to support Internet Explorer .

It's one of the limitations of what we're doing because this is a business, we have a big client that's still using IE 9 or God help you, IE 8 or something like that and you're the one who has to communicate those limitations and explain to people. Yes, I know they want to do it this way, but that doesn't really align with the limitations of the system that we're designing here, so there we're going to determine the needs of the user, satisfy those needs within the economic and technological limitations that They are now done in software. architecture is very easy it has to do three things you have to make a decision communicate it and then reinforce it thank you very much bye now we will do some more so when making decisions, how do you choose someone?

He comes to you as an architect and says we want to create a system that does this. We want to create a D cup similar to a login system so that you can create different microservices that use common authentication. How can we do it? And your job is to come up with a way to do it sooner. You can do that. First you need to understand five things. What you have now? Long time in software organizations and teams. There will be two versions of the truth. There will be what people think they have because they paid someone a lot. money for a high-performance transaction processing system and there will be what they really have, which is a hundred thousand lines of Ruby that don't work properly, you know, and you need to understand these disparities now, the best way I found to do this is look the boundaries, the boundaries between different systems, you want to understand the traffic that flows between the components of these systems, don't worry too much about the code, don't worry about the specifications and you will know when people tell you what something is.

I take it with a pinch of salt, it's helpful, but it may not be one hundred percent accurate. Here is the simplest possible systems diagram I can think of now as an architect, it doesn't matter if that website is PHP, dotnet, Perl or Ruby. or whatever, and the Internet is someone else's problem, but this thing in the HTTP medium, how many questions can you ask about it? How many transactions does it support? Is there HTTP in it? When does the certificate expire? Can you still stand it? Post What if? I put a proxy there, how much of this can we charge?

Are we using electronic tags on the traffic that flows through it? Simply putting a network trace on that HTTP and looking at it for half an hour will give you more information about how this website actually works. works than any number of hours spent reading the code and following oh this module looks interesting oh it's never been run we don't know why it's here you know traffic is real traffic it's the lifeblood of living systems no you care about nothing. It was designed to make its Kranz gene on Apollo 13. It cares about what it can do.

You need to understand the actual capabilities of the systems, not what was in the specifications. Sometimes this will be disappointing, as our high-performance authentication system can only support six users. Wait a minute, sometimes it'll be a pleasant surprise when you dig into AWS and it looks like there's an entire Redis cluster here that you didn't know we had. This is brilliant. We can start using it to speed up all kinds of things we can. put varnish in front of our web server and boom instant speedup and we can start rewriting things, you know, there will be pleasant surprises and disappointments, it's worth taking the time to do this, of course, some of you are doing well, we are working. in a greenfield project here we have nothing, there is no such thing as a greenfield project because there will always be a couple of small systems scattered across the landscape, maybe there is some sales data in an Excel spreadsheet that you need to work with. and some of this you will be able to work with and some you won't, for complicated reasons, there will be remnants of the last attempt to build the Greenfield system because someone has always tried this before and there will be some code floating around there will be politics there will be the person who was fired for choosing use Microsoft's sequel server and now no one will touch Microsoft's sequel server because the last person who did it was fired and you know, now it's okay, I'm really glad to know that, because now we know how to approach those kinds of conversations, there will be a rabbit hole, which seems really very easy and you tell your team to just integrate Redis with nginx and they come back three months later and go boss, we really need something, this is not going as it says in the documentation, all these things are out there and only once you understand them, know where they are, can you really make informed decisions about how to approach what you're doing. you are doing, you know what you have, what you need, you have most of the business stakeholders, they say yes, the website must be fast, the website must be secure, you say brilliant, thanks for the briefing, you go to your team, hey, the boss wants it. to be fast, the team works brilliantly, we will build our own HTTP accelerator.

I saw a conference where they talked about it and you come back two weeks later and the boss says the project is finished, yes, and you say no, no, the team is working on an HTTP accelerator. really cool, they are using bitwise pattern matching on the incoming network stream to get one of the ten fastest web servers of all time and boscoe is not that fast how quickly to turn this into business conversations because as an architect , you will be the conduit. between what it means in technology and what it means in reality how fast is a fast website 500 millisecond response time from the 90th percentile some stakeholders will say it sounds brilliant others will say what percentile you assigned it, you got it right what this means If there are ten people on our website, one of them will have to wait a little bit and I will say how long and you say I don't know a second, five seconds and now that yes, five seconds is too long, no, no.

I don't want that, so you can turn this into a conversation and they go back and make it faster and you say, well that's going to cost and they say how else can we make it faster and you say we could eliminate the JavaScript that draws. the advertisements and they say, we can't do that and you say, well, you want it fast or cheap, they both know how to turn this into business conversations, they say it must be safe, how safe do you know, go further. you need to be sure what is the threat model you are worried about?

There's a great talk I saw James Mikans give here a couple of years ago where he talked about basically three different threat models that are Russian botnets. He is angry. partner and the Mossad and the Russian botnets are going to knock on the door for three seconds and if they don't come in they'll move on to the next account so you know they download these huge password tables from Pirate Bay and that kind of thing is a threat profile, the angry ex partner, this is difficult because they probably have access to the cell phone that belongs to the account, so two factor authentication might not work, so think of mechanisms to prevent Mossad from already being in your system, just let worry about it and enjoy your life and don't piss them off, what can you build if you decide right?

We have to do this, this is what we ship, how reliably can you achieve those goals in your sprints or your iterations or your stand-ups or whatever cycle you're using to do this work and this comes down to what I call the four p people patterns packages process who are the people on your team and who are the people you can hire what communities is your project interesting for other people there that you can reach and involve them do you know how easily what kind of skills your angular people have the f-sharp people react the people who are at the front and understand all this and align themselves with the type of work you're doing make technology decisions based on who you have based on what you can do who you can hire patents are the type of conceptual building blocks of modern software and some patents fit very well with some people using some languages ​​and others not.

I've been working a lot on Ruby on Rails recently and Rails is so tightly coupled to the MVC pattern that we had a 10 minute conversation the other day about something called a service. object and I was like what's the service, I'm even sure how about talking about classes, you know, the behavior of classes and data and one thing and rails are so coupled to your view model or a controller that something which is not one of these things have a special name whereas in dotnet we start with everything is a class and then you say oh yeah and if your class does this then it's probably the controller pattern understand the relationship between patterns and technology choices what you're doing because that can make a big difference, especially if you find yourself fighting against the language's own or frameworks' opinions about what patterns you should work with.

Packages. The entire language now survives in a sort of ecosystem of components, libraries and modules, and you need to encode a transparent PNG or do some cryptography or stream some video for most languages, you will be able to find someone who has already solved this problem, Understand the breadth of the ecosystem you're choosing to work with, how easily you can get those packages. actively maintained what happens if one of them goes away how easy it is to branch off and do your own thing and the process is just about reproducibility, it's about being able to sit down on a Monday morning and say we're going to ship this on Friday onwards Friday most part of the time you've done it it's about how your people collaborate it's about how well you understand the obstacles and capabilities of the systems you're working with What can you buy?

There is a rule. Dillon's Law of Software. never use PowerShell when you could use MasterCard your team should be building the things you can sell the things or you know the things you can give away the things that create value for your organization you know don't build your own cloud system Amazon you've done it unless that you're trying to compete with Amazon in the cloud infrastructure space, that's a waste of time, they solve that problem, you solve your problem, look at everything you're doing now, there's a point here, there's actually a conversation interesting about using Google Analytics because one of the systems I'm working on has its own tracking and analytics engine and the reason is that we are using those analytics as part of the product and someone said why don't you use Google Analytics. and I said, because we don't want to rely on Google for something that we actually deliver to our customers, this is what we do, we're delivering it, we own the value stream to see how many people clicked on an email, yeah, have Google Analytics for that's okay there's this kind of yin and yang there's this balance here what can you lose raise your hand if there's one system in your company that sends email keep your hand up if there are two systems that send email three four five I once did an audit and we wanted to change the name of the outgoing emailto fit the new corporate color scheme.

I found fifteen different places in the code where a developer had written some code to create an email template to fill in the HTML and send it and The first person to do this was definitely me because nothing existed and I sat down and said this . The second was a developer who didn't know he had already done the first. The third was someone who was, we will be two people. I've already done this clearly, this is how things work around here, the fourth was an outsourcing and you know, I had to go and search, make the emails purple, it's actually going to be very complicated, we have converted the color of an email into a software architecture problem because we have this duplication, so what we actually did was in the process of converting it to purple, we consolidated all of our email into an outbound relay service that applied branding on the perimeter before Before you ship it, look for that kind of duplication because there will be opportunities to make things easier, optimize them, recover some technical debt, you know, improve the cost of changing those things.

Once you understand these five things you need to decide what to do next, this is the easy part because once you've gone through all those motions, you've had the conversations, you've talked to the teams that you understand the picture that you come up with things. as an NDC and you stay up to date with what's happening in the industry and the community, a solution will emerge, you'll have a couple of good ideas, you'll share them with some people on your team It'll be like you know, I think we should do it this way, then Here comes the really fun part: you've decided what the software is going to look like and in your head there's this beautiful crystalline structure of data flowing through systems and interfaces, you know, data. structures and Landers and server lists and cloud and you sit down with the team and say: let me show you how the software is going to work and you draw them the diagram and they look at it and say: what is this Java that I will talk about?

The problem with diagrams now in construction engineering you hire someone to build you a building, they'll start by making some drawings and you'll look at the drawings and say, "Okay, I'm sure you know what you're doing." They'll give you some more drawings and produce drawings of final elevations, side elevations, plan views, schematics, but sooner or later they'll get visualizations of artists' impressions and you'll look at that and you'll be okay, I can see where we are. Let's go with this and I'll come up with slightly higher fidelity versions and you'll think okay and then they'll build the building and you'll go.

It's exactly what I thought it was going to be and you can see it and you can. look at the drawing look at the building and see yes, he did it that's exactly what he expected now we grow up surrounded by drawings one of the first things we learn to do when we are children is draw to communicate by making marks on pieces of paper and your parents glue them on on the refrigerator and they hope you improve your heart before it becomes embarrassing, you know, and we become good readers, we have children's picture books with pictures and we relate the pictures to the words so we are visual. creatures who grew up surrounded by diagrams, drawings, photographs and illustrations that we intuitively know how to read and understand, unfortunately in software, this is not necessarily true.

Here is a software architecture diagram. Who wants to build this for me now? this is this is a formal notation this is a diagram drawn using a notation that you can learn in school I studied this in college this is the yordan de março notation for software engineering who can tell me what the things in this diagram are someone nobody no, it's not the forward slashes that are backwards on what's on the right, well for starters let's add a key for you to meet people who might have forgotten a little about you besides DeMarco since they were in school , so there we go, there is the key to the Frame Order notation, so the top right is not a regular expression, it is a database or a file system we don't know which, but it is a database or a file system and the oval things have functions, so now you can look at this and you can say, "Okay, so we have some, you know, these two things that have data and then they go through these two ovals and then there's this thing on the bottom right, what is that?

Okay, that's input/output and for some reason it's called mandrill and Hann. I think I might know what chuck is because I remember reading about it in the MailChimp documentation, so maybe it's that and this thing with the backslash that's maybe a Windows shared file, it's got a dollar. in the end, you know what it could be, let's start decorating this with more details, so first of all, the internal codenames, let's just put quotes around them to say don't bother Googling this, you won't find anything. Excelsior is a sequel server full of client details why it is called excelsior because the person who built it took it from Excel I don't care to name it is difficult mercutio what is it?

It's a dotnet service that populates email templates, so Norman is a dotnet application that sends emails why Norman Mailer Well, thanks Steve, I really appreciate that this here JK 6 GB 87, which is the asset tag of Dell's server where the marketing department keeps all their email templates, all of these things are real, by the way, they are real pieces of software that I have worked on and mandrill is the SMTP relay service for MailChimp, which is a mail platform electronic, so now we're like we're still not sure, but you could sit down and go, okay. I think I understand the type of people we are.

We will need to build this system, we are still restricted by the fact that we are using DeMarko or notation because we got it from a book and that means the only things we can conceptualize are our databases, the functions, the data flows to the outputs , we discard it. create our own notation, no one can read it anyway, we're going to have to include a boom key now that we're getting somewhere, we've got some clip art and we've got some Microsoft Office templates and we've got some stuff we found on Google, we've got this red line here with the charts that I pulled from the rabbit and the queue documentation, so now we can say, okay, this is great, we have Excelsior, what's the green line here?

That's a dotnet, okay? This makes sense, we have Mercutio, what is the little cogwheel? Okay, those are Windows services, that blue thing that's an SMB file share, okay, and we're starting to think, okay. Now I get it, you can look at this diagram and see what kind of things they are. we're going to have to do to deliver it, let's go even further, let's write down the traffic limits, a deonette, ok, Windows authentication, now we know how to connect these things together, this Windows file share that we're using for text and HTML, this RabbitMQ, okay, that's AMQP in the cloud.

Great, we know how to work with that SMTP port 993 TLS enabled, that's why I can't send any email. I'm using the wrong port and I don't have the certificate. Now we have enough information here to have a meaningful conversation about how. Are we going to build this? How much time will it take? How many instances do we need to provision to run it? The one on the left looks like the ones in the textbooks, it's clean, elegant and looks like the work of a professional and people who read it say: I'm not going to ask about that because I don't want to look stupid.

The one on the right is starting to look a little messy, but it's a mess that contains useful information and you can actually use it to have a conversation. One of the big challenges I find in all types of software development are the examples in books, tutorials and conferences, they are always small, no one shows you how complicated everything becomes when you do it. Seriously, this is part of a systems architecture diagram that I built as part of a collaboration and outsourcing project about five years ago and, you know, it's literally broken down. There's a key here, like I said, it's all different types of traffic there's even a color code in there for a horrible VB cursor based library that we knew existed, network traffic didn't make sense, but we knew it had Visual Basic on it. one end and a sequel server on the other, we could never make sense of it. so we capture there, look, this is here, it's important but abandoned, I hope you never figure out how this works and we just paste in, you know, arbitrary notations like there's a comment here.

Database Inc every five minutes updates usernames and passwords as you can. make it on demand by pressing the big red button, put that kind of thing because this is something that people like, okay, it's already messy, what if we doodle on it, let's start taking notes, annotating and moving things and stuff, and this is what the diagrams look like. like when you try to convey reality instead of making things look good like they did in engineering textbooks final note on diagrams here are two software architecture diagrams one of them is hexagonal architecture which one will I give you a clue that it's not the one with hexagons most of the time there will be words like hexagonal architecture and shear ports and adapters, layered interfaces, that sort of thing, if you've heard the expression hexagonal architecture and you look at these diagrams, logically Suppose the one with the hexagons is hexagonal architecture, now we use the name hexagonal architecture because the first version of the ports and adapters document used hexagons and the diagrams in the name were a bit stuck together, it has nothing to do with hexagons, not them. there is. necessarily six of anything in a hexagonal architecture is just a name, we have the thing on the left with the data ports and adapters on the express doors, the hexagonal thing on the right is a honeycomb with clip art glued on, it has nothing to do with the software.

I made it up, never be afraid to ask, never be afraid to say hello. Sorry, I'm still not clear. Can you go over what that thing is in the diagram one more time? What is this line here? What are these things? the yellow thing is that a sequel server database, which you know, having these kinds of conversations makes it okay for the other people in the room to say yeah, I don't understand either, can we do that again? It gives the architect the context of well, then he could present something. These are the things I want to cover beforehand so we can jump right into what we're going to do and how we're going to build it.

It's about reinforcing decisions. work out your design you understand the constraints you know what you're trying to achieve now you want to help the team build the right thing Initially I called this application decisions, but I didn't like the kind of you know the architect like the police, you want to support your team in the work that they're doing and this comes down to two different types of things, what we call validation and verification, validation, are we building the right thing? This is difficult because what you can do is go back in ten years and see if this company is still in business and if the software worked.

There's not really a shortcut to this, but checking if we're building the right thing, if what we're creating matches and reflects the ideas, designs and structures that we've talked about now with building architecture. You can take your diagram and you can take your building and you can see them side by side and you can say, Yeah, that looks good to me and there are other dimensions, stress diagram engineering and load-bearing things and stuff, but this technique that We developed as children to look at a drawing and say whether it looks like real life or not, that keeps us in good standing, so let's do the same. with some software here's our diagram, the right teams created the code, that's it, it's shipped.

We want to take a look at it and see if it looks like the diagram. How do we see the software? I know Microsoft Azure has a dashboard, let's look at it. it was very pretty but it doesn't really look like the diagram maybe teamcity can show us what's going on, they are still pretty but it doesn't really help us and these red bits can be bad. I know we'll look at the code. Now I just don't see the relationship here, how can you tell if the software that has been created matches the design, architecture, concepts, structures and things?

Now, when I started doing this, I made a classic mistake: I'm going to do all the code reviews so all the teams can build what they want, and then as an architect, I'm going to review the code, read it, and make sure it's correct? This really sucked, it was horrible. and I don't recommend you ever try it, you'll get tired, you'll have days where you're still at work at 7 o'clock to 8 o'clock at night and you think those 15 pull requests are still there. review, but if I don't review them, no one can dono work tomorrow, then you get a little sloppy and say, yeah, that kind of looks good, I don't know, and the other thing is it restricts capacity. of your teams to do things you don't understand and you get this.

I reviewed your SHOP code and I still don't know what it does and your lead engineer says dude my team is using Scala, the other problem with code review is Take a look at this code here. We have had a meeting about the architecture and design and we said that we will use a repository pattern with an identity map and everyone has followed the repository identity map. We understand Mr. Architect, thank you very much and then they give you this code, what can you say about this code? You can tell that the developers knew that the word repository and identity map were important and that they should use these names.

The names don't tell you what. the code just tells you what someone called it by reading the code and trying to distill what it does on a good team that used the name inconsistently and understands the relationship between patterns, classes, names and so on, it may work, but it could also being a bit of a minefield is like wandering around a city at night and going to a luxury hotel that looks pretty nice and then waking up in the morning and saying okay, maybe following the labels wasn't the best way to go. understand what we were doing here, so what can we do to gently guide our teams down the right path?

Create a well of success that helps them find the right type of implementation. One of the most powerful things you can do is exploit something called Conway Legal Teams Building Systems, the system they build will end up matching the communication and organization structures of the teams that built it, so if you have a split software in components, you'll want tight-knit teams that create one component and another tight-knit team. building another component and another team building another component and aligning them with the technology options, a group of front-end people, okay, to the front-end, this sounds obvious, but there are places where this front-end team goes wrong , you're there, react angularly with JavaScript, whatever you want to do.

You have your part here you are doing F sharp and you know calculations and back-end and pricing all this kind of stuff you can even exploit geography to make this happen you know how to say very well, we have an angular team here in London, we have a F Sharp team in Belarus, where we have outsourced much of the heavy lifting and processing, and then our Android team will be based in Porto, what you get here are the limits. between these things will arise naturally because it is actually cheaper to collaborate and it is actually very expensive to change something by collaborating with a team in another time zone so that the boundaries between the teams are correct and this is where you as an architect can get involved. this, you have a front-end team, the front-end team, a build code that connects to an API server, sit down with them at the beginning and tell them what we need to do here, it will fake some API responses so you can start working and then on the other side, you get the other backend development team and you say: right, I'll help you create the specifications, the test suite for your API and then you can go away and create the client that satisfies those requirements, that's how you communicate the you design, you create the data and you create the tests, you work with them on this and then you let them go and you build the actual code and then you can connect these two pieces together and as an architect, that's where you look at what it's happening. into the system and look at the traffic, are you seeing the data structures you expected to see, latency, throughput, and traffic volume.

The kind of thing I was hoping to see. One of the questions that frequently arises is: should architects? still code yes, absolutely yes, because if you stop coding your hair turns pointy and all your Def Leppard t-shirts are taken off, but you don't work on production systems because what will happen is you will have a good idea on how to improve the architecture and sooner or later you will give in to temptation and say: I don't want to update the diagrams and have a meeting, I'll just do it and then the team will leave, what the hell? you've done it and you say it's better now and they say it's okay and the first time they will say and the second time they will say it's okay, you do it and you will become the bottleneck again and suddenly you will know that the architecture is lagging along the way, the team will say, well, you keep changing things, so this is your problem now, we're not working with it anymore, but you have to stay in control, you have to keep coding, otherwise.

It's really hard to just keep your tools sharp, stay up to date with what's happening in software; It's a great way to establish credibility and good working relationships. The best way I have found to do this is to have the architect build the monitoring systems. You pick people on teams you like, right? I want to see what your API is doing and I want to show that traffic on a big screen on the office wall with, you know, red and green lights and all this kind of stuff, let's team up together in building that thing so that you As a coder, you have enough information about how that system works, but you are not responsible for anything that actually goes into production in a customer-facing system, you are building the things that run on the wall and it gives you a sense of property, you know you say, hey, this is cool, I have a code of life there too, you get to collaborate with people, you learn from them, you share some advice and wisdom, most of the architects were pretty.

Good developers before you start specializing in architecture, there is value in those things, but don't become the bottleneck, the other thing that you can do most of the time, especially when you make the decision to go and use er off. having a service available or hosting something somewhere or integrating it with a payment provider as a business decision, it makes a lot of sense because these things work, but for the developers on the team that experience often sucks because they have these nasty APIs with cryptographic xml signatures signed. and weird sandboxes and stuff, and the developers don't see the business value.

I had a real case a couple of years ago where we moved a lot of things from internal systems to Microsoft Dynamics and Dynamics as a developer, it has some interesting capabilities, but there were a lot of things that were quite difficult to work with and you know the team was a little oppressed. I wonder, I said then one day, do you remember last year, every Monday morning, someone spent two hours sending mail? database lists so the marketing team could send out the weekly newsletter and everyone said yes and I was like, did you realize we don't do that anymore? and everyone said oh yeah, because you lose sight of these things when the business problem arises. is solved developers very rarely see the solution their job as an architect is to go searching, don't remember that unpleasant thing we used to do, we don't do it anymore, that's why they know how to communicate the value that is being created through these decisions . with the other developers on your team, create dashboards, create monitoring systems, watch network traffic, don't become a bottleneck, all these kinds of things are the collaboration patterns you can use to create teams high-functioning behaviors that allow these behaviors to emerge. respond to change by following a plan you have the plan but you are not married to it if the plan is wrong you make a better plan and all this there is this classic xkcd cartoon how to write good code, you know it and you can Okay, we have to do things right or fast, if you do it fast, does it still work?

No, no, no, almost, but it's a huge clutch and spaghetti code, throw it away and start again, otherwise you do it right, code it right, are you done yet? and the requirements have changed, do you know how to get good code? Good code happens when good developers look at the code and say I can improve this and they do and pretty much everything we talk about at events like this about how to build better systems. frameworks unit testing integration testing architecture what we are trying to do is empower the developer to feel confident that they can test their idea to improve it the architecture is what is expensive to change, you do it right, things will be cheaper to change. little ideas little refinements someone can open up a piece of code and that's it I think I can refactor this so it works better make it fit better buying a good architecture allows people to do this entire teams to do this for years and years and years like I said it's hard to validate it, you come back five years later and see if it's working or not if you're not moving it around a little bit, but like everything else, it's about giving good developers the ability to look at a piece of code and improve it. send it and know that they haven't broken anything doing so, thank you