SYNERRY Enterprise Platform Engine — เบื้องหลังการสร้างระบบใหม่ทั้งหมด

บทความนี้เหมาะกับ: ผู้บริหาร / หัวหน้าทีม / เจ้าของธุรกิจ IT ที่กำลังจะยกเครื่องระบบเก่า

เวลาอ่าน: 25 นาที

ระดับ: กลาง-ขั้นสูง

Category: Behind-the-Scenes / Business + AI

Funnel Level: 2-TRUST (เล่าเรื่องจริง ปัญหาจริง)

โครงสร้างเนื้อหาทั้งหมด (สารบัญ)

1. จุดเริ่มต้น
   1.1 ปัญหาที่ทีมเล่าให้ฟัง — Survey ทีม Dev 7 คน
   1.2 หาข้อมูล — จะเลือกอะไร ใช้อะไร เพราะอะไร
2. เริ่ม Build ระบบ
   2.1 Tech Stack ที่ตัดสินใจเลือก — เหตุผลทุกข้อ
   2.2 วาง Foundation — Monorepo, CI/CD, Design System
3. [เมนูถัดไป — ยังไม่เขียน]
...

1. จุดเริ่มต้น

ระบบเก่าของ SYNERRY ใช้มาหลายปี ลูกค้าเพิ่ม ทีมเพิ่ม แต่ปัญหาก็เพิ่มตาม

ผมไม่ได้นั่งเดาว่าปัญหาคืออะไร — ผมให้ทีมบอกเอง เพราะพวกเขาคุยกับลูกค้า คุยกับ code ทุกวัน พวกเขารู้ดีกว่าผมว่าอะไรพัง อะไรใช้เวลานาน อะไรทำให้ลูกค้าโกรธ

แล้วพอปัญหาชัด ผมก็ต้องตอบคำถามที่ยากกว่า — จะแก้ด้วยอะไร?

ไม่ใช่แค่เลือก framework ใหม่มาใส่ แต่ต้องมองทั้งภาพ — architecture ที่วางมาดีพอไหม? security ผ่านมาตรฐานไหม? ทีมพร้อมเปลี่ยนตัวเองไหม? งบพอไหม?

1.1 ปัญหาที่ทีมเล่าให้ฟัง

ผมส่ง survey ให้ทีม dev ทั้ง 7 คน — Ohm, Mart, tar, bat, ten, pun, Oum

คำถามง่ายมาก: "อะไรที่ทำให้คุณปวดหัวที่สุดในการทำงาน?"

ไม่ได้ถามแค่คนเดียว เพราะคนที่เห็นปัญหาคนละจุดกัน — backend dev เห็นอีกแบบ frontend dev เห็นอีกแบบ คนที่อยู่กับลูกค้าเห็นอีกแบบ

ผลลัพธ์? ปัญหาทั้งหมดประมาณ 40 รายการ จัดกลุ่มได้ 14 กลุ่มหลัก

พูดตรงๆ — ผมตกใจ ไม่ใช่เพราะมีปัญหาเยอะ (ระบบเก่าทุกที่มี) แต่เพราะหลายปัญหาเป็นเรื่อง พื้นฐาน ที่ควรแก้ตั้งนานแล้ว

ภาพรวมปัญหาทั้ง 14 กลุ่ม

สิ่งที่ทำให้ผมตกใจ

ไม่ใช่จำนวนปัญหา — ระบบเก่าทุกที่มีปัญหาเยอะ นั่นปกติ

สิ่งที่ตกใจคือ 5 คนจาก 7 คนพูดเรื่องเดียวกัน — SQL Injection

SQL Injection ไม่ใช่ปัญหาใหม่ มันเป็นช่องโหว่ที่รู้กันมาตั้งแต่ปี 1998 แต่ระบบเรายังมีอยู่ หลายจุด ไม่ใช่จุดเดียว

Ohm, tar, bat, ten, pun — ทุกคนพูดตรงกันว่า "หลายส่วนของระบบมีความเสี่ยง" ผลกระทบ? ข้อมูลลูกค้าอาจถูกเข้าถึงโดยไม่ได้รับอนุญาต แย่กว่านั้น — อาจต้องพัฒนาใหม่ทั้งหมด

แค่ข้อแรกก็หนักพอแล้ว

แต่ปัญหา Security ไม่ได้มีแค่ SQL Injection

Content Security Policy (CSP) ก็ไม่มี — อีก 5 คนรายงานเหมือนกัน Dependency เก่าที่ไม่เคย scan อีก 5 คน Cookie ที่ JavaScript อ่านได้ (httpOnly: false), IIS ที่มีช่องโหว่ Backdoor, ไม่มี Security Headers, ไม่ check file upload header จริงๆ, Authentication ที่ไม่มี 2FA

รวมปัญหา security ทั้งหมด? 3 กลุ่มหลัก ทุกกลุ่มมีคนรายงาน 3-5 คน

ระบบเก่าไม่ใช่แค่ "เก่า" — มัน อันตราย

ปัญหาที่ทำให้ทีมทำงานช้า

Security เป็นเรื่องเร่งด่วน แต่ปัญหาที่กินเวลาทีมทุกวันคืออีกกลุ่มหนึ่ง

"code เก่าไม่ได้ใช้แต่ไม่กล้าลบเพราะกลัวพัง"

ประโยคนี้จาก bat สรุปปัญหาได้ดีที่สุด — ทีมเราอยู่ในสถานะที่ กลัวจะแก้อะไร เพราะไม่รู้ว่าถ้าแก้แล้วอะไรจะพังตาม

ไม่มี test ไม่มี monitoring ไม่มี audit log — เท่ากับบินโดยไม่มีเรดาร์

Deploy แล้วพัง? ไม่มี rollback strategy Mart คนเดียวที่รายงานข้อนี้ แต่ผมคิดว่ามันสำคัญมาก เพราะถ้าระบบล่มบน production แล้วกู้กลับไม่ได้ — ทุกอย่างที่เราสร้างก็ไร้ค่า

สิ่งที่ผมเรียนรู้จาก survey นี้

ปัญหาจัดกลุ่มได้เป็น 3 ชั้น:

ปัญหาชัดแล้ว คำถามถัดมาก็คือ — แล้วจะแก้ด้วยอะไร?

เราไม่ได้แค่ patch ทีละจุด เราต้องออกแบบระบบใหม่ตั้งแต่ต้น

แต่ก่อนจะเลือกเทคโนโลยี ผมต้องรู้ก่อนว่า สิ่งที่เราวางไว้ มันมีจุดอ่อนตรงไหน

1.2 หาข้อมูล — จะเลือกอะไร ใช้อะไร เพราะอะไร

หลังจากเห็นปัญหาจากทีม ผมไม่ได้กระโดดไปเลือก framework ทันที

ผมให้ AI ช่วยวิเคราะห์ Spec ที่เราร่างไว้ — SYNERRY Enterprise Platform Engine — โดยตั้ง 4 บทบาทขึ้นมาตรวจ:

ผลวิเคราะห์ออกมาหนัก — พบจุดอ่อน 20 จุด แบ่งเป็น 8 จุดวิกฤต, 6 จุดค่อนข้างสูง, 6 จุดปานกลาง

พูดตรงๆ — Spec ที่เราร่างมา มี ambition สูงกว่าที่ทีมจะ deliver ได้

นี่คือ 5 จุดอ่อนที่ทำให้ผมต้องหยุดคิดใหม่ทั้งหมด

จุดอ่อนที่ 1: "เปลี่ยน DB แค่แก้ .env" — ฝันสวยที่ทำไม่ได้

Spec เขียนว่า "เปลี่ยน Database แค่แก้ .env — DATABASE_PROVIDER=postgresql หรือ mysql, sqlserver"

ฟังดูดี. ขายลูกค้าได้. แต่ความจริง?

การตัดสินใจของผม: ลด DB support เหลือ PostgreSQL (default) + MySQL (legacy) เท่านั้น Oracle, MSSQL — เพิ่มทีหลังเมื่อมีลูกค้าจริงที่ต้องการ ไม่ใช่สร้างไว้ "เผื่อ"

ลด test matrix ไป 60%. ลดงาน maintenance ไปมหาศาล. ไม่ต้อง maintain 2 ORM layers.

ขายน้อยลง แต่ deliver ได้จริง — ผมว่าดีกว่า

จุดอ่อนที่ 2: Branch-per-Project = Merge Hell

Spec วางไว้ว่าใช้ monorepo แล้วแตก branch ตามโครงการ:

main          -> Engine core (stable)
project/rid   -> RID customizations
project/cgd   -> CGD customizations

แล้ว cherry-pick core updates ไปทุก project branch

ฟังดูเข้าท่า — จนกว่าจะมี 10+ projects

จุดอ่อนที่ 3: ทีมถนัด Vue แต่ Spec เลือก React

นี่เป็นจุดที่ทำให้ผมคิดหนักที่สุด

ทีมเราใช้ Nuxt 3 (Vue.js) มาทุกโครงการ มี codebase, patterns, components สะสมมา ทุกคนถนัด Vue ecosystem — Pinia, VueUse, Nuxt modules

แต่ Spec เลือก Next.js (React)

timeline 12 สัปดาห์ + ทีมต้องเรียน React ใหม่ = สูตรสำเร็จสำหรับความล้มเหลว

ผมมี 2 ทางเลือก:

1. Training 4 สัปดาห์ ก่อนเริ่ม Sprint 1 — แต่เสียเวลา
2. คงไว้เป็น Nuxt 3 — ทีมถนัดอยู่แล้ว ทำงานได้เต็มประสิทธิภาพตั้งแต่วันแรก

จุดอ่อนที่ 4: Timeline 12 สัปดาห์ไม่จริง

ลองนับจริงๆ ว่าต้องสร้างอะไรบ้าง:

ตัวเลขไม่โกหก ขาดอีก 27-58 man-weeks — ไม่ใช่ขาดนิดหน่อย ขาดเกือบเท่าตัว

ทางออก? แบ่ง Phase

• Phase 1 (16 สัปดาห์): CMS + Auth + Search + Admin + Design System + CI/CD
• Phase 2 (8 สัปดาห์): Workflow + Report + Migration + AI

ไม่ใช่ส่งทีหมดแล้วทุกอย่างห่วย — ส่งทีละ phase แต่ทุก phase ต้องใช้ได้จริง

จุดอ่อนที่ 5: จุดอ่อนด้าน Security ของ Spec เอง

ยิ่งดูยิ่งพบว่า Spec ที่เราร่างมา ยังมีช่องโหว่ security เหมือนกัน — ไม่ต่างจากระบบเก่า

จุดอ่อนทั้ง 20 จุด — สรุปรวม

5 สิ่งที่ต้องแก้ก่อนลงมือ build

จากจุดอ่อน 20 จุด ผมสรุปเป็น 5 สิ่งที่ต้องตัดสินใจ ก่อนเขียน code บรรทัดแรก:

บทเรียนจากขั้นตอนนี้

การวิเคราะห์จุดอ่อนไม่ใช่เรื่องสนุก มันเจ็บ เพราะหลายอย่างที่เราคิดว่า "โอเค" มันไม่โอเคเลย

แต่เจ็บตอนวิเคราะห์ ดีกว่าเจ็บตอน deploy

สิ่งที่ผมเรียนรู้:

• อย่าขายสิ่งที่ deliver ไม่ได้ — Multi-DB 5 ตัว ฟังดูดี แต่ maintain ไม่ไหว ลดเหลือ 2 แล้วทำให้ดี ดีกว่า
• ถามทีมก่อนตัดสินใจ — ทีมถนัด Vue แต่ Spec เลือก React ทำไม? เพราะ "เทรนด์" หรือเพราะ "ทำงานได้ดีกว่า"?
• ตัวเลขไม่โกหก — 75-106 man-weeks กับ 48 man-weeks ที่มี ตัวเลขบอกหมดว่า timeline 12 สัปดาห์ไม่จริง
• Security ต้องคิดตั้งแต่วันแรก — ไม่ใช่ "เดี๋ยวค่อยเพิ่มทีหลัง"

2. เริ่ม Build ระบบ

ปัญหาชัดแล้ว จุดอ่อนเห็นแล้ว ถึงเวลาตัดสินใจ

ผมไม่ได้นั่งตัดสินใจคนเดียว — ผมให้ AI ช่วยวิเคราะห์ เปรียบเทียบ หา trade-off แต่สุดท้าย คนตัดสินใจคือผม เพราะผมรู้บริบทของทีม ของลูกค้า ของงบ — สิ่งที่ AI ไม่มีทางรู้แทนได้

2.1 Tech Stack ที่ตัดสินใจเลือก — เหตุผลทุกข้อ

ก่อนจะเลือก ผมมีกฎอยู่ 3 ข้อ:

1. ทีมต้องทำงานได้ตั้งแต่วันแรก — ไม่ใช่เรียน 3 เดือนแล้วค่อยเริ่ม
2. ลูกค้าต้องได้ของจริง ไม่ใช่ demo — ทุก feature ที่ขายต้อง deliver ได้
3. ไม่สร้าง "เผื่อ" — สร้างสิ่งที่ต้องใช้ตอนนี้ เพิ่มทีหลังเมื่อต้องการจริง

จากกฎ 3 ข้อนี้ ทุก technology ที่เลือก มีเหตุผลชัดเจน

Frontend: ทำไมถึงเลือก Next.js — ทั้งที่ทีมถนัด Vue

พูดตรงๆ — ถ้าเราสร้างระบบนี้ให้ตัวเองใช้อย่างเดียว ผมจะเลือก Nuxt 3 ไม่คิด

แต่เราสร้าง Platform Engine ที่จะขายลูกค้า Enterprise ต้องหาคนมาดูแลต่อได้ ต้อง scale ทีม ต้องให้ AI ช่วยเขียน code ได้มากที่สุด

React ชนะตรงนี้. ไม่ใช่เพราะ "ดีกว่า" — แต่เพราะ ecosystem ใหญ่กว่า

Backend: NestJS — ตัวเดียวที่ตอบโจทย์

ตัดสินใจตรงนี้ไม่ยาก — NestJS เป็น TypeScript เหมือน Next.js ทีมเขียนภาษาเดียวทั้ง frontend + backend ไม่ต้องสลับ mental model

ส่วน Python AI Module ที่ Spec เดิมวางไว้? ตัดออก Vercel AI SDK ทำได้ทุกอย่าง — OpenAI, Claude, Gemini — จาก TypeScript โดยตรง ไม่ต้องเพิ่ม Python เข้ามาให้วุ่น

Admin Panel: Refine — ไม่ build จากศูนย์

ตรงนี้คือจุดที่ประหยัดเวลาได้มหาศาล

Payload CMS 3.0 ดีมาก (GitHub stars เยอะกว่า Refine ด้วยซ้ำ) แต่มันเป็น backend ในตัว — ถ้าใช้ Payload ก็ไม่ต้อง NestJS ซึ่งขัดกับ architecture ที่เราวางไว้

Refine ตอบโจทย์ตรงกว่า — เป็น headless framework ต่อกับ NestJS backend ที่เรามีอยู่ ประหยัดเวลาไป 15-20 man-weeks

Full Stack ที่เลือก — ภาพรวม

สิ่งที่ตัดออก — สำคัญเท่ากับสิ่งที่เลือก

ตัดออก 5 อย่าง ลด complexity ลง 40%

ไม่ใช่ "ลดคุณภาพ" — แต่ "ลดสิ่งที่ไม่จำเป็น" ทุกอย่างที่ตัดออกสามารถเพิ่มกลับมาทีหลังได้ถ้ามีลูกค้าต้องการจริง

2.2 วาง Foundation — Monorepo, CI/CD, Design System

Tech Stack เลือกแล้ว ขั้นตอนถัดมาคือวาง foundation ก่อนเขียน feature แม้แต่บรรทัดเดียว

ผมเปรียบเทียบขั้นตอนนี้กับการสร้างบ้าน — ถ้าฐานรากไม่ดี ต่อให้ตกแต่งสวยแค่ไหน สุดท้ายก็พัง

สัปดาห์ที่ 1-2: Monorepo Setup

synerry-engine/
|
|-- apps/
|   |-- web/          # Next.js 15 — Public website
|   |-- admin/        # Refine v5 — Admin panel
|   |-- api/          # NestJS — Backend API
|
|-- packages/
|   |-- @engine/ui/          # Design System (shadcn/ui)
|   |-- @engine/config/      # Shared config (ESLint, TS, Tailwind)
|   |-- @engine/auth/        # Auth module (JWT, RBAC, MFA)
|   |-- @engine/cms/         # CMS module (content types, workflow)
|   |-- @engine/db/          # Prisma schema + migrations
|   |-- @engine/search/      # Search integration (Meilisearch)
|   |-- @engine/file/        # File storage (MinIO/S3)
|   |-- @engine/ai/          # AI module (Vercel AI SDK)
|
|-- docker/
|   |-- docker-compose.yml   # Local dev environment
|   |-- docker-compose.prod.yml
|
|-- .github/
|   |-- workflows/           # CI/CD pipelines
|
|-- turbo.json               # Turborepo build orchestration
|-- pnpm-workspace.yaml

สิ่งที่ต่างจาก Spec เดิม — เราไม่ใช้ branch-per-project อีกแล้ว

แต่ละ package ใน packages/ จะถูก publish เป็น versioned npm package ไปที่ GitLab Package Registry เมื่อโครงการใหม่เข้ามา แค่ npm install @engine/[email protected] — ไม่ต้อง cherry-pick ไม่ต้อง merge

สัปดาห์ที่ 1-2: CI/CD Pipeline

ก่อนเขียน code บรรทัดแรก ต้องมี pipeline ที่จับ bug ให้ก่อนถึง production

จำได้ไหม? ปัญหาข้อ #10 จาก survey — "ไม่มี testing pipeline, ไม่มี SAST scan, bug หลุดเข้า production บ่อย"

Pipeline นี้แก้ตรงจุดนั้น ทุก push ต้องผ่าน 5 ด่าน ถ้า fail ด่านไหนก็ merge ไม่ได้ ง่ายมาก

สัปดาห์ที่ 2: Design System Foundation

สัปดาห์ที่ 1-2: Security Foundation

ก่อนจะเขียน feature ต้องวาง security foundation ให้เรียบร้อย — แก้ปัญหาที่ทีมรายงานตั้งแต่แรก

Timeline Phase 1 — แผนจริงที่ทำได้จริง

บทเรียนจากการวาง Foundation

สัปดาห์แรกไม่ได้เขียน feature เลยแม้แต่บรรทัดเดียว ทั้ง 2 สัปดาห์ไปกับ monorepo, CI/CD, Docker, security headers, design tokens

ทีมบางคนอาจรู้สึกว่า "ทำไมไม่เริ่มเขียน code สักที?"

แต่ผมรู้ว่า — ถ้าฐานไม่ดี เดี๋ยวก็ต้องมาทุบทำใหม่ เสียเวลามากกว่า

เหมือนสร้างบ้าน ถ้าเทฐานรากไม่ดี ต่อให้ตกแต่งสวยแค่ไหน สุดท้ายก็ร้าว

ต่อในเมนูถัดไป: เริ่มเขียน feature จริง — CMS, Auth, Admin Panel และ Cursor + AI เข้ามาช่วยตรงไหน

สรุป Blog Structure ที่วางไว้:

>

เมนูหลัก 1: จุดเริ่มต้น -- เสร็จ

- 1.1 ปัญหาที่ทีมเล่าให้ฟัง

- 1.2 หาข้อมูล — จะเลือกอะไร ใช้อะไร เพราะอะไร

>

เมนูหลัก 2: เริ่ม Build ระบบ -- เสร็จ

- 2.1 Tech Stack ที่ตัดสินใจเลือก — เหตุผลทุกข้อ

- 2.2 วาง Foundation — Monorepo, CI/CD, Design System

>

เมนูหลัก 3+: รอวางโครงสร้างเพิ่ม