Data Management at Scale Quotes

“Connascence, in the context of software engineering, refers to the degree of coupling between software components. (Connascence.io hosts a handy reference to the various types of connascence.) Software components are connascent if a change in one would require the other(s) to be modified in order to maintain the overall correctness of the system.”
― Piethein Strengholt, Data Management at Scale: Best Practices for Enterprise Architecture

“One of the patterns from domain-driven design is called bounded context. Bounded contexts are used to set the logical boundaries of a domain’s solution space for better managing complexity. It’s important that teams understand which aspects, including data, they can change on their own and which are shared dependencies for which they need to coordinate with other teams to avoid breaking things. Setting boundaries helps teams and developers manage the dependencies more efficiently.

The logical boundaries are typically explicit and enforced on areas with clear and higher cohesion. These domain dependencies can sit on different levels, such as specific parts of the application, processes, associated database designs, etc. The bounded context, we can conclude, is polymorphic and can be applied to many different viewpoints. Polymorphic means that the bounded context size and shape can vary based on viewpoint and surroundings. This also means you need to be explicit when using a bounded context; otherwise it remains pretty vague.”
― Piethein Strengholt, Data Management at Scale: Best Practices for Enterprise Architecture

“The Scaled Architecture you will discover in this book comes with a large set of data management principles. It requires you, for example, to identify and classify genuine and unique data, fix data quality at the source, administer metadata precisely, and draw boundaries carefully. When enterprises follow these principles, they empower their teams to distribute and use data quickly while staying decoupled. This architecture also comes with a governance model: engineers need to learn how to make good abstractions and data pipelines, while business data owners need to take accountability for their data and its quality, ensuring that the context is clear to everyone.”
― Piethein Strengholt, Data Management at Scale: Best Practices for Enterprise Architecture

“What I envision is an architecture that brings all the data management areas much closer together by providing a consistent view of how to uniformly apply security, governance, master data management, metadata, and data modeling, an architecture that can work using a combination of multiple cloud providers and on-premises platforms but still gives you the control and agility you need. It abstracts complexity for teams by providing domain-agnostic and reusable building blocks but still provides flexibility by providing a combination of different data delivery styles using a mix of technologies.”
― Piethein Strengholt, Data Management at Scale: Best Practices for Enterprise Architecture

“This technical debt (future rework) will cause problems later.”
― Piethein Strengholt, Data Management at Scale: Best Practices for Enterprise Architecture

“The transformation of a monolithic application into a distributed application creates many challenges for data management.”
― Piethein Strengholt, Data Management at Scale: Best Practices for Enterprise Architecture

“For advanced analytics, a well-designed data pipeline is a prerequisite, so a large part of your focus should be on automation. This is also the most difficult work. To be successful, you need to stitch everything together.”
― Piethein Strengholt, Data Management at Scale: Best Practices for Enterprise Architecture