The question skips some details. Are the clones used for a specific reasons in completely disconnected teams, or have mixed have purposes in the same area? Do they all use the same source of truth or do they replicate data/accounts? Is it because of 2 separate groups not communicating, or a failed/incomplete migration?
There are many reasons you may end up with 2 software packages with similar responsibilities. It's not always good or bad. All things being equal, using the same software everywhere means everyone if familiar with the same interface, potentially lower costs, easier automation. But things are rarely equal ;)
I'd say: know the reason why you have clones to begin with and not a common solution. And maybe check it from time to time, in case the restriction is not relevant anymore.
By clones I meant - software solutions which are trying to solve minor variations of the same problem. They sit in separate code repositories, they have different sources of truth for data, etc.,
Clones are never a good thing, labeling them as okay just breeds complacency making the enterprise more enterprisey. It should be labeled what it is, a pile of tech debt. I'd almost list them as one of the greatest evils, because you need to maintain two separate systems dedicating engineering resources maintaining yet another system. The upfront cost of consolidating the systems will pay dividends in the future.
Understanding the level of effort to deprecate some of the clones you'll encounter it's reasonable to suggest that you're going to have to tolerate them but I would strive to look for opportunities to consolidate the clones.
Thanks! This is something we are trying but because of the complexities with the legacy, it is getting hard and expensive. Often, they get pushed down the priority list.
"Clones" are okay when one is the current standard that is used by most of the organization and any others are experiments (possibly in production) for possible future directions of standardization with a clear picture to why you are exploring the alternative, a clear process for evaluating the alternative, and a plan to retire the alternative and put the function back on the standard if the alternative is rejected.
Or if its a separate org that was merged in and hasn't moved on to the standard yet -- and either has a plan to transition or is in the planning process.
Otherwise, no, generally not.
(There are "false clones" that serve the same purpose on a high level description but have clearly delineated different functional roles in the organization -- beyond just "this unit uses X" and "this unit uses Y", but actual different concrete needs that are served, despite being in the same general product category. This can be acceptable with each being standard in its niche, but those niches need to be defined so that the use within the organization doesn't get blurred and you end up with real clones.)
9 comments
[ 2.8 ms ] story [ 29.6 ms ] threadThere are many reasons you may end up with 2 software packages with similar responsibilities. It's not always good or bad. All things being equal, using the same software everywhere means everyone if familiar with the same interface, potentially lower costs, easier automation. But things are rarely equal ;)
I'd say: know the reason why you have clones to begin with and not a common solution. And maybe check it from time to time, in case the restriction is not relevant anymore.
Understanding the level of effort to deprecate some of the clones you'll encounter it's reasonable to suggest that you're going to have to tolerate them but I would strive to look for opportunities to consolidate the clones.
Or if its a separate org that was merged in and hasn't moved on to the standard yet -- and either has a plan to transition or is in the planning process.
Otherwise, no, generally not.
(There are "false clones" that serve the same purpose on a high level description but have clearly delineated different functional roles in the organization -- beyond just "this unit uses X" and "this unit uses Y", but actual different concrete needs that are served, despite being in the same general product category. This can be acceptable with each being standard in its niche, but those niches need to be defined so that the use within the organization doesn't get blurred and you end up with real clones.)