Data Management at Scale, 2nd Edition

Chapter 3. Mapping Domains to a Technology Architecture

Now that you know what data domains are and how to recognize them, it’s time to discuss how to group and manage them together, and how to plot them in a technology architecture. The decomposition of your functional domains and architecture and the alignment between these two is important because there’s a strong correlation between the architecture and how governance standards must be implemented, controls will be set, data products will be managed, and so on.

My experience is that between organizations, there are significant differences in how they decompose and manage their domain architectures. Organizations make trade-offs when designing a large-scale architecture, because it must be shaped to fit their unique organizational requirements and strategy. These trade-offs cover many aspects, such as ownership, organizational size and complexity, security, pace of change, technology, cost management, and cultural and political characteristics. As discussed in Chapter 1, some organizations prefer a high degree of autonomy, while others prefer quality and control. Some organizations have a relatively simple structure, while others are brutally large and complex. It’s not easy to balance all of these requirements, so organizations typically pick a common architectural design that matches most of their requirements to use as a base and build on that. As you’ll see, choosing the right architectural foundation from the start helps ...