Agile Data

Clean Data Architecture: Architectural Concerns

Follow @scottwambler on Twitter!

This page is a work in progress.

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.

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:


Architectural Concern: Cohesion

TBD


Architectural Concern: Consistency


Architectural Concern: Coupling

TBD


Architectural Concern: Domain Driven

TBD


Architectural Concern: Evolvability

TBD


Architectural Concern: Flow

TBD


Architectural Concern: Resiliency

TBD


Architectural Concern: Scalability


2.2 Tactical Data Architecture Concerns

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


Architectural Concern: Deployment

TBD


Architectural Concern: Fit-for-purpose technology


Architectural Concern: Integration

TBD


Architectural Concern: Latency

How fast does access need to be?


Architectural Concern: Real-time

TBD


Architectural Concern: Security


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.

Advantages
  • Easier to understand
  • Easier to evolve, thereby enabling agility
  • Easier to validate
Disadvantages
  • Requires investment to keep clean, including in architectural modeling and architectural refactoring
  • Existing legacy architectures often have significant technical debt that needs to be addressed before your architecture is sufficiently clean
When to Adopt This Practice My knee jerk reaction is to say always, but that wouldn't be accurate. Sometimes time is of the essence and it makes sense to accept technical debt now and decide to pay it down in the future. Hopefully that is rare decision that when it is made is a prudent and deliberate one.


4. Related Resources