Splitting the monolith | Jimmy Bogard | #LeadDevAustin

Thanks. Mary I, do know that I'm standing between you and lunch so, let's keep this short right. The key to splitting a monolith is a very sharp axe, okay. That was horrible that was my last bad joke of the day I promise. Slug marry SID I work at a consulting company here in town called head spring and a lot of what I do is work with existing legacy systems, to break them apart into smaller. More modern systems, now, I've worked there a very long time and we didn't call these monoliths, when I first started they were just legacy, systems or mainframes. Or things like that but. Now we call them monoliths micro services so hey we got to get with the times I guess and so, I wanted, to talk about and. One, case study in particular, in. This, this. Application, dealt, with a, company, that did life insurance, and annuities which. Was actually a bit of a depressing, domain to work in because basically like the comics money when we die so, there's a little, bit morbid but, this organization, company had been around for over a hundred years but they started in like the mid 1800. Or something like that so they've been around for a very very long time and the. Existing, system that they were dealing with was also around for a very long time has actually started sometime. In mid 70s, so, this existing code base was, over 40 years old it. Probably were flannel, in the 90s is a solid, Jenek citizen, system and. This. System though had got this company to where it was today this. Company was the leader of their, industry. Because, they. Had this system for four decades that none of their competitors had, but. This system like many systems had started to show its age and could, no longer keep, up with the business the. Workforce itself that was responsible, for maintaining. This existing. System was, also aging out of the company in fact, a lot of the developers, we were talking to we're, reaching a retirement, cliff in five, to seven years the, developers, were actually pensioned, which is like unheard of right nobody here has pensions, anymore but, they've been around for so long they actually had pensions. And once they hit 55, they, were out the door going, ice fishing or something and we would never see them ever ever again so, a huge risk to the company that this existing, code base had all this knowledge pent up in these people they were about to just leave and so. The IT, organization saw. This said, okay we have a really big problem on our hands this big cliff coming up so, why don't we just buy a new system that will replace the existing system and that. Unsurprisingly. Failed. Magnificently, because this, is a custom, system that had been built up over decades and, you can't just take some off-the-shelf, product, and expect it to replace all, that sort of things that have built up over the, years so, after by didn't work the, company looked around and said okay clearly, we, can't buy our way out of this problem so why. Don't we do something new and they looked right and said well it seems like a lot of people are talking about micro services so. Let's do that thing whatever. That means so they said clearly we have a monolith and let's go to microcircuits. Now. One of the problems I typically see and this kind of approach. Is it. Can be difficult just to define what exactly is a monolith, is it just a system that's really old like, it could have children and the children could have children as well is. It just that it's very large, but. I've done with a lot of large systems, that still serve the business very well so what differentiates, large, systems, that do well for the organization, versus, large systems that don't so. I looked at this and said none, of these definitions are that good like everyone just says model that's bad micro, service is good and for, me a micro a monolith is really a software, system whose, design data, model and and user interface, combined, to many multiple. Competing, business, domains, into. One a single, system, and. Application. And data model and it's that competition, that, really tells us if that system can no longer be brought forward anymore if that, system has, too many different people having too many different concerns inside of it then. We're going to have a, point. Where we can no longer bring that system forward anymore and the system development. Basically grinds, to a halt so, we. Don't want, this right because that means that the system we're dealing with can no longer grow with the organization, and I. Hear a lot of like instead of doing monoliths we should just go do micro services but, there's a lot of different things between a, big system that doesn't work for the company more and there's really small systems and on, top of that when you look at the definitions, of micro services they're not very descriptive, the.

