OSCON – Amsterdam 2015

Sobre este curso

good morning everybody so I want to talk to you about the history really of evolutionary architecture because over the last couple of years this notion of

evolutionary architecture has been getting slightly less dangerous to discuss and when when we think about how things have gone with agile at the beginning agile was the dirty word and

then it expanded out and then it was okay for developers and then it was okay for analysts and then it took a while for protesters to realize that they didn't have to test the entire

application or wait until it was all done and we've been slowly expanding out the roles of people who are comfortable doing agile and we're getting to the point where architecture is now coming

into that sphere that people are starting to feel comfortable with the notion that perhaps you don't have to specify all of your architecture completely up front that we can do some

of these things ayrton iteratively iteratively so I want to start by talking about how this really is grounded in the agile manifesto and if you go back to the principles there are

several principles that apply and if you look at a traditional Enterprise Architect role very often they feel their responsibility is to define a technical direction and understand how

the the company is going to work together and such and this all has to be done upfront and it's very prescriptive but when we look at the manifesto we see things like how good architectures

actually emerge from self-empowered teams and there's a focus on simplicity and there's also this focus on being able to respond to changing requirements and unfortunately there are a lot of

enterprise architects and I've talked to a lot of them and very often they'll have these pesky little things in their performance criteria that that that they're judged in part on their ability

to have code be reused which means even though they're potentially disconnected from what's going on in the actual development teams they have to somehow figure out with their magic crystal ball

just what people are going to need so that they can get all this wonderful reuse they keep talking about and so that isn't necessarily set up to succeed and

what we're trying to do when we start talking about evolutionary architecture is rather than focus on being able to predict the future we want to be ready for the future so when we started this

at a whole agile journey one of the major things that made this safe was the use of continuous integration and how that allowed you to actually rather than sitting back and trying to figure out

what your code should look like you could it early leave develop it and the design would actually emerge from this process of adding something new doing the next best thing the next most

important thing that wasn't yet reflected in the code whether it was test-driven development or not but this whole notion of this continuous integration safety net allowed us to

protect ourselves from any mistakes that we might introduce and so this was really the first form of emergence when we looked at how code bases were now being developed and then we move on to

thinking about patterns in a different way initially patterns were very low-level code fragments but then there were two books that came out talking about enterprise application

architecture patterns and enterprise integration patterns and we started to think about this pattern language at a higher level than we had before at this architectural level and I know

architecture is this you know very poorly defined word sometimes it's just whatever whatever a company thinks is hardest to change or whatever a company thinks it's their most important problem

and I actually prefer that second definition because the role of an architect and different kinds of organizations is very different and what they need to focus on is very different

but when we think about how patterns started to evolve and now we're not just thinking about code patterns but we're thinking about architecture patterns and then we can start to think about how we

might evolve architectures towards a pattern just like we looked at refactoring code as a way to get to a particular pattern I think one of the more

can't intellectual achievements when we talk about evolutionary architecture is actually this notion of refactoring databases as I said you know it took a while for different roles to get

comfortable with doing things in an iterative fashion oh well it's all right for the developers to do their code that way but I need to map out the story in advance and one of the most common areas

that was really difficult for for people to get their head around what does it mean to be iterative is the DBAs the database community because when you think about how relational database

works there are all kinds of performance issues that come in when you may potentially minor changes to the database and they felt quite strongly that ok well maybe we don't have to do

the code all in advance but I need to know what my whole data model is going to look like so that I can properly set this up and we all know that even though conceptually data migration shouldn't be

hard data migrations are a mess and as soon as you've got something in production in a database if you're going to change that database you've got to do a migration and those things never go as

smoothly as they should I don't know why but they're always just harder and they get harder the older the data is or the more active the data is and so thinking about how you can actually evolve the

database was a big issue and what this book on refactoring databases put together by promotes at a log and Scott Ambler they looked at how could we actually take all of these even

large-scale changes to a database and put them into smaller refactorings and compose those refactorings together and most importantly include along with those refactorings the data migration

for just that small change and how does that help if data migrations are messy aren't they still going to be messy yes but just like continuous integration tells us very quickly when we've broken

