Muutke küpsiste eelistusi

Data Mesh in Action [Pehme köide]

3.62/5 (39 hinnangut Goodreads-ist)
, ,
  • Formaat: Paperback / softback, 300 pages, kõrgus x laius x paksus: 235x188x20 mm, kaal: 580 g
  • Ilmumisaeg: 24-Jan-2023
  • Kirjastus: Manning Publications
  • ISBN-10: 1633439976
  • ISBN-13: 9781633439979
Teised raamatud teemal:
Data Mesh in ActionSuurem pilt
  • Formaat: Paperback / softback, 300 pages, kõrgus x laius x paksus: 235x188x20 mm, kaal: 580 g
  • Ilmumisaeg: 24-Jan-2023
  • Kirjastus: Manning Publications
  • ISBN-10: 1633439976
  • ISBN-13: 9781633439979
Teised raamatud teemal:
Püsilink: https://www.kriso.ee/db/9781633439979.html
Märksõnad:
Revolutionize the way your organization approaches data with a data mesh! This new decentralized architecture outpaces monolithic lakes and warehouses and can work for a company of any size.

Data Mesh in Action teaches you to establish a data mesh in organizations of any size. The book avoids a dogmatic one-size-fits-all approach and utilizes flexible “sliders” to adjust a data mesh to your company’s specific needs. You’ll learn processes and facilitative leadership techniques that will help change the way your colleagues think about data.

