Mở đầu — vì sao bài này quan trọng
Đến giai đoạn này của khóa học, bạn đã hiểu về modern data stack, data warehouse, dbt, BI tools, governance và cả cách xây data team. Nhưng có một câu hỏi len lỏi vào mọi cuộc họp ngân sách, mọi buổi review roadmap của một tổ chức data-driven: "Cái này chúng ta tự xây (build) hay đi mua (buy)?"
Đây không phải câu hỏi kỹ thuật. Đây là câu hỏi chiến lược có sức nặng tài chính khổng lồ. Chọn sai hướng, bạn có thể đốt 18 tháng và cả tỷ đồng để tự viết một hệ thống ingestion mà một công cụ SaaS 500 USD/tháng làm tốt hơn. Ngược lại, mua nhầm một nền tảng đóng kín cho phần lõi tạo lợi thế cạnh tranh, bạn có thể vô tình trao chìa khóa "vũ khí bí mật" của công ty cho vendor, rồi bị khóa chặt (vendor lock-in) không thoát ra được.
Điều làm quyết định này khó là vì nó luôn bị chi phối bởi cảm xúc và cái tôi. Kỹ sư giỏi thường có bản năng "tôi tự xây được mà" — đó là hội chứng NIH (Not Invented Here). Lãnh đạo tài chính thì thường có bản năng ngược lại: "mua cho nhanh, cắt đầu người". Cả hai bản năng đều có thể đúng, cũng có thể dẫn công ty xuống hố. Người dẫn dắt data trưởng thành là người biết gạt cảm xúc sang bên, đặt quyết định build-vs-buy lên một khung phân tích tỉnh táo. Bài này trao cho bạn khung đó.
Khái niệm cốt lõi
Một quang phổ, không phải công tắc bật/tắt
Sai lầm đầu tiên là nghĩ build-vs-buy là lựa chọn nhị phân. Thực tế nó là một quang phổ (spectrum) với ba vùng chính:
- All build (tự xây toàn bộ): Mọi thành phần đều do đội nội bộ code, từ pipeline ingestion, orchestration, transformation, đến cả BI layer. Đây là con đường của các gã khổng lồ như Netflix, Uber thời kỳ đầu — khi quy mô và độ đặc thù lớn đến mức không công cụ nào ngoài thị trường đáp ứng nổi. Đổi lại là chi phí nhân lực khổng lồ và gánh nặng vận hành vĩnh viễn.
- All buy (mua toàn bộ): Dùng SaaS cho mọi thứ — Fivetran cho ingestion, Snowflake cho warehouse, dbt Cloud cho transformation, Looker/Power BI cho BI. Triển khai nhanh, ít cần kỹ sư platform, nhưng chi phí subscription tăng phi tuyến theo dữ liệu, và bạn phụ thuộc vào lộ trình của vendor.
- Hybrid (lai — thực tế phổ biến nhất): Mua phần "hạ tầng chung" mà cả thị trường đều dùng giống nhau (warehouse, ingestion connector phổ biến), tự xây phần lõi tạo lợi thế cạnh tranh (mô hình gợi ý, feature store, logic tính toán đặc thù ngành). Đại đa số tổ chức trưởng thành nằm ở vùng này.
Khi nào nên BUILD
Nguyên tắc cốt lõi nằm ở một từ: differentiation (sự khác biệt tạo lợi thế cạnh tranh). Bạn build khi thành phần đó là nguồn tạo ra lợi thế mà đối thủ không sao chép được.
Cụ thể, nên nghiêng về build khi:
- Đây là "core" chứ không phải "context". Ngôn ngữ của Geoffrey Moore: "core" là thứ khách hàng trả tiền vì nó, tạo khác biệt cho công ty bạn; "context" là thứ cần thiết nhưng không khác biệt (kế toán, hạ tầng email). Chỉ build core. Với Grab, thuật toán định giá động (dynamic pricing) và matching tài xế là core — họ phải tự build. Nhưng data warehouse của họ vẫn là context — mua được.
- Không có sản phẩm nào trên thị trường đáp ứng đúng nhu cầu, hoặc nhu cầu quá đặc thù (ví dụ tính toán phức tạp theo quy định pháp lý riêng của ngành ngân hàng Việt Nam).
- Quy mô lớn đến mức chi phí SaaS vượt xa chi phí tự vận hành. Ở khối lượng dữ liệu petabyte, hóa đơn Fivetran có thể lên hàng triệu USD/năm — lúc đó tự xây pipeline lại rẻ hơn.
- Bạn cần kiểm soát tuyệt đối về dữ liệu, độ trễ, bảo mật (fintech, y tế) mà vendor không cho phép.
Khi nào nên BUY
Nghiêng về buy khi thành phần là "context" — cần thiết nhưng không tạo khác biệt. Cụ thể:
- Bài toán đã được giải tốt bởi thị trường (commoditized). Ingestion từ Postgres/MySQL vào warehouse là bài toán hàng nghìn công ty đã giải; tự viết lại là lãng phí.
- Bạn cần Time-to-Market nhanh. Mua giúp có kết quả trong vài tuần thay vì vài quý.
- Đội nội bộ nhỏ, không đủ người để vừa xây vừa vận hành 24/7. Xây xong ai maintain khi kỹ sư nghỉ việc?
- TCO (Total Cost of Ownership — tổng chi phí sở hữu) của việc mua thấp hơn tự xây khi tính đủ lương kỹ sư, chi phí cơ hội, và rủi ro.
Cạm bẫy chi phí: thứ ai cũng tính sai
Sai lầm phổ biến nhất là so sánh giá subscription với 0 đồng của tự xây. Đây là ngụy biện. Tự xây không hề miễn phí — nó có chi phí ẩn khổng lồ:
- Lương kỹ sư trong suốt thời gian xây (và mãi mãi để maintain).
- Chi phí cơ hội: nếu 3 kỹ sư giỏi nhất dành 6 tháng xây pipeline, họ không làm được feature tạo ra doanh thu.
- Rủi ro vận hành: pipeline tự xây hỏng lúc 2 giờ sáng thì ai chịu trách nhiệm?
- Chi phí "bus factor": khi người viết nó nghỉ việc, cả hệ thống thành hộp đen.
Tình huống thực tế
Ví dụ 1: Tiki và bài toán ingestion — chọn Buy đúng lúc
Giả sử đội data platform của một sàn TMĐT lớn như Tiki, giai đoạn 2019–2020, đứng trước nhu cầu đưa dữ liệu từ hàng chục database dịch vụ (đơn hàng, kho, thanh toán, seller) về data warehouse tập trung. Một nhóm kỹ sư đề xuất tự viết framework ingestion bằng Airflow + custom Python connector.
Trưởng nhóm data đã làm phép tính TCO. Tự xây: cần 2 kỹ sư trong 5 tháng (chi phí nhân sự ~600 triệu đồng) chỉ để có phiên bản đầu, cộng thêm 0.5 kỹ sư maintain vĩnh viễn (~150 triệu/năm), chưa kể connector mới cho mỗi nguồn dữ liệu phát sinh. Mua một công cụ managed ingestion: khoảng 30.000–50.000 USD/năm cho khối lượng lúc đó.
Kết luận: buy. Lý do không chỉ vì rẻ hơn, mà vì ingestion là context — nó không phải thứ tạo lợi thế cho một sàn TMĐT. Lợi thế của Tiki nằm ở tốc độ giao hàng TikiNOW và trải nghiệm sản phẩm, chứ không phải ở việc pipeline chép dữ liệu đẹp thế nào. Mua giúp giải phóng 2 kỹ sư quý giá quay lại làm mô hình dự báo tồn kho — thứ trực tiếp tạo tiền.
Bài học: Đừng để cái tôi kỹ thuật khiến bạn tự xây phần "context". Hãy hỏi: "Nếu tự xây xong, khách hàng có yêu công ty hơn không?" Nếu câu trả lời là không, nghiêng về buy.
Ví dụ 2: MoMo và mô hình chấm điểm rủi ro — chọn Build vì đó là "vũ khí"
Ngược lại, hãy xét một ví điện tử như MoMo với bài toán chấm điểm rủi ro giao dịch và phát hiện gian lận (fraud detection) theo thời gian thực. Đây là nơi có sẵn nhiều sản phẩm SaaS "fraud detection as a service" trên thị trường quốc tế. Vậy có nên mua không?
Câu trả lời là build. Lý do:
- Đây là core tuyệt đối. Khả năng phát hiện gian lận chính xác mà không chặn nhầm giao dịch thật là lợi thế cạnh tranh sống còn của một ví điện tử. Nếu mua công cụ mà đối thủ cũng mua được, bạn không có khác biệt.
- Mô hình gian lận ở Việt Nam có đặc thù bản địa (mô thức lừa đảo, hành vi người dùng, quy định NHNN) mà công cụ nước ngoài huấn luyện trên dữ liệu phương Tây không nắm bắt tốt.
- Dữ liệu giao dịch là dữ liệu cực nhạy cảm; đẩy sang bên thứ ba xử lý real-time tạo rủi ro tuân thủ và bảo mật lớn.
Bài học: Với phần lõi tạo lợi thế, câu hỏi không phải "mua có rẻ hơn không" mà là "chúng ta có dám để lợi thế cạnh tranh nằm trong tay vendor không". Với core, nghiêng về build gần như luôn đúng — miễn là bạn có đủ năng lực đội ngũ.
Ví dụ 3: Một chuỗi bán lẻ tầm trung — chọn Hybrid và một cú "build" hối hận
Xét một chuỗi bán lẻ mỹ phẩm tầm trung (giả định), doanh thu ~500 tỷ/năm, đội data chỉ 4 người. Họ đi con đường hybrid hợp lý: mua Google BigQuery làm warehouse, mua công cụ ingestion, dùng dbt để transform, mua Metabase (bản open-source tự host) làm BI. Đến đây rất tốt.
Vấn đề nảy sinh khi CEO muốn có một "hệ thống CDP (Customer Data Platform) hợp nhất khách hàng 360 độ". Đội kỹ thuật, vì hào hứng, quyết định tự xây CDP từ đầu. Sau 9 tháng, hệ thống chạy lỗi identity resolution (ghép nhầm khách hàng), tốn 4 người gần như toàn thời gian, và vẫn thua xa một CDP thương mại.
Lỗi ở đâu? Họ đã build một thứ context (CDP là bài toán đã được thị trường giải tốt) với một đội quá nhỏ để vừa xây vừa vận hành. Bus factor bằng 1 — kỹ sư chính vừa nghỉ việc là cả hệ thống đứng hình.
Bài học: Hybrid là đúng, nhưng trong bức tranh hybrid, mỗi thành phần vẫn cần được đánh giá riêng. Đội nhỏ nên "buy" mọi thứ trừ đúng một hai điểm tạo lợi thế thật sự. Sức người là nguồn lực khan hiếm nhất — đừng rải mỏng vào việc tự xây thứ mua được.
Hướng dẫn từng bước
Đây là quy trình 6 bước để ra quyết định build-vs-buy cho một thành phần data cụ thể:
- Phân loại Core vs Context. Hỏi: thành phần này có trực tiếp tạo lợi thế cạnh tranh mà khách hàng cảm nhận được không? Nếu có → thiên về build. Nếu không → thiên về buy. Đây là bước quan trọng nhất, làm trước mọi tính toán tiền bạc.
- Khảo sát thị trường. Có sản phẩm nào (SaaS hoặc open-source) giải bài toán này ở mức "đủ tốt" chưa? Liệt kê 3–4 lựa chọn, đánh giá độ phù hợp (fit) với nhu cầu thực tế, không phải nhu cầu mơ ước.
- Tính TCO 3 năm cho cả hai phương án. Với build: lương kỹ sư (xây + maintain), chi phí cơ hội, hạ tầng. Với buy: subscription (nhớ mô phỏng tăng trưởng dữ liệu để thấy chi phí phi tuyến), chi phí tích hợp, chi phí đào tạo. So trên cùng một mặt bằng 3 năm.
- Đánh giá năng lực đội ngũ và bus factor. Đội có đủ người để vừa xây vừa vận hành lâu dài không? Nếu chỉ một người hiểu hệ thống, rủi ro quá cao — nghiêng về buy.
- Đánh giá rủi ro vendor lock-in với phương án buy. Dữ liệu có xuất ra được không? Chi phí chuyển đổi (switching cost) sau 3 năm ra sao? Ưu tiên vendor dùng chuẩn mở, cho phép export dữ liệu.
- Quyết định và ghi lại lý do (decision record). Viết một trang: bối cảnh, các lựa chọn, tiêu chí, quyết định, và điều kiện review lại. Quyết định build-vs-buy không vĩnh viễn — hẹn review sau 12–18 tháng khi quy mô thay đổi.
Lỗi thường gặp & mẹo
- Lỗi: So giá subscription với "0 đồng tự xây". Tự xây không bao giờ miễn phí. Luôn quy đổi thời gian kỹ sư ra tiền và cộng chi phí maintain vĩnh viễn.
- Lỗi: Hội chứng NIH (Not Invented Here). Kỹ sư giỏi hay tin "tôi tự làm được". Đúng, nhưng "làm được" khác "nên làm". Câu hỏi đúng là chi phí cơ hội.
- Lỗi: Build phần context. Tự viết ingestion, orchestration cơ bản, BI tool — những thứ thị trường đã commoditize. Đây là cách nhanh nhất để đốt tiền và người.
- Lỗi: Buy phần core rồi bị lock-in. Đẩy phần lõi tạo lợi thế cho vendor, sau 2 năm muốn thay đổi thì switching cost quá lớn, mắc kẹt.
- Lỗi: Quyết định một lần rồi quên. Ở quy mô nhỏ, buy có thể đúng; đến khi lớn lên, TCO đảo chiều và build lại hợp lý. Không review = trả giá.
- Mẹo: Với thành phần chưa chắc, hãy buy trước để đi nhanh, build sau khi đã hiểu rõ bài toán. Mua giúp bạn học nhu cầu thật với chi phí thấp, rồi tự xây khi đã đủ tự tin và quy mô.
- Mẹo: Ưu tiên open-source tự host như một điểm giữa — kiểm soát như build, tận dụng cộng đồng như buy (ví dụ Airbyte, Metabase, Superset).
Bài tập thực hành
- Lập bảng Core vs Context. Chọn một tổ chức bạn biết (nơi bạn làm hoặc một công ty giả định). Liệt kê 6 thành phần data (ingestion, warehouse, transformation, BI, CDP, ML model). Với mỗi thành phần, đánh dấu core hay context và giải thích một câu.
- Tính TCO 3 năm. Chọn một thành phần (ví dụ ingestion). Ước tính chi phí build (giả định lương kỹ sư 40 triệu/tháng, cần 2 người 5 tháng + 0.5 người maintain) so với buy (giả định 40.000 USD/năm). Phương án nào rẻ hơn trên 3 năm? Điểm hòa vốn nằm ở đâu?
- Viết một decision record một trang cho một quyết định build-vs-buy thật hoặc giả định, theo 6 bước ở phần Hướng dẫn. Đặc biệt viết rõ điều kiện để review lại quyết định trong tương lai.
Tóm tắt
Build-vs-buy không phải công tắc bật/tắt mà là quang phổ (all build — hybrid — all buy), quyết định theo từng thành phần, và đại đa số tổ chức trưởng thành nằm ở vùng hybrid. Nguyên tắc chủ đạo là Core vs Context: build phần lõi tạo lợi thế cạnh tranh mà khách hàng trả tiền vì nó; buy phần cần thiết nhưng không khác biệt và đã được thị trường giải tốt. Luôn so sánh trên nền TCO 3 năm, không so giá subscription với "0 đồng tự xây" — vì tự xây có chi phí ẩn khổng lồ về nhân lực, cơ hội và vận hành. Cảnh giác hai cạm bẫy đối xứng: hội chứng NIH khiến build phần context, và mua tiện tay khiến lock-in phần core. Cuối cùng, hãy nhớ quyết định này không vĩnh viễn — hẹn review khi quy mô thay đổi, và khi phân vân, hãy buy để đi nhanh rồi build khi đã hiểu rõ bài toán.