DRAFT: Enterprise Architecture Framework

Why This Framework Exists

Every technology solution begins with a need.

A business problem needs to be solved, a service needs to be improved, a regulatory requirement must be satisfied, or a new capability must be delivered.

Over time that need becomes a series of decisions, requirements, implementation approaches, deployments, operational responsibilities, and future changes.

Without a common framework, the reason behind those decisions is quickly lost and teams are left trying to rediscover information that already exists.

The Enterprise Architecture Framework provides a shared way to connect business needs, architecture decisions, implementation approaches, and deployed solutions so people can understand not only what was built, but why.

The Architecture Journey

Need

    ↓

Decision

    ↓

Requirement

    ↓

Implementation

    ↓

Operation

    ↓

Continuous Improvement

Architecture helps move an idea from concept to operation in a consistent and supportable manner.

Architecture Artifacts

Architecture Principles

Architecture Principles define the foundational beliefs that guide decision making across the enterprise.

Architecture Controls

Architecture Controls define stable outcomes that solutions must provide, such as workload isolation, audit logging, role-based access control, network segmentation, encryption, backup protection, or governance inheritance.

Architecture Controls act as a bridge between regulatory requirements and technical implementation. Multiple regulations may map to the same Architecture Control, allowing architecture decisions, standards, patterns, and product to remain consistent even as regulatory requirements evolve. 

Policies

Policies establish organizational expectations and obligations. Within this framework, Policies refer to Academic Policies, Fayetteville Policies and Procedures, and U of A Systemwide Policies. 

Architecture Decision Records

Architecture Decision Records explain why significant architecture decisions were made and provide context for future teams.

Standards

Standards define mandatory requirements that solutions must satisfy.

Patterns

Patterns describe approved implementation approaches for satisfying architecture requirements.

Products

Products represent approved, reusable infrastructure or platform implementations that teams can deploy through approved automation and engineering processes.

Governance and Change Control

Architecture governance is integrated into the existing change control process.

Architecture artifacts, infrastructure products, and significant design changes should be reviewed through established governance processes.

When an approved standard or pattern cannot be followed, the implementation should be documented and reviewed through the appropriate process. In the event that the implementation does not follow the standard literally, it must follow the intent through risk mitigation and compensating controls. 

Traceability

The framework creates a traceable path between organizational needs and deployed technology.

Regulation or Business Need

        ↓

Architecture Control

        ↓

Policy

        ↓

ADR

        ↓

Standard

        ↓

Pattern

        ↓

Product

        ↓

Deployment

        ↓

Operational Evidence

This traceability allows teams to understand how decisions connect to implementations and how implementations connect back to organizational requirements.

The Desired Outcome

The goal of the Enterprise Architecture Framework is to make technology decisions understandable, consistent, supportable, and traceable.

Success means:

  • Workload owners understand what is required.
  • Engineers know how approved solutions should be implemented.
  • Reviewers understand why decisions were made.
  • Operations teams know what was deployed and who owns it.
  • Architecture remains connected to the solutions running in production.
  • Future teams can build on prior decisions instead of rediscovering them.

Enterprise Architecture is not intended to slow delivery or create additional process. Its purpose is to help the University make consistent decisions, reuse proven approaches, reduce unnecessary complexity, and preserve organizational knowledge over time. When successful, teams spend less time rediscovering answers and more time delivering value.