“Net New Ground Up (NnGu) Innovation” in software development requires a different, a very open mindset that necessitates buy-in from the teams and requires demonstrated continuous iterative progress. NnGu often brings in the digital transformation, and while oftentimes it is around a new idea; some times it may involve new ways to bridge existing gaps in your application feature set. NnGu is crucial to the long-term success of the business, makes it efficient and agile, and moves it leaps and bounds ahead of the competition.
Legacy software, 20+ year old program is increasing in terms of cost. Additionally, the legacy software is regarded as “slow,” “outdated,” “expensive to maintain,” “annoying to change,” and “impossible to work with,” “can cause more harm than good”, and specially in a connected healthcare it “can interrupt workflow” and “negatively impact patient safety.” Yet businesses demand the continuous use and enhancement of it, “because it works and is vital.” Changing or improving our legacy systems software is what the users desire, because to them new software could prove to be even more cumbersome. The most prevalent saying revolves around the legacy software is,
if it ain’t broke, don’t fix it.
Yet, updating that legacy software can feel like a stagnation of our own engineering skill set, rest aside aforementioned reasons. It, in a sense, contradicts the very definition of innovation, because by rather innovating and creating new, potentially more beneficial software programs, we’re prioritizing updating an older, outdated software that isn’t even necessarily fully functional.
Everyday we hear stories of creating the next generation software; building a “NnGu Innovation” that will manage, transform and leapfrog the legacy software systems. In December 2017, MIT Technology Review released a report [1] highlighting that integrating with legacy systems is the toughest challenge when moving to a multi-cloud environment. Given the challenge, the opportunity also lies in our ability to learn from our mistakes and finding the right balance between the two. As we progress through development, our success depends on several factors-
- Biz Case — an approved biz case reflecting the gains on completing the NnGu. A well formed and a well articulated biz case takes weeks if not months to build and present. As any other investment it goes through the approvals based on how much it adds to your business’s YOY NPV (Net Present Value) over the next 5 years or so. This sets the project goals/expectations and often requires a deep technical, functional and support knowledge to establish the measures, metrics and benefits of the innovation and how this investment is justified/balanced with everything including the cost of running legacy.
- Open Mindset — specially for the leadership on the project. This is extremely important as it sets the right direction, tone and our ability to adapt. It helps accept the challenges as they appear with utmost confidence and thus have them resolved with the right skillset. Project leaders can find themselves dealing with a lot of emotions and experienced legacy skillset and years of expertise tied to the legacy software solution. The ability to quickly align the right resources to the right problem and balance sentiments enables your team’s progression and is an absolute must have for the leadership. It’s important to be willing to stand up and fight for the right thing and to do even if the path is riddled with pain and challenge.
- Buy-in — Consistent buy-in’s from the direct team engaged on the project is a must have. If the team does not believe in what we are trying to produce and how, it will be a futile effort. It’s imperative to get an initial buy-in from all the stakeholders but its equally important to have them weigh in their buy-in iteratively at every major change or stage of the project to ensure that development stays on the right course. White boarding your architecture approaches/discussions and turning them into professional diagrams, user journey maps, empathy maps are extremely helpful; and as such these evolve and iterate from the initial discussions to next and further helps to maintain and advance the big picture in front of the team.
- “Boil the Ocean? No!” — there’s never a successful project where EVERYTHING is completed perfectly in one swoop. It’s necessary to always get iterative validation, the sooner the better, in order to help refine and polish the end product so that it stays user friendly, valuable and relevant in the market.
Demonstration of continuous progress to keep the stakeholders informed and engaged does incur a cost on the team. So, be prepared and planned to accommodate the cost of each demo, as it takes some time away from innovation to show and prove out your work. Build a cadence where this can be done with negligible disruption, and
always keep it real and simple
- “Legacy Meets Innovation” — is a fine intersection of the functionality where south meets north in full harmony, and therefore must be thoughtfully planned and righteously balanced. How much of the legacy systems [2] functionality you want or should move/transform/modernize into the net new? Eventually,
what do you desire?
From architecture perspective, how much you can converge and how much can you modernize to reduce the TCO/support. For example, if there are standalone services running in local installations, if might make sense to consolidate them, make them cloud enabled [3], and likewise locally installed rich client apps can be reviewed for the common set of functions that can be run in a more distributed cloud deployment with perhaps leveraging a web responsive device agnostic architectural framework. While doing this you may also want to carefully evaluate the future enhancements/fixes that goes in the legacy vs. building them inside the new architecture. At some point, any changes to your legacy applications must require an approval from the leadership. And, as you shift your work towards a possible set of modern cloud enabled apps and services you can start reaping the benefits from your next generation code and newer technologies. For example, the innovation can be geared towards a more consistent User Experience, Look-N-Feel and can take advantage of APM (Application Performance Monitoring), Logging, Auditing, Reporting, Dashboards, SLAs, etc. to name a few. This is also where your innovation can derive benefits from user journey maps, empathy maps and human centered designs. You want to ensure that the current paint points are removed or reduced as much as possible with a final validation from the stakeholders.
- “Game Plan” — Don’t hesitate to build or renew the game plan as needed. Whenever there is a chaos around the work allocation and timelines, make sure there is a clear game plan with designated players to move further. Our daily quest should be to accurately know,
what’s on my windshield?
Sometimes we have daily/weekly game plans, specially in the later stages of the projects when the team is trying to stabilize the final product. During this stage, teams must stay laser focused on the effort and time to get their WIP product in the hands of the validation partners as quickly as possible and with the best quality. The key here is not to compromise on the quality of the code but rather ensure that the validation partners/stakeholders are kept abreast of the current state. Remember, “it takes a village to build an innovation” that often requires,
full commitment with comprehensive followups.
Often there are several teams involved in building an innovation that may or may not be in your direct control. Identification, creation and assignment of work with the external teams is not a surprise, but make sure that there is a constant followup with all of the relying parties regardless of the assurances, until the work is complete. Ultimately, it’s your innovation that needs to stay on track and as such you must always carry a pulse and stay on top.
