This guide is for the engineer, analyst, or technical manager who can already get something working — a notebook model, a clever prompt, a one-off extract — but who wants to build the durable system underneath analytics: the data that feeds it, the architecture that holds it, and the discipline that keeps it honest in production. The through-line follows the corpus's own causal chain. Good data and a fitting model produce good outputs; good integration produces trustworthy data; sound architecture produces reliability and scale; and only requirements tied to a real business objective convert all of that into decisions worth making. You will not find a single 'right answer' here, because the books that grade this work disagree about what the central outcome even is — system quality, predictive accuracy, or business adoption. That disagreement is load-bearing, and the guide maps it so you can choose deliberately for your situation rather than inherit one camp's bias by accident.
Grounded in 16 books, 10 constructs, 8 relationships.
The reader A capable technical practitioner — software or ML engineer, data scientist, or BI lead — who can build a convincing demo but has not yet owned the full system that keeps analytics reliable, trusted, and used.
The external problem. Heterogeneous, inconsistent, siloed data and fast-moving tooling make it hard to move from a model or prompt that works once to a system that performs reliably in production and that the business actually adopts.
The internal problem. They are unsure whether their choices are principled or just lucky, anxious about runaway cost, silent failure, and being blamed when a high-profile effort underdelivers.
The path
- Define the business objective and requirements before touching source data or algorithms.
- Establish training/feed data quality, coverage, and volume as the foundation everything rests on.
- Engineer integration and ETL so heterogeneous sources become consistent, auditable data.
- Make data trustworthy on the five Cs so consumers will rely on outputs built from it.
- Choose model architecture and capacity to fit the problem's structure, not its hype.
- Measure model output quality honestly on data the model has never seen.
- Design the system architecture so it scales and stays reliable under real load and faults.
- Tie outputs back to decisions and ROI, and feed usage signals into the next iteration.
Success. You ship analytics and AI systems that perform reliably in production, deliver information the business trusts and uses, and translate clearly into better decisions and measurable ROI — and you can explain why each choice was made.
At stake. Your model looks great in a notebook but degrades, fails silently, or is quietly ignored; BI lands late and over budget; people route around it with shadow spreadsheets; and nobody can say whether it changed a single decision.
The transformation. From a demo-builder hoping their choices hold up, into a systems builder who reasons about trade-offs across data, model, architecture, and business value — and who shows the work behind every claim.
The model
The outcome: Business Value and Decision Quality
- Training Data Quality, Coverage, and Volume (core) — The accuracy, cleanliness, representativeness, coverage, and quantity of data used to train, fit, or pretrain models and feed analytics.
- Model Architecture and Capacity Choice (core) — Selection of the model's structural backbone, scale/parameter count, inductive biases, and capacity to represent patterns.
- Data Warehouse / System Architecture Design (core) — The chosen structural framework, storage engine, partitioning, replication, and architectural patterns organizing a data or application system.
- Data Integration and ETL Quality (core) — The rigor, robustness, and consistency of extract-transform-load pipelines and integration that combine heterogeneous sources into consistent data.
- Data Quality and Information Trust (core) — The accuracy, consistency, completeness, currency, and conformance of delivered information, and the resulting confidence consumers place in it.
- Requirements and Business Objective Alignment (core) — The clarity of problem/purpose definition and the degree to which design is driven by business needs, objectives, and stakeholder expectations rather than source data.
- Model Output / Predictive Performance (core) — The accuracy and quality of model outputs—predictions, classifications, generations, forecasts—on holdout or production data.
- System Reliability, Safety, and Resilience (core) — The system's continued correct functioning, safety, and resilience at acceptable performance under faults and production load.
- Scalability and Performance (core) — The system's ability to maintain good performance—query speed, throughput, pipeline scale—as load and use cases increase.
- Business Value and Decision Quality (core) — The realized organizational benefit—improved decisions, ROI, competitive advantage, sustainability—from deploying analytics systems.
How they connect:
- Training Data Quality, Coverage, and Volume → produces → Model Output / Predictive Performance
- Model Architecture and Capacity Choice → produces → Model Output / Predictive Performance
- Data Integration and ETL Quality → produces → Data Quality and Information Trust
- Data Quality and Information Trust → enables → Model Output / Predictive Performance
- Data Warehouse / System Architecture Design → enables → Scalability and Performance
- Data Warehouse / System Architecture Design → enables → System Reliability, Safety, and Resilience
- Requirements and Business Objective Alignment → enables → Business Value and Decision Quality
- Model Output / Predictive Performance → produces → Business Value and Decision Quality
What good looks like
- Foundations. You define the business problem before choosing tools, you can clean and partition data honestly, and you evaluate model output on data it has never seen rather than trusting accuracy in development.
- Practitioner. You build integration once and reuse it, you match model architecture and capacity to the problem's structure, and you design for reliability and scale — anticipating faults and load rather than discovering them in incidents.
- Advanced. You run the whole loop: requirements tied to business metrics, trustworthy data, fitting models, observable production systems, and a usage-driven flywheel that improves the data that improves the system — while navigating the corpus's genuine disagreements deliberately.
Requirements and Business Objective Alignment
Foundations
Before any data is pulled or any model is chosen, you have to define the problem: what decision this serves, who the stakeholders are, what 'better' means, and how you will know. The data-mining literature is blunt that most serious failures trace to poor problem understanding rather than poor algorithms. The BI literature reframes the same point organizationally — focus on business needs and value first, technology second — and adds that requirements are not a one-time document but an ongoing negotiation of realistic expectations. Designing Machine Learning Systems sharpens it into a rule: tie ML metrics to business metrics, because a model that improves accuracy without moving a business outcome will be deprioritized or killed. UX Strategy pushes one step further upstream: validate the value proposition with real users before you build, so the requirement itself is evidence-based rather than assumed.
Why it matters. Get this wrong and every downstream investment compounds the error: you clean the wrong data, optimize the wrong metric, and ship something accurate that nobody needed. BI projects famously land late, over budget, and unused not because the technology failed but because the purpose was never pinned down. The cost is not a bad model — it is months of work that moves no decision.
The myth: Requirements come from the source data — start by exploring what's in the warehouse and see what's possible.
The reality: Design should be driven by business needs and stakeholder objectives, not by what the source data happens to contain. Source-driven projects produce technically impressive systems that answer questions nobody asked.
The myth: Once requirements are signed off, they're settled and you can build in peace.
The reality: Requirements and expectation management are continuous. The BI guidance is to set realistic expectations and communicate openly and continuously, using justification, roadmaps, and ongoing dialogue — not a frozen spec.
The myth: A higher accuracy number is self-evidently a better result.
The reality: An accuracy gain that does not move a business metric will be deprioritized or killed. The metric that matters is the one tied to the decision.
How to:
- Write a one-paragraph problem definition naming the decision, the stakeholders, the intended use of results, and the decision context — before choosing any algorithm or schema.
- Translate the business objective into a measurable target and explicitly link your technical metric to it (e.g., forecast error to inventory cost, classification accuracy to fraud caught).
- Build incrementally and iteratively rather than trying to boil the ocean; deliver a thin, usable slice and expand from validated demand.
- Where the problem is a new product or experience, validate the value proposition with real customers through rapid, small experiments before committing build effort.
- Maintain a living roadmap and communicate openly with stakeholders so expectations stay realistic as you learn.
Watch out for:
- Letting the availability of a dataset define the project — the classic source-driven trap that produces unwanted answers.
- Optimizing a metric divorced from any business outcome; if you can't name the decision it changes, you're measuring the wrong thing.
- Treating requirements as a single up-front event rather than an ongoing negotiation, then being blamed when reality diverges from the frozen spec.
- Skipping user validation on the assumption that you already know what people want — assumptions are where BI and UX efforts quietly fail.
Grounded in: Data Mining for Business Analytics: Concepts, Techniques, and Applications; Business Intelligence Guidebook: From Data Integration to Analytics; Designing Machine Learning Systems; The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling; Ux Strategy Levy; Data Warehouse and Data Mining
Training Data Quality, Coverage, and Volume
Foundations
The data you feed a model is the raw material it learns from — and its accuracy, cleanliness, representativeness, coverage, and quantity set a ceiling no architecture can exceed. Across the corpus this is the most consistently cited determinant of output quality. The data-mining tradition emphasizes correctly obtaining, exploring, cleaning, encoding, and normalizing data before modeling, and visualizing it first to catch errors and outliers. AI Engineering offers a sharp correction to the volume reflex: data quality and diversity matter more than quantity — a small, well-curated dataset beats a large noisy one. For foundation models, the relevant 'data' is the pretraining corpus, where diversity means breadth of domains, sampling frequencies, total volume, and the variety of temporal or structural patterns represented. The dimensional-modeling tradition adds a quieter requirement: capture data at the atomic grain, the lowest level of detail, so you retain the ability to answer questions you haven't thought of yet.
Why it matters. A model trained on narrow, dirty, or unrepresentative data fails in exactly the situations you didn't sample — and it fails silently, scoring well on a holdout drawn from the same biased pool. The damage shows up only in production, on the cases your data never covered, which is the most expensive place to discover it.
The myth: More data is always better — collect everything and the model will figure it out.
The reality: Quality and diversity beat quantity. A small, well-curated dataset reliably outperforms a large noisy one; volume without coverage just amplifies bias.
The myth: Training data is a fixed input you collect once and then model.
The reality: AI Engineering treats data as the output of a usage-driven flywheel: production usage generates feedback that improves the training data that improves the model. This is a genuine split in the corpus (see tensions) — most ML books treat data as exogenous; whether yours is depends on whether you can instrument usage.
The myth: You can summarize data at a convenient reporting grain to save space.
The reality: Capture at the atomic grain. Pre-aggregated data forecloses questions you haven't asked yet; the lowest-level detail is what preserves future analytical flexibility.
How to:
- Explore and visualize data before modeling — plot distributions to surface errors, outliers, and missing coverage, and to guide variable selection.
- Audit coverage against the situations the model will actually face in production; deliberately check whether under-represented segments are present at all.
- Curate over collect: invest in cleaning, correct encoding, and normalization rather than chasing raw volume.
- For foundation models, match the pretraining corpus's domains, frequencies, and pattern variety to your target task before trusting it.
- Store at the atomic grain so you can re-derive aggregates and answer new questions without re-extracting.
Watch out for:
- Equating dataset size with dataset quality, then being surprised when a large noisy corpus underperforms a curated one.
- Coverage gaps that holdout evaluation cannot reveal because the holdout shares the same blind spots.
- Aggregating away atomic detail for short-term convenience and permanently losing analytical options.
- Assuming a foundation model's pretraining covered your domain when its corpus may not include your sampling frequency or pattern types.
Grounded in: AI Engineering: Building Applications with Foundation Models; Designing Machine Learning Systems; Data Mining for Business Analytics: Concepts, Techniques, and Applications; Probabilistic Deep Learning with Python, Keras and TensorFlow Probability; Understanding Deep Learning; Time Series Forecasting Using Foundation Models; The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling; Data Warehouse and Data Mining
Data Integration and ETL Quality
Practitioner
Real organizations don't have one clean data source; they have many heterogeneous ones that disagree. Integration and ETL are the discipline of combining them into something consistent. The BI guidance crystallizes the governing principle: do integration once and use it many times — write once, use many — so consistency and productivity are designed in rather than re-invented per report. The data-warehouse literature treats ETL as a first-class engineered subsystem (the Toolkit catalogs 34 distinct subsystems), not a pile of hand-coded extracts. Designing Data-Intensive Applications adds the engineering posture that makes integration evolvable: treat inputs as immutable and outputs as derived data that can be recomputed, decide a total order of writes through a single source of truth, and preserve integrity above timeliness so derived systems stay consistent. The recurring failure mode the BI book names is the 'accidental architecture' — ad hoc extracts accreting until nobody knows which number is right.
Why it matters. When integration is ad hoc, the same metric computes three different ways and the organization loses trust in all of them — the precondition for shadow spreadsheets and stalled adoption. Worse, ad hoc pipelines are unauditable: when a number looks wrong, no one can trace where it came from, so the fix is guesswork and the trust never returns.
The myth: Each report can pull and transform its own data; that's fastest.
The reality: Per-report extracts produce inconsistent numbers and the accidental architecture. Integrate once and reuse the result many times — consistency is the whole point.
The myth: Hand-coded scripts are fine; tooling is overhead.
The reality: The BI tradition argues for tool-based development with standards, reusable components, documentation, and auditability over ad hoc manual coding — because hand-coded extracts can't be reasoned about or trusted at scale.
The myth: Pipelines should mutate data in place to stay current.
The reality: Treat inputs as immutable and outputs as derived. Recomputable, ordered, single-source-of-truth pipelines stay consistent and recoverable; in-place mutation makes errors permanent.
How to:
- Design integration as a shared, reusable layer feeding many consumers — write once, use many — rather than per-report extracts.
- Adopt fit-for-purpose integration tooling and impose standards: reusable components, documentation, and auditability from the start.
- Build incrementally and iteratively; integrate a few high-value sources well before attempting enterprise coverage.
- Treat raw inputs as immutable and your warehouse tables as derived data you can recompute from source.
- Establish a single source of truth and a total order of writes so all downstream derived systems agree.
Watch out for:
- The accidental architecture — uncontrolled growth of ad hoc extracts that quietly destroys consistency.
- Pipelines no one can audit, so a wrong number can't be traced to its origin.
- Mutating source data in place, making errors irreversible and recomputation impossible.
- Trying to integrate the whole enterprise at once instead of delivering reusable slices.
Grounded in: Business Intelligence Guidebook: From Data Integration to Analytics; Data Warehouse and Data Mining; The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling; Designing Data-Intensive Applications
Data Quality and Information Trust
Practitioner
Integration produces data; the question is whether anyone believes it. The BI literature frames information quality on five Cs — clean, consistent, conformed, current, and comprehensive — and treats trust as the outcome that determines whether the data gets used at all. Data quality is the accuracy, consistency, completeness, currency, and conformance of delivered information, and the confidence consumers place in it follows directly from those properties. Metadata management and governance underpin this: lineage and documentation are what let a consumer verify where a number came from and decide to trust it. The LLM-era books add a parallel concern — developer trust in model output — and a hard rule: never blindly trust generated output, validate queries and results before acting, and keep a backup before granting any model write access. Trust, in this corpus, is earned by verifiable provenance and honest validation, not asserted.
Why it matters. Untrusted data is unused data. The moment a stakeholder catches one wrong number with no traceable cause, they revert to their own spreadsheet and the entire system's ROI evaporates — and rebuilding trust costs far more than maintaining it. With LLM outputs the failure is sharper: an unvalidated hallucination propagates straight into a decision.
The myth: Accurate data is automatically trusted data.
The reality: Trust requires the full five Cs plus visible lineage. Data can be accurate today but stale, inconsistent across sources, or unverifiable — and any one of those breaks confidence.
The myth: If the model or pipeline produced it, it's probably right.
The reality: Never blindly trust generated output. Validate LLM-generated queries and results before acting, sample-check accuracy, and back up storage before granting write or delete access.
The myth: Governance and metadata are bureaucratic overhead.
The reality: Effective metadata management underpins data governance, quality, and usability — lineage is precisely what lets a consumer verify a number and choose to rely on it.
How to:
- Define and measure the five Cs explicitly: is the data clean, consistent, conformed across sources, current, and comprehensive?
- Capture lineage and metadata so any delivered number can be traced to its sources and transformations.
- Validate model and pipeline outputs against ground truth on a representative sample before anyone acts on them.
- For LLM-driven analysis, inspect generated queries before execution and keep backups before granting any write or delete access.
- Surface quality status to consumers (freshness, completeness, known gaps) so trust is informed rather than blind.
Watch out for:
- Conflating accuracy with trust — stale or inconsistent-but-accurate data still fails the five Cs.
- Letting one untraceable wrong number drive users back to shadow systems permanently.
- Acting on LLM output without validation, letting a hallucination propagate into a decision.
- Skipping metadata so failures can't be diagnosed and consumers can't verify provenance.
Grounded in: Business Intelligence Guidebook: From Data Integration to Analytics; Data Warehouse and Data Mining; Data Analysis with LLMs; Effective Data Science Infrastructure; AI Engineering: Building Applications with Foundation Models
Model Architecture and Capacity Choice
Practitioner
Architecture is the structural backbone of the model — its scale, parameter count, inductive biases, and capacity to represent patterns. The deep-learning books converge on a principle: architecture should encode inductive biases that match the structure of the problem — locality for images, position-independence for sequences, permutation invariance for tabular or graph data. Capacity is a budget to spend wisely, not maximize: depth is more parameter-efficient than width for many function classes, and residual connections make depth practically trainable. For foundation models, the choice is concretized as architecture type (encoder-decoder, encoder-only, decoder-only, with patching or mixture-of-experts), which determines whether output is autoregressive or single-shot and whether prediction is deterministic or probabilistic — and you select size by available hardware, latency, and storage, not parameter count alone. AI Engineering's governing rule sits above all of this: start simple. Exhaust prompt engineering before RAG, RAG before finetuning, and finetuning before training from scratch. The cheapest adaptation that meets the bar is the right one.
Why it matters. Choosing an architecture that ignores the problem's structure wastes capacity learning what a better inductive bias would have given for free — and reaching for a custom-trained model when a prompt would do burns weeks and budget for no gain. Both directions cost you: under-fit to the problem's structure, or over-build past the simplest thing that works.
The myth: Pick the biggest, most capable model you can afford; capacity solves problems.
The reality: Capacity is a budget. Match inductive bias to problem structure first; an architecture that fits the data's geometry beats raw size, and excess capacity invites overfitting and cost.
The myth: Building a serious AI capability means training or finetuning your own model.
The reality: Start simple. Exhaust prompting before RAG, RAG before finetuning, finetuning before training from scratch — and use the smallest model that reliably solves the task, upgrading only when quality is demonstrably insufficient.
The myth: Parameter count is the headline number for picking a model.
The reality: For foundation models, select size based on hardware, required inference latency, and storage — not solely on parameter count. A model you can't serve at acceptable cost isn't capable for your purpose.
How to:
- Identify the structure of your problem (spatial, sequential, tabular, graph, temporal) and choose biases that match it before considering scale.
- Climb the adaptation ladder deliberately: prompt → RAG → finetune → train, stopping at the first rung that meets the quality bar.
- For generation or forecasting, decide whether you need probabilistic output (full distribution) or a point estimate, and pick an architecture that supports it.
- Size foundation models against your real hardware, latency, and storage constraints, not against benchmark leaderboards.
- Prefer the smallest model that reliably solves the task; upgrade only on demonstrated, measured insufficiency.
Watch out for:
- Reaching for maximum capacity and inviting overfitting and serving cost when a structurally-fitted smaller model would generalize better.
- Skipping straight to finetuning or custom training before exhausting cheaper adaptation.
- Picking a model on parameter count alone and discovering you can't serve it within latency or budget.
- Choosing a deterministic architecture when the task genuinely needs calibrated uncertainty.
Grounded in: AI Engineering: Building Applications with Foundation Models; Data Analysis with LLMs; Probabilistic Deep Learning with Python, Keras and TensorFlow Probability; Understanding Deep Learning; Time Series Forecasting Using Foundation Models; Generative Deep Learning
Model Output / Predictive Performance
Practitioner
Output quality is where data and architecture converge: the accuracy and usefulness of predictions, classifications, generations, or forecasts on data the model has not seen. The single most repeated discipline in the predictive-modeling books is to evaluate on holdout — split into training, validation, and test sets, or cross-validate — because performance measured on training data measures memorization, not capability. Designing Machine Learning Systems adds a leakage-specific rule that catches many practitioners: split by time, not randomly, so the model can't learn from the future. The probabilistic books reframe the metric itself: model outcomes as distributions and use validation negative log-likelihood, so you're scoring calibrated uncertainty, not just point accuracy. AI Engineering's evaluation-driven development closes the loop: define your evaluation criteria and metrics before you build, not after — and match the metric to the task, weighting classes and costs by their real importance. Parsimony is the tiebreaker: simpler models that generalize beat complex models that overfit.
Why it matters. A model that scores well in development and degrades in production is the canonical failure this corpus exists to prevent — and the usual culprit is dishonest evaluation: testing on data the model effectively saw. Believing a leaked or in-distribution score is worse than having no score, because it manufactures confidence right before deployment, where the failure is most costly.
The myth: High accuracy on the data I have means the model works.
The reality: Always evaluate on data the model has not seen. Performance on training data measures memorization; only honest holdout or cross-validation estimates real capability.
The myth: Random train/test splits give an honest estimate.
The reality: For temporal data, random splits leak future information. Split by time so the model is tested only on what comes after what it learned from.
The myth: Decide what to measure after you see what the model can do.
The reality: Evaluation-driven development: define criteria and metrics before building. Choosing the metric after seeing results invites rationalization rather than honest assessment.
How to:
- Hold out a genuine test set (or use cross-validation; for foundation-model forecasting, validate over at least 20+ held-out time steps) and never tune on it.
- Split temporal data by time to prevent leakage from the future.
- Define evaluation criteria and metrics before building, and match the metric to the task — weight classes and costs by real importance, not default accuracy.
- For probabilistic models, use validation negative log-likelihood to score calibrated uncertainty, not just point error.
- Prefer the simpler model when two perform comparably; justify added complexity only with significant, measurable gains.
- Specify output format precisely (especially for LLMs) so outputs are reliably parseable and verifiable downstream.
Watch out for:
- Tuning on the test set, which quietly converts your honest estimate into another training score.
- Random splits on time series that leak the future and inflate measured performance.
- A holdout drawn from the same biased pool as training, hiding coverage gaps until production.
- Optimizing a default metric that doesn't reflect the real costs of the errors you care about.
Grounded in: AI Engineering: Building Applications with Foundation Models; Data Analysis with LLMs; Data Mining for Business Analytics: Concepts, Techniques, and Applications; Designing Machine Learning Systems; Generative Deep Learning; Understanding Deep Learning; Time Series Forecasting Using Foundation Models; Probabilistic Deep Learning with Python, Keras and TensorFlow Probability; Data Warehouse and Data Mining; The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling
Data Warehouse / System Architecture Design
Advanced
Architecture is the structural framework that organizes storage, partitioning, replication, and patterns — and in this corpus it is the enabler of both scale and reliability. The warehouse tradition starts with a stance: data warehouses are subject-oriented, integrated, time-variant, and non-volatile, and analytical processing (OLAP) should be separated from transactional (OLTP). Dimensional modeling supplies the discipline that keeps analytic schemas usable — declare the grain so a measurement event maps one-to-one to a fact row, use surrogate keys, populate verbose descriptive attributes, and conform dimensions across processes. Designing Data-Intensive Applications generalizes the choices: data model and encoding, storage engine, replication, and partitioning are each deliberate trade-offs, and the meta-principle is to design for evolvability — abstraction, schema evolution, loose coupling, and backward/forward compatibility so old and new code coexist during rolling upgrades. Architecture Patterns adds the software-design lever the model-centric books omit entirely: keep the domain model free of infrastructure (persistence ignorance), let behavior drive storage rather than the reverse, and depend on abstractions so the system stays testable and changeable. Effective Data Science Infrastructure frames the goal humanely: make possible things easy, and minimize incidental complexity.
Why it matters. Architecture decisions are the ones you can't cheaply reverse. A schema that ignores grain, a storage engine mismatched to the workload, or a domain model fused to its database produces a system that resists every later change — and the cost surfaces as buckling under load, silent inconsistency, or a codebase nobody can safely evolve. This is the layer where the ML books fall silent and the systems books carry the weight.
The myth: Run analytics against the transactional database to keep things simple.
The reality: Separate OLAP from OLTP. Analytic and transactional workloads have opposing access patterns; mixing them degrades both.
The myth: Design the database schema first, then write code against it.
The reality: Behavior should come first and drive storage requirements, not the other way around. Let the domain model lead and keep it free of infrastructure dependencies.
The myth: Pick the architecture that's optimal for today's requirements.
The reality: Design for evolvability. Abstraction, schema evolution, and loose coupling matter more than point-in-time optimality, because requirements and tools will change underneath you.
How to:
- Separate analytical from transactional processing and organize the warehouse around subjects, integration, time-variance, and non-volatility.
- Apply dimensional discipline: declare the grain, use surrogate keys, write verbose descriptive attributes, avoid null foreign keys, and conform dimensions across processes via a bus matrix.
- Choose data model, encoding, storage engine, replication, and partitioning as explicit trade-offs against your real workload, not defaults.
- Maintain backward and forward compatibility so old and new code and data coexist during rolling upgrades.
- Keep the domain model persistence-ignorant and let behavior drive storage; depend on abstractions so components stay testable and swappable.
- Make possible things easy and add complexity only in proportion to the problem's inherent complexity.
Watch out for:
- Fusing the domain model to the database, so every behavior change forces a storage change and tests stay slow and fragile.
- Skipping grain declaration, which produces fact tables that can't be aggregated or trusted.
- Optimizing for today and creating a rigid system that resists the next requirement.
- Incidental complexity — accidental coupling and tooling that adds difficulty beyond the problem's inherent difficulty.
Grounded in: Data Warehouse and Data Mining; Business Intelligence Guidebook: From Data Integration to Analytics; Designing Data-Intensive Applications; Designing Machine Learning Systems; Effective Data Science Infrastructure; Architecture Patterns with Python; The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling
Scalability and Performance
Advanced
Scalability is the system's ability to hold performance — query speed, throughput, pipeline scale — as load and use cases grow. Designing Data-Intensive Applications treats it as a property you design for explicitly through partitioning to distribute load and storage, storage engines tuned to the access pattern, and rebalancing strategies that don't fall over. Effective Data Science Infrastructure reframes scalability as organizational, not just technical: minimize interference among workloads through isolation, so that adding more data scientists or jobs doesn't make everyone slower — and remember that human time is more expensive than compute time, so optimize for human productivity first. In the LLM context, scale also means cost: inference optimization (latency, token and compute consumption) is a first-class engineering concern, and the practical guidance is to measure token consumption and accuracy on a representative sample before committing to a full-dataset run, and to use specialized external tools for heavy structured processing rather than the model as a compute engine.
Why it matters. A system that works for ten users or a thousand rows and collapses at production scale is a demo with a deployment date. The failure shows up as queries timing out, pipelines missing windows, or — with LLMs — an API bill that arrives after you've already run the full dataset. Scale that isn't designed in is discovered in an incident.
The myth: Performance is something you optimize later if it becomes a problem.
The reality: Scalability is an architectural property you design for — partitioning, storage-engine fit, and workload isolation are choices made early, not patches applied after the system buckles.
The myth: Scaling is purely about machines and throughput.
The reality: Scalability is also organizational. Isolating workloads so they don't interfere is what lets more people and jobs run without slowing each other — and human time costs more than compute.
The myth: Just run the LLM over the whole dataset and see what it costs.
The reality: Measure token consumption and accuracy on a representative sample first. Inference cost compounds with volume; the sample tells you whether the full run is worth it before you pay for it.
How to:
- Partition data to distribute load and storage, and choose a key distribution and rebalancing approach deliberately.
- Match the storage engine to the workload (transactional vs. analytic access patterns).
- Isolate workloads so jobs and users don't interfere, prioritizing human productivity and organizational scalability.
- For LLM pipelines, sample first to measure tokens and accuracy, then decide on the full run; offload heavy structured processing to specialized tools.
- Treat inference latency, throughput, and cost as balanced engineering targets, not afterthoughts.
Watch out for:
- Deferring performance to 'later' and finding the architecture can't be partitioned without a rewrite.
- Shared, un-isolated workloads where one heavy job degrades everyone.
- Running an LLM over a full dataset before sampling, then receiving the bill.
- Using the model as a compute engine for large structured data instead of a specialized tool.
Grounded in: Designing Data-Intensive Applications; Architecture Patterns with Python; Data Analysis with LLMs; Effective Data Science Infrastructure; Data Warehouse and Data Mining
System Reliability, Safety, and Resilience
Advanced
Reliability is the system continuing to function correctly, safely, and resiliently under faults and production load. Designing Data-Intensive Applications gives the founding stance: build reliable systems from unreliable components by anticipating and tolerating faults, and operate in distributed environments knowing networks are unreliable, clocks unsynchronized, and process pauses unpredictable. It separates two guarantees worth keeping distinct — timeliness versus integrity — and argues integrity matters most and can be preserved without synchronous coordination. Designing Machine Learning Systems names reliability as one of four properties every production ML system must satisfy (with scalability, maintainability, adaptability), and warns that ML systems fail silently in ways unit tests and accuracy scores never reveal — so observability has to be designed in, with metrics, logs, and traces on every component. Architecture Patterns supplies the structural means: decoupling and testability so a fault in one part can't cascade, and consistency enforced by modifying one aggregate per transaction with eventual consistency across boundaries.
Why it matters. An analytics system that's right in the lab and wrong silently in production is worse than one that's visibly broken, because nobody catches it before the bad output reaches a decision. Faults, partial failures, and silent ML degradation are not edge cases — they are the normal operating condition of distributed and production systems. Without designed-in observability, you discover failure from a stakeholder, not a dashboard.
The myth: Reliable systems require reliable components.
The reality: You build reliability from unreliable components by anticipating and tolerating faults. Assuming the network, clocks, and processes are dependable is how partial failures become outages.
The myth: If the model passed its tests and accuracy check, it's safe in production.
The reality: ML systems fail silently in ways tests and accuracy scores never reveal. Observability — metrics, logs, traces on every component — is the only way to catch degradation before it reaches a decision.
The myth: Strong consistency everywhere is the safe default.
The reality: Distinguish timeliness from integrity. Integrity matters most and can be preserved without synchronous coordination; insisting on synchronous consistency everywhere trades resilience for a guarantee you may not need.
How to:
- Enumerate the faults your system must tolerate (node loss, network partition, clock skew, process pause) and design to survive them.
- Design observability in from the start: metrics, logs, and traces on every pipeline and model component.
- Decouple components so a fault is contained rather than cascading, and keep modules depending on abstractions.
- Modify one aggregate per transaction and use eventual consistency across boundaries to preserve invariants without global coordination.
- Prioritize integrity over timeliness where they conflict, and recover derived data by recomputation.
Watch out for:
- Silent ML degradation that no test or accuracy score surfaces — the failure this whole layer exists to catch.
- Assuming network and clock reliability and being blindsided by partial failures.
- Tight coupling that turns a local fault into a system-wide outage.
- Over-insisting on synchronous consistency and sacrificing resilience for a guarantee the use case doesn't require.
Grounded in: AI Engineering: Building Applications with Foundation Models; Architecture Patterns with Python; Designing Data-Intensive Applications; Designing Machine Learning Systems
Business Value and Decision Quality
Advanced
This is the terminal outcome the requirements set in motion: realized organizational benefit — better decisions, ROI, competitive advantage, sustainability. Model output produces business value only when it changes a decision and gets adopted. The BI tradition is explicit that value depends as much on people, process, and politics as on technology, and that success means delivering clean, consistent, conformed, current, comprehensive information that business people actually trust and use — with adoption growing incrementally and ROI demonstrated. Designing Machine Learning Systems reinforces the loop: tie ML metrics to business metrics, because a model that doesn't move a business outcome gets killed. Adoption itself depends on understandability, frictionless UX, and trust — which is why UX Strategy's emphasis on validated value and frictionless design and the BI emphasis on executive sponsorship and business-IT partnership belong here. And the loop closes back to the start: usage generates the feedback that, in AI Engineering's flywheel, improves the data that improves the next model. Value is not a finish line; it's the input to the next iteration.
Why it matters. A technically excellent system that nobody adopts produces zero value — and the corpus is full of BI projects that delivered exactly that. The failure isn't a bad model; it's a good model people route around because they don't understand it, don't trust it, or it doesn't fit how they actually decide. Without sponsorship and adoption, the entire chain you built upstream returns nothing.
The myth: If the system is accurate and well-built, the business value follows.
The reality: Value requires adoption, and adoption requires trust, understandability, frictionless UX, and executive sponsorship. A good system nobody uses is worth nothing — value depends as much on people and politics as on technology.
The myth: Shipping the model is the finish line.
The reality: Usage is the start of the next loop. Feedback from real use feeds the data flywheel that improves the next model; treating deployment as the end forfeits the compounding advantage.
The myth: Business value is self-evident once the model is live.
The reality: Tie ML metrics to business metrics explicitly and demonstrate ROI; a model that doesn't measurably move an outcome will be deprioritized or killed regardless of its accuracy.
How to:
- Trace every output to the specific decision it improves and measure the business metric, not just the model metric.
- Secure influential business sponsorship and a genuine business-IT partnership before and throughout delivery.
- Drive adoption through understandable, frictionless interfaces and visible trust signals (lineage, freshness, validation).
- Grow incrementally — demonstrate ROI on a thin slice and expand from proven value rather than launching big.
- Instrument usage so feedback feeds back into requirements and the data flywheel, closing the loop to the start of this guide.
Watch out for:
- Building something accurate that nobody adopts because it isn't trusted, understood, or frictionless.
- Treating deployment as the finish line and forfeiting the usage-driven flywheel.
- Lacking executive sponsorship, leaving a high-profile effort exposed when it underdelivers early.
- Reporting model metrics that no stakeholder can connect to a decision or a dollar.
Grounded in: Business Intelligence Guidebook: From Data Integration to Analytics; Data Mining for Business Analytics: Concepts, Techniques, and Applications; Data Warehouse and Data Mining; The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling; Designing Machine Learning Systems; Ux Strategy Levy; Understanding Deep Learning
Live tensions in the field
Where the corpus genuinely disagrees — these are choices to make for your situation, not settled answers.
What is the central outcome you're actually optimizing — system quality, predictive accuracy, or business adoption?
System quality first (DDIA, Architecture Patterns, Effective DS Infrastructure): reliability, scalability, and maintainability are the terminal goals; a model is just one component. · Predictive accuracy first (the ML/DL/statistics books): output quality on unseen data is what you build toward; everything else is plumbing. · Business adoption and value first (BI/DW and UX books): a trusted, used system that changes decisions is the only outcome that counts; accuracy and engineering serve it.
This is a genuine context-contingent split (contested, not settled), and the right emphasis depends on your situation. If you're building shared infrastructure that many teams depend on, weight system quality — its failures are the most expensive and the least visible. If you're shipping a single predictive feature whose job is to be right, weight output quality and honest evaluation. If your risk is a polished system nobody uses — the classic BI failure — weight adoption, sponsorship, and trust. The integrating move the chain in this guide makes is that these are sequential, not exclusive: requirements set the business target, data and model produce accuracy, architecture produces reliability and scale, and adoption converts all of it to value. Name which camp your project's biggest risk lives in, and weight accordingly — don't inherit one camp's bias by accident.
How is generalization achieved — by managing the bias-variance tradeoff, or by emergent zero-shot capability that needs no target training?
Bias-variance tradeoff (Data Mining, Understanding Deep Learning): generalization is earned by balancing capacity against regularization and validating on held-out data; complexity must be justified. · Emergent zero-shot capability (Time Series Foundation Models): a model pretrained on diverse enough data generalizes to new tasks with no target-specific training at all.
These are opposing theories, but they're not equally evidenced for your case, and they apply at different scales. The bias-variance account rests on decades of validation-set practice and is the safe default when you train or fit your own model — it's the discipline that catches overfitting. The zero-shot foundation-model claim is real but conditional: the foundation-models book itself cautions to treat these models as the new baseline, not a guaranteed improvement, and to match pretraining frequency, horizon, and domain to your task before trusting them. The practical reconciliation: if a foundation model's pretraining plausibly covers your domain, try it zero-shot as a baseline and verify with cross-validation; whatever you build, the bias-variance discipline of honest holdout evaluation still governs whether you believe the result. Emergent capability changes where the generalization comes from, not whether you must measure it.
Is training data an exogenous input you collect once, or an endogenous output of a usage-driven flywheel?
Exogenous input (most ML/DL books): data is the raw material gathered before modeling; you clean it, partition it, and model it. · Endogenous flywheel (AI Engineering): production usage generates feedback that becomes the training data that improves the model — data is an output of the system, not just an input.
These differ on the direction of causality, and which holds depends on whether you can instrument usage. Most of the corpus treats data as exogenous because most modeling contexts don't have a live feedback loop — and in that case the exogenous discipline (curate, clean, partition, evaluate) is exactly right. AI Engineering's flywheel is the stronger competitive position when it's available: instrument real usage so feedback compounds into a data advantage rivals can't easily copy. The two aren't contradictory in practice — start by treating data as an input you must curate (quality and diversity over quantity), and build instrumentation so that, once in production, usage begins feeding the next iteration. If you can close that loop, do; if you can't yet, the exogenous discipline still fully applies.
Is decoupling and testability a primary lever for building these systems, or a software-engineering concern peripheral to the model?
Decoupling/testability is primary (Architecture Patterns, and by extension Effective DS Infrastructure): persistence ignorance, dependency inversion, and a test pyramid are the levers that keep a system maintainable and changeable. · Essentially absent (the model-centric ML/DL and statistics books): these books focus on data and model quality and say almost nothing about software design discipline.
This isn't a disagreement so much as a blind spot — the model-centric books don't argue against decoupling, they simply don't address it, which is exactly why model-first practitioners ship tangled systems that resist change. Weigh the evidence by type: Architecture Patterns argues from concrete engineering practice (test pyramids, aggregates, dependency inversion) for a class of problem the statistics books never consider — the long-term maintainability of production code. Take the position that the discipline is load-bearing precisely where the ML books are silent: the moment your model lives inside an application other people maintain, persistence-ignorant domain models and a fast unit-test base become the difference between a system you can evolve and a ball of mud. Adopt the discipline; the ML books' silence is a gap to fill, not a counterargument.
The playbook
This composite process spans building the data foundations and the models that analytics systems depend on, from raw data through deployment and ongoing maintenance. It sequences the work as a practitioner would run it: stand up the data pipeline and prepare quality data first, decide whether to customize a model and how, evaluate rigorously, wrap the model in a production application architecture with safeguards and inference optimization, and then monitor and iterate in production. Where the source books diverge on method — data transformation ordering, and how to adapt models — those splits are surfaced as tensions rather than flattened.
Extract, consolidate, and acquire the raw dataset
Pull data from relevant sources into a central store and identify what data and labels the task actually requires.
How to:
- Identify the most relevant, highest-quality data sources for the defined ML/analytics task.
- Run ETL (or ELT) to consolidate raw data into a central location.
- Acquire labels for training data, deciding between in-house labeling, crowdsourcing, or automated methods.
- Handle privacy and PII concerns in user-generated data at acquisition time.
Watch out for:
- Ambiguity about which sources are highest quality before you've defined validation rules.
- Choosing a supervision level that doesn't match the labeling budget or task.
Grounded in: AI Engineering: Building Applications with Foundation Models; Designing Machine Learning Systems
Split the dataset before cleaning to prevent leakage
Partition data into train/validation/test so preprocessing decisions don't leak information from evaluation data.
How to:
- Choose a splitting strategy (random, time-based, or stratified) appropriate to the task.
- Determine the size of each split.
- Split before applying cleaning and feature engineering steps that could otherwise leak test information.
Watch out for:
- Applying cleaning or scaling across the full dataset before splitting, which leaks information.
- Random splits on time-dependent data that inflate apparent performance.
Grounded in: Designing Machine Learning Systems
Filter, clean, and preprocess the data
Remove low-quality and irrelevant examples and prepare the training set so the model learns from sound data.
How to:
- Define explicit criteria for identifying low-quality data and acceptable duplication levels.
- Clean and balance the training set, handling missing values via deletion or imputation.
- Select a strategy to handle class imbalance.
Watch out for:
- Vague quality thresholds that make cleaning inconsistent across runs.
- Over-aggressive filtering that removes valid edge cases the model needs to see.
Grounded in: AI Engineering: Building Applications with Foundation Models; Designing Machine Learning Systems
Engineer features and augment or synthesize data as needed
Build model-ready feature sets and close coverage/volume gaps with augmentation or synthetic data.
How to:
- Apply appropriate scaling and encoding; decide which features to cross based on domain knowledge.
- Apply data augmentation for the relevant modality when a baseline model suggests data scarcity.
- Synthesize additional high-quality data when there are gaps in coverage or insufficient volume, choosing an appropriate synthesis method.
Watch out for:
- Augmentation or synthesis that introduces artifacts not representative of production data.
- Setting synthetic-data quality thresholds too low, letting bad examples into training.
Grounded in: AI Engineering: Building Applications with Foundation Models; Designing Machine Learning Systems
Verify, annotate, and format the final dataset
Confirm examples pass quality checks, annotate to task requirements, and format for the target model.
How to:
- Run quality checks; decide whether failing examples are discarded or sent for revision.
- Annotate data per task requirements, deciding what needs manual vs. automated annotation and how to keep annotation consistent.
- Convert the annotated dataset into the exact format the model training pipeline expects.
Watch out for:
- Inconsistent annotation across annotators degrading label quality.
- Format mismatches that surface only at training time.
Grounded in: AI Engineering: Building Applications with Foundation Models
Decide whether to customize a model, and select the approach
Determine if finetuning/custom training is justified over simpler options, then pick the strategy.
How to:
- Assess whether the performance gap is addressable by finetuning and whether the ROI beats prompt engineering.
- If proceeding, choose between teaching a new skill (SFT) or aligning with preferences (Preference Finetuning).
- Decide adapter-based methods (LoRA) vs. full finetuning, and whether to use a direct optimization or distillation path.
- Start model development from a simple baseline and increase complexity only as needed.
Watch out for:
- Finetuning when prompt engineering or a baseline would suffice.
- Committing to full finetuning without weighing cheaper adapter or distillation options.
Grounded in: AI Engineering: Building Applications with Foundation Models; Designing Machine Learning Systems
Train with experiment tracking and hyperparameter tuning
Execute the training run reproducibly while tuning critical hyperparameters.
How to:
- Stand up an experiment tracking tool and log parameters, configurations, code and dataset versions, metrics, and artifacts.
- Tune critical hyperparameters such as learning rate based on loss-curve behavior; decide when to stop to avoid overfitting.
- Execute the training run to produce an initial model.
- Review and compare logged experiments to decide which configuration to pursue.
Watch out for:
- Untracked runs that can't be reproduced or compared later.
- Overfitting from training too long without an early-stop criterion.
Grounded in: AI Engineering: Building Applications with Foundation Models; Designing Machine Learning Systems
Evaluate beyond accuracy before deployment
Rigorously assess performance, fairness, robustness, and reliability to confirm production-readiness.
How to:
- Establish baseline metrics for comparison.
- Run slice-based evaluation to surface hidden biases across critical data slices.
- Conduct behavioral tests for robustness and correctness; check model calibration and correct if needed.
- Set confidence thresholds and a policy for low-confidence predictions.
- Decide whether the improvement is sufficient to deploy or whether to iterate.
Watch out for:
- Judging readiness on aggregate accuracy while a critical slice fails.
- Deploying uncalibrated probabilistic outputs downstream analytics will trust.
Grounded in: AI Engineering: Building Applications with Foundation Models; Designing Machine Learning Systems
Build the production application architecture around the model
Wrap the evaluated model in a robust, safe, incrementally-built application.
How to:
- Start with a simple direct-to-model architecture, then add capability incrementally.
- Implement input and output guardrails; define policies for blocking vs. sanitizing queries and for unsafe outputs.
- Enhance context with external data sources and tools where valuable.
- Add a model router/gateway for multi-model pipelines and rules for escalating to a human.
- Add exact or semantic caching to cut latency and cost on repetitive queries.
Watch out for:
- Building complex routing/caching before a secure baseline exists.
- Cache policies (e.g., TTL) that serve stale results.
Grounded in: AI Engineering: Building Applications with Foundation Models
Optimize inference for speed, throughput, and cost
Configure generation and serving so the deployed system meets latency and cost targets.
How to:
- Select and configure a generation/sampling strategy appropriate to the use case; optionally add a Best-of-N strategy.
- Apply model compression, weighing accuracy loss against performance gain.
- Implement efficient batching and resource allocation to raise throughput.
- Use prompt caching and parallelism to remove redundant computation.
Watch out for:
- Compressing past the acceptable accuracy trade-off.
- Batching strategies that violate latency requirements.
Grounded in: AI Engineering: Building Applications with Foundation Models
Design the data-serving system for scale and integrity
Ensure the underlying data infrastructure serving analytics is scalable, fault-tolerant, and consistent.
How to:
- Use batch processing (e.g., MapReduce with mappers/reducers, shuffle-and-sort, chained jobs and joins) when tasks are too large for a single machine.
- Manage node lifecycle and failover in replicated stores: snapshot the leader to add followers, catch up recovered followers, monitor leader health, and elect the most up-to-date follower on failure.
- Use ACID transactions with an appropriate isolation level, with commit/rollback and retry-with-backoff on transient errors, when operations must all succeed or fail together.
- Use two-phase commit (2PC/XA) with a coordinator and durable transaction log when a single atomic operation spans multiple systems.
Watch out for:
- Choosing an isolation level too weak for the analytics correctness the workload requires.
- Coordinator failure leaving in-doubt distributed transactions if the transaction log isn't durable.
- Failover promoting a follower that isn't the most up-to-date, causing data loss.
Grounded in: Designing Data-Intensive Applications
Monitor in production and iterate through continual learning
Detect degradation and drift, then feed learnings back into data and model to keep the system relevant.
How to:
- Set up monitoring and dashboards for operational and ML-specific metrics.
- Detect data distribution shifts with an appropriate statistical test and a defined significance threshold.
- Create alerting for significant shifts or performance degradation.
- Trigger retraining on verified degradation, choosing full retraining vs. incremental fine-tuning and the right dataset (recent vs. combined).
- Integrate user feedback mechanisms and use poor performance signals to identify data gaps for the next iteration.
- Validate and deploy the retrained model, then resume monitoring.
Watch out for:
- Retraining on an unverified alert or on a dataset that overweights recent noise.
- Requesting user feedback in ways that disrupt the user experience.
Grounded in: AI Engineering: Building Applications with Foundation Models; Designing Machine Learning Systems
Where practitioners disagree
When to transform data relative to loading and splitting.
Choose deliberately between ETL and ELT patterns during consolidation, and split the data before any cleaning/feature engineering to prevent leakage (designing_machine_learning_systems). · Treat data engineering as a sequential curate→synthesize→verify→annotate→format pipeline driven by task requirements, with refinement folded back in from model feedback (ai_engineering).
If evaluation integrity is paramount and you control the pipeline, split first and be explicit about ETL vs. ELT so no transformation leaks across splits. For foundation-model finetuning where you're assembling and synthesizing a bespoke dataset, follow the curate-verify-format sequence but still carve out held-out evaluation data before you begin transforming, borrowing the leakage discipline from the ML-systems approach.
How to adapt a model to a specific task.
Prefer starting from a simple baseline model and progressively adding complexity, developed and tracked iteratively (designing_machine_learning_systems). · Adapt a pre-trained foundation model via finetuning (SFT/preference, LoRA vs. full, progression vs. distillation) — or avoid weight changes entirely and use prompt engineering plus RAG/agents (ai_engineering).
Gate on the ROI check first: if prompt engineering or a simple baseline closes the performance gap, do that. Reach for finetuning only when the gap is demonstrably weight-level and high-quality training data exists; within finetuning, prefer adapter methods or distillation before full finetuning unless the target task demands it.
Sources
- AI Engineering: Building Applications with Foundation Models — Chip Huyen
A comprehensive engineering guide for building production-ready AI applications on top of foundation models, covering the full stack from evaluation and prompt engineering to RAG, finetuning, inference optimization, and deployment architecture.
- Architecture Patterns with Python — Harry J. W. Percival & Bob Gregory
A practical guide to applying Domain-Driven Design, Test-Driven Development, and Event-Driven Architecture patterns in Python to build maintainable, testable, and loosely coupled systems.
- Business Intelligence Guidebook: From Data Integration to Analytics — Rick Sherman
A comprehensive, vendor-agnostic practitioner's guide to building a sustainable business intelligence environment from data integration through advanced analytics, with emphasis that BI success depends as much on people, process, and politics as on technology.
- Data Analysis with LLMs — Immanuel Trummer
A hands-on guide showing developers and data scientists how to use large language models—across text, tables, images, audio, and graphs—to build effective, cost-efficient data analysis pipelines in Python.
- Data Mining for Business Analytics: Concepts, Techniques, and Applications — Galit Shmueli, Peter C. Bruce, Inbal Yahav, Nitin R. Patel, Kenneth C. Lichtendahl Jr.
A practical, hands-on guide that teaches the core concepts, techniques, and applications of data mining for business analytics using R, organized around a disciplined predictive-modeling process.
- Data Warehouse and Data Mining — Jugnesh Kumar
A comprehensive textbook that teaches the foundational concepts, architectures, and techniques of data warehousing and data mining and their real-world applications.
- Designing Data-Intensive Applications — Martin Kleppmann
A deep, principles-first guide to the architecture of reliable, scalable, and maintainable data systems, explaining the trade-offs behind databases, distributed systems, and data processing.
- Designing Machine Learning Systems — Chip Huyen
A holistic, iterative framework for designing production-ready machine learning systems that are reliable, scalable, maintainable, and adaptive across every stage from data engineering to continual learning.
- Effective Data Science Infrastructure — Ville Tuulos
A practical guide to building human-centric infrastructure that empowers data scientists to develop, deploy, and operate machine learning applications end-to-end without becoming DevOps experts.
- Generative Deep Learning — David Foster
A hands-on technical guide to building generative deep learning models that can paint, write, compose music, and play games by teaching machines to create original content through VAEs, GANs, RNNs, and reinforcement learning.
- Probabilistic Deep Learning with Python, Keras and TensorFlow Probability — Oliver Dürr, Beate Sick & Elvis Murina
A hands-on guide to building probabilistic deep learning models using the maximum likelihood principle and Bayesian inference, implemented in Python with Keras and TensorFlow Probability.
- The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling — Ralph Kimball, Margy Ross
The definitive guide to dimensional modeling for data warehousing and business intelligence, teaching practitioners how to design simple, fast, business-driven analytic databases through case-study-driven techniques.
- Time Series Forecasting Using Foundation Models — Marco Peixeiro
A hands-on practitioner's guide to understanding, applying, fine-tuning, and comparing foundation models—from TimeGPT to LLM-based approaches—for time-series forecasting and anomaly detection.
- Understanding Deep Learning — Simon J. D. Prince
A comprehensive conceptual guide to deep learning that builds from fundamental supervised learning through generative models and reinforcement learning, candidly acknowledging what remains unknown about why deep learning works.
- Ux Strategy Levy — Jaime Levy
A practical guide for product makers to devise innovative digital solutions by integrating business strategy with validated user research, competitive analysis, and frictionless UX design.