This text was generated using AI and might contain mistakes. Found a mistake? Edit at GitHub
So, welcome everybody to another episode of Software-Architektur im Stream, this time with Nick Tune about architecture modernization.
So, Nick, welcome to the show and do you want to say a few words about yourself?
Sure.
Firstly, thanks for letting me come on your show.
So, great honor.
A few words about myself.
I would probably say I’ve worked in IT for around 15 years.
During that time, I’ve done lots of things.
I’ve been a very opinionated junior developer and upset lots of senior engineers.
Nowadays, I try to be a bit more balanced in my approach, my mindset, still have a lot of opinions about things.
I try to use them more wisely.
I’ve been a developer, tech lead, principal engineer.
I worked as a consultant for around five years.
So my role as a consultant would be helping companies to modernize a particular focus on the major in design.
And for the last three or four months, I’ve been working full focus 100% at a French company called Payfit, which specializes in payroll and payroll products.
My role here is a staff engineer.
My responsibilities vary from being hands on with the developers, implementing, migrating from the old architecture to the new architecture.
Also working on the business side, helping to shape the roadmaps, helping to make those difficult decisions around, do we build new features or do we modernize?
Trying to balance the short term perspective and the long term perspective.
Working with the product people, understanding their point of view.
And also trying to help apply new concepts like DDD across the company, trying to level up the whole company in new practices.
So it’s quite a diverse role.
I get pulled in lots of different directions.
Usually have a lot of Slack notifications and threads to respond to, but I’m very much enjoying it.
Never worked with a French company before.
It’s been a very good experience so far, so very happy at the moment.
Which sort of leads me to the first question.
So I mean, consulting and working for a product company are two quite different things.
So what made you switch from the consulting role to the product company role or to a role in a product company?
Yeah, good question.
And I think probably some some general insights here that people might find useful for their own career choices.
So when I worked full time, I always wondered what would it be like if I got to do things like event storming on a more regular basis in different companies and learn about different domains and how different companies work.
And then the opportunity came up.
Some other consultants I know invited me to work with them on some projects and work with some clients.
I thought this is actually very interesting as I have to meet these different companies, get to do a lot of event storming.
At one point I was doing event storming workshops maybe once every two weeks or minimum once a month.
I got a lot of experience there and that also opened my mind up to the things that are common across different companies.
The challenges that are unique to different companies and having to work on different kind of skills.
I wasn’t really much of a people person.
Not sure I am now either.
But when you’re a consultant and you have to meet new clients on a regular basis, have to make relationships, have to do these difficult workshops, have to help them make decisions or start implementing new ideas.
It’s like, wow, I have to learn how to talk to different people in their language, get comfortable doing the small talk and a chitchat.
So, yeah, consulting has been great for those reasons.
Broad experience, working on different skills, more diverse skills and varied skills.
But then as a consultant, one of the issues is that as you’re working with different clients at the same time and you’re doing lots of event storming to different companies, for example, and working on different projects, maybe three months here or splitting your time a couple of days a week here, then do some workshops for another company.
I started to lose that sensation of what’s it actually like to work at a company when you’re there every day?
What’s it like to be involved in a long term project and have to face all these challenges on a daily basis?
And so previously I was working full time for a company and I was like, oh, what am I missing out by not being a consultant?
And now my mindset shifted to what am I missing out by being a consultant and not being here and having that experience of what’s it like every day?
What are all the problems and difficulties on this long term journey?
So at the end of last year, I put out a message saying I’m looking forward to I’m trying to get back into working for a company to get get connected to those experiences and feelings.
So it was, yeah, definitely a purposeful choice.
And I would say if anyone’s listening and thinking about their career, I think it’s great to have variety, to have those different experiences, to work on those different skills.
In the long run, it’s been very useful.
Yeah.
So thanks a lot for sharing that insight and for the German speaking people.
So if you go to the homepage, there is also a section of the homepage about Berufs or about the profession.
And there is the story of quite a few people who shared their story about their career and what makes them tick, how their career went.
And that might be also interesting to look there and see what other people are doing.
And there is a great variety of different people there.
So that is something that is valuable.
And I’m sorry that it’s only in German.
But what we want to talk about here is architecture modernization.
So that’s also the title of a book that you put out this year, by the beginning of this year.
And as you said, you are quite well known for in particular for your experience or your expertise in domain driven design.
So what is architecture modernization?
What is that all about?
And what made you write about that specific topic?
Yes.
So the question of what is architecture modernization?
Firstly, I think it’s important not to try and be too strict with the definition.
There are different things that people may consider that is modernization, that isn’t, that is architecture, that isn’t architecture.
So I’m not trying to be too precise here.
And I don’t think we need to always have a very precise and perfect definition.
But for me, the general challenge is the longer your company build software, the more you build up software that is not in the ideal shape that your company would like it to be in at the current moment in time.
Some companies like the Norwegian government I spoke to recently, they’ve got systems that are 40 years old.
And so when we talk about modernization, what we’re trying to achieve is to remove the constraints and the bottlenecks and the problems that the current architecture is preventing us from achieving.
So it might be because we’re on old technologies that are difficult to work with, or it might also be because the architecture is based on old assumptions in the company, the old business model, for example.
So some examples might be a company would like to build a new kind of product or it would like to move into a new country or a new market.
But the cost and the risk of doing that is just too high with the current system.
So modernization would be how can we use the latest technologies?
How can we update some of the abstractions in our software so it matches our current business model, the way the domain currently works, how our industry currently works nowadays and achieve things that are currently not possible or too expensive.
Okay.
And what’s the typical scope?
So do you think it’s – is it about one specific application or about all of the enterprise?
So what’s your experience there or what – yeah, what’s your experience there?
Yeah, I think it can vary.
Some companies are much bigger in scope and for some companies it might be the scope is only a certain area.
We only focus on one product, for example.
Right.
And that’s why it’s really important to have a broader understanding of the business.
And one of the things I learned as a consultant, which I apply a lot in my work, working for one company now, is always trying to understand the question, where’s the company going in the next two to three years?
We can’t predict the future, but we can certainly get some guidance on what the expectations are.
So when I joined PayFit, for example, one of the questions I was asking all of the stakeholders, head of strategy, head of product, CTO, like, where do you see the company in two or three years?
What things are most likely to happen in terms of how the company will grow and what things are not going to happen?
Because then we can have a much – and there’s always a risk here.
Some companies are very fickle and, you know, they say things that will happen that don’t happen and things that they say don’t happen will happen.
So there’s always the caveat that nothing is ever 100 percent guaranteed.
But based on our best efforts to understand the probabilities of how things might evolve, we can then start to build a modernization strategy that says, well, if the company wants to go in this direction and there are things it wants to do now that aren’t possible or too expensive or too risky, then modernizing this product would make sense.
Modernizing this system and extracting a platform that can help to bring new products into market in the future would make sense.
So I think the scope, yeah, will depend on what the business wants to achieve.
And which sort of leads to the next question.
If we talk about software architecture and architecture modernization, then this sounds like a technical challenge.
And you talk a lot about the business side of things.
I mean, we just spent a few minutes talking about it, and it seems that we are talking about business and more business and business goals and so on.
So is architecture modernization actually a technical challenge or is it something else in your opinion?
It’s definitely a very technical challenge without question.
Thinking about the work I’m doing at the moment, for example, lots of very difficult technical challenges.
How to build new things in a new way that talk to old things that were built in an old way, based on different assumptions, different domain models and abstractions.
So which technologies to use, whether to use in-house things or buy things off the shelf.
How do we migrate in a gradual way and balance things out?
What’s a pragmatic solution?
How do we make sure we don’t implement a pragmatic solution and keep it?
How can we make sure that we don’t start a migration and not finish it?
This is a very common thing I saw as a consultant.
For example, sometimes we will talk to like a customer support team, for example, and we map out their process and we’re like, oh, you have to use three different tools to get your job done.
We’re going to build a new tool for you that you only have to use one tool and make your life much easier.
And they’re like, no, don’t do that.
Why don’t you want this tool that solves your problem?
Because the people said that last time we had two tools then and now we have three.
We don’t want four.
So lots of very difficult technical challenges for sure.
And that’s what I enjoy most about modernisation, being hands on, doing this technical migration work.
But it’s also very much a business problem.
And because I think the main thing to remember is modernisation can be a lot of effort, putting a lot of effort into these legacy systems that have ended up in a state that’s difficult to work with, to extract the behaviour, to decouple things, to decouple these monolithic databases, to split up code that has lots of teams working in it.
We really need to have a very strong business case and say it’s worth it.
What can’t we achieve now?
What will this give the company?
Why should we stop building new features and invest in this?
And then there’s always the ongoing question of the roadmaps.
Can we build this new feature?
Can we just do this one new feature?
And you need to have a very clear reason to say we can build this new feature.
But this modernisation we’re doing is also worth 50 million per year once it’s complete in two years time.
And every feature we build now is making it longer to achieve that 50 million extra revenue per year goal.
So we need to be able to very concretely justify those decisions when we’re getting started, as we’re going.
I think a lot of people even struggle at that point.
They’ve got this legacy.
It’s very difficult to work with.
But people on the business side say things like, we’re not an IT company.
We don’t need to use the latest technologies.
We’re happy with the current way things are working out.
Without a clear business case, it’s very difficult to do modernisation.
And even with a very clear business case, it’s still very difficult to do modernisation.
So this seems to be a discussion that basically says, okay, you need to have that strong business case to make that modernisation happen.
So it seems that the role of a technical person would be to understand the business, to translate that to some architecture, technical, software things, but not to challenge it.
Is that what you think the role should be?
Or should it be somehow different?
I think that will depend on the company you work in and your role in the company.
But with the caveat that you should always be thinking about what’s the best result here, even if it might not feel like your responsibility.
So firstly, very often the business case might not be clear.
Different stakeholders might have different opinions.
Some might say we need to move into new countries, target new customers.
Others might say, no, no, we have to focus more on existing customers.
The sales team and the product team may want to go in very different directions.
So there may not be a business strategy.
It may not be a clear business strategy.
There may be different opinions on what the strategy should be.
And as you said, you may not agree with it.
You may think it’s too ambitious or it’s not possible with the current systems.
So you may also have to push back on that.
And that’s always the balance between products and engineering.
What would we like to do and what’s the cost of doing that?
And I think you have to be able to say the cost of doing that currently is very expensive.
If we invest in improvements, it would be much cheaper to do that and also much safer, much more reliable with fewer incidents, fewer support tickets and things.
And I think not just challenging if you disagree with it.
But one thing I learned as a consultant is sometimes when you, well, maybe a lot of maybe all the time or maybe not all the time, but nearly all the time or very often you might someone might tell you what the strategy is and you might ask some questions to them.
And this might be the first time someone’s actually asked them that.
And they might not even understand that well themselves, the strategy.
And as they’re answering the question to you that this is all they’re calculating things in their head.
So sometimes you have to facilitate them in explaining what their thoughts are, why they think something’s important, trying to articulate what are the trade offs between this new product feature, for example, and this thing you want to achieve in the future.
And also they might have assumptions where they might think, oh, we wanted to do this expansion into the UK two years ago.
But the engineer said it wasn’t possible.
Your job is to try and tease out those assumptions.
They’ve gone and say, actually, no, we might be able to do this now.
What’s it worth to you?
If we could achieve that, what would it be worth in terms of revenue?
And I can tell you what kind of effort it might cost to achieve that now.
I guess in a few situations, architects might feel that they just get the requirements from business and they don’t.
They are sort of on the receiving end of some commands that they get from the business sides.
And what you’re saying is something different where you would actually give them some feedback, try to understand the business case and have an open conversation.
Do you think this kind of problem is a common problem?
Is there a way out of that or what do you think about this?
So I guess there’s a few different aspects to the problem.
I guess the first one which you mentioned is you work in a company and it’s a very one directional in terms of instructions and requirements.
Sometimes it is worth pushing back, but sometimes it might also be worth recognising that the company you work in has worked this way for a very long time.
And if you push back, it’s unlikely to be successful.
But I think it’s always worth challenging yourself.
And I think it’s always one thing I learned is sometimes you work with people who seem to be very opinionated, very senior.
Like, oh, I would never challenge what that person says.
But sometimes you can.
And that’s what I learned as a consultant.
I have to actually challenge these people and just ask them to clarify things.
One of the ways I find useful to do that is sometimes I just say, like, I’m going to play devil’s advocate here.
If you don’t achieve this goal by the end of the year, is that a good year or a bad year for you?
What would it feel like to the company if that thing isn’t achieved that you’ve just told me is the most crucial priority?
Sometimes they might say, if we don’t achieve that, people get fired.
It really is a crisis.
And sometimes you might say, well. we’ll just update the targets next year to be more accurate, like okay so it’s not really that strong of a goal, like it’s more of an artificial goal, so I think you can challenge things on that and also challenging the strategy, like saying, so you feel very strongly that going into the UK is how this company should grow in the future, why the UK and not other countries, or why not wait two years and fix the current problems we have, what’s the exact trade-off in terms of revenue, what’s the benefit of both of those and what’s the risk attached to both of those, and that’s kind of what I was saying before, where they might not have thought about this before, they might just be parroting what they’ve been told by the CEO, for example, or the CEO says we have to do this, so we have to do this, so you might uncover, yeah some assumptions or hard constraints that aren’t that hard, and you might realize that, yeah some people are more willing to open up and discuss these things, it can also take time, you might have to work with some people a bit more patiently, it might not be a one conversation turnaround, it might be having coffee with the person, having drinks after work, it might take a while, but you might get to a situation where they do feel more confident to be challenged.
I think it’s also important to recognize that in some companies people are expected to be experts, and so if they show any sign of weakness by not knowing something, that could be, they might feel that’s a threat to their place in the company and their identity, so be aware of that.
I think yeah, if you can have one-to-one conversations, that’s normally a bit more of a safer space to challenge things.
Yeah, and I think those are pretty good points, because those are things that you can work on, have these one-to-one conversations, and you know just give it a shot, and try to see what the other people actually think, and whether they want to be challenged, and what their opinion really is.
There are a few questions or a few comments on YouTube, so there is one comment I have to admit that I don’t really get, and I totally get it, but we can see what we can make out of it, and I have to admit that it’s also, it was asked a few minutes ago, so Deutschroot says, agree with the technical challenge, but without a strategy for the long term, you are at the short end of the stick, or don’t you think?
Not sure what he is referring to, so I’m not sure whether we can actually answer that, or how we want to answer that.
So it sounds like, could we modernize if we don’t have a very clear and a very strong strategy?
If that is the question, I think we can do that.
I think we can define principles about how we’d like to work, and what’s about how things currently aren’t approaching.
So at PayFit, one of the principles is domain ownership.
We’d like to have clearly defined domains, where a team owns a domain, and all the data for that domain.
So even if we, PayFit does have a clear strategy, but even if PayFit didn’t have a strategy, at least with that kind of principle, we’ve got, we know that we’re moving in the right direction if we want to decouple things, and give teams more ownership.
So we don’t need to have a very clear vision about what the actual architecture is, or exactly how we get there.
We just have some principles that we know are taking us in the right direction.
The problem can be that modernization often does require some bigger decisions, some more global decisions around particular ways of shaping an architecture, certain architectural principles, or particularly technologies.
I’ve seen companies that say we have the principle of teams being autonomous, and then they build things in different ways with different tech stacks, and they have tech sprawl, and then that becomes the next big topic three or four years later.
So I think we we can definitely define principles, and try and move in the right direction, even if we can’t invest in big modernization work.
Or sometimes we know there are things that need to be modernized, and that goes back to the scope question.
We can say, well we know this needs to be modernized, we’re not sure if it’s the right thing to modernize first, or the most valuable thing, but we know there’s definitely value in doing this, so we can do this, and then figure out if we modernize other things later on.
Obviously it does contain some risks.
You might modernize this in a way that you later decide doesn’t meet the approaches and patterns or tech stacks you want to use, and so there’s always some risk though, but I definitely feel that it doesn’t need to be a big strategy, as long as you can have some justification that we have some principles, we have some inkling of where the business is going, that makes it seem important that this will be useful at some point in the future.
I really like the principle that you just mentioned, that there should be, and I think you said teams should be responsible for domain, including the data, I think that’s what you said, right?
Yeah.
And I think, because it’s just one sentence, but it’s actually quite powerful, and it reminds me about that principle that Amazon had, that everything should be accessible by an API, which is also quite simple, and I guess also quite powerful.
So I think that’s a good thing.
And it’s not a strategy that is on a hundred slides, but it’s a rather simple thing, simple and powerful.
Then there is a comment by, so if that doesn’t answer the question, you can still answer additional questions.
There is a comment by Christian BeuthenmĂĽller, and he says, usually modernization in my area is just driven by end of life of existing technologies, products, et cetera.
And usually it goes on and says, that sounds familiar, mostly it’s modernization pushed by security teams, and that he heard about that by a friend, and it goes on many times without doing a lot of work in business process and data quality modernization.
We just leave you in a more modern version of the same crappy situation.
So I guess the answer that we could try to, that you could try to answer is, what would you do in such a situation where the modernization seems to be just about, you know, that old technology that doesn’t have any security updates anymore, and that you need to migrate away from?
Would you just do that, or, you know, put that same stuff to a new technology, or would you use a different strategy in that case?
The first thing I would say is, we have a very hard commitment, or a very hard requirement to modernize, because the technology is becoming to its end of its life.
So I would see the positives and say, well, we have to modernize, so we have to modernize, basically, and then the second part of that would be, how can we modernize this in an effective way?
If people are just expecting us to rewrite it in the new tech, well, if we can’t convince them that’s a bad idea, let’s maybe not tell them exactly what we’re doing, and just tell them it will be done by this date.
But I think the important point is, there are different layers of modernization.
Moving to new technologies is definitely an important one.
We can be productive in the latest programming languages, latest infrastructure, for example.
Definitely some benefits there, but also we have a chance to improve the UI as well.
That is something that’s visible, and so you probably couldn’t do that under the radar, but you can say things like, you know, it would be much easier for us to actually build a new UI from a blank canvas than actually try and rebuild the current one.
So you could use a few magic tricks there to get some investment in the new UI.
But what’s also important is the coupling in the software, some of the bugs in the software, and also the domain model.
Domain model is something that changes a lot over time, and the domain model in your people’s heads and the domain model in your software can become very different.
When you first build a product, you build it for certain use cases, and then over time the software solves more problems, implements more use cases, and you build these features in a way that you probably wouldn’t build it if you were starting from a blank canvas.
Like when I worked at Salesforce in the marketing cloud, for example, we had this tool that was used to run advertising campaigns on Facebook, and there was a business requirement to make it support LinkedIn and Twitter.
Did they build a domain model that treated Facebook, LinkedIn, and Twitter equally with some optimal abstractions?
No, they put LinkedIn and Twitter on top of this model designed for Facebook, and so that’s the kind of thing that happens as the software evolves.
The thing I would say in these situations is, to try and justify this kind of investment, is it can actually often be cheaper.
There’s probably a lot of your software that is not being used anymore.
If you can figure out what that is and not modernize it, you can save a lot of time.
You can also take the chance to identify where the current software causes problems and say, if we’re going to modernize this, we could also fix this problem quite easily.
An example might be the words used in the software don’t match how we talk about the business, and we have this problem where whenever we try and figure out how to implement new requirements, it’s difficult to translate between the information in Jira and the words in our code, and we have some issues where things are implemented incorrectly, the business rules, QA fails the tickets a lot.
So I would say it’s nearly always beneficial.
Well let me clarify, if all you need to do is for that software to keep running and you don’t want to make any changes to it, maybe it is okay to just do the minimum amount possible to update to modern technologies and make those security issues go away.
If you plan to keep making improvements to that software, I would say in nearly every case it makes sense to do a deeper modernization where you fix the domain model and make that code base easier to work with.
And so then trying to justify the changes or trying to do them secretly.
Or, you know, talk.
I mean, to me it seems like it’s a reoccurring theme.
It’s basically what we discussed before, you know, talk to the business people, talk to them in the language, try to be explicit about what the benefits might be and maybe have that one-on-one conversation and talk to them about how that modernization, how you could get a lot more out of it.
And, you know, give it a shot and not just accept that there should be, just the business problems should be fixed.
So that might also be an answer, I guess, or it seems to be the logical conclusion from what you said before.
So let me see.
I’m just looking at the chat now.
So Deirdre said about the question about the strategy that the question was indeed about the technical challenges and whether you can do a modernization without a strategy.
So I think we answered that question.
Superman said, agree with both of you about the modernization and how sometimes the modernization is just about fixing security problems.
And he or she continued to say, maybe modernization is a bit controversial to never change the running system.
So what do you think about that?
That’s actually interesting because sometimes, you know, ending legacy code means making sure that the code behaves in exactly the same way as it did before any changes.
While what you’re saying is that we have to figure out the business case and which means that we have to change the behavior.
So how do you, is there a contradiction there or what’s your answer to that?
No, I think that makes sense.
I think it’s all about what our future plans are, as I touched on before.
If this is what we might call a core domain, for example, in DDD, an area that’s highly important, an area where the company does something unique to that industry, something that doing it better would give the company an advantage in the market, and we want to evolve that in the future, then I think modernization should definitely be about how to make that code base as easy as possible to work with for future improvements.
But if we just want to keep something running and not make changes to it, then yeah, I think it’s okay to take a less risky approach.
But the one caveat I would say is we have to understand if something isn’t changing because there’s no business reason or because it’s currently too expensive.
And that’s one of the questions to try and get out of the stakeholders.
We don’t really make improvements in this area that much, so it seems like it’s not important.
But let’s imagine we could implement some new features here, and let’s imagine we could implement a feature and it would only take a week.
Would that change your perspective on actually adding some value here?
And they might say, as I touched on before, they might say, oh yeah, there was a lot of things we wanted to do here, but the developers always said no, or it was too expensive, or we started these projects and they never got finished, so we don’t touch that anymore.
So trying to understand what’s the ideal level of change in a domain, and you might realize, oh, that actually could be a core domain.
We see that as a supporting thing and we don’t touch it very much, but it could actually be a core domain.
And just to add one more thing, I think that mindset of if something’s running, try not to touch it, I think that’s kind of the risk that leads us to need to modernize.
If we can not have that fear, if we can continuously improve our codebases, we can avoid the need to do these big modernizations.
Karol Skiamowski, I hope I pronounced it correctly, said, how would you approach a modernization of interoperability on an IT ecosystem level?
It is a very specific topic, I know, that’s what he added, and he also said later on interoperability as in application integration capabilities.
I have to admit that I’m not entirely sure what he is talking about, so do you have any thoughts about this?
Maybe need a little bit more, I’d be very happy to answer the question, maybe a bit more clarification, if you can describe the scenario a bit more.
Sounds very interesting though, so please do share some more details, we’d love to answer that one.
Okay, excellent.
Then there is Marcello Costa, again I hope I pronounced the name correctly, he says, Nick, do you believe that modernization is a strategy that needs to be accepted by the highest position in an organization, including those who implement the actions such as the infrastructure team?
That’s a good question.
My default feeling is it’s certainly a lot easier, and that’s one of the great things about working at PayFit right now.
PayFit recognizes, whether you talk to the CTO or the CEO or the Chief Product Officer, everybody recognizes and talks about this transformation work that’s happening, and there’s a very clear connection between doing this architecture tech transformation work now and the business opportunities that this will open up in the future.
So there’s a very clear connection and everyone’s talking about this, and so it makes life much easier because we all know that modernization is useful, we all know why modernization is useful.
Modernization is not just a tech thing, it’s something that product wants as well, because product knows in one or two years we can do the amazing things that are currently possible but may be a bit difficult or a bit expensive to achieve, but in one year we’ll be able to do some things that will really change the industry perhaps we could say.
So definitely my answer is it definitely makes it easier if you have that buy-in and if people sing a consistent message and if there’s a clear link between business and modernization, well I feel very lucky to be in this situation at Salesforce definitely.
Is it mandatory?
I don’t necessarily think it is, but at some point you’re going to have to build a roadmap and at some point people are going to be asking for new features and at some point people are going to be saying why aren’t we delivering any new product features if you just do modernization?
So I don’t know how you can avoid having that conversation.
It can be done, you might not want to talk about this big modernization thing because that might have the narrative of oh it’s a tech thing.
If you can frame it in the business perspective and not call it modernization or not use a technical sounding word that might be the best approach, but I think at the end of the day there needs to be some agreement at a high level of the expectation around new features versus investing in improving IT systems.
And to that point I mean as you said before you could start to do things in secret and Christian Beutenmüller said I don’t like hiding, making things in secret seems like a terrible fix for a toxic work environment and not enough trust.
That’s a fair response, I agree.
If we don’t have to do things in secret I wouldn’t do that and I think there’s always a risk to doing things in secret, but sometimes we don’t have to tell people too many of the details.
We can say this will be modernized by this particular date, here’s how long it will take, maybe here’s how much it will cost and the way you modernize that is left to your best interest about what you think is best.
So maybe it’s not secret.
Maybe it’s just not giving people information that they might not be able to use correctly and might interpret incorrectly.
Or, yeah, because you want to avoid having a conversation, but you must be very confident that what you’re doing is the right thing.
And you’re going to decide to make that executive decision yourself.
So I agree most of the time, we should try and address those dysfunctions.
Sometimes keeping things a bit quiet, quiet, being a bit sly, hiding a few details might be an effective tool.
Yeah.
And I just want to underline what you said, what you already said, that, you know, having one-on-one conversations, trying to challenge people in an environment where, you know, it’s just the two of you and people can actually.
And, you know, it’s not in front of a crowd or anything like that.
And trying to become better and trying to understand what the other people are actually achieving.
This is something that we can do as technical people.
And I really like that you spoke about that.
I’m not sure whether it’s always a toxic work environment.
Sometimes I have the impression that technical people think, well, those business people, they don’t know anything because they don’t actually know a lot about technical stuff.
While we have the same problem, we don’t really know a lot about the business stuff.
And, you know, this is something that we can change.
And you said that, you know, we can have these conversations and so on.
And that is something that we can change.
And maybe that’s one key to not do it in secret, but, you know, rather have a good conversation and a better collaboration between business people and technical people in particular.
So Carol says, to clarify, we have an ecosystem composed of – so that’s about the integration thing.
He added some information as you requested.
So he says, we have an ecosystem composed of over 20 systems, each having its own domain.
Those systems need to communicate and exchange data often cross-domain interoperability.
So let’s say that the current application integration capabilities are limited to file transfer and batch.
How do you approach modernization of that particular capacity?
And Marcello already suggested to – already said that he built something like this with an integration hub based on Apache Kafka.
And Carol went on to say that this might not be a feasible option because most companies do not need streaming for EDA.
It is not the right tool other than that the issue is not technical really.
So any thoughts about that?
Seems like a technical challenge somehow to implement a better version of integration, not using files.
I think that’s basically what it boils down to.
Yeah, so very clear question, makes a lot of sense.
One of the most important topics on the technical side of modernization is around integration.
At PayFit, for example, that’s one of the responsibilities of the staff community.
We have an engineering strategy which talks about our approach to use event-driven architecture.
That’s a choice that’s being made on a global level, a way to give teams autonomy and a way for domains to talk to each other and stay connected, share state changes, for example.
So with that global strategy on a technical level, we then have some guidelines on how to do event-driven architecture, have some patterns, recommended patterns.
We have guidance on what’s a domain event versus what’s a more technical or CRUD event, provide teams some guidance on how to do that effectively, on how to model those interactions.
And then we also have some tooling, a platform and some tooling that handles some of the conventions to make it easier for teams.
So for me, that’s always one of the best situations to be in.
I work in a team.
We’re responsible for a domain that we own.
We need to integrate with other domains.
We have a clearly defined way of doing this, a standard way in the company.
We have toolings and platforms that make it easier for us to do this in the approved way.
It just takes a lot of responsibility away from the team, makes our life easier.
It makes it easier to enforce conventions, to build tooling that can be reused by all of the teams.
There’s also another benefit there where you standardize on technology stack.
If you have the more standards you have, the more tooling you can build around those standards.
And then this kind of integration is also useful for the modernization itself.
One of the biggest technical difficulties of modernization is that migration phase where you’ve built some new stuff, but you still have old stuff.
And these two things have to talk together.
It might be that you’re still doing transaction in the legacy system and the new system is displaying that information to the user in a read model.
Or it could be the other way around where your new system is processing transactions, but the legacy still has to present the information to a user.
Maybe in some back office application.
So this data synchronization has to happen.
You’ve still got bits of the logic in different places.
And if you have a standard way of making the new and the old systems talk to each other, again, that can accelerate your modernization, make it much easier.
So for me, the topic of integration is super important.
You don’t have to follow those principles I mentioned.
But for my position as a staff engineer who works across multiple teams, my position as a developer who’s worked on these kind of projects before.
Having a way to do a consistent way to do integration and tooling that makes it easy to do that.
Certainly my preferred approach.
And I would say, why not have standard ways of doing things?
Why have multiple different ways of doing things?
If there’s performance benefits or if there are other specific benefits, then it’s OK.
But most of the time, having different ways of doing integration just for the sake of it makes things a bit more brittle.
It puts more load on the teams.
It makes it harder to enforce standards.
You can’t build tooling to make your life easier.
So I definitely lean more towards the side of consistency with a caveat of, as always, you need to have good standards and you need to build good tooling that makes developers lives easier.
The more of this stuff you build in-house, the more you have to be careful.
Are we doing this the right way?
Definitely some risks in this approach.
I’m not saying it’s a perfect solution, but when it’s done well, I’ve seen it done well.
It can be very beneficial.
When I worked at the UK government, for example, they had a platform that allowed you to build new microservices and APIs, provided lots of tooling.
They provided a HTTP library that all applications had built into the application template.
And it baked in some security ways of doing authentication, added headers on to your requests and things.
So that was one way.
Like I said, at PayFit, we’re doing more of an event-driven approach here.
So the tooling makes that easier.
Yeah, thank you.
There is a completely different question, which I think is quite interesting, by Z.
Parvich.
And the question is, do you find modernization efforts overlap with feature development or more often stand on their own?
In the former, how do you effectively balance the goals, which may be at odds with each other?
Sorry, I’m just choking on some water here.
Sorry.
Could you repeat the question, sorry?
So the question is, do you find modernization efforts overlap with feature development or more often stand on their own?
In the former, how do you effectively balance the goals, which may be at odds with each other?
I would say the… Sorry, go ahead.
No, no, carry on.
I was just trying to sum it up.
So it’s basically about feature development versus modernization.
How do you deal with those two competing goals?
I would say in most cases, modernization is an ongoing topic.
In the projects I’ve worked on, it’s very often teams are being asked to do modernization work alongside their product work.
There isn’t this one roadmap that the whole company follows.
Modernization is more principles driven, and it’s up to different teams, different departments in the company to balance feature work and modernization work.
I have seen companies that do a complete modernization and start building new features.
You can do that.
And one of the examples in my book is OpenTable, who did that around 10 years ago.
They did a whole modernization in nine months.
And there was a business reason to do that, and it was sensible, but that’s not the most common experience.
So, yeah, I think for most people, there will be a need to balance features and modernization work, and that brings a lot of challenges.
So there is no one way of doing it, I guess.
There are still a few questions.
I just want to really shortly talk about the book, because there is so much stuff that we just can’t cover.
So the book talks about, as Chip does, about what the mapping, product taxonomy, big picture, event storming, and so on.
So it gives actually quite an overview about lots of different techniques that you can use to do application modernization.
So I think that makes it quite valuable.
And because we already talked about the communication side of things, do you want to say a few words about the listening, too?
I think that was quite an interesting thing, too, that I read about in your book.
Yeah, sure.
I’ll quickly touch on those chapters of the book, and I will say, basically, as we discussed in this call today, the business strategy is the north star we need to be able to make effective modernization decisions.
And so I didn’t just want to write a book that says, you need to have a good business strategy to do modernization.
I wanted to actually cover the techniques I’m using myself to actually get that knowledge.
And so the listening tool is definitely one of them.
There are many benefits from a listening tool.
I would say, firstly, it’s a chance to understand what’s important to different stakeholders.
You can do these listening listening tours in different ways.
But the idea is talk to different people in the company, people that you might not normally talk to.
And what you’re trying to work out is what are the main problems they face?
What are the what things keep them up at night?
What things have they stopped asking for?
What assumptions do they have?
What misassumptions do they have about what’s possible?
And it’s also a chance to build relationships.
So we just talked about this product versus modernization trade off.
If you can build good relationships with people, I think probably trust is the most underrated skill you can have when you’re modernizing.
Because at some point you’re going to have to say to someone, I know you want to build this new feature, but trust me, if we don’t build this new feature now and we do some modernization instead, you’re going to get something really better in the future as a result of this modernization.
And that person has to decide, do I actually trust this person that I will get something better in the future?
Or do they not understand the business or do they just want to modernize for tech reasons?
And so if you talk to people about what they’re trying to achieve, their work, what keeps them up at night, what they’d like to improve, you’re much more likely for them to feel like this person has listened to me.
They understand what my challenges are.
They didn’t come in with a solution.
They weren’t talking about modernization and looking for a reason to justify it.
So you’re much more likely to understand the true value of modernization and you’re much more likely to be able to have those conversations.
And you’re much more likely to actually get to do modernization because you have clear justifications and better relationships with those people.
And I think, yeah, doing a lot of those listening tours as a consultant, I learned a lot of things in those sessions.
And it’s a skill that was definitely not easy.
I had to work on this a lot.
I’m not someone that likes small talk, really.
When someone says, how are you?
And you say, yeah, I’m good, thanks.
I actually really hate that, hate all of those small talk things.
But in these good listening tours, I realized I learned how to get used to that.
And I found the best conversations I was having were where you start with some small talk and you let the conversation move on to what’s important.
If you rush in and say, what are your top five problems or what are the 10 things that you want to achieve?
Or what’s your top priority for this year?
It can all feel a bit forced and artificial.
You can have these more organic conversations and you can steer the conversation in directions and say, someone might talk about what they’re currently doing in that day.
Or they might arrive to the meeting a few minutes late and they’ll say, I’m so sorry, we had an incident in production.
You might say, oh, no worries.
Hopefully it won’t happen again.
Or hopefully it was just a one-off.
And they might say, oh, no, it’s not a one-off.
This is happening every week.
And you’ve already learned, okay, we’ve got some great information here.
They’ve got a lot of production incidents.
And that’s one of the things why I really like the idea because it builds the foundation for further communication.
And also the skill of actually listening to people and making an effort to understand what their goals are is quite valuable.
And it’s sort of, I guess it’s underrated.
So that is why I think this is quite interesting.
And as I said, I mean the conversation that we are now having is quite different from what the book can add because there are so many chapters about concrete techniques that you can use, as you said, to understand the business, to model the business and do these kinds of things.
So therefore, I guess this conversation is a good addition to what it says in the book, which basically means you should take a look at the book and what it has to offer because we are definitely not covering at all what the book says.
So that’s why I think it’s an interesting additional source of information.
There is one final question that we can, I think, answer from the chat, which is, again, quite a different question.
And the question is, Nick, do you have any experience with documentation by modernizing systems environments?
Is legacy documentation hindering, misleading, or is it useful?
Well, I would say most often there’s some usefulness in there, but things change very quickly.
So I recently joined PayFit, for example, three months ago, as I said, and I go through a lot of the documentation and I see things like, oh, the team that owns this doesn’t even exist anymore because there was a reorganization there.
This way of modeling these domain concepts has changed and it might only be one year ago.
So I think documentation is always very suspect, but if you treat it with the right mindset and you imagine this was correct at a certain point in time, there’s probably lots of this that is still correct nowadays, then I think it can be useful.
But I think at the end of the day, if you want to be very confident about something, you usually need to go into the code and look at the code or the database, for example.
And that’s why I like to be a staff engineer in these projects, because I want to have time to get into the code, understand issues, see the complexity in the code.
At PayFit, I currently work on customer support sometimes.
We do this rotation role, so I get to see the customer support issues that are coming in.
And I think the documentation helps me to learn some things, but actually getting into the details of the system, I learn a lot more that way.
Okay, thanks.
So, final question.
Is there anything that you think the audience should do or what they can do?
Any advice in that regard?
I would say in terms of architecture modernization, the one thing I learned writing the book is there are many things that are similar, many challenges, but also lots of things that are quite unique.
As I wrote the book, I worked with different people.
There were some case studies in the book, and I found that this was the most enjoyable thing for me, talking to other people, learning about how they modernize in their company, the real challenges they faced, what works, what didn’t.
Realistic expectations.
And so I think I would love other people to write more about this topic.
It will be great to see more case studies out there, things that worked and didn’t.
I think that there’s maybe not as many as there should be.
And I think that a lot of people might not realize that what they’re doing is super interesting and other people could benefit from it.
You might think, oh, we have this weird, obscure legacy system, but I’m sure someone will have some similar issues or there will be some principles and takeaways that they could benefit from.
So if you’re ever in doubt of sharing any of your experiences, I’m sure it would be worth it.
Yeah, so thanks a lot.
And I think this is also actually something that I enjoy about the community, having conversations like these and reading through any kind of blogs and material.
So I would totally agree that it would be great to read more of that.
So we’re actually pretty precisely on time.
And we also actually, or you, answered all the questions in the chat.
So that’s great.
So thanks a lot for being on the stream.
Thanks a lot for answering all the questions, for the insights.
And next week, I’m actually not sure I am going to do next week, but there will be a show next week.
And I will put the link to the book in the show notes and also the link to your website.
So if you want to have any further information, those are the sources that you can look up more information.
So thanks a lot and have a great day.
Have a great weekend.
Thank you.