Micro Service book says a micro service is software. That is small and does one thing well which. Are all hotly, subjective, criteria, that. Anyone could point at anything and say look that's a micro service why well because it's not a monolith, so, I don't like that so. I had my own definition which was a micro, service is a service-oriented, architecture, in which were, angling, towards the, smallest, possible still, autonomous. Boundaries, so, micro services aren't applications, and not components, that out widgets their app modules, there, are still services, but. We're trying to build towards small, boundaries. So. In this organization, this life insurance organization, the first thing I wanted to understand, is well, what's wrong with the existing system I mean I see it's like old, and green screen that's but what what exactly about it is causing, you problems that, mean you can no longer move forward as a business, on top of this technology and, so. His main business challenges, was one I want, to modernize the work force our. Existing. Processes are, completely, tied to the interface of this legacy system, if we want to try new things try. New business ideas we, can't because it's all stuck in this existing, system so. In a new system we want to take all the things that were done well with that existing system, but. Hopefully, do them better and try, to improve where possible, and as big metric he had was an existing, legacy system, we, only can grow our, revenue, grow our business when we introduce new products, as they sell something new in the market an existing. System we've, proven that we can only release new products once every five years which, is a very very long time and as, yarn mark for success. And the new system would, be to releases, a year two new products a year so, that's an order of magnitude set. Of agility. That he wanted to go for from, the old system to the new system now, in my head as a consultant, I know like technology, is not gonna solve all of those problems like. Going from 5-year, releases to six months releases for products, that touches everybody in the organization is gonna be a lot more than just like going. From green, screen to like react, like that's not gonna solve all of your business, from so the system that we design has to be able to enable, those kinds of releases, I also. Talked to the IT folks to say what, are some of the things that you want to enable in this. New world that you have I. Heard, mainly, buzzwords which is kind of typical because. This, organization, was mainly used to dealing with the, old existing system, and so, everything, they wanted to do in the new system they wanted to be able to say you know we are a modern, development shop which, means we're gonna be agile, we're gonna be DevOps e and we're gonna be modernized all the things that I guess, the CIO wouldn't, want to stay, so.

This, Would involve for, us a four-step, strategy, before, Pease we're. Gonna start with gaining, some perspective, and. Exactly what the system is doing today, build. Out a plan for what the first new system is going to be and how we're going to approach the overall problem, build. Out a pilot program, for that first system that's going to go live and finally. After the pilot, program is finished then have a phase, migration. From, one system to the next it's still P it still counts for peace I promise. So. Step one is gaining some perspective, this. Is a step that a lot of organizations I deal with either spend way too much time on like years and years and years trying to gain perspective and analysis or others. To just like Leroy Jenkins right into and just like want to start developing start, building stuff so, it's important, that we, kind of approach it like I can only like how do the modern art masters approached. Like, our masterpieces. And and exquisite. Sculptures that is they don't try to design every, little component, and piece up front and so what they try to do is have a broad sketch, of the overview of what's going on and to provide enough detail in some areas, to be able to get started so, we're going to try to, understand, the what the, who that why the. When the, how of. Everyone. Affected by this, existing. System. So. As part of this we're going to conduct. Quite a few user interviews, and first, and L&R views of everyone. Involved, in this system and along, the way we're going to get a lot of history less like, we'll hear about the story about Marsha in 1987. Who approved that claim by God she really should not have approved that claim and. Of course we have to approach this with empathy. And respect, even, then back her head were like cheese could you let it go like 30 years ago so. As part of this will see that emotions, are gonna run really high a lot, of times especially. As a consultant, when I'm coming in I'm coming, in usually is like the second or third attempt, to try to get off of the existing legacy system so, there's got to be a lot of animosity, and hurt feelings and, just. Tension, and strife between, groups. And side i.t between, groups inside the business so. I have to approach this with. A lot of soft skills which. Are ironically named because they're actually very hard but if we call them soft and so, I have to practice empathy, good. Listening skills good, comprehension, skills, with. The, people I'm interviewing to make sure that I'm both. Hearing what they're saying gaining. Trust and making sure that what I'm building is actually going to support, them and make, their lives better. So. As part of this process I'm really performing. A mapping exercise in. Which I'm trying to map the people the processes, information, and technology, around. This system. Now. Mapping people could be somewhat straightforward you, could just go look at the org charts and say this is how everyone's, organized in the company but, things I try to look for are who, are gonna meet my potential champions, inside the organization, who, are gonna be the people that's after, I delivered for them they're gonna go and advertise. For me inside the company like hey you should work with these folks next you should usually, get your system and your set of functionality, on the doc index because it's, done so well for us I'm, looking for those domain experts who, are the people that can answer the hard questions about, what the system should or should not do and so. I'm trying to build out just a picture. Of who or all the key people involved. In order to be successful, now. This is never gonna be 100% accurate, or. Correct, before. We go live there's always gonna be one group that pops their head up and says wait a second what are you trying to do you can't go live. It's. Usually legal, like that's, almost always the case like someone's, always pops up from there. But I'm trying to find all the people who care, about what we're trying to build and, can either have a handed success or will, be a barrier, to, it going live. I'm. Also going to be mapping the processes. Within the organization and one, great resource for this is value, stream mapping now. A value stream mapping is very popular, in the lien community. And software, but I'm trying to take the business, focus approach understanding, the business processes, at play so, I'm looking for things like how, long does it take from, when a claim, comes in to one actually gets paid out what, are all the steps that happen as part of that process how, long does it wait for, it to take to go to one step to the next and how many things do they do it once all those kind of lean concepts. Come. Out of this value stream mapping exercise, and. It's part of this I'm actually going physically, to where people are doing the work to.

