[HN Gopher] Ask HN: Integrate Software Solution with Competitor's?
___________________________________________________________________
Ask HN: Integrate Software Solution with Competitor's?
I'm involved in a merger between two competing organisations. We're
in the same market segment, but our software solutions
differentiate themselves slightly differently. 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?
Author : temp088773
Score : 25 points
Date : 2021-11-28 08:46 UTC (2 days ago)
| twohey wrote:
| I have experience doing this and am happy to talk offline as this
| is a complicated situation - just shoot me an email and I'll make
| time.
|
| 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.
| tacostakohashi wrote:
| The way I have seen this done in mergers I have been involved in
| is quite gradual. First, do some quick "day one" changes, where
| you change branding, and make the systems interoperable to some
| degree in terms of logins, file formats, terminology,
| import/export to each other, etc.
|
| 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.
| tyingq wrote:
| Personally, I'd stall a bit and see which of the two products
| starts to the win the politics war. In these kinds of mergers,
| it's typical for areas like sales or support to merge together
| before the software developers. That's when it usually becomes
| more clear which product is going to win out.
|
| 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".
| user5994461 wrote:
| I am gonna join this opinion.
|
| It's quite likely that one of the products takes over. Maybe
| one product had more traction with customers, or maybe one
| product is losing customers. Maybe the entire sales or
| development team will leave within a year, leaving one product
| in shambles. It's quite possible that one organization will be
| torn apart, who knows the terms of the acquisition.
| Closi wrote:
| Sometimes two products are there to stay - just ask
| BlueYonder, SAP, Korber or plenty of other large enterprise
| software vendors which end up with two products (be it
| merchandising systems, ERPs or WMS products they have ended
| up with via acquisition).
| tyingq wrote:
| That's true, though more often the case with products that
| have a lot of overlap, versus really being competitors in
| the same market. Perhaps Trello is a good example. It
| overlaps with Jira, but it doesn't really compete for the
| exact same customers in an either/or decision.
|
| It's hard to find a good example where a merger of two
| products with very similar markets where both products
| thrived after the merger.
| gerardnico wrote:
| Check change management. This is a complete field that goes way
| over just software integration.
|
| 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.
| bob1029 wrote:
| Right now, it seems your biggest struggle is with the number of
| competing ideas and priorities. You may need to invoke a series
| of developer honor duels and whittle it down to one chef in this
| kitchen if you want to survive.
|
| 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.
| pkrotich wrote:
| If I was in your position - I would push for integration of some
| sort while keeping the two products separate for now. Then have a
| separate team from both organizations start on a new product that
| borrows from both products. Obviously it's easier said than done
| - ego have to be put to the side.
|
| The advantage is you keep the status quo with minimal customer
| and cash flow distraction while working on integrated solution.
| ssss11 wrote:
| There needs to be a transition project headed up by influential
| leaders, and they need to set out the synergy goals - things like
| what important services or features are key, which side will lead
| important aspects in the future etc...
|
| 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.
| temp088773 wrote:
| Thank you for your thoughts. I fully agree that it's critical
| to set up the relevant business targets for the integration,
| both short term and long term ones.
|
| Do you really think a large and important project like this can
| be efficiently planned in detail ahead of time? And that the
| people who are not "on the floor" are the people with the
| insight to be able to pull that off?
| ssss11 wrote:
| It depends on the context I think - big or small company,
| personalities at the top, internal politics...
|
| In the planning there definitely does need to be someone with
| the technical understanding on both sides giving input
| though. An architect or CIO or something.
| tconfrey wrote:
| Completely agree on the points here about organizational buy-in,
| apis, pros/cons of gradual convergence etc. I'd add UX into the
| mix. If these products have user-facing UIs they probably employ
| different metaphors, cater to different user persona's etc.
| Figuring out how (or if) to migrate users of A and users of B to
| C is part of the problem space.
| a-priori wrote:
| First step: Do nothing. You've got two working, independent
| products, and that's okay. You can keep running like this
| indefinitely so there's no need to rush.
|
| 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.
| Jugurtha wrote:
| Some of our earliest design decisions were:
|
| - 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.
| 0des wrote:
| > - 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'm going to have to owe you a beer on this one. These are all
| very good points that I wish more services would take to heart.
| Jugurtha wrote:
| > _I 'm going to have to owe you a beer on this one. These
| are all very good points that I wish more services would take
| to heart._
|
| I know, right ! End of service notice email you didn't read
| that gave you a couple of days to think about and exfil years
| of work with no way to automate the thing ? Fuck that. Our
| users train models on data? Don't upload anything to us.
| We'll mount your S3 buckets like a filesystem.
|
| Your company already has a billing account on GCP, AWS,
| Azure, or DigitalOcean ? We'll just link to your cluster. You
| don't need to budget for new compute or talk about security
| policies.
|
| PS: I'm having a beer as I'm typing this. I'll drink it as if
| it were the one you offered. Thank you! It's delicious. Next
| few on me.
| Closi wrote:
| Don't assume that they will ever be a single product - but do
| assume that they will move closer together.
|
| 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.
| polote wrote:
| Don't keep two similar solution working at the same time. Keep
| the one that has the better foundation, implement the most
| important feature of the second platform and migrate over all
| customers, kill the other one. If you don't do that, you will
| have to do it in a few years and you will have lost all those
| years.
|
| 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
| [deleted]
| pram wrote:
| If they're smart, they'll kill one of them. Unfortunately if
| you're on that dev team you've just become an outsider. Start
| brushing up your resume because you won't have any clout or
| credibility with the "winning" team. They will absolutely circle
| the wagons, I've been there twice in my career.
| codingdave wrote:
| I've been working on exactly that for the last 2 years. It has
| not gone well. I can't get into detail because it is all internal
| info, but I can give generic advice:
|
| - 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.
___________________________________________________________________
(page generated 2021-11-30 23:01 UTC)