Enterprise and Enterprise Architecture in TOGAF

Hello! This course begins with the vocabulary behind TOGAF, then builds toward the Architecture Development Method and, later, Foundation and Practitioner exam practice. No prior enterprise architecture experience is needed. Today’s aim is precise but foundational: understand what counts as an enterprise and what its architecture describes. Keep one distinction in mind throughout: the enterprise is the thing being considered; enterprise architecture describes its structure and guides its evolution.

What counts as an enterprise?

In the TOGAF context, an enterprise is any collection of organizations with a common set of goals. That collection might be a whole organization, a division, or a single department. It could also span several organizations working toward shared goals. “Enterprise” therefore does not simply mean “large company.”

Consider a library system whose branches share a goal of making materials available to readers. The entire system could be the enterprise for one architecture effort. For a narrower effort, the lending service across those branches could be the focus. If several otherwise independent library systems jointly operate a shared catalog, their collaboration might be treated as the enterprise for an effort concerning that catalog.

The important question is what is in scope for the goals being addressed. A legal boundary, such as the edge of one company, does not always give the most useful answer. Nor does everything connected to an organization automatically belong inside the chosen enterprise. Architects need to state the boundary clearly so that people know whose operations, responsibilities, and systems the architecture covers.

Dr. Raj Ramesh’s short explanation introduces both the structural idea of enterprise architecture and the range of organizations to which it can apply:

What does enterprise architecture describe?

Once an enterprise and its scope are clear, its enterprise architecture describes the significant elements of that enterprise and how they fit together. In TOGAF’s treatment of architecture, three ideas matter particularly:

1. Components: What are the important parts?
2. Relationships: How do those parts interact or depend on one another?
3. Principles and guidelines: What should govern their design and evolution over time?

For the library system, components might include its lending service, staff responsibilities, rules for borrowing, information about items and borrowers, software used to manage loans, and the technology supporting that software. Listing these components is a start, but it is not yet a useful architecture. The relationships tell a fuller story: staff and readers use the lending service; the software records loans; borrowing rules constrain what the service permits; information must remain consistent across branches.

Principles add guidance for decisions that have not yet been made. For example, a principle that borrowing rules should be applied consistently across branches could affect how a proposed service is designed. It is guidance about the architecture’s evolution, not merely a description of what exists today.

This is why enterprise architecture is more than an IT inventory. A list of applications and servers leaves out the activities they support and the rules that shape their use. It is also more than a high-level organization chart: reporting lines alone cannot show how information and technology support a service. The architecture selects and connects the details needed to understand the enterprise at its chosen scope.

You may hear enterprise architecture used for both the description produced and the ongoing work of developing and using that description. In this lesson, concentrate on what the description captures. TOGAF provides guidance for carrying out the work; TOGAF is not itself the architecture of a particular enterprise.

One enterprise, several possible scopes

Return to the shared library catalog. Suppose its records sometimes disagree with the lending records held by individual branches. Before proposing a fix, an architect must establish the scope.

If the enterprise in scope is one library branch, the architecture may describe that branch’s lending activities and its connection to the shared catalog. If the scope is the whole library system, it must also account for how branches share information and apply common rules. If the scope is a collaboration among independent library systems, it must account for responsibilities and information-sharing across organizational boundaries.

These are not three competing definitions of the word enterprise. They are three choices of boundary for different goals. Each choice changes which components and relationships are important. A description useful for improving one branch’s workflow may be insufficient for deciding how several organizations should keep a catalog consistent.

This also explains why an enterprise architecture is selective rather than an exhaustive account of everything. It needs enough relevant structure and guidance to support the decisions within its scope. It does not need to document every detail of every person’s work.

A concise definition to retain is:

An enterprise is an organization, part of an organization, or collection of organizations considered together because of common goals. Enterprise architecture describes the significant components of that enterprise, their relationships, and the principles and guidelines for their design and evolution.

The definition is easier to use when you keep the two questions separate: Which enterprise, for which goals? and What about its structure and evolution must the architecture make clear?

Looking ahead

You can now distinguish the subject of an architecture—the enterprise—from the description and guidance that make up its architecture. You can also see why stating a boundary matters: the same organization can be examined at different scopes without changing the basic meaning of either term.

Next, we will use these definitions to examine how enterprise architecture supports strategic change and organizational decisions.