Bring external dependencies into DCAR
Owner: @jamesmockett
1. Direct impact on consolidation
Does this directly bring us closer to decommissioning duplicate platforms?
- Which legacy template/component does this help remove and how?
- Which migration milestone does it unblock?
Assessment: This doesn't directly bring us closer to decommissioning duplicate platforms
2. Reduces time, risk or cost of decommissioning
Does this meaningfully reduce the time, risk or cost of safe decommissioning?
- What aspect of the migration becomes faster or safer?
- Can we say roughly by how much?
- What evidence supports this?
Assessment: This probably does not have much impact on reducing the time, risk or cost of safe decommissioning. It may help in cases where the migration benefits from a new feature or functionality in one of the core shared libraries as we're currently blocked on updating these due to being unable to update braze-components, one of the external dependencies we could bring into DCAR.
3. Mitigates material user-facing, security or operational risk
Material = user-facing errors/downtime, security exposure, reputational risk, significant operational challenges etc.
- What specific risk does this work mitigate?
- What's the likelihood and impact if the risk materialised?
- What happens if we don't address this in Q1?
Assessment: This has a direct benefit in mitigating security vulnerabilities as we've already faced a situation where there was a critical vulnerability in support-dotcom-components, one of our external dependencies. In this case we were able to update the vulnerability without needing a new version of the package, but for future vulnerabilities this may not be the case. We've already seen with braze-component that it's not necessarily a simple process to get a new version of these external packages published so that they can be consumed by DCAR. If they were part of the same codebase then it becomes a much simpler task to keep dependencies updated. This is how things have been for all of DCARs existence so it doesn't feel critical to address it in Q1.
4. Estimated effort
Input what's currently known
- Size: 1 person for 1 sprint
- Key dependencies: Supporter Revenue and Commercial teams
- Unknowns to consider:
braze-components may be decommissioned in which case there's no need to move it. There may be downsides to relocating these dependencies such as making it more difficult for the teams that maintain them, and the risk of accidental breakage due to the WebX team being unfamiliar with them and not necessarily knowing if an update has caused an issue.
Recommendation
Based on the above, should this work be categorised as:
Rationale: Whilst this would be a nice to have, there are no immediate issues caused by leaving things as is. (Assuming the braze-components publishing issue is resolved.) Maël has also told me that they're currently working on using out of the box Braze functionality for banners and epics which means they may eventually retire braze-components completely. There's little point in us planning to relocate this if it may be removed. They hope to have a better idea if this is possible next week. We could, however, do some further investigation into the feasibility of moving support-dotcom-components and commercial-core.
Bring external dependencies into DCAR
Owner: @jamesmockett
1. Direct impact on consolidation
Does this directly bring us closer to decommissioning duplicate platforms?
Assessment: This doesn't directly bring us closer to decommissioning duplicate platforms
2. Reduces time, risk or cost of decommissioning
Does this meaningfully reduce the time, risk or cost of safe decommissioning?
Assessment: This probably does not have much impact on reducing the time, risk or cost of safe decommissioning. It may help in cases where the migration benefits from a new feature or functionality in one of the core shared libraries as we're currently blocked on updating these due to being unable to update
braze-components, one of the external dependencies we could bring into DCAR.3. Mitigates material user-facing, security or operational risk
Assessment: This has a direct benefit in mitigating security vulnerabilities as we've already faced a situation where there was a critical vulnerability in
support-dotcom-components, one of our external dependencies. In this case we were able to update the vulnerability without needing a new version of the package, but for future vulnerabilities this may not be the case. We've already seen withbraze-componentthat it's not necessarily a simple process to get a new version of these external packages published so that they can be consumed by DCAR. If they were part of the same codebase then it becomes a much simpler task to keep dependencies updated. This is how things have been for all of DCARs existence so it doesn't feel critical to address it in Q1.4. Estimated effort
Input what's currently known
braze-componentsmay be decommissioned in which case there's no need to move it. There may be downsides to relocating these dependencies such as making it more difficult for the teams that maintain them, and the risk of accidental breakage due to the WebX team being unfamiliar with them and not necessarily knowing if an update has caused an issue.Recommendation
Based on the above, should this work be categorised as:
Rationale: Whilst this would be a nice to have, there are no immediate issues caused by leaving things as is. (Assuming the
braze-componentspublishing issue is resolved.) Maël has also told me that they're currently working on using out of the box Braze functionality for banners and epics which means they may eventually retirebraze-componentscompletely. There's little point in us planning to relocate this if it may be removed. They hope to have a better idea if this is possible next week. We could, however, do some further investigation into the feasibility of movingsupport-dotcom-componentsandcommercial-core.