What do you think?
Rate this book
Data Management at Scale: Modern Data Architecture with Data Mesh and Data Fabric
As data management continues to evolve rapidly, managing all of your data in a central place, such as a data warehouse, is no longer scalable. Today's world is about quickly turning data into value. This requires a paradigm shift in the way we federate responsibilities, manage data, and make it available to others. With this practical book, you'll learn how to design a next-gen data architecture that takes into account the scale you need for your organization. Executives, architects and engineers, analytics teams, and compliance and governance staff will learn how to build a next-gen data landscape. Author Piethein Strengholt provides blueprints, principles, observations, best practices, and patterns to get you up to speed.
409 pages, Paperback
Published May 16, 2023
14 people are currently reading
68 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 2 of 2 reviews
September 4, 2023
First, let's clear the confusion.
The book says that it's the 2nd edition. It's not. It's not a revised Data Management at Scale: Best Practices for Enterprise Architecture, it's a slightly different book with a different focus.
This book operates on a much more abstract level than the first edition.
What I didn't like about this book is that the author throws in a lot of concepts and ideas without clarifying much what he means and with almost no examples. For instance he starts using the term data product without properly explaining what it is. He gives a handwavy definition of it in Chapter 4, but it doesn't really explain anything. Or maybe I'm too dumb to understand it - that's also a possibility.
Another example is free usage of the word metadata. The problem is - there is a JSON schema and there is EXIF and there is Fileinfo and there is (an example from the book) the description of the flower for a flower auction. Is all of that metadata? Is all of that data? Is all of that parts of the data product? I don't know, and there is no clear answer in the book. It just doesn't go on that lower level to explain it, instead preferring to fly in the clouds.
And that is the biggest problem with it - it's filled with a lot of statements that are kinda hard to criticize because they're so abstract, that anything could pass in them.
Like "the golden source data should not be modified" or "you should standardize the interface specification". This doesn't give the reader new information, this doesn't explain how do you achieve those goals in practice.
All-in-all, the "first edition" book linked in this post seem to be a bit more practical and down to the point and I would recommend reading that one instead.
The book says that it's the 2nd edition. It's not. It's not a revised Data Management at Scale: Best Practices for Enterprise Architecture, it's a slightly different book with a different focus.
This book operates on a much more abstract level than the first edition.
What I didn't like about this book is that the author throws in a lot of concepts and ideas without clarifying much what he means and with almost no examples. For instance he starts using the term data product without properly explaining what it is. He gives a handwavy definition of it in Chapter 4, but it doesn't really explain anything. Or maybe I'm too dumb to understand it - that's also a possibility.
Another example is free usage of the word metadata. The problem is - there is a JSON schema and there is EXIF and there is Fileinfo and there is (an example from the book) the description of the flower for a flower auction. Is all of that metadata? Is all of that data? Is all of that parts of the data product? I don't know, and there is no clear answer in the book. It just doesn't go on that lower level to explain it, instead preferring to fly in the clouds.
And that is the biggest problem with it - it's filled with a lot of statements that are kinda hard to criticize because they're so abstract, that anything could pass in them.
Like "the golden source data should not be modified" or "you should standardize the interface specification". This doesn't give the reader new information, this doesn't explain how do you achieve those goals in practice.
All-in-all, the "first edition" book linked in this post seem to be a bit more practical and down to the point and I would recommend reading that one instead.
January 16, 2024
This book has great strengths and weaknesses to me. But the strong points of it made it very worth it to read it.
The chapter on APIs was in my view the weakest ones, I had the feeling that the Author wasn't that familiar how APIs work. For example, he contrasted SOAP vs. JSON or RPC vs. JSON. That's comparing apples with oranges (or concretely, protocols with serialization formats).
In general, I have the feeling that the author did come up with some vague or unusual definitions, e.g. of SOA, which microservice architecture is just a flavor of. Since the definitions are fuzzy, it's a point you may make, but my impression is that he goes against the overall consensus. That's just one example where I think the author makes up rather unusual definitions or uses terms in a very vague sense. Regarding SOA, the book reads like SOAP is still an up-to-date technology choice :)
But on the other side, the author describes some concepts from DDD very well and makes a lot of very good points and insights. It's clear that the author has a big picture understanding and a lot of personal experience in the field.
With that, I'd definitely recommend reading it, but also read other books on the matter to get a more unbiased view on the topic and the terms.
The chapter on APIs was in my view the weakest ones, I had the feeling that the Author wasn't that familiar how APIs work. For example, he contrasted SOAP vs. JSON or RPC vs. JSON. That's comparing apples with oranges (or concretely, protocols with serialization formats).
In general, I have the feeling that the author did come up with some vague or unusual definitions, e.g. of SOA, which microservice architecture is just a flavor of. Since the definitions are fuzzy, it's a point you may make, but my impression is that he goes against the overall consensus. That's just one example where I think the author makes up rather unusual definitions or uses terms in a very vague sense. Regarding SOA, the book reads like SOAP is still an up-to-date technology choice :)
But on the other side, the author describes some concepts from DDD very well and makes a lot of very good points and insights. It's clear that the author has a big picture understanding and a lot of personal experience in the field.
With that, I'd definitely recommend reading it, but also read other books on the matter to get a more unbiased view on the topic and the terms.
Displaying 1 - 2 of 2 reviews