Tản mạn về kiến trúc phần mềm (Phần 1: Mối tương quan với vòng đời sản phẩm)

Mình hay nói về kiến trúc phần mềm nhưng ít khi kể những câu chuyện về sản phẩm, đặc biệt là mối tương quan giữa kiến trúc phần mềm và vòng đời của sản phẩm, hôm nay là một bài viết về chủ đề đó, nhằm giúp anh em hình dung được bức tranh tổng quát về vai trò của kiến trúc phần mềm và nó được quyết định áp dụng ở giai đoạn sản phẩm như thế nào.

Rất nhiều anh em làm việc trên các sản phẩm phần mềm không có kiến trúc, khi dự án phình to thì họ cảm thấy khó khăn trong công việc phát triển dự án. Đừng vội đổ lỗi cho các lập trình viên tiền nhiệm đặt những dòng code đầu tiên cho dự án. Chúng ta sẽ cùng nhau làm rõ về các yếu tố ngoài kỹ thuật quyết định đến kiến trúc phần mềm như thế nào.

Dự án product khởi nghiệp bắt đầu với một team nhỏ. Theo yêu cầu từ phía doanh nghiệp, các nhà phát triển họ sẽ cố gắng hoàn thành dự án nhanh nhất có thể để ra mắt sớm và đưa dự án vào vận hành. Nhằm vào việc thử phản ứng của thị trường với sản phẩm phần mềm đó. Thật khó để thuyết phục doanh nghiệp áp dụng kiến trúc phần mềm tối ưu bảo trì và vận hành dự án ở giai đoạn này. Khi họ còn đang phải đối đầu với các vấn đề sống còn ngay trước mắt. Khái niệm sản phẩm tốt ở góc độ kinh doanh lúc này là đảm bảo các functional requirement hoạt động tốt và ít lỗi xảy ra.

Trong vòng một năm kể từ thời điểm dự án được phát hành lần đầu tiên, dự án đã qua một quá trình phát triển bứt phá. Tần suất phát hành phiên bản mới dày đặc, khách hàng rất hài lòng vì các yêu cầu của họ được đáp ứng kịp thời. Nhưng mọi thứ đều có chu kỳ của nó, dự án này cũng không ngoại lệ. Số lượng functional requirement ngày càng gia tăng khiến dự án trở nên hỗn loạn. Tuần suất phát hành phiên bản mới càng giảm. Những thay đổi nhỏ cũng trở nên khó khăn do thiếu thiếu sót những ranh giới về kiến trúc rõ ràng.

Mặc dù có thể có hoặc không về các cảnh báo về kiến trúc phần mềm từ đội phát triển. Nhưng đến thời điểm này doanh nghiệp mới dần thấm các ảnh hưởng to lớn của việc thiếu vắng của kiến trúc phần mềm trong hệ thống của họ. Tất nhiên chưa phải là quá muộn, việc chuyển đổi từ một sản phẩm không có kiến trúc đến một sản phẩm có kiến trúc có nhiều chiến thuật khác nhau. Chỉ tiếc là không phải cách nào cũng dễ dàng chuyển đổi ngay lập tức như một cú bật/tắt cái công tắc đèn. Đặc biệt các sản phẩm phát triển nhanh chóng thường bỏ qua rất nhiều quy trình, đặc biệt quy trình liên quan đến tài liệu, việc thiếu tài liệu là một trở ngại rất lớn để hỗ trợ cho việc chuyển đổi.

Những con tôm trưởng thành phải trải qua quá trình lột xác, sau khi cởi bỏ lớp vỏ cũ, lớp vỏ mới còn rất non nớt, nó trở nên dễ bị tấn công bởi kẻ thù. Việc doanh nghiệp dành nguồn lực để chuyển đổi kiến trúc phần mềm cũng vậy. Các đối thủ có thể dành lợi thế cạnh tranh trong thời điểm này.

Thực ra. Kiến trúc phần mềm hoàn toàn có thể được can thiệp sớm, bởi không phải toàn bộ quyết định liên quan đến kiến trúc đều "đắt giá". Có những quyết định với chi phí rất rẻ nhưng lại là các quyết định then chốt giúp hệ thống ổn định trong suốt thời gian phát triển. Đấy là câu chuyện về một sản phẩm phần mềm bắt đầu với một team nhỏ. Còn đối với các dự án có nhiều team tham gia phát triển cùng lúc ngay từ đầu. Việc kiến trúc phần mềm rất được chú trọng. Các team cần chia các ranh giới kiến trúc với trách nhiệm rõ ràng, lúc này họ mới có thể tiến hành công việc của mình với ít va chạm nhất có thể.

Ngoài ra còn nhiều câu chuyện khác nhưng mình sẽ tạm thời chỉ nêu ra vài châu chuyện kinh điển, đây là phần đầu tiên của series về "tản mạn kiến trúc phần mềm" hy vọng anh em đón nhận tích cực. Mình sẽ đi sâu hơn vào các vấn đề kiến trúc phần mềm ở các phần sau. Anh em đón đọc nhé!