Do Fusion, Unity and Next Gen get the job done?
“An architect’s first work is apt to be spare and clean. … The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a ‘big pile.’”
— Frederick P. Brooks, Jr., The Mythical Man-Month
We evaluate and help scores of software companies every year. It’s uncanny that most of the companies we work with have a “next gen” initiative underway, typically called “Fusion”, “Unity”, “Convergence”, or sometimes even just “Next Gen”. These promise to address all the architectural limitations of the first product; fixing the user interface, improving integration, speeding performance, increasing scalability, addressing reporting, supporting the cloud, and making future development more productive. Sometimes, it is the project that will address integration between acquired and original technologies. Not surprisingly, the development and product management teams are excited and motivated to work on “Fusion”.
And it’s almost always a waste of our client’s money.
Why Does the Next Gen Project Get Funded?
Our clients are often motivated to “rewrite” by internal and external forces:
- The products are missing a “platform change”, most frequently migrating an application to the cloud, or making the application in the cloud multitenant and arguably more scalable.
- The development team is challenged by the amount of work needed to meet the requirements presented by product management in the existing architecture. They believe the workload will only be manageable when they’ve moved to a better code base.
- Management can’t achieve consensus on how to integrate products and customers brought together through the merger of companies or divisions.
- Misaligned corporate vision for growth, where the organization attempts to achieve faster growth in a mature market by improving the technology they understand, in the market they understand.
- A belief by management that in order to attract a superior valuation in a fundraising or exit environment a “Next Gen” story is needed.
Finally, the technologist’s primal urge to use better technology and build “cleaner” work can overpower the less technical business advocates. Faced with alternatives both few and unpalatable, product and executive management feel they have no choice.
Sounds Good! What Can Go Wrong?
There are many significant problems with the “rewrite” process, which can eat away at the foundation of the business:
- Customer Base Erosion. The more the product changes between releases, the more likely your customers are to consider it worthy of comparison to other market alternatives. The more change you introduce, the more they can justify the investment in evaluating competing products. Thus, a vendor’s incumbent advantage gets diminished in the face of a “Next Gen” offering.
- Customer Base Dissatisfaction. New development comes at the expense of incremental improvements for existing customers. Even if development adds people to offset the talent drain, management focus remains divided. Typically, the first release of a “Next Gen” offering reaches at best feature parity. New capabilities that actually help the vendor compete are further out.
- New Sales Loss. To protect their customer base, our client’s tendency is to share the “Fusion” vision with customers, and therefore with the channel. This can produce a death spiral, as sales freeze while customers wait for a new system, and are potentially lost if the release is delayed.
- Slow Sales Recovery. “Fusion” will usually have the problems associated with new systems; schedule delays, bugs, scaling problems, limited integrations, or missing collateral materials. Startups sell to early adopters that expect to work through these problems. Our clients’ customer bases are rarely that tolerant.
- Diligence Questions. In the event your company is pursuing an investment or exit, the presence of “Next Gen” often raises more questions than it answers. Should the buyer/investor conduct robust diligence, they will find a significant multi-year cost center with lots of risk and vague unpredictable benefits. Furthermore, the notion that a “Next Gen” was required brings into question customer satisfaction and the competitiveness of the existing line of products.
Evolution Rather Than Revolution
There is an exponential relationship between project complexity and schedule uncertainty. Simple projects can be reliably scheduled, but complex tasks obscure issues that can blow up schedules deep into the development process. For twenty years now, the software project management community has recognized this problem, and has worked to come up with procedures that break complex product releases into the smallest chunks of viable product possible. The procedures for doing this incremental development is generally termed Agile development.
Agile development is wide spread, and about 80% of our clients use a development process based on Agile variants (Scrum, Kanban, etc.). These teams have embraced the Japanese Total Quality Manufacturing concept of Kaizen: a small series of incremental improvements leading, over time, to industry leadership.
Two key concepts embedded in Agile development lead to a better approach than the “rewrite the architecture” approach: “Refactoring” and “Incremental Process Improvement”. These two techniques focus on making major changes one step at a time, de-risking the project, and providing incremental customer benefit. Examples include:
- Changing pages of the user interface one at a time, rather than the (much more elegant) wholesale replacement.
- Running two databases in parallel, rather than the (much more efficient) wholesale conversion from one to the other.
- Wrapping certain legacy technologies with modern APIs and web services, rather than replacing them completely.
- Migrating functionality to a PaaS cloud vendor, rather than (the more cost-effective) building both a full cloud-based product replacement and a hosting environment.
The disadvantage is a significantly longer projected schedule start to end, but partial benefits available sooner. Our clients have found it is better to incrementally improve toward a better product over a long time period, than to risk “Fusion” or “Unity” being delayed to the same time period.
The Information Imbalance
The most surprising result is that most management teams recognize some or all of these risks, and yet decide to move forward. Often, management has difficulty negotiating the information imbalance between their technical team and the business leadership. The technical team can produce arguments, demonstrations, implementation plans, and budgets that seem to address the business issues.
It can be an intimidating prospect to wade into the details and challenge the acknowledged experts. Frequently, business leaders create compensation structures to keep development aligned, but become frustrated when development misses the goals anyway. Our clients’ development and product management team leadership are generally experts at their technology, their market, and at allocating their resources. This virtuosity blinds them to the “unknowable” nature of complex product development. As consultants, our role is to facilitate the development of an incremental path toward product transformation, producing “evergreen” products capable of delivering high margin growth.
As the Weizenbaum Principle famously states: “Projects will always take longer than expected, even after factoring in the Weizenbaum Principle.” Our philosophy is that you should spend that unknowable period of development time selling an ever improving product.