Technology Strategy and Business Alignment Questions

Direct answer

The approved catalog is the list of technologies the company has already vetted and supports. I would treat the request as a risk-based exception, not a yes or no on the database. The team states the requirement and shows why the approved options fail it, a small panel decides within a fixed time, and the approval is conditional, limited in scope and expires on a date unless it is renewed on evidence. An exception here means permission to deviate from a standard for a stated reason and period.

Workflow

1. Intake: a short written request: the specific feature needed, what was tried with approved databases, data classification (the sensitivity label on the data, such as public, internal or customer-personal), expected size and criticality, and the team's plan for running it.
2. Triage by risk tier. Low risk (non-sensitive data, non-critical service): an architecture lead approves. High risk (regulated or customer data, critical path): security and operations also approve.
3. Decision within 5 business days of a complete request, so the exception path is not slower than ignoring the rule.
4. Conditions, then a review, as below.

What I weigh

• Is the feature truly required, or a preference? A short test against an approved option often settles it.
• Operability: who patches, backs up, monitors and is on call; does the organization have skills for it?
• Security and compliance: encryption, access control, audit, data residency (the rule about which country or region the data may be stored in).
• Cost, including people.
• Exit cost: how hard it is to move off later; whether the engine locks in the data model (vendor lock-in: the more of your design depends on one product's special features, the more it costs to leave).
• Spread: if three more teams ask, the right answer may be to evaluate it for the catalog rather than to grant repeated exceptions.

Making it time-bound (illustrative record)

Approval as a pilot works well: run it for a limited scope, measure whether the feature actually delivers, then decide on adoption, renewal or migration back to the catalog.

Why this works

The expiry makes the default "ends" instead of "lasts forever", and conditions put the extra operating burden on the team that asked. What would change my call: if the data is highly regulated and the controls cannot be met, I decline the exception and help the team find the nearest approved option.

Pitfalls

Granting by seniority of the requester, no owner for the expiry date, and exceptions piling up with no review (a shadow catalog: an unofficial second list of technologies in use that nobody owns or supports).

Direct answer

I would run technology bets through a lightweight, tiered process: every bet gets a one-page proposal that answers strategic fit and risk in business language, a time-boxed proof of concept (PoC, a small experiment to test the key uncertainty) with success and kill criteria written before it starts, and a short decision report to the CTO, with only large or hard-to-reverse bets going on to the board. The goal is to say a fast, reasoned yes or no, not to slow engineers down.

1. What a bet must show

A concrete example of a technology bet: an RPC (remote procedure call) framework is the library that lets one service call a function running in another service over the network, and a protocol is the agreed message format and rules, such as moving from JSON over HTTP to gRPC, which sends compact binary messages.

• Strategic fit: which company goal it serves and through which lever (cost, speed to market, reliability, new revenue). "Cleaner code" alone is not a fit.
• Alternatives, including doing nothing, and the cost of waiting.
• Risk and reversibility: how many teams must change, what migration costs, who runs it at 3 a.m., security and hiring implications. A tool one team can drop in a week is a different decision from a framework every service depends on.
• Kill criteria: the results, agreed before the work starts, that end the experiment automatically, for example "error rate more than 0.1 percentage points worse than today" or "still not working after 6 weeks".

2. Tiers of decision

3. Bounding the PoC

Illustrative PoC for an RPC framework swap: 2 engineers for 4 weeks (8 engineer-weeks), one real service with two endpoints, shadow traffic only (production requests copied, answers discarded). Criteria fixed in advance (illustrative thresholds): error rate in shadow within 0.1 percentage points of today's (for example today's 0.30% means the new path must stay at or under 0.40%), 99th-percentile latency no more than 10% worse, an on-call engineer who has not used the new framework diagnoses a staged fault in under 30 minutes with current tooling, and an estimate with a range for migrating the rest. Hard stop: if it exceeds 6 weeks, stop and report. Naive extrapolation: the 8 engineer-weeks of the PoC include evaluation work (setting up shadow traffic, building the comparison, the on-call exercise) that later services do not repeat. Suppose the PoC shows that actually moving one service to production takes 3 engineer-weeks of that; with 30 services, that is up to 90 engineer-weeks (6 engineers for 15 weeks); treat as an upper bound because later services go faster.

4. Reporting to the CTO or board

A one-page decision record (the write-up for a bigger decision, as opposed to the one-line entries in the decision log): decision requested, results against the criteria, cost spent, what we learned, recommendation, and next gate (the next checkpoint where the bet is reviewed, for example "expand to five services or stop"). Quarterly, a portfolio view: bets in flight, adopted, stopped (stopping is a healthy result). Boards see only the big ones, in terms of cost, risk and customer impact.

Trade-offs and pitfalls

