The strategy-to-execution gap

Strategy is a short list of choices. Execution is a long list of projects. Between the two there is a gap, and money falls into it. You met strategy as a kernel of diagnosis, guiding policy and coherent actions. The word that matters here is coherent. When each department turns the goals into its own projects, the actions stop supporting each other.

Here is what usually happens. The board publishes goals. Each department head asks, "What can my team do for this?" Each answer is sensible on its own. Then the answers land on one budget list, and three kinds of problem appear:

• Duplicates. Two projects change the same thing in different ways. Finance and the app team both build credit approvals, so the company ends up with two sets of credit rules that disagree.
• Gaps. A goal needs a change that nobody proposed, because it belongs to no single department. Everyone assumes someone else has it.
• Orphans. Projects that name no goal. Some are pet projects. Others are foundations, such as replacing a system whose support ends next year, that every goal quietly depends on.

Duplicates also create integration spaghetti. Each project connects its new system to whatever it needs, by whatever route is quickest. After a few years nobody can draw how data moves, and every change takes longer than the last.

Mangrove Market is in exactly this position. The board's three-year plan (FY2027 to FY2029) has three goals. G1: double partner-shop revenue, from about $52M a year to about $104M. G2: open in two new cities by mid FY2028, with about 25 stores each, one new distribution centre and about 600 new partner shops. G3: cut the cost to serve a partner order by 30%. Within a month, departments sent 14 proposals worth $4.63M in total. The diagram groups them by what they would change.

Look at the warehouse row. Proposal 5 buys a warehouse management system (WMS) for the new city's DC, $650k. Proposal 6 upgrades North and East from WMS version 7 to version 9, $540k, because the vendor ends support for version 7 in 2027. Read separately, both are fine. Read together, they could leave Mangrove with three WMS setups and three support contracts, unless the new DC joins version 9 too. Look at order capture: proposal 1 adds a rep mode to the Partner app, so sales reps take phone orders in the app; proposal 14 rewrites the 2014 back-office order entry tool for $480k. If rep mode works, the old tool can be switched off. Rewriting it means paying to rebuild something you plan to remove.

Enterprise, business and solution architecture

The word architect covers several jobs. Titles vary by company, but three scopes come up everywhere.

Enterprise architecture (EA) looks at the whole organisation, business and technology together, over the same horizon as the strategy, usually three to five years. Its main question is which changes to make, in which order, so the goals are met without building things twice. The TOGAF Standard from The Open Group, the most widely used EA framework, splits this work into four domains: business, data, application and technology.

Business architecture is the business domain of EA. The Business Architecture Guild's BIZBOK Guide describes it as views of the business across capabilities, end-to-end value delivery, information and organisation, and how those connect to strategy, products, policies, initiatives and stakeholders. A business architect can talk about Mangrove's partner business for an hour without naming a system.

Solution architecture designs one change: a product, a feature, a migration. Its horizon is the life of a project, months to a year or two. It answers how to build this one thing well and how it plugs into what exists. You did a lot of this thinking in the system design lessons.

The three need each other. The solution architect for rep mode needs to know whether credit checks will live in the ERP finance module or in a new service, and that is an enterprise decision. The enterprise architect needs solution architects to say what a change really costs. A business analyst moving into this work already has the core skills from the Business Analysis course: asking why, separating the problem from the requested solution, and modelling what happens today. Business architecture applies them to the whole business instead of one project.

The chain from strategy to roadmap

Enterprise architecture is easier to learn as one chain of questions. Each link answers the question the link above raises, and this course follows the chain lesson by lesson.

• Strategy and goals. What are we trying to achieve, measured how? G1's measure is partner revenue: today about 1,800 shops × 2.2 orders a week × $250 × 52 weeks ≈ $52M; the target is about 2,700 shops × 2.6 orders × $285 × 52 ≈ $104M.
• Capabilities. What must the business be able to do, and do better, to hit those numbers? Adding 900 shops (2,700 minus 1,800) means Mangrove must get much better at partner onboarding, partner order capture and partner credit management. You will map these in ea-02.
• Value streams. Where does value flow and where does it break? A partner order goes from placing it to Mangrove being paid. Shops pay about 23 days after delivery on 14-day terms. That is a break, and ea-03 measures it stage by stage.
• Information and applications. Which systems and data support each capability, and where are they duplicated, missing or unfit? Partner master data lives in three places that disagree on about 1 shop record in 8 (ea-04).
• Technology. What do those applications run on, and what constrains them? Support for WMS version 7 ends in 2027 whatever the board decides.
• Initiatives and roadmap. Which funded steps close the gaps, in which order? This is where the 14 proposals get merged, reshaped and sequenced (ea-05), in the spirit of the outcome roadmaps you already know.

The chain gives you traceability in both directions. Down: for G2, which capabilities, systems and projects must change? Up: for proposal 14, which capability does it improve and which goal does that serve? When the board asks why it should fund $4.63M, the answer is a traced picture instead of fourteen separate business cases.

Views that answer someone's question

What do architects produce? The tempting answer is documents and diagrams. The useful answer is decisions, supported by a few pictures that each answer one person's question.

The international standard for describing architectures, ISO/IEC/IEEE 42010 (latest edition 2022), gives you the words. A stakeholder has concerns, the questions they need answered. A viewpoint is a reusable recipe for one kind of picture: which concerns it covers, for whom, in which notation. A view is the actual picture you make with that recipe for your situation. The standard deliberately does not tell you which views to draw. That depends on who is asking.

Two habits follow. First, start every view from a named stakeholder and a question. If you can't name either, don't draw it. Second, keep the views few and alive. Five views that are updated each month and used in real decisions are worth more than fifty in a repository. Gregor Hohpe calls the architect's job riding the "architect elevator": moving between the boardroom and the engine room, and carrying each side's reality to the other. Views are what you carry.

When enterprise architecture fails, and what good looks like

Many people have met EA at its worst, so expect some doubt when you start. The failures are well known:

• The ivory tower. Architects draw target states for a future that delivery teams never see, and the teams build around them.
• Frameworks first. Six months spent tailoring a framework and a model of every element type before answering one real question. Frameworks such as TOGAF say themselves that they should be adapted to the organisation. You will see how to use TOGAF lightly in ea-06.
• The 300-page document. A complete current-state description, out of date the week it is approved, read by nobody.
• Architecture police. A review board that every change must pass, adding weeks, so teams learn to hide their changes.

Good architecture looks smaller and faster. It is judged by decisions: duplicates merged, gaps filled, foundations funded before the work that needs them. It keeps a few living views, such as the capability map, the application map and the roadmap, and updates them as decisions are made. And it gives fast answers. When the head of operations asks which WMS the new DC should run, a good architecture team answers in days, with the trade-offs, because the map already exists.

A simple test for your own work: for each thing you produced last month, name the decision it changed. If the list is empty, you are drifting toward the ivory tower.