3 ms·
Poll: In an enterprise, are software clones okay?
These clones are due to legacy or acquisitions etc.,
For Eg: We have multiple content management systems in our enterprise.
- the_arun 10y agoHow do you guys manage clones in your enterprise?
- jstanley 10y agoWhat do you mean by "clones"?
- the_arun 10y agoDuplicate applications built to solve same problem. As I gave in the example above. Multiple CMS solutions for managing content.
- viraptor 10y agoThe 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.
- the_arun 10y agoBy 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.,
- vincagi 10y agoClones 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.
- the_arun 10y agoThanks! 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.
- dragonwriter 10y ago"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.)
- the_arun 10y agoBy clones I meant multiple applications doing similar functionality running in Production managed by different teams, code and data.