- 0908106080/ 0969182526
- bittrain@bittrain.coach
AI đang giúp Developer viết code nhanh hơn. Nhưng nếu Developer vẫn phải chờ Platform Team, Security Team, Identity Team, Database Team hay những quy trình approval khác, liệu tốc độ của Developer có thực sự chuyển thành tốc độ của Organization?
Cùng tìm hiểu casestudy của Saxo để thấy rõ hơn.
Saxo có hơn 700 developers và hơn 400 người đã sử dụng GitHub Copilot kể từ khi triển khai vào tháng 2/2023. Theo Saxo, Copilot giúp developers “unblock” công việc, hỗ trợ tạo code, test, debugging và làm việc với những công nghệ mà họ chưa quen thuộc.
Nhưng song song với AI-assisted development, Saxo còn giải quyết một vấn đề khác: Developer bị phụ thuộc vào một hệ thống infrastructure phức tạp bên ngoài Kubernetes.
Đây là phần rất đáng chú ý đối với các tổ chức lớn.
Bởi vì:
Developer Productivity không chỉ được quyết định bởi tốc độ viết code. Nó còn được quyết định bởi mức độ dễ dàng để biến code thành một service thực sự có thể chạy được.
Trong một môi trường enterprise, một service không chỉ cần code và Kubernetes.
Tại Saxo, các application còn phụ thuộc vào nhiều hệ thống bên ngoài Kubernetes, bao gồm:
Điều đó tạo ra một thực tế quen thuộc trong nhiều tổ chức lớn:
Developer → Platform → Identity → Security → Data → Network → Infrastructure
Mỗi dependency có thể kéo theo một quy trình riêng.
Developer có thể đã hoàn thành code, nhưng service vẫn chưa thể sẵn sàng bởi một số thành phần khác chưa được provision hoặc cấu hình.
CNCF mô tả chính vấn đề này là việc các dependency của workload nằm ngoài Kubernetes và thường phải được quản lý thông qua nhiều hệ thống, repository và quy trình khác nhau.
Không nhất thiết một team nào làm việc kém. Vấn đề nằm ở cách các phần của hệ thống tương tác với nhau.
Saxo xây dựng Saxo Service Blueprint trên nền Kubernetes, kết hợp với các thành phần như Backstage, Operators và GitOps.
Mục tiêu không phải đơn giản là “automate thêm một vài task”.
Ý tưởng quan trọng hơn là:
Developer khai báo service cần gì; Platform tự động xử lý phần lớn cách thức cung cấp nó.
Ví dụ, thay vì Developer phải trực tiếp xử lý hàng loạt chi tiết như:
Developer có thể khai báo nhu cầu của service trong Service Catalog.
Sau đó Blueprint tự động tạo và đồng bộ các cấu hình infrastructure tương ứng.
CNCF mô tả flow của Saxo là: Developer declares intent => Service Catalog => Blueprint Operators => Infrastructure configuration => Validation & GitOps => Infrastructure converges to desired state
Đây là thay đổi rất quan trọng. Saxo chuyển một phần công việc từ: “Developer phải biết cách yêu cầu infrastructure”
sang: “Developer chỉ cần khai báo service cần gì.”
Đây có lẽ là insight đáng chú ý nhất trong case. Hãy hình dung hai cách tiếp cận.
Developer: “Tôi cần Kafka.”
Sau đó phải tìm hiểu:
Developer: “Service này consume Kafka API X.” Platform xử lý phần còn lại.
Đây là một dạng abstraction layer.
Developer làm việc với intent thay vì phải thao tác trực tiếp với từng infrastructure component.
CNCF cho biết Blueprint thực hiện chính việc này đối với Kafka: Developer khai báo quan hệ API trong Service Catalog, sau đó hệ thống tự động propagate access configuration qua các environment.
Đây không chỉ là câu chuyện về Kubernetes.
Nó là một nguyên tắc thiết kế workflow: Hãy giảm lượng organizational knowledge mà một Developer phải nắm giữ để hoàn thành một công việc.
Developer không nên phải trở thành chuyên gia của tất cả hệ thống mà họ phụ thuộc vào.
Một thay đổi khác rất đáng chú ý là Saxo giảm sự phụ thuộc vào ticket-based workflow.
Ví dụ với Kubernetes namespace.
Trước đây, việc provision một namespace cùng ownership, RBAC, Active Directory groups và các platform integrations mất trung bình khoảng 3 tuần.
Với Service Blueprint, thời gian này giảm xuống dưới 10 phút. CNCF ghi nhận mức giảm khoảng 99,97% thời gian provisioning.
Đây là một con số rất ấn tượng.
Nhưng cần hiểu đúng: Đây là improvement về infrastructure provisioning lead time, không phải bằng chứng rằng toàn bộ Developer Productivity của Saxo tăng 99,97%.
Điểm này rất quan trọng.
Case study tốt không nên biến một operational metric thành một business claim lớn hơn dữ liệu cho phép.
Một cách nhìn khác về case Saxo là:
Automation thông thường Một task mất 2 giờ → automate task → còn 10 phút.
Automation ở cấp Flow tại sao Developer phải thực hiện task đó ngay từ đầu? Đây là khác biệt lớn.
Nếu một Developer phải: Request → Wait → Follow-up → Approval → Configuration → Retry
thì việc tự động hóa một bước trong chuỗi chưa chắc giải quyết được bottleneck. Saxo đi xa hơn bằng cách tự động hóa cả chuỗi provisioning giữa service và các infrastructure dependencies.
Blueprint có thể tự động:
Vì vậy, điều đáng học không chỉ là: “Saxo dùng automation.”
Mà là: “Saxo dùng automation để giảm coordination giữa Developer và infrastructure.”
Trong 12 tháng, Saxo Service Blueprint đã thực hiện:
| Chỉ số | Kết quả |
| Automated infrastructure operations | 1.827 |
| Commits kích hoạt platform automation | 379 |
| Domain contributors | 121 |
| Amplification of developer intent into infrastructure state | 4,8× |
| Kubernetes namespace provisioning | ~3 tuần → <10 phút |
CNCF giải thích mức 4,8× amplification là việc 379 user commits từ 121 contributors đã kích hoạt 1.827 automated infrastructure operations. Đây không phải là tuyên bố Developer Productivity tăng 4,8 lần; nó phản ánh khả năng một thay đổi ở cấp developer được platform khuếch đại thành nhiều thay đổi infrastructure tự động. Ngoài ra, Blueprint đã tự động hóa nhiều loại infrastructure operation khác, bao gồm Kafka access, network policies và database access.
Saxo không dừng lại ở automation phía sau. Họ xây dựng DevReach, một internal developer portal dựa trên Backstage.
Developer có thể nhìn thấy trong một nơi:
Portal cũng có Service Relationship Graph, giúp nhìn thấy quan hệ giữa service và các dependency. Đây là một thay đổi đáng chú ý trong cách tư duy về Platform. Platform không chỉ là: Infrastructure for Developers mà đang trở thành: Developer Experience Product
Nói cách khác, Platform Team không chỉ cung cấp technology. Họ cung cấp một cách làm việc dễ dàng hơn cho Developer.
Đây là điểm cần phân biệt rõ khi nhìn vào case Saxo. AI-assisted productivity
GitHub Copilot giúp Developer:
Hơn 400 trong hơn 700 developers tại Saxo đã sử dụng Copilot. Saxo cho biết Copilot được sử dụng trong việc tạo gần như toàn bộ code mới và giúp developers “unblock” công việc.
Service Blueprint giúp Developer:
Hai thứ này không phải cùng một initiative.
Nhưng chúng cho thấy hai lớp khác nhau của Productivity:
AI có thể giảm friction trong việc tạo ra software.
Platform có thể giảm friction trong việc đưa software đi qua infrastructure.
Và khi nhìn ở cấp độ Organization, cả hai đều hướng đến một mục tiêu rộng hơn:
Reduce Friction in the Flow of Work
Nếu nhìn case này dưới góc độ Agile, bài học không nằm ở Kubernetes hay GitHub Copilot. Nó nằm ở câu hỏi: Where does work get stuck?
Một tổ chức có thể có:
nhưng vẫn có thể bị chậm vì:
Dependency → Handoff → Waiting → Approval → Rework
Do đó, khi một tổ chức muốn tăng tốc, đừng chỉ đo: Developer viết được bao nhiêu code?
Hãy nhìn rộng hơn: Work mất bao lâu để đi từ Intent → Software → Production → Customer Value?
Đó là sự khác biệt giữa: Local Productivity và End-to-End Flow.
Case Saxo không phải công thức để các doanh nghiệp khác sao chép nguyên trạng.
Nhưng có một số nguyên tắc đáng tham khảo.
Đừng bắt đầu bằng:
“Chúng ta cần Copilot hay Platform nào?”
Hãy bắt đầu bằng:
“Developer đang bị block ở đâu?”
Map toàn bộ flow:
Code → Test → Security → Infrastructure → Deployment → Production
Sau đó tìm:
Một Team có thể rất productive nhưng vẫn bị block bởi một Team khác.
Vì vậy:
Team Productivity ≠ System Productivity
Đặc biệt trong các tổ chức lớn, bottleneck thường nằm giữa các team, không nhất thiết nằm bên trong một team.
Nếu Developer liên tục phải request cùng một loại service:
hãy đặt câu hỏi:
Có thể biến dependency này thành self-service không?
Không phải mọi dependency đều nên self-service.
Nhưng những dependency có pattern rõ, policy rõ và có thể kiểm soát bằng automation là những ứng viên tốt.
Một tổ chức regulated không thể đơn giản loại bỏ control để chạy nhanh hơn.
Câu hỏi nên là:
Làm thế nào để control trở thành một phần của workflow?
Saxo sử dụng automated validation, approval và audit trail trong GitOps workflow.
Đây là hướng đáng tham khảo:
Governance không nhất thiết phải đồng nghĩa với Waiting.
Nếu policy có thể được codify và kiểm tra tự động, một phần control có thể được đưa trực tiếp vào flow.
Platform Team nên xác định rõ:
Customer: Developer / Product Team
Problem: Friction trong Software Delivery
Product: Developer Platform
Value: Self-service, lower cognitive load, faster provisioning, better visibility
Và Platform cũng cần được quản lý như một product:
Discover → Prioritize → Build → Measure → Improve
Đây là nơi tư duy Product Operating Model có thể kết nối rất tự nhiên với Platform Engineering.
Từ case Saxo, BitTrain nhìn Productivity theo 4 tầng:
AI → Developer
Developer hoàn thành một task nhanh hơn.
Team → Collaboration
Team giảm coordination và rework.
Platform → Dependencies → Governance
Work di chuyển qua Organization với ít waiting và handoff hơn.
Flow → Customer Value
Tốc độ từ ý tưởng đến giá trị được cải thiện.
Điểm quan trọng là:
Không nên mặc định rằng cải thiện ở Level 1 sẽ tự động tạo ra cải thiện tương ứng ở Level 4.
Đó chính là lý do AI adoption cần được nhìn trong bối cảnh rộng hơn của workflow và operating model.
Nếu ngày mai AI giúp Developer của bạn làm việc nhanh hơn đáng kể, hãy thử hỏi:
Nếu Developer tạo code nhanh hơn nhưng:
thì một phần productivity gain có thể bị hấp thụ bởi organizational friction.
Đó là lý do câu hỏi quan trọng không chỉ là:
“AI giúp Developer nhanh hơn bao nhiêu?”
mà còn là:
“Work Flow có nhanh hơn bao nhiêu?”
Case Saxo Bank không phải là câu chuyện:
“Hãy triển khai GitHub Copilot và Kubernetes Platform.”
Điều đáng tham khảo hơn là cách họ tiếp cận friction trong Software Delivery.
Saxo có một câu chuyện về AI-assisted development, nơi GitHub Copilot giúp developers giảm friction trong coding. Đồng thời, họ có một câu chuyện khác về Platform Engineering, nơi Service Blueprint giúp giảm manual coordination và dependency trong infrastructure provisioning.
Hai initiative này không nên được hiểu là một quan hệ nhân quả.
Nhưng khi đặt cạnh nhau, chúng gợi ra một câu hỏi rất đáng suy nghĩ cho các tổ chức lớn:
Nếu AI đang làm cho Developer nhanh hơn, Organization đã loại bỏ đủ friction để tận dụng năng lực đó chưa?
Saxo cho thấy một hướng tiếp cận đáng tham khảo:
Reduce manual work.
Reduce handoffs.
Make dependencies self-service where appropriate.
Embed controls into the workflow.
Build Platform around Developer Experience.
Bởi cuối cùng:
AI can accelerate work.
Platform can reduce organizational friction.
And better flow is what allows productivity to become value.
