The stakeholders are obviously interested in seeing an integrated software solution that provides the strengths of the two existing solutions in one service.
Obviously, there are technical challenges with this: the two existing solutions use extremely different tech stacks, where neither of which is appropriate for "plugging in" the other one. The technical people involved also want to take the opportunity to fix some long-standing scalability problems when it seems like they have to restructure the top-level architecture anyway.
But I'm more concerned with organisational problems. I feel like most of these integrations easily turn out wrong or inferior to either original service.
Do you have experience with this type of work? What did you learn? What would you suggest?
- Everything one could do with point and click must be possible with an API call. A developer should build a clone using the API. Developers should be able to build products on top of this or use it as a subsystem in their systems.
- Build on top of common abstractions and units of 'thought'. Docker, S3, HTTP, JSON, etc.
- The platform must be able to die without users left scrambling to exfiltrate their work (based on my personal motto of being able to die without the team being impacted beyond nostalgia).
I can't say whether integrating your two products would give a pizza+ketchup, but if you are going that way, having APIs on both products could result in at least one prototype of a new product leveraging both without being entangled in anyone's implementation or limitation. Then slowly removing the scaffolding and replacing each API call with functionality from the new product and shutting down the functionality in the original product until none of the calls go to any of the two originals.
That is one way to do it with pros and cons. The pros are that you're not bastardizing anything or trying to fit a square peg into a round hole. One other advantage is that you get a first proof of concept that has the valuable functionality of both. Cons would be that the new code isn't battle tested and lacks the scar tissue. Like any rewrite, pros and cons.
Both of your teams are one team now. This is your new product. Both must be willing to kill/retire their own product or each team will try to make theirs survive.
1. One of these products/services is going to die. The people who were making the dead product/service will know it pretty soon, and while a few of them will find niches in the new organization, many of them are going to hang around precisely as long as it takes financial incentives to mature.
2. Some of the customers who chose the loser will come over. All of them looked at the market and decided that there were good reasons for making that decision. If there's a third strong contender in the market, this is good news for them.
3. If you can craft a painless migration from the loser to the winner, many many many more customers will stay.
4. If you can identify the features in the loser that were attractive, and promise a realistic timeline to get those features in the winner, many more customers will stay.
5. In a few months to years, someone is going to push to re-do the whole enchilada with an architecture which is both trendy and can be sold as "best of both worlds". Unless they have an amazingly solid track record of leading projects on that scale, this will fail.
If it's clear, for example, that your product is going to win out, then working on "import from other product" is higher priority than "export to other product".
- Define your new solution first, worry about the tech later - the effort to make the tech work is worth it if you get the solution right. If your solutions came at problem from different angles, choose the angle you want to take based on what the customers need, not what the tech makes easy.
- Be willing to throw away old tech - re-use of legacy apps often brings legacy baggage. At the same time, don't re-write just because you can. Take each decision of re-use vs. re-write extremely seriously.
- Sadly, same advice for the people. My project struggled more with personnel concerns than tech concerns. Make sure everyone who works on the new product is not tied to the old work - not technically, emotionally or via their ego. Re-tool the team in terms of culture and skill up to whatever stack you want for the new product. Make that happen early - in the long run, getting the team right will make the difference.
- Merging two products is harder than writing either one in the first place, so be sure your leadership has accurate expectations of what this will really take.
Second step: Figure out what the future combined product/company is going to look like. There's no sense doing any integration work until you know where you're going.
Third step: Form a combined team and come up with a plan to build the new product, reusing and rewriting the existing technology as appropriate. The details here entirely depend on the existing products and the end goal.
Keep in mind this situation can easily become political and toxic -- in fact, I would say that's the default outcome -- and will require strong leadership to navigate well.
Then, gradually make changes to each system over time towards a common direction, and either they'll end up similar enough that you can pull the plug on one and nobody will notice, or they'll become two different offerings in the same family. Think of Windows 96/98/ME + NT 4, XP, etc - make them look and feel similar, different implementations that co-exist for a while.
Refrain from trying to make the long term decisions and planning on day one, and just see what happens with the market, personnel, etc.
The advantage is you keep the status quo with minimal customer and cash flow distraction while working on integrated solution.
Having 1 technical leader who can fight consistent and honest battles with the business makes things a lot easier in my experience. When it's 1 room of 10 people vs another room of 15 people, you aren't going to move anywhere. And if you do end up somewhere, it almost certainly won't be ideal.
My initial take was to say both codebases are now legacy, and both teams need to select a final tech stack for the rewrite. Without seeing the business and technology, that would be quite presumptive depending on priorities and market dynamics. That said, a clean start can sometimes be the fastest and easiest path if everyone is still fresh on the current codebases.
Personally I can't offer too much advice, after a year or so of stalling I learned to polish my resume and move elsewhere.
There were endless top-down driven discussions, initially about how to merge to the favoured child, then about a "new platform" to encompass everything (but with an unrealistic scope and timetable).
It was clear that either this thing would never be built or would not achieve the level of integration desired. It was also clear it was only the board level who actually wanted this to happen, everyone on the workshop floor so to speak knew it wasn't what customers wanted or really a good fit.
So I got out.
Start with the vision of the company, which one is better suited to go to that vision ? Ignore all the details. I know it is hard, but that's a complex situation and it needs strong decision and leadership
Without a clear plan and good communications down to the lowest levels from above there are a number of ways chaos can ensue… not just technical differences but as you say org and people issues mainly.
Once the commercials are agreed someone needs to take the reigns on the transition aspects ASAP.
The principal is that every human being is active and has a voice in the future architecture (based on spec).
Architecture is easy. Getting everyone on board is not. Luckily, it seems that human being are smarter together.
If you miss that, intern conflicts, architecture rejections will bring you integration project to a big failure.
Team / product competition is way easier to manage and is may be also the way to keep a bigger market share.
Work out what that first task is - often the best place to start is the UX rather than the back end (as the UX may be easier to merge onto a single platform/codebase), and then you can have the two products having a similar 'look and feel'.
Then you can start looking at other bits to merge - for instance can you use the same database engine, languages, coding styles?
But the most important bit - don't go rewriting it all Big Bang otherwise you will just get yourself in a rut.
The part that will be the most difficult to change is the business logic - if the two products fundamentally have different processes it is very difficult to merge them together (from a customer perspective). A decision early on is required to know if they will fundamentally be two separate products, or if they will kill one and it will become one product, but you can't have one product with two different ways of doing the same thing for every feature.
You will need to create organizational accountability for the integration and define what success looks like and how it will be measured. You will also want to avoid an "us vs them" situation inside the two companies.
There are a ton of subtleties in how to do that above that vary with organizational dynamics, but you must ensure that at a senior level you have alignment from both organizations or there will be a lot of shared misery.
If you have the opportunity always tackle technical debt.