Watch Them actually perform these processes, what, we don't do is send out a survey and say tell me what your workflow is and they get back and they're like step, one open, the application step. To approve, the invoice step three go home like, there's, probably more involved, than just opening and so I'll go sit and look at what they're doing to see okay, actually they've got a whole Excel spreadsheet, over here and they've got post-it, notes all around the cubicle, describing, the actual process that's going on I want to capture every single activity that's going on to understand what, processes, are actually enforced, and captured by the system versus, what processes are actually around the system in between people. This. Will include some information mapping, exercises as well so, all the data that's captured, that's, being read being written both, inside, the system and outside. The system so. Some organizations they're, able to capture a lot of that information inside. Their mainframe or database but, also see like you've. Got a lot of paper files and folders around here and really. Your workflow is just email, and Skype so trying, to capture those sets of information. As well gives, me the complete, picture of everything that's going on I. Also. Understand. Outside. Of just that single legacy, system what, are all the other technologies. At play here I guarantee. If you have a system, that's older than a decade a developer. At some point has, given a connection string to the business and, now. Excel. Is hooked up directly to the production database and critical. Core business functionality that no one knows about is on the CIOs desktop, where they're running the daily numbers and daily reports that's. Absolutely, the case that's why I want to have these interviews, across the organization, to understand where, are these where, are these minefields, these grenades these that that I will I'll, inevitably, run into that, when I switch off that legacy database suddenly, someone, yells and screams that, I've turned off their business. For. The existing technologies, will, start to catalog what we see in that system so, it'll be what applications, and systems are being used what. Functions, and operations are possible in, those systems how, often, are those functions and operations used when, are they being used I'll do a lot of instrumentation, here, to understand this, this, button they say is so critical is only pushed once a year so how. Important, actually is that is, that function, for. Individual screens I look to see when, information is being read versus, what's being written and, we will literally print out the screens and get a highlighter, and say this is this field this is that field this is that field to, understand, for, any given screen I have to replace that what, are all the back in pieces that we have to touch, and. Of course we have to understand what are the dependencies how. Does, this one system connect to other systems and inside, that system how are all the components connected. To each other now. There are some tools to help us with some of these things but. For a 43. Year old mainframe no. There, aren't any systems, to do this so it's going to be a lot of legwork for me to map out how, the different, pieces are connected to each other. So. With this analysis, component done, which. I want to limit to. Ideally. Three months or less like if you're taking a year to do this it's probably a bit too long again, we're trying to do gather, enough information to, build, out a plan of, how. To attack, this overall problem. Now. To build a plan we of course need to look at what are our possible strategies, now, what I'm trying to avoid here, in these different strategies are, things like a holistic. Buy versus build arguments. That will replace the entire, existing, system with, some new system over here that almost never works I want, to avoid things like. Trying. To tackle too many problems at once so, something like Operation, Market Garden, or a bridge too far that's like I have, to have everything succeed. And every, little component, go live if the whole thing is supposed to be successful, I want to pick something that's small enough to be able to go live but, still provides some value to the business. So. This could involve rewrites. Now. A rewrite could mean entirely, new software, that the, developers, write or could me a rewrite that's already been done by someone else so. I could look at the existing system, and say you know what actually this part over here is just dealing with customer, relationships, so, instead of building our own CRM.

