Distinguishing Enterprise Architecture Domains

Welcome back. In the previous lesson, you saw how enterprise architecture connects strategic intent to coordinated organizational and technology change. We used Northstar Distribution Group’s hybrid-cloud transformation to show that Azure and Microsoft 365 are enablers, not the transformation’s purpose.

That broad view now needs structure. TOGAF distinguishes four architecture domains so that an architect can examine the enterprise from complementary perspectives: Business, Data, Application, and Technology Architecture, often remembered as BDAT. The objective is not to create four disconnected sets of diagrams. It is to make sure a business change is supported by appropriate information, applications, and technology—and that technical decisions remain connected to business outcomes.

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

---

Four domains, one enterprise change

A transformation initiative can look deceptively simple when described as a technology project:

“Move the legacy inventory platform to Azure.”

But that sentence leaves several architectural questions unanswered:

• What business outcome is the change meant to improve?
• Which processes, roles, and decision rights will change?
• Which inventory, product, customer, and order data must remain accurate?
• Which applications exchange that information?
• What identity, connectivity, resilience, security, and operational services will support the new environment?

The four domains organize those questions.

The diagram below is a useful memory aid for the four domains.

The pyramid can be helpful, but it can also create a misleading impression. BDAT is not a one-way waterfall. Business direction gives change its purpose, but constraints and evidence from data, applications, and technology also influence what is feasible. For example, a business ambition to provide real-time inventory visibility may need to be adjusted when the current applications cannot produce reliable data at the required speed.

The domains should therefore be understood as lenses:

Domain	Primary concern	Core question
Business Architecture	Enterprise purpose and operation	What must the organization do, and how must it operate?
Data Architecture	Information assets and their management	What information is needed, trusted, governed, and shared?
Application Architecture	Application services and interactions	Which applications provide needed functionality, and how do they work together?
Technology Architecture	Platforms and technical services	What infrastructure and technology services support the applications and data?

The same transformation will have implications in all four domains. The architectural skill is to distinguish those implications without losing their relationships.

---

Business Architecture: how the enterprise creates and delivers value

Business Architecture describes the enterprise in terms of its business strategy, capabilities, organization, governance, processes, roles, and business services. It is concerned with how the organization operates to achieve its goals.

It answers questions such as:

• Which business capabilities must improve?
• What value does the enterprise provide to customers, partners, or internal users?
• Which processes support that value?
• Which organizational units, roles, and actors perform or govern the work?
• Who can make which decisions?
• What policies, measures, and business outcomes matter?

For Northstar, consider the strategic ambition to improve operational visibility across warehouses. A Business Architecture view might identify:

• a capability for inventory visibility and exception management;
• a target process for detecting and resolving stock discrepancies;
• warehouse supervisors who own local exception resolution;
• a central operations team responsible for enterprise performance reporting;
• measures such as time to identify an exception and percentage of discrepancies resolved within an agreed period.

Notice what is not yet specified: the name of a dashboard product, the database technology, or Azure service configuration. Those may become relevant, but they are not the primary Business Architecture decision.

Business process is not the same as application workflow

A common early mistake is to equate a business process with whatever steps happen in an application.

Suppose a warehouse manager approves an inventory adjustment. The business process includes the business purpose, the accountable role, the decision criteria, the approval authority, and the expected outcome. The application may automate some of those steps, but the process exists at the business level.

This distinction matters during transformation. Replacing an application should not automatically preserve the current process. Sometimes the current workflow reflects genuine business needs; sometimes it reflects limitations of a legacy system.

A useful test is:

If the application disappeared tomorrow, could you still describe the required business outcome, roles, policies, and decisions?

If yes, you are probably discussing Business Architecture.

---

Data Architecture: making information meaningful, trusted, and governable

Data Architecture describes the structure, ownership, lifecycle, quality, movement, and management of data assets. It covers both logical data concerns—what information means and how it relates—and physical data concerns such as where information is stored and managed.

It addresses questions such as:

• What are the important data entities?
• What do terms such as “customer,” “inventory available,” or “active order” mean?
• Which source is authoritative for each data entity?
• Who is accountable for data quality?
• How is data classified, retained, protected, shared, and archived?
• Where does a data item originate, and where does it move?

For Northstar, important data entities might include:

• product;
• stock item;
• warehouse location;
• inventory balance;
• customer;
• sales order;
• supplier;
• employee identity;
• collaboration document or record.

A Data Architecture decision might state:

The inventory management service is the authoritative source for inventory balances, while the reporting platform receives governed copies for analysis. Warehouse teams own the timely recording of stock movements; the central operations function owns enterprise definitions and quality standards.

This is a data decision because it defines the meaning, ownership, and management of information. It is not simply a statement about which database happens to hold a table today.

Data Architecture versus Technology Architecture

The boundary between these domains can initially feel unclear because data must be stored on technology.

Compare the following statements:

Statement	Primary domain	Why
“Inventory balance must have one enterprise definition and a named data owner.”	Data	It concerns meaning, accountability, and governance.
“Inventory records must be retained for seven years.”	Data	It concerns lifecycle and information-management policy.
“The data platform must encrypt stored data and use managed backups.”	Technology, with Data input	It specifies technical controls that protect data.
“Use a managed relational database platform with geo-redundant backup.”	Technology	It selects a platform service and resilience approach.

In real architecture work, a decision often touches multiple domains. The objective is not to force it into one box permanently. Instead, identify the primary concern and record the cross-domain dependencies.

For example, a retention policy is a Data Architecture concern, but it creates Technology Architecture requirements for storage, backup, deletion, and legal hold capabilities.

---

Application Architecture: the systems and services that support the business

Application Architecture describes the applications, application services, interfaces, interactions, and significant dependencies that support business processes and manage information.

It answers questions such as:

• Which applications support a business capability?
• What application services does each application provide?
• Which applications must exchange information?
• Which integrations, interfaces, APIs, or events are needed?
• Which applications are duplicated, obsolete, strategically important, or candidates for retirement?
• What are the major dependencies between applications?

For Northstar, an Application Architecture view could include:

• an inventory management application;
• an enterprise resource planning application;
• a warehouse mobility application;
• a reporting and analytics application;
• an integration service connecting inventory and order information;
• Microsoft Teams and SharePoint services supporting controlled collaboration;
• a legacy application with several undocumented interfaces.

An application architecture decision might be:

The target inventory visibility capability will use a shared integration service to publish approved inventory events to reporting and order-management applications, rather than requiring every consuming application to directly connect to the inventory database.

That is an Application Architecture decision because it concerns application responsibilities and interactions. It influences data quality and technology choices, but its central subject is how applications collaborate.

Application Architecture versus Data Architecture

The distinction is especially important in integration work.

• Data Architecture asks: What does “available inventory” mean? Who owns it? Which source is authoritative? How long is the information retained?
• Application Architecture asks: Which application provides inventory availability? Which systems consume it? Does the interaction use an API, an event, a file exchange, or a managed integration service?

The same item of information appears in both views, but for different reasons.

A practical way to separate them is to ask whether the main decision concerns:

• the information itself: its definition, quality, ownership, lifecycle, classification, or lineage; or
• the system behavior: which application provides, consumes, transforms, or exchanges that information.

The first is primarily Data Architecture. The second is primarily Application Architecture.

---

Technology Architecture: the technical foundation for applications and information

Technology Architecture describes the technical services, platforms, infrastructure, networks, environments, and standards needed to support applications and data.

It includes more than physical servers. In a hybrid-cloud environment, it may cover:

• compute, storage, and database platform services;
• network connectivity and segmentation;
• cloud landing-zone foundations;
• identity and access technology;
• endpoint and device management;
• security monitoring and logging;
• backup, recovery, and disaster-recovery services;
• operating systems, runtimes, middleware, and container platforms;
• technology standards, product lifecycle, and operational support arrangements.

For Northstar, Technology Architecture may define:

• Azure platform foundations for approved workloads;
• secure connectivity between on-premises sites and Azure;
• identity integration across Microsoft 365, Azure, and legacy applications;
• logging and monitoring standards;
• resilience requirements for services that support warehouse operations;
• technical patterns for integration, backup, and recovery.

A Technology Architecture decision could state:

Workloads containing operationally critical inventory data must use approved Azure hosting patterns, centralized identity controls, monitored connectivity, managed backup, and tested recovery procedures.

This statement still reflects business and data concerns, but it translates them into a technical foundation that delivery and operations teams can implement and run.

Technology Architecture is not just “the infrastructure team’s diagram”

An infrastructure diagram can be a Technology Architecture artifact, but Technology Architecture has an enterprise purpose. It explains which technical capabilities and standards are needed to support the target business, data, and application architectures.

For example, a server-management perspective might focus on patching, capacity, monitoring, backup jobs, and incident resolution for a specific environment. Those are essential operational activities.

Technology Architecture works at a broader decision level:

• Which hosting patterns are approved for different workload types?
• Which identity model is required across cloud and on-premises environments?
• Which applications may use a given platform?
• What resilience standard applies to business-critical services?
• Which technology products should be standardized, modernized, tolerated temporarily, or retired?

Operations provides vital evidence to architecture: recurring incidents, capacity constraints, unsupported systems, recovery failures, and maintenance cost often reveal gaps in the target technology design.

---

Seeing one transformation through all four domains

Consider Northstar’s goal: enable secure hybrid work while improving the governance of enterprise information.

The goal may result in a Microsoft 365 initiative, but describing it only as “deploy Microsoft 365” is insufficient. The following view shows how each domain contributes.

Domain	Questions for Northstar	Illustrative architecture content
Business	Which collaboration practices need to change? Who approves external sharing? Who is accountable for records?	Collaboration and records-management capabilities; roles for content owners and support teams; governance decisions; user adoption measures
Data	Which documents contain sensitive information? What labels, retention rules, and ownership are required?	Information classification model; data ownership; retention categories; requirements for handling sensitive information
Application	Which collaboration applications will be used? How will they relate to line-of-business applications and document repositories?	Teams and SharePoint application-service roles; integration needs; application portfolio decisions; approved patterns for document access
Technology	What identity, endpoint, network, security, monitoring, and recovery services are needed?	Identity controls; device management; secure connectivity; audit logging; technical configuration standards; resilience arrangements

This is why an architect should resist statements such as “Microsoft 365 is an application” or “Microsoft 365 is infrastructure” without context. A cloud service can be discussed in more than one domain depending on the decision being made.

For instance:

• If the question is how employees collaborate and which application services they use, the discussion is mainly Application Architecture.
• If the question is how information is classified, retained, or owned within those services, the discussion is mainly Data Architecture.
• If the question is identity, endpoint compliance, audit logging, service availability, or technical integration, the discussion includes Technology Architecture.
• If the question is who may create Teams sites, approve external sharing, or own business records, it is mainly Business Architecture.

The service itself does not determine the domain. The architectural concern determines the domain.

---

The domains are connected, not isolated

A strong architecture description makes relationships between domains explicit. Working in isolated domain silos creates predictable problems:

• A business process changes, but applications still enforce the old workflow.
• An application is modernized, but its data ownership and quality problems remain unresolved.
• A data platform is introduced, but business teams disagree about definitions and accountability.
• A cloud environment is built, but applications were not designed for the required resilience, monitoring, or identity model.
• A project deploys a technically sound service, but no operating model exists to govern it.

For Northstar’s inventory-visibility transformation, the architecture should connect the domains through a coherent set of statements:

1. Business Architecture defines the target capability: timely inventory visibility and accountable exception management.
2. Data Architecture defines trusted inventory measures, ownership, quality rules, and authoritative sources.
3. Application Architecture defines the inventory, order, reporting, and integration services that create and share the information.
4. Technology Architecture defines the hosting, connectivity, identity, monitoring, and resilience services needed to run those applications safely.

A dependency in any one domain can affect the others. For example, if warehouse locations have unreliable connectivity, a Technology Architecture constraint may require an Application Architecture design that supports offline operation and later synchronization. That, in turn, can create Data Architecture requirements for conflict handling and data-quality controls, as well as Business Architecture decisions about how staff resolve discrepancies.

---

How BDAT appears in the ADM

You will study the Architecture Development Method, or ADM, in detail in the next module. For now, recognize this important TOGAF mapping:

ADM phase	Domain focus
Phase B: Business Architecture	Business Architecture
Phase C: Information Systems Architectures	Data Architecture and Application Architecture
Phase D: Technology Architecture	Technology Architecture

The combined term Information Systems Architectures is important for Foundation preparation. It includes both Data Architecture and Application Architecture. It does not mean Technology Architecture.

The phases should not be interpreted as an instruction to complete one domain perfectly before thinking about the next. In practice, architects iterate. A target business capability may suggest application changes; an application limitation may reveal a data issue; a technology constraint may require a revised target process. The ADM provides a disciplined way to manage that interaction.

---

A reliable method for classifying architecture concerns

When a scenario mentions several technologies and business issues at once, use this short classification method.

1. Identify the decision, not merely the noun

Words such as Azure, SharePoint, database, or customer do not automatically determine the domain.

Ask: What decision must be made?

• “Who owns customer information?” is a Data Architecture concern.
• “Which application provides customer-profile services?” is an Application Architecture concern.
• “Which managed database platform hosts customer data?” is a Technology Architecture concern.
• “Which teams are accountable for improving customer onboarding?” is a Business Architecture concern.

2. Identify the primary architectural concern

Look for the central subject:

If the concern is mainly about…	It is likely…
Capabilities, processes, organization, roles, policies, measures, governance	Business Architecture
Data entities, definitions, ownership, quality, classification, lifecycle, movement	Data Architecture
Applications, services, portfolios, interfaces, integrations, dependencies	Application Architecture
Platforms, network, infrastructure, identity technology, hosting, resilience, operations tooling	Technology Architecture

3. Record the cross-domain implications

Avoid declaring that a decision has no effect beyond its primary domain.

For example, implementing centralized identity services is primarily a Technology Architecture initiative. Yet it has:

• Business implications for access-approval responsibilities;
• Data implications for identity attributes and access records;
• Application implications for integration with legacy and cloud applications.

This is the practical difference between merely categorizing work and doing enterprise architecture.

---

Foundation-style recognition cues

In TOGAF examination questions, the domain is usually signaled by the kind of architecture being described.

Wording or emphasis in a scenario	Most likely domain
Business goals, organizational structure, process change, capabilities, governance	Business
Data ownership, information flows, data definitions, authoritative source, retention	Data
Application portfolio, interfaces, application services, integration, software dependencies	Application
Platforms, hardware, cloud services, network, infrastructure, technical standards	Technology

Watch for plausible distractors:

• A business process may be executed through an application, but the process itself belongs to Business Architecture.
• A database stores data, but the logical meaning and ownership of the information are Data Architecture concerns; the database platform is a Technology Architecture concern.
• An API is usually an Application Architecture concern when discussing application interaction, while an API gateway platform is usually Technology Architecture.
• A cloud migration is never solely a Technology Architecture matter if it changes applications, information handling, operating practices, or business capabilities.

---

A workplace habit: build a four-domain change view

For a transformation initiative, create a simple four-row note before discussing solution options. Keep it concise enough to use in meetings.

Domain	Record
Business	Outcome, capability, affected process, accountable roles, governance decisions
Data	Important data entities, ownership, authoritative sources, quality or lifecycle rules
Application	Applications involved, services, integrations, dependencies, portfolio action
Technology	Required platforms, technical standards, security, resilience, operational capabilities

For Northstar’s planned hybrid-cloud transformation, this small view prevents two common failures:

1. treating a technology product choice as the whole transformation; and
2. discovering late in delivery that data ownership, application dependencies, or operating responsibilities were never addressed.

At this stage, do not aim for exhaustive detail. The purpose is to expose the right questions and make missing decisions visible. Later modules will develop each domain into baseline and target architecture artifacts.

---

Key takeaways

TOGAF’s four architecture domains provide distinct but connected perspectives on enterprise change:

• Business Architecture describes business purpose, capabilities, processes, organization, governance, and outcomes.
• Data Architecture describes information assets, their meaning, ownership, movement, quality, lifecycle, and management.
• Application Architecture describes the applications and application services that support the enterprise, including their interactions and dependencies.
• Technology Architecture describes the platforms, infrastructure, technical services, and standards that support applications and data.

The domains are not isolated implementation layers. A transformation should maintain traceability across all four. For Northstar, secure hybrid work and operational visibility require business changes, governed information, coordinated applications, and a resilient Azure and Microsoft 365 technology foundation.

Next, you will use these domains to distinguish baseline, target, and transition architectures—the three architecture states that make transformation planning concrete.