BW-301b · Module 3

Translating Architecture into Business Language

5 min read

The problem with technical proposals is not that technical people write them. The problem is that technical people write them for technical readers, and the person who signs the contract is usually not technical. An architecture document that correctly describes the system and uses no language the decision maker understands has failed at its actual job.

Translation is not simplification. A simplified explanation that loses accuracy is worse than a technical explanation that is not understood — at least the technical reader can verify the technical explanation. A simplified explanation that is subtly wrong will go unchallenged and then be wrong in the contract.

  1. Identify the Decision Maker's Frame of Reference Before translating, identify what the non-technical reader already understands. An operations executive understands workflow, bottlenecks, and cost per transaction. A CFO understands total cost of ownership, depreciation schedules, and risk-adjusted value. A legal officer understands liability, compliance, and auditability. Translate into their existing frame — do not build a new one. "The proposed microservices architecture reduces single-point-of-failure risk" means nothing. "The system is designed so that a failure in one component does not take down the others — your team keeps working even if one piece fails" means something.
  2. Lead with Outcome, Follow with Mechanism Every technical description should begin with the business outcome it produces, then briefly explain the mechanism for readers who want it. Not "We will implement an event-driven messaging architecture using a distributed queue to enable asynchronous processing." Instead: "This design means your finance team can submit batch jobs at any time without waiting for the system to be free — the queue handles the scheduling automatically. The technical pattern is event-driven messaging with a distributed queue." The first sentence is for the executive. The second sentence is for the technical evaluator. Both are in the proposal.
  3. Create a Two-Register Document Technical proposals frequently need to speak to two registers simultaneously. The practical solution: write each major technical section with two components — a "business impact" paragraph in plain language, followed by a "technical approach" paragraph in appropriate technical language. The executive reads the first paragraph of each section and forms an accurate picture. The technical evaluator reads both. Neither reader is asked to navigate language that excludes them.

Do This

  • "The proposed solution eliminates the manual reconciliation step your finance team currently runs each quarter, saving an estimated 40 analyst-hours per cycle. Here is how: [technical mechanism]"
  • "This approach meets SOC 2 Type II requirements, which means your auditors have a clear and verifiable trail of every data access event."
  • Lead with the outcome that matters to the decision maker, then add the mechanism for the technical evaluator
  • Use a glossary for essential technical terms that cannot be avoided in the body text

Avoid This

  • "Containerized microservices deployed on a Kubernetes cluster with horizontal pod autoscaling" without a business translation
  • "This is enterprise-grade technology" — this says nothing to anyone
  • Assume the non-technical reader will ask for clarification if they do not understand
  • Relegate all business-language translation to the executive summary and write the body entirely in technical register