How, About when we get to that part of the system we just use Salesforce someone's, already done the rewrite and we just have to plug in our components, to that other piece. One. That I really like is to start, at the edges that, is I draw, the dependency, graph of systems, or components inside the system and say, maybe let's not start and that thing in the middle that everyone's connected to and if, possible can I start along the outside to minimize, the amount of integrations, or connections. I have to worry about when replacing those individual, components. If. I look at the overall business process, or value chain we, can arting, at the beginning, or end of the overall business process, as it, means to minify, the amount of integration. And, connections. That have to worry about as I replace individual components, so. This guy I can start with a sales process or at, the very end of the process. But. Ultimately this comes down to if I'm, going from a single system to smaller systems, I have, to actually define the names of those boxes, that I'm drawing on board so. That comes down to defining, the boundaries, of our different services now. One thing that I've found a few times is people. Assume that the brought that boxes they draw initially are the correct ones, but, over and over I found that the initial boundaries we draw on the whiteboard are going to be wrong and so, we should plan accordingly now. The problem is that it, can be it, may be easy to do things like refactor, code inside, a code base but it's much more difficult to, do things like refactor. Boundaries, of services, so, as much as possible I want to reduce the amount of work if my boundaries are wrong to get it from one place to the next even though if that wrong is just the wrong name if I have the name hard-coded. Into a. Thousand, different places inside, of my service then, that's gonna be much more difficult for me to rename it to the correct. Thing at the end. So. Our. Surface boundaries, could, follow the organizational, structure this, also is known as Conway's, law that, is I look at the information and organizational, structure of the company and say let's build systems, and services to, match what we see in the org chart but. Org charts never change right. Like. Most. IT organizations. I've been with have gone undergone. A major, reorg, within, the last two years and basically, if I just talk to them in any two years they've just kind of read in a reorg are within two years like it's just a constant thing that happens. So. Perhaps. The, organizational. Structure isn't what I want to focus on maybe, I build systems, around, the organizational, structure that I want as, opposed to the organizational. Structure that I have and, this is known as they reverse Conway maneuver I build, systems and services over, what the organizational, boundary should be versus. What they are today, I've, had varied success with this because at, this point I'm dealing with like people's career aspirations, and so, that's really risky to do so, I try, to be a little less ambitious, when.

Trying To just say you, don't need a customer, service department, what you're like no like there's these are people's careers on the line and so I want to be very careful about how. I'm drawing this, kind of reverse picture I. Can. Also look at the value chain to say, for. The overall business process. Over the organization of the, business if the, organizational. Structure actually, matches, the business. Process, over the organization and that business process hasn't changed, fundamentally and, 50, years then, it's probably a pretty good place to, to. Draw my boundaries if, my, organizational, structure does not match the overall business process, then, we can assume that there's, going to be some change coming in the future. Now. That was just the organizational, structure what about the data structure, can I look at the database and say how, about I just draw some boxes around these sets of tables and that will be my new service now. It's never that simple. Usually, the picture, of my database, schema for these legacy systems as, like as big as this wall over here and. I've met organizations, like they've plotted it out they got something pensive plaughter they've, printed, out their attire schema, it was too big so they started color coding things those. Color coding could, be a good place for me to draw my service boundaries but. Ultimately though we will find that there are going to be some boundary, issues between, different. And pieces of data inside my database but, we will have cases where there's like the table, that everybody uses and that table has like three or four hundred different fields in it and so it's this one table that means everything, to everyone, and that's gonna be very difficult just to say I'm gonna lift this one table up and put, it over there and now it's gonna be its own individual, service I. Could. Look at business or functional areas to say well maybe the organizational, structure is a little bit too broad let, me dig one level deep inside of each part of the organization, and see how do they organize himself internally. Inside, of their own organizational. Boundaries and maybe that's a better way that we could look at my service boundaries, or. I could look at value streams that, is the overall business processes, that derive, and define value for the organization, these, are things that kind of capture an entire business, flow these, are possible areas as well that it could define my service boundaries now, the challenge here is that value. Streams too often, cross, organizational. Boundaries so, that will mean that I may be building systems, that have to be used by, multiple parts, of the organization. So. With all this kind of cataloguing definition, of service boundaries, we have to decide, at some point where. Are we going to start and what. I like to do here is to try to catalog, the, different services, that we've identified that four areas of the system and then plot them against. The risk associated with pulling. Those different pieces out, and. Ideally. I could start with something that is very low risk but at very high value, that. Never, like, that never happens there's never a piece of the existing system that is really easy to pull out but also super high value and instead, you always find the thing that is most valuable to the organization is, also the hardest thing to pull out so, I there's probably something in the middle there that's high enough value, but low enough risk that, would be a good first step in the process to be able to pull out I, tried. To catalogue, the different risks associated with. Moving. Individual, components, out and I tried to scale them or try, to score, them, from a people perspective how. Willing, is the group, that I'm going to be focusing on wheeling, to be able to use some new system or are, they so like, in tune with their function keys on the mainframe that any change whatsoever is gonna be highly disruptive and maybe those shouldn't be the first people I start with. Perhaps. Them there's some large technology, risk as well I'm starting to look at how many connections does this piece have to the outside world. Are. There some licensing, concerns that we have to worry about if. This mainframe, lives on for another year, will that incur, another 8 or 9 figure, licensing. Cost to the organization, maybe. Those are the places that from a money perspective I can focus on next as well and finally. Looking at project in scope risk that is are there places in this existing, system that, I know we're going to change in the future is there, some very large project, looming for the existing system that if I try to replace that part I'm now having to do that work twice.