something and so we've got a relatively small set of changes to look at when something is broken this refactoring approach to database migrations allows us to pinpoint which one of those

isolated changes was that broke the migration so it's easier to fix it doesn't take the problem away there are no silver bullets really there aren't instead it makes it

easier to fix by isolating the problem and so database structure and your data architecture which has always been a critical part of the overall architecture of a system now became much

more amendable to an evolutionary approach because you were no longer taking these huge risks on migrations you could test these migrations in smaller chunks and then of course came

so ax and service-oriented architecture is really a very unfortunately maligned term and unfortunately it deserves most of that because we it was really a good idea at the time and we just let it go

so horribly wrong because what the vision of service-oriented architecture was is that you could change your app your business processes you could change your flows and we've been trying this

for years with business business process modeling languages and lovely little doodle where where your business executive can sit there and drag things around and magically the system changes

itself to reflect whatever it is he put on the screen so we've been trying for years to figure out how can we encapsulate these pieces of business functionality to make it easier for us

to effectively reaaargh attack the system and so it was one attempt for this and then you had the debates between the soap world and the rest world and which one was actually easier

to work with and soap is actually in some ways easier to think of from the perspective of configuration and and cogeneration and such whereas rest is often thought of as

being a bit more evolutionary one of the distinctions that we draw between soap and rest is very often this distinction between orchestration and choreography and what is that distinction well on the

conductor of an orchestra stands in front of the orchestra and everybody follows along you have one single point of control and that conductor does not like it if you do not

pay attention to what he's telling you and there is actually a piece that has two very different strands to it and when that piece is performed by by orchestras they have two conductors

you've got one standing over on this side doing the one strand and another conductor taking the rest of the orchid orchestra through the other that's what it means for orchestration choreography

is much more like a dance performance the choreographer lays out their vision the individual participants understand what their role is and how they're supposed to interact at any given point

in time and what the vision is but you don't have a central source of control all of these different actors performers are independently making progress so I think given that description you can see

why restau is potentially a bit more evolutionary and we're seeing more and more attraction around rest-based architectures and then perhaps even as significant as refactoring databases is

the recent introduction of continuous delivery and what continuous delivery really gives us is the ability to safely change and just like continuous integration protected us from this more

iterative style of development where we could gradually introduce code without a huge plan in advance because the continuous integration and the test suite that we had underlying it was our

safety net for changes continuous delivery takes this from just the code level to the path to production where we can now safely know that when we deliver software that it's going to install

properly that the system is going to work and we get to now focus rather than celebrating that we didn't crash anything when we put out the new release we get to celebrate the new features

isn't that fantastic that we can actually focus instead on what it is that we're delivering a value than just being grateful that we haven't messed anything up and so continuous

delivery by automating all of these different steps and setups it allows us to be more to be more iterative with our architecture we can change things safely because we know all the environments

look the same we know that when we're going to put something in production we know what that environment is going to look like because we ran the script and we don't have to rely on some poor soul

actually getting all the keystrokes right at three o'clock in the morning so continuous delivery is a major enabler and since the advent both of cloud and continuous delivery we're starting to

see again a lot of innovation in architecture including things like micro services which I'm sure you'll be hearing about here at this conference so when we think about evolutionary

architecture then what I want you to focus on is not so much what the architecture looks like but what principles you want that architecture to display I don't want to focus so much on

maintainability I want to focus on evolved ability as a first-class citizen I want to think about the organizational implications of my architecture and take into account Conway's law which is

starting to actually come up quite frequently in discussions I have with architects we want to think about communication patterns we want to think about testability and one of the things

that we found is if you focus on the testability of your architecture you will come up with a cleaner architecture than if you don't pay attention to it so testability is also important and so

these are the principles of evolutionary architecture you want to be able to establish what you want your architecture to look like what you want it to evolve to and that's why it's

evolutionary architecture and not emerge in architecture because we have a goal we know what good looks like and we're going to continue to move the system forward until it reaches that goal State

which of course it won't because the goal will change that's the IT industry so evolutionary architecture is actually no longer this dirty word for which I'm very grateful because I actually spend a

lot of time talking about evolutionary architecture so thank you very much I hope you enjoy the conference