Tôi không chắc mình chính thức gia nhập phe “lão làng” từ khi nào, nhưng tôi chợt nhận ra rằng mình đang ở trong phe đó khi tham gia vào một cuộc thảo luận về các nền tảng phát triển “low/no-code” gần đây.

Trước khi tôi định nghĩa nó, bạn nên hiểu một chút về lịch sử đằng sau mã hóa. Ở trường, tôi được hướng dẫn cách viết mã máy bằng thẻ đục lỗ. Điều này được phân loại là 1GL (lập trình ngôn ngữ thế hệ đầu tiên). Ở trường đại học, tôi đã viết một trình hợp dịch chéo cho bộ xử lý 6502, điều này đã đưa tôi đến với việc lập trình bằng 2GL, còn được gọi là hợp ngữ. Cuộc sống trở nên dễ dàng hơn rất nhiều khi tôi viết bằng Pascal, Basic và sau đó là Cobol. Đây là những 3GL. Một ví dụ về 4GL là SQL, về cơ bản là ngôn ngữ phi thủ tục. Những ngôn ngữ này được sử dụng để cho máy tính biết phải làm gì và không phải làm như thế nào. Cuối cùng, chúng ta có 5GL, còn được gọi là ngôn ngữ tự nhiên. Chúng có thể dịch các hướng dẫn của con người thành mã thực thi và được thiết kế để giúp máy tính giải quyết một vấn đề nhất định mà không cần lập trình viên.

Tôi mạnh mẽ lập luận rằng low/no-code không phải là 5GL hay thậm chí là 6GL, vì nhiều nền tảng trong số này không sử dụng ngôn ngữ như vậy và phương pháp phát triển của họ trực quan hơn nhiều.

Các nền tảng thấp/không có mã thường có ranh giới và bối cảnh được xác định rõ ràng trong miền vấn đề nhất định của chúng, vì vậy cấu hình trở thành một nhiệm vụ tương đối đơn giản để thực hiện, trong khi tùy biến vượt ra ngoài ranh giới trở nên phức tạp hơn, đòi hỏi sự can thiệp của lập trình viên truyền thống trong công cụ mới. Salesforce (dành cho CRM), Pega (dành cho RPA/quy trình làm việc) và SAP (dành cho ERP) là những ví dụ thể hiện nguyên tắc này. Gartner sau này định nghĩa chúng là “tiền thân” của công nghệ sáng tác trong danh mục sản phẩm góc phần tư kỳ diệu của họ, chứ không phải các nền tảng sáng tác ứng dụng chơi thuần túy.

Tôi không chắc chính xác “thấp/không mã” xuất hiện khi nào, nhưng nghiên cứu của tôi xác định Excel là ví dụ đầu tiên về nền tảng không mã. Đối với tôi, đó là vào cuối những năm 80 trên chiếc IBM 4700 sử dụng nền tảng phát triển có tên là Trình tạo bản đồ ứng dụng (AMG). Giải pháp này cho phép bạn tách định nghĩa giao diện người dùng, quy tắc/logic và văn bản. Mục tiêu của nó là tối đa hóa khả năng tái sử dụng và giúp dễ dàng tạo các giải pháp dựa trên màn hình. Nó hoạt động rất tốt cho các giao diện dựa trên ký tự.

Tua nhanh 15 năm tới năm 2001 khi tôi đồng sáng lập một công ty tạo nền tảng phát triển cho phép bạn tạo các ứng dụng đa kênh (hỗ trợ ngoại tuyến, web, di động và cổng thông tin) mà không cần viết mã. Trong nội bộ, chúng tôi gọi nó là nền tảng không mã. Tuy nhiên, chúng tôi không đơn độc và có những nền tảng tương tự khác, một số có công cụ quy tắc mạnh hơn, một số tập trung vào quy trình làm việc. Về cơ bản, mỗi nền tảng đều có sắc thái và điểm khác biệt.

Vào khoảng thời gian này, Gartner đã đặt ra thuật ngữ “nhà phát triển công dân” cho người dùng các nền tảng như vậy và sau đó vào năm 2015, Gartner đã mở rộng cụm từ này sang tích hợp, nêu rõ các bộ phận CNTT, nhà phát triển ngành kinh doanh (LOB), nhóm phát triển ứng dụng di động (AD), các nhóm ứng dụng và thậm chí cả người dùng doanh nghiệp là "các nhà tích hợp công dân", những người tận dụng khả năng của các nền tảng này để phát triển, thực thi và quản lý các giao diện tích hợp (hoặc "luồng tích hợp") trong đám mây.

Những nền tảng này đã thu hút các công ty nhỏ hơn cần nhiều hơn từ nguồn lực CNTT ít ỏi của họ và sự thiếu hụt nhân tài công nghệ đã khiến nhu cầu ngày càng tăng đối với những nền tảng như vậy không còn cần thiết và cấp bách. Trong các tổ chức lớn hơn, họ cũng kêu gọi các lĩnh vực kinh doanh không được ưu tiên truy cập vào tài nguyên CNTT. Tuy nhiên, hầu hết đều gặp khó khăn trong việc thay thế sự phát triển chủ đạo trong 3GL như Java hoặc .Net. Hầu hết, chính các bộ phận CNTT sẽ viện dẫn tính không linh hoạt của nền tảng và thiếu nguồn lực được đào tạo sẵn có. Các câu hỏi khác được đưa ra bao gồm:

1. Điều gì về kiểm soát nguồn và tái sử dụng?
2. Nó có hoạt động với thử nghiệm tự động không?
3. Chúng tôi có thể mang/nhúng mã của riêng mình nếu chúng tôi đạt đến giới hạn không?
4. Nó phù hợp với những tiêu chuẩn bảo mật nào?
5. Về khả năng mở rộng, chúng tôi có thể phát triển hoặc sử dụng các tiện ích giao diện người dùng của bên thứ ba không?
6. Nó có thể mở rộng quy mô?

Tôi có thể bổ sung thêm nhưng tôi chắc rằng bạn hiểu rõ ý chính là các nhóm CNTT muốn bảo vệ bộ kỹ năng và kiến ​​thức chuyên môn của họ và không bị bó buộc trong bộ công cụ độc quyền hoặc các giao dịch dài hạn với các nhà cung cấp bên thứ ba bằng mọi giá.

Tua nhanh đến bây giờ (20 năm rồi… trời ơi, tôi già rồi!) và chúng ta đến với bối cảnh kinh doanh hiện tại nơi “phần mềm đang ăn mòn thế giới” và do đó có một “cuộc chiến tranh giành nhân tài” trong CNTT. Đồng thời, công nghệ đang phát triển với tốc độ chóng mặt và việc theo kịp các khả năng mới là điều khó khăn.

Tuy nhiên, trong thế giới ngân hàng có thể kết hợp, trọng tâm có xu hướng tập trung nhiều hơn vào kết quả và giá trị kinh doanh hơn là cách bạn hoàn thành công việc cũng như các công cụ và công nghệ được sử dụng để đạt được điều đó. Tốc độ đạt được bản phát hành sản xuất đã trở nên quan trọng hơn nhiều. Do đó, mua trước khi xây dựng trở thành câu thần chú cho các thành phần có thể tái sử dụng và giờ đây, việc soạn thảo trước khi viết mã để “điều phối” các thành phần này hiệu quả hơn nhiều.

Trong lĩnh vực ngân hàng, các ngân hàng nhỏ hơn đã được hưởng lợi từ các giải pháp cốt lõi của nhà cung cấp hiện tại có thể “cấu hình được”, cho phép người dùng doanh nghiệp xác định các sản phẩm như khoản vay hoặc tài khoản tiền gửi. Các ngân hàng lớn hơn vẫn có xu hướng thích tính linh hoạt cao nhất, điều này thường tập trung vào khả năng mã hóa bất kỳ thứ gì không thể thực hiện được trong giải pháp cốt lõi.

Các nền tảng ngân hàng có thể kết hợp đang ngày càng cung cấp các giải pháp phát triển mã thấp/không cần mã của riêng họ để giúp phối hợp các nền tảng của họ. Điều này sẽ dẫn đến năng suất cao hơn và thời gian đưa ra thị trường cao hơn trong khi giảm nhiệt cho các tài nguyên CNTT có giá trị, thứ mà hầu hết các công ty sẽ tuyên bố rằng họ không bao giờ có đủ. Bộ phận CNTT đã trở nên thoải mái hơn với các công cụ để quản lý quy trình công việc, quy tắc kinh doanh và định nghĩa sản phẩm ngân hàng. Họ đã không cảm thấy thoải mái hơn, chắc chắn là ở các ngân hàng lớn, với giao diện người dùng hoặc các tác vụ “tích hợp”, nơi “tầm nhìn” của nền kinh tế API vẫn chưa mang lại trạng thái niết bàn của những lợi ích đã thực hiện như đã hứa.

Giống như hầu hết các nền tảng, nền tảng phát triển đã chuyển sang đám mây. Băng thông tốt hơn và hỗ trợ trình duyệt tốt hơn đang làm cho sự phát triển dựa trên đám mây trở nên khả thi và dễ tiếp cận hơn nhiều. Ví dụ: các nền tảng như Appeggio, Betty Blocks và Bubble.io giúp tạo ra các giải pháp mà không cần mã. Các giải pháp như vậy có các mẫu và các thành phần có thể tái sử dụng để theo dõi nhanh quá trình phát triển của bất kỳ giải pháp mới nào. Chúng dựa trên đám mây và không chỉ tự động hóa quá trình phát triển mà còn cả việc triển khai, cho dù đó là điện thoại di động (thông qua cửa hàng ứng dụng) hay máy chủ lưu trữ giải pháp web.

Cần lưu ý rằng làm việc với các hệ thống cũ và tại chỗ cho các giải pháp chủ quyền dữ liệu là những nhiệm vụ khó khăn hơn đối với họ. Một tính năng chính là khả năng quản lý các yêu cầu phi chức năng để người dùng không phải phát triển về hiệu suất, khả năng mở rộng, bảo mật và khả năng phục hồi. Riêng các yêu cầu phi chức năng này có thể tiết kiệm 40% so với các phương pháp phát triển truyền thống sử dụng mã.

Một số công cụ có AI trong nền đang cố gắng hết sức để hiểu ý định của người dùng. Mục tiêu của họ rất rõ ràng: bạn không cần phải là chuyên gia CNTT để xây dựng và triển khai các ứng dụng cấp doanh nghiệp. Điều này không có nghĩa là bạn không cần tài nguyên CNTT. Điều đó chỉ có nghĩa là bạn có thể tập trung nguồn lực của mình vào các nhiệm vụ cấp cao và khẩn cấp như tìm nguồn cung ứng hoặc tạo các thành phần có thể tái sử dụng.

Đối với tôi, sự trưởng thành của những nền tảng như vậy không thể đến sớm hơn một chút vì luôn có một số điều tất yếu hướng tới một cách thông minh hơn và nhanh hơn để tự động hóa hoạt động kinh doanh. Khi các ngành hợp nhất, nhu cầu kết hợp và kết hợp phần mềm tiếp tục tăng lên, như chúng ta đang chứng kiến ​​với ngân hàng nhúng. Tôi không nói rằng lập trình đã chết, tôi chỉ nói rằng low/no-code cho phép chúng ta cải thiện năng suất khi chúng ta trao nó cho thế hệ tài năng công nghệ mới nổi tiếp theo. Chúng tôi cũng có thể cải thiện thời gian đưa sản phẩm ra thị trường trong một thế giới mà việc liên tục tìm kiếm các lập trình viên giỏi và duy trì sự linh hoạt trong kinh doanh là một thách thức, tương tự như cách mà AWS tự trừu tượng hóa chính mình trên trung tâm dữ liệu cả về mặt tiếp thị “đám mây” như một khái niệm và chức năng trong về kết quả kinh doanh.

Vì vậy, mặc dù low/no-code đã và sẽ tiếp tục vấp phải những chỉ trích và hạn chế, phần lớn là từ những người đương nhiệm và cộng đồng nhà phát triển, tôi thấy một con đường tiến hóa không thể tránh khỏi đang nổi lên hướng tới các nền tảng có thể kết hợp sẽ mã hóa IaaS trên đám mây (AWS, GCP , Azure) đã đến trung tâm dữ liệu.

Giới thiệu về tác giả

Dharmesh Mistry đã hoạt động trong lĩnh vực ngân hàng hơn 30 năm và luôn đi đầu trong lĩnh vực đổi mới và công nghệ ngân hàng. Từ ứng dụng ngân hàng di động và internet đầu tiên đến trí tuệ nhân tạo (AI) và thực tế ảo (VR).

Anh ấy đã ở cả hai bên hàng rào và anh ấy không ngại chia sẻ ý kiến ​​của mình.

Anh ấy là giám đốc điều hành của Hỏi gia đình, tập trung vào trải nghiệm cho các hộ gia đình, đồng thời là nhà đầu tư và cố vấn trong lĩnh vực proptech và fintech.

Theo dõi Dharmesh trên Twitter @dharmeshmology và LinkedIn.

Đọc tất cả suy nghĩ "Tôi chỉ đang nói" của anh ấy tại đây.