Data Mesh in Action reveals how this groundbreaking architecture looks for both small startups and large enterprises. You’ll see a data mesh in action as you explore both an extended case study and multiple real-world examples. As you go, you’ll be expertly guided through discussions around Socio-Technical Architecture and Domain- Driven Design with the goal of building a sleek data-as-a-product system.

Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications.
Foreword xii
Preface xiv
Acknowledgments xvi
About this book xvii
About the authors xxiv
About the cover illustration xxvi
Part 1 Foundations
1(84)
1 The what and why of the data mesh
3(27)
1.1 Data mesh 101
4(3)
1.2 Why the data mesh?
7(4)
Alternatives
8(1)
Data warehouses and data lakes inside the data mesh
9(1)
Data mesh benefits
10(1)
1.3 Use case: A snow-shoveling business
11(4)
1.4 Data mesh principles
15(9)
Domain-oriented decentralized data ownership and architecture
16(2)
Data as a product
18(2)
Federated computational governance
20(2)
Self-serve data infrastructure as a platform
22(2)
1.5 Back to snow shoveling
24(1)
1.6 Socio-technical architecture
25(2)
Conway's law
25(1)
Team topologies
26(1)
Cognitive load
26(1)
1.7 Data mesh challenges
27(3)
Technological challenges
27(1)
Data management challenges
27(1)
Organizational challenges
28(2)
2 Is a data mesh right for you?
30(26)
2.1 Analyzing data mesh drivers
31(8)
Business drivers
31(2)
Organizational drivers
33(2)
Domain-data drivers
35(1)
Minor organizational drivers
36(2)
Is a data mesh a good fit for me?
38(1)
2.2 Data mesh alternatives and complementary solutions
39(6)
Enterprise data warehouse
39(2)
Data lake
41(1)
Data lakehouse
42(1)
Data fabric
43(1)
Data mesh vs. the rest of the world
44(1)
2.3 Understanding a data mesh implementation effort
45(11)
The data mesh development cycle
45(3)
Development cycle in the shoveling example
48(1)
Enabling the team
49(3)
Development cycle in detail
52(4)
3 Kickstart your data mesh MVP in a month
56(29)
3.1 Getting the lay of the land
57(6)
Drawing a system landscape diagram
58(2)
Performing stakeholder analysis
60(3)
3.2 Identifying candidates for the MVP implementation team
63(6)
Choosing development teams
63(3)
Choosing the cooperation model
66(1)
Choosing a data governance team
66(3)
3.3 Setting up MVP governance
69(3)
Defining data mesh value statement(s)
70(1)
Defining data governance policies
71(1)
Federating data governance
72(1)
3.4 Developing minimal data products
72(8)
Identifying domain-oriented datasets
73(3)
Choosing data product owners
76(1)
Deciding on the minimum viable data product description
77(2)
Developing the simplest tools to expose your data
79(1)
3.5 Setting up the minimal platform
80(5)
Ensuring platform-forced governability
81(1)
Ensuring platform security
82(3)
Part 2 The four principles in practice
85(134)
4 Domain ownership
87(36)
4.1 Capturing and analyzing domains
90(5)
Domain-driven design 101
91(1)
Invite the right people
92(1)
Choose the correct workshop technique
93(2)
4.2 Applying ownership using domain decomposition
95(14)
Domain, subdomain, and business capability
97(3)
Decompose domains using business capability modeling
100(1)
How are domains and business capabilities related to data?
101(5)
Assign responsibilities to the data-product-owning team
104(2)
Choose the right team to own data
106(3)
4.3 Applying ownership using data use cases
109(5)
Data use cases
109(2)
Model and bounded context
111(2)
Setup boundaries of use-case-driven data products
113(1)
Choose the right team to own data
114(1)
4.4 Applying ownership using design heuristics
114(4)
What is a heuristic?
115(1)
Using design heuristics
115(1)
Designing heuristics and possible boundaries
115(3)
4.5 Final landscape: The mesh of interconnected data products
118(5)
Messflix data mesh
118(2)
Data products form a mesh
120(1)
Is it already a data mesh?
121(2)
5 Data as a product
123(40)
5.1 Applying product thinking
124(7)
Product thinking analysis
125(3)
Data product canvas
128(3)
5.2 What is a data product?
131(4)
Data product definition
131(2)
Product, not project
133(1)
What can be a data product?
134(1)
5.3 Data product ownership
135(5)
Data product owner
136(1)
Data product owner responsibilities
137(1)
An Agile DevOps team as a base for data product dev team
138(1)
Data product owner and product owner
139(1)
5.4 Conceptual architecture of a data product
140(6)
External architecture view
140(4)
Internal architecture view
144(2)
5.5 Data product fundamental characteristics
146(6)
Self-described data product
146(1)
Introduction to metadata
147(1)
Metadata as code
147(2)
Data product metadata
149(1)
Domain dataset metadata
150(1)
Other kinds of metadata
151(1)
5.6 Additional data product characteristics: FAIR and immutability
152(5)
Findability
152(2)
Accessibility
154(1)
Interoperable
155(1)
Reusable
156(1)
Immutable
157(1)
5.7 Data contracts and sharing agreements inside the data mesh
157(6)
Data contracts and sharing agreements
159(1)
Implementing data contracts and sharing agreements
160(3)
6 Federated computational governance
163(29)
6.1 Data governance in a nutshell
164(3)
6.2 Benefits of data governance
167(2)
Business value perspective
167(1)
Data usability perspective
168(1)
Data control perspective
168(1)
6.3 Planning data governance outcomes
169(10)
Hierarchy of data governance outcomes
171(1)
Strategic-level outcomes
172(4)
Tactical-level outcomes
176(1)
Implementation-level outcomes
177(2)
6.4 Federating data governance
179(9)
Thinking of data governance in terms of "sliders"
179(1)
Extreme ends of data governance models
180(1)
Federated data governance model
181(6)
Setting-up governance team operations
187(1)
6.5 Making data governance computational
188(4)
Making policies computational
189(1)
Automating policy checks
190(2)
7 The self-serve fata platform
192(27)
7.1 The MVP platform
193(7)
Platform definition
195(2)
Platform thinking
197(3)
7.2 Improvements with X as a service
200(5)
Xas a service explained
201(2)
X as a service applied
203(2)
7.3 Improvements with platform architecture
205(7)
Platform architecture explained
206(2)
Platform architecture applied
208(4)
7.4 Improvements for the data producers
212(7)
Part 3 Infrastructure and technical architecture
219(64)
8 Comparing self-serve data platforms
221(26)
8.1 Data mesh on Google Cloud Platform
223(7)
Self-serve data platform architecture
223(2)
Identifying the components of the platform
225(1)
Identifying the components of the data product
225(2)
`Workflows
227(1)
Variations
227(1)
Relation to data mesh ideas
228(1)
GCP architecture summary
229(1)
8.2 Data mesh on AWS
230(6)
Self-serve data platform architecture
230(2)
Identifying the components of the platform
232(1)
Identifying the components of the data products
232(2)
Workflows
234(1)
Relation to data mesh ideas
234(1)
Variations
235(1)
A WS architecture summary
235(1)
8.3 Data mesh on Databricks
236(5)
Self-serve data platform architecture
236(2)
Identifying the components of the platform
238(1)
Identifying the components of the data product
239(1)
Workflow considerations
240(1)
Variations
240(1)
Databricks architecture summary
240(1)
8.4 Data mesh on Kafka
241(6)
Self-serve data platform architecture
241(2)
Identifying the components
243(1)
Considerations
244(1)
Kafka architecture summary
245(2)
9 Solution architecture design
247(36)
9.1 Capturing and understanding the current state
248(4)
What is software architecture?
248(1)
How to document architecture: The C4 model
249(3)
9.2 Understanding architectural drivers of a data product design
252(7)
Architectural drivers
252(3)
Capturing architectural drivers for a data-product design
255(4)
9.3 Designing the future architecture of a data product and related systems
259(24)
Design session
260(1)
File-based data product: Spreadsheet
260(6)
From monolith and microservice to a data product
266(9)
Exposing data for stream processing and batch processing
275(8)
Appendix A 283(1)
Appendix B 284(1)
Appendix C 285(3)
Appendix D 288(3)
Index 291
Jacek Majchrzak is a hands-on lead architect in the area of drug discovery where he implements the data mesh idea. Jacek is a workshop facilitatorwith a strong focus on domain-driven design, software architecture andsocio-technical systems design.

Dr. Sven Balnojan manages data products and teams by day. At night, he has a passion for diving deep into technology and data-related topics in hisopinionated in-depth newsletter, as well as his blog and various essays.

Dr. Marian Siwiak is a data scientist with a track record of using data knowledge and managerial experience to successfully deliver multimillionIT, scientific and technical projects covering various areas, from lifesciences to robotics.