Great advice! To get management buy-in, focus on other benefits as well. While important to reduce failure rate, it's also great to get better opportunities to e.g. consolidate logic, improve performance, add a cache, add monitoring, modernize tech stack, move from vertical to horizontal scaling (containers?) or whatever you might be eyeing at the same time..
As i here your wise advice i have failed promise of OOP before my eyes, especially missed shoot at encapsulation level - betting on objects more than modules
Timely advice. I currently have.a system where data is duplicated in mongo, maria db, sybase and SAP where the same tables are updated via multiple apps. I am trying to convince management the idea of ownership. Then there is the reporting where they hit a mariadb directly via a third party reporting system (tables with 200+ columns) and I keep telling them to create an API because maria db is failling them and we need to migrate since scaling is an issue. I think they are sick of me in meetings because I keep asking which app should own the data . I think they understand but quite frankly there are so many apps spread out and what I am suggesting will take time just with existing functionality it is virtually impossible to get buy in.
I'm currently working on a big spaghetti codebase where I'm trying to migrate databases. It does a lot of things including generate reports for that data. And the way I've approached it with this mindset is I'm moving out reporting to a new service. It has basically forced us to implement a way to know when data changes to be able to update the data in the new reporting database. This also means that when I start moving out other parts of the system, I will be able to still have a way to hook into these events and have the data I need to perform whatever it is I need to do. For years this project has struggled because it is too big and being supposedly impossible to refactor without a big bang rewrite but I finally see a light at the end of the tunnel thanks to this pattern. Great advice.
Reporting/Query purposes is often times what is the biggest hurdle. I wanted to mention it more but yes, creating a specialized DB or even creating a schema that resembles the current schema but purely for read purposes is also a strategy, and the segregating the write schemas behind their proper boundaries. At least as a stop gap to keep existing queries working while you transform everything.
I work on a 20+ years old shitty laravel codebase without any test and with gigantic, 2k+ lines, files 😅 I doubt we can fix it, even more so with only 3-4 devs on the team 🤣🤣🤣
Ya it's a challenge. You may never get it to where you want, but small incremental changes to isolate functionality and the data behind it can be beneficial.
Great advice! To get management buy-in, focus on other benefits as well. While important to reduce failure rate, it's also great to get better opportunities to e.g. consolidate logic, improve performance, add a cache, add monitoring, modernize tech stack, move from vertical to horizontal scaling (containers?) or whatever you might be eyeing at the same time..
That's a good comment and topic about management buy-in.
As i here your wise advice i have failed promise of OOP before my eyes, especially missed shoot at encapsulation level - betting on objects more than modules
Timely advice. I currently have.a system where data is duplicated in mongo, maria db, sybase and SAP where the same tables are updated via multiple apps. I am trying to convince management the idea of ownership. Then there is the reporting where they hit a mariadb directly via a third party reporting system (tables with 200+ columns) and I keep telling them to create an API because maria db is failling them and we need to migrate since scaling is an issue. I think they are sick of me in meetings because I keep asking which app should own the data . I think they understand but quite frankly there are so many apps spread out and what I am suggesting will take time just with existing functionality it is virtually impossible to get buy in.
Thanks for the comment. As another commentor mentioned as well, approval/buy-in really is a roadblock beyond technical.
I'm currently working on a big spaghetti codebase where I'm trying to migrate databases. It does a lot of things including generate reports for that data. And the way I've approached it with this mindset is I'm moving out reporting to a new service. It has basically forced us to implement a way to know when data changes to be able to update the data in the new reporting database. This also means that when I start moving out other parts of the system, I will be able to still have a way to hook into these events and have the data I need to perform whatever it is I need to do. For years this project has struggled because it is too big and being supposedly impossible to refactor without a big bang rewrite but I finally see a light at the end of the tunnel thanks to this pattern. Great advice.
Reporting/Query purposes is often times what is the biggest hurdle. I wanted to mention it more but yes, creating a specialized DB or even creating a schema that resembles the current schema but purely for read purposes is also a strategy, and the segregating the write schemas behind their proper boundaries. At least as a stop gap to keep existing queries working while you transform everything.
I work on a 20+ years old shitty laravel codebase without any test and with gigantic, 2k+ lines, files 😅
I doubt we can fix it, even more so with only 3-4 devs on the team 🤣🤣🤣
Ya it's a challenge. You may never get it to where you want, but small incremental changes to isolate functionality and the data behind it can be beneficial.
JavaScript
Javascript?