Quản lý nợ công nghệ kiến trúc

Khi nghĩ về nợ kỹ thuật, tôi vẫn nhớ ứng dụng đầu tiên tôi tạo ra khiến tôi nhận ra hậu quả của một kiến trúc không phù hợp. Chuyện này xảy ra vào cuối những năm 1990, khi tôi mới bắt đầu làm nhà tư vấn.

Khách hàng đã yêu cầu sử dụng nền tảng Lotus Notes để xây dựng hệ thống mua sắm cho khách hàng của họ. Bằng cách sử dụng ứng dụng khách Lotus Notes và một ứng dụng tùy chỉnh, người dùng cuối có thể đưa ra các yêu cầu sẽ được ứng dụng theo dõi và được nhóm của chủ sở hữu sản phẩm thực hiện. Về lý thuyết, đó thực sự là một ý tưởng hay – đặc biệt khi các ứng dụng phát triển trên web chưa phổ biến và mọi người đều sử dụng Lotus Notes hàng ngày.

Vấn đề cốt lõi là dữ liệu có tính chất quan hệ rất cao trong thiết kế – và Lotus Notes không phải là cơ sở dữ liệu quan hệ. Thiết kế của giải pháp yêu cầu quản lý lược đồ trong mọi tài liệu Lotus Notes và dựa trên một loạt trường đa giá trị để mô phỏng mối quan hệ giữa các thuộc tính dữ liệu. Nó là một mớ hỗn độn.

Rất nhiều logic trong ứng dụng Lotus Notes sẽ không được yêu cầu nếu một nền tảng tốt hơn được đề xuất. Mã nguồn rất phức tạp để hỗ trợ. Những cải tiến đối với cấu trúc dữ liệu dẫn đến việc tái cấu trúc chính mã cơ bản – chưa kể đến việc chạy các công việc dựa trên máy chủ để chuyển đổi dữ liệu hiện có. Đừng bắt tôi phải bắt đầu nỗ lực đằng sau việc tạo báo cáo.

Ngay từ khi mới bắt đầu sự nghiệp, tôi đã tập trung vào việc cung cấp giải pháp mà khách hàng mong muốn hơn là cố gắng đưa ra giải pháp tốt hơn. Đây chắc chắn là bài học tôi đã học được từ rất sớm trong sự nghiệp của mình, nhưng trong những năm kể từ dự án đó, tôi đã nhận ra rằng hậu quả của nợ kỹ thuật kiến trúc là một thực tế đáng tiếc mà tất cả chúng ta đều phải đối mặt.

Hãy cùng khám phá khái niệm nợ công nghệ kiến trúc thêm một chút ở cấp độ vĩ mô.

Nợ công nghệ kiến trúc (ATD)

Thư viện Nợ Kỹ thuật Kiến trúc (ATD) tại Đại học Carnegie Mellon cung cấp định nghĩa .) sau đây về ATD:

Nợ kỹ thuật kiến trúc là một phương pháp thiết kế hoặc xây dựng phù hợp trong thời gian ngắn nhưng điều đó tạo ra bối cảnh kỹ thuật trong đó cùng một công việc đòi hỏi phải làm lại kiến trúc và chi phí thực hiện sau này sẽ cao hơn chi phí hiện tại (bao gồm cả chi phí tăng theo thời gian) .

Trong “Trả lời nhanh: Cách quản lý nợ kỹ thuật kiến trúc” (xuất bản ngày 22/09/2023), Gartner Group định nghĩa ATD như sau:

Nợ kỹ thuật kiến trúc là loại nợ kỹ thuật gây ra bởi sự trôi dạt kiến trúc, các quyết định kiến trúc dưới mức tối ưu, vi phạm kiến trúc sản phẩm mục tiêu đã xác định và các thực tiễn tốt nhất về kiến trúc ngành đã được thiết lập và sự đánh đổi kiến trúc được thực hiện để phân phối phần mềm nhanh hơn.

Trong cả hai trường hợp, những lợi ích thường mang lại niềm vui ngắn hạn có thể gặp phải những thách thức dài hạn. Điều này tương tự với ví dụ Lotus Notes của tôi đã đề cập trong phần giới thiệu.

Vấn đề càng phức tạp hơn khi thiếu công cụ giúp xác định và quản lý nợ công nghệ cho kiến trúc phần mềm so với các khía cạnh khác của phát triển phần mềm:

Về chất lượng mã, khả năng quan sát và SCA, công cụ đã được chứng minh tồn tại với các sản phẩm như Sonarqube, Datadog, New Relic, GitHub và Snyk. Tuy nhiên, phân khúc kiến trúc phần mềm đã tụt lại phía sau mà không có giải pháp nào được chứng minh.

Điều này thật đáng tiếc, vì thực tế là ATD luôn là loại nợ kỹ thuật lớn nhất - và gây thiệt hại nặng nề nhất, như được tìm thấy trong báo cáo “ Đo lường nó? Quản lý nó? Bỏ mặc nó? Người thực hành phần mềm và Nợ kỹ thuật ” Nghiên cứu năm 2015 do Carnegie Mellon xuất bản.

Hình minh họa sau đây tóm tắt Hình 4 từ báo cáo đó, kết luận rằng những lựa chọn kiến trúc tồi là nguyên nhân rõ ràng dẫn đến các nguồn nợ kỹ thuật.

Nếu không được quản lý, ATD có thể tiếp tục phát triển theo thời gian với tốc độ ngày càng tăng, như được minh họa trong hình minh họa đơn giản này:

Nếu không giảm thiểu, nợ kiến trúc cuối cùng sẽ đạt đến điểm giới hạn đối với giải pháp cơ bản đang được đo lường.

Quản lý ATD

Trước khi có thể quản lý ATD, trước tiên chúng ta phải hiểu vấn đề. Desmond Tutu từng nói một cách khôn ngoan: “Chỉ có một cách để ăn thịt một con voi: cắn từng miếng một”.

Cách tiếp cận dịch chuyển sang trái bao gồm khái niệm di chuyển một khía cạnh nhất định đến gần điểm bắt đầu hơn là điểm cuối của vòng đời. Khái niệm này đã trở nên phổ biến với shift-left để thử nghiệm, trong đó giai đoạn thử nghiệm được chuyển sang một phần của quá trình phát triển chứ không phải là một sự kiện riêng biệt sẽ được hoàn thành sau khi quá trình phát triển kết thúc.

Shift-left có thể được thực hiện theo hai cách khác nhau trong việc quản lý ATD:

• Shift-left để biết khả năng phục hồi — xác định các nguồn có tác động đến khả năng phục hồi và sau đó khắc phục chúng trước khi chúng biểu hiện thành hiệu suất.
• Shift-left để bảo mật - phát hiện và giảm thiểu các vấn đề bảo mật trong vòng đời phát triển.

Cũng giống như shift-left để thử nghiệm, việc ưu tiên tập trung vào khả năng phục hồi và bảo mật trong giai đoạn phát triển sẽ làm giảm khả năng xảy ra sự cố không mong muốn.

Khả năng quan sát kiến trúc

Khả năng quan sát kiến trúc mang lại cho các nhóm kỹ thuật khả năng giải quyết dần dần sự trôi dạt kiến trúc trong các dịch vụ của họ ở cấp độ vĩ mô. Trên thực tế, Wall Street Journal đã báo cáo chi phí để khắc phục nợ kỹ thuật là 1,52 nghìn tỷ USD vào đầu năm nay trong bài báo “Vấn đề vô hình 1,52 nghìn tỷ USD: Phần mềm cũ cồng kềnh”.

Để thành công, lãnh đạo kỹ thuật phải hoàn toàn phù hợp với các mục tiêu tổ chức sau:

• Khả năng phục hồi - để phục hồi nhanh chóng sau những sự cố bất ngờ.
• Khả năng mở rộng - để mở rộng quy mô phù hợp với nhu cầu của khách hàng.
• Vận tốc - để cung cấp các tính năng và cải tiến phù hợp với mong đợi của sản phẩm.
• Tính phù hợp của đám mây - chuyển đổi các giải pháp cũ thành các dịch vụ gốc đám mây hiệu quả.

Gần đây tôi đã phát hiện ra nền tảng quan sát kiến trúc dựa trên AI của vFunction , nền tảng này tập trung vào các sản phẩm sau:

• Khám phá kiến trúc thực sự của giải pháp thông qua phân tích tĩnh và động.
• Ngăn chặn sự trôi dạt kiến trúc thông qua chế độ xem thời gian thực về cách các dịch vụ đang phát triển.
• Tăng khả năng phục hồi của ứng dụng thông qua việc loại bỏ các cải tiến và phụ thuộc không cần thiết giữa các miền ứng dụng và các tài nguyên liên quan của chúng.
• Quản lý và khắc phục nợ công nghệ thông qua khả năng quan sát do AI điều khiển.

Ngoài ra, nền tảng vFunction còn mang lại lợi ích phụ là cung cấp lộ trình di chuyển để chuyển đổi từ giải pháp nguyên khối sang giải pháp gốc trên nền tảng đám mây. Khi các đội đã hiện đại hóa nền tảng của mình, họ có thể liên tục quan sát chúng để phát hiện tình trạng trôi dạt đang diễn ra. Nếu các công ty đã có vi dịch vụ, họ có thể sử dụng vFunction để phát hiện độ phức tạp trong các ứng dụng phân tán và giải quyết các phần phụ thuộc ảnh hưởng đến khả năng phục hồi và khả năng mở rộng. Trong cả hai trường hợp, sau khi được triển khai, các nhóm kỹ thuật có thể giảm thiểu ATD trước khi đạt đến điểm giới hạn.

Trong hình minh họa ở trên, các nhóm kỹ thuật có thể giảm thiểu nợ kỹ thuật như một phần của mỗi bản phát hành nhờ việc triển khai nền tảng vFunction và phương pháp tiếp cận dịch chuyển sang trái cơ bản.

Phần kết luận

Độc giả của tôi có thể nhớ lại rằng tôi đã tập trung vào tuyên bố sứ mệnh sau đây mà tôi cảm thấy có thể áp dụng cho bất kỳ chuyên gia CNTT nào:

“Hãy tập trung thời gian vào việc cung cấp các tính năng/chức năng giúp nâng cao giá trị tài sản trí tuệ của bạn. Tận dụng các khuôn khổ, sản phẩm và dịch vụ cho mọi thứ khác.” - J. Vester

Nền tảng vFunction tuân thủ tuyên bố sứ mệnh của tôi bằng cách giúp các nhóm kỹ thuật sử dụng cách tiếp cận sang trái để đảm bảo khả năng phục hồi và bảo mật cho các dịch vụ của họ ở cấp độ vĩ mô. Đây là một điểm khác biệt quan trọng vì nếu không có những công cụ như vậy, các nhóm có khả năng giảm thiểu ở cấp độ vi mô, giải quyết nợ công nghệ không thực sự quan trọng từ góc độ tổ chức.

Khi nghĩ lại ứng dụng đã khiến tôi nhận ra những thách thức với nợ công nghệ, tôi không thể không nghĩ về việc giải pháp đó mang lại nhiều vấn đề hơn là lợi ích với từng tính năng được giới thiệu. Chắc chắn, việc sử dụng shift-left chỉ riêng cho khả năng phục hồi sẽ giúp giải quyết các vấn đề nổi bật với kiến trúc cơ bản ở điểm mà chi phí xem xét các giải pháp thay thế sẽ khả thi.

Nếu muốn tìm hiểu thêm về giải pháp vFunction, bạn có thể đọc thêm về chúng tại đây .

Chúc bạn có một ngày thật tuyệt vời!