So. In all this there's never going to be a perfect, place to start there's, not gonna be one thing that just stands Allen says yes that's absolutely the right place in fact, oftentimes what I'll do is we'll get a ranking, of these different there's different risks and values and I'll just pretend present, them to the to the CEO and CIO and, it'll. Seem like they're just like throwing a dart at the board and saying we're gonna pick that I, don't care as long as we pick something that, makes sense to go forward. Now. There are some places that are bad, to start at in. The middle step of a process, or a highly, contentious, area or, I know we're gonna part, of the organization, that doesn't, really use the existing system or, maybe it's just like a cross-cutting, concern across all the different parts of the application I, want to pick something that's the, tie enough value that has meaning to the organization, that's going to prove out our approach. Now. As part of this we're going to have to worry, about transitions, that, is going from the old system, to the new system and one, of the things I want to have is to make sure that anything up hold on to a service is going, to be the single source of truth for this, I think one of these is actually Hebrew, for thou, shalt unit test I'm pretty sure but. We want to build as, we're building out these new services they have to be the, owner of that information, they. Have to have their own information. Model that they, are in charge of that isn't leaked out to the outside world so. This is gonna mean that we're gonna have to do things like migrate, data paths from the old system to the new system, and the, way this will generally work is that I start with my, existing, monolith, and hopefully you can actually change the existing system will. Write to both locations then. I modify. All the places in the old system that read from. The old database to read from the new database then. I modify all the places that write to, both places to now just write to the new place and then, finally I go back and remove all the old information from, the old database and it's all going off the new structure completely. What. I'm trying to do though is just avoid any kind of bi-directional updates, if, I have two sources of truth this is going to cause a lot of contention and ultimately. I've seen these kinds of like I can, edit the thing in both systems, ultimately. Fail, we. Can do this. By. Disabling, functionality. In existing, systems so this could be things like you're. Now going to be approving invoices, in this new system so just remove that screen, in the existing system or maybe we can't remove the screen but we just disabled, that function, so they can't do it in the old system going, forward. So. This comes to our next P which is going to be the pilot program which, is trying to come up with a, complete. Running, system and application, that, still performs, all the functions of the business but doesn't necessarily have all the bells and whistles of the existing system so, this if you took anything else away from this it's it wouldn't be a complete, running system we. Want to have the minimum pieces available to be able to perform whatever. That function is as part of it. So. Part, of this is going to be building on a dedicated, team that is we want to make sure the people on our project, aren't also assigned to other projects, competing, for time, and resources for, what we're doing so we have to put police, tape around, even. Now sometimes physically moving these people into a separate place to, make sure that they are being pulled off onto other projects, we're. Going to be destroying silos, pulling. People from multiple parts of the organization, you probably have a project, management mode. You probably have QA you probably have operations.

Or DevOps organization, all these gonna be pulled together into, one single team to ensure, we're, delivering for success. Developers gonna want, to. Customize. And make all the bells and whistles for this very new application, because this is probably the first chance that, they're getting to build new, software, so they will want to make it as like crazy, and customizable, as possible where we're going to have to try, to constrain what we're trying to build here which. Could be self-contained. Systems these, work well of, a, self-contained system is a system that is completely wholly, owned by one part of the organization, and no one else uses it this. Works well for backend applications, or, it can be more like a composite, UI where, I have multiple, services coming together into one single comprehensive, user, interface this, is mainly, used for customer, facing applications versus. Those back-end sort, of systems. There. Will be navel-gazing, and bite shedding by the developers, this is a very complex problem to solve and they will want to solve the, very, simple. Problem and spend a lot of time on that versus, trying to reason about the complexity, of the system as a whole they, will want to argue, endlessly, over what technology, to use the. New hotness was whatever nan Jas, framework. Is is new today versus, like the old you know like reliable, technology that's kind of boring to work with whatever, but. Through all this the, the team is almost certainly not used to these kinds, of new techniques and technologies, and so we'll have to invest in training to make sure that they are able to be able to deliver on this, new kind of system that we're building today. We'll. Have to constraint scope to, make sure that the business is not putting too much into this first system and we'll, have to constrain goals as well to make sure that we're not trying to end world hunger with, this very first system we're trying to put out the door what, we're trying to get to is a complete, solution that is still a complete working application perhaps, just, for a few, individual, workflows and use cases but, it's still enough of a complete system that someone can look at and say yes that does validate, overall, approach. Now. From here on out B, comes into. Our last section which is a phase. Migration. And. Eyes in my head picture, it very similar to something us as Texans o near. And dear which is highway. Construction, which. Seems like endless here in Texas and in. This highway construction we're, not entirely. Replacing an existing highway, with a new highway to the side and one day and flips the switch and everyone's on the new highway and said, were we're migrating one, component one set of a mile, at a time with. A new system on the side of the old system that is a little bit bunk bumpy and janky to go back and forth but, eventually the new systems in place but at no points was, traffic. Ever stopped. As. We're deciding, what is going to be the next service we still have to perform some of the risk, assessments. And measurements, we did before because the, picture could have changed as we, pick out that next system.

We'll. Be looking at staging, our teams as well that, is instead of having individual. Projects, for H individual, service instead, what I want to do is have a more staged approach that as I'm, delivering, one, part, of the system there's, always that at the same time the planning folks are looking, ahead and analyzed in the next system we should be looking at so there's this continuous. Delivery approach, as. We go through and replace the, rest of the monolith and. Finally. The most important question that the business wants to know is. When, is it going to be done like. They want to know like how much is left and you say we have, 13,000. Story points left whatever, that means. So I try to have some kind of tangible measure of progress whether. That's users. Or products. Or maybe it's geography, like we've migrated, these states maybe, it's people in the organization, or just screens, or tables, I think, that's more tangible, in business focus it says we, are nearing the end of this overall project. So. Some. Final lessons, in performing. This you, probably know it's like I didn't talk at all back technology because, I've never seen a project fail or. Succeed slowly. Because the technology, it's always because of people aspects of it we need to make sure that what we're building is actually going to be solving. The overall business problems, in a safe way that gets them off of their existing system, we. Need to practice compassion of, our, users even the system, or disdain, we, don't have negative words to say about the existing system because that, system would exist where it is today unless was actually successful for the organization, we. Want to have a product mindset, over a project mindset, if this system took 43 years to build is going to take hopefully. Not 43 years to replace but it's not gonna be replaced in a year. And, finally of course we will have no civil Berlitz kubernetes. Is not going to just make this problem, infinitely, easier for us we. Have to actually it. Is a very hard problem to solve and there will be a bumps along the way. So. If you want more information about this, two great resources I found one. Is the Phoenix project a book, that really, just invented. The DevOps movement and then the one is that other book the value of stream mapping book, so. Thank, you all very much I hope you enjoy the rest of the conference and.

2019-11-18 14:35

Other news