Week 12 – The trap of functional parity in modernization

First and foremost, let me attempt to define functional parity. The phrase functional parity is used in the context of system modernization to indicate that the new, modern system will have the same features as the old system. It is kind of an implied assumption between the users of the systems and the developers attempting to guarantee to the users that they will continue to get the same functionality and results from the new system as they were getting from the old.?

In principle, this is a great expectation, after all if you are going through the trouble of spending money into modernizing a system, it should be able to do everything the old one did and more, right?

Keeping our consulting hat, the answer is: well, it depends. A typical upgrade cycle builds upon the same platform and add features while fixing bugs, but there comes a tipping point for the existing platform when there is a need to switch to take advantage of a more modern platform to introduce new features. A good example is the comparison between the mainframe platform and the cloud, moving to the cloud provides an almost infinite ability to scale horizontally on as needed basis while staying with the mainframe would forcibly require upgrading the hardware and this could only be done vertically by paying the hardware vendor for well-defined capacity in advance.

When a decision is made to move to a new platform it is because the overall advantages will supersede the cost of the change; either because running on the new platform is significantly less expensive, or taking advantage of the more modern platform will allow an organization to introduce new features not previously available at a lower cost of implementation.??However, the new platform will be by its very same definition “new” and will not be as well understood as the previous one. Most organizations would have spent a significant amount of time “hacking” their existing legacy platform and would have optimized them to the limits, pushing the boundaries of what was possible throughout many years. The new platform will have important features out of the box but more than likely not all the functionalities would be available in the first release of the new system. At this point is where most modernization teams will be tempted to delay their first release until every single feature of the old system is accounted for in the new one: the functional parity trap.?

Let us take an example of a well-known company: Apple and its iPhone OS; copy/paste was first invented by Xerox between 1973 and 1976, it became a well-known and expected feature across all operating systems (including smart devices) over the years, but for those of us who remember, the first iPhone operating system did not include it. It was not until iOS 3.0 that copy/paste came to the iPhone. If Steve Jobs had decided that he needed to wait for functional parity to release the iPhone, he would have delayed its launch for over two years! Does this mean that the iPhone was not transformational when it came out? Absolutely not, it might not have had copy/paste, but it introduced us to many new innovations, including a fully functional touch only screen (with no physical keyboards), the ability to zoom in and out of pictures, and the ability to listen to music AND make phone calls from the same device, not to mention the promise of being able to add infinite new features through mobile apps. It is this author’s opinion that it would have a been a big miss to delay the release of the iPhone because it did not have fully functional parity with other smart devices operating systems.

Now, on the other hand, if the iPhone would not have been able to make calls until iOS 2.0, it would have been a MAJOR problem. Every team working on modernizing (or implementing new) systems needs to be able to weight what features are critical for each of the releases, perhaps the most important being the first release.?

Rather than trying to achieve functional parity, the project team needs to focus on what is critical for the software to perform (e.g., a?minimum?replacement of the existing system). It is not that the other features are not relevant, but they might be added later to enhance the usability and completeness of the system without impacting its core function. An additional benefit of this approach is that it will help the team to truly understand how the system is being used by the business and ultimately help improve its usefulness to the organization. By delaying the re-introduction of obscure, complicated features which might have been distracting and not being used, it effectively buys the team the time they need to rewrite them in a way that is simpler and more user friendly. Never underestimate what you can learn by releasing a?minimum?viable product and learning how the users miss (or don’t miss) the additional features.

As a disclaimer, this is not to say that achieving functional parity is not important and there might indeed be situations where you need to make sure a system is not productionized until it can perform as good – or better – than its legacy counterpart, with all its features. The decision needs to consider the trade-offs, be carefully crafted, and - more importantly - not be the result of a zealous guiding principle which was established early on the project and was never challenged for practicality.?