Traditional relational databases and a lot of database people said to us well yeah you can do all this agile stuff on the code but the database schema has to be defined at the beginning because.
It's a right pain in the neck to change so you've got to fix that you've got to go through and get a full data model I remember being in sessions where people were trying to come up with these data models but fortunately we were saved by one of our colleagues promoted algae who questioned that whole approach and said well you say the database is hard to change let's let's work on that let's try and figure out how to make it easy to change and he came up with a scheme that said well the database gets modified by a series of migrations.
Where each migration is very small it might be splitting the single field into two separate columns or something of that kind or moving a column from over here to over there and every change not just changes the schema but migrates any data within that so you have the necessary DDL to migrate the data and then that way you can change the schema steadily all the time and you might have a database out.
There in production but you can still change it to a new version by running the migrations and if you've used tools like liquid base or rails migrations or things like that you're familiar with how this scheme works now and in fact this is how we work on pretty much all our projects right if we're still doing it good but that was because of the fact that promote said well let's take something that's seen to be irreversible and make it reversible and what does that do it means that this database schema is no longer an architectural concern and it's no longer hard to change you wretched the best architects remove architecture by figuring out how to make things shiftable.
I'll throw in another example as well that of contracts between sister of different services I remember talking to somebody there was a big noise in the SOA world and he was saying well service contracts they have to be fixed upfront because they're so hard to change and immediately all my spidey bells went off and said hang on hang on that must be a problem again is what I keep mentioning our colleagues but we do seem to be a bit single-minded on this and Ian Robinson came up with a technique of consumer-driven contracts which allows you to change service contracts more easily.
So again a hard part but to get up front is to say where are the things that are hard to change and how can we make them easy to change do that and you hope you get a very big win and I'll just add in one more thing is during an inception I like to make sure that everyone in the room kind of agrees on what is hard to change there are they vary based on a lot of factors organization size capability thing things like timelines that are if timelines are really short or really pressing on the project there are some other things that might be hard to change so.
Defining that upfront and having an agreement not only from technical stakeholders but from business stakeholders and their understanding about what is hard to change and then also what might be easier to change and what might change in the future if we learn more having that up front having an idea is always a good thing to start with the next thing we wanted to talk about was stories in agile teams especially ours we write stories to breakdown function to breakdown functionality and deliver it.
Incrementally the stories are usually based on user well architecture has user value as well and change to the architecture should also be tracked and and shown what you were adding or what we're changing as we go along a lot of the times after inceptions we will have written down or documented some some spikes that we want to do the definition of spikes are exploring these things that are hard to change and figuring out.
Software systems
Maybe the path that we want to take if we have some ideas what what do we want to explore so we know is it hard to change or is it something that we can decide later at the more responsible moment and in doing this what you're doing is allowing the team to talk about what are the key things in the software system and this reinforces what I think is a very key point the architecture of a system doesn't lie in any architecture diagrams or any other static artifacts that are produced that doesn't mean they're not useful as well mention later on but they are just one representation of the architecture not the most important.
One the most important one is the shared understanding between the people in the team as to what how the system fits together Kent Beck had a very nice Ville Teske would do as a consultant he would wander around teams and say describe to me how the system works using only four objects and he said that he did that if he did that and most people pick the same or roughly the same four objects he knew they had a good coherence across the whole team but if everybody was telling him a completely for diff completely different set of four objects then he knew there was no coherence so the architecture might be written down on a diagram or something but it wasn't in people's heads and that's where the most important place for architecture is it's in the heads of everybody who's taking part in it the other thing around stories or incrementally changing functionality that deals with
Architecture is is acknowledging the fact that as you're working on a story you may be deal dealing with architectural changes not only when it's an architectural related story but something that's the new feature are creating and changing architecture is happening while you're paired programming or or just developing a new feature on your own even so thinking about architecture in in someone's head it's it's happening as you're you're going along and changing the software one of the best.
Architectural elements is something that people often forget which is example areas of the code particularly when you're starting an iteration and you're thinking about the stories that are going to be played in that iteration it's often useful to say ah you're going to be accessing the flow Berlin um system go to this module over here that's an excellent example of how that should be done well people when they writing code they often look to examples that currently in the codebase and use them as inspiration for how to do things and so.
What you want to do is to try and make sure that the really good bits are the ones that are highlighted and people copy those they don't copy the half-half attempt that you made when you didn't really understand what was going on but you haven't got around to fixing up yet it's really important to highlight the exemplar parts of the code and now actually then become very important drivers in architecture that if that's done on our teams we usually have these things that we call show cases where we are showing off new functionality how things have changed for product included in this is sometimes technical aspects of the
Technology aspects of how how the code is working this is an example of a tool called gatling which is a performance metrics tool and we showed this in some of our showcases because we want to also highlight different pieces of how the code is working how the architecture is working and in this particular project it was a very important that we have a performance that met we were replacing a system so we wanted to meet or exceed the performance of the current system so being able to show aspects of architecture and technical thinking in showcases makes it also makes us also remember that the architecture and thinking about how how we're implementing the code to solve these business problems is is important and it's important to help us not step on our own toes later on by thinking about what kinds of things we are designing for another aspect of that Martin kind of hinted on that.
I want to talk about is is what some people might call meetings but I'm going to call collaboration so on a lot of projects I've been on we do something called a mob code review or or mob code refactoring I think there are a lot of different ways that within a team you can collaborate on changing the code and if you want changing your architectural path and we've focused a lot on collaboration and talking in a lot of it we've given face-to-face examples such as inception meetings or iteration planning meetings or just the fact that that team is physically together which allows a lot of face-to-face communication and we have accent this a lot because our observation follows without from original Angeles who feel that you get the highest bandwidth and fidelity of communication.
When you're actually physically co-located for most people not necessary for all people but I think for the majority of people but collaboration isn't just a face-to-face stuff a lovely example of collaboration and a role for an architect that I came across and one of our projects was the the tech lead the architect he went sure when he booked a certain amount of time every week for reviewing code commits two or three times a week.
Codebase he wouldn't necessarily
I got remarried roughly that kind of frequency he would sit down spend a couple of hours and go through all the commits gone into the codebase he wouldn't necessarily look at in detail at everyone he would triage them a bit he would say oh yeah I know this developer he's really good whatever I know this other developer a bit more a book more iffy wow this developer here she's normally really sharp but she doesn't nobuseri.
The codebase terribly well so maybe I'll take a look here went through in that kind of way reviewing certain commits and then if you found something that he wasn't too happy with it'd say okay I need to spend some time pair with that developer and show them how I think it ought to be done instead and this isn't a face-to-face thing so much except of course the pairing later on but again it's a role of making sure that the architect is able to see what's actually going on in the project and get a sense of what's going on in there and this is.
I think a really important point because one of the things that always amused me about the traditional waterfall style is that when the architectural designers came up with a grand design nobody ever asked them to look to see if the code that was written actually matched it when it had been written and when I mentioned that to my wife the structural engineer her reaction was really surprised that well in in tradition proper construction engineering you always go and look to see if the construction people have done what had been said because half the time they won't you have to be keeping an eye on that sometimes and just out of ignorance sometimes for other reasons but it's part of your responsibility to look to see what happened.
Partly because of course you want to ensure that the plans were carried out but also so that you can learn so that you can see what worked and what doesn't work you can't disengage yourself from the process by reviewing commits the architect that gives you one mechanism to see what's actually happening on the ground and to see if some of the decisions being made early on are actually panning out.
Nearshoring developers
In practice that technique was suggested to me as something that I could do when I first started as a tech lead at one of my projects and that was also done on a distributed team but between Cincinnati Ohio and Spain with koukio.com.
India so it also is very good to in to look at commits and that will help spark different conversations between distributed teams or between two areas or several different areas I think it's it's a really good technique to use to say oh I just saw this and then that starts a conversation about about how the code is changing and and the kind of plan that you're you're working towards so come back to this diagram again and the last thing that we want to talk about is is plans are okay and oftentimes in our offices.
We have big whiteboards that are all all of the walls and there's always there's always a drawing on them whether or not it is a business process or something technical we're always drawing and revising so one of the important things is being able to change that as we go now whiteboards make it really easy but we also have to do that to communicate to external stakeholders people that depend on us maybe an Operations team maybe maybe someone that is a client of our API we need to be able to communicate what is happening internally we can't just keep everything in our heads
It's important to understand the direction but to be able to have tools now it doesn't necessarily need to be a diagram you have to find that right balance of writing something down at showing code showing something in person there's a balance there and this also can be done in a very collaborative style again a another story from one of our projects was a situation where they've been building this large code base and people were getting a bit uncle about the the way in which the dependencies between the various modules was taking shape so what they decided to do was to first figure out what the problem what the problem actually looked like and use a code analysis tool to plot out the dependencies between the major modules and they saw that and they said oh now this is a lot more messy than it should be so they then got together
In a meeting put the diagram up on on the wall and said okay what do we want this to look like and this was the arc checked on the team plus the senior developers I don't think it was the entire team because that wouldn't have fitted it fit into any of our meeting rooms but it was you know half a dozen a dozen or so of the senior developers and they ended up drawing a picture of what they felt they ought to look like and then they went out to the whole development team and said we want to move in this direction so whether whenever you're in the codebase and you see one of the dependencies that currently present but isn't in the direction but we want to head to we want you to fix it and do little fixes over the course of the next couple of months and then over the course of two months the code gradually got into the shape that they wanted it to having and then in the last week or whatever
A couple of the senior developers just went in and finish the job off and crossed off all the finalized and teams and that kind of measure can be very useful not just because it's a collaborative effort of coming up with what do we want that future to look with but the fact that everybody is engaged in moving towards that kind of position and then to make sure that things work out at the end they actually put into the build process that the ability to fail the build should an illegal dependency crop up not necessarily because there weren't any cases but because they wanted to know if anybody inserted a dependency.
that was against what was there in the diagram so that is the role the tools can play as a verification mechanism to help do that so we've been talking a lot about certain aspects of agile teams practices that a lot of agile teams have and and I want to kind of step back and say what do we see often and what are some things to kind of end on what are some suggestions so one of the things we see a lot is we have these agile software development projects that are working in an agile fashion and then we have.
Maybe this separate group that is doing some sort of architecture well we've suggested some ways that architecture is happening in agile teams and I want to call out that it's a two-way street to make sure the architecture is happening so the developers on the team in fact bas and QA s project managers we should all be talking about what what we're changing in the project how it's changing what's that impacting we should be talking to people that are external to the project people that are trying to make sure that architecture is happening so they know that thinking is happening but oftentimes we see that there's a responsibility on the team to be reporting or or asking for permission for architecture to change so it is a two-way street for people.
That have the responsibility to make sure we have a plan and some organization within our software to also participate on teams and utilize some of the practices that are happening already to gain that knowledge and help maybe draw those diagrams or communicate in the right ways by utilizing things that are currently happening that show architectural thinking we kind of been talking about how architecture is the important things the things that are hard to change the good news is there's less that is hard to change and it's getting let more and more easy to change a lot of different things.
Martin gave the example of promote an Allah questioning whether databases are hard to change and now we have the question of whether or not relational is the right thing and a lot of no sequel databases are even built in with with migration systems rails is built-in with migrations so people are adopting change and making that the norm things like environment provisioning or infrastructure as a service that these are all things that ten years ago fifteen years ago would have been in our list in an inception is hard to change so that's good that we have less of those but we still want to be important we still want to be thinking about what is important in our system.
Still want to make sure our catastro thinking is happening and it's that thinking that is really the most important thing I mean we'll talk a lot about different techniques appropriate architectures and things like that and we've done a bit of this in this talk will be a lot more of it out there in the conference but in the end the most important thing is the will to do this but you have people who care and that you give them the space and the time to do that a lot of times particularly more senior developers get really over stress and have to do a gazillion things that works you're discovering that glorious life that thought works now where there's so many different things you could be doing and you always of course want your best most experienced people to be doing that fact but it's important from the whole project management side to make sure that the senior people have time to think about architecture there are various ways that you can do that and the technique of setting aside time for commit reviews that.
I mentioned earlier on is one case of that another example that I've seen on a few projects is saying that although that the developer the the architect is pairing on stories and taking part in the programming they're never allowed to sign up and be responsible for a story's delivery they always have to help other people as opposed to actually taking that role themselves and that also is a technique that allows a certain amount of provision of time because in the end it's that time and will that is crucial because like so many other things in software and getting a good architecture for your system is primarily a people problem so with that we want to say thank you for listening to us we hope that you have a little bit more context around different things that are probably happening on agile teams and how they can be utilized to show and demonstrate architectural thinking and to enable those that are already.
Thinking about architecture on your teams and if you want to talk to more about to us at all about what we've been talking about we'll be hanging around the footworks booth most of the time I do have a book signing at the Pearson booth for the room 10:30 today but other than that I'm going to be around the footworks booth during the breaks and of Cour turning lots of talks and Molly is going to be doing at an interesting contest between microservices and mana lifts I'm not quite sure which side you're on so that grand debate is going to be later on today I think you should find that quite interesting if you find that discussion absorbing and thank you very much