Data architecture addresses the data aspects of a system or enterprise. A clean data architecture is one that easy to understand, to implement, and to evolve. To create and maintain a clean data architecture, you must make trade offs between a collection of architectural concerns such as coupling, cohesion, security, scalability, resiliency, and many others.

This article addresses the following topics:

1. Why is clean data architecture important?
2. Architectural concerns for clean data architecture
3. Clean data architecture in context
4. Related resources

1. Why is Clean Data Architecture Important?

There are several reasons why clean data architecture is critical to your success. First, the environment in which we work is constantly changing, and the rate of change is increasing. Clean data architectures enable us to better address and support these changes than architectures that are difficult to understand and work with. Second, the problems that we are taking on are complex and growing in complexity over time. Clean data architectures are better suited to enable us to deal with that complexity that those that are not. Third, we must be able to properly govern our data and data solutions. Clean data architectures better enable us to do so because they are easier to understand, and thus easier to monitor and support.

2. Architectural Concerns for Clean Data Architecture

For our architecture to be clean, what architectural concerns should it potentially address? These concerns, which could be thought of as quality of service (QoS) requirement categories, are overviewed in Figure 1 and explored in greater detail below.

Figure 1. Data architecture concerns.

There are two types of data architecture concerns:

1. Strategic concerns. Strategic concerns focus on aspects that enable the long-term viability of your data architecture.
2. Tactical concerns. Tactical concerns focus on aspects that enable effective implementation of your data architecture.

2.1 Strategic Data Architecture Concerns

Strategic concerns focus on aspects that enable the long-term viability of your data architecture. These strategic concerns are:

• Cohesion
• Consistency
• Coupling
• Domain Driven
• Evolvability
• Flow
• Resiliency
• Scalability

Architectural Concern: Cohesion

TBD

Architectural Concern: Consistency

• ACID (Atomic Consistent Isolated Durable) transactions
• Eventually consistent
• Good enough

Architectural Concern: Coupling

TBD

Architectural Concern: Domain Driven

TBD

Architectural Concern: Evolvability

TBD

Architectural Concern: Flow

TBD

Architectural Concern: Resiliency

TBD

Architectural Concern: Scalability

• Do you need to cluster?
• Support multiple physical locations globally?

2.2 Tactical Data Architecture Concerns

Tactical concerns focus on aspects that enable effective implementation of your data architecture. These tactical concerns are:

• Deployment
• Fit-for-purpose technology
• Integration
• Latency
• Real-time
• Security
• Throughput
• Usage

Architectural Concern: Deployment

TBD

Architectural Concern: Fit-for-purpose technology

• SQL
• Hierarchical
• No-SQL
• Files

Architectural Concern: Integration

TBD

Architectural Concern: Latency

How fast does access need to be?

Architectural Concern: Real-time

TBD

Architectural Concern: Security

• Who should access which data?
• Encryption

Architectural Concern: Throughput

TBD

Architectural Concern: Usage

TBD

3. Clean Data Architecture in Context

The following table summarizes the trade-offs associated with the strategy of having a clean data architecture and provides advice for when (not) to adopt it.

4. Related Resources

• Agile Architecture
• The Agile Data Architect
• Agile Data Architecture
• The Agile Database Techniques Stack
• Data Technical Debt
• Database Design Strategies