Architecture Is the Blueprint; Data Strategy and Security Are What It Has to Carry
The deck's stated aim, on its session-title slide: examine the concepts of enterprise architecture and data strategy; discuss risks and mitigations related to digital security. That is three subjects, not one, and only the first is hinted at by the article and case. The organizing question the deck poses on its "Digital Opportunity and Risk" slide ties them together:
How should an organization organize its infrastructure, networks, applications and data to support growth without making the entire business vulnerable?
The deck's driving question. Note the second half — this session treats resilience and security as architecture problems, not IT-department problems.
The premise underneath it: digitalizing operations and digitizing data make organizations more efficient and better-informed — but digital dependence has become an operational risk. Modernization raises efficiency, while an organization's ability to keep operating during a technology failure becomes a strategic vulnerability. Every framework below is a response to that trade-off.
The Opening Hook — Hinton on Canadian Conservatism
The deck opens on a Financial Post piece (June 25, 2025) reporting Geoffrey Hinton — the Canadian "godfather of AI" and 2024 Nobel laureate in Physics — at Toronto Tech Week: Canada risks losing its early AI advantage because business adoption is too slow. His words: "[Canada] has got one big disadvantage, which is that … most Canadian industry is very conservative. They've been bad at taking up AI and educating employees. That's a big problem." He credits the government with good value from its R&D funding, but doubts Canada can stay at the cutting edge against U.S. and Chinese spending.
Why it's slide 2: it sets up the article's argument — timid, small-scale AI never reaches the deployment step that creates value — as a Canadian problem, in a room full of Canadian managers. Expect the professor to ask whether your own organization is the conservative adopter Hinton describes.
Evolution of Digital Infrastructure
Nolan's model (with Ghosh & Narain), plotting organizational complexity against environmental dynamism across four infrastructure eras:
Simple / Stable
"Centralized" — Mainframe/Mini
One machine, one department, one set of standards. Control is total because there is nowhere else for computing to happen.
Simple / Dynamic
"Decentralized" — Microcomputer
Computing escapes to the desktop. Responsiveness rises, standards fragment — the origin of the enterprise-spaghetti problem two slides later.
Complex / Stable
"Networked" — Client-Server
Integration attempted through the network layer. Middleware and EAI appear because the applications underneath were never designed to talk.
Complex / Dynamic
"Ubiquitous" — Cloud
Infrastructure becomes elastic and consumed rather than owned. This is where every cloud-migration question in the deck lives.
The deck attaches three evolving infrastructure perspectives to that arc — the lenses through which infrastructure investment gets justified, in maturing order: (1) cost savings via economies of scale; (2) business benefits for the life of the current strategy; (3) future scalability and flexibility.
Harley connection, ready to use: Krishnan explicitly refused to justify Harley's cloud migration on lens 1 — his line is that they moved "not to save money, but to get speed and agility." That is a company arguing from lens 3 while most of its peers are still arguing from lens 1. It is the cleanest possible illustration of this slide, and worth saying out loud.
"Enterprise Spaghetti" — the Problem Being Solved
The deck's blunt characterization of the installed base: enterprises "are typically comprised of hundreds if not thousands of applications that are custom-built, acquired from a third-party, running in multiple tiers of new and legacy operating systems and hardware platforms." The slide's question — how should organizations get out of such a mess? — is what enterprise architecture exists to answer.
The Operating Model (MIT Sloan CISR)
The conceptual 2x2 the deck uses before any formal framework. Axes: business process standardization (low → high) and business process/data integration (low → high).
Coordination — High integration, low standardization
Unique businesses that need to know each other's transactions and relationships. Easy access to shared data for decision making, without forcing common processes.
Unification — High integration, high standardization
A single business with global process and data standards: standard business processes plus shared data access.
Diversification — Low integration, low standardization
Independent businesses with different customers and expertise. Shared services for scale, but with genuine independence.
Replication — Low integration, high standardization
Independent but similar business units running standard business processes for efficiency.
Use it as a diagnostic, not a label. Harley's dealer network is structurally a replication model — independent dealers running a standard process — while Krishnan's integrated dashboard is a bid for coordination: shared visibility across demand, inventory, factories and logistics without making the dealers one business. Pernod Ricard (Session 4) sits in the same square for the same reason. Naming the target quadrant is a sharper contribution than saying "they need better integration."
From Legacy to Modern (Feld & Stoddard, adapted)
The deck's picture of what modernization actually changes, layer by layer. Legacy is four parallel silos, each with its own stack; modern is one stack with shared layers:
| Layer | Legacy (Siloed) | Modern (Integrated) |
|---|
| Apps | Separate applications per silo | Enterprise-wide applications |
| Data | Separate data store per silo | Shared data layer |
| Middleware | Point-to-point middleware per silo | Common middleware and APIs |
| Hardware | Separate hardware per silo | Shared hardware and networks |
Three Digital Architecture Dilemmas
The deck names these as genuine trade-offs, not problems with clean answers — useful language for the memo's Criteria section:
- Agility vs. standardization tension — standardization drives down costs and improves security, but it can hinder local innovation and agility.
- Legacy systems trade-off — legacy systems block digital transformation initiatives, yet replacing them is costly and time-consuming with no immediate returns.
- Applications and data control — business unit leaders are reluctant to give up preferred local applications and databases for fear of losing control.
The Enterprise System as Internal "Digital Platform"
A simplified map of the enterprise-wide systems present in established organizations: ERP at the centre; SCM/SRM on the supply side; CRM on the customer side; BI/BA above; and a data warehouse / data lake underneath. These are integrated using EAI, middleware, SOA, microservices and APIs — and must also link outward to the systems of suppliers, customers and government.
The accompanying challenges slide lists four failure axes — standardization, integration, cost, security — and the symptoms that produce them: data collected in separate departmental databases with access and security issues; more resources needed to keep applications upgraded; legacy systems never replaced and turned into "workhorse" systems; a technology portfolio of "three letter words"; and a continued lack of understanding between business and technology leadership.
What Enterprise Architecture Is
The deck's definition, worth memorizing: enterprise architecture defines the logical layout (blueprint) of an organization's digital assets — data, software, hardware — and includes the policies and guidelines that govern the arrangement of those assets. It is the discipline of aligning business strategy with digital execution, and it delivers three things: informed decision-making (when to standardize, when to differentiate), prioritized investments (technology spend supports business outcomes), and intentional change (a guided path from current to desired future state).
Business strategy may define where the organization wants to go, but enterprise architecture determines whether it can get there.
Straight off the EA slide — the single most quotable line in the deck, and the cleanest answer to "why should a general manager care about architecture?"
Two analogies the deck uses, both worth borrowing in discussion: EA as the architect's blueprint sitting between the owner's vision (business strategy) and the finished building (data, software, hardware); and EA as "urban planning" (Pearlson & Saunders) — you do not design each building, you zone the city so the buildings that get built can coexist.
The Digital Architecture Pyramid
A stack where each layer supports the one above, with security cutting across all of them:
Layer 1
Technology (Infrastructure) Architecture
Computer servers, desktop/laptop computers, operating systems, networks, middleware, storage.
Layer 2
Application Architecture
In-house and outsourced software — enterprise, functional and network applications — running on that infrastructure.
Layer 3
Data Architecture
Data model, data management, data quality, dashboards — data that must be collected, organized, secured and accessed through the applications.
Layer 4
Business Architecture
Strategy, structure, processes, operations — the business processes and activities that use the data.
Cross-cutting
Security Architecture
Risk management, access control, backup/recovery, training, crisis management — the deck draws this as the layer that safeguards all layers, not as a fifth tier.
Zachman — the Ontology (What to Document)
A matrix-based schema, not a methodology: six questions (What = data, How = function, Where = network, Who = people, When = time, Why = motivation) crossed with six perspectives (planner, owner, designer, builder, developer/vendor, functioning system). The deck shows the simplified three-column version: Data / Function / Network descending through Business Scope → Functional Model → Logical Model → Physical Design → Systems Development.
The deck is explicit that Zachman "is not a methodology for implementation or transformation" — it is "a structured organization of essential [digital] components necessary for creating, operating, and changing the enterprise."
| Advantages | Disadvantages |
|---|
| Comprehensive coverage; clear structure; neutral language; foundational | Too abstract; steep learning curve; overwhelming detail; not a roadmap |
TOGAF — the Methodology (How to Build and Manage)
The Open Group Architecture Framework: an iterative process model supported by common language, tools and templates so business and technology teams can work together. Its Architecture Development Method (ADM) runs a preliminary phase plus eight lettered phases around a Requirements Management hub:
A
Architecture Vision — scope, stakeholders, the vision itself, and approvals. (The deck's margin note: "get the organization committed and involved.")
B
Business Architecture — developed to support the agreed vision.
C
Information Systems Architectures — data and application architectures. (With B and D: "get the architecture right.")
D
Technology Architecture — the infrastructure for the project.
E
Opportunities and Solutions — initial implementation planning; identifying delivery vehicles.
F
Migration Planning — detailed transition-architecture sequences with an implementation and migration plan. ("Make the architecture work.")
G
Implementation Governance — architectural oversight of the implementation.
H
Architecture Change Management — procedures for managing change to the new architecture. ("Get the process up and running.")
TOGAF covers four architecture areas — business (how the organization works), data (what information is needed), application (what systems are used) and technology (what infrastructure supports it all). The deck's shopping-mall analogy: business architecture decides what stores belong in the mall; data architecture is what information each store needs; application architecture is the systems each store runs; technology architecture is the electricity, wi-fi and escalators serving the whole mall.
The complement, stated on its own slide: Zachman is what to document, TOGAF is how to build and manage — "the map and the journey." Zachman ensures completeness (no perspective missed) and aligns stakeholder viewpoints; TOGAF ensures process and delivers working systems. Both are heavy, and the deck's realistic advice is that organizations which succeed customize, adapt and blend them — Zachman for structure and completeness, TOGAF for transformation, execution and governance. If asked "which framework should Harley use?", this is the answer to give.
When Enterprise Architecture Becomes Important
Five triggers the deck lists — useful for arguing why now rather than why ever:
- Enterprise resilience — exposes critical dependencies and builds the adaptability to withstand security challenges and recover quickly from disruption.
- Cloud migration — guides purposeful adoption by aligning platforms, security, data and infrastructure with business priorities.
- Regulatory compliance — connects regulatory requirements to systems, data flows and controls.
- Mergers and acquisitions — accelerates integration by identifying duplication, aligning capabilities and creating a transition roadmap.
- Digital product delivery — lets teams innovate quickly within shared guardrails that reduce fragmentation.
On cloud migration specifically, the deck warns that capturing the benefits requires more than moving existing hardware and software. It needs different perspectives (data, people, processes and business goals, not just technology), a path from strategy to execution connecting the "what" to the "how", governance and accountability (without clear decision rights, projects drift, duplicate or fail compliance), and adaptability over time — migration is not a one-off but a repeatable method.
Data Strategy — Defence vs. Offence, SSOT vs. MVOT
The deck's pragmatic concession: comprehensive Zachman or TOGAF efforts are "often costly, time-consuming, and difficult to sustain," but companies should not skip the conversation — at a minimum they need a clear data strategy, balancing risk minimization against business growth. The central distinction is Single Source of Truth (SSOT) — one standardized, authoritative source — versus Multiple Versions of the Truth (MVOT), allowing flexibility tailored to specific business needs.
| Elements of data strategy | Defence (SSOT) | Offence (MVOT) |
|---|
| Key objectives | Ensure data security, privacy, integrity, quality, regulatory compliance and governance | Improve competitive position and profitability |
| Core activities | Optimize data extraction, standardization, storage and access | Optimize data analytics, modeling, visualization, transformation and enrichment |
| Data-management orientation | Control | Flexibility |
The named challenges: maintaining consistency and trust; balancing governance with flexibility; managing ownership and accountability.
This is the deck's own vocabulary for Krishnan's framing. Block 1 of this note reached "digital defense vs. digital offense" from the case; the deck arrives at the identical split from the data side and gives it precise content (SSOT vs. MVOT, control vs. flexibility). Using both together — Krishnan's phrase and the SSOT/MVOT mechanism — is a stronger contribution than either alone.
Data Strategy Maturity Model (C. Mello, CIO — adapted)
Four levels across people, process and technology, moving left-to-right from defence to offence:
Level 1 — Reactive
No data metrics
Staff discover a product is out of stock when a customer asks, then place an urgent order.
Level 2 — Controlled
Limited metrics
Everyone uses one inventory report showing stock quantities and weekly sales to decide what to reorder.
Level 3 — Proactive
Standard metrics
All stores measure stockout rate and inventory turnover the same way; managers review weekly and adjust orders before shortages occur.
Level 4 — Predictive
Real-time dashboard
A dashboard combines live sales, inventory and demand forecasts to predict shortages. Store managers see reorder alerts; finance sees the expected cash impact.
Place Harley on this scale in discussion. Krishnan's integrated dashboard — live demand, inventory, factory and logistics visibility — is a Level 4 artifact. But the case's problem is that Level 4 visibility sat on top of a business still making Level 2 decisions about production and dealer shipments. That gap, not the dashboard, is the story.
Data Strategy Components and Roadmap
Six components that "turn fragmented data into a trusted, secure and accessible foundation for better business decisions": master data management (one record for each customer, product, employee, facility), data integration (combining data from multiple sources), data quality (accurate, consistent, complete, up-to-date), data protection (security, backup and restoration), data governance (availability, relevancy, integrity of usage), and data storage (on- and off-site recording and storage policies).
The deck sequences them into a staged roadmap, illustrated with a retail example:
| Horizon | Moves | Retail illustration |
|---|
| 3–6 months | Clean, then Police | Remove duplicate products and correct inventory counts; flag missing product codes and reject invalid stock entries. |
| 6–12 months | Analyze, then Update | Identify sales patterns and calculate reorder thresholds; adjust those thresholds as demand changes. |
| 12–18 months | Acquire, then Expose | Add weather and local-event data to improve demand forecasts; share inventory forecasts securely with suppliers to coordinate replenishment. |
Two execution rules attached to the roadmap: treat it as a project (people / process / technology), and establish clear roles and responsibilities with a data leader — a Chief Data Officer.
Memo-ready structure. Clean → Police → Analyze → Update → Acquire → Expose is a sequenced, costed, ownable roadmap. If a Harley alternative or action item needs to be concrete about what happens in what order, this ladder supplies the phasing and the CDO supplies the accountable owner.
Digital Security as a Business Issue
The deck's framing (Austin & Darby, HBR): security breaches affect 90%+ of businesses worldwide, causing billions in damage annually. Digital security means protecting data and technology assets from intruders — hacking, phishing, denial of service and more. And the pointed question the deck asks about executive behaviour: why do executives relegate digital security to the bottom of the list? Its answer is uncomfortable and worth quoting — security requires specialized knowledge and offers little personal payoff; because it is invisible, no one is praised for the breach that never happened.
The guidelines are the classic "CIA" triad:
C
Confidentiality
Limiting information access and disclosure to authorized users, and preventing access by or disclosure to unauthorized ones.
I
Integrity
The trustworthiness of information resources — that data have not been changed inappropriately, whether by accident or deliberately.
A
Availability
Information that is not available when you need it is almost as bad as none at all.
The 5-Whys — Technology Problems Have Business Causes
Toyota's root-cause technique applied to a breach. The deck's worked example is the whole argument of the session in miniature:
Problem: 50,000 files were stolen from the company's systems.
1. Why? The files were accessible to everyone in the company, even guests.
2. Why? The folder's access control list (ACL) was configured incorrectly.
3. Why? An intern configured that server in 2021; it hasn't been reviewed since.
4. Why? We don't have a process to review file-system permissions.
5. Why? Because manually reviewing every folder's ACL is like searching for a needle in a haystack — and there are three of us and one thousand file servers.
Deck slide 36, adapted from GigaOm
Note where the chain lands. It starts at a technical misconfiguration and ends at a resourcing and governance decision — three people for a thousand servers. That is the deck's thesis about security being a business issue, demonstrated rather than asserted. It is also a ready-made template for the NordicWave mini-case.
Building a Cybersecurity Program, and the DRP
Three moves (Updyke, HBR, adapted):
- Establish leadership and understand needs — hire a CISO; review security policies, procedures and protocols; engage departments and leaders on their specific concerns; prepare a disaster recovery plan.
- Develop a plan based on simulations and technologies — design simulations covering a range of breach scenarios, focused on real-world situations employees will actually encounter; engage vendors and implement appropriate technologies.
- Execute an ongoing campaign of training and exercises — invest in employee development, schedule exercises regularly, and debrief each one on what worked and what could improve.
A Disaster Recovery Plan (DRP) — or Business Continuity Plan — is the documented, structured approach for responding to unplanned incidents, safeguarding data, applications and hardware so the organization recovers quickly from cyberattacks, natural disasters or other disruptions. Its four elements on the slide: identification of potential disasters · recovery roles and activities · communications protocols · preventative measures.