Jumping in and learning a legacy code base is challenging. Often the neglected, legacy code base is the most important to modernize, yet few people understand how the application fits together — and typically, documentation doesn't exist. Teams rely on oral histories, whiteboards, and static outdated diagrams that offer an incomplete picture of application information, derailing modernization plans and exacerbating project delays. When organizations rely heavily on legacy applications for business success, making risky changes can come with big repercussions.
Teams need up-to-date software architecture truth in order to successfully modernize applications, tackle architectural challenges, and make intelligent changes.
Data architecture is destiny
Last week, CodeLogic's Chief Software Architect, Brandon Tylke and DevOps Visionary, Eric Minick presented a joint Webinar with SD Times: It's Data First When Modernizing Applications. In this two minute teaser video, Brandon and Eric outline best practices for modernization and the importance of understanding the data model to successfully build out microservices.
Video Replay Preview
Access Full Video Replay
Modernize in reverse
A common strategy when modernizing legacy applications to microservices is to do the following:
- Break up the data to match the services;
- Integrate at an API layer between the service (rather than at the data layer); and
- Eventually, refactor the database
Teams working through this strategy frequently run into problems.
Often, data is hard to split in the same way you'd want to logically split runtime services. If you tackle modernization to microservices in reverse and understand how the data can be partitioned first, you can better understand how to build efficiently.
Visualize the vertical stacks
When visualizing your software architecture in a hierarchal layout, look for vertical stacks. Fairly tidy class-to-method-to-database relationships imply clean class-to-table mapping. When there are obvious pieces that are not too interconnected you can break them up easily into microservices without incurring too much pain.