Being a successful company means staying power. Your brand, market presence, and most importantly your products, have managed the difficult task of growing year-over-year, staying ahead of the competition, and ensuring your solutions are relevant. With that success comes the very common reality aging technology and a growing pile of “tech debt”.
Tech debt is not inherently a bad thing. It is a business tool and works very much like its financial counterpart. Technology debt items are choices made throughout the development and maintenance of a product to forgo seemingly complex, expensive solutions in the short-run which would save you money in the long-run, in favor of cheaper fast solutions now, that if not addressed would end up costing you more in the long-run. Like financial debt, technology debt compounds if not paid down, but if used responsibly, can accelerate time to market and revenue.
Tech debt is a choice that was made, it is not your bug list. Regardless, if your tech debt is not paid down and your technology is aging, it's likely that your bug list is growing too. The result is a slow but steady march toward obsolescence that presents itself in at least 6 ways:
A rising total cost of ownership
Brittle inconsistent technology that is difficult to modify or learn
Slow ramp-up of new engineering talent
Slow feature development
An inability to leverage newer and lower cost infrastructure technologies
The competition running circles around you
You need a technical strategy to modernize your products while addressing both your tech debt and your bug list all at once. And you need to do it without shutting down your business for a year to rewrite everything.
As a technologist addressing this problem, there are several immediate issues that need resolution.
How do you incrementally update or refactor components of a solution while preserving functionality as you go?
If you have a monolithic solution, how do you do maintain referential data integrity within each sub-component of your stack while you tease apart your solution into services to avoid a whole-scale refactor?
How do you insulate end users from what is happening beneath the covers?
Let's assume the worst case scenario, a monolithic 20+ year old application that needs an overhaul in order to modernize. Here’s how we’d go about the task, and how United Effects transformation services in conjunction with Core EOS makes it a little easier.
Ensure logical separation between UI, API requests, and data access
Before you address any major changes to the product, you’ll want to ensure there is some separation of concerns in the processing layers of the solution. Many applications grow organically and if they did not account for complexity early on, there may be some inconsistencies that you need to map and if possible fix.
Specifically, you should, at minimum, ensure logical separation between the UI Client, API / Business Layer, and the Data Access Layer.
This distinction will allow the API interface being used by the UI to remain consistent despite the business or data logic changing.
If you find that your application is in the first category, having the UI directly interact with the Data Access Layer, there are a number of possible approaches, but a common one is to use a proxy service to achieve the same concept.
Regardless of what your API actually uses as a schema (REST, XML, SOAP, etc) it likely uses a request response format. To that end, the requests likely allow interaction with various elements of the application. In an organically grown solution, this may not be very cut and dry - that's ok. Do your best to identify approximate lines of delineation between the requests and document those groupings as functional areas.
Notice that it's ok for the overall sizing of the groups to be different.
Congrats! You’ve just done a rudimentary Domain Decomposition.
Now that you’ve logically grouped and segmented your product functionality, you can implement the Strangler Pattern. Steps 1 and 2 created a buffer between your legacy solution and the client UI (in other words, a facade) so that you can now transition one functional grouping at a time to a new technology implementation.
Core EOS handles the two biggest technical hurdles you will have to overcome while you do this:
As new components are defined, authentication and authorization will need to work between both the new components and the old without interruption. The technical components themselves may also need to securely interact across http requests.
As you pull functionality from the main body of the legacy solution into a new technical implementation (often this would be a microservice pattern), you will need to ensure that data that is being managed by the new implementation is still being synced to the legacy solution so data referential integrity is maintained, otherwise it will no longer function correctly because data will be missing that is required.
Core EOS provides this capability by providing a foundational platform upon which you can build this and many other solutions.
With Core EOS you can now incrementally move one grouping at time to a new technical implementation, modernizing with each step, all at a pace that your business and R&D group can self-manage.
If this problem and solution sound familiar, we’d love to hear more about your world and how we might help. We are confident Core EOS can help you. Schedule a demo to get started.