Architecture Problem Statement for the Case-Study Transformation

Welcome back. In the previous lesson, you identified the stakeholders who can authorize, shape, deliver, operate, or be affected by Northstar Distribution Group’s transformation, along with their distinct concerns. You now have the raw material needed to express the transformation challenge in one clear, decision-ready statement.

This lesson develops a concise architecture problem statement for Northstar’s Azure, Microsoft 365, and hybrid-cloud transformation. The aim is not to select detailed technologies or write requirements yet. It is to state, in business-relevant language, what is wrong with the current situation, why it matters now, and what the architecture work must make possible.

Focus: Foundation terminology with workplace application
Estimated study time: 35–45 minutes

---

The role of an architecture problem statement

An architecture problem statement is a short description of the enterprise-level situation that architecture work must address. It turns a collection of drivers, constraints, baseline issues, stakeholder concerns, and intended outcomes into a shared account of the problem.

It should allow a sponsor, operations leader, security lead, or delivery team to agree on three things:

1. Why architecture work is needed
2. What enterprise problem it must address
3. What successful architectural direction must enable

This is especially useful in a transformation such as Northstar’s. “Move to Azure” or “deploy Microsoft 365” might be programme slogans, but neither explains the architecture problem. They prematurely name a solution and leave critical questions unanswered:

• What is failing or becoming unsustainable in the current enterprise?
• Which business activities and stakeholders are exposed?
• Why is change urgent?
• What trade-offs must the architecture help leaders make?
• What must be protected while change occurs?

A meaningful architecture problem statement keeps the focus on the problem space before detailed solution design begins.

For example, compare these two statements:

Weak statement	Why it is weak
“Northstar needs to migrate its systems to Azure.”	It assumes the answer, says nothing about business impact, and does not explain which systems, risks, outcomes, or constraints matter.
“Northstar must modernize IT and improve security.”	It is too broad to guide decisions, scope, or stakeholder alignment.
“Northstar needs secure Microsoft 365 collaboration.”	It identifies one possible need but omits the wider hybrid estate, operational continuity, data issues, and transformation trigger.

A stronger statement describes the underlying situation first. Azure and Microsoft 365 can appear where they are established constraints or strategic directions, but they should not replace the explanation of why the architecture is needed.

TOGAF does not prescribe one mandatory paragraph template called an “architecture problem statement.” In practice, however, this concise statement is a valuable input to the Architecture Vision and later to the Statement of Architecture Work. It gives the engagement a coherent starting point.

---

Four ingredients, written as one argument

A concise statement usually contains four connected ingredients:

Ingredient	What it establishes	Northstar example
Context	The enterprise situation and the trigger for action	A data-center lease is approaching its end while Northstar relies on a mixed on-premises estate.
Core problem	The architecture-level deficiency or gap	Fragmented data, legacy dependencies, and inconsistent controls hinder reliable and governed operation.
Significance	Why the problem matters to the enterprise and its stakeholders	Fulfilment, customer service, cost control, security, compliance, and service continuity are exposed.
Architectural intent	What the architecture work must enable, without designing everything prematurely	A governed, phased hybrid direction that reduces data-center dependency while protecting critical operations.

These are not four unrelated sentences pasted together. They should form one argument:

• Northstar is in a particular context.
• Its current architecture has a particular problem.
• That problem has material consequences.
• Architecture work is needed to establish a viable direction within known constraints.

The following short video places this work in the early Architecture Vision activity. Its most useful point is that stakeholder concerns, project context, drivers, objectives, and high-level requirements need to be connected—not treated as separate lists.

A general writing framework can also be helpful, provided you adapt it to architecture rather than academic research. The following video offers a compact check on whether your statement covers context, issue, relevance, and objectives.

---

Build from evidence, not from a preferred product

A problem statement should be traceable to evidence already gathered. At Northstar, the previous lessons established a sufficiently strong first evidence base.

Evidence category	What Northstar has identified	How it appears in the statement
Drivers	Data-center lease timing, pressure to reduce technology burden, need for better collaboration and more trusted operational information	Explains why action is necessary now
Baseline issues	Fragmented information, legacy application dependencies, mixed hybrid environment, uneven operational and governance practices	Defines the architecture problem
Stakeholder concerns	Warehouse continuity, customer service, cloud cost, secure collaboration, privacy, operational support, auditability	Explains impact and shapes the desired direction
Constraints	Need to sustain live operations, protect information, manage cost, use available skills, and meet applicable obligations	Establishes boundaries for the architecture work
Intended outcomes	Reduced data-center dependency, reliable fulfilment, secure collaboration, improved information use, sustainable hybrid operations	Describes what the architecture must enable

Notice the level of abstraction. The statement does not yet claim that a named warehouse application will be rehosted, replaced, or retired. Nor does it declare a particular Azure service, Microsoft 365 configuration, identity protocol, or migration wave.

Those decisions require baseline investigation and later architecture work. A problem statement should make those future decisions easier by establishing their purpose and boundaries, not make them accidentally in advance.

This distinction is useful:

Artifact or statement	Primary question it answers
Architecture problem statement	What enterprise problem requires architecture work, and why does it matter?
Architecture Vision	What high-level change and value proposition are stakeholders being asked to approve?
Scope statement	What breadth, depth, domains, organizational areas, and time horizon are included or excluded?
Architecture requirement	What specific capability, quality, constraint, or condition must be met?
Solution concept	At a high level, what kinds of solution components or patterns could address the problem?
Statement of Architecture Work	What architecture engagement has been authorized, including scope, governance, deliverables, risks, acceptance approach, and plan?

The Statement of Architecture Work screenshot below makes the separation visible: it includes architecture objectives and a solution concept. Both are useful, but neither is identical to the concise problem statement that justifies the work.

---

Drafting Northstar’s problem statement

A reliable drafting method is to begin with plain evidence statements, then compress and connect them.

For Northstar, the raw material might read as follows:

• The data-center lease creates a time-bound decision about reducing dependency on on-premises infrastructure.
• Warehouse fulfilment and customer service depend on reliable applications, integration, and timely inventory information.
• Fragmented data sources and legacy dependencies make change harder and can reduce trust in information.
• Microsoft 365 collaboration and external sharing need consistent identity, information protection, and governance.
• A hybrid estate must remain secure, supportable, resilient, and affordable during transition.
• Operations, finance, security, data owners, and business leaders have legitimate concerns that may conflict.

That evidence can be formed into this concise draft:

Northstar Distribution Group is approaching the end of its data-center lease while relying on a mixed on-premises estate and inconsistent collaboration practices to support warehouse, customer-service, and corporate operations. Fragmented inventory and supplier information, legacy application dependencies, and uneven identity, security, and operational practices create growing cost, continuity, security, and compliance risks, while limiting reliable information sharing. Northstar therefore needs an enterprise architecture that defines a governed, phased hybrid direction for Azure and Microsoft 365 so that it can reduce data-center dependency while protecting fulfilment, enabling secure collaboration, and meeting agreed cost, resilience, and applicable-obligation constraints.

This is deliberately a short paragraph, not a multi-page business case. It can be read in less than a minute, yet it captures the essential argument.

Why this draft works

The first sentence gives the context and trigger. It identifies the data-center lease and makes clear that Northstar’s existing estate supports critical business operations.

The second sentence identifies the architecture-level problem. It does not blame a single server, application, or team. The issues span information, applications, identity and security, and operational capability. That is an enterprise architecture problem because the concerns cross multiple domains and cannot be resolved responsibly by changing one isolated component.

The third sentence defines the architectural intent. It names the agreed transformation environment—Azure, Microsoft 365, and a phased hybrid direction—while avoiding detailed implementation commitments. It also makes important constraints explicit: fulfilment continuity, secure collaboration, cost, resilience, and applicable obligations.

The statement does not include every stakeholder by name. It does not need to. The stakeholder register remains the detailed source for individual concerns. The problem statement should be short enough to align those stakeholders around one shared challenge.

---

Concision is disciplined omission

A common mistake is to make a problem statement sound comprehensive by adding every known fact. That usually produces an unreadable mixture of assumptions, requirements, scope boundaries, risks, and proposed solutions.

For early architecture work, aim for one paragraph of roughly 60–120 words. The exact word count is less important than the test: can a sponsor understand the problem, urgency, intended direction, and principal constraints without needing an explanatory meeting?

Remove content that belongs elsewhere:

If you find this in the draft	Usually move it to
“Deploy Azure Virtual Desktop for all office staff by September”	Roadmap, work package, or solution design
“The service must achieve 99.9% availability”	Architecture requirement or acceptance criterion
“The architecture engagement includes Finance and Operations but excludes the acquired subsidiary”	Scope statement
“The legacy warehouse system may not support modern authentication”	Assumption, risk, or baseline assessment finding
“Azure is preferred because Northstar has Microsoft licensing and administrator skills”	Rationale, constraint, or option evaluation
“The transformation will create a cloud center of excellence”	Target operating model or governance design

The following screenshot shows why that separation matters. Risks, assumptions, acceptance criteria, and ownership are essential for managing architecture work, but they should not be crammed into the problem statement itself.

---

A practical quality check

Before using a draft in a stakeholder discussion, test it against six questions:

1. Enterprise-specific: Could the statement apply to almost any organization? If so, add meaningful context such as the operating model, transformation trigger, or critical business activities.

2. Problem-focused: Does it state a deficiency in the current architecture, rather than merely announcing a technology programme?

3. Consequences visible: Does it explain why the issue matters to business outcomes, risk exposure, service continuity, cost, or obligations?

4. Stakeholder-aware: Does it reflect the concerns of more than one function? Northstar’s statement should not be written only from the platform team’s viewpoint.

5. Outcome-oriented: Does it say what the architecture must enable, without mistaking a detailed technical design for an outcome?

6. Bounded: Does it recognize material constraints—such as continuity, time, cost, security, resilience, and regulatory obligations—without becoming a requirements catalogue?

One final discipline is important in workplace use: separate known facts from assumptions to validate. For instance, it may be established that the lease has an expiry date, but the migration suitability of a particular legacy application may still require analysis. The problem statement can refer to “legacy application dependencies” without pretending that every dependency is already understood.

This makes the statement credible. It frames the need for architecture work precisely because some critical answers are not yet available.

---

Key takeaways

• An architecture problem statement is a concise, evidence-based account of the enterprise situation architecture work must address.
• It connects context, the core architecture problem, business significance, and high-level architectural intent.
• It should be solution-aware but not solution-prescriptive: Azure and Microsoft 365 may be part of Northstar’s strategic direction, but the statement must still explain the underlying enterprise problem.
• It is distinct from an Architecture Vision, scope statement, requirement, solution concept, and Statement of Architecture Work.
• Northstar’s statement centers on data-center dependency, fragmented information, legacy dependencies, inconsistent governance and operations, and the need to protect business continuity while evolving toward a governed hybrid environment.
• A strong statement is short enough to align stakeholders, but specific enough to guide later architecture decisions and traceability.

This completes the first module’s transformation case foundation. Next, you will move into the TOGAF Standard itself: its Fundamental Content, Series Guides, and the wider TOGAF Library.