Understanding the Four Enterprise Architecture Domains

Hello! In the previous lesson, the library’s goal of reliable cross-branch borrowing showed why a change to software might also require changes to lending rules and records. We now need a way to distinguish those concerns. TOGAF uses four architecture domains—Business, Data, Application, and Technology—to describe different aspects of an enterprise without losing sight of how they work together.

By the end of this lesson, you should be able to hear a proposed change, identify which domain it principally concerns, and explain where it depends on the other three. This is foundational vocabulary for both your initial understanding of TOGAF and later exam preparation.

Four questions about one enterprise

Imagine a reader checking whether a book is available at another library branch. Four different questions immediately arise:

• Business: What service is the library trying to provide, and who is responsible for each part of borrowing?
• Data: What does an “available” record mean, and how is it kept accurate across branches?
• Application: Which software lets readers search and lets staff record loans, and how do those systems interact?
• Technology: What infrastructure allows that software to run and communicate reliably?

These are not four unrelated projects. They are four ways of examining the same service. The distinction is the subject being described, not whether the subject happens to involve a computer.

For a compact introduction to the terminology, watch the domain overview in Topictrick’s TOGAF Architecture Framework | TOGAF Introduction | Kind of Architecture.

The image below offers a visual reminder of the four names and typical concerns.

The blocks look stacked, but do not take that literally. Business work can be performed without an application, data can move between multiple applications, and infrastructure choices can constrain what applications can do. Architecture has to account for those relationships.

What belongs in each domain?

Read the “Architecture Domains in TOGAF” section of Visual Paradigm’s The All-in-One TOGAF Guide. It provides definitions and typical objectives for each domain. Treat the examples that follow in this lesson as a way to test and refine those definitions, rather than memorizing a list of technologies.

A useful shorthand is to ask four questions in order: What does the enterprise do? What information does it need? What applications handle that information and support the work? What technology supports those applications? The shorthand is for classification; it does not imply that architects must work through the domains only once or in a rigid order.

Business Architecture describes the enterprise’s business strategy, governance, organization, and key processes. In the library, it includes the cross-branch borrowing service, the rule that a reader can request an item from another branch, and the responsibilities of branch staff. The architecture describes how the service is intended to operate and support the goal; it does not, by itself, decide what the library’s goal ought to be.

Data Architecture describes the structure of information assets and how they are managed. Here it includes the meaning of an item record, an availability status, and a loan record; where those records originate; and how branches maintain their accuracy. If one branch marks a book “available” when it is reserved while another does not, the problem is partly about the meaning and consistency of data—not merely about the screen displaying it.

Application Architecture describes applications, what they do, how they interact, and how they relate to business processes. The reader-facing catalog, a staff lending application, and the exchange of availability updates between them belong here. An application is more than its visible interface: it may provide services to other applications or carry out rules needed by the borrowing process.

Technology Architecture describes the hardware and software infrastructure needed to support those applications and services. In this example, it might cover branch network connections, hosting infrastructure, and the platform used to run the catalog. An outage caused by an unreliable connection is principally a technology concern, even though readers experience it as a failure of the borrowing service.

“Principal” matters. Connecting applications will also involve data exchanged between them and technology that carries the exchange. The domain label identifies the primary architectural concern; it does not forbid considering consequences elsewhere.

The boundaries are useful precisely because they connect

Suppose the library wants readers to see trustworthy availability information. It would be tempting to label this an Application Architecture issue because readers see the information in the catalog. But work backwards from what “trustworthy” requires.

First, the Business Architecture must make clear when an item can be requested and which branch is responsible for updating its status. The Data Architecture must specify what each status means and how availability information is maintained. The Application Architecture must support staff updates and make the correct information available to the catalog. The Technology Architecture must provide sufficiently reliable operation and connectivity for those updates to reach readers.

If the display is attractive but the status definitions conflict, redesigning the display will not make the information trustworthy. If the definitions and applications are sound but branch connections repeatedly fail, the information may still be stale. This is the value of examining all four domains: each reveals a different possible cause of the same observed problem.

Some terms require care because they can appear in more than one domain. Consider a database. The meaning and organization of loan records are Data Architecture concerns. The application that creates or updates those records is an Application Architecture concern. The database platform and infrastructure on which it operates are Technology Architecture concerns. Likewise, a rule about who may borrow is principally a business rule, while a data rule specifying valid values for a loan status principally concerns data. Ask what decision you are making, rather than classifying by a word alone.

This also prevents a common mistake: Technology Architecture does not mean all technology-related architecture. Applications are software, but their functions and interactions are treated under Application Architecture. Data may be stored digitally, but its structure and management are treated under Data Architecture. Technology Architecture focuses on the underlying capabilities that support their operation.

Key takeaways

The four domains give you a practical way to separate concerns while keeping their dependencies visible. Business addresses goals, organization, responsibilities, and processes; Data addresses information assets and their management; Application addresses software systems and their interactions; and Technology addresses the supporting infrastructure. In a real change initiative, an issue usually has a principal domain and effects across others.

Next, we will step back from these areas of architecture and ask what the TOGAF Standard is for—and what it does not prescribe about an organization’s particular architecture.