It takes courage to re-architect a complex product

It’s funny how many people present their “I/we re-architected our product” story from a nuts and bolts, facts and figures point of view. I am always struck by how much courage, planning and foresight is required to successfully re-architect a complex product. I guess we mostly hear about the successful re-architecture projects. I would venture a guess that there are many, many more failures than there are successes.

This is definitely the case for Wes Rosenberg, CTO at Levels Beyond as they took on re-architecting their REACH ENGINE media orchestration platform. He describes the challenges, objectives and architectural outcome in great detail in his Couchbase CONNECT presentation, “Orchestrating Bricks from Mud — Increasing Scalability and Reliability at Reach Engine”. What makes it an interesting story is that Reach Engine is a complex platform with a large, well established customer base full of marquee customers. They needed to re-architect the product, but they had to do it in a way that wasn’t disruptive to their existing users.

But why re-architect in the first place? If it ain’t broke, why fix it, right? In a nutshell, 10+ years of platform development, with extensive customer-specific features and extensions had left them with an unmaintainable application wrapped in a “big ball of mud” architecture. A trivial problem to fix, right? Wrong!

So, once they realized this, they picked a bunch of emerging technologies on which to base the new architecture, went off and started coding, right? Wrong, again! They spent time coming up with an approach that met both the business requirements and set out the technology objectives of the re-architecture project. With that in hand, they were able to identify where they could start to break up the “big ball of mud” into functional components (a.k.a. microservices). Conceptually, their new architecture started to look much more like this.

Now, the goal was to make this new architecture work for their existing customers, as well as serve as a framework for new innovations and customer extensions in the future. Rather than throw the baby out with the bath water, they incorporated what they already had today with their platform for the future. This allowed them to avoid major disruptions to their existing customer base, while laying the foundation for the future at the same time.

Did this happen by luck? No, it happened through courage, planning and execution. It’s easy to see how this project might have failed. But it’s very exciting to see and hear how this re-architecture solved major business/technical problems, made their customers much happier, and paved the way for new, faster, more reliable innovation for the company. Everybody wins, and I tip my virtual hat in admiration for what they accomplished.

For more detail on this transformation, please see Wes’s presentation here.