Sandro Mancuso

[00:00:15] Okay, so
[00:00:18] Look, we, we as a company, like we, we are a consultancy company, we we specialize in software craftsmanship, so most of the work that is relevant for for this talk, uh, is, I've been involved with Agile since the early days and then, uh, I got heavily involved with the software craftsmanship movement. Uh, and through the software craftsmanship movement, I end up, uh, being very, uh, how can I say, uh, focused on quality, on testing, uh, and I end up writing a book and then talking about software craftsmanship a lot. Uh, But what happened was a lot of companies that adopted Agile in the past, they, they felt that there was something missing, mainly on the engineering side. And, and because of that, they start looking at software craftsmanship and they wanted to, to improve their systems, improve their technology, the way that they build soft, uh, software.
[00:01:18] And, and continues today is almost 100, uh, people, uh, company. So, what happened to us was, uh, a bit unexpected in a way, because as companies wanted to adopt better technical practices, the the companies that were focused on, uh, improving their technical practices, improving their systems, uh, modernizing their technology, they tended to be a little bit larger companies with a very large ecosystem full of very old systems with old technologies, uh, and we had to apply software craftsmanship, uh, and techniques from extreme programming and many other things into environments that were difficult, that was not just like starting from scratch. Uh, because when you start from scratch, you don't feel the pain of bad software, right? So you feel when you already have those strategic systems. And and almost as as a as an accident, we end up becoming specialized in what today we call software modernization projects, because we are, we were not just trying to change the the practices, but also modernizing those systems. So,
[00:02:32] this talk, the the idea for this talk came because I believe that most people, uh, watching this talk, maybe the ones with a more technical background, we quite often see a lot of issues. We see a lot of things that are not working well, the system is not well designed, or there's no test, and, and so we see a lot of technical problems. And the people that has more of a business background, they quite often are also frustrated that everything takes a very long time to to do, so every feature that they want, uh, it seems, uh, for them it takes forever, right? So,
[00:03:11] So then we have all these different types of people, all of them seeing different types of inefficiencies, uh, in the processes, in the software, but quite often we fail to make a case to fix those those things. So how many of us, uh, thought many times, why other people don't see those inefficiencies? Why can I, why I can't convince them to give us time to to refactor this or give us time to change this or go to the cloud or whatever you want to to do. So, so that was the the the inspiration for this talk is like, uh, for anyone that wants to drive technical change, how can you go about that? Because we had to go about that ourselves, right? So for many, many years now, that's what we've been doing. We, we need those companies have issues, the people normally speaking to us, they want to to drive those changes, but they fail to make a case, they fail to to associate a business value to it. And this is why we are calling like a strategic approach to software modernization, right? So,
[00:04:16] First of all, you need to define, uh, a little bit of what software modernization is. I want to make a distinction here. is that, uh, software modernization in the context that I'm talking about is not about those small refactorings, or, uh, retrofitting some tests, maybe that the system doesn't have tests, so you want to add some any tests or or or refactoring. For me, this is part of your normal process, right? As you are working with the software, you you have the boys count rule, you are cleaning up a bits and bobs. You are adding a few tests here and there. Uh, this is for me just normal part. But for me, when you talk about software modernization, you're talking about something more strategic. It's something that is far more longer term, that is much harder to change, it will have an impact. Uh, so, so normally, uh, and also it cannot be done everywhere, it needs to be very focused. So that's how I like to define it, there is a continuous process of improving strategic systems in order to increase business agility, right? So, for me, those those words, they have a meaning. First of all, it's not a thing that you start and finish, if there is a business that relies on technology, relies on on certain systems, they should have a continuous improvement program anyway. And, and that is focused on the strategic systems. That can vary over time as well, as the company evolves, as, uh, the business changes, different types of systems or different types of features will become more or less strategic. Right? And the goal of changing those things is not just because we want to, right? We need to have a goal in mind and normally, the technology should be powering the business, and that's why the focus on business agility. So,
[00:06:00] I'm trying to emphasize this because for most of us, many of the technical with technical background, we want to drive technical change, but we cannot drive technical change if we don't relate what we want to do to business value. And that's what I'll be trying to cover to cover here. So, why do we fail to make a case for those changes? If there are so many inefficiencies, so many, so much frustration from so many people, why do we fail to make the case?
[00:06:35] Quite often, uh, again, I'm not saying that everyone is the same, I'm just here what I'm just reporting here what I see more often, right? So, but very often, when we are trying to to to drive change, uh, we tend to propose a solution, right? So technical people are very good at of going to business and and go with a solution. You need to adopt, you need to architect the system, you need to go to the cloud, you need to adopt microservices, and the business have absolutely no clue about all of that, right? Even among ourselves, this is how we also don't agree even among ourselves, because someone will say, you need to adopt Docker, or you need to do, I don't know, a technology X. We go with solutions. Even for me, Scrum, Agile in general, extreme programming, all those for me they are means to an end, right? So, but if you want to uh, help people to adopt certain practices, we need to understand what's the value. So, so I think this is one of the the reasons that we, uh, struggle. And for the the people like, for example, some some heads of departments or or, uh, product owners, that they are, uh, sometimes they need to make a case to get the budget approval. They can see even the business value, but they don't, but not in enough depth to make a case to approve the budget.
[00:08:01] So again, so we need, so what is lacking is we need to find a way to align that business and technology. So, I'm going to give you a few examples, but before we even go into the strategic approach, we need first of all to build a common foundation, that I say. Uh, so one of the the first things that we need to understand is like what are the main drivers, right? So, uh, that that we have, uh, for for software modernization, right? Because those things, uh, software modernization project, it will hopefully create what I call a long-lasting impact. They should be strategic thinking, uh, things, right? So that's if you want to drive that change, how do you position that? And there are many different ways to position that. So, as you've been working on that for years now, in many different projects and companies, the motivations or the drivers, they sort of fit into some of those six categories, there might be other categories, but I try to simplify a bit. Uh, so, so those are the common categories that we have as drivers. I'll go into a little bit more details, uh, into one of them. Like sustainable change, for example. Uh, a common problem that we see everywhere is a lot of waste in the process, like for people like, uh, this is a flow call, so I believe that a lot of people are into lean and Kanban and stuff, so value stream mapping. So, there is a lot of waste in the process. So, one of the drivers for software modernization is to remove, is to create this sustainable change. In order to create sustainable change, you need to optimize your process, uh, and then you need to reduce technical debt, you need to reduce the cost of change, right? So, you need to reduce the lead time. So, and for that you need to automate repeatable process, you need to to to apply, uh, to have a more modular architecture. So, it's important to understand when you are trying to drive a change, what is the driver? What is the kind of business value? So, sustainable change is a very, very common one.
[00:10:09] Uh, so, innovation. So, a lot of companies, they lost the ability to innovate. So they, they, they complain, for example, we cannot, uh, build a a feature fast fast enough. And there are also, I, uh, we realize that there are different types of innovation. So, for example, companies that are more on the lean startup approach, let's say, they have a very innovative product or feature, right? So, but it's a new market, it's not that is, it's not an area that is very easy to do user research. You just need to push it out as fast as you can, collect feedback and then inspect and adapt, right? So, you build something quick, push it out, get data, understand the data, adapt. So, in order to do that, you need to design your systems to enable that. Your systems need to be designed in a way where experiments are easy. And you don't normally experiment across your entire system, mainly large organizations, you might isolate one area where you are, you are experimenting, which means that area needs to be designed or re-architected or even modernized in a way to enable that speed. This is the same for a more, uh, experimentations in more, uh, stable products, for example, we work with a lot of large organizations where they have a very well-defined set of clients, so before they release a feature, they do some user research. They speak to their clients, they figure out what what are the core features that that their clients are waiting for. So, and then they keep releasing one after another. But in order to have that cadence and and that and keep innovating their product, but with more certainty, you also need to design your system or modernize your system in a way that is possible, because different from the other one, uh, as you this more, uh, let's say, design thinking approach and stuff, your your system needs to be flexible, because it needs to keep changing, but it needs to be robust, because every time that you push a feature, it needs to be stable, because it's going straight to clients, it's not, it's not just experiment. So,
[00:12:19] again, when you are driving change, is innovation one of the drivers? Because you need to, uh, uh, match that, uh, your change to to to that driver. Leverage technology.
[00:12:33] Uh, for example, a lot of companies have large data centers, they have like, uh, or they they are have a lot of departments doing, uh, working in a very, uh, not very, how can I say, uh, sustainable way or efficient way. So there are a lot of technologies, going to the cloud, or automating your pipelines, or orchestrating your containers, or being able to spin off, to spin off new environments. Uh, so, you can leverage technologies. So this is also one type of modernization where you can modernize your technology in order to enable some business, uh, uh, uh, drivers. So, business alignment.
[00:13:12] So, this is also key because different areas of the business, they evolve at different paces. So your system needs to be modernized in a way where your architecture matches the the different types of areas or functional areas that you have in your business. In domain driven design, we're going to talk about bounded contexts, so those bounded contexts they need to match the functional areas of the organization. As the organization evolves, sometimes the architecture of your system will be misaligned, will lose that connection. So a modernization may also allow you to to create that alignment and then decouple those those initiatives within the areas. Uh, people and culture. So this is a thing that not many people talk about, but quite a lot of companies struggle to recruit. So they struggle to hire and they struggle to maintain, to retain talent.
[00:14:05] For a for a technology company, it is essential that you you hire good people and you retain them. But you cannot do that using very old technologies, uh, that are proprietary and and things like that. So it needs to be appealing for good people to come to your organization and stay. So there is an investment that you need to keep maintaining, so evolving your technology stock and modernizing your technology stock and architecture offers and everything else, also has a significant impact on the people that you recruit and retain. Uh, and also there are, like things like risk management.
[00:14:40] So, we work with a lot of regulated, uh, companies in regulated environments, in pharmaceuticals, in, uh, investment banking, and insurance, and stuff like that. So there is a lot of compliance, security, operational accidents, so observability of systems in production. So, uh, not always as the regulations are changing, you need to modernize your systems in order to make it easier to be compliant with the regulations or certifications and so on so forth. So, what I'm, so this is part of the foundation. You need to understand before you drive a change, what impact the change that you want to drive will have in the business, where does it fit? So,
[00:15:26] but then there is also the impediments. The other side of this is like, what would block, even if you make that case or we are going to improve certain areas of the business, but what would be the impediments? Lack of time, lack of money, the two most common ones, right? Those things are relative. Right? So, time and money is, is relative. You don't have time compared to what? Because for example, they might say that they they don't have time, but if they have a lot of inefficiencies in their process, you can make a case to say, look, we are saying that we don't have time, but we spend, like three months just with the QA cycle with manual QA every time we want to release a version of our system.
[00:16:12] Or, or we have so many bugs coming back from QA, so there is a lot of rework, or there are tons of cycles of approvals, or we need to change five different systems in order to get something out. So there is a lot of time that is going in places that is just pure waste, if we could reduce that, we would have more time to do something more important. Money is exactly the same thing. But you have other things, you have lack of skills, you have, uh, fear of increasing risk. You have like some, some companies have tried to modernize certain things and they failed, so now they are burnt, they don't want to do it. So you need to understand, I'm not going to go through all of them, but you need to understand, uh, your stakeholders and what are their main concerns, so when you are making that case, you need to address those things, right?
[00:16:58] And also,
[00:17:01] everything that becomes like a a name, like Agile and craftsmanship and Lean, people start having different interpretations. So, modernization is the same. Uh, you need to to be able to explain, uh, what you mean by that as well. So, for example, there are for me some principles that will guide, uh, any modernization effort. For me, like you need to have a big vision, so in order to convince someone to do something meaningful, it's strategic, not just do a small improvement here and there, then in the great scheme of things, it's not going to be significant. So, you need to sell a vision, you need to have a good vision to to say like, look, we can be much better in one, two, three years time, right? So, you need to have a vision, but you need to work in small increments and every increment needs to have value, right? Another very important thing. A modernization normally will disrupt business as usual. Right? So, so because you'll be re-architecting systems, you're going to be re-juggling things around and change how data is manipulated or how systems are deployed and, and so there is a disruption. So, in your plan, you need to try to maximize as much as possible, say that you can completely, uh, avoid disrupting business as usual, I cannot say that, there's always some disruption. But it needs to be minimal. Uh, if it's not broke, don't touch things that are working. If it's working and it's not in the critical path, it's not going to be a strategic moving forward, it doesn't matter if you like the code or not, if you like the technology or not, if it's not changing, not strategic, not moving not essential moving forward, leave it, leave it be. Excellence within pragmatic solutions is also quite important. Quite often, mainly technical people, like me and probably some of you, we we want, if you have an opportunity, we want everything to be excellent and perfect. But this, uh, end up, we lose pragmatism. We just, we want everything to be perfect because we are focusing on the technology, we are focusing on the solution that we want, but we lose sight of what is important to the business. So, what I always say is like we, excellence should be bounded. You cannot just have excellence being unbounded because, uh, you lose pragmatism, you never there's never return on investment. So you need to have a pragmatic solution where excellence exists within, right? So, and then there is a law of diminishing return, you need to learn at this stage, at this, uh, level, the strategic level, we cannot go too deep. There's no point in keep adding tests, adding tests, adding tests and trying to to to add unit tests for millions and millions and millions of lines of code. At some point, you say, you know what, this area is more important than the other area, let's focus in here and do what is good enough, because it's the the whole Pareto's law. Maybe with a 20% investment, we can get an 80% return, but to get the last 20% return, you need to invest the other 80%. So you need to be careful that at some point, you say, this is good enough. Uh, so, so this is for me the foundation, right? So, before you try to drive any change,
[00:20:25] you need to understand all of those things.
[00:20:28] And then with that foundation, now we can say, so how can we start? not go too deep. There's no point in keep adding tests, adding tests, adding tests and trying to to to add unit tests for millions and millions and millions of lines of code. At some point you say, you know what, this area is more important than the other area. Let's focus in here and do what's good enough because it's the the whole Pareto's law. Maybe with a 20% investment we can get an 80% return, but to get the last 20% return, you need to invest the other 80%. So we need to be careful that that at some point we say, this is good enough. Uh, so, so, this is for me the foundation. Right? So, before you try to drive any change, you need to understand all of those things. And then with that foundation, now we can say, okay, so how can we start? There is a, I simplify an a a five approaches. Normally this can be done if you are able to get the right people, and who are the right people? Uh, your sponsors, representatives of the business, representative of technology, from business and technology can have different roles as well. The technology can have people from operations, from uh QA, from architects, team leads, whoever. Business the same thing, you can have people from sales, from marketing, from uh account managers or whoever, right? So, you need to get those people together. We normally are able to do the things that I'm going to mention until the end of the presentation in a few days. Right? In a week, in two weeks, sometimes in three days depending of how much time we have. So, this is not like a big thing. It's a lot of things that I'm going to cover, but it's not as big in terms of time as long as you know what you're doing. So, first thing you are trying, you need to do, align the business. Right? You align the business, align technology, create a vision, create a strategy to to to start going into that that that vision, and then you say, okay, but how are you going to do each one of those steps? That is the implementation. So that is in a nutshell that is it. How do we do the business, uh, uh, align it. So, first of all, we need to understand what are we trying to achieve. As I said, there were the drivers before, and you can be a little bit more specific what is there, what is the strategic value, are we tackling inefficiencies? Are we doing experimentation? So, we need to agree as a group what is the criteria that we're going to have the business criteria, the business goals for the modernization. Another thing we need to do. We need to focus. Right? So, those organizations that want to invest in modernization, they are they have a, they don't have one system, they have loads of systems, they have loads of departments. And so, you cannot just say we're going to modernize everything because that's not going to work. You need to focus. So, what are the key areas that we should focus on that are core to our business? This is a very high level uh uh exercise that we've done with a 5,000 people company with their senior management. We were able in a few days to map out 16 functional areas of their business. And within those 16, we chose three that were more important, and each one of them were broken down into far more areas. We had like three levels of of breaking down areas. And then within those areas, we end up focusing in certain key areas. So then you can really focus your modernization approach in where it matters. So that is assuming the alignment. Now that you have the focus, now that you have the business areas that you want to focus on. And everything else? If one day you get there, great, but you focus on what is important. There are areas that you will never touch, right? So,
[00:23:28] what are the main features? What are the pain points? The desired improvements? So, it's fascinating to run those workshops with those different people, with the technology, the business, the sponsors and stuff. And you say, okay, so in this area, in this product, what are the key things that this thing do? Right? Oh, this this thing does. Each one of them will have a different view in terms of what are the main features, the main uh yeah, uh activities that that area performs. And the pain points the same. Each one of them, because they look at the the systems and the the the business model from different perspectives, they also have a different view of the pain points. And because they see different features as main features and different pain points, they also have different desired improvements. So, bringing them together and running those workshops, we align them on what is really important, what is really a pain point, and what we really should act on. Because some certain pain points, so yeah, it's a pain, you need to learn how to live with that. Right? So, because you have much bigger pains to focus on. Right? So, this is part of the alignment. And one of the for me, the the most important exercises to run is what we call a value stream map. Right? Uh, again,
[00:24:50] not everyone, and we've we've done a lot of those workshops, like, a value stream map for those of you that don't know, is is just mapping from an idea, from idea to soft production. What are all the steps? What happens? From someone that has an idea until it's deployed in prod.
[00:25:09] This is one uh result of a workshop that we ran, there were seven people I think from the client, from different areas, like uh, but all looking at the same systems.
[00:25:18] We ran like for an hour and a half, two hours, and by the end of it, because each one of them, we have like the business analysts or product owners, they had their own process of prioritizing ideas and backlogs and assigning to teams and stuff, they had their own process. budget approvals. I don't expect by the way that you read all those post-its, right? So, uh, and then there were loads of things as soon as it gets to development, there are different people, there are different departments and there is separate QA and and. So when we finished, each person were were contributing was contributing different parts, when we finished, all of them looked and it's like, is this how we work? Yes. But no one had the full visibility. So, this exercise allows to bring everyone together and be very precise where the inefficiencies are.
[00:26:14] Because then you can say, okay, we need to automate this bit. We need to re-architect the system or you know what, you just need to fix your process. You don't need to change anything in technology, you just need to to find a more uh, how can I say, a better way of communicating and removing some of bureaucracy that God knows why is there. Uh, another, there are few things missing as well because uh, we also need to look forward. So, sometimes you will have a portfolio management, so they know what they want to achieve in each quarter, all the different initiatives or strategic initiatives that you're going to have in your portfolio. What if you're looking at something that is a little bit more uh focused, uh, you might they might have some milestones uh and or backlogs and stuff like that. So we need to know what is coming next. Because as I said, uh we should not be modernizing things that are not useful in the future. There's no point in touching one area. If there's no new feature coming in. So, leave it be. So, just all the modernization should uh support the strategy of the business. So whatever we do now should should be to enable the the the the strategic vision of the business to be implemented. And then there are constraints as well.
[00:27:36] We didn't look at it, but we need to look at it, uh, for example, uh, SLAs, regulations, certifications, external and internal deadlines. So, all of those things, they impact the modernization. So we need to understand what are uh uh constraints that we cannot do anything about, if there is a certification, a regulation, an external deadline. It doesn't matter how much we hate them. We need to suck it up. Right? So, it is what it is. Whatever we do, let's create a strategy that will take that into account. And we'll do our best within those constraints. Other constraints we might decide to to remove. And then we need to have a conversation. But we need to to to keep that in mind. OKRs, KPIs, metrics is also again related to the portfolio. So what does the business want to achieve and stuff because you need to align your strategies to that. Right? So, and and basically some a few metrics are always important, uh, again, different modernization styles will have different metrics. But there are four key metrics for those of you that uh read or that didn't read that accelerate book, I highly recommend, is a phenomenal book and and it explains the the research behind it, it's all based on on data and stuff. But they talk about four key metrics. That is the the frequency that you deploy software. Uh, the lead time, so the the time it takes from uh to software to go to production. Uh, if something goes wrong, how fast can you restore that and the amount of waste or in this case in failures that you have in the process. Right? As the the work is going through the the pipe, how much failure do we have? We should be reducing that. So, so those are key indicators that we can use to monitor your uh modernization approach as well. So, with that, by the end of those, and again, you can run through those things, if people are available, you can do that in one day, by the way. I'm not talking about months, it's not, it's one day you probably can get some alignment.
[00:29:38] Once we have that, now we need to go through the technical side of it.
[00:29:43] The technical side. We start looking, okay, within the areas that we are focusing on, what is the the current architecture? What do we have? So, and then, as we look at the overall architecture, then we need to decide where we're going to go a little bit deeper. Then you need to look at some of the components, some of the services, what is the overall design? And also you what we call it a a functional uh mapping. So, for example, if we have a few features, and by features, I'm not only talking about users clicking on screen. A lot of organizations don't even have screens, what they have is messages coming from different systems, coming from outside the the company. So, messages coming in and navigating through a bunch of systems, or they have different uh delivery mechanisms and UIs and stuff. So, but we need to take those features, whichever they are.
[00:30:32] and map as soon as those our systems are triggered, what happens, which other systems are touched, which areas of the systems are touched for each one of those systems, so you can do that mapping as well. So this allows us to create an understanding. And this exercise is done not only with technical people, this exercise is done with the business people on the same in the same room as well because they themselves don't understand how our systems are architected. And and because those workshops are at a high level, it's easy for them to uh to understand. We are not going to be opening Java classes or closure or some crazy JavaScript framework. That's not the deal. This is a design, architecture design level. That's where the strategy is at that level, not on the low level coding issues. So this allows the business people to understand the kind of complexity that we have, and how the system is mapped. So, then we do a very similar thing, what are the pain points, what are your desired improvements, technical constraints? And we also talk about the risks for modernization. Because in certain environments, maybe in regulated environments, environments that have too many concurrent users buying things or being prescribing medicine and stuff like that. You cannot just start hacking the code or hacking the architecture and changing things around and changing APIs and changing databases. You need to understand what are the risks. So, so there is a whole session on risks as well. So then, you look at constraints, for example.
[00:32:11] We work with one client, uh, where they are uh uh health care provider, their systems are, they have 11,000, more than 11,000 production installation, 4,000 of them are on premise, on environments that we don't even have access to. Right? That is controlled by other people, by their clients.
[00:32:35] So, because they have, they need to be multi uh tenant, what does it mean? uh, well, multiple clients can access the same production instance, they need to have one instance for client. Because if one system goes down, one hospital might go down, but not the entire American uh health system goes down. So, because they have, they need to be multi-instance and not multi-tenant. That created a very big technical constraint in the architecture that we had. We cannot go microservices, for example. Because otherwise, imagine like 11,000 production installation, and we put, I don't know, 50 microservices in each one of those installations, the complexity would be gigantic.
[00:33:18] On top of the 4,000 on premise. So, we had to go for uh uh uh what we call a modular monolith. But this is just one example of technical constraints. But you have SLAs, you have regulations, you have volume of data, you have many other things. Right? So, again, that we all need to understand, not only technical people, but the business people need to understand.
[00:33:46] Once we have that alignment with business and technology, only then we start to create a vision.
[00:33:52] You say, okay, so given what we know now of where we are in the business and the technology, what are the pain points, what do you want to improve and so on and so forth? What is our vision? And here I call the the magical wand. Right? So if you have a magical wand and you say, and see this beautiful future ahead of you with all the systems using the technology that you want. split the way that you want, and the process being whatever you want, all the automation. So, let's paint that picture. Let's try to understand what we would like to have. Of course, we will never have that. Most of the time we will paint a vision that you will never achieve. But it needs to serve as a guide. So, I always say that technical vision is a direction.
[00:34:39] It's not a plan that you follow, uh, it needs to give guidance. It's okay, this is what we would love to have. But we cannot stop the whole world or be spending money forever and time forever. uh chasing a vision. Again, we need the pragmatics uh solutions with with excellence, right? So, so you create the vision to serve as a direction and then you start moving towards that. Right? So it's not going to be a straight path. So each increment you're going to go a little bit on the side, maybe a little bit on the side. And we keep recalibrating, we keep re- recreating the vision, as we work towards the vision, we is it still the same vision or is it changed, is it moving to the side, and then you keep adjusting. Right?
[00:35:28] So, and we'll be talking about the testing strategy. The technology, the deployment, production environment, modernization, team ownership. Team ownership is very, very, very important. I'll probably talk more a little bit later if I don't, uh, send me a question. We can talk more about team ownership as well. But you can create you need to create that vision. And and in that you need to take into account all the constraints, business and technical, priorities, OKRs, uh, and so on, so forth. So, it sounds obvious. But I'm yet to see when people are trying to drive technical change if they have this alignment and and this plan. That's why we normally are not able to do that. So, once we have the vision, the vision side, is where people get excited. Right? So, so you as a change agent, you as as a person that wants to drive the change, you need to excite people. You bring them along. When you bring them along, they now are on the same place, they all verbalize their pains, their desires and stuff, and now things are getting together and then you are together creating that vision. And then at that point, is your job to make sure that everyone is excited and now you say, you know what, this might be actually possible. But like, well, up until now we just talked about. Desires and pain points, we create this beautiful vision. But I'm still skeptical, like, can we even get there? I'm I'm not seeing this actually being implemented.
[00:37:04] And that's when
[00:37:07] highly technical people can really shine. Because now it's our time to say, okay, we've created this excitement, now let's see how we can do that in a way that is sustainable. And I'm not going to prescribe because it's impossible for me to prescribe what to be the strategy without knowing the context, so I'm going to give you ideas.
[00:37:27] This slide shows the most simplistic approach to software modernization. This came from Gartner. Which I personally think that there are great things in there and some some things that Gartner loves to show those reports, they're very simplistic in nature. So, Gartner says, oh, there are different types of modernization, there is a rewrite, re-platform, re-architect, re-factor, uh, so, that's that's what they talk about. There are one or two that were a bit too weird for me, but anyway. This is for me very simplistic. Because most of the modernization projects that we've been involved, they were a hybrid of all of that. There is a bit of everything in there. So, let's forget this because this is way too simplistic to talk about software modernization.
[00:38:13] We divide it in slightly different ways. Because as I said, you cannot change everything. So, one one strategy, this is these are more uh modernization strategies that have some business impact. One one way of doing that is to say, which functional area of your business is more critical? Either it's it's is is causing you a lot of pain and you need to stop the bleeding, you need really to fix that so that you can focus in other things more important. Or is very critical to the future and is not ready uh to enable what you want to do, so that is a focus on a functional area. Right?
[00:38:53] Another way of doing that, you know where you want to touch. But you don't you cannot stop business as usual.
[00:39:00] And you don't have enough people or or time or resources or whatever to do that. So what you can do? This is an approach we use a few times, you can take, I'll give a concrete example, the new features one. We were working with this client and the and and they had a they had a big monolith in their online store where payment was part of the monolith. So the monolith had like uh orders, uh products, catalog, all the the common domains that you might imagine including uh payment. So the the payment side was complicated because they were storing credit cards. Which means that the entire system had to be PCI compliant. So every change that we wanted to make, even if you're changing the catalog, they might need to keep PCI compliance, which is was not even changed, but it had to go through auditing. example, the new features one. We were working with this client and they and they have a they had a big monolith in their online store. where payment was part of the monolith. So the monolith had like uh orders, uh products, catalog, all the common domains that you might imagine, including uh payments. So the the payment side was complicated because it was storing credit cards. Which means that the entire system had to be PCI compliant. So every change that we wanted to make, even if you were changing the catalog, they might need to keep PCI compliance, which is was not even changed, but it had to go through auditing. And so what we wanted to do, we wanted to decoupler the the the the deployment cycle. If we could remove payments from the rest of the monolith, we could allow the rest of the the codebase to be deployed much faster and with less bureaucracy. And keep the the more more bureaucracy or more auditing and stuff where it really matters, that is the payments. But they could not just stop everything to do that, so what we did, we used new features. They wanted to add uh new payment methods. They had already a few credit cards, but they wanted to add PayPal, they wanted to add Apple Pay and stuff like that. So what we've done, we took the the the new payments, in fact we were actually in this case they were integrating with a payment gateway from third party. So so I said, okay, let's take the the payment gateway integration. So we created the vision and we use the new feature in the system and but we designed the new feature uh with a new architecture, with the new vision. And that allowed us to still progress towards the business and start introducing the new vision for that area. And then gradually we start moving the existing payment methods into the new system. So that is a very interesting way of doing there is business flows. Business flows, for example, one of another uh company. They had 300 employees uh that in order to do their operations, they were very inefficient because they had to use three different systems. To do their normal business flows and quite often they had to copy data from one system to another so that they continue the flow because they acquire different companies and so on. So, what we've done, we took the the business flows and we based our modernization approach in the flow that the users needed. And then we chose what we had to decouple, what we had to rewrite, what we had to to to create another service and so on, so forth, but that was tailored to that business flow. I'm not going to go into all of them, but I'm just giving you uh ideas.
[00:41:57] That when you are modernizing, the way that you create your strategy can vary significantly, but you are always tailoring that to the business. And then there is a more technical approach. Then there is the actual architectures that you're going to use or or stuff. So, for example, I mentioned the modular monolith uh a little bit earlier. So given the constraints that we have and the needs from the business, architectural wise, our biggest modernization approach today, the system is a modular monolith and it's going to remain a modular mono, right? So, because it makes sense. But you can go from from microservices or you can use a strangular figure or you can have modernization that are based in separation front end and back end. Or for example, you have a a bunch of microservices, but you have different delivery mechanisms, you might have mobile, you might have the web, you might have integration with other systems that use your systems, so consumers of your APIs. Uh, so, who manages the flow, the business flow, the user journey?
[00:42:58] So then you can also uh organize your systems in a way and push the flow to the delivery mechanisms, because then the mobile uh uh flow can be different from the web flow that can be different from another system that is interface with the APIs. So, but that's an architectural decision, so data segregation, data ownership.
[00:43:18] So who owns the data, which areas of the system will own the data, which data the system own and what do I mean by own?
[00:43:26] Data that they can't change, they can insert, they can delete, they can update. So who owns products, who owns orders, who owns I don't know catalog, and who needs that data, who consumes that data? So that uh uh organization is extremely important in how you architect your system. So there are techniques and architectures for that as well. And then there is modularization, all the the types of uh uh software modernization uh efforts we had had a degree of modularization. And by modularization, I'm not saying like uh modules is is a conceptual term, right? But but eventually you will need to modularize separate areas. And this is a very difficult thing to do in larger systems. There are many different variables and depending on how you look at your system or from which perspective that you look, you might come up with a different type of module or the boundaries between modules. So there are many different techniques you can use. The data, the the functional mapping, the the areas, the the functional areas of the business. There are many different uh perspectives that we need to analyze in order to decide where the bound context if you want to be more domain driven design technical term or the functional areas uh in order to get that split. Uh, but there are many advantages and uh so the modularization.
[00:44:57] I know that sounds obvious, but uh very for for technical people, so of course you need to modularize. Of course you need to have things that are loosely coupled, that is highly cohesive and of course we do that, but why? Right? So how do you how do you talk about that with someone else that is not a developer, right? Or not an architect. So there is a reduction in cognitive load. Every time you you go to a place, an area of the system, you can think about that area without having to have the entire system in your head. And that is not only on the technical side, on the business side as well. If you can match the the the the functional areas to the the bounded context, you have that reduction of cognitive load when you're talking about those areas. And of course, if you have that, you can also have localized and safer changes. That's another drive, so when you go to to to to someone, you want to drive that change. You don't go to say, I need to modularize my system. Why? Because it makes sense for me as a developer. Right? Because it's easier. No, because you can localize and make change safer. Right? So we can enable parallelization of work.
[00:46:11] So if the system is modular, I can have multiple changes going at the same time without affecting each other. As long as the way that those modules interface with each other remains the same. Or their interfaces. Right? So, it's easier to achieve continuous delivery. Because this is another misconception, continuous delivery doesn't mean that you need to release your entire system every day or all the time. You can release different parts of your systems continuously. So one day you release a feature in payments, another one you're releasing in in in the customer side another. So you are constantly releasing things and they are coming from different areas. So that's what can give you continuous delivery. So as I'm saying like there are many different ways for you to express your you the things that you know that are wrong with the system, but now more business-wise, let's say or.
[00:47:03] And there are different types of modules. Right? Modules can be all the way low level from packages and name spaces to components, to libraries, to services or groups of services. So our payments area, as I was saying before, is a module of the system at architectural level. And that module of the system is composed by a few services. Each one of those services have their own modules inside. And so on so forth. So that that modularization it exists in multiple uh levels. Similar to architecture and software design. Your architecture are the very all the way from the very top in different areas and then you go deeper and deeper into you get to classes and methods or functions if you prefer. Right? So all of that needs to be at least part of your uh technical strategy. And then finally you have. Okay, so now we understand what the vision is, the pain points, all the alignment and stuff. And we know we have a strategy, we we we have a vision and we have a little bit more concrete what needs to happen. So how do we go about that? Where do we so how do we use our people, right? So how do we go about that? There are many different ways.
[00:48:23] All of them have pros and cons as everything we do, right? There are always pros and cons and then you need to understand your context and what would work best. So, for example, one way that you can do, you have a dedicated team just to do that modernization beat.
[00:48:41] Or at least part of it, you might have more than one team to do different parts of the modernization uh uh exercise, uh the modernization uh strategy.
[00:48:52] What is the advantage of having a dedicated team just doing that? You can get it done faster. Because you can assemble a team that has the skills that you need. Because some modernizations might be moving to the cloud, might be upgrading technologies, or might be uh breaking an old monolith apart, so you need people with knowledge of that. Modularly and not necessarily knowing that latest technology, but more of a domain knowledge of uh system knowledge. So you can assemble the team according to what you're trying to do and that team will blaze ahead. So you might achieve that faster.
[00:49:30] Uh, so there is advantage of that. The the disadvantage is that that knowledge is a bit concentrated. So after the team blazes ahead, you need to find a way to spread that knowledge across other teams as well. Uh and also this team will need to interface with a lot of teams potentially as well. There are specialized team, you can just bring a few people say like, okay, those are cloud uh specialists, they are AWS specialists, or they are I don't know, they understand everything about this domain, they built this thing 15 years ago. Right? So they built a very specialized team, it's not a cross functional team and they will take a very specialized area.
[00:50:09] Other combines we prioritize the backlogs, they have a backlog that has business as usual, real features and technical improvements. Advantages, yeah. You can do both, you don't stop the entire business, you share the knowledge. The same team that is doing the new features is also the ones that are fixing the issues. But it's going to be far slower. And more often than not, the new features will always take precedence. Right? So,
[00:50:36] you can embed your specialists, you can have 20% improvements. So there are many different configurations, I'm not going to go into each one of them. Uh if you want to know more, uh pop up the question and then I'll go in more details. But as as I said, there are many different ways for you to arrange your teams. And there is also a great book, I think one of the authors gave a talk in this conference not a few days ago. That is the guy who wrote the team topology. Uh so that book is really, really good. I think one of the authors spoke here. Uh, have a look at that book because it gives very, very good insights in how to align those teams.
[00:51:13] Every modernization needs to be run as an agile project. It needs to have an incremental approach. It needs to have roadmap and milestones. Uh, so do demos regularly and show progress. You need to figure out a way to show progress. And we've been doing those for for a long time now. At the beginning it was very difficult to figure out how I'm going to talk about a piece of refactoring that I'm doing or an API that I'm changing or I don't know, some cache that I'm putting somewhere. How do I explain that to the business? Well, you there are many different ways, you just need to find a way. I can offer you examples, but you can talk about performance, if you're improving, you do demos. See, this is this is uh so this is without the cache, that's how long it takes, now we have the cache, it takes much faster. So you can uh show metrics, Sonar, in code scene and stuff like that. So there are many different ways and but you need to show uh the the business value.
[00:52:14] So that's a summary. So those are uh the the the a few areas. So as I said, if you want to drive the technical change, you cannot just go there and say,
[00:52:26] we need to do microservices. And I need one year to do that with a team of 10 and it's going to cost a million pounds. Forget it, you're not going to convince anyone. And you cannot just be upset, oh, I don't know why they don't listen to me. They don't understand, they are all stupid people.
[00:52:45] They they cannot see what I'm saying. Because it's the solution you're not aligning, you're not mapping to to the value. And there are different ways in doing that. Uh I'm not going to cover these in to to a a big degree. But large organizations, they might want to trigger multiple initiatives, uh and we are running some of those things in certain clients. Uh, you can scale that. But you also need to be careful. So in a way we create so we we we talk about this continuous improvement program, so basically you can have like multiple initiative sources. So those are different functional areas of the business or it might be some different groups like QA operations or a specific task force. Like uh a root cause analysis and CAPA, that is corrective action, preventive action, some companies create those areas to act on some immediate.
[00:53:40] uh issues that they are having. Uh so they're all different types of different sources of initiatives, of improvement initiatives. And they can present a case to what we call a steering group. This steering group will understand the business value of tackling those things, they will create a very high level backlog that is more like a portfolio of initiatives, and then they can decide what kind of teams I'm going to be going to be working on those things.
[00:54:07] And what is the amount of work in progress, right? So how many uh uh improvement initiatives are going to have at some point in time, remember that those initiatives they tend to be long. They tend to be measured in months, uh if not a year, uh so they are more uh expensive, they are more uh strategic.
[00:54:28] So you don't want too many of them because you you may destabilize the entire system. So you need to be very careful. This is why the steering group is important because the steering group is not only by sponsors that can pay for it, but all the technical architects if you have them or whoever the technical people is. The CTO, the head of engineering, whoever. Because they need to understand the technical risks of doing certain things in parallel. Uh and then the teams they can decide, they can assemble a brand new team just for a single initiative, and once that initiative is done, the team goes back to whatever they were doing next. Or they can have a few teams dedicated to the to the CIP, right, the continuous improvement program, that they are taking one initiative after another, assuming that they have the skills to do so. Or they can bring a team from our department, the department joins, does that initiative and goes back. Right? So you can you can have multiple combinations. So I'm not going into detail, there are different types of initiatives, tactical, strategic and But but this is a way to to try to scale modernization uh programs.
[00:55:36] And ultimately, what you want to achieve is this alignment.
[00:55:42] You want to align the product and software design, by product is any system that is strategic. It's not necessarily a product that is going out to uh uh an external customer, I'll treat an internal system that is strategic as a product in this case. But what you want is to align. Because those strategic systems, business-wise, normally they will have a roadmap, they have milestones, which means that the business is planning for them, business-wise, there is a plan for them. And as they are uh uh the teams is iterating, the business is adjusting that plan, adjusting those milestones, adjusting the priorities in the backlog. But what we don't do is this strategic on the ideation and strategic planning that that normally happens at the in the product level, we do at the product level, but we don't do at the technology level. So as they are creation and definition of the product, as they are discussing road maps and change road maps, as they are discussing milestone. We should be working together to say, okay, so if I understand what you're trying to do, I can say if it's feasible. What is the technical feasibility of it? Do we need to buy a system? Do we need to integrate? How many systems are going to be changed? Do we need a different technology? So how much is going to cost at least a ball park? In terms of not only buying uh licenses or stuff, but also development uh uh effort. Of course, we won't do estimates at that level. But we can have a high a a ball part, we're talking about six months, maybe this is a a year long. Maybe two years program, so you can give that ball park. Just just to to start. Once we have more clarity of the road map.
[00:57:20] Then it's okay, if that's our road map for the next six 12 months, business-wise. Does our architecture support that? Do we have an architecture that can support that or we need to adjust our architecture or create a new architecture to support that road map? And as we are iterating, we also need to make sure that we're making uh strategic decisions in the technical level.
[00:57:43] And as we go to the milestones and and the the increments or if you don't like increments, user stories or whatever, we also need to start refining the low-level design.
[00:57:54] The problem is that those are the green boxes on the ideation and strategy and planning, they normally don't happen. They normally it's done at the top for the business, but the technology gets involved once the backlog is already created and the teams are normally working on the top items of the backlog. So that's normally how I see a lot of the agile implementations.
[00:58:17] There's a lot of thinking in the product. But the teams, their interaction with the business is, what are the top levels of the backlog? Okay, so how do we split that in an iteration? And then they are working on iteration level, because they work on this mold. They cannot do any significant architectural change or create an architecture or a technical strategy, when they are just iterating one of the another, and they don't have the full visibility because those decisions they need to be made. As the business is adjusting the the portfolio and the road maps, so that's what we want to achieve.
[00:58:52] And for that, if you are starting from scratch, it's easy. But if you have a a bunch of legacy code, you will need to start modernizing your systems to to provide that alignment. So,
[00:59:04] that's what I wanted to share with you, so uh hope that it was useful.
[00:59:10] But yeah, so this is this is how we things that you should think about uh if you are considering to drive change.

Transcript