Buying software from different companies does not necessarily give your business independent systems. This week, we recommend looking beyond the names on your software invoices and asking a more useful question: what do those services depend on?
The October 20 Google Cloud disruption in London offers a concrete reason to investigate. Google’s preliminary incident report describes a power-related outage affecting its europe-west2 region, with a reported incident duration of six hours and ten minutes. Source: Google Cloud Service Health. ([status.cloud.google.com](https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj?trk=article-ssr-frontend-pulse_little-text-block&utm_source=openai))
This is not a recommendation to abandon cloud services. It is a recommendation to make purchasing and operational decisions with a clearer picture of shared dependencies.
What the incident revealed
Google reported that the physical power outage was isolated to one availability zone, europe-west2-b. However, some customers using other zones or regional architectures also experienced unexpected effects. Source: Google Cloud Service Health. ([status.cloud.google.com](https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj?trk=article-ssr-frontend-pulse_little-text-block&utm_source=openai))
Its recovery work included moving regional service routing away from affected infrastructure and progressively restoring services. In other words, this was more complicated than simply switching the power back on. Source: Google Cloud Service Health. ([status.cloud.google.com](https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj?trk=article-ssr-frontend-pulse_little-text-block&utm_source=openai))
The impact also appeared in other vendors’ customer updates. CRM provider Beacon reported errors affecting functions including exports and suggested duplicates, then identified the wider Google infrastructure issue as the cause. Source: Beacon Status. ([status.beaconcrm.org](https://status.beaconcrm.org/?utm_source=openai))
Later, Beacon reported that its systems were returning and that it was checking whether remedial actions were required. That distinction matters: a supplier’s recovery announcement and confirmation that your own workflow works are separate checkpoints. Source: Beacon Status. ([status.beaconcrm.org](https://status.beaconcrm.org/?utm_source=openai))
Start with work, not a software inventory
For your next management meeting, choose three activities that would cause immediate disruption if unavailable. Consider accepting orders, scheduling field staff, processing payments or accessing customer records.
For each activity, ask your IT team to document the applications involved, the person responsible for each supplier relationship and any known underlying hosting dependencies. Include sign-in services and connections between applications, not just the main software product.
Keep the first version simple. A one-page diagram with a few unanswered questions is a better starting point than postponing the exercise until someone can produce a perfect technical inventory.
Look specifically for places where apparently separate workflows share a dependency. Treat those as questions to investigate, rather than assuming they represent an unacceptable risk.
Ask suppliers for evidence, not reassuring labels
At your next renewal or purchasing discussion, ask what the supplier means by terms such as resilient, redundant and highly available.
Request a plain-English explanation of which failures its design is intended to withstand. Does that include losing one hosting location? What about a wider regional disruption? Which features remain usable, and which require manual intervention?
Ask when its recovery arrangements were last exercised and whether a customer-facing summary is available. Request the incident notification process, too: where updates appear, who receives them and how customers learn whether follow-up action is necessary.
Do not assume every vendor will disclose detailed architecture. Where information is unavailable, record the uncertainty and include it in the purchasing decision.
Choose proportionate safeguards
We would not recommend buying a second platform for every application simply because a major cloud provider experienced an outage.
Instead, agree on a practical tolerance for each essential activity. For an internal report, waiting may be acceptable. For dispatching technicians, you might want an approved way to access the day’s assignments and record changes while the main system is unavailable.
Before purchasing an alternative service, ask your IT team to check whether it shares the dependency you are trying to avoid. Define how staff would use it, who authorizes the change and how work gets reconciled afterward.
Test one complete workflow
Run a short tabletop exercise: assume your main scheduling application is unavailable during a busy morning. Ask the people who actually use it to walk through their next steps.
Include customer communication and the return to normal operations. Who checks that new appointments were recorded correctly? Who resolves conflicting changes? Who confirms the workaround can be retired?
For this week, aim for one useful outcome: identify a shared dependency affecting an important workflow, assign an owner and agree on the next action.
Magic Touch Computers is Your Global IT Department, providing business IT services since 2003 from Calgary to businesses internationally. Contact Magic Touch at (403) 770-6652 or through our contact page, or take our free AI IT assessment to start the conversation about your business technology.
— The Magic Touch Team