Analyzing and optimizing technical and business processes

Technical processes

Software development lifecycle

The SDLC phases are plan, design, build, test, release, operate and feedback. Cloud changes it in three ways: environments are created from code, releases are small and frequent, and operations feed back into planning through metrics and incidents.

• Shift left: test and scan earlier (unit tests, static analysis, dependency and container scanning, policy checks on Terraform before apply).
• Environment strategy: separate projects (and often folders) for dev, test, staging and production, with the same infrastructure code and different variables. Production access is narrower.
• Trunk-based development with short-lived branches and feature flags supports frequent releases; long-lived branches cause integration pain.
• DORA metrics measure delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service. They are a good answer when a question asks how to measure improvement of the delivery process.

CI/CD on Google Cloud

Design points:

• Build once, promote the same artifact (by digest) from dev to prod; do not rebuild per environment.
• Deployment strategies: rolling (replace gradually, cheapest, mixed versions run), blue/green (two full environments, instant switch and rollback, double capacity), canary (send a small percentage first, compare metrics, then widen; Cloud Run traffic splitting, Cloud Deploy canary, load balancer weights, Cloud Service Mesh). Feature flags decouple deploy from release.
• Database changes need backward-compatible, two-phase migrations (expand then contract) so old and new versions can run together and rollback is safe.
• Modernising CI/CD for containers with central management (the Altostrat requirement): Cloud Build + Artifact Registry + Cloud Deploy across GKE clusters on Google Cloud and on-premises, with fleets, Config Sync and policy controllers for consistency.
• EHR’s fast release goal: automated pipelines with testing gates, canary releases and automated rollback, plus regional GKE for availability.

Testing and validation

Use emulators (Pub/Sub, Firestore, Bigtable, Spanner) for fast local and CI tests; use real projects for performance tests, because emulators do not behave like the real service at scale. A test environment should mirror production in configuration, not necessarily in size.

Troubleshooting and root cause analysis

A repeatable approach: detect (alert, user report), triage (impact, severity, who is on call), mitigate first (roll back, fail over, shed load, scale up) and only then find the cause, fix, and learn.

Tools:

• Cloud Monitoring metrics and dashboards, Cloud Logging with Log Analytics (SQL over logs), Error Reporting (groups exceptions), Cloud Trace (latency across services), Cloud Profiler (CPU and memory per function), Cloud Debugger is gone (use snapshots in logs or Cloud Code tooling).
• Network Intelligence Center: Connectivity Tests (does path A reach B, which rule blocks it), Performance Dashboard, Firewall Insights, Network Topology, Flow Analyzer.
• Audit logs answer “who changed what” before the incident. Recent changes plus deployment history are the first suspect. Compare with the last known good version.
• Policy Troubleshooter for permission denied; Gemini Cloud Assist investigations correlate logs, metrics and changes to suggest a cause.
• Blameless postmortem: timeline, impact, root cause and contributing factors, what went well and badly, and action items with owners. Aim to fix the system, not blame a person.

Common root-cause pairs worth knowing: instances unhealthy because the firewall blocks health-check ranges (130.211.0.0/22, 35.191.0.0/16); Cloud Run cold starts or exhausted concurrency; GKE pods pending because of insufficient resources or IP range exhaustion; permission errors because of missing service account roles or organization policy; slow queries from missing partition filters; hot Bigtable node because of a monotonically increasing row key.

Service catalog and provisioning

Give teams self-service, approved building blocks: a private Service Catalog of Terraform solutions, Infrastructure Manager deployments, shared Terraform modules (Cloud Foundation Toolkit and Terraform blueprints), project factory automation that creates projects with correct folder, billing, APIs, budgets, labels, networks and baseline IAM, and Application Design Center and App Hub to model and track applications. Governance comes from organization policy, not manual review of each request. This reduces lead time and keeps standards (labels, regions, encryption) consistent.

Disaster recovery

• Terms: RTO (how long you may be down) and RPO (how much data you may lose). Different systems get different tiers; classify by business impact.
• Patterns: backup and restore, pilot light, warm standby, hot standby (see the design notes). Pick by RTO/RPO and budget.
• Technology: regional or multi-region services, cross-region replicas, Backup and DR Service, snapshots schedules, Cloud Storage dual/multi-region, global load balancing for fail-over, DNS TTLs short enough, infrastructure as code to recreate environments, and runbooks automated where possible.
• Test regularly: tabletop, then game days that actually fail over. An untested plan is a hypothesis. Include dependencies (identity, DNS, certificates, secrets, on-premises links) which often break recovery.
• On-premises or other-cloud DR into Google Cloud is a common design: replicate data to Cloud Storage or Persistent Disk, keep a minimal warm environment, scale up on failover, use Interconnect or VPN.
• Backups must be immutable and separate (another project, another region), because replication faithfully copies a deletion or ransomware.

