 All right, let's, without further ado, let's get started. First of all, my name is Jonathan House. I work at a company here in town called Amrises. It is a medical software company, small medical software. We have approximately 35, 40 people on the team right now. And the four years that I've been there, we've grown from the size of probably half that. Probably through no fault of my own, but we don't need our progress changes. The reason why I'm here today is because at least some of the corporate conference organizers think I know what I'm talking about, as far as agile and architecture is concerned. So we'll find out if I actually do know anything about this or not. This is a tutorial, not a talk. If I'm doing most of the talking, there's a problem, because this is about exploring things. This is not an only technical session. We will not be spending a huge amount of time on 14 million different acronym type things that sit underneath architecture. We're looking for patterns. We're looking for the big picture of architecture. So we can see what sort of things we have to deal with on a regular basis to make our jobs easier, especially in the natural environment when things are changing constantly. So that's the purpose of the session. If you do not have architectural experience, we do not write code. Great. I'm glad you're here because you are going to serve a very important part of this discussion today. You're going to be a part of the discussion where you look across the board in a while and you realize what all was part of these changes that we have to make. So that's the purpose of today. Before it really gets started, though, I wanted to share something with you. This morning, I was reading one of my mailing lists and I saw a post-comment from somebody who shall remain nameless. They're probably not here anymore, probably not even in the country. But their title on the email was Agile Java Architect. And I thought that was kind of funny. That was a lot funny, actually. Not the least, which is because I have no idea what that means. So, I mean, if you take these pieces separately, Agile, we know that as we're all here for that purpose, right? Java, pretty self-explanatory. An architect. What does an Agile Java architect do? Designs, boldings, while drinking coffee, balancing on a pole. Exactly. Or there's one other over here, too. The architect-agile Java. The architect-agile Java. I've seen a lot of that. That's how I've never seen any of my Agile Java yet. But that's just how it goes. Anyways, there's a lot of talk right now about the transition of Agile, Agile fundamentally being a people process over to the world of architecture. And we're going to talk about that a little bit today. These things are related to each other, but they're also kind of orthogonal to each other. And that's really where we get run into problems. We need to understand that Agile is a methodology to process the way of doing things. Architecture is a means of doing things. But they also have a big impact on each other. So we want to make sure that we understand both and can work in a way that we're not going to at least kill each other on one side or another, depending upon the choice that we make in the opposite side. So without further ado, how many in the room are developers or architects, people that have had their hands in code, write code in a regular basis, or have written code? Okay. Pulling his arm out. Apparently your code isn't that good. What is your manager now? You've been elevated, so you can't touch code anymore. I was actually at my company. I was told that I can no longer write code for the teams like production systems, so I feel your pain. How many of you are management or executive? And if you don't write code, your job is to make sure that we actually make something for you. Good. Executives, anybody at the sea level, officer level of the company? Well, there's one. One, two. Good. Your experience is going to be very valuable here. We're going to be organizing yourself in the teams very shortly, and I want to blend of technical and non-technical people on the teams because when we get stuck, we start talking about architecture. The fundamental drivers for architecture are usually business oriented, and you'll see that as we go through our exercises. And without the business perspective there, we tend to be a little incestuous at times, don't we? We try not to, but it happens. So the point of the session today is not to give you a deep understanding of architecture. It's really to give you an exposure to the forces of the patterns that occur so that we can start looking down into the details. The concept of architecture, of architecture is huge. There's hundreds of books running on it. There's millions of electrons on the web that have been devoted to this information. There's a lot of people out there that have devoted their careers to this subject. So I'm certainly not going to accomplish anything in 90 minutes that they haven't already done for us or at least communicated. We just want to kind of open the kimono, so to speak, to take a look at what's going on and get rid of all the day-to-day distractions that keep us from seeing what's going on in the architecture. How many of you have been in a training session with Alistair before? He's going to pop over once we're on. When he comes over, let me know so that we can act like we're doing something important. One of the things that I love about Alistair is that he looks at the detail. He looks at what it really takes to get things done but he also looks at the meta-concepts. He's a great, high-level strategic thinker. One of the things that he says all the time that I picked up as a habit is talking at the Shu, Ha, and Ri levels. Has anyone heard that before? I know a few of us have. What that means, Shu, Ha, is a series of Japanese terms coming from martial arts, but really what it says, there's different levels of experience. When you are at a level of experience, there's only a certain way that you can communicate or be communicated to where it makes sense. The higher up you go in experience, the more communication you can accept and more abstract concepts, so finally you get to a point where you can really understand the big picture and then on, we don't always pay attention to where people are relative to the Shu, Ha, Ri levels. Now if I'm going to build myself as an architect, I would probably say that maybe I could claim to be a Ri level architect. I've seen a lot of systems, designed a lot of systems, I've failed a lot of times, and I've succeeded just often enough to make me think, hey, I can talk about this. But if I'm talking to somebody that's doing architecture for the first time, are we going to communicate on the same level? No. So in the discussion today, we're going to talk about systems in and back, and as you are talking amongst yourselves and your groups, make sure that you're talking across those boundaries if you're really dealing with technical stuff. Take a step back, simplify it. If you're deep in business stuff, again, simplify so that the other side of the technical slash business divide can understand. I'll try to do the same thing as well. Every once in a while I geek out so I apologize in advance, but I will try to keep it at a simple level as possible. Alright, so definitions. Cover the agile.architect. Now I want to cover definitions a little bit. We're going to be using a few terms in here. I want to make sure that we're all talking about the same thing. The first one is agile. You'd think we've been spending a day talking about this already, some of us spent multiple conferences talking about this for years, but we'd have the same definition of what agile means. What does agile mean in terms of software? Specifically in terms of software architecture. The things that are going to keep our software running over time. What does agile mean? Easy to change. Can I say flexible? Hand writing is horrible, so I apologize for right off the bat. What else? Mitigating risk. Mitigating risk. Very good. Two more. Understandable. Expand on that a little bit. So it feeds into the flexible and the mitigating risk, but an architecture that is very elegant, but it takes you weeks of careful study to really grok isn't so great because we're going to be doing the work on that system aren't necessarily going to all grok it. So something where you can look at it and go ah, I understand what this is doing. Okay, so visibility, understandability, would that be a fair way of stating that? Absolutely. One more. Yes, scalable. Agile, scalable. Size. Can we really make our Agile teams bigger? I'm kidding. It is scalable. It's adjustable. Again, it gets back to the flexible concept, but we can adjust over time, right? So Agile, really, we're getting into the heart of what Agile is. It's iterative, it is flexible, it responds to change, we reflect, it increments, all those things are important to us. That allows us to deliver software the software that we need is how we need it. And very important concepts. Let's take a look at the words that show up for architecture. Maybe we'll post those out there. Hopefully we'll get them up at the wall at some point. Francine, would you mind just throwing them up on the wall somewhere? Thank you. By the way, everybody, this is Francine. She'll be assisting you today. Please sign her hand. That's what it takes to get a good review on this session. I know nothing about what you guys are talking about, except that easy to understand Agile. Give you some words associated with architecture. Think about architecture. What do we think about? Design. What does this look like? How is it going to work? Strategy. Strategic, right? Got to think for the long term. High level. Scalable. Scalable. Adoptable. Adoptable? Adoptable. Say a little more about that. If you're building an architecture, presumably you're wasting time on this because you've got a whole staff of people who are going to have to conform to it. If it's just you, then do what you want. There's a whole bunch of architectural forces that are required to allow your staff to actually conform to your architecture. It has to be adoptable. Does that make sense? We agree with that? It has to be adoptable. For the greatest architecture in the world, it doesn't make any sense if nobody can jump in and use it. Architecture. Got some words. If we look at the words, and France, you're going to hurry up and get this on the wall. You know what I mean? If we look at the words on the list, you'll find that we've got flexible, we've got adjustable. Big surprise in the Agilist, right? But over here we've got strategic, we've got high level. We've got some different terms there. What's the fundamental disparity between these two? What's the difference? We're talking about Agilist. We're really planning for the tactical. We're talking about architecture we're really planning for strategic. And that's where we're running the problems, and that's why this is so hard, because we've got to balance these things. And that's the point of the session today. A couple other things real quick, just so that we're using the same terms as we're talking through this time. Architecture, when we talk about architecture today, we'll be referring to application architecture. There is a more generalized concept of enterprise architecture, which is a whole organization that runs on. We're going to focus specifically on application context today. The other thing is, how many of you have seen Martin Fowler's book on architectural habits? Anybody seen that book? Do you have this out here? In the book, one of the things we've talked about over time is the structure or how architecture is laid out and decentralized. We're going to be using three terms today, the terms are, we talk about the front end of the application, we're talking about the presentation there, right? So we have presentation. Sit spot. What is it? Business layer. Business layer, domain logic. Anything else that you go on that list? Data. Just data, big pile of data out there. What does data sit at? Persistence. And if we take persistence as a class of system, to a more generalized concept, what are we talking about? Persistence is one major piece of most applications. We also sometimes talk to other applications as well. So really what we're talking about, we're talking about persistence and other things is integration, external systems. So those are the three main areas that we're going to be working in today. External systems. Anybody have to clear out on those three concepts? Generalized enough? Okay, let's move on. The other thing that we're going to be talking about today is we're going to be talking about, when we get down to the design work, the exercises that you're going to be doing, you'll be spending most of your time today working on two things. You're going to be identifying common functionality for applications. These are generally frameworks, components, tool kits, things like this. We can name a hundred if we ran around the room a couple of times. The other thing that we're going to be talking about is we're going to be talking about customized code. Customized code meaning code that we write for that particular application. We draw a line between these two because they're architecturally interesting and they differ from each other. We'll find out as we go along in this exercise. Okay, so we said that we're going to spread the teams around a little bit. Those of you who are not technical, what I'd like you to do, we're going to shuffle the room around a little bit. There's two things I'm going to ask. First of all, I want to ask that you guys, when you start to pull us into groups, please do not try to get with a group of people that you work with on a regular basis. Learning is sometimes it could be a painful exercise. At the very least, it should be instructive. And when you hear the people and you talk to other people, you're going to learn things that you may not learn from somebody you sit next to every day doing your job. So please try to get with a group of people that you haven't met before and as you're going through. I would ask that the non-technical people just stand up for me for a moment. Excellent. And what I'd like to do is amongst these one, two, three, four, five, six tables here. We'll slide that one over and slide this one out a little bit. Just go ahead and distribute yourselves equally amongst those six tables. We're going to use you as a basis for your teams. So one or two at each of the tables would be great. Okay. We have a lot to do very shortly on time. So I want to introduce the exercise and what I'm going to ask you to do is actually run through this exercise with me as we do this to kind of introduce how this game is going to be played. You're going to need a couple of things first. Each table you should have a couple of different colors posted notes. You should have at least a few pieces of chart paper, probably about six would be good and a sharp piece to write on. So if you don't have it, come on over to the table grab yourself supplies. Okay. Each table, chart paper two different colors posted and at least a point chart to write. This is a it should be a relatively simple game but it's surprisingly how it's really how complex it gets because we're talking about architecture. There's a lot of ways to skin this particular cat. So we're going to set out some rules we're probably going to break up and we're going to have a mess and we start to deal with them but hopefully we'll understand the general rule of the game over time. The idea here is that we're going to give you an initial architecture. We're going to give you the actual technology that you're going to work with today. Sorry, but I'd love to have everybody declare all of them. We'll keep you here for a long time if that happens. The second thing I'm going to give you is I'm going to give you the initial rounds of the game that we're going to play. And I'll show this. I'll walk you through so you can understand how it works. My job is to give you changes to the business. I've got a whole interesting stack of them here. Your job is to figure out how architecture is going to respond to those changes over time. The important part about this is we get through a lot of iterations of this because we want to see patterns, we want to see things develop and if we don't get through multiple iterations of this it's really hard to see the patterns that develop. So we're going to start out slow with this initial tutorial round and then afterwards we're going to speed things up and put a lot of pressure on you guys to just get this thing done quickly. So that being said, there's a couple of things. First of all, the understanding of what the system is. We are building software for an auto insurance company and this is claims management software. Does anybody actually work for an insurance company? Show of hands. Forget everything that you know about your domain because it's going to be too complicated to bring in here. When we talk about functionality or when we talk about bullet points you'll notice that the stickies in front of you are very small. That's a hit. Use that. We're going to be talking about functionality in general terms. The functionality is interesting because that's what our system does but it's not interesting when we're taking a step back to looking at architecture. Not as interesting as I should say. So here's what you're going to have. You're going to start off with two sheets and as we start, as we start working with these I want you to copy what we've got up here on the board. I'm going to give you the tour of these in just a second. First one, you've got a sheet and it's going to be divided into three sections. At the top, we've got a presentation. We've got a domain and we've got a persistence slash external. This is going to be our current architecture. At any given point, we should be able to look at this one sheet that's going to remain during the session and see what your architecture looks like. Look at all the colors, stickies, and see what we've got. There's a second sheet that you're going to have. This is change motivation. This is going to track our architecture over time. What you do here is you're going to have a section where you actually identify what the change motivation is, what happened to your business, and then down here you're going to identify the changes to your presentation, your domain, and your external systems. We'll keep doing this until we get a lot of things done or we dissolve into chaos. One of the two. That's the general theory behind the game here. We'll see if it actually works this way. What I'd like you to do is for the first two rounds so that we're all starting at the same place, just kind of play along with me as we do this. I should probably cover the architecture. I want to get rid of the implementation. It's a typical developer. The architecture. How many of you work on Java? More or less Java technologies. A few. Ruby Rails, that sort of thing. Show of hands. .NET. We're into it a little. No, I'm kidding. The idea here is that we have to pick an architecture to work with, and since I'm the guy that's doing this session, I guess put the architecture. We're going to use a Java technology platform. Very simple. Let's just lay this out real quick. First of all, the legend. If you see a blue-green sticky up here, this implies that this is framework and tools as far as the architecture is concerned. This is stuff that is not written specifically for application. This is more generalized stuff. So you'll see the framework and tools for that. The pink-orange stickies are for domain logic. This is logic for the application. Demand logic is actually not the right term, because that implies that it sits in the slayer. This is code that you write for that application. It could be presentation, it could be domain, it could be persistence. It doesn't matter. We just want the two different colors so you can see the differences. Does that make sense? Explain that again. You've got two different colors. Something you're going to use to specify frameworks, tools. Second one is application-specific logic. On the framework tools, we're going to ask you to do two things. One, give it a name. And then two, a very brief description. You cannot go any longer than a sentence today on anything. So the framework piece, the framework sticky should have a name, whatever you want to call it as we start adding architecture, and it should have a description. The application-specific code will only have a description on it. We're going to talk about the business purpose of that to give a piece of code. With me so far? Let's take a look at the game. The playing game is the important part here. So we'll just stick these up here and hopefully they'll stay. So we have a lightning. Now let's actually look at an example. The architecture we've chosen, as I said, is a job stack across the board. And when I say job, it's primarily job. It doesn't mean that everything in here is job. And here we go. So the front end, scene. Have I worked with scene before? One person? Wow, I picked them well, didn't I? Okay, it doesn't matter except for the fact that the application itself, scene is the name. It is a JavaScript slash dynamic HTML interface layer. That's all it does. It's going to deliver that out. Now, scene does more than that, but we're going to keep it simple on the scene. So that's what our architecture is for the front end. That's what's driving our actual screens. In addition to that, I also need something that binds my user interface back to the business tiers. So I've got a second piece of architecture up there, which is also scene that covers this. It provides a simple functionality. So that goes there as well. I've got my architecture, I've got my architectural elements, the framework style elements for my first tier. In the middle, Spring. Okay, a couple. Spring is just a business logic framework provides a lot of basic services. There's no magic about it other than the fact that it's really specified to sit on that domain tier. So Spring is going to be our initial business logic framework. Okay, and if you haven't done so already, go ahead and start creating these stickies because these will change over time and then stick them on your sheet because it's going to look something like this. Two other pieces and I'll give you a minute to catch up on the architecture. On the back end, we know we need to be able to do this, right? Probably a good idea. On the back end, we're going to have two pieces. One is an API. The API that we're choosing today is called JPA. It's a web-surgical resistance architecture. So we'll put that on the back end. And the final one, we like Postgres. Anybody else like Postgres? Okay, so Postgres is our actual database system. Why did we break this out? Why did we specify JPA and Postgres? What's that? These are not a fundamental unit. These are two separate things that do similar related behavior, but you can change them. Okay, go ahead and take a minute. 60 seconds. Just real quick, draw a page. This is going to be your permanent architecture. And we all got... Okay, now, this is a great architecture. Now we're going to mess it up by putting business logic in them. So what we're going to do is we're going to add our application-specific code. We're going to switch stickies. What I'd like you to do is, as we create these up here, I'd like you to do a figure group as well. So go ahead and elect whoever is going to be described temporarily as we create these. Now in order for us to create this... In order for us to create this, we have to understand exactly what it is that we're building. These are the change parts. Now obviously the first change is we have to have something to start with. So what I'm going to do is I'm going to just identify very quickly at a high level what the functionality is and then we'll continue on from there and see what stickies generate. Now I'm going to have Francine actually write these for me because as you can see, my stuff is completely illegible, even if you do get up close. So the first one is this is an auto-assurance claim processing system. We get a very simple one to start with. We're going to be making it more complex as time goes on. The first thing is we need to be able to create the claims and capture data associated with claim. That's it. Now we can talk about the details of what data, what does a claim look like, things like that. But again from the architectural perspective, from the perspective that we're looking at today, not really important. As we go through these rounds, you're going to have a chance to question the customer, even me, at the beginning of the round after I explain to you what the change is. And I'm going to identify the things that you should pay attention to and you shouldn't. If it's something that isn't really relevant to the exercise, I'll say that it's not relevant, so you don't have to worry about it. If it is, then you want to keep an eye on it or keep track of it somehow. I may lie. Of course that never happens in your life. So the first one, we need to be able to on the user interface, capture claims, right? We have to have a screen to be able to create claims. So on the user interface, we have functionality, create claims. So we've got creating claims on the user interface. That sets on our scene architecture, right? In addition to that, we also have business logic for we have to be able to have claims, right? Claims are a fundamental part of our system, so let's have some claims business logic. And a claim is a general term for somebody in my car, maybe a decimate, and now I have to get money to fix it. And the insurance company is going to take a lot of time to work with me for that. Thank you. All right. If I just create claims, is that interesting? Business wise? Business people? What's that? We just create them. If we just create them, is that interesting? We want to be able to modify them. Right, we want to be able to modify them. For the purpose of this exercise, we're looking at three things. I want to be able to create claims, I want to be able to submit quotes against it for repair, and I want to be able to cut a check for it. Those are the three behaviors. So we're going to repeat the business logic for those other two things. The most important business option is to deny it. To deny it? We haven't gotten there yet. It's small. So we have to have a need of capturing quotes as we get them from the repair places, right? So that's the user interface element. And it's probably also the main logic associated with the quote on the back end. Go ahead and do that. If we capture the user interface, it should be the main logic, right? Very good. One more thing, we have to be able to settle the claim, right? So we need user interface for settlement. What's that? Settlement. And business logic site, we also have to have a settlement, right? The main logic, settlement. Again, we're talking real gentlemen. So we have a settlement for you guys. Quick check. Do we have the user interface? The user interface of the house is great. We have business logic for it. We can put quotes against the settlement. What can't we do right now? There is a logic that is missing. And that is for the persistence layer. If we've got a persistence framework here, we also have to have a code that actually does the persistence for this code, right? It's demand-specific. We can't just have JVA with no customization for application. Persistence without telling the instrument, telling it how to persist, it's kind of useless. So we also have a custom code here for persistence. So this is allocation persistence. Application persistence. Okay. In your experience so far, does this match up with House Office Bill at a very general level? Do you have any questions across the board? Do you also have a custom code that you write for the specific business purpose? Are we on the same track so far? If you don't do that, let me know because I really want to hear about your project. That will be an interesting conversation. One other thing, a couple of assumptions. First of all, we haven't said anything about the information on our insurance. People that are actually recovering with insurance, we can safely assume that we have the ability when you create a claim, you have the ability to look somebody out and find some information whether or not they're valid. It's not going to be important to the exercise. Okay, a couple of rules before we get to the interesting part. This is the boring part of this. We had to start somewhere and this is where we're starting. Now we get into the more interesting things, hopefully. Rules are you can't have more than one functionality. If you guys later on decide to add frameworks or you decide to add business logic, that's great. Has to have one purpose. Now, in reality, there are things that out of business world there are frameworks so we can pick out those components. But when we start looking at these across the teams here, it's going to be very difficult for us to understand that. So we're going to keep it to one concept for architectural elements, framework, component, and one concept for business component. Does that make sense? It's really the only rule other than that, we'll let creativity reign. Once we have something here, we want to look at the changes that affect architecture. We've got our very first change coming up in that with our existing system here, we have found that the business has come back and said, hey, we're getting killed by our competitors because they have better fraud detection. We're spending lots and lots of money on fraud, people are submitting fraudulent claims. So the functionality that we have to enter or we have to deal with this, we need to be able to compare a new claim against any previous claim to see if there's any fraudulent activity going on. But again, the detail of that is very complicated. If you're actually writing that, is that important if we're looking at general architecture? Okay, so in this period, once we actually start this, this is going to be the real sessions as we go on. What we're going to do is we're going to present to you the business motivation or the change motivation and you're going to figure out what that means in the architecture. Well, this first time, obviously, we're going to do that with you so you can see how the game is played. So as I'm changing architecture, first of all, if I have the functionality of I've got to create an ability to go back and check and see if there's fraudulent claims against a new claim. Does that mean we're going to enter a new framework? Is there any new components coming from this? Does it feel like there's something new there on that side? Okay, you said yes, I saw a no back there. John, you don't think there's any new frameworks and components or anything like that, right? What do you think? I think there needs to be a process unless we want to build anything. There needs to be a process unless we want to build it. Now we're getting into the architecture game. This is the interesting part about this because these are the ones that you're going to be making your minds up on in your teams after the first couple rounds. So what we're going to do is we're going to show you what a first change looks like and on the first change it's really very simple. We need to be able to create the functionality of doing a fraud check. Real simple fraud check means I go back and I look and see if there's any commonality with previous claims. Saying claims submitted multiple times, submitting a series of claims, there's a lot of logic to it that we're not going to be worried about. So I'm going to go ahead and create my fraud check. This is a changed functionality. So we're going to go to our change motivation board here. On the change motivation, what's our actual motivating factor? Fraud control. Fraud control. This is the competitive pressure. When we get right down to it, the business value is we need to be able to compete more effectively with the other companies out there. So we're going to reduce our fraud the money we pay out. So the change motivation is this. We have a fraud check. If we go back and look at our the main logic, do we have anything to take your fraud check right now? So we've got to add this, right? Our change is we're going to add the fraud check to the domain logic. Do we have anything to change in the presentation? No. No? Yes. Quick show of hands. How many of you think that our presentation is fine at this point? One, two. No. How many of you think that there has to be some sort of user interface change? Most of you. What's the change? Real simple. What change do we have to make? Fraud alert. Fraud alert. When we go through and the important part about this is right before we settle the claim we want to have a fraud alert that shows up, right? In software we have really three choices that we can do each time that we make changes to the system. We create something new, which we did right here. We created a new functionality fraud check. We can refactor existing functionality. We can take the existing screen user interface for settled claims and add a fraud check to it. Or we can completely replace something. Those are the three games that we can play with an architecture. What do you think is the right one to play here? Free work. Free work? Free work through existing screen? Alright, works for me. So we will have refactor. Refactor settlement. Here. Alright, any other changes that we need to make to satisfy the change of the change in operation? Persistence. Persistence. You have to store the alert. Persistence, we're going to store the alert. We're not going to put that one up for now, but that is a valid point. These are the things you have to look at. Where does the effect cross the system? Anybody else? For your claims. This is the functionality for that, right? Hopefully, it's the body within the fraud check. That's the assumption we're making right now. If not, well, we've got more work to do. We'll find out what gets quality assurance. Did I tell you that when you have quality assurance coming? Oh, sorry, I forgot to mention that. Look my mind. This is the change in operation. This is the change in modification. This is going to impact our architecture. We want this to be as current as possible. This is our record only time. This is what we're going to look at at the end of the session. So, what do we want to do to this based upon this information? Add those. Add it. But we don't want to just carry the stickies over because we'll lose our record, so we're going to repeat these stickies. We're going to have Francine do this for me. We're going to repeat the stickies over on our architecture and just make the changes that we've identified and change motivation. So, we want you to project and then change self-finery to include the project. So, while she's doing that, let's talk a little bit about that. So, there's really two changes we're making on here. The first one is, again, we want to move fraud check as a new functionality to our domain. We got that? Excellent. And we want to take the subtle plane and refactor it. We don't want to add something new there. We want to refactor what we have, right? So, you can change that one. Here's our old subtle plane. Now I've got subtle plane including fraud check. Okay. Are we all here so far? Yay! These guys are ready to deliver over here. All right. Okay, so that's the first round. Has anything interesting architectural happened yet? No, not a thing. We've changed functionality in the application, which is important to the business, but as architects are being concerned about architecture, nothing's changed yet. So, we're going to play one more round. And this time, we're going to go a little bit faster. We'll give you a chance to follow up. After we get it, gentlemen, we'll give you a chance to work in the groups. We'll give you a chance to make the changes. Let me just talk you through it first so we can get through all the changes we're going to make. So, I'll play this round up here, and then we'll add it all at one time so that we're all on the same page. Does that work? Excellent. Okay. So, the second motivator. Here's the new change motivation that's coming in. We already know that we have functionality for checking against claims in our existing system, but it turns out that the industry has also been doing some work as well. So, the insurance industry as a whole has created a clearing house that does the same thing. So, now we have an external system that we are now required, by law, this is a regulatory change, to go and compare against with our system. Okay? We've already got the functionality, but now we've got additional things to do. What's the impact? Let's look at the framework impact first. The architectural impact, non-business-specific. What are we going to do? First thing. We need an API to the external system. What's that? An API to the external system. We need an API to the external system. So, this is, we'll call this clearing house API. If we create an API that talks to an external system, obviously we have the architecture there. We also have to write our own code around that to talk to our application and the API. So, for this next change, we've got API. Now, we've got custom code that is API to map communications. Or is that the second one you just did? Second one is the application-specific code. This is API's application communication. This is just wiring the application, the API into our system. Now, this is the first interesting architectural change. We've got to talk to an external system. We've seen that there's more to the stocking of external systems than meets the eye. What do we do about our existing functionality? What do we do about this box? Any changes? Yes? The presentation takes up. And all the data is coming back from it. It depends on what data is coming back. At a more general level, we probably want to respond based on what we hear, communication wise, right? So, we have to do what here? Are we only consuming the API or are we also updating the clearing house? Update the clearing house so that's out of scope right now. So, you can just assume that you're querying the API. That would be an example of business question you want to ask the customers. So, the change that we need to make is what? Business logic. Now, we've got, we've added Do we have the functionality? So, we have the functionality from the user interface, and we have the project here. Do we have the project for it? No, it looks like we didn't have the project or it's on the floor somewhere. Which is usually where business logic goes. So, we have the project. Do we need to refactor that? Yes, absolutely. We're going to be talking to an external system to our own. We've got to make a change, right? So, here we refactor project. Yeah, this one we we do suspensions for. Is there any implication on the user interface? Still need the alert right? No. We've got a nose over here. You say yes. We need the alert right? We know we have it. The alert is here from last round. Do they want to know that they disagree? One at a time, please. We'll have a chance to have all kinds of questions with these two groups. Say that again, ma'am. Do you want to know that they disagree? Do I know if they disagree? Does the answer from one system is that significant from the answer from another system? Do we want to see if there's a conflict? We may. These are the things we have to worry about with our business customers, right? In all honesty, yeah, we probably change this from a fraud check. During this exercise, we're not going to really get back to the fraud check. It's okay to just say that user interface is good. If there's fraud, there's a flag and you can go figure it out later. So far, what we've got is we've gone through two rounds of the game. The second round is one where we've had the first interesting architectural change. When I say interesting is a relative term, they're going to get a little more interesting after this point. We're going to have an architectural change following business logic. Clear as mud, right? Yeah, we'll do the update in just a second. As we go through this, the way that we're going to do this is we're going to have about a seven-minute segment where I'm going to give you the change. You have a minute to interview me as a customer and then you adjust your architecture. At the end of that, we're going to have a very quick quality assurance round. Quality assurance is past fail. If you fail quality assurance check, of course, you know, you don't want that. But then when we're done with that, we're going to push the change off to our current architecture. So it's really two parts. Discuss the architecture, lay out what you're going to do, plan for it, and then afterwards you're going to go back and you're going to apply it after we have a chance to look at it. So are we clear so far? Somewhat clear on how this works. We're going to go off the rails a couple of times. The important thing here is that we try to pick out something interesting about this. Over the course of the exercise, if you see a pattern developing, if you say to yourself, you know what, we keep touching this stuff, or I keep having to change this code, identify it. Make a note of it. These are the things we want to know. We want to learn what we discover as we look at architecture from a higher level view. If we don't discover anything, then I'll have to tell you all the discoveries myself and your discoveries might be mine. So, we're ready to play. Excellent. Let's make these adjustments so that we're also ready to see for an architecture. You should have an API and a specific system or an external layer of things. And the refactored project will keep a complete change. Those are already up. We're just clearing it back. It's time to move on to the next round. Now is where you start playing. Not going to be on my rails anymore. You'll have more fun with it now in five months. Let's talk about the next change motivation. On your sheet, as you're tracking this, please write down the change motivation so you have traffic on your sheet so we can see what caused and what changes through architecture. At the top of the sheet, you just want to identify it. There's new business rules. This is competitive. This is competitive pressures. Auditors from the accounting department now must approve any claim that's over $5,000. So, you can't, you adjust or the person that's actually doing all this work right now cannot approve a claim by themselves that's over $5,000. So, we've got auditors that are going to come into the workflow now. That's the change motivation. You have a minute to interview me. Any questions? Yes, sir? So, are they working on their own system or are they actually working on their own development? Auditors will be working within the same software system. What security roles are they going to have? Only auditors can approve checks over $5,000 or settlements over $5,000. So, you have to make sure that whoever does the approval is an auditor. You need to know who approved which auditor approved a claim of that amount. Can an auditor return a claim for clarification or ask for more information and have it resubmitted for approval? Or is it a one-time only pass bill? Okay. So, don't worry about the circling back. On one rule that you have to enforce the business logic here is if it's over $5,000, auditors have to approve it. You cannot close. You cannot settle a claim until the auditor has approved it. Can an auditor close it? Can an auditor close it? No. All they can do is they can go in and they can say they authorize it. It's still the adjuster that's closing or settling. Any last questions? All right. Is it binary or disapproved? For the purposes of exercise, yes. Approved or disapproved is the main two choices. Okay. Off you go. Report your change. So, we need an auditor. You're changing. You have format. So, we need to know. Okay. Can I get our attention for a minute? We have two ways that we can do this. One way is that each of your teams will learn individually. The other way is that we all learn from each other's teams. My recommendation is that you actually listen in when we do the QA. I'll be as brief as I can with each of the individual groups. And we all listen in on that. Otherwise, if you're still working on your architecture with somebody else being quality assured, you may miss something important that they picked up on or vice versa. So, is that okay with everybody? Whatever you've done up to this point, it's good enough. Let's find out if you have passed or failed. I've got my notes. I've got my stickers. Let's start with this group over here. So, the business change is auditors must approve anything over $5,000, right? Did I capture that correctly? Yep. So, what they did is they added new user interface logic, custom user interface logic for auto review. I'm assuming that this is something from the auditor teams. That's a new user interface for the auditor. Good. We have a workflow engine. Oh, they added architecture. Cool. Are we good? Yes. Thank you. We have a security framework. What's the security framework for you? We provide infrastructure for the roles. So, authentication. Excellent. We've got cell plane, access control. Did they need business requirements? I don't know. Oh, we've got the auto log, of course. Very important. They need business requirements, we think? They over-engineered with the word quality. We'll find out. I'm going to give them the three stickers. Looks like they've got it. Remember, change log states make new stickers. Over here. We've got a new auditor UI. The auditor UI is the place where we go and do approvals. We've got a refactor of the settlement. What are we going to do with the settlement? When it comes to that. We can see what the auditor did, right? They added Active Directory authentication system. More architecture. Is that good? Active Directory. Is this internal functionality or is this an external system? External. Is that correct? What's the problem? That's the code interface. That's the code interface. It's on the green sticky. That's the framework sticky. We've got a fail on Q1. Next one. I'd just like to point out that the color coding these guys are using there's some experts that want to say we'll collage it later. Experts use color coding of the darker stickies for framework and the lighter stickies for custom code. What's their bias? John, you've heard of XP, right? Okay, it's a lot better than this. So here's what we've got. We've got authorization persistence. We've got refactors, planes, user interface or business logic. We've got auditor approval. We've got refactor, the create clean process and logging authorization. They get the business requirements? Absolutely. We've got new architecture. The frameworks are components level. Not yet. Stream sticker. Everything gets a cast. Okay, role based security. Role management. Now this is the presentation layer. So are you creating user interface for roles? Okay, so you actually created the user interface to manage all this. Now these guys are getting down to the point line. This is good stuff. It's Skull, but it's good stuff. We've got a refactor there. What's that one? It's returned something. Well, if I can't read it, we're going to have to give them a fail. So, what we've got here. We've got Otters, Buster Proof 7 over 5K. That's change authorization. Thank you for knowing that. They've got it actually on here so we can look at the changes as we go down. Refactors 7, make UI to accommodate the limit. We have authorization of the business logic and we have refactor of the business layer. Now the refactor of settlement UI to accommodate this. Can this imply that an auditor is working with the system? They're going to refactor the settlement page. Who's using the settlement page? The agent. The adjuster. Not the auditor. So if we refactor existing screens for a new role, is that allowed? I know we do it. But is that a good choice? It's not. It'll work. They're going to be bit by it later. I'll tell you, but... Okay, last but certainly not least. It's going to be hard to say. Alright. We need a login page. We need a login page for auditors. Absolutely. We've got auditor, proof and reject user interface. They get right to the heart of the matter? Absolutely. Check claim amount. They have rules here. The system that's going to check claim amount. They've got rules and permissions added. Rules and permissions. How are you going to accomplish that? Custom code? The name of it. Okay, perfect. Now, you'll notice the LDAP is sitting over in their external systems. Right place for it? Absolutely. Free sticker. Alright, give them a hand. Free stickers. Thank you. Thank you. Alright, for the next round. If you haven't already, make sure that you open up your architecture. Leave your stickers on there. Make new ones so that we can see the change. Here's our next round. We're going to go a little faster now. Here we go. The CIO is playing golf with the buddy of this. Who happens to have a proprietary arcane authentication system that he's selling? Guess what? He lost the last goal. Now, you have to implement it. You have to take whatever you've done for authentication and throw it away and replace it with this external system with this really funky interface. Detailed, not important. You have three factors to your authentication. Regardless of how it is right now, that's changing. One minute questions. So it's not a standard space at all? Non-standard space. Never even heard of that. What's that? Yes, you have an API. I don't know what to tell you about it, but we have an API. I'm sorry, say that again. Get your place. Don't worry about the user who thinks that that's an external system. So interacting with the user. Not to worry about it. Question. Doesn't matter. You guys pick it. You guys pick what the API is. Okay, last questions. Yes, sir. You have to buy it or actually use it? Oh, you bought it. You're standing here telling you to get off my channel. You don't. You don't. You're going to hire me to commit and do the quality insurance. Hold on for a second. One more question. The authentication is an external system. The authentication is an external system. You will talk to it. Do all your authentication. Okay. Go. If you haven't already, stop working at your architecture and let's take a look at what we've got. I've noticed, based on our time, we have 20 minutes left for the session, unless you guys want to go to 7A. You don't want to go to the car to do you. I might even try to compete with that. Is it this to the party? I'm going to try it. We're going to try to get through two more rounds. Here's what I want you to do. I want you to look at this yourself and just ask the questions. Based on your needs here, did you add the external system? Yes or no? Did you go into that external system? Yes. Did you refactor your authentication and your business domain to match that? Yes. Don't worry. We're accounting for that. Oh, you're accounting for it? Yes. You have answers, right? Next round. Give yourselves a name. Here we go. This is going to be fun. Find us a relative target. Are we ready? Are you ready? I'm going to do a little bit now. Is it an option? Yes. Are we using the embassy? Yes. Do you have any questions? No. Go ahead and move your architecture. I apologize about the time pressure. This is, we're trying to get a lockdown in a short amount of time. So the most important thing is that the kids change. Are you done yet? Are you done yet? Next round. Are you ready for new business requirements? Excellent. Remember that clearing house system that the government mandated all things, that centralized clearing house. All the vendor went out of business. Got a new vendor there. That's a completely different system. Completely different API. Whatever you've got that touches that has to be reflected. Ready? Questions? Any questions? Any questions? Any questions? Any questions? Any questions? Full拿. Okay, time. Put down your architecture. Do you have a new API, did you rewrite the API? Yes. Did you connect to the new, do you show the new external system? Yes. All right. Did you change your code? Raise your hand if your group changed your functional code. Did you change your functional code? Did you change your domain code? Yeah. Did you change your domain code? What did you change? Touch the... Cross. Yeah, the fraud check. That's the fraud check. That's because I told, now there's something different that I told anybody else that asked me. What did I tell you guys? That the functionality is substantially different. Substantially different. So they realized that if it was substantially different enough, they're going to have to touch their functional code. APIs are great for abstracting system communication, abstracting functionality on two sides. Sooner or later, you're running problems. Right, John? He's giving me a look. I love that look. Okay, so we're going to put an end to the game right now. I apologize. I was hoping to get through a few more rounds, but if we don't stop now, we're not going to be able to talk about the big picture. So I want to go back to that. Let me just show you a couple of things that you would have been in store for having had a little more time. Let's see, we had hackers that were going to break into the system that were requiring you to print all your data from the back. We had a bad business decision of quotes have to be submitted electronically. So all those shops that would call in quotes from them from that point forward couldn't put passing quotes anymore. Of course, that sort of thing never happens in real life. Most bad business decisions. Mobile submission tool. You'll give your insurance the ability to submit a claim from their mobile phones right on the spot. Actually, has anybody seen this? It actually came out with, I think, Allstate recently. Really cool. Great idea. So this is where the inspiration for this one came from. All right. The insurance company acquired somebody else, and now you have to be able to at least view data, claims data, and the other system. How many have you ever done integrations at that level? Acquired a company, integrated their systems with yours? Fun stuff, guys? Sucks. Sucks. Badly. All right. Let's see. Change regulatory requirements, not important. Oh, former insurers. They sue because you lost their data in a hacker incident. So now you have to go back and you have to change your logic to make sure that if anybody's policy goes, if their policy goes inactive, 90 days later, their data has to be purchased from the system. And the last one is, remember that authentication system that your CIO bought? Well, the one guy that knew how to run it was laid off because of the lawsuit. So now nobody knows how to do that. You have to rebuild your authentication from scratch. Down the road. You know that? You know that? The serious question about all that is, do these things happen in real life? Yes. Yes, they do. They happen all the time. So these are a little bit more frequent than others. These are the functional changes. Business changes. The business pressures are the most common changes. But these other things do happen. And we have to deal with them architecturally somehow. Did we see any patterns as we went through this? And I realize we didn't have a huge number of rounds. But what sort of patterns did we see as we went through these architectural changes? Anybody? I want to change the urge to overengineer. Is that that again? The urge to overengineer. The urge to overengineer. You want to protect yourself from the future, right? How do you protect yourself from the future? John, how do you protect yourself from the future? Write lots of tests. Write lots of tests. Okay? That's one way to do it. All right? What else? How else do we protect ourselves from the future? Keep it simple. Abstract things. Have interfaces. Key points. Okay? Abstraction. How many of us have a tendency to abstract before there's a real need? I'll be the first one. I have written full on front to back frameworks just because I thought it would be cool to have functionality. So I'm definitely in that camp. The important thing to track there is when we're dealing with architecture, the thing that's really interesting to us is the cost of change. How much does it cost to change our architecture? Look back. Find your sheet. If we change business logic in the existing application, is that very expensive? Generally speaking, in our experience so far, was it expensive to change our business logic? It's mostly adding your factor, right? Tens to be high risk. Tens to be high risk. Okay? It also goes down to certain channels. These guys over here, if you look at their architecture, it's a lot of custom code. Okay? And that's fine until there is a major C change in how your application works. Then you have major refactoring. Okay? It's a strategy. It is something that you have to choose. You have to decide which way you're going. So there's cost. Does it cost us much to replace a framework? Yeah. Yes. Speaking from experience. How many of you ever swapped out a framework in an existing system? One? Yup. That's the pain over there. You guys are still twitching. Okay? It's very expensive. A framework's supposed to make things easier, right? Yeah. But at the same time, if you have the framework there and you need to change and go away from that framework. Now all of a sudden it's really expensive, doesn't it? Okay? What else is expensive in terms of architectural? What sort of things from our list that we see? What was I to have on this? Database. Database. Why is the database expensive? Or because it's such a thing. Now, if you did that to yourselves, I didn't know what to do with that. Okay? Changing external systems. Changing major pieces of the front. That is a framework just like anything else. It's a persistent system. It's external. But if you try to swap databases, how expensive is that? Yeah, that's great. Okay? You pay a lot. That's expensive. Okay, so the game here is how do we keep from having to pay these huge costs over time, right? I hope that's the game is up. Do we like how you cost? Well, maybe you guys do. I don't know. There's a lot of great work going on over here. Available hours. It's all depends on how many hours you can charge. One thing you kept saying is it's expensive to change. To change. To change. Don't build it until you need it. There's one approach too, right? A lot of people, when you're building software, a lot of times will say, I think we might need that in a year. You can always throw it out in the future and it's... I mean, don't build it until you need it. Make it flexible enough that you can add... Hold up, hold up, hold up. Sorry. Let's get your point of time. Don't build until you need it. What's the acronym for that, John? Over in the HB world? Yagney. You're drawing your prismatic tool down, that's it. This is actually the intersection of Yagney and Eagney. You aren't... You ain't going to need it and no, I am going to need it. So we're getting into that boundary area, but you have to have a... You're saying there has to be a real reason for me to put it in there, right? Yeah. Okay, don't build architecture unless you have a real reason. That's a strategy. Give me some other strategies for architecture. So on a sticky, we had workflow. We were thinking about a workflow system, but that didn't ever materialize in our architecture. Okay, so they were thinking about a workflow system. Would it have benefited that very much in the rounds that we had added workflow? This is the auditor thing, right? Okay, would it have benefited in that? Yeah. Maybe. They pay more for it, right? Yeah. You pay more for flexibility, so they add a new system, they pay more, it's going to take more time and effort to invest in that. But if that workflow change is coming in the future, like for instance, we now have claims processors that do the entry work, I'm sorry, claims entry people that do the entry work and the adjusters now don't do entries, that's a workflow change, isn't it? Guess who's going to have the cheapest amount, who's going to have the cheapest change when that particular functionality comes around? That's these guys, okay? There is a certain amount of betting that you do. This is really like handicapping a sports event. As an architect, you really have to compare these things. What is the likelihood of this changing, that changing? You've got a list of things that change there. What are the most common changes? What changes most often? External systems. What's that? External systems. External systems for you? What changes for you guys most often? Domain. Domain logic, user interface? It's pretty nice. User interface. For you guys, what changes most often? Persistence. Persistence and back down. So that kind of gives you a pointer for where investment is justified, right? It's a bet. To give you an example of this. When I first started at Amherst, we had built a system that was intended to be literally shipped on servers into hospitals. They were just going to sit inside of their room. We had to build security and make sure they couldn't crack into this thing and steal our data. There's a whole bunch of stuff here. We realized halfway through the implementation of that, you know what? Why don't we just do a web-based application and just keep it outside of their environment? Gosh, that'd be easy. I guess how much work went into the refactor. The assumptions that we made at the beginning of the project were completely off base. So we have to protect ourselves from those things. And now we're starting to get into the strategies. You ain't going to need it as one aspect of this. Don't build it until you need it. Well, that's exactly what we did. We didn't build it until we needed it. What we needed it was really expensive, right? So this item has made them a little more beneficial. I am going to need it. Let's build it from the outset. A few other things. What are some of the other strategies that we can use for architecture? Protecting ourselves from paying a high cost for changing architecture. Don't do web logic. Don't do web logic. Yeah, we'll talk about the whole proprietary thing later. We'll talk. Leveraging frameworks. Leveraging frameworks. There's tools out there, right? Leveraging frameworks. What about persistence? There are data layers. I'm going to steal something from what you said. Layers. I'm going to be read. I may be familiar with how networking works nowadays. The evolution of networking doesn't exist today. What sits at the bottom of our networking protocols? Very bottom. Way down. Internet, right? This is the fundamental functionality. This is the fundamental definition of how communication takes place. Do we ever code for ethernet anymore? No. Dude, there's a whole stack of technologies. Each one is more of an abstraction on top of the other ones, but it also has more power. The concept of layers is important. Frameworks are layers. They give us common functionality. If we pick the right ones, do we have to worry about rebuilding that functionality? No. So layers. The strategy of layers. And this one is well documented. As a matter of fact, it's in that architecture of patterns book. That's Robert Fowler. Robert? Sorry. Yeah. Martin Fowler did it. It's in there. It's one of the things that he talks about. Very important thing. So the layers. Thank you for the layers of building the top. The layers is a strategy. So those of you who have spent time around Alistair, 2004, wrote an article. Do you remember the article? I was actually surprised when I was looking for this because I've heard the term for several years now and I forgot where the term came from. And I realized that it was Alistair that said it. Incremental rearchitecting. Back in 2004, Alistair wrote an article on hey, architecture is a problem. Especially when we were dealing with it in a magical context and we were changing over time. So incremental rearchitecting is a proven strategy for working. Anybody summarize that? What is architect? Incremental rearchitecting. Sorry, I slid out for that one. Did anyone summarize that for us? We just did it. We just did like five sessions of it. It's this. Right? It is. In the sense that you're making changes in the system but never did we make a pervasive across the board change the entire system. We didn't. We didn't have to do that. Right. We were hopefully in a position to be able to isolate some of the changes. Who's your weed? Our team here. Right. Do you guys make more sweeping changes? No? I know you touched this logic. Okay. Here's the thing. We refactor it. Yeah, we refactor it. Exactly. The thing that we don't have here is we don't have the measurement of exactly what it costs to do this. To do this versus this, I'll tell you, based upon experience, they pay to have your costs. Whether or not they could actually get that done within an iteration or two iterations is questionable. But now you have to deal with the issue of if I go long enough, if I go long enough without this, is it going to cause problems for me? So you have to figure out a strategy. Incorrect and re-architected is exactly what Jonathan is saying. It is you make changes over time. You have your destination in mind. You make changes gradually. Do not let your system go offline for six months while you're trying to make a massive change. You know, one of the things I noticed was there were several cases where there was something we knew needed to happen, but it was kind of unclear whether it belonged on one side of the line or the other side of the line. In other words, whether it was in the resistance layer or in the domain layer or was in the presentation layer. And in some cases, we're kind of like, you know, we'll leave it there for now, but let's see what the next change is because maybe we're going to have to pull this back or push this forward, right? And that's an example of what strategy. Okay, you ain't going to need it. There's actually a refinement that I really want. And that is last responsible moment. How many of you have heard that sort of last responsible moment? Okay, good. Excellent. Last responsible moment means you delay these decisions until the last not possible moment or responsible moment. You don't know what's going to happen. There are a lot of unknowns out there, so you wait until you do, you can reduce uncertainty. Now you don't have a moving target. So last responsible moment is another strategy that we can use. How many of you have heard of real options? We talked about it on the round table a while ago here in Salt Lake, real options. Chris, can you summarize real options for us? I don't know that I can. The pieces of it that I've seen, I'm pretty sure not the whole thing, but what I saw was basically breaking your possible paths down like basically a binary or more than a binary tree. We could make this decision, we could make that decision, and then trying at the end to have basically the value of maybe $10 laid out. I think that's part of it. I don't think that's the whole thing. It is. You have two different decisions when you're going down. You understand both of them. You actually pursue both of them until one of them pervs itself over the other. That's an investment. You're investing in two different possible outcomes. That's the real option. There's more to it than that. It's originally coming from the financial community, but it works well with software that can be applied between a couple of different options. Implementable until you can. You'll have something real. There's two other things I want to cover before I wrap up on this session. Two other strategies that are really important for architecture. The first one is, in conjunction with incremental re-architecting, there's walking skeletons. You guys have all heard about walking skeletons, right? Walking skeleton is a great strategy not just for functionality and application, but also for functionality in our architecture. If you cannot build a walking skeleton and have function within some environment and have provided value to the application, are you doing a good job of building your architecture? Probably not. I would bet that you aren't. Wrong, but walking skeleton works really well for this. How many of you have gone through the process of creating an architecture that starts at designing the interface, mock it so that everybody can start using a version of it to do their own thing, and then you build it as other people are using the mock implementation of that. Everybody have done that before? Excellent strategy for this. You don't want, architecture should not be a blogger. It should not keep you from being able to build a business. If you're running an agile world and you have new requirements coming in all the time to change your business direction, you can't afford that. It gets way too expensive. You've got to be able to shift direction with your architecture, and that means doing the least possible on work over time and adjusting along with your application. There's no right answers to this. This is a tough, tough field, architecture, not by itself. Just because of the fact that you have to be part, you know, a good sayer, part sports booking, part you know, counselor to the business. For the business people in here, how many of you have had a chance, how many of you are now looking at this and going, wow, I didn't realize the breadth of the impact of changes? Anybody have that experience? One person? All right, well I've made, one person, I've received my goal. And if the business people don't understand this world that we live in, they don't understand the implications of all this. And if you're not telling them this, if you're not going through this exercise and not seeing and letting them understand what happens with these things, there's always going to be a conflict and the worlds are going to be doing this. I love this happening as much as the next guy, but you know, by the end of the day we're going to have a shift to offer, right? There's one last thing I want to leave you with is a concept for a strategy. Necessary architecture has business value. If you're building architecture, the question you have to ask yourself is, does this piece of architecture in a building doesn't deliver business value? Okay, how many of us developer-wise, architect-wise have built architecture without a clear, immediate business value? Oh, come on. No one wants to. Exactly, and we can't help it. This is part of, this is the bet that we make. This is our world. We deal with this. Sometimes we have to gamble. Sometimes we're really wrong. I won't tell you about that, because I'm wrong. It's that you won't think I'm as cool as I am. But it's a complicated field. The most important thing you can do, other than the strategies we've talked about, is to understand it. You need to speak the language. You need to immerse yourself in it. If you have somebody that comes to be an architect and they can't code their architecture, stop listening to them. Okay, so that happened to talk to me last month. Architects must code. They must eat their own dog food. If they can't do that, they're really going to give you an architecture that works. Thank you for your patience. This was the first time I ran through this exercise, and as you can see, it was pretty frantic. Hopefully you got something valuable out of it. If nothing else, the conversation, and just the exposure to things change over time. Once we all take a step back. Any questions before we wrap up? I have a question. What about a backwards compatibility strategy? We talked about growing an LLAP bridge on top of our new authentication API, so we didn't have to rewrite anything else. What's your experience with that? For re-architecture? Does that make sense? What are you saying? We have new business changes. We have things that are going to change our architecture, but we wouldn't maintain backwards compatibility. Isolation. Isolation, exactly. This is a good strategy for slow migration. That's actually one of the baseline strategies for doing this incremental re-architecture. But there's a corollary to that. If you do this, you also must at some point go back in and fix it. Backwards compatibility is great up to a point. And if you want to go up to a point, you can just talk to Microsoft. That's a good question. As we were talking, you were saying that changing persistence is actually more expensive than domain and interface, right? That makes sense to a point to me. If you go from SQL Server to Oracle, yes, it's very expensive. But if you go from Java to C++, I would consider that way more expensive than the database change. Is that correct? Is that just a domain logic changer? Is that a fundamental architectural change across the board? It's really a matter of scope. You can take any two examples, and they can be out of balance with each other. The generalities are changes to frameworks or generally more expensive to changes in business logic. Generally. Any other questions? Again, thank you for your time. If you have any specific feedback, I take bad feedback too. I want to make this better. If I call time too soon, let me know about it. I appreciate that. Thank you, everybody.