Using the Enterprise Continuum to Classify and Communicate Reusable Architecture Assets

Hello. Last lesson, you learned where an architecture team might find descriptions, standards, reference material, and governance records. Finding an asset is only the first step: a team also needs to know what kind of asset it is, how broadly it can be reused, and what adaptation it needs.

This lesson introduces the Enterprise Continuum as a way to classify and communicate those assets. We will use the order-status example from earlier lessons, then look at how an architect might discuss reusable material with another team or a supplier.

A classification, not another storage place

Suppose you find three things that might help with an order-status initiative: a general integration pattern, a retail order model, and a diagram of another enterprise’s order service. All three could be useful, but not in the same way. The pattern may apply widely; the retail model assumes a particular industry; the diagram reflects decisions made for one enterprise.

The Enterprise Continuum gives architects a common way to express such differences. It classifies architecture and solution assets along a broad progression from generic to organization-specific. Think of it as a view or classification of available assets, not a second repository where every asset must be stored. Relevant assets can come from earlier work within the enterprise or from external sources that the enterprise considers for reuse.

Read the overview and reuse discussion in Enterprise Continuum, reproduced by the QualiWare Center of Excellence. This page reproduces earlier-edition TOGAF material: use it to understand the concept, rather than as a definitive source for every current-edition exam term.

The distinction between classifying and storing is useful. The Architecture Repository helps people locate and manage material. The Enterprise Continuum helps them say, for example, “This is a broadly applicable reference pattern” or “This was tailored for a particular enterprise.” That extra context makes an asset easier to assess before adopting it.

It also prevents a common misunderstanding: available for reuse does not mean ready to copy unchanged. An externally published model may need substantial adaptation. An internal architecture may contain a useful pattern but also assumptions that do not hold in a new setting.

From general guidance to a particular enterprise

The image shows the continuum’s organizing idea. Across the top are increasingly specific architectures; across the bottom are increasingly specific solutions. For this lesson, concentrate on the movement from broadly applicable material toward material tailored to particular needs. We will examine the distinction between the two rows closely in the next lesson.

The four labels are classifications of specificity, not four ADM phases or a required sequence that every project must complete:

• A Foundation Architecture provides generic components, relationships, principles, or guidance on which more specific architectures can build.
• A Common Systems Architecture addresses a problem shared across many settings, such as identity management or networking.
• An Industry Architecture brings in requirements and concepts particular to an industry.
• An Organization-Specific Architecture addresses the requirements and circumstances of a particular enterprise.

Read the descriptions behind these labels. Notice especially the source’s warning that the four illustrated types are not fixed stages in a process.

Now apply the classification to our continuing example. A team designing order-status information might draw on general architectural guidance for connecting systems. It might reuse a common systems architecture for controlling access to services. A retail industry model could supply concepts for orders and fulfillment. The team’s organization-specific architecture would then describe how its portal, order service, data, and operating processes should work together.

The point is not that every decision must pass through all four categories. An organization-specific design might draw directly on a common systems pattern without using an industry architecture. Nor does “farther toward organization-specific” mean “better”: it means more dependent on a particular context. The classification helps the team see which assumptions it can retain and which it must reconsider.

Reuse works only when people understand what is being reused

Imagine an architect asks a supplier for a “reusable order solution.” The supplier offers a packaged product suitable for many retailers. The architect, however, is looking for an architecture model that explains order states and their relationships, so the team can evaluate several possible products. Both parties may reasonably call their material reusable, yet they are discussing different kinds of assets.

The Enterprise Continuum provides vocabulary for making that conversation precise. The architect can clarify whether they mean architecture guidance or a solution, and whether they need something generic, industry-specific, or tailored to the enterprise. This matters within an enterprise too: one team’s detailed design may be a helpful starting point for another team, but its enterprise-specific constraints should not be mistaken for universal rules.

Classification also helps architects discover commonality. If several projects independently design similar access controls, a common systems architecture might capture the shared guidance for future work. Conversely, if a previously tailored approach proves useful more widely, people can identify the reusable part and describe it at a more general level. Reuse therefore involves judgment in both directions: adapting general material for a particular need and recognizing when specific work has broader value.

Read two short passages on adaptation and on the relationship between architectures and solutions. Keep the main question in mind: What would another person need to know to reuse this asset responsibly?

A useful way to describe any candidate asset is to state what it describes, how widely it is intended to apply, and which assumptions must be checked before reuse. “Retail order model” communicates more than “order diagram”; “retail order model adapted to our fulfillment process” communicates more still. The Enterprise Continuum supplies the shared classification that makes such descriptions intelligible across projects and between an enterprise and its suppliers.

Key takeaways

The Enterprise Continuum classifies available architecture and solution assets so people can find opportunities for reuse and communicate their level of generality. Its Foundation, Common Systems, Industry, and Organization-Specific classifications describe a progression from broadly applicable guidance to material tailored to a particular enterprise. They are not compulsory project stages, and an asset’s suitability still depends on its assumptions and the need at hand.

Next, you will separate the two rows shown in the image more carefully: the Architecture Continuum, which classifies architecture assets, and the Solutions Continuum, which classifies assets that realize architectures.