Business processes

Stakeholder management

• Identify stakeholders (executives, product owners, security, finance, operations, developers, end users, partners), what each needs and fears, their influence and interest. Engage high-influence/high-interest people closely, keep others informed.
• Influencing and facilitating: translate technical choices into business outcomes (cost, risk, time to market); run workshops to reach shared requirements; present options with trade-offs and a recommendation; agree success measures up front; use proofs of concept to reduce disagreement.
• When requirements conflict (finance wants lowest cost, operations wants resilience), make the trade-off explicit, quantify it, and get a decision from the accountable owner. The architect documents the decision (a decision record) rather than choosing silently.

Change management

Technology migration fails more often from people than from technology. Practices: a clear case for change, executive sponsorship, a communication plan, training before cutover, pilot groups and phased rollout, champions inside teams, feedback loops, and measurement of adoption. Operationally: change windows, peer review of changes, automated rollbacks, and an approval flow proportionate to risk (standard changes automated, high-risk ones reviewed). A “big bang” cutover with no pilot, or training after go-live, is the wrong answer in most scenarios.

Team assessment and skills readiness

Assess current skills against the target (Kubernetes, Terraform, SRE, data engineering, security). Close gaps with training and certification paths (Google Cloud Skills Boost), pairing, a cloud centre of excellence, partner support or hiring, and by choosing managed services when the team lacks operational capacity. EHR’s executive says training for different systems was costly: standardising on a single platform and tooling reduces that. KnightMotives lists upskilling and communication between business and technical teams as objectives.

Decision-making processes

Use structured methods: collect requirements, list options, score against weighted criteria (cost, risk, time, fit, skills), run a proof of concept for the uncertain parts, record the architecture decision and revisit when assumptions change. Favour reversible (two-way door) decisions quickly, and slow down for hard-to-reverse ones such as database engine or region. Bring data (benchmarks, TCO, SLO reports) rather than opinion.

Customer success management

For a company that ships software or services to customers (EHR onboarding new insurers, Cymbal’s shoppers): define customer outcomes and health metrics (adoption, satisfaction scores, time to onboard, churn), instrument the product to measure them, create fast support paths and self-service, gather feedback into the roadmap, and share SLOs and status openly. Faster onboarding is designed through automation: templated environments, standard interfaces and APIs (Apigee) for new partners.

Cost and resource optimization

• CapEx versus OpEx: on-premises means up-front capital, depreciation and over-provisioning for peak. Cloud turns much of it into operating expense that scales with use, which improves cash flow and flexibility, and needs governance to avoid waste. Commitments (committed use discounts) bring back some predictability.
• FinOps practices: labels and a project structure for cost allocation, billing export to BigQuery with dashboards, budgets and alerts, quotas to cap runaway spend, Cloud Billing reports, and Cost Optimization hub with Recommender (idle VMs and disks, right-sizing, unused IPs, committed use suggestions).
• Levers: right-size and custom machine types; delete idle resources; autoscale and scale to zero; Spot VMs for tolerant work; committed use discounts for steady baseline; storage classes, Autoclass and lifecycle rules; BigQuery partitioning, clustering, slot reservations or editions, and avoiding SELECT *; keep data and compute in the same region to avoid egress; use CDN and caching; serverless for spiky load; shut down non-production out of hours.
• Optimise resource, not only price: removing waste beats negotiating a discount on waste.
• Sustainability: Carbon Footprint reports, choosing low-carbon regions, and removing idle resources also cut cost.

Business continuity

A business continuity plan covers people, process and technology: a business impact analysis to find critical functions and tolerable downtime, DR for IT systems, communications plans, alternate working arrangements, vendor dependencies, and regular testing and review. It lines up with the SLOs you set for services. Multi-region design, backups, tested runbooks and incident response roles all feed the plan. For EHR, regulation and patient care make continuity a hard requirement, for retail the peak season is the critical window.

Applying it to the case studies