Solution architect: behavioural questions

Action: I started with business capabilities, not systems.

• I built a capability map of the 14 capabilities the offer needed. Eleven existed in some form. Three were real gaps: identity verification, credit decisioning and document handling.
• I made a reuse, buy or build call per gap, based on differentiation. We bought identity verification (a commodity), reused the enterprise document platform, and built credit decisioning, because risk appetite is where we compete.
• I defined two releasable transition states, each with a funding gate and exit criteria such as decision time and pilot loss rate.
• Executives got one page of trade-offs and a "not doing" list; engineers got the integration views.

Action: I built the case with finance, not for them.

• I modelled four cost lines: licences and hosting, specialist skills, incident cost, and change lead time as cost of delay.
• I wrote down every assumption with an owner, and agreed the assumptions with finance before showing any totals.
• I showed pessimistic, expected and optimistic cases. Even the pessimistic case paid back in under 3 years.
• I timed the migration to the renewal cycle: no renewal for the two platforms we were retiring, and a short extension with a break clause for the third.
• I counted dual running and retraining honestly, and showed the cost of doing nothing: two platforms were near end of support.

Action: I compared options on cost, risk, time to first value and reversibility.

• I showed that big-bang replacement delivered nothing for about 3 years and ended in one high-risk cutover. Re-hosting kept every problem.
• I recommended progressive modernisation. CDC events stream changes out of the core, so new services read data without touching it.
• New capabilities, such as hardship handling and pricing, were built outside the core. A strangler at the channel layer routed journeys to new services, domain by domain.
• I set a policy: no new features in the core without an architecture exception.
• I tied each domain move to an outcome, so the board saw progress every quarter.

Action: I sat with the lead and asked what the gateway really cost them: two weeks of tickets, manual policy setup and hand-built certificates.

• I judged that "temporary" bypasses rarely get removed, and the blast radius of an unaudited partner link at a bank was not acceptable.
• Instead of escalating, I paired with the platform team to build a paved-road template: one config file generated the gateway route, mTLS, rate limits and dashboards.
• I made this team's integration the template's first customer, so a real need shaped it.
• I agreed a simple rule with the platform lead: use the template, or raise an exception with an expiry date.

Action: I started with evidence, not opinions.

• I reviewed six months of submissions: about 70% were low risk, and nearly all had been approved unchanged.
• I proposed risk-tiered reviews with a one-page checklist covering data sensitivity, external exposure, reversibility and cost.
• Tier 1 became a self-certified lightweight ADR, published and spot-checked. Tier 2 became an async review with a 3-day reply rule. Only Tier 3 came to the board.
• I added weekly office hours, so teams could get advice before writing anything.
• I ran it as a 3-month pilot with monthly metrics, so sceptical board members could judge the data.

Action: I treated it like an incident review of my own decision.

• I gathered evidence: change lead times, teams involved per change and the blocked backlog.
• I told the architecture forum plainly, "my decision didn't hold up", with no blame on teams.
• I proposed domain-owned contracts: each domain publishes its own versioned events, plus a translation layer for consumers that still needed the old shape.
• I migrated consumers in waves, starting with the noisiest, and kept the old schema behind the translator until the last one moved.
• I wrote a decision post-mortem ADR that superseded my original, recording what I knew then and which signals I missed.

Action: I asked our customers before choosing metrics.

• I interviewed 6 delivery leads and 2 executives: "What would make architecture worth paying for?"
• I chose four metrics: pattern reuse rate, design-approval lead time, incidents traced to architecture decisions, and cost avoided (licences not bought, platforms retired).
• I baselined them honestly, including the bad ones. Approval lead time was 18 days.
• I agreed the cost-avoided method with finance, so we weren't marking our own homework.
• I published a one-page quarterly report: four numbers, the trend, one story and one thing we got wrong.

Action: I reframed the question as "which risk are we buying down?"

• I named three risks: concentration risk, a provider-wide failure, and a commercial dispute we couldn't leave.
• I modelled active-active multi-cloud: roughly double the platform engineering, skills and security tooling, and a lowest common denominator of services. Run cost rose about 1.8 to 2 times, and delivery slowed.
• I proposed a primary cloud with portable layers: containers, open standards, infrastructure as code and data in open formats.
• I wrote an exit plan per critical service, and proved it by rebuilding two services in a second cloud.
• The second cloud got one narrow job: immutable backups and a cold rebuild path for critical data.