• Too much process kills the experimentation you want; keep reversible bets nearly free.
• A PoC with no pre-agreed criteria always "succeeds" because the people running it want it to.
• Sunk-cost pressure: celebrate a clean stop.

Direct answer

I would judge the enterprise architecture (EA) function by what changed for the business because of it (faster safer decisions, less duplicated spend, fewer architecture-caused incidents), not by what it produced. I would show a CFO a small set of cost-avoidance and risk-reduction estimates with their assumptions stated, and pair every process measure with an outcome measure so that complying with the process is not the goal.

What to measure

Governance telemetry as a feedback loop

Governance telemetry means the counts that your own review process and automated checks generate. Example rule: "no storage bucket may be publicly readable". If an automated policy check blocks any design that breaks that rule, count the blocks per rule. Illustrative month: 200 designs checked, 60 blocked by the public-bucket rule (30%) and 4 blocked by every other rule combined. There is no universal "too high" rate; a rule that blocks far more than the rest is the signal. Either teams cannot tell what it means or the rule is wrong for how they work, so fix the rule's wording or the template that creates the bucket rather than blaming the teams. Also track how many decisions are recorded as architecture decision records (ADRs, short dated notes of what was decided and why) and how many are later reversed.

Maturity model

A maturity model scores a function by levels (for example level 1 "ad hoc, depends on individuals" up to level 5 "optimised, continuously improved"). It is useful for direction (what to build next), not as a target score; chasing a level is itself a compliance metric.

Showing value to a CFO (illustrative)

Cost saving (existing spend removed): three teams each pay 40,000 a year for a separate ticketing tool (120,000 in total). EA brokers consolidation to one tool costing 50,000, saving 70,000 a year in run cost; the one-time cost of migrating the three teams must be subtracted in year one, so the first-year saving is lower. Finance distinguishes a saving (reducing spend that exists today, as here) from cost avoidance (spend that would have happened but was prevented, which is softer and needs a stronger counterfactual); I label each correctly. Count it only if the spending was real, the decision is attributable to EA, and the counterfactual (what would have happened otherwise) is stated. "Duplicate capabilities" in the measures table means two or more teams paying for or running separate tools that do the same job.

Risk reduction: expected annual loss is probability times impact. A design flaw with a 2% yearly chance of a 500,000 loss costs 10,000 a year in expectation. A control that lowers the chance to 0.5% leaves 2,500, so 7,500 a year is reduced. These are estimates, and I label them as such and give a range.

Phrased to a CFO: "Consolidating three ticketing tools into one removed 70,000 a year of run cost (before one-time migration cost) that was real and budgeted; without EA's brokering the three teams would have kept paying. Separately, one design change cut an estimated 7,500 a year of expected loss, a figure with a range of roughly 5,000 to 10,000 depending on the loss estimate."

I put these next to the cost of the function and keep it at that altitude; a full return-on-investment model is a separate exercise.

Avoiding compliance-rewarding metrics

Do not report documents produced, reviews held, or percent of projects "compliant". Use counter-metrics: for every process measure, add a second measure that would get worse if people gamed the first. Example: the process measure "decision time" can be gamed by approving everything quickly, so pair it with "late-stage design reversals", which rises if approvals were careless. Review the metric set yearly, and ask teams whether the function helped.

Pitfalls

Claiming credit for outcomes teams drove, counting avoided cost that was never going to be spent, and presenting estimates as measurements.

Direct answer

The two options: a shared platform team is a central group that builds and runs common infrastructure and tooling for everyone; a squad is a small, autonomous team that owns one product area end to end. For companies with enough squads to pay for it (see the break-even below), I would recommend product-aligned squads (stream-aligned teams, in the Team Topologies book's terms: teams aligned to a flow of business work) supported by a small platform team that runs as an internal product (it treats squads as customers, measures whether they adopt it and takes feedback). Teams choose the platform because it is the easy path, not because they are forced to. I would centralize only where duplicated effort or risk outweighs the cost of lost autonomy.

Trade-offs in business terms

• Autonomous squads: faster decisions and clearer ownership of customer outcomes (good for speed and accountability). Cost: duplicated tooling and inconsistent security or reliability practices (cost and risk).
• Shared platform teams: economies of scale, consistent compliance, lower engineering spend on plumbing (the repeated infrastructure work such as build pipelines, monitoring and deployment setup). Cost: queueing for the platform team and a risk of building what nobody asked for.
• Conway's law (a system's design tends to mirror the communication structure of the organization that builds it) means the org chart will shape your architecture, so choose the structure you want the system to have.

What I would need to know first

1. How many squads, and how much of each squad's time goes to shared plumbing today.
2. Regulatory exposure, and whether a failure in one squad can hurt the whole company.
3. How much the business needs speed in separate products vs consistency across them.
4. Whether we have the people to staff a platform team that is good enough to compete with squads doing it themselves.

Worked example (illustrative assumptions)

12 squads of 6 engineers (72 engineers). Assume each squad spends 1 engineer on shared plumbing: 12 engineers, or 16.7%. A platform team of 5 that cuts each squad's plumbing to 0.4 engineers costs 5 + 12 x 0.4 = 9.8 engineers: a saving of 2.2. Break-even is where 5 + 0.4n = n, so n = 8.3: with fewer than about 9 squads the platform does not pay for itself on headcount alone. The assumptions are stated, not measured: 1 engineer per squad on plumbing would come from a time survey of the squads, and 0.4 from a pilot or the platform team's own estimate. This is why the recommendation above is conditional on scale: below roughly 9 squads I would not form a dedicated platform team at all, and would use shared libraries and a part-time volunteer group instead, moving to a funded platform team as squads are added. The answer depends on scale.

The same logic applied to other shared capabilities

• ML/model serving (running trained machine-learning models so applications can call them): central if serving needs scarce specialist skills and strict governance; product teams run their own if each model is tightly coupled to a product and the platform tooling is mature.
• Analytics: a central team gives consistent definitions and one source of truth; embedded analysts give speed and context. A common compromise is embedded analysts on a shared data platform with a central standards group.
• Ownership models that reduce coupling: give each service one owning team and make cross-team work go through APIs.

How I would know it is working

• Lead time (days from a change being committed to running in production) and deployment frequency (how often a squad releases to production) per squad, trended after the change.
• Share of squads choosing the platform voluntarily, and the number of duplicate tools being retired.
• Time for a new service to reach production.
• Cross-team incidents (outages that needed more than one squad to fix) and the number of requests waiting on another team.

If these worsen after two quarters, I would revise the model.

Direct answer

I would treat it as two problems in order: contain the risk without breaking anything the teams depend on, then fix the reason they went around us. Cracking down alone makes teams hide things better. The official path was too slow, so I would make it faster than the workaround.

Step 1: Immediate risk (first days)

1. Find everything. An unmanaged account is a cloud account the central team does not know about or control. List all accounts through billing records and the cloud provider's list of every account in the organisation, plus an ask to teams for amnesty-style disclosure. The message might read: "If you run anything outside the official accounts, tell us by the end of the month. Nobody is penalised for what you disclose, and we will help you move it or secure it. After that date, undisclosed accounts are handled as policy violations."
2. Triage each account by what it holds and how exposed it is: customer data or not, public internet exposure, who owns it, spend, and whether anyone is watching it.
3. Contain the worst. Close public exposure on accounts holding sensitive data, make sure someone is the named owner, turn on logging and billing alerts (notifications when spend jumps unexpectedly). Do not shut accounts down without the owner, because that can cause an outage and loses trust.
4. Bring accounts into management with a baseline set of controls, sometimes without moving the workload at all.

Step 2: Why they went around

Ask the teams, not defend the process. A useful opening question: "What did you need that the official route could not give you in time?" Measure the official path: how long from request to usable account? Suppose it is six weeks and the workaround takes an afternoon (illustrative). That gap is the finding. Other causes: required approvals nobody can explain, missing services, cost of the platform.

Step 3: Change governance

• Self-service account creation that already includes the baseline (a landing zone: a preconfigured, secured starting setup for a new cloud account), with a target of hours, not weeks.
• Guardrails that prevent the dangerous things (public storage with sensitive data) automatically, rather than approvals for everything.
• A light approval tier for low-risk work, and a fast exception path.
• A published service level for the platform team's own response time, so the official path is accountable too.
• Visibility: unmanaged accounts surface within days through billing and account-list checks.

Worked example: a managed service that bypasses network controls

A team starts using a third-party managed service whose endpoint (the network address the service is reached at) is reachable from the public internet, skipping our private network controls.

• Assess: what data goes to it, how is it authenticated, where is it hosted, what contract exists, and what security attestations (independent audit reports or certifications the vendor holds) does the vendor have?
• Remediate: move traffic to private connectivity (a link that keeps traffic off the public internet) if the vendor offers it, restrict allowed sources, encrypt data, and limit what data is sent. If none is possible, accept a documented, time-limited exception with compensating controls (extra safeguards that reduce the risk when the ideal control is impossible) and an owner. For instance: a team of eight sends customer email addresses to a hosted analytics service. The exception reads: "Allowed for 90 days, owner: the team lead; conditions: email addresses are hashed before sending, access is limited to our office network range, and the vendor's audit report has been reviewed."
• Prevent: a short intake form for any outside service touching our data, and an approved-services list with a fast path for common categories.

Trade-offs and pitfalls

• Too much amnesty teaches that rules are optional; too little drives it underground. Offer amnesty once, and enforce after.
• What would change my order: finding customer data exposed publicly means containment is the first hour, before any conversation.