Defining the milestones to your organization’s future state
When Replatforming an application or system, most software professionals are good at imagining the desired future state. However, identifying the real-world objectives, challenges, and milestones in the journey to that future state ultimately ensures a successful project. In this blog post, we focus on Incremental Releases as a core tactic in our Strangler Fig toolbox for Replatforming critical systems. We describe Incremental Releases and share some relevant considerations and Agile practices.
A large Replatforming initiative is not a sprint; it’s a marathon. Including defined milestones or interim releases along the way helps manage project risk by providing opportunities to check on progress, gather feedback, and course correct as needed to ensure the journey heads in the right direction and at a sustainable pace. Interim releases allow you to reap the benefits of your investment early while also helping mitigate technical and business risks, rather than waiting for the big bang finale.
After more than 30 years of development experience, Intelliware has implemented many Replatforming projects for enterprises big and small. It’s not just the strategy that makes it work; it’s the detailed tactics a team uses in modernizing that have the most significant impact.
“In reality strategy is actually very straightforward. You pick a general direction and implement like hell.” – Jack Welch
The Strangler Fig strategy to Replatforming involves creating a new and improved system around the old one until, over time, the old system is effectively strangled. We have found Incremental Releases helpful when implementing the Strangler Fig approach. Effectively architecting, implementing, testing, deploying, and validating interim states or milestones, without disrupting the existing system’s operations, represents the fundamental challenge to making this approach work.
What Are Incremental Releases?
Incremental Releases means delivering software in pieces. This approach jives with the Strangler Fig strategy because the process of surrounding a legacy system with a new one relies on moving functionality to the updated architecture and platform in chunks or milestones. Incremental Releases provides a mechanism for identifying what should go into the milestones and implementing, testing, deploying, and validating them.
Defining Increments
Determining what each milestone should contain or focus on when implementing the Strangler Fig strategy is not straightforward. The team must balance multiple forces, including technical risk, business value, and feasibility. Experience helps with the many decisions. Context Mapping, part of the Domain Driven Design (DDD) toolkit, is one technique that can help determine the scope for milestone releases.
Early and frequent delivery of business value to the customer matters greatly. The first principle of the Agile Manifesto affirms: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Close collaboration between the development team and customer when defining milestones helps determine what matters most to them and how best to deliver against their expectations.
Milestones must balance technical risk with business value. Deferring key technical risks too late in a Replatforming initiative can lead to failure if discovering a difficult technical hurdle late in the project doesn’t leave time to solve or work around it. It’s better to address critical technical risks early and fail fast than to discover, a technical concern that blocks the way with little time left. Collaboration can help ensure that the customer understands why some features may be a priority from a technical perspective, even though they may not provide much business value.
Feasibility considers when a milestone gets tested, deployed, and used successfully. The development team should assume that each milestone eventually ends up in a production environment and ultimately used by people. For example, a milestone that can’t be deployed due to unresolved external dependencies is not useful. Similarly, milestones that lack user acceptance testing to ensure the seamless integration of new functionality also provide little use.
How Often to Release
The answer here is “as often as possible.” But it’s essential to understand the difference between deploying something to production and releasing functionality to end-users. On a Replatforming project, developers can deploy each new feature to the new platform while leaving existing functionality running on the legacy system. But releases to users should only occur as often as they can test and adopt them.
Continuous Integration and Continuous Delivery (CI/CD)
Continuous Integration is a refined adaptation of the regular delivery cadence. It puts greater value on testing automation to confirm an application works after changes are integrated into the main branch. This approach helps to stabilize development and increase efficiency while providing feedback.
Continuous Delivery automatically creates packages or artifacts as part of the build stage to deploy, or not, toproduction. In addition to automated testing, an automated delivery process enables the agility to deploy your application at any time.
Embracing continuous delivery and deployment practices ensures the delivery and deployment of software artifacts to non-production environments (e.g. Development, QA, Staging) at least once per day.
The practice of continuous deployment to Production environments depends on the software team’s technical maturity and business considerations (e.g. regulations, testing requirements, certifications). Continuous delivery and deployment accelerate feedback loops and remove the big release day; teams become accustomed to delivering and deploying smaller changes more frequently.
Replatforming projects tend to focus on how the new platform’s architecture evolves as features from the legacy system are delivered and deployed. However, to realize the benefits of frequent deployments and frequent releases, the Pipeline technologies that support the delivery and deployment of features must be addressed.
We recommend using Continuous Integration to reduce regression risk, introducing Continuous Delivery to accelerate feedback and reduce release risk, automating deployments and using Feature Toggles to manage the availability of deployed features to end-users.
A DevOps mindset integrates these activities with the core development team, not delegating them to the SysOps team. A Replatforming project should focus on replacing a legacy system and providing opportunities to improve your practices and policies for deployment.
Want to know whether the strangler fig approach can help Replatform your legacy applications?
Ask us to complete a short Discovery. We can eliminate the risks in your digital transformation and find the best path forward to replace your legacy headache.
More recent stories
Category:
