Technology Strategy: From Goals to Choices
The retailer’s technology strategy was sixty pages long and had been approved by the board. It opened with a vision, continued through nine strategic pillars, and ended with forty-seven initiatives, each with an owner and a year. Three years on, forty-one were in progress and six had not started. The cloud migration was at forty percent. The two ERPs that the strategy had planned to consolidate were both still running, one of them upgraded in the meantime. An earlier e-commerce rebuild, completed before these forty-seven initiatives were approved, had not fixed delivery delays; another rebuild was now on the list. The board still did not know why customers who ordered online waited two days longer for delivery than at the company’s main competitor. None of the initiatives had been tied to an explanation of that gap.
The company and its numbers are fictional. Its document contained goals and activities without explaining how the activities would overcome the business’s obstacle. A technology strategy needs that explanation, including the contribution technology can make alongside changes to responsibilities and processes. This article follows the reasoning from a diagnosis through a guiding policy to principles, standards, sourcing choices, and investments. It also examines how to fund shared capabilities and decide which proposals to pursue, revise, defer, or decline.
A strategy is an argument, not a list
Richard Rumelt’s account of bad strategy warns against avoiding the challenge, substituting goals for strategy, setting poor objectives, and hiding weak reasoning behind abstractions. The retailer illustrates the problem: its initiatives had sponsors and dates but no account of the delivery bottleneck. Adding more detail to those initiatives would not establish that they addressed it.
Rumelt calls the underlying structure a strategy kernel: a diagnosis explains the challenge, a guiding policy chooses an approach to it, and coherent actions carry out that approach together. These parts provide a useful way to examine technology choices. Filling three headings is not enough; the evidence, the fit of the approach, and the feasibility of the actions still need scrutiny.
Begin with the business outcome and investigate what prevents it. Business users, operations staff, and technologists can contribute observations, logs, and competing explanations. The cause may involve responsibilities, procedures, data, or technology; the investigation determines which interventions are useful. In the retailer’s case, order traces and warehouse walkthroughs showed that checkout used yesterday’s inventory and a nightly assignment process, even when a nearer warehouse had stock. Two ERPs and three warehouse systems held different parts of the inventory record. Their number alone was not the diagnosis: the missing timely, reconciled view and the allocation process explained a delay the team could address.
The chain from a business goal to a technology choice
The capability map from Eighty Diagrams and No Answer helps connect a business outcome to the abilities it requires. The diagnosis identifies obstacles to those abilities; a guiding policy chooses how to address them. Principles can then guide recurring decisions, while standards and individual choices make the approach concrete. Investments fund the work, and the target architecture describes the intended state. The following chain makes the retailer’s reasoning inspectable. It does not deduce a unique product from a goal: alternatives, required controls, contractual constraints, and operating capacity also shape each choice.
| Link | Question | The retailer |
|---|---|---|
| Business goal | What outcome does the business need? | Within eighteen months, match the competitor’s delivery lead time and make dependable delivery promises without increasing fulfillment cost per order for comparable orders |
| Capability | Which abilities does that depend on? | Maintain stock availability by location within a defined freshness limit; promise a feasible date; reserve stock and allocate orders to suitable warehouses |
| Diagnosis | What prevents it, and what evidence supports the explanation? | Checkout uses overnight inventory and batch allocation; the completed front-end rebuild left this path unchanged |
| Guiding policy | What approach addresses that obstacle? | Establish an agreed inventory view and allocation responsibilities, then connect delivery promises to that view before expanding features that depend on it |
| Principles | What should recurring decisions preserve? | Assign inventory write authority by site and attribute; allow governed read copies; meet checkout freshness needs; compare sourcing options against required behavior and operating capacity |
| Choices | Which alternatives meet those requirements? | A shared event platform; a purchased warehouse system after fit tests; a small in-house promising service after evaluating commercial configuration and integration |
| Investments and target | What is funded, and what depends on what? | Inventory stream with existing-system adapters; staged warehouse consolidation; production promising on validated stock and reservation paths; second ERP retirement after dependent workloads migrate |
ERP consolidation comes later in this example because the team can supply the inventory view from the existing systems. The choice depends on validating those adapters, their support cost, and the remaining ERP obligations. Design and pilots for the promising service can overlap with warehouse work; production rollout depends on reliable stock, reservation, and fulfillment paths. The completed e-commerce rebuild is a sunk investment. The proposed new rebuild remains a choice, and the team can compare it with integrating the existing site.
Principles: the guiding policy written as rules
A guiding policy should be clear enough to summarize, with supporting evidence available where needed. An architecture principle carries that approach into recurring design decisions by stating the direction, its rationale, its scope, and its implications. Teams need to know which decisions are delegated and which require approval. A mandatory rule needs a compliance test; a guiding preference needs a way to explain tradeoffs.
The UK government’s Cloud First policy illustrates explicit scope: public cloud is the default, mandatory for central government and recommended more broadly in the public sector. Other hosting choices require supporting evidence and a value-for-money case. The Technology Code of Practice distinguishes mandatory points from guidance to follow where practical. Its Use cloud first guidance describes reducing infrastructure-management work so teams can focus on user services. Those documents show how a direction can have a stated scope and rationale; the retailer’s approval arrangements below are an illustrative local design.
| Element | A principle that cannot be applied | A principle that can |
|---|---|---|
| Statement | Use best-of-breed technology | For each inventory site and attribute, identify who may authoritatively change it; define how consumers receive and interpret updates |
| Rationale | An unsupported preference | Conflicting updates and stale checkout data cause incorrect allocation; consumers need agreed meanings and freshness bounds |
| Implications | Unstated | Read models and caches are permitted under the update contract. A proposed independent writer requires review of authority and conflict handling. Warehouse systems own specified stock attributes; the shared view combines their updates |
| Exception route | No process for unmet needs | Record the reason, responsible owner, approving authority, controls, and review or expiry date. Investigate clusters before changing the rule |
| Test | No criteria for review | Check mandatory requirements; for advisory principles, explain the alternatives and the tradeoff made |
A technology standard names a supported choice within a scope; a principle explains a direction that may guide many choices. A standard can also derive directly from a required control or contract. A principle can influence an individual decision without producing a standard. A Standard Nobody Could Deviate From explains the operating arrangements for standards and exceptions. Without a route for unmet needs, teams may stall or depart silently. A cluster of exceptions warrants investigation: the scope may be wrong, but implementation defects, migration stages, or missing skills can produce the same pattern. Recording an exception does not authorize it or waive a mandatory obligation.
Foundation or initiative: where the money goes
Funding shared capabilities and funding particular business outcomes are related decisions. Several initiatives may benefit from an inventory service, but someone must fund its operation and evolution. If that responsibility is absent, projects can duplicate work or inherit an unsupported dependency. Conversely, a shared platform can consume funding without meeting a demonstrated need. The Vote Always Went to the Forty examines that problem through platform users and priorities. A shared capability can itself differentiate several business units; differentiation does not rule out common ownership.
Decide which processes and data need to be shared, which may vary by unit, and who has authority to make those choices. Evan Bottcher’s platform discussion describes the tension between team autonomy and the costs of divergent implementations. The platform strategy article’s questions about demand, differentiation, divergence costs, and operating capacity help investigate a capability; they do not settle its value automatically. Make planned allocations visible with a period, a spending denominator, and the assumptions that would change them. The table shows this retailer’s chosen funding arrangements, not a universal central-budget rule. Its rows overlap: a shared service can also need renewal. For budget totals, assign each cost once and use separate tags for sharing, business outcome, and lifecycle work.
| Investment | Who funds | Who decides | Test for belonging here | The retailer |
|---|---|---|---|---|
| Shared foundation | Central budget with business sponsors in this retailer | Named investment authority, with platform and consumer input | Shared demand or strategic importance justifies the joint operating arrangement | Inventory event platform; identity; warehouse integration |
| Core process change | Central funding for this cross-channel change | Executive process owner with delegated investment authority | The benefits and constraints justify a common process across channels | Order promising and allocation; shared components counted once |
| Unit initiative | Unit budget in this example | Delegated unit authority, with required control approvals | Benefits primarily accrue to the unit; shared dependencies and controls remain funded | Marketplace seller onboarding; stores clienteling app |
| Renewal and retirement | Central or unit funding according to ownership; no universal fixed share | Accountable service and budget owners using lifecycle evidence | Support dates, risk, migration dependencies, and service obligations justify the timing | Second ERP retirement provisionally funded in year three |
A sourcing policy sets criteria for build-or-buy decisions. GOV.UK’s purchasing guidance asks teams to examine requirements, market alternatives, lifecycle costs, and their delivery and support capabilities. Unusual needs or a need for modification can favor building; suitable configurable products can favor buying. A combination is possible. Differentiation alone does not establish which option meets the need.
For this fictional retailer, assume trials show that a commercial warehouse package supports the required stock events, reservation interface, and site workflows through supported configuration. The comparison favors buying over extending each legacy warehouse system or building a replacement. Assume separately that evaluated promising products cannot implement the required allocation rules within the agreed response-time and integration constraints, while a prototype and staffing review support a small custom service. That evidence supports building this component, with operating ownership and cost estimates recorded. If configuration or integration had met the same needs at a better overall value, buying could have supported the same business differentiation.
The technology selection method keeps requirements ahead of the shortlist. Compare quality, expected benefits, risks, and total cost of ownership, including exit cost. Cloud First’s value-for-money definition combines quality and effectiveness with cost over the period of use. TCO supplies the cost side of that comparison; it cannot by itself rank alternatives with different outcomes.
A strategic choice versus a list of initiatives
The retailer needs to decide what its resources can support. Agreement to fund every proposal would leave the allocation problem unresolved. A credible choice records the alternatives and the consequences of accepting one, whether it ends a project, changes its scope, or confirms an existing course of action. A portfolio already aligned with the evidence need not invent a cancellation to qualify as strategic.
Before ranking discretionary work, identify mandatory obligations, service-continuity needs, deadlines, and dependencies. Work outside the inventory policy may still be necessary. If a proposed implementation conflicts with the policy, its obligation remains until an authorized alternative satisfies it. In this example, assume the forty-seven open initiatives are discretionary proposals; required operational and control work is separately identified and funded. Nine proceed, twenty-two are deferred with review conditions, and sixteen are canceled with their remaining work closed, or withdrawn before starting. The latter include the proposed new e-commerce rebuild, not the completed one. They also include a CDP proposal that, on examination, would independently edit the same customer identity attributes already owned elsewhere without an agreed conflict process. A CDP that consumes those attributes would require a different assessment; the inventory diagnosis alone would not justify rejecting it.
The nine selected initiatives form work packages across the inventory stream, warehouse consolidation, and promising-service investments. ERP retirement remains a separately budgeted lifecycle dependency. Reasons for each deferral or cancellation are published, and deferred work is reconsidered when its assumptions change rather than promised an automatic place later in the roadmap. Strategic planning develops the sequence under uncertainty; portfolio comparison determines which feasible proposals receive the available funds.
Record consequential choices and assumptions in an architecture decision record at the appropriate scope. Assess reversal cost as described in Architecture Decisions instead of treating every large choice as irreversible. Review the diagnosis when evidence changes: competitor service, warehouse support dates, or the operating model after an acquisition. Scheduled reviews can complement those triggers, checking whether the expected outcomes appeared and whether anyone is still monitoring the assumptions.
Judging a technology strategy
A review should connect the diagnosis to evidence and the selected actions to that diagnosis, applicable obligations, and available capacity. A short explanation helps people use the strategy, but length does not establish its quality. Check the scope and force of principles, the authority behind exceptions, and the reasons for funding shared or local work.
Confirm that alternatives were considered and that benefits have measures, owners, and review points. People who make affected decisions should be able to explain the direction and find its supporting evidence. Use these review prompts to examine the evidence for the choices. The author has not validated them as a score, and the assessment does not require canceling a minimum number of initiatives; an already aligned portfolio can retain its proposals.
What a reviewer should ask
- What is the business obstacle, and what evidence distinguishes technical, process, and responsibility causes?
- What approach is chosen, which alternatives were considered, and why does it fit?
- Which principles bind, which guide tradeoffs, and who approves departures?
- Which exceptions cluster, and what explanations have been investigated?
- What spending period and denominator define the allocation, and how are overlapping categories counted once?
- For each sourcing choice, what evidence compares fit, operating capacity, value, and lifecycle cost?
- Which proposals proceed, change, wait, or stop, and how are mandatory obligations preserved?
- Can each funded initiative be traced to an outcome, obligation, or justified dependency?
- Who measures outcomes, and what evidence or review date would prompt revision?
The retailer’s revised strategy retained the diagnosis, sourcing evidence, and investment dependencies in a document its decision makers could use. A little over a third of the next year’s approved technology change budget was allocated to shared capabilities, counted once even where they also served a business initiative or renewal. Continuing operations were budgeted separately; the split would be reviewed as demand and obligations changed. The inventory stream went live in nine months. Later, after validating stock freshness, reservation, and fulfillment paths, the promising service began displaying dates on the existing site. This was an initial capability result. The team still needed to compare promised lead times, actual on-time delivery, and fulfillment cost per order across comparable orders to assess the eighteen-month goal. The second ERP remained scheduled for retirement in year three, subject to migration readiness and support commitments. The revised strategy made those decisions and remaining uncertainties visible.
References
- Richard Rumelt, The perils of bad strategy, McKinsey Quarterly, 1 June 2011.
- GOV.UK, Government Cloud First policy (Open Government Licence v3.0).
- GOV.UK, The Technology Code of Practice (Open Government Licence v3.0).
- GOV.UK, Use cloud first (Open Government Licence v3.0).
- GOV.UK, Define your purchasing strategy (Open Government Licence v3.0).
- Evan Bottcher, What I Talk About When I Talk About Platforms, martinfowler.com, 5 March 2018.
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.