As a client-facing technical project and product manager, I've often employed the 'Spiked Solution' design pattern when modernizing legacy applications. This deliberate approach, akin to the 'Steel Thread' in its overarching direction, instills confidence in the project's trajectory.
A Spiked Solution or Steel Thread compels a cross-functional team to construct a proof-of-concept by first tackling a system's most complex and critical data workflow.
For instance, on a recent banking project, the client wanted my research and development engineering team to investigate the possibility of integrating a legacy loan origination system into the modern data activation platform. With its complex and expensive desktop app, the banking legacy system was thoroughly investigated to meet the business request of integrating the legacy system API deep into the modern data-driven platform our team was building.
The business request: Can we replace the legacy desktop app with the modern web application we are building? Can we save money on desktop app licenses? Can we create operational efficiency by using one less tool?
The 'Spiked Solution' was pivotal in addressing the business request. It answered crucial questions: Can we leverage the legacy API in our modern tool? How much can we integrate and replace today? What steps will become apparent for future integrations and replacements? This progress reassures the audience of the project's well-managed trajectory.
We used the legacy app as the specification for the modernization, not the user manuals, API docs, or our desires. During a deep-dive demo of the legacy desktop app, it was obvious that there were at least five, possibly more, third-party enrichment/integrations in the legacy app that did not exist in user docs or developer API.
Working with the consulting engineers on our team, we reviewed the legacy API docs. We saw none of the third-party enrichment APIs. I emailed the legacy vendor professional services contact, who confirmed these enrichments did not exist in the client-facing API and that we needed to develop relationships directly with the third-party API vendors.
With a healthy budget and a competent engineering team, I instructed my engineers to Spike / Steel Thread the Loan Origination API and prove we had no return options for third-party enrichments. Within a week, my engineers built a modern web application that constructed API requests to the legacy app API endpoint, captured responses for debugging, and saved the data into a modern database. We could now compare the modern Spiked Solution / Steel Thread data workflow with the same workflow in the desktop legacy app.
The Spike / Steel Thread was sparse, with no third-party enrichment, and reset expectations around what was achievable in modernization at what stage. Our cross-functional team could celebrate a qualified success. We originated a data flow, but third-party enrichment and completion of the workflow would require further vendor management, commercial arrangements, and research and development.
The Spike or the Steel Thread highlighted these indisputable facts, put boundaries around our modernization product feature implementations, shaped our roadmap, and filled in future project budgets.
Using the discovery from the Spiked Solution or The Steel Thread, we adjusted expectations based on ground-truth reality, added boundaries around the Spike proof-of-concept, and now had a roadmap for future third-party enrichment API integrations.
I've used the Spiked Solution or Steel Thread in many projects, where research and development lead to discovery and feedback on product definition. This form of lean product development aligns client requests with continuous delivery of business value and avoids big bang/success-fail project surprises.
The "Spiked Solution" was one of the first software patterns I learned from the Cunningham Wiki C2 Wiki (before Wikipedia), and its cousin, the "Steel Thread", is a worthy inheritor of this legacy. Legacy application modernization projects require careful and continuous delivery of business value, unlocking business data workflows from legacy apps and bringing those data workflows into modern platforms for future agile development.
More research:-
