Enterprise Architecture Begins Where Responsibility Is Defined

In previous articles, we examined how ITIL situates asset management within IT services and operations.

That framing is useful. But it leaves a larger question unaddressed: what happens when the same discipline is applied not just to technology components, but to architecture itself?

Architecture determines how technology components are assembled, constrained, and executed, which is to say it determines what digital systems ultimately do.

If assets require disciplined stewardship, architecture cannot be exempt, which means that treating architecture as anything less than an asset discipline is a structural contradiction.

IT Asset Management and the Definition of an Asset

IT Asset Management (ITAM), one of ITIL’s 34 practices, exists to govern assets throughout their lifecycle. The definition it relies on is intentionally broad:

An asset is any financially valuable component that can contribute to the delivery of an IT product or service.

The breadth of that definition is remarkable.

If anything of value that contributes to service delivery qualifies as an asset, then architecture cannot sit outside that boundary. Architecture is a structured composition of value-bearing components.

And if it is a composition of assets, then it is also a structure of defined responsibility.

The Limits of Traditional IT Asset Management

The most typical use for IT Asset Management in technology organizations is focused on physical things such as devices provided for end users, equipment in data centers, and software that runs on those machines.

Any well-run technology organization will track these assets so that they can be effectively and securely managed over time. It’s simple in concept but can, of course, be challenging at scale.

When that discipline stops at physical technology, architecture becomes structurally disconnected from the simple fact that, at some point, the computer is going to do something.

Architecture as a Structured Set of Assets

The most effective way to structure enterprise architecture programs is through an asset-based model.

The concept is straightforward and scalable across large organizations.

But to make this approach practical, architecture assets need to be organized in a consistent and understandable way. This structure is also what makes responsibility assignable.

A Layered Asset Structure for Enterprise Architecture

Governance operates at responsibility boundaries, not at the level of individual components. Layering makes those boundaries visible.

Technology Assets

At the foundation, there are technology assets, which largely align with ITIL-based asset management. They’re primarily hardware and software assets. Service assets (e.g., cloud services, APIs, managed platforms) should also be included at this level, as they increasingly represent core architectural building blocks in modern environments.

Security and Infrastructure Assets

In the middle are security and infrastructure assets. They consist of hardware, software, and service assets aggregated into domains. For example, an image can be considered an infrastructure asset while endpoint protection could be considered a security asset. Each consists of hardware, software, or service assets.

Application and Data Assets

At the top, there are application and data assets, which also consist of hardware, software, and service assets, again, in an aggregated form, and likely infrastructure assets as well.

System Assets

In most modern environments, a top-level system or workload asset is essential.

For example, a workload might consist of a customer-facing application, its supporting data stores, APIs, and the infrastructure it runs on. These types of aggregated assets are especially useful in environments where architectural dependencies (e.g., deployment dependencies, latency sensitivity) are a concern.

Collectively, these assets—system, security, infrastructure, application, and data—are architecture assets: they are composed of, and dependent on, the underlying technology assets, but they represent architectural structures.

Once architecture is understood as a set of managed assets, it becomes governable.

Lifecycle Management and Asset Ownership

As with physical equipment (i.e., hardware assets), each architecture asset is managed over time.

A consistent set of attributes should be maintained, and each asset type is managed according to an appropriate lifecycle, including a systematic approach for policy implementation.

Lifecycle processes define how assets are managed, but ownership determines whether that management is effective.

Why Defined Responsibility Makes Architecture Governable

Every architecture asset must have an assigned owner. The asset owner is the leader who is responsible for the work that is done on the asset (e.g., application development manager, software installation lead).

This ownership-based approach provides the foundation for driving accountability for architecture processes.

But the challenge is rarely understanding the idea of ownership. Applying it effectively in complex organizational structures is the real work.

Aligning Asset Ownership with Organizational Structure

This is where architecture asset management proves its value.

The goal of architecture asset management is to provide a structure and ownership model that reflects how an organization actually governs responsibility for technology, rather than imposing a theoretical structure disconnected from how work actually gets done.

Then, that model is used as a forcing function for the implementation of architecture practices.

But while defining architecture as a structure of owned assets is necessary, that is not sufficient. These assets must also be classified in ways that align to risk, lifecycle, and responsibility in ways that are measurable, and, in many cases, nonnegotiable.

That work begins in the next article, Asset Classification as the Foundation for Enterprise Architecture Governance.

Notes:
1.Image created with OpenAI’s ChatGPT.