or “Synergistic Nondistruptive Integration”

Back in my Space Suit Architect days, I was a fan of “green field” or second system redesign.  It made sense that we should use our hard earned knowledge of the application domain to “build the product right this time instead of rushed crapware.”  Since then, I’ve come to appreciate a more pragmatic approach that I call “Tippy Towers.”

Let’s get specific with an example…

My company, BEware, has a shipping product, Alpha, that works pretty well even though it’s all written in this obsolete language AWFOL-88.  Yeah, it’s got problems scaling, only runs on Vista, and it’s hard to add new features; however, it’s earning revenue and the sales team can sell it.

The engineering team is really hot to recreate Alpha as a new product, Omega, using Ruby on Rails (yeah, baby!) and marketing is behind the move because they’re told it’s the only way to add features.  Side note: in my experience, these claims are always exaggerated but generally true (look for a future post about working out of order).

In a green field approach, everyone agrees to stop working on Alpha and focus all work on Omega.  The company enters the tunnel of death and hopefully dies of starvation before a buggy v1.0 version Omega ships to the companies few remaining customers.

Here’s the plan.  Since we’re astronauts, our design is to build the new hotness Omega first and the later bring over the boring old features of Alpha (like an installer).  As good Agile engineers, we’ll build the most critical use cases into Omega first.  We’ll identify early customers that only need a subset of the Alpha features.  Since these are a known subset and core features, we quickly build some kick-ass next-generation hypen-inducing wonderware.

The early trial customers love the stripped down Omega product and start demanding more of the Alpha features.  Now the Alpha tower begins to tip over because we need Omega to duplicate the all features that are working adequately in Alpha.  Customers can do a comparison between Alpha and Omega and conversations start saying “I would buy Omega but I need to green cross fade accounting API from Alpha.” 

At this point, our Alpha tower is free falling.   Omega has enough features that it is hurting the sales for Alpha while customers wait for Omega.  Worse, abandoned Alpha is falling behind in the market.  At this point, we’re going to spend many months porting working Alpha features from Omega.  This is not value added work, its quality optional crisis management where we rush Omega to be “feature complete” ASAP.

Our alternative is to see Alpha as a tippy tower that we want to keep standing.  Each feature we pull from Alpha to Omega can makes it more unstable.  It takes more effort to support both; however, if Omega can leverage Alpha and vice versa then we have the luxury to focus on new features and better designs.

In a Tippy Tower mindset, Alpha is valuable.  The existing code base is field proven, generating revenue, and shipping.  Even if Omega holds promise, it’s worth our time to keep Alpha selling.  It may slow down Omega, but it ultimately gives the company more time to get Omega right.

Let’s take the Tippy Tower concept a farther.  I argue that Alpha and Omega should be designed to co-exist.  For example, Omega’s new web interface could be displayed on a form in Alpha’s UI.   It may take some time to enable a browser in Alpha, but Alpha users would have immediate access to Omega’s new capability.  In this case, we’ve done work that helps create Omega and also added uplift to our shipping product.

In an ideal Tippy Tower case, those legacy Alpha features just stay in the Alpha code base and die a natural death because Omega replaced them with a better paradigm. The fact that we keep Alpha from tipping over kept us from having to port them and kept us from creating more rushed crapware.

One last note: sales people love this approach – they always have something to sell and customers to reference.