Telecom and IT consulting · Strategy · Operating resilience
A second supplier is not an independent recovery path. Test the dependency before approving the investment.
Arcus helps telecom, software and IT-service leaders connect growth strategy, operating responsibilities, customer commitments and investment choices. We examine whether the proposed operating model can deliver the service—and adapt when a critical dependency changes.
The decision before the programme
01 / Which customer service must continue, and at what minimum level?
02 / Could the response team operate if the primary service failed?
03 / Does an alternative support immediate recovery, a future exit, or neither?
What decision should telecom and IT leaders make?
A leadership team may be asked to add a provider, move workloads, automate delivery or consolidate infrastructure. These choices can improve economics or capability, but the number of contracts is an incomplete measure of resilience. The relevant question is which failures the operating model can withstand and what the organization can actually do when they occur.
Arcus’s central thesis is to assess independence by failure scenario and response task. A second platform can still depend on the same identity service, connectivity, data pipeline or scarce specialist. Conversely, a concentrated platform may be a defensible choice for a less critical service if its limitations are understood, proportionate controls exist and leadership accepts the exposure.
Separate two decisions. Incident recovery concerns maintaining or restoring an acceptable service under disruption. Strategic exit concerns transferring a workload or service when commercial, capability or risk conditions change. An exit plan taking months does not establish recovery within hours; an emergency workaround does not establish a sustainable replacement operating model.
Four explanations for weak service performance
Use evidence to identify the cause before buying another platform or prescribing automation.
01 / The commercial promise exceeds operating capability
Sales terms, launch dates or service expectations may exceed realistic delivery capacity. Compare customer commitments with observed workload, support coverage and exception handling. A technical upgrade cannot by itself resolve an unachievable service promise.
02 / Several services share a hidden failure point
Nominally separate suppliers may depend on shared access, connectivity, data or operating tools. Trace the proposed failure scenario across those dependencies. Technical specialists should establish the actual architecture rather than infer independence from different brand names.
03 / The organization cannot execute the response
Tools may be available while authority, contact paths, specialist access or practiced procedures are missing. Review incident records and exercise observations. Distinguish lack of redundancy from an alternative that exists but cannot be activated safely.
04 / Economics or incentives encourage excessive concentration
Discounts, delivery targets and scarce skills may favour one platform or rapid change. Compare total operating and transition requirements, not only the visible subscription bill. Identify who gains from consolidation and who carries customer disruption or exit costs.
What documented evidence changes the analysis
The CRTC-published Xona assessment of the July 2022 Rogers outage, full report published in 2024 documents how a common IP core affected wireless and wireline services. It also describes loss of remote management access and impaired staff communication during recovery. The assessment identifies shortcomings in risk classification and simultaneous changes, alongside architectural trade-offs. This is one documented incident, partly redacted and substantially based on Rogers-provided information; it is not evidence that all converged networks or current Rogers services have the same weaknesses.
The UK Competition and Markets Authority’s 16 October 2026 Update on cloud actions reports steps by Amazon and Microsoft to reduce switching and multi-cloud barriers, while identifying further work, including identity/access management and container portability. This is a UK competition assessment, not a Canadian compliance requirement or a guarantee that an individual workload can switch economically. Current contracts, service design and customer-specific constraints still need examination.
Arcus’s management inference is that architecture, organizational execution and commercial portability need separate evidence. The diagnostic below is our original analytical synthesis, not original empirical research, an engineering certification or a validated risk score.
The Arcus dependency-to-commitment test
Apply these four tests to one proposed service, platform or supplier commitment.
01 / Failure boundary → what stops together?
Name the customer-facing service, minimum acceptable delivery and scenario. Map connectivity, hosting, identity, data, key suppliers and operational tools. State which dependencies remain shared and which independence assumptions require specialist verification.
02 / Recovery control → can people act?
Identify who declares an incident, approves a change, contacts suppliers and restores or suspends service. Test communications, privileged access, usable records and rollback arrangements under the assumed failure. A written procedure needs evidence that it can be executed.
03 / Transferability → can the service move?
Define the workload and data to transfer, necessary permissions, formats, interfaces, licensing and customer obligations. Distinguish an emergency fallback from a strategic migration. Confirm realistic elapsed time, specialist effort and constraints with the relevant experts.
04 / Retained capacity → can the organization sustain the choice?
Specify internal service ownership, supplier management, monitoring, support skills and recurring exercises. Compare dual operation and transition demands with available capacity. Record approval conditions, unresolved evidence and the next review trigger.
Worked diagnostic: two clouds, one route to recovery
Consider a fictional software business proposing a second cloud for a critical customer service. Its proposal names two providers, but the response team relies on one identity service for administration and one communication channel for incident coordination. The secondary environment has not been exercised against failure of those shared dependencies.
The diagnostic does not conclude that the second cloud is useless or that the identity service will fail. It identifies the unanswered decision: can authorized staff access, coordinate and recover the minimum service under the specified scenario? A demonstration that both platforms run normally is different evidence from an exercise in which the primary access or communication dependency is unavailable.
Compare targeted changes to management access and incident communication, a limited alternate service, broader platform diversification, and a deliberately accepted interruption for a lower-priority workload. Have qualified technical and security specialists evaluate the designs. Leadership should assess the residual customer impact, operating burden and affordability before choosing.
An orderly exit is a different work package: data transfer, application adaptation, licenses, customer acceptance, training and retirement of the former environment. Its effort can be material even when emergency recovery works. This example is illustrative; it makes no claim about an Arcus client, a named provider’s architecture or the frequency of such failures.
Compare realistic operating alternatives
Select the response that addresses the evidenced failure mechanism.
Strengthen the existing operating model
Appropriate when change control, role clarity, access or incident execution explains the gap. Can avoid unnecessary platform complexity, but cannot remove a fundamental shared technical dependency. Obtain evidence that the changed process works under the relevant conditions.
Add targeted independent capability
An alternate communication route, management-access arrangement or limited fallback may address a specific scenario. Check capacity, security, data currency and activation authority. A narrowly scoped capability should not be presented as complete business continuity.
Diversify platforms or service providers
May reduce selected dependencies or support different capabilities. Adds integration, skills, monitoring and coordination requirements; shared control services can remain. Make the intended protection explicit and verify the full service path.
Consolidate with explicit conditions
May simplify operations and improve commercial leverage where concentration is acceptable. Define customer consequences, risk acceptance, contract review, exit readiness and review triggers. Lower nominal cost is not evidence that the accepted interruption is tolerable.
How should leaders assess cost and implementation?
Compare investment and migration effort with recurring operation. Include adaptation of applications and data, supplier and specialist support, security and access design, training, parallel running, testing, monitoring and eventual retirement. Review minimum commitments and transfer terms in the actual contracts rather than assume a generally advertised policy applies. Avoid invented outage probabilities or unsupported savings estimates.
Assign an executive service owner to set the business requirement. Operations and engineering validate dependencies and feasible recovery; security assesses access and controls; procurement and legal review commercial and contractual constraints; finance tests affordability; customer teams clarify delivery commitments. Responsibilities should survive an incident, not depend on informal knowledge held by one person.
Begin with a small number of consequential services and explicit scenarios. Map dependencies, review incident and change evidence, compare alternatives and agree the unresolved tests. Run authorized, safely scoped exercises with the appropriate specialists before relying on a new arrangement. Use observations to revise the design, decision rights and procedures.
Measure whether the minimum service was actually delivered, how long recovery took, which access or coordination steps failed and what actions remain unclosed. Record exercise conditions and exclusions: success in one scenario does not establish resilience against every failure. Reassess when services, supplier terms, architecture or key staffing change.
For growth or new offerings, connect these findings to the business case. Service promises, support staffing and investment sequencing should fit what the delivery model can sustain. Customer research and commercial positioning remain essential; resilience work alone does not establish market demand or profitable growth.
How Arcus can help leadership decide and act
A management engagement connects the business decision with specialist evidence and accountable implementation.
01 / Diagnose → decision and dependency brief
Clarify the service or growth decision, review documents and interviews, and map organizational responsibilities and decision-critical dependencies. Identify evidence gaps for technical, security, financial or legal validation.
02 / Evaluate → operating and sourcing options
Compare realistic configurations, commercial implications, recurring cost drivers and transition requirements. Deliver an options paper that separates supported findings, assumptions and unresolved risks.
03 / Design → governance and operating model
Develop service ownership, decision rights, supplier-management processes, capability requirements and an implementation roadmap. Agree evidence gates before major commitments or retirement of existing capability.
04 / Implement and measure → management follow-through
Support leadership alignment, organizational change and review of agreed actions. Deliver an action register, escalation responsibilities and meaningful measures. Specialist engineering, penetration testing and regulatory opinions require separately scoped qualified expertise.
Discuss your telecom or IT consulting priorities
Tell Arcus which service, growth initiative or supplier commitment is under review, the next decision date and the main uncertainty. We can discuss strategy, research, organizational design, operational improvement or implementation support. A general description is sufficient for an initial inquiry; avoid sending credentials or sensitive technical records.
Related support includes strategy planning, market research, operations improvement, transformational change and human resources consulting.
Existing related resources
These retained resources provide additional topics for consideration; their inclusion does not establish the results of the operating choices discussed above.