Enterprise Architecture vs. Solution Architecture, Project Delivery, and IT Operations

Hello again. In the previous lesson, you defined enterprise architecture (EA) as enterprise-level architectural thinking that aligns strategy, capabilities, information, technology, and coordinated change. That definition is broad by design—but it can create a practical question: if EA covers technology and change, where do solution architects, project managers, and IT operations teams fit?

This lesson draws those boundaries without treating them as rigid job-title rules. In real organizations, one person may perform several of these functions, and titles vary. What matters for TOGAF and for workplace practice is the scope of the decision, the time horizon, and the accountability involved.

This lesson: Foundation emphasis, with practical workplace application.
Estimated study time: 40–45 minutes.

---

One transformation, four kinds of work

Consider Northstar Distribution Group’s aim to improve operational visibility, support hybrid work, reduce legacy risk, and adopt Azure and Microsoft 365 in a controlled way.

That one ambition creates several legitimate kinds of work:

• deciding which enterprise capabilities must change, which principles and standards should apply, and what sequence of investments makes sense;
• designing a specific solution, such as a secure warehouse application integration or a Microsoft 365 records-management implementation;
• planning and coordinating the people, budget, suppliers, delivery risks, and schedule for that implementation;
• operating the resulting services reliably once they are live.

These are related, but they are not interchangeable.

A useful way to remember the distinction is:

Discipline or function	Central concern	Typical question
Enterprise architecture	Enterprise coherence and strategic change	“What must change across the enterprise, why, and within what principles and roadmap?”
Solution architecture	A bounded solution or product	“How should this particular capability or system be designed to meet its requirements?”
Project delivery	Coordinating a temporary change effort	“How will we deliver this agreed scope within the required time, cost, and risk constraints?”
IT operations	Reliable ongoing service	“How do we run, support, monitor, secure, and improve the live service?”

The four functions overlap in information and collaboration. They differ in their primary object of attention:

• EA considers the enterprise and its future states.
• Solution architecture considers a defined solution within that enterprise.
• Project delivery considers the work required to deliver a change.
• Operations considers a live service throughout its useful life.

The distinction is not a hierarchy of importance. A transformation fails if any one of these functions is weak. An elegant target architecture that cannot be delivered has little value; a well-managed project that creates an isolated, unsupported system also has little value.

---

Enterprise architecture and solution architecture: breadth versus depth

Enterprise architecture considers the organization as a connected system. Its decisions are usually cross-domain and longer-lived: business capabilities, shared data, application portfolio direction, technology standards, investment priorities, governance, and transition states.

Solution architecture works at a narrower level. It translates a defined set of requirements into a feasible design for a specific solution, product, workload, or implementation increment.

What EA decides

EA does not normally decide the subnet, the precise API payload, or the individual Azure service configuration for every project. It establishes decisions and guardrails that allow many delivery teams to make local decisions without pulling the organization in conflicting directions.

For Northstar, EA-level work might include:

• agreeing that identities are governed through a common enterprise identity approach rather than separate local accounts for each application;
• defining a principle that shared customer and inventory data must have identified owners and authoritative sources;
• setting an integration direction that reduces point-to-point dependencies;
• deciding which legacy applications are candidates to retain, replace, retire, or modernize;
• identifying common Azure and Microsoft 365 foundations that product or project teams should use;
• creating a roadmap that sequences identity improvement, platform foundations, application modernization, and retirement of obsolete infrastructure.

These decisions matter beyond one implementation. They shape the conditions under which many solutions will be designed, delivered, and operated.

What solution architecture decides

A solution architect takes a particular need and creates a design that can actually be built and run. They need to understand functional requirements, non-functional requirements, existing constraints, delivery capabilities, and relevant architectural guardrails.

Suppose Northstar approves a defined initiative: give warehouse supervisors a mobile view of inventory exceptions while protecting customer and stock information. The solution architect might determine:

• the components of the mobile solution and their responsibilities;
• how the solution authenticates users through the enterprise identity platform;
• how it exchanges data with the inventory application;
• which Azure services are appropriate within agreed platform standards;
• how logs, monitoring, backup, access control, and error handling work for this solution;
• how to balance response time, cost, resilience, security, and delivery constraints.

This is architecture—just at a different level of abstraction and scope.

Dimension	Enterprise architecture	Solution architecture
Scope	Multiple business capabilities, systems, teams, and domains	One solution, product, workload, or bounded change
Primary focus	Coherence, strategic alignment, reusable direction, and transition planning	Technical and functional fitness for a defined need
Typical horizon	Multi-year or multi-increment transformation	The lifecycle of a solution or delivery increment
Detail level	Principles, standards, target states, gaps, roadmaps, reference architectures	Components, interfaces, patterns, configurations, and detailed non-functional requirements
Key success test	The enterprise can change coherently and achieve intended outcomes	The specific solution meets its requirements and can be delivered and operated

The boundary is a matter of scope, not merely how technical a decision appears. A hybrid identity pattern that affects every business unit is likely enterprise or platform architecture. The detailed authentication configuration for one warehouse application is solution architecture.

Architecture is a conversation, not a one-way handoff

It would be a mistake to think EA issues standards and solution architects simply comply without discussion. A solution team may discover that an enterprise standard cannot meet a valid requirement, such as a regulatory need, a latency requirement, or a vendor limitation.

A healthy architecture relationship works through four responsibilities:

1. EA establishes direction through principles, target architecture, roadmaps, and governance.
2. Solution architecture designs within that direction, making justified technical choices for a specific scope.
3. Solution architects raise exceptions or gaps when the guardrails are inadequate or conflict with real requirements.
4. EA evaluates the implication: uphold the standard, grant a time-bound exception, revise the standard, or initiate broader architecture work.

This feedback loop keeps EA connected to delivery reality while preventing every project from inventing its own enterprise standards.

---

Enterprise architecture and project delivery: direction versus execution

A project is a temporary endeavor organized to create a defined result. Project delivery manages the work: scope, schedule, cost, resources, risks, dependencies, communications, procurement, quality, and implementation coordination.

Project delivery answers questions such as:

• What work must be completed, by whom, and by when?
• What is the approved scope and budget?
• Which risks, issues, and dependencies threaten delivery?
• How will the project coordinate business stakeholders, suppliers, engineers, security teams, and operational teams?
• Has the agreed outcome been delivered and accepted?

These questions are essential, but they are different from EA questions.

For example, an EA roadmap might identify that Northstar needs a common identity foundation before several application modernization efforts can proceed. A project manager may then lead an identity modernization project. The project manager coordinates delivery; the enterprise architecture work establishes why the initiative matters, how it fits the broader transformation, and what architectural outcomes it must support.

A project plan is not an architecture roadmap

Both plans contain dates, milestones, and dependencies, so they can be confused.

Artifact	Main purpose	Typical level
Architecture Roadmap	Shows the sequence of enterprise changes, transition states, and expected outcomes needed to reach the target architecture	Portfolio and transformation level
Project plan	Organizes tasks, people, schedule, cost, risks, and delivery controls for a defined initiative	Project or delivery level

An architecture roadmap might state that Northstar will establish secure hybrid foundations first, then modernize priority applications, then retire selected legacy services once dependencies are removed. It is concerned with what must change and in what architectural sequence.

A project plan might show that a specific identity project has discovery workshops, license procurement, pilot deployment, migration waves, training, cutover, and hypercare. It is concerned with how a particular initiative will be managed and delivered.

In Agile or product-based organizations, this distinction remains. The project plan may be replaced or supplemented by product backlogs, release plans, objectives, and quarterly planning. EA still provides the cross-product direction, constraints, standards, and transformation logic.

EA informs delivery; it does not manage every delivery task

TOGAF includes architecture work that supports implementation and change. This can include implementation governance, compliance assessment, architecture contracts, and responding to change requests. Therefore, EA is not finished when a target diagram is approved.

However, EA implementation governance is not the same as managing the entire project. An architect might review whether a proposed design meets agreed identity, security, integration, and data requirements. The project manager remains accountable for managing the delivery effort itself.

A concise division of responsibility is:

• EA: “This initiative must meet these enterprise requirements and contribute to this transition architecture.”
• Solution architecture: “Here is the solution design that meets those requirements.”
• Project delivery: “Here is how the agreed design will be delivered, controlled, and communicated.”

---

Enterprise architecture and IT operations: change design versus reliable service

IT operations is the ongoing work of running live services. It includes activities such as monitoring, incident response, access administration, patching, backup and recovery, capacity management, service requests, operational documentation, and continual service improvement.

With experience in server management and Microsoft 365 administration, you will recognize that operations has a direct view of reality. Operations teams know:

• which services are genuinely critical;
• where manual workarounds exist;
• which dependencies are poorly documented;
• which alerts are noisy or ineffective;
• which backup or recovery assumptions fail in practice;
• which changes repeatedly create incidents;
• where support, security, or cost pressures are growing.

This makes operational evidence essential input to EA. Architecture that ignores live-service realities becomes theoretical; operations that ignores architectural direction can preserve an increasingly fragile status quo.

Different accountabilities, shared consequences

Suppose Northstar’s on-premises file servers contain uncontrolled copies of sensitive customer information. The issue spans all four functions:

Function	Contribution to the issue
Enterprise architecture	Defines the target information-governance direction, identifies business and compliance implications, and sequences changes across data, collaboration, security, and technology domains.
Solution architecture	Designs a particular controlled collaboration or document-management solution, including migration, access, retention, integration, and security patterns.
Project delivery	Coordinates the migration effort, training, communications, budget, cutover activities, and delivery risks.
IT operations	Operates the live environment, handles access and incidents, monitors service health, manages backup and recovery, and provides evidence about operational performance.

Notice that the same situation is not “owned” by one discipline alone. Each makes a different contribution.

EA should incorporate operational needs into architecture requirements. A target Azure or Microsoft 365 environment is incomplete if it specifies capabilities but ignores operational responsibilities, observability, backup, recovery, support processes, security monitoring, and ownership.

Conversely, operations should not be asked to decide enterprise priorities alone. An operations team may correctly identify that a server estate is difficult to patch, but EA helps assess broader questions: should the workloads be moved, modernized, replaced, retained temporarily, or retired? What business capabilities and dependencies would each option affect? Which change sequence minimizes enterprise risk?

---

Architecture capability can be organized in different ways

These functions do not have to be represented by four separate departments. Organizations choose operating models based on their size, maturity, culture, and transformation needs.

In the decentralized model, business units may each plan and build their own solutions. This can provide responsiveness, but it risks duplicated applications, inconsistent security, fragmented data, and what the image labels “shadow IT” unless there are effective shared standards.

In the centralized model, planning, building, and running may be managed primarily through a central IT organization. This can improve standardization and operational control, but it can also become distant from business outcomes if decision-making is slow or overly technology-led.

In the business-outcome-aligned model, cross-functional product lines contain planning, building, and running capabilities closer to the business outcomes they support. Shared digital platforms, applications, infrastructure, data, integration, and tooling provide common foundations underneath them.

For TOGAF purposes, the key point is this:

Enterprise architecture is an enterprise capability and decision discipline, not necessarily a department named “Enterprise Architecture.”

An EA capability may be centralized, federated across business units, embedded in product teams, or supported by a small architecture practice. Regardless of its structure, it needs clear authority over enterprise-wide concerns such as principles, standards, exceptions, roadmaps, and cross-domain trade-offs.

---

A practical classification test

When you encounter an activity, do not classify it by the job title of the person performing it. Classify it by its purpose.

If the activity mainly concerns…	It is primarily…
Business outcomes, cross-enterprise capability gaps, target states, principles, standards, portfolio dependencies, or transition roadmaps	Enterprise architecture
A particular workload’s components, interfaces, security design, detailed technology choices, and non-functional requirements	Solution architecture
Scope coordination, delivery schedule, budget, resourcing, stakeholder communications, risks, or implementation tracking	Project delivery
Incidents, requests, monitoring, patching, backup, operational readiness, service levels, and continual improvement	IT operations

Some activities remain shared. For example:

• A security requirement might originate as an EA principle, be detailed by a solution architect, planned by a project team, and enforced by operations.
• A service outage might be handled by operations, reveal a design weakness for solution architecture, and expose an enterprise-wide resilience gap that EA must address.
• A project may deliver one roadmap work package, but the roadmap itself usually considers dependencies and outcomes beyond that project.

The goal is not to erect walls. It is to make sure each concern receives the appropriate type of decision-making.

---

Foundation-level exam distinctions

In a TOGAF Foundation-style question, look for the wording that reveals the scope.

Wording in a scenario	Most likely focus
“Define common standards across the organization”	Enterprise architecture
“Create a target-state roadmap across applications and infrastructure”	Enterprise architecture
“Select the detailed integration pattern for a customer portal”	Solution architecture
“Manage a migration schedule, project risks, and supplier dependencies”	Project delivery
“Restore a failed service and improve monitoring coverage”	IT operations
“Check whether a proposed design conforms to approved architectural requirements”	Architecture governance, which connects EA with delivery

Two common distractors deserve special attention:

1. “EA is a project-management method.”
   Incorrect. EA informs and governs change, but project management manages the delivery work itself.

2. “EA is IT operations at a strategic level.”
   Incorrect. EA considers how services should evolve and fit together to achieve enterprise outcomes; operations runs and improves the live services day to day.

---

Key takeaways

Enterprise architecture, solution architecture, project delivery, and IT operations are complementary functions with different primary concerns.

• Enterprise architecture creates enterprise-wide direction: target states, principles, standards, trade-offs, and transformation roadmaps.
• Solution architecture designs a specific solution in enough detail to meet requirements within enterprise guardrails.
• Project delivery coordinates the temporary work of implementing an agreed change.
• IT operations runs, supports, secures, and improves live services over time.

In practice, their boundaries are defined by scope, time horizon, decision type, and accountability, not by job title alone. Effective architecture depends on a continuous relationship among them: enterprise direction must guide delivery, solution designs must be feasible, delivery must be controlled, and operational evidence must improve future architecture decisions.

Next, you will examine how enterprise architecture connects business strategy to organizational and technology change—the central reason EA exists in the first place.