 Michael, do you just want to let me know when you're ready to go? Okay, cool. First of all, thanks very much for coming along to ThoughtWorks Singapore and TechTalks. My name is Patrick Qua, and I'll be talking about the topic about introducing evolutionary architecture. So, I'm actually a consultant that works for ThoughtWorks in London, and I'm visiting Singapore for a couple of weeks, so it's very nice to be here, and thanks for coming along tonight. If you don't know about ThoughtWorks, you might know a couple of our sort of luminaries. So, we've got Martin Fowler and Jim Highsmith, who are both agile manifesto signatories, and some of our work that we've produced includes the continuous delivery book and the Lean Enterprise. Probably what's maybe more of interest to you more directly is actually our TechRadar, and our TechRadar is our kind of view of what we're seeing with clients around the world, and we've actually just released this two days ago about what our current view is. So, we kind of do this on a sort of biannual event, and it's kind of a view of what we're actually seeing. It kind of is this idea behind what we actually see that's helping clients, what they're sort of starting to assess, and also what are the things that they are sort of saying actually it's not so good, therefore we should put a hold on that, and it kind of covers quite a broad spectrum of different types of things, including techniques, including platforms, tools, and because we're in technology, obviously a lot of languages and frameworks. So if you're interested, there was the URL that was on the previous slide, and there were a few booklets that were going around, but you can probably talk to anyone that's wearing sort of a ThoughtWorks shirt and learn a little bit more about the TechRadar. But I'm going to talk to you about sort of evolutionary architecture, and one of the reasons I want to talk to you about this is I guess in my history, I do a lot of training of new sort of architects and tech leads, and part of this is actually starting to help people understand sort of a newer way of actually approaching architecture. So I've done quite a lot of work with different clients around the world. I've been working with ThoughtWorks for about 13 years. I've seen a lot of different industries from say finance, travel, retail, sort of all types of sort of company sizes from sort of startups to large corporations, and it's quite interesting when you actually look at how people are approaching architecture, particularly as more organizations are adopting agile over the course. There's going to be a book around this, and I'm actually working with our CTO, Rebecca Parsons, and Neil Ford, who actually talks a lot about this sort of topic as well, and we're hoping to get the book out probably end of this year, or at least sometime this year, depending on how reviews go, but I want to sort of talk first about why we actually picked evolution, and really it's kind of an interesting metaphor if you think about biology and evolution because a lot about evolution is actually about this idea of change, and the fact that when we actually have sort of our environment around us, things are constantly changing, and so this kind of helps us understand that this idea that change is inevitable. So I don't know how long people have been in the IT industry, I've been working in the IT industry for about 15, 16 years, and when I first started, the landscape of technology is completely different from what it was when I first started. Even in the last couple of years, we've seen a huge bunch of changes to sort of the environment, as well as the technology landscape, and it's kind of interesting when you think about, well, where will we be in five or 10 years? It's going to be really different, and there's actually two types of change that we actually really care about. When we think about software, we're often very focused on sort of the technology space, right? We often think about the tools, the frameworks, but actually when we actually build software, we need to think about these two types of changes, and we can kind of roughly talk about them in terms of both technical and the domain types of changes. We'll explore what sort of changes that we have in both of these. In the sort of technical landscape, which is the one that we're most familiar with, we're probably quite familiar with new programming languages. If you scale back to, say, 10 years ago, Java was probably like the new thing. It was kind of replacing C++ and C, but in that sort of 10-year period, we've actually seen a proliferation of many other languages, .NET, C-sharp, F-sharp. In the JavaScript world, we've seen sort of TypeScript come out, ClosureScript, more sort of functional programming languages like Scala and Closure as well, and it won't be the last of it. We'll see more programming languages as they come. And that's kind of an interesting dilemma for us as sort of software developers or architects. When we're thinking about supporting change, we have a whole new platform, whole new set of programmers that need to know that programming paradigm. That means that we have to support that and make that easy to change. Alongside programming languages, we also have a whole bunch of libraries that come along with it. And I think this is actually a huge shift in our industry probably in the last kind of decade as well, because we're benefiting from sort of open source sort of sharing, right? So if you sort of fast forward 20 years ago, or rewind 20 years ago, a lot of these sort of libraries were actually closed source. Everyone would have to go about rebuilding their own sort of collections library that would have to go and do this because it was all proprietary. Now, we actually get to reuse a lot of this, and it's actually kind of interesting because there will always be new implementations of libraries to solve different types of problems. Alongside libraries, we also have a whole bunch of frameworks that come along with problems that we have. So probably in the last kind of sort of eight years, we've had a lot of MVC or web frameworks. We're seeing a lot more probably in the last five years around JavaScript, web frameworks in particular, with sort of single page applications. As we go to sort of more mobile type things, we're also seeing hybrid frameworks that try to help us support those things. And as the sort of platforms and environments change, we end up with newer frameworks as well. But what does that mean when we actually need to support new frameworks? Alongside this is we also have a whole bunch of tools that go along with all the different sort of environments that we have. So if you think about sort of build in infrastructure tools or deployment tools, there's new things coming out all the time. And if we want to stay up to date with the current sort of latest tool, we have to be aware about the decisions we make, about coupling ourselves too closely to our existing tools that we choose. We also have seen a huge change in sort of operating environments, right? So if we actually think about servers operating systems, we actually don't even think about really acquiring servers a lot, physical servers these days. A lot of people are actually thinking about we just have a cloud account, and we create new servers as we need and call them on demand. And that actually shifts the paradigm about the things that we actually care and worry about. No longer is the lead time for requiring a server months because we have to get data center space and install these physical boxes. For some companies, it's still a constraint. But for others, it's not. And actually, we're actually moving to a different space as well where we're moving towards more serverless architectures where instead of renting boxes, we actually rent our processing space and time. And that will actually change the way that we need to architect our applications. We also have a whole bunch of sort of technical constraints that are actually changing around us. I think if you're here in sort of Singapore, my perception of the country is it's small but dense, right? There's a lot of infrastructure here. And one of the benefits of a dense country like this is that you actually have huge capacity to have big broadband and high speed networks. In other countries, that's not true. So I grew up in Australia. And if you live in the middle of Australia, you don't have the same operating broadband speed, right? People are still on sort of very slow DSL because it costs a lot of money to actually roll out network. But over the last 10 years, we've seen a lot of changes to this space as well. So if you think about how fast your mobile speeds are with internet, it's only going to get faster. And these things will change as well. So there's a whole bunch of technical changes that we need to think about. And it can be kind of overwhelming. Unfortunately, it's not the only ones. We also have to think about the environments in which we build software and how this software gets used as well, which is about the domain. So around the sort of domain, and I don't know how many people here are working in the product space. But there's lots of changes around this that you're always worried about because our environments change as well. So a good example is about revenue models. If we think about how software used to be sold, you used to buy a box on a CD, maybe a floppy disk of some sort. You have to physically install this and you go to a store and actually buy this. We've sort of moved on to we actually download software and we buy a license. Sometimes we don't even do that anymore. We just pay a rental fee. We sign up for a subscription and we pay a monthly fee. And that's changing the way that we actually need to think about our software as well. Because businesses are businesses and they want to make money. And so our software actually has to understand how we're actually going to account for money if we're going to have to track usage. We've also seen a change in base technology adoption. So I was talking about sort of broadband before, but even the adoption of smartphones is quite a big change. We have an office in Johannesburg in South Africa and I visited it there last year and it's kind of interesting because you talk to people and the types of technology there and the rates of adoption are quite different there because the constraints in their environment is really different. So you've probably been frustrated with your smartphone because you didn't get a whole day with a full charge, right? Now in South Africa they don't actually have or in the African continent, not all countries are lucky enough to have energy everywhere around them. And actually you don't have the same rate of smartphone adoption because people want a phone that will last for two weeks before they can get to a point where they can actually recharge it as well. And so as infrastructure rolls out we'll actually see changes in the way that technology gets adopted as well and that will drive the software that we need to build to support the infrastructure and the technology that people are using every day. Naturally with all sort of businesses and markets there's new competitors turning out every day, every moment, right? I believe at the moment the world is sort of going through a bit of a startup phase. There's a lot of investment and new exciting kind of companies with new ideas and it's not going to slow down any time soon. So we've gone through a couple of dot com booms and busts but it won't be the last one and this means that we have to keep on our toes and we have to help our businesses actually innovate as well. And with new products we actually have different customer needs as well. So we always have people that have higher demands and if you think about how sort of shopping on the internet used to be many, many years ago, we were quite happy with very terribly designed web pages but now we probably have very high demands about the user experience. We want things that are easy to use. We want things that are easy to understand and that means that we have to actually architect our software to support this as well and to be able to adapt to the changes of customer needs. We've also seen a huge change in the types of markets that are actually coming out as well. So a couple of really good examples that we're actually seeing around are things like 3D printing, blockchain technology and also internet of things. And each one of these new markets means that as software developers and architects we actually have to think about how are we going to change software so we can support these new devices and new markets and actually respond to change as well. And actually with new markets you have new products as well. So even in your company, in your industry, the product portfolio will never stay constant. People will always want to have a new product to entice and attract new customers and it won't be the last of it. So it can be quite overwhelming but the fact is that change is inevitable and when we're actually designing our applications need to understand we can't avoid any of this. We have to recognize and embrace the uncertainty that our technical landscape will actually change. The markets in which we work will actually change as well. So if change is inevitable what does that mean? We actually need to then think about, well, instead of thinking about our plan, about what we'd actually like to have, we actually need to anticipate that there's going to be a myriad of paths of which we can't really predict where we're going to go. So we can pretend that we have a 12 or 18 month roadmap of what we plan for our systems but in reality if the business shifts where they want to go or if some new technology comes onto the market we need to be able to respond to this really rapidly. And so actually this changes our idea around how we approach architecting systems. So we need to sort of stop thinking that we can actually project all the things, come up with this master plan of systems and pretend that this will be the ideal target state in 18 months. And to sort of drill into this point I want to talk about a case study and this is actually a case study that we see with sort of customers all the time, it's a bit of an archetype. So we often sort of get involved and this is kind of maybe the path of why we get involved. Our customers, maybe in a particular industry, have gone out to maybe approach new products of some sort. So there's a new business goal that the market actually wants to achieve. And a good solution architect will actually go and talk to the business, try to understand what the business needs are, what capabilities they actually have. So they're talking to the market, they're trying to understand what the customer needs are. This sounds very sensible. We're trying to understand what type of system we need to build, how many users we need to support, what sort of features we have. And then they sort of start to put together sort of a shopping list of different types of features, different types of capabilities that the business would like to have. This all sounds very sensible. Now, every good person wants to deliver value really early. And what's very common is people end up going on a sort of shopping spree. So they look for products that kind of map to these capabilities that they're looking for. And they look for a way of sort of putting these products together because they believe it's going to be the quickest way of actually delivering the value that the business would actually like to have. And like all good things, people are concerned about change. So they're thinking about, well, what's the best way that I can actually support change? I do definitely want to acquire these products, but I don't really want to be locked into them. I need some way of sort of connecting these products together and allow me to sort of configure maybe a different workflow, different business rules depending on what my business would actually like to have. And a very logical step is people would like an enterprise service bus to sort of connect these disparate products together and to be able to sort of constrain what things can actually change. So this all sounds really good. They put the plan together and they get budget approval. They sign contracts for three years because that's what the product vendors need. And then the work starts. So they get teams together. You have multiple teams from multiple vendors starting to customize their products. And maybe a year later, one of the product vendors might actually be done. And the solution might be ready to use. So some of it's actually working. But in that time, a year's a long time, things have actually changed. The business no longer want to do what they actually set out to do. They've actually changed because the market has changed. The business needs have changed. They haven't seen any returns. And actually now we're in a dilemma because we've signed these contracts to actually deliver these products according to these time frames, but the requirements have changed. So this is OK. We can support change. But you go back to a vendor and you ask them, you know, here's the original contract. We'd like these customizations changed. That's OK. That will cost you. It's a natural thing, right? Change means cost. But the problem with this is the vendors are not just supporting one sort of customer. They're actually supporting multiple types of customer. And in order to accommodate your change, you actually are going to have to wait for their schedule until they can actually create the time that they can work on your change. So you may not even be able to get the change for that business in the sort of time frame that you want. You might need to wait another six months before you actually get the change implemented. And this can actually take a lot of time. And this is OK. So even if it delivers what it does, the business will get eventually what it wants. And maybe they end up delivering this sort of product into the environment. But now, fast forward, this is maybe 18 months of sort of different types of work, integration. What normally happens is things are in production. The business starts using it. There's a whole bunch of unexpected behavior of what the business didn't want. So anyone who's worked on a software project knows this is exactly how it goes. You work on something according to how business people have said what they want, and you show them the working software, and it's not really how they wanted it. Now that they actually look at it, it's actually, that's not what I meant. I actually wanted this. And it's only once I actually see this final product can I actually say, actually, what I really wanted was this. And one of the problems with this sort of product approach and integration is that you only really have one environment in which this is all working together. And that's production. And so when you actually make changes to this environment, it becomes a precious environment where any changes can actually disrupt the entire business because there's no safe way to actually make changes. And so change becomes really hard. The business constantly want change because they're actually now using this product. They're onboarding customers. They're now working out what their customers actually need and asking for more change. And that's becoming really, really hard, slow, and costly. And often what normally happens on these sorts of programs of work is that the business get fed up with the way that IT is actually dealing with this. And I want to start again. They call a digital department. And they often call us in to help work out how they actually purchase from a different perspective. Now the intentions of the people who set out on this sort of program of work were really well intentioned. We want to understand what the business needs, understand how we can deliver that really rapidly, support change. But we need to not do that just once. We need to do that multiple times. So the question is, what is it if we architected a system where change was the key thing that we actually cared about? And this is bringing us back to the topic about evolutionary architecture. How does that change the way that we approach architecture if we make change that fundamental element and core? So as I said, we're working on a book. And this is kind of our working definition of what evolutionary architecture is. So an evolutionary architecture is one that supports guided incremental change as a first principle among multiple dimensions. Now we debated this definition quite some time. And we're kind of stepping a little bit away from the biology metaphor in that in evolutionary architecture it is guided because you, as your sort of business or sort of architecture element, you want to actually guide the shape of this. In reality, biology kind of throws randomness and then hopes for a right sort of product. We don't have the time for that. So we actually guide our architecture. What's really important is that we also go through incremental change as well. So we actually want to make sure that we take increments and change our architecture and the features to test the ability to change over time. And it's really key that the architecture supports change across multiple dimensions. And this is thinking about not just the technical dimensions. So not if we're going to replace the database or if we're going to replace a library, but actually meaning to support business change as well as technical change and not just trade one for the other. So you may think, well, we have architecture that supports change. Well, we'll have a look at a few. We'll question whether or not these architectures actually support change in multiple dimensions. So some of these architectures that we'll look at are maybe your classical big ball of mud or your monolith. We'll have a look at layered architectures. We'll have a look at microkernel. And lastly, we'll look at microservices. And we'll have a look at each of these through a dimension of understanding how well does it actually support change. So let's have a look at our big ball of mud. So this is actually from a client of ours where we did a visualization around which classes in a system, which are the edge nodes, calling another method on another class. And as you can see, the thicker the line, the more calls that one class was actually on calling to another. And you end up with a big ball of mud. So this is a really poorly designed monolith. And I would say that you can actually design monoliths that don't look like this. But this type of architecture doesn't really support any types of change. So if you're actually trying to change a framework or something, you probably start to work out, oh, there's 300 places I need to touch in order to update this framework. And it's not really clear to me where I actually need to do that in the code base. I have to go through all the code looking for references to this sort of framework in order to start to work out how to replace that. OK, so not a great sort of architecture. Try to avoid if we can. Our laid architecture is your classic kind of thing that looks really nice on paper. So in this kind of classical tiered architecture, we have our presentation layer that is maybe responsible for rendering. So it might be in JavaScript, or it might be HTML. It might be iOS type stuff. You have a business layer, which is kind of the things that is responsible for your sort of logic and business. You have a persistence layer, which are the things that are responsible for mapping it to some sort of store. And then you might have a database or a file system where the persistence layer is kind of supporting things. So if you actually want to change something, say you want to change the way that you render your application. This is kind of a nice architecture because you actually just focus on where your presentation layer is. Say you want to actually change your implementation of your database. Where do you go in your code base? Well, you kind of know that because it would be this persistence layer. And if it's really well structured, none of these other two layers would actually have to be modified. So from this respect, this is actually a thing that supports from a technical perspective OK in a single dimension. Now, one of the things that we often see with this kind of application architecture is that we like to be really consistent, right? In that if you're an architect, you kind of want things to be consistent so that when the next person comes along, everyone knows how it kind of works. And so in this kind of model here, when we actually need to create a new sort of layer, or create a new sort of feature, we actually have to touch each of these different types of layers. So even if we have to put a field onto a screen, there's no real business logic. We just have to capture information. We actually have to go through each of these layers because we want to be consistent. And so even though we don't actually want to make business change, we're actually forced to add in an extra change to this sort of code base because of this level of consistency. And this is actually making it harder to actually support new business change because we're adding an extra work when we didn't need to. So a slight modification of this, which is giving up consistency to make change a little bit easier, is kind of this layer where you're kind of inconsistent. You can jump through layers. So in this example, we might actually jump over the service layer because there's no need to actually do anything in that. And that's OK because we can support business change a lot faster in that respect. So some classic examples of frameworks that support this architecture are probably your Spring, Ruby on Rails. There's many other examples out there. And a lot of people use this. There's nothing necessarily wrong with it. Another architecture here is your microkernel. So microkernel is this idea where you have kind of a heart or an engine, which is the sort of core part of the system. And that core system allows extension points through specific plug-in interfaces. So you can sort of add in extra behavior to this kind of architecture. And this kind of approach to architecture can actually help with change if you really clear about what type of change you want to be able to extend. So from a technical perspective, if you want to add in new behavior, you can actually do things in that sort of plug-in. One of the problems with this sort of approach is actually if you want to make some core changes to the core system, so you want actually to support some business changes that the core engine doesn't really support, you can't. You end up doing some funny workarounds of trying to do things on the side. And then you have to sort of work around the core system because this is not designed for that sort of change. And we see this all the time when people, say, want to build a rules engine, or they want to build something on top of a product, that it's fundamentally not made to do. And they end up adding a lot more complexity because the core engine doesn't really support it. So if your business capabilities map really well to the core system, and you might want some sort of changes on the side, this type of architecture might help you. But if you are not really sure what the core capabilities will be over time, and those things will really shift, it's going to be really hard to use a system like this. And you end up with funny workarounds in order to get things done. So some good examples about tools that use this kind of architecture. Things like Maven, which is a build sort of system. Eclipse, which if you're a sort of developer, you're probably familiar with. And Firefox as well, right? And so if you're building something that's kind of like a web browser and you want to be able to customize it, some people use Firefox as a container to be able to do things and to extend it through its sort of plug-in system. But it's still fundamentally a web browser. And if you actually want to do something really different, so you want to build a mobile application out of it, install it onto a sort of Apple or an Android device, you're going to go to a lot of complexity in order to be able to do that because your microkernel architecture just fundamentally doesn't support that. Doesn't mean you can't, but you're going to add in a lot of extra complexity which slows down change as well. And actually this is one of the problems that I hear a lot with Maven as well. So there's kind of two camps with Maven's users. There's like people who like it and people who adamantly hate it. One of the reasons that a lot of people hate Maven is that once you get to a very complex system, it's very hard to change the build life cycle of Maven because it's a fixed element of how the core system works. So if your project looks like an Apache project and that all you're doing is kind of building a single artifacts and it needs to sort of compile and test and then you create your artifact, that works really wonderfully. If you end up with a multi-module application with lots of different deployments, need several levels of testing, you end up doing funny sort of workarounds of overloading the Maven life cycle in order to add in your extra behavior just because it's fundamentally no concept of that and you can't change it because it's part of that core engine. And so it doesn't mean you can't do any of that change. It just means that the extra change that you have is a lot more complex and it doesn't support that sort of change. So we'll have a look at maybe a domain sort of level of this as well. So we won't go through each of these architectures but we'll have a look at the layered architecture. So we have this kind of nice tiered layered system and let's say that the business actually want to change the way that they actually do their pricing. So they now actually want to track something about transactions. They actually want to understand usage and then they want to actually bill people for a different sort of use of that. Where would they actually go in this sort of architecture to actually go and make that change? You say business, it's kind of a bit all over the place. So they're going to have to track something maybe about transactions and create a new space here. They probably need to actually track usages through some sort of application and they probably need to have some interface to be able to report on this now. And so there's no one clear place that you'd actually go to to actually make this change. You kind of still have to go through all the tiers in different places. And so from a domain perspective, actually as a developer you kind of have to understand the entire code base to understand what things might be affected by this. And so it supports the change from a technical layering perspective but this kind of architecture doesn't really help support people from a business perspective. And this is maybe one of the reasons we actually see a lot more popularity with microservices today. And there's a lot of complexity about microservices. This isn't supposed to be a microservice talk but if you do microservice as well, one of the ideas behind it is that you kind of focus on very business driven encapsulated services such that each service is representative of that sort of business entity. And within that sort of service, you don't get services talking to each other through databases or through sort of other reusing libraries. You get each service to talk through a well-defined sort of API so that you can actually make changes as well. And one of the benefits of this is say that we actually need to change the way that our customers get persisted. So instead of storing things in a relational database, we actually want to start to understand the relationship between customers. We want to use a graph database. And one of the benefits of this approach is if people are talking through the API, nobody needs to know about changes to the technology stack. So actually I can actually swap out this database for a graph database without affecting anyone else in the system. And because I know that it's actually attached to customers, I am sort of encapsulated within this one spot of the architecture. And so this kind of style of architecture when done well actually supports change in a couple of different ways. We can support new technology at an incremental level. We can choose the right tool for the right job. And we hopefully can actually understand business change that is only affecting one part of the system at a time rather than everything. So we can go back to our definition of an evolutionary architecture supporting guided incremental change as the first principle among multiple dimensions. And hopefully you're starting to get an understanding about what it looks like. I guess maybe the next question is, well, how do you get there if that's what you really want to get to? And this is where we're going to explore a set of principles. And like all good things in software, we actually need to balance out not just the technology needs, but also those business needs. So we'll have a look at some of these principles from our technical and domain perspective. The first one is that the technical sort of constraints of our system should never, ever dictate schedule of change. So whenever the business actually wants to make change, we should be able to release that really rapidly. We can't say to the business, I'm sorry, we have to wait until we upgrade our database before we can actually do a release. And three months later, we can actually do a release. So if you're doing this well, you can actually release whenever the business needs change so you can support them in those changes that actually need to. In order to do this, you actually need to be able to support fast feedback as well. So when you're actually looking at tools and frameworks, one of the things that you'd be looking for is really how fast does it affect your ability to get feedback around confidence of things working and also just speed of development. And for me, this is actually a real key killer for some tools and frameworks. So if I think about an average developer cycle for some tooling where you need to use a proprietary tool to deploy into an environment and then that takes, say, three or four minutes, a single line of code is going to take three or four minutes each time as well as then maybe training to understand how to use that tool, that's just going to slow down the entire development cycle overall. It's not supporting fast feedback. So I'm always looking at the tools and frameworks that I use to understand, do I get fast feedback in the things that I'm actually using? We also want to look at appropriate coupling. Now, the hard thing about software is that we can't avoid coupling. So we always say, OK, we should have low coupling. But in order to have something useful, you have to have some level of coupling. Things have to be connected somehow. And the difficulty with appropriate coupling is trying to find the right level of coupling. So when we looked at that big ball of mud, that was clearly inappropriate of so many points coupled together. And this is where actually our fundamental understanding about how we model and review architectures for coupling can help us reduce and improve this to a minimum level. Another principle that we should actually follow with architecture is that it should be iterative. So it's not enough to sort of say, here is my grandmaster plan, and that's all that there is. The difficulty about building systems, particularly from scratch, is often the planning process is when you're actually making decisions where you have the least amount of information. And so when you actually take an iterative approach, what you're trying to do is actually accelerate the amount of information so you can make better decisions and test the validity of those decisions against real data versus some assumptions that were made 12 months ago. Now, if we look at some of the domain perspective, we really want to match business capabilities. And so this is the idea about that cohesion side. And we'll talk about that in a little bit. We also want to be able to enable experimentation. So if we're actually going to be able to understand change, we actually want to be able to make change really rapidly, but also be able to undo change. And so when we're actually thinking about tools that sort of commit us to a path of doing things without a way of reversing that, that actually is preventing us from being able to experiment. And so we're looking at tools, whether or not they actually help us make change easier and whether or not we can actually reverse decisions. Now, this kind of approach actually requires quite a different governance style. So I work a lot with sort of client architects. I've worked with quite a lot of banks and I believe that there's quite a lot of banking here in Singapore. And one of the sort of challenges is this idea of very centralized governance, often meaning that architects are the people that make decisions. We'll talk about how you can do governance without having it centralized and fixed. And the final thing is really understanding what is your fitness function for the system that you're actually trying to build? And we'll explore this right now. So what is a fitness function? So the fitness function is kind of the thing that we want our system to match, whether or not we know the evolution of our system is going in the right direction. Now the difficulty with this is that it's very different depending on the type of application and the domain that you're actually working in. And so one of our first jobs as architects is actually try to work out what is the fitness function for the system that we're building. And so at the very beginning, we should be looking at some of the characteristics of what we actually like from our system. Sometimes these things are called cross-functional requirements or non-functional requirements or quality attributes. And we should be trying to understand which ones are the ones that we actually care about for the system versus which ones we don't. And as part of this, we actually want to understand then these are the success criteria around each of these types of attributes that we actually care about. Now, one of the unfortunate things about people adopting agile is we kind of throw out the baby with the bathwater and that architecture is not often talked about in sort of agile sort of software development, but it's still a very important characteristic of thinking about what are the things that you still need to support overall with what you're actually doing. But one of the key things with this is not just simply saying that these things are important. It's actually turning them into something that you can try to evaluate as well. So when you actually start to classify these things into the important versus non-important, we actually want to start to create some metrics around these things, maybe some tests. So there's quite a lot of things that you can actually do for testing these days. So we've got a lot better with sort of automation tools that we can actually do performance testing quite well. We can actually even improve security testing as well. There's a lot of automated tools that scan for typical security problems. And hopefully we can actually quantify some of these things. Some of these aren't actually necessarily quantifiable. So if you're thinking about usability, you can sort of do usability testing, but it's not something that you can really get a number out of each time that's consistent. But it still means that you should be doing that if it's an important characteristic of the application that you're building. And one of the reasons that you actually want to do this is that as you make changes to your system, you want to test those changes against the existing fitness function. And if there are tools and sort of decisions that you make in your system later that affect your fitness function, you probably need to make different decisions, right? It's about earlier feedback around that. But the hard thing is that these things are kind of the known knowns. And so these are the things that we should be able to predict as architects and think about this a little bit up front. But the difficulty is there's also this whole thing and Donald Rumsfeld is really a good example of this. He said, there are known knowns, but they're also known unknowns, right? So we know that there will be new programming languages. We know that there are gonna be new libraries and tools. We don't really want to box ourselves in too much to the current version of these things because we know we're gonna have to upgrade. If you have ever worked in a system for years, you know you're gonna have to make sure that you upgrade to the latest versions of these things because they're solving performance problems, security problems, or just bugs. And so you don't want to couple yourselves too tightly to these things, but we don't really know when these things are gonna come or if we're gonna have to adopt them. So we want to be aware that actually we can plan for them. But there are also unknown unknowns. So there are whole bunches of things that we won't ever be able to predict. So for people who can't see it, it says psychic fare canceled due to unforeseen circumstances. Be ironic. And one of the things that this sort of teaches us is that if we're actually gonna be able to experiment, we need to understand that there are things we can't predict. And Docker is a really good example in that if you think about three years ago, Docker sort of came out of nowhere and it suddenly become this huge thing around deployments. And it's one of those things where actually nobody could really predict it was gonna be a really powerful thing. Serverless is probably a more recent example where nobody really could have predicted it, but actually now we're seeing a lot more of it. But what does it mean for companies and application architects who've built things assuming that there will always be servers? And so this is where you actually have to be thinking about how you support these types of changes and you can't predict all of these things. Now when we actually think about sort of software and this idea of evolution, what does that actually mean for us? This is the idea of probably generations, right? So in a biology and biological metaphor, in order for a generation to happen, you kind of need sexual reproduction. So you need sort of animals mating and that will sort of generate the next sort of offspring. And what you end up with is slight variations of that sort of genetic sort of mixture and you end up with maybe a different type of animal generations down the line. Now in a software sense, we don't really have sexual reproduction of software, right? But what we do have is actually the ability to make changes to software and get it live. And so actually our version of generations is actually our ability to get software out. And so if you think about how fast, how many generations can your software actually support? Is it two times a year, six months? Is it three months? Or is it in the order of days or hours? And so when you're actually thinking about how you can actually make more generations of software, this idea is actually about cycle time. And this is really about the time taken to get a change into production. So your generation of software, you do not know if it's successful until it's live, until users are actually using it. And so this will be your bottleneck in your constraint of whether or not you can actually test your architecture for change. Now it's really important that you think about cycle time and reducing that, but it's not only just about reducing the cycle time, it's also about being able to do this in a repeatable, reliable fashion. Maybe this is resonating with a few people, and that's probably because a lot of these ideas come from the ideas of continuous delivery, right? So continuous delivery is about really the idea of getting software into production in this repeatable, reliable manner. And that's where a lot of the practices that come from CD actually work really well with evolutionary architecture because they're supporting our ability to make changes. It helps us make a change and get it into production to test that change as rapidly as possible. Therefore, they're kind of natural partners in being able to build evolutionary software. The Phoenix Project is also a really good book that kind of talks about the last mile. So often it's the operations mile, which is one of the difficult parts of actually getting software live. And the Phoenix Project is a really good sort of business novel that talks about how you do that and collaborate well. So if you know about sort of DevOps, that's kind of one of the really good books that sort of talks about how that can actually work in production. So evolution, we should think about generations, increasing or reducing cycle time so we can increase the number of generations. One of the other things that we should really care about is actually about Conway's law as well. So how many people have heard of Conway's law? Not so many, okay. So Conway's law is this. I'll let you read it for a sec. So as you can see, it's actually quite an old law, 1968. And the observation still holds true. And we see this all the time with the way that sort of organizations and architecture work. So basically what it's saying is your organizational structure will affect how your software is built and designed. There's no going about that. And so if you want your architecture designed in a certain way, you should be thinking about how your organizational structure affects that. A really good example that we often see is this idea of specialists, right? So we have a whole bunch of UI developers. We have a whole bunch of middleware or middle tier developers. And then we have a whole bunch of DBAs. Now what does this look like as an architectural style? This is pretty much your kind of three tiered architecture manifested, right? In that UI people need a certain API to talk to because they don't talk middleware. And so you end up creating a very rigid interface between your middleware developers and your UI specialists because they don't want to have to always make changes all the time, right? Change across the groups becomes really hard. So you end up with very rigid boundaries across that. Now what this means is that actually when we're actually thinking about monoliths for our microservices, we can actually take advantage of that. So you don't even need microservices to really go down this path. But one of the benefits of this is thinking about Conway's law and architecting your organization such that you want to architect your product. So if we go through our system and how we actually want to work, we want to think about the skills that we have and organize them around the way that we actually want to architect our system. So if we want a three tiered architecture that's really rigid in those layers, we would want an organization that kind of looks like this. But if we actually want sort of responsive change to businesses in an area where people can evolve their tools as well, we actually want a different type of architecture as well. And so actually this is about reorganizing people into sort of cross-functional teams that are more focused around these kind of business areas. And this is what we call the inverse Conway maneuver. Now it's probably quite hard depending on where you are about if you can actually influence your organization. But for the people who actually have the ability to influence the organizational structure, they should bear in mind that this stuff is affecting how well your systems are architected. And therefore if you want systems to be easy to change, you kind of want to think about how your organization structure is organized such that you match your technology capability as close to the business capability as quick as possible. And this is really about thinking about if we really want these cross-functional teams organized around business capabilities, this is one of the best ways of actually creating this evolutionary change of being able to be as responsive technically to the business domain as things are actually changing. And this is all because of Conway's law. And another view of this is actually thinking about it from domain-driven design. So domain-driven design talks about this idea of bounded context. And this is actually another good example where this is actually domain-driven design's bounded context in reality. So if you think about how businesses work, you still have departments of some sort, but often they're around business capability. So you might have marketing or product people, or you might have product lines. And actually between the product lines, they don't really talk to each other. They might have some type of common language, but actually customers for one product, they only care about their customers for their product. So they want special needs for that particular product. And that's where you actually want these kind of areas responsive to that business line as much as possible. And that doesn't mean you really want to sort of suck out all the sort of common functionality across all customers in a single place. You want that view that's as close to the business capability in their terms as much as possible. And one of the things that really helps with this is actually the way that people create budgets and the way that they spin up software. So this is the idea of products and not projects. So one of the problems with sort of this idea of projects is that you have a team that's working on a goal, and often what happens in a sort of project-centric model is that sort of team gets disbanded, and then they work on a whole other new project. And one of the costs of this is that we want to save some knowledge, and the normal way of doing this is actually by saying, okay, before you finish you have to write everything down. And in the process of writing everything down, you lose a lot of history as well, right? So you don't know what information the people coming along next will actually want, and you have a whole bunch of skills and knowledge and experience that is suddenly lost, disbanded, lost into the other. And this is actually where we're seeing a lot more sort of companies use a lot more success around longer-lived teams built around a product. And this is actually really, Amazon's You Build It You Run It style, where that sort of long-lived cross-functional team understands the implications of the choices that they made, and they get to live with it, but they also get to change it because they understand the business part really well. Now when we're actually thinking about making decisions, one of the key ideas is this idea of the last responsible moment. So as I said before, often what happens when we go on large sort of programs of work is that you're forced to kind of make decisions very early when you have the least amount of information. So one of the games that we need to play as architects is actually a game of collecting information as rapidly as possible to test whether or not our assumptions hold true or not. But also, if those assumptions hold false, we need to actually be able to reverse those decisions as much as possible. And so we actually need to be thinking about architectures and patterns that allow us to reverse decisions such that we're not coupled to a particular tool or framework at the heart of our system. And one of the ways of thinking about it is that if we have some code using some library, it's often very easy to sort of stick those things wherever it gets used. If you're in a framework, it's easy to stick things into that framework. So anyone who's done the Spring MVC or Rails app, you see a lot of things stuck into controllers because that's how it's done, right? But often what happens is that you might need to make a change in a business layer that needs to be cross-cutting. And then you have to extract that out and it takes a lot more effort. And this is where it makes a lot of sense to actually think about the adapter pattern around thinking about not sort of calling that thing directly, but actually having a simpler representation that the rest of your code is calling and then that one thing is dealing with the complexity of dealing with the sort of external interface. Now, if you apply this to a application over time at all the particularly external points that might actually change, you end up with a pattern called ports and adapters or hexagonal architecture. So a good example is when you're actually thinking about external dependencies, those external dependencies will probably change. So we're thinking about analytics, APIs or a web service, some sort of external service that we depend on, even maybe a physical installed product, each one of those dependencies may change because they become too expensive, they get outdated. So actually when we make that change, we hope that there's only one part of our system that we need to go to make that change and that should be the adapter for that element. Now, one of the other side benefits of taking this approach is that when you go down this path, your system becomes a lot more testable as well. So when we're actually thinking about humans being a simple interface to our system, if we actually have an adapter that represents how they interact with the system, suddenly we can actually automate that by writing something that simulates the interactions of how a user would actually interact with that application. And so our system becomes a lot more testable that allows us to get more confidence around the changes as we make them. But there is a bit of a warning around this and I think this is where it can be sort of a bit misapplied and this is really not an excuse to abstract all the things, right? So you can get a little bit too carried aboard around thinking about this thing will change and that thing will change. Too much abstraction is also really confusing as well. So try to keep it as real as possible, but in a single place. Now, this approach means that we actually have to take a different style when we're actually evaluating decisions and this is really thinking about sensing and probing over predicting and this is thinking about what we can actually do to get more information. Now, one of my favorite approaches to this is actually this idea of an architectural spike. So this is really about, we don't know anything about these technologies but before we commit to it, we should be evaluating these things to see how well they support change. So we should be evaluating how hard it makes deployments, how hard it makes testing and if it's not making any of these things easier, maybe we need to find an alternative. And so it's not just about architectural spikes or does it do the thing that we care about but actually we're trying to test these things to see if they support change as well. Because if it suddenly becomes the heart of our system, we're gonna be slowed down by this tool or framework for the life of the system. And this idea is really actually about this idea of sort of bringing the pain forward. Sounds a bit unusual, right? So, you know, why should we do things if it's painful? Now, one of the ideas behind this is that if it's painful, hopefully you get better at making it less painful, right? You improve something to make it less painful. And so some of the practices that kind of help with this is things like continuous integration, right? So we knew that integrating software was a painful task and actually continuous integration helps reduce that because it reduces the amount of effort that we have in one big bang into a smaller amount. And we've automated some of it so that becomes a bit easier as well. You know, we know that deployments are really painful. So actually if we deploy a lot more frequently, we can improve that process by learning about it each time. Database migrations are also a huge thing where if we're making changes to schemas, maybe we can do them in small steps so that we can actually make it a lot better and improve that through automation and testing as well. And yeah, you can apply this concept to pretty much everything around your software that you're actually building. And this is really starting to change the nature of how we actually think about making decisions. And what I think a successful architect will often do is actually move towards principle-driven architecture versus rules. So in a lot of places, there's a lot of rule-making of you can use this, you can't use this. And actually that's really hard when somebody has a different problem that doesn't fit that rule set. And this is where actually architectural principles help a lot more because you really need to think about what's the right decision for the context and what are the constraints that drive that type of decision. So if you're looking for some good examples around what are good principles of architecture looks like, I'd recommend the 12-factor app is a really good example of if you wanna build an application that has a characteristics that can be deployed onto a hierarchy and easily scalable, they set out 12 simple principles that you can sort of follow as guidelines. It doesn't mean you have to follow each one, but if you do, you'll have a more successful architecture that scales in that sort of approach. And you can kind of think about this in your sort of applications that are specific to your specific areas. So if you're thinking about mobile apps, what are the principles that help people make better decisions? And there's a whole bunch of principles if you wanna support change as well, that you should be asking people to think about, like the testability and whether or not it supports fast change. So we'll put this into practice and see what this actually means. Now, one of the first lessons about architecture that I've learned over time is that architecture is abstract until it's operationalized. So everything looks really great when you put things onto sort of diagrams, but what happens when you actually put these into reality, you never really know, right? And this is where actually you need to put this into reality, put it into production and then test that. But that's not the only time that you actually test your system. What actually happens is when you evolve your system and you try to make another change as well. And so this is actually this idea behind upgrading maybe one version of the library to understand how hard was that and how well does your architecture support change if you're making those types of changes? And so if each of these changes become a really, really hard, difficult task that takes months, you need to ask yourself, have we maybe over-engineered or coupled ourselves to not support types of changes that we actually care about? And this process doesn't really stop, unfortunately, unless your systems stop. But I hope that your systems last for a long time and you can kind of evolve that. And so what this means for us is that we need to sort of move away from this idea of a linear model where we architect things, we develop, and then we release. Instead, we should actually be thinking about a cycle where we're thinking about architecting, developing, releasing, but also reflecting on how well does our architecture support the change that we want? How easy is it to make technical changes? How easy is it to make business changes? And actually one of the things that we want to do is try to improve this cycle. So what is it that we can do to reduce this cycle and learn a lot more about architecture in particular? And so your cycle time will really be your constraint here. So if I can't emphasize it more than enough, in order to build an evolutionary architecture, you need a fast cycle time in order to prove the decisions that you make. And one of the things that can really help around this is actually thinking about architectural briefings. So I've been having a discussion with a client of mine where we talked about, well, what is an architect? And the response will was, well, anyone who makes a decision, right? What do you think developers do every day when they're actually writing code? They're making hundreds of decisions about where to put their code, about maybe which tools or libraries that they might use, how to abstract that. And there's no way that we can really stop people from making decisions. And so the best way that we can actually do is to improve the quality of those decisions by helping people understand what are the architectural constraints or drivers for what we care about? And so this is the idea with architectural briefings where you kind of want to have people that are maybe owners of different areas of your sort of system. And you kind of have this team. So one of my favorite approaches is the idea behind feature-driven development or having a feature lead who is focused on perhaps a particular fitness function area. And they sort of maybe talk and distribute this information to people. So it's not enough just to document this stuff, but it's really important that people understand the intent behind it. So these briefings might be around particularly a design decision. It might be around why we use a particular tool, the way that we use it. It might be a way how we've implemented something because if you're going to support change to it, it's important to understand why we implemented the way that we did. And the point of this architectural briefing is not just a unique way sort of direction, but actually it's a chance for people to discuss things as well, right? So people might have better experience having built something in that sort of area and have a different idea and then that can be incorporated into the design for the next time. But it also means that as people are talking about these different areas, everyone on the team can actually make better decisions if they go work in that area. And so in this sort of process, these sorts of architectural briefings should hopefully rotate and you get the next person coming along and actually talking about this sort of stuff. And one of the things that I've learned over time about software is that it's really hard because what we build is very intangible. We have these ideas about what we were trying to build in our head. And one of the reasons why these things work is often because when we actually write software, we all have these ideas and mental models in our head, but they're not always the same. And by getting these things out onto a whiteboard, we can actually talk about where those differences in understanding is. And so hopefully evolve those thinking to make sure that we're all on the same page and hopefully help people make better decisions as a result. And so in this model, it's a little bit funny because anyone who makes a decision is effectively an architect. And so this is the idea where everyone becomes more powerful because there's the decision-making capability, but hopefully everyone's a lot more informed so they're making better decisions. So what about the person who is responsible for the architecture overall? Well, the role changes a little bit from making decisions to helping educate and make sure there's that right environment, but also thinking a bit like a town planner as well. So if you're thinking about planning a town, a town planner is not really gonna get involved with every single building and every single decision about how things get up. They talk about what are the things that are fundamentally non-changeable because these are constraints. Perhaps they're legal constraints, perhaps they're operational constraints, but you know, whoa. Perhaps there is no ability to expand the land and so that becomes a constraint of some sort as well. And so as a overall architect, there's something about having this town planner of trying to let people know what the boundaries are but also allow them to make the better decisions that fit for that local design decision. So some of the practices that we've talked about are the things that help. There's a few more that I'm not gonna go into detail but you can go read about each of these things. So feature toggles are definitely one of those things that can actually support this. So we talked about experimentation and feature toggles can definitely help around trying to test something out in a small manner without exposing a huge amount of risk. Another approach might be branched by abstraction because in actually trying to introduce change, you're actually trying to think about what's the right type of abstraction for the behavior that I'm trying to replace. And so you kind of hopefully improve the design as you go as well. Tracer bullet deployments can definitely help as well. So we talked about getting your sort of software into production really early and you don't need a fully developed system in order to test that path to see whether or not that actually is easy to do. And make sure that you actually review fitness functions as well. So some systems will evolve over time and so the ecosystem will change around it and the system actually needs to evolve with that ecosystem as well. And so you might have different security requirements, different performance requirements and you need to adapt to that. There's a lot of information in this and I also don't want to sort of talk about why this is actually important and where you actually use it. So often when we're actually making choices it's not really a clear cut way of how we actually do things and often there's this idea behind build and buy but it's not really a binary kind of choice. We kind of mix and match things all the time so it's a bit of a blurred line. And one of the things that a lot of people are thinking about when they talk about build and buy they're always thinking about features and functionality. We want to deliver value, we want to deliver value fast. And this is why there's often the spectrum looking at say custom code all the way through to components of the shelf, cots or software products where we generally evaluate products based on what they give us. And one of the interesting things around this is actually thinking in terms of well if it's the things that they give us actually we should also be careful because we would care about evolving our system. So we should also evaluate these things in terms of how well does it actually support change, right? So if we're dealing with custom code we get to do anything we want because we get to build it. But if we're actually dealing with a component of the shelf or software product maybe they don't even support any customizations. If they do, maybe it'll be really costly as well. And frameworks, you're kind of a little bit more constrained because it's a web framework or it's an NBC framework. Whereas libraries you can hopefully compose a little bit more. And so there's a bit of a trade-off when I actually think about what is it that we actually care about? The change or the functionality and how much change is there? So when I think about systems I often use this sort of chart to think about well where does it make sense to think about evolutionary architecture? So if you think about in terms of is your system or component a value-generating thing? So does it make a lot of money? Is it a really important thing for the business? And does it actually need to change in response to the domain changes? So there are some software systems which are commodity type systems, right? So for instance the software operating system that we run on our Mac. It's not really a high value-generating because we need something to run these applications. And I don't really need a lot of changes on it because I don't need special customizations. And so actually this makes sense to actually just buy and acquire that type of software. For other types of software where we need to have some level of change maybe it makes sense to actually still buy software but have some level of customization. So for instance you might use a ticketing system because it's important for you. It's not really a value-generating thing it's a support type software. But you still need some customizations because you want a particular workflow but it's not gonna be a hugely changing type of system. Now there's other types of systems where you really wanna rapidly test a business market need. And these things are actually about the experimental type stuff. So it's a huge potential for value-generating but if it fails you're not gonna make a change at all you're just gonna throw it away. And so that's where you also probably don't want to use a lot of these sorts of things. But there are a lot of applications particularly in today's world there's more businesses go digital where actually their product is a strategic system. So it's a high value-generating thing it's their business proposition a unique thing to the business and you know that they're gonna wanna make changes to it. And this is the sweet spot of evolutionary architecture. This is where you really wanna be thinking about not necessarily buying stuff off the shelf and customizing it because that's gonna limit how fast you can actually respond to the business need but actually do and implement all the things I've been talking about because it'll help you both support technical changes as well as business changes overall. Now what are the things that prevent people from actually implementing change? Really comes down to a couple of different concepts. So it talks about coupling which we talked a little bit about where it talks about sort of cohesion as well and we've also kind of talked about slow feedback cycles. I wanna talk a little bit about cohesion because we haven't really talked about that and there's actually lots of different types of cohesion and there's actually a rating from where you go from the lowest type of cohesion all the way up to the top level. Now one of the lowest forms of cohesion is this coincidental type of cohesion and this is the type of things that happen when you end up with a big bowl of mud, right? So it's like, I'm working on this increment I'll just stick it wherever. It's coincidentally here. There's no real logical place for it. Now that's where you end up with people just trying to get functionality over the line not thinking is this a cohesive concept in a single place of the system? The next natural level is actually the logical one and the logical level is thinking about, oh okay well this stuff deals with the database stuff so I should stick all the database stuff together or maybe this is the stuff that deals with all payment stuff and I'll stick all of that stuff together. So it's still better than coincidental but it's still actually very low. Now there's a whole bunch of other types of cohesive concepts but when you go through this list it's interesting that the top one is about functional cohesion and this is actually going back to the idea of when there is a business change what part of the system do you go to to make that change? If it's very cohesive from a functional level you should only really have to go to one place in the system that represents that concept and so in any system I really highly recommend people think about object responsibilities, domain driven design and using the ubiquitous language to make sure that those domain concepts are represented in the code base to be as cohesive as possible because the best cohesion will allow you to actually support business change over time. Now we see a lot of these sort of systems and we often come in and try to rescue these sorts of systems that haven't really gone through evolutionary architecture. So what are the things to avoid if you're actually going through systems and you can make choices about it? So one of the first ones is around exuberant coupling. So one of the reasons that a lot of people don't like soap and we've seen a lot more update with rest is because of wisdoms. So if you've ever had to be a consumer of a wisdom you know how complex this stuff is, right? You add a new API, you have to generate a new version of the contract. Adding a new operation generates a new type of wisdom and you have to then expect all your clients to upgrade to the appropriate level of the wisdom. Now that's a huge coupling because it's now coupled the producer to the consumer and if you want to make versions you have to create a new one that they can actually support. So this is where rest has less coupling because they're not so exuberant around the way that they have. They can add new features in without breaking existing clients and that's okay. Another trap that we've kind of talked about is really about product customization. So what's very common is that you might start off with a CMS, you want to customize that CMS because you want to do something different. So you have that system and then you sort of branch off that system and then you do some level of customization. But we know that actually things won't stop changing. There will be a new version of that CMS system. But your IT department is really busy and can't keep up the change. So actually well there's another upgrade to that system and we're still behind and actually we get sort of to a system which is no longer supported and we still have to upgrade but that upgrade is going to be really painful and so we can only really upgrade to the latest version. And so actually this is something if you're going to do some product type stuff it's better not to customize it and to change your business process if you can rather than customize your product because you'll end up in a system where you won't be able to keep up to date with the latest version. Another trap a lot of people fall into is this idea of integration of the database layer. So in this example we have sort of three different sort of applications and they're using the same sort of database. Now what happens if one of these applications wants to change a database table that the other applications are using? Well you have to be really careful because if you introduce a breaking change you really have to synchronize with two other applications which may be run by two different teams or two different organizations and you can't really do that. And so this is where actually thinking about API integration is a lot better because you can abstract away the implementation details and you're less coupled. So if you're going down this path it's often seen as an easy way to share code or without having to develop an interface but it often ends up with a lot of hidden coupling that people don't really know about. The next kind of trap that we see a lot is actually around the sort of ESB customization rules. And actually what happens is that people don't want to customize products, sounds reasonable. So we can't really put it here, we actually have to stick it somewhere else. And what ends up happening is people add in a lot of logic about routing, about message transformation into your ESB but actually this is hidden coupling. So if you want to make a change you have to understand what other changes have happened in that ESB to be able to be confident that change is successful. And maybe you only have proprietary tooling that allows you to actually deploy and test that change which is going to prevent you from actually getting fast feedback as well. And so one of the traps that we often see in this is that a lot of people end up with production only being the only place where changes can be made and everyone doesn't want to make changes to it because they're afraid of breaking it. So a different pattern here is actually using smart endpoints and keeping the ESB as a messaging platform. So you would end up sort of having an adapter between a product and the channel in order to do the things that you would have, deploy that as a separate application and then you can actually test that component separate from the actual messaging infrastructure. So at the beginning we talked about the definition of evolutionary architecture supporting guided incremental change as a first principle among multiple dimensions. And to summarize, when you're going down this path it's really important that you think about architectural choices, how well they couple you to them, how easy are they to test, how easy are they to deploy. Think about not just the software side but also the decision making process and thinking as well. Enable everyone on the team to make better decisions and choices that enable change a lot faster and also think about the organizational and cultural elements of how your teams are organized if you want your architecture to represent that. Thank you. Does anyone have any questions or comments? Yes. Regarding the microservice architecture. So what about a presentation layer? Usually in your each customer order, actually your presentation layer is a single dashboard. So is the presentation layer separate microservice itself? So the question was, what about the presentation layer in a microservices architecture? So what we often see is actually the interface is created by that service. So each sort of microservice has a way of sort of exposing some sort of element and then they've agreed on a way of sort of composing the overall view. And the good thing about the web type stuff is that it's very loose coupling, right? So if you move from one webpage to another webpage, actually as a user you have no idea that it might be served by a completely different application. You still need to have some considerations like style guidelines and shared understanding which is the overall constraint. But there's nothing stopping you from actually having different UIs with different technology that match that sort of need for the customer. So when I talk to some of the banks here, I mean, first question they're asking about microservices is that how are we gonna manage the diversity of this kind of technology brought over by different kind of developers, right? And they also kind of unconscious about those controls and guidelines and standards and everything. How do you see that some banks that are going to come up with style from colors or something? Yeah, so I guess in a classical, so if I talk about more traditional I'm a bit more progressive perhaps. So in a traditional sort of place, there are those rules, you can't use this, you can use that. In a more progressive place, we see a lot more guidelines and principles around choosing stuff. So there's a lot more talk about say if we're gonna use technology, we wanna think about where we can actually hire people from and also training for that sort of stuff. I think also with more progressive ones, there's actually a lot more thoughts around the experimentation. So the difficulty with the things like that you can't use it and you can is that it doesn't really allow you to deal with new technologies. So classically it's done by a group of people that are approved to test new technologies but often that's quite out of ban with what the business problem is and so they end up saying here's the approved technologies but nobody in the sort of development teams want to use it because it doesn't solve their business problem. And so what we see is actually a governance process around encouraging teams to do some level of testing of new sort of technologies but they can't sort of build an entire application of it. So that's to sort of prove it out first and then look for approval if that makes sense. So it's really about helping people understand the constraints of say hiring and also that's a lot more helpful if it's based around sort of product lines versus having just a whole pool of developers that can then be farmed out to all types of applications. So when you end up on a sort of more long live product team that team is more responsible for the long live sort of nature of that code base and so actually the hiring of that team isn't so much of a worry rather than thinking about overall because they're always gonna be on that sort of product. So what are some thoughts about building applications which have significant analytic components to them and how does one architect for the fact that analytic components will take time and have their own life cycle. And yet you want your business applications to respond to the latest analytical model of the latest intelligence. Yeah, so a lot of these principles apply also to analytical solutions because also we've seen huge changes in technology around analytical tooling as well. So customers can't rely on a single data warehouse for all of that information. There's multiple sources now. And so this is where actually they need to think about smaller, faster applications that serve particularly needs. So we're seeing a lot more places go towards say the data lake and then teams enabled and powered to use more analytical tooling to respond to what a specific business need is because what we often see with data warehousing is or analytical pool is that often it takes years to develop that solution but actually just to solve a business problem. When they get to it, they've been so diligent in crafting the perfect data scheme or meta model scheme that nobody can get the information that they want out of it, right? So they've done a lot of things and actually the business is often wanting a lot more responsiveness to that. So a lot of it is really thinking about how you break that down into the ideas of fast feedback, delivering something really quickly and then testing for whether or not you can actually support the change as well. So what this means is actually for the companies that we see do this successfully, they're applying a lot of the ideas of continuous delivery to analytical space as well. So it's not just that we've configured a Spark server and off we go and like we've configured it but actually we're thinking about how we sort of program our code, we test it and actually we're testing that as fast as we can so that we can evolve and support that. We're also thinking about how much of it are they too coupled to that technology. So rather than saying actually everything is stuck in a particular product in a proprietary format, actually we're preferring to have things that is owned by our company and not owned by a particular product proprietary format. So a lot of these principles are actually very applicable to the data space. Yes, it takes a lot longer because of the size and the nature of data but the same concepts apply. Smart endpoints and dub-factor lessons. Yeah. What's your view on API gateways lessons? What should it do, what should it not do? So it's a good question. So my view on API gateways, what it should do and what it shouldn't do. I guess it depends on what your business is doing. So if you're in the business of just creating an API, like if you're charging by APIs, so if that's your product, it's a strategic product and that probably means that you're probably gonna do things that are unusual for other types of products. Whereas if you're just using a gateway to, say, consolidate existing APIs and it's not really, so I go back to my four quadrant kind of example, trying to understand what thing you actually want and the types of change you actually wanna support. So there are some things where API gateways I think provide, say, throttling or account management where maybe that makes sense, but if you're gonna have specific behaviors that maybe are driven by the business, you probably actually want to build that in rather than use a gateway for that. Does that make sense? Yeah, so how do I design databases and microservices? So a lot of the initial design is actually thinking about the domain modeling around what are the separate business entities you actually wanna support in terms of the microservices. The actual data that you wanna store per microservice should be a evolvable thing. So you shouldn't have to care about the details about that too upfront, about how it's getting stored. That can be sort of delegated down into that sort of particular microservice. So the general process would be trying to understand the bigger picture about what parts of the business may wanna make changes to types of information. There's also a bit of laxness in microservices where the bounded context means that actually the view of a customer in one part of the business may be quite different in another part of the business and that's okay. You have to be clear about where maybe the creation of customer information comes from, but it's okay for other people to say replicate that and add extra information because that's part of their business need. So a lot of it comes down to sort of higher level modeling first to understand what the granularity of the microservice is and then the actual information within a microservice should be kind of hidden away. You don't need to worry about the implementation of the details up front, if that makes sense. Yeah, I would agree with it. If you are to retain something like one mic, I mean a very trivial example, one microservice is storing department and another and there's storage in the employees, right? And the third microservice needs a department and employees all right. So it's very trivial example. So it has to be much more microservice. How you design your way out is how do you retrieve the data? So I guess it depends on what the business is doing with departments and employees or customers. So because in a microservice sort of world that may not be separate entities or services. So there might actually be an entity that is dealing with I don't know if you're education or something like that. Actually all of that is part of the same sort of microservice. So actually you'd be looking for a document or a tree of information. So I wouldn't simply map as microservice to a database table. It's actually thinking about how does a business entity make changes to related entities. If that makes sense. So it's more granular than what a typical database table would be. The microservice is architecture. How do you handle the cross-cutting concerns that is there across the application? Could test the business way or it could be cross-cutting business concerns. How do you architect? So how do you deal with cross-cutting business concerns across microservices? This comes down to that town planning kind of idea around what is it that each microservice needs to have to comply. So in a town for instance you probably have a standard electricity supply because that's a constraint of you wanna share power grid or something like that. So what we typically see is there and what we normally see is like there's a commonality around the operation stuff and monitoring because you don't wanna have hundreds of monitoring solutions. And so actually that's a cross-cutting concern we see quite a lot. And often that's a, if you're going to develop a microservice we want to be able to monitor it using say Nagios or something. So a specific endpoint. And then that would work with a different team perhaps to aggregate the information. So it's kind of an agreed standard interface so how you might interact with that. For other things like performance I would actually say you get different performance characteristics depending on the service that you have. So for instance, public facing things will probably have higher because it's like on the internet but if it's internal you don't need to worry about that so much. So it'll probably depend on the microservice because it's more of a back end supply service. You don't need to worry about the constraint so much. In a sense, updating the cross-cutting microservice Yeah. If quick change. Yeah, absolutely. And that's really trying to identify what's the fitness function for the entire set of things. Is that fundamentally everything has to meet that fitness function. But if that fitness function is changing fundamentally then it's going to be kind of hard to change as well. But at least you know where to go, right? So you should be able to map to which service those constraints actually apply. Yeah. Cool. What about managing change? How would... So the most important thing is for impact assessment. So while we move to microservices I guess our changes is isolated with the microservice but at the same time how do we manage the impact on you? The people who are calling the service up and down street how do we identify that early so that we can as part of this architecture we know what we are impacting. So we're basically trying to get rid of all the unknowns and maximize what we know we are going to impact. So, I mean if you're making a change to your own service and you have people that are depending on your service you would treat it like any other thing in that you should know your impact and your consumers. You see a couple of environment and then we're just publishing services. So does that mean that in this case we should introduce some kind of API new way to know who are my consumers are or what we need to introduce in this kind of environment? Governance in place or what? Does it know your whole impact? Yeah, I mean it's kind of a loaded question because it depends on the scale of the organization. So if it's the same team dealing with all the microservices you don't need anything special because they know who the other dependents are. If you're an organization of thousands of people then you might need to have some things like version management which is making sure that you have say backward compatibility and then maybe better monitoring in place. So I know some places who have monitoring of which APIs are actually getting called in production and basically instances that aren't getting called get blown away. So it kind of depends on the scale of that. Are you a big proponent of using the Nog as a good source for test cases? The log? Yes. I have no opinion on that. So I mean I think it's a useful source sometimes. It kind of depends on what you're trying to test. Yeah, maybe two last questions because then we can probably wrap up. How does architecture would help mobile applications? How does this architecture help mobile? I think it's very similar as well, right? So when you're actually thinking about mobile development how much of the code that you are having is actually coupled to libraries or frameworks? How testable a lot of that stuff is? So I think one of the difficulties is can you think about ways of actually speeding up your cycle? So for me mobile development is very similar to if you're building using a web framework or something is that you can write code in the framework but of course that means in order to test anything you're gonna have to deploy that framework into a place where you work whereas if you're actually not coupled to the framework you can actually probably test that really rapidly and then do sort of a final pass of actually testing it in a single application. So you can actually think about ways of how you speed that feedback cycle up as well as being wary of the tools that you use that sort of pull you in and couple yourselves to them unintentionally. Just wanted to know your thoughts on how modeling the enterprise see for example you're using Archimede or Toolkit how does it actually complement or even contradicts with evolutionary architecture? I think that kind of complementary approaches so I don't know the first one that you were talking about but I know Toolkit for a little bit and I think they're just kind of complementary approaches so I see all of these things as tools that you add to your architecture Toolkit and you have to pick the things that actually make a lot of sense for what you have and question the value. So I think a lot of the stuff in Togaf is actually around the analysis and modeling of that sort of stuff and what I would say is that it's a good way of maybe doing the domain modeling as well trying to do an initial version but actually I would try to rapidly test it as fast as possible so you can iterate over those models that you created. So I would say the things that probably need to change is maybe a bit more of the how do you actually test those ideas, those assumptions made with the least amount of information fast so you can re-correct in course adjust. Cool. So yeah, I think that's probably a good last question because we've gone quite late. Thank you very much for coming tonight and I'll be around if you have any other questions. Thank you.