Rearchitecting Following an Acquisition Doesn’t Start Where You Think
By: Rafi Schwarz
Tags: Redesign, Aquisition, Software Architecture, Business Analysis

Merging separate software products into one is a challenging task. Each product comes with its own functionality, terminology and technology stack. So why do it? The reasons can vary of course. Your company’s business might need a shift in direction, the technology domain of your business might have gone through a disruption, or it could result from your company acquiring another.

With one product I work on, we recently reached the realization that we wanted to change our architecture and further simplify it for our users. The way we wanted to achieve this is by merging its independent platform into the company’s main suite of products, thereby creating a much tighter and seamless integration.

In this blog, I will share this process and my role in it, as lead architect.

Defining Our Goals

The main motivation for our new architecture is wanting to create a simpler more holistic user experience across our company’s products. Our product was capable of running as a standalone, without being part of the full suite ecosystem, but that capability wasn’t preferred by most of our customers. Through this paradigm change, we wanted to simplify the user experience, by simplifying our product and making it easier and more productive to use.

Let’s take a look at how we started approaching this.

Collecting Knowledge and Defining Our Assumptions

First of all, we got excited! It’s an interesting part of a product’s lifecycle.

We knew why we wanted to make this change, we knew what we wanted to achieve, so then it came down to the hard part of deciding how we were going to execute it.

To my surprise, understanding the “how” required me to do much more than building an architecture, designing the components, and writing code. I needed to work closely with my product managers, product owners, the product R&D managers, and the teams software architects.

First we reevaluated our product and tried to answer these questions:

What is the added value we provide to our users? How do we think our users use our product?

The first question helped us to identify the functional capabilities that are most important to our users. For example, a strong authentication of applications in Kubernetes is an important functional capability of our product. On the other hand, auto failover, while being an important feature, is just an implementation detail. The user has a non-functional requirement of high availability but doesn’t really care how it’s achieved.

The second question helped us to organize and prepare our assumptions about how the product is being used. We wanted to validate which features are most important to the majority of our users, so we would be able to focus on them at the start, and bring maximum value immediately. In addition, we reevaluated the different personas that use our product, and analyzed their workflows.

In our case, our main personas are developers, DevOps engineers/site reliability engineers (SREs), and security administrators. Each persona has different expectations in terms of functionality and user experience. This approach made us think about all the aspects of the product, from installation to configuration, ongoing management, using the product in development, test, and production.

Validating Our Assumptions

Lead by the product manager and product owner, we defined the main use cases that the product must support. Once we had this, we were able to move to the next step of validation.

To validate our assumptions, we talked with our sales engineers, professional services, and of course, our customers. Each gave a very different angle: sales engineers focused on features that would help sell the product. Professional services focused on simplicity, availability and maintainability of the product. Most importantly, the customers are the ones the product is for, so any information we got from them was priceless.

Reducing Risk, Creating Clarity

In parallel to this validation process, I was working on developing an initial prototype of the new product. The goal of this prototype was to create, as fast as possible, a piece of software that implemented an end to end flow. This is done in order to flush out any technical concerns and to reduce risks. The code doesn’t have to be polished. Actually, if it helps for a faster delivery, it’s legitimate to throw this code away later and not use any of it in the actual product.

In my case, our new product would use the company’s main suite as its backend. To save time, I used the existing APIs and reused existing entities that the backend suite already supported, even though I knew that for our actual future product, we’d develop new, dedicated APIs and entities. This allowed me to focus more on the business logic of my product (instead of the backend suite that is owned by a different group) and reach a working end-to-end faster.

This task really proved itself useful. In about two weeks of work, this prototype surfaced about 14 insights. For example, I realized that our current product relies on a few manual steps, when bootstrapping it for the first time. While this approach works well for our existing workflow, the new workflow will need to have this process automated and simplified. The fact that I had to reach a working end-to-end, “forced” me to encounter this limitation, be aware of it, and consider it when building a plan and designing the future solution.

Defining a Scope and Creating a Plan

After we analyzed the technical gaps and collected all the information we could, we sat down to create a scoped plan. When creating a plan, it’s very important to keep it lean. We want to build a lean end-to-end and constantly expand the functionality of our product. As soon as an end-to-end exists, we can share it either internally with our field, or externally with select customers, to get feedback. This feedback helps us to refocus, adjust and align towards a better outcome. This way we create a constant feedback loop: plan, build, ship, collect feedback, adjust and start again from the top.

Merging products is not easy and requires a lot of planning to get right. For us, this included: 1. defining our goals 2. collecting and organizing our knowledge and assumptions 3. validating our assumptions with other roles 4. allowing us to reduce uncertainty and risks 5. creating an actionable plan that involved validation points throughout the process.

Now the next step on my to do list is the most fun part of all: building the architecture and starting to code. I will share more about that part of the process in my next post.