Action: I mapped the service before judging any system.

• I drew an end-to-end service map: channels, login, fraud checks, payments hub, core banking, scheme gateway and shared infrastructure.
• With the business owner I set impact tolerances: at most 2 hours of disruption, and no loss of accepted payments.
• I designed scenarios such as region loss, ransomware on shared infrastructure and a key vendor outage. We ran tabletop and live tests.
• The tests found a shared single point of failure: all payment signing depended on one HSM cluster in one data centre.
• I priced the fix against the cost of a tolerance breach and put it in the investment plan.

Action: I made the risk visible first.

• I built a dependency map from connection strings, network flows and the configuration database. It showed 23 applications on the cluster, 4 of them customer-facing.
• I scored each app on business criticality, change frequency and coupling, such as cross-schema joins.
• I told the executives what one failure meant: 23 apps down together, and payments delayed for customers.
• I set a target pattern of a database per service, with data shared through APIs or events, plus a "no new tenants" rule from that day.
• Moves were funded through each app's own roadmap where possible, with a small central fund for the rest.

Action: I treated it as a design problem and a commercial problem together.

• I showed the composite availability maths to the business and the vendor. Even with perfect systems on our side, the chain reached only about 99.4%.
• I asked for the vendor's real availability history. It was near 99.8%, which gave us room to negotiate.
• I designed a degradation mode: writes are queued with idempotent retry, and customers see balances and status from a read-only cache during outages.
• I negotiated a 99.7% SLA with tiered service credits and root-cause reports within 5 days.
• I also secured data export rights in an open format, an exit-assistance clause and 12 months' notice of breaking API changes.

Action: I started with facts, then made the target simple enough to remember.

• I built an inventory from network flow logs, code scans and team interviews, and gave every link an owner and a criticality rating.
• I set three defaults: layered APIs (system, process, experience) when a caller needs an answer now, events for state changes others care about, and managed file transfer for bulk.
• I rejected a big-bang re-platform. Instead, any project touching a link had to move it to the target, funded as part of that change.
• I published a one-page decision tree and an integration catalogue, so teams could self-serve the choice.

Action: I pulled several levers at once.

• I wrote a short API style guide and turned its rules into linting in CI, so feedback came in minutes, not at a review board.
• I stood up a catalogue and developer portal with docs, sandbox keys and self-service onboarding.
• I named an API product owner for each core domain API, with a roadmap and a deprecation policy.
• For the three customer APIs, I ran a consumer survey, picked the strongest as the base, and gave the others a published sunset date.
• I reported reuse metrics quarterly: consumers per API and time to first call.

Action: I designed a coexistence architecture instead of a rushed migration.

• I used identity federation, so our identity provider became the front door while the fintech's stayed live behind it.
• I put an anti-corruption layer between the two customer models, so neither team had to adopt the other's schema.
• I added a customer-matching service. High-confidence matches linked automatically, and low-confidence ones went to a human review queue.
• I planned phased migration by product, with a rollback path at each step, and left the fintech's app front end untouched.

Action: I adopted data mesh principles, not a big-bang reorganisation.

• I started with two domains that had strong engineering teams, payments and lending, rather than forcing every domain at once.
• I made each dataset a data product with an owner, documentation and a freshness target.
• I introduced data contracts (schema, quality checks, service levels) checked automatically in the pipeline.
• I turned the central team into a platform team offering templates, a catalogue and access controls as self-service.
• Privacy classification and retention rules became policy as code, so governance ran on every publish.

Action: I designed an AI gateway as the single path to any model.

• It provided central auth and per-team quotas, so keys left team code and runaway spend was capped.
• It added PII redaction, prompt-injection screening and content safety on inputs and outputs.
• I set up a model catalogue of approved models, each with a risk rating and data-handling terms.
• I added an evaluation service so teams could test quality before release, and token cost tracking per product.
• I made migration cheap: an SDK swap of about a day, and the first three teams got hands-on help.

Action: I set up a light intake process with the risk and data teams.

• Each idea was scored on value, feasibility, data readiness and a risk tier based on who could be harmed.
• I used the EU AI Act as a reference point: its Annex III lists creditworthiness assessment as high-risk, which matched our own instinct.
• We picked three: complaint triage, policy search for staff and document classification.
• I deliberately deferred the credit-limit idea. I offered a human-in-the-loop version instead, where the model only drafted reasons for an analyst.
• Each funded idea had a stage gate with a measurable success target.

Action: I ran a time-boxed trial instead of a debate.

• I agreed four criteria up front: observability (can we trace every step and tool call?), security (least-privilege tool access), cost control (token budgets that stop runaway loops) and maturity.
• Two teams built the same internal workflow, reconciliation exception triage, on two frameworks over six weeks.
• I scored the results in the open, with the teams in the room.
• I published a split verdict on the radar, with the evidence behind each part.

Action:

• I got a pre-release environment from the vendor and ran our contract tests against it within 48 hours: 14 of 60 cases failed.
• I put the impact in business terms: a failed cutover meant manual rework of about 300 applications a day and an outage for brokers.
• I framed three options. A: go live with a quick hotfix (untested under load). B: ask the vendor to delay (not in our control). C: move go-live 3 weeks. I recommended C, with B as a fallback.
• I took a one-page decision paper to the steering committee that week, not at the next monthly report.
• I agreed weekly checkpoints, so the new date was an evidence-based re-plan, not a guess.

Action:

• I ran a 90-minute contract clinic with product and tech leads from all three units. We mapped each request to the fields and behaviour it needed, and why.
• About 80% of the asks overlapped. All three needed a structured address and consent per channel; the differences were naming and edge cases.
• I proposed one versioned change: a v2 with additive fields, with v1 kept for 6 months. I rejected separate endpoints per unit, because that meant triple the maintenance and slow drift.
• For the other 20%, I published a roadmap ordered by launch date and customer impact, agreed in the room.
• I set a weekly 15-minute check-in, so nobody needed to escalate.

Action:

• I redefined the definition of done as "running in a prod-like environment with real masked data and passing end-to-end tests". By that measure only 12 of 50 were done, not the 35 or so that had been reported.
• I put every interface on one board (built, deployed, data-tested, done) as the single source of truth.
• The board showed the real bottleneck: test data and environment access, not code. I got a masked-data refresh pipeline prioritised and a shared environment booking system set up.
• I changed the daily stand-up to 15 minutes on the oldest blocked card, not status reporting.
• I re-baselined with the sponsor using the measured burn-down rate, not hope.

Action:

• I met the GM to understand the real goal: to be seen as innovative, and to cut calls about simple questions.
• I named three risks in plain words: wrong fee answers (conduct risk), privacy and reputation. Then I showed a short demo of a prototype quoting a fee from a 2-year-old PDF.
• I proposed internal agent-assist first: the same assistant helping call-centre staff, with a human in the loop and cited sources, delivered in 3 weeks.
• I set measurable evaluation gates for going customer-facing: groundedness above an agreed level on a 300-question test set, red-team results, and compliance sign-off.
• I suggested announcing the internal launch together, so the GM still had a story to tell.

Action: I built the session around their two questions.

• I opened with the answer: "Yes, it can make mistakes. The accountable executive is the product owner, the same as for any other channel."
• I explained hallucination with an analogy: a very well-read new graduate who answers confidently even when unsure, unless you hand them the policy manual and check their work.
• I showed the controls as layers: grounding on approved content, evaluation before release, human review for high-risk answers, and live monitoring with a kill switch.
• I gave one metric: the groundedness rate on a fixed test set, with a 98% target, reported monthly.
• I proposed three tiers, so the board could say where AI may act alone, may only assist, or must not be used.

Action:

• I acknowledged the deadline and the value: spotting hardship early helps customers.
• I explained the risk: a sandbox copy with weaker controls would widen access to very sensitive data, including hardship indicators. That breaks data minimisation.
• I proposed a pipeline: masking and tokenising direct identifiers, plus synthetic data for rare cases, with the privacy review at the start, not the end.
• I brought the privacy officer in during week 1, and we agreed acceptance tests: re-identification risk checks and no raw identifiers.
• In a controlled environment, we compared model quality on masked data with production-like samples to prove it was fit for purpose.

Action: I mapped every place customer data could go, then closed each one.

• I chose in-region model deployment in an in-country cloud region, and kept the vector store and caches there too.
• I used private networking, so no traffic crossed the public internet.
• I agreed no data retention by the model provider, in both the contract and the service configuration.
• I added tamper-evident audit logging, with the logs themselves held in-country.
• I designed disaster recovery to a second in-country region. I refused a cheaper overseas failover, because residency had to hold during an outage too.