Kiến trúc tinh gọn

Kiến trúc là một phép ẩn dụ lâu đời cho thiết kế và xây dựng phần mềm và đặc biệt là để lập trình trong phạm vi rộng lớn. Kỹ thuật phần mềm chủ yếu chấp nhận phép ẩn dụ này dưới nhiều hình thức, từ việc sử dụng tiêu đề phần mềm "kiến trúc sư" cho đến các phép ẩn dụ được cung cấp bởi kỷ luật mẫu.

Kiến trúc là hình thức của bất kỳ hệ thống nào được tạo ra thông qua thiết kế có ý thức, và do đó nó có các yếu tố con người mạnh mẽ cả trong quá trình và sản phẩm của nó. Thuật ngữ hình thức ngụ ý một mô hình tinh thần sâu sắc về bản chất của một cấu trúc nào đó. Một cấu trúc có hình thức; một biểu mẫu nhất định đang chờ triển khai trong cấu trúc. Ví dụ: một hình ảnh xuất hiện trong tâm trí bạn khi chúng tôi gọi từ "ghế". Đối với hầu hết mọi người, đó không phải là một hình ảnh hoàn toàn cụ thể; nó thậm chí có thể không có màu cho đến khi câu hỏi khiến bạn phải gán cho nó một màu. Chúng tôi có thể gợi ý rằng chúng tôi muốn bạn nghĩ đến một chiếc ghế có năm chân và, mặc dù bạn có thể chỉ hình dung ra bốn chân, bạn có thể sẽ không phản đối rằng cấu trúc như vậy vi phạm hình thức của một chiếc ghế. Kiến trúc hướng đến bản chất của một hệ thống.

Thuật ngữ "kiến trúc" chạm đến một loạt các mối quan tâm trong thế giới xây dựng, mà có lẽ tốt nhất có thể được tóm tắt trong các thuật ngữ được phổ biến bởi kiến ​​trúc sư La Mã quá cố Vitruvius: tiện ích , linh sam và venustas . Như được nắm bắt bởi những thuật ngữ này, phần lớn tầm nhìn kiến ​​trúc cổ điển nói lên chất lượng cuộc sống của con người. Trong khi liên kết của kiến trúc đến thời trang và thậm chí đến thẩm mỹ là gây tranh cãi, hàng hóa và tiện ích ( utilitas ) là nền tảng, vì vậy kiến trúc là cái đẹp. Kiến trúc không phải là không có thành phần kỹ thuật mà bao gồm vật liệu và kỹ thuật xây dựng, như xây dựng tốt phải được bền ( firmitas) và kiến ​​trúc, có thể nói là vượt thời gian. Cuối cùng, nhưng chắc chắn không kém phần quan trọng, kiến ​​trúc phải truyền cảm hứng cho con người ( venustas ). Chúng ta có thể coi "sự vui thích" là sự thoải mái, vẻ đẹp hoặc sự kinh ngạc.

Bởi vì hình thức là kết quả của thiết kế, chứ không phải của phân tích, kiến ​​trúc sống bình thường trong không gian của thiết kế. Do đó, bản thân kiến ​​trúc không phải về cơ bản là quản lý tri thức, mặc dù các hoạt động quản lý tri thức như phân tích miền và khai thác mẫu thường đóng vai trò là những bước dạo đầu mạnh mẽ cho kiến ​​trúc. Lean là về loại bỏ lãng phí và kiến ​​trúc giúp ích trong việc này vì:

• Kiến trúc sẽ xác định các tiêu chuẩn nhằm giảm thiểu sự mâu thuẫn và tránh lãng phí thời gian và năng lượng trong các vấn đề và thảo luận định kỳ.
• Kiến trúc thiết lập hệ thống để phát triển tính năng chống giả, giảm lãng phí thời gian và năng lượng trong các vấn đề lặp đi lặp lại và số lượng tấm lò hơi lặp đi lặp lại.
• Kiến trúc tổ chức mã để nó có thể tự nói, giảm lãng phí thời gian và năng lượng trong việc viết tài liệu mở rộng.

Kỷ luật về mô hình phần mềm đã có những khởi đầu lớn từ tầm nhìn của người Alexandria về kiến ​​trúc, và những sự ra đi này không rõ ràng hơn ở bất cứ đâu so với thực hành hướng đối tượng. Các mẫu thiết kếcuốn sách đã được chọn lọc trong việc áp dụng các lý tưởng của Alexandria. Mặt khác, GOF nhận ra rằng phần mềm có các cấu trúc cắt ngang không hiển thị trong mã, nhưng vẫn là một phần trong tầm nhìn thiết kế của lập trình viên. Khái niệm mở rộng vượt ra ngoài các đối tượng riêng lẻ cho các mối quan hệ đưa chúng ta vững chắc vào lĩnh vực kiến ​​trúc. Các mẫu được cho là một trong những nền tảng vững chắc nhất của chương trình nghị sự Agile, design thinking, design sprint, Lean Startup và Lean UX. Các ý tưởng về tăng trưởng từng phần và thích ứng địa phương là nền tảng cho sự phát triển dựa trên mô hình sẽ được cộng đồng mô hình tiếp thu gần như nguyên văn. Những người theo thuyết Agilists sẽ chấp nhận định giá của Alexander về những mối quan tâm của con người so với phương pháp chưa đầy một thập kỷ sau đó. Gartner (cũng như nhiều người khác) đã cố gắng hình dung cách các phương pháp luận như Tư duy Thiết kế, Tinh gọn, Thiết kế Sprint và Agile lưu chuyển độc đáo từ cái này sang cái tiếp theo. Hầu hết những hình ảnh trực quan này có một số vòng tròn được tô màu và kết nối độc đáo.

Geert Claes đã đưa những phương pháp luận này vào một mô hình X, Y một cách tuyệt vời. Nhưng dù sao đi nữa, hầu hết các phương pháp luận đổi mới đều có thể mang lại giá trị to lớn và việc quyết định bắt đầu từ đâu và khi nào áp dụng phương pháp và kỹ thuật nào thực sự tùy thuộc vào nhóm. Điểm chung mà hầu hết có thể đồng ý, là tránh rơi vào tình yêu với giải pháp của riêng bạn và lắng nghe phản hồi định tính cũng như định lượng của khách hàng.

Làm cách nào để xác định kiến ​​trúc kinh doanh?

Để đơn giản hóa bất kỳ doanh nghiệp hoặc công ty nào, tôi thường cố gắng xác định chúng thành 3 lớp. Trong hình sau, tôi đã chia sẻ mô hình tư duy của mình:

Để hiểu mô hình kinh doanh, tôi sử dụng nhiều công cụ canvas khác nhau nhưng một trong những công cụ phổ biến nhất mà tôi rất hay sử dụng là Business Model Canvas. Một tiêu chuẩn toàn cầu được sử dụng bởi hàng triệu người trong các công ty thuộc mọi quy mô. Bạn có thể sử dụng canvas để mô tả, thiết kế, thử thách và xoay quanh mô hình kinh doanh của mình. Nó hoạt động cùng với Khung đề xuất giá trị và các công cụ và quy trình quản lý và thực thi chiến lược khác.

Sau đó, tôi tập hợp mỗi doanh nghiệp trông như thế nào trong 3 lớp đó. Ví dụ, đối với một công ty khởi nghiệp FinTech có tên iCare Benefits  là một doanh nghiệp xã hội vì lợi nhuận cho phép các nhà sản xuất, tổ chức xã hội, ngân hàng và nhà cung cấp dịch vụ phục vụ những người lao động ở tầng đáy của kim tự tháp kinh tế. Hình sau minh họa 3 lớp của iCare:

Điều rất quan trọng là phải xác định được đâu là hoạt động kinh doanh cốt lõi của bạn và đâu là lĩnh vực không, sau đó bạn có thể thiết lập các chiến lược về lĩnh vực nào quan trọng nhất và đòi hỏi sự tập trung nhiều hơn. Bên cạnh đó, đối với hoạt động kinh doanh không phải cốt lõi, bạn nên mua một sản phẩm sẵn sàng và áp dụng các quy trình của bạn và kiềm chế tùy chỉnh. Tại iCare, để tạo điều kiện thuận lợi cho quá trình chuyển đổi này và cam kết tuân thủ các nguyên tắc của chúng tôi, chúng tôi đã xác định các danh mục sau:

• Kinh doanh cốt lõi . Tại iCare Benefits, chúng tôi đã xác định các hạng mục sau là hoạt động kinh doanh chính:

  • Tạo Doanh thu : bất kỳ kênh, kỹ thuật, công nghệ hoặc sản phẩm nào giúp chúng tôi tạo ra nhiều doanh thu hơn.

  • Trả nợ : bất kỳ kênh, kỹ thuật, công nghệ hoặc sản phẩm nào giúp Thành viên iCare hoàn trả khoản vay.

  • Thu nợ: bất kỳ kênh, kỹ thuật, công nghệ hoặc sản phẩm nào giúp chúng tôi thu nợ.

• Kinh doanh không cốt lõi . Tất cả các lĩnh vực khác ngoại trừ hoạt động kinh doanh chính sẽ được coi là không cốt lõi, chẳng hạn như Tài chính, Kế toán, Hàng tồn kho, Thực hiện, SCM và v.v.

Theo cách phân loại này, chúng ta nên quyết định sản phẩm hoặc dịch vụ nào nên được mua. Tất cả mọi thứ thuộc hoạt động kinh doanh không chính phải được mua lại từ bên thứ ba. Sau đó, chúng tôi xác định một chương trình thay đổi được gọi là: “iCare Reloaded” đi kèm với nhiều giải pháp khác nhau bao gồm tất cả các khía cạnh kinh doanh của chúng tôi. Hình sau minh họa cấu trúc cấp cao của iCare Reloaded Program.

Dữ liệu, ngữ cảnh và tương tác

DCI là từ viết tắt của Data, Context và Interaction. DCI rất phù hợp với những thay đổi kiến ​​trúc này trong Agile. DCI thiên về các mô hình tinh thần hơn là về công nghệ - thiên về ý định của người dùng cuối hơn là ý định của kiến ​​trúc sư. Phần mềm tốt, giống như một ngôi nhà tốt, phù hợp với những người sử dụng nó. Về mặt công nghệ, tập trung vào tư duy và tạo ra sự tách biệt tốt về hình thức. Mặc dù một số nền tảng công nghệ tất nhiên là cần thiết để hỗ trợ mô hình tính toán DCI, nhưng vấn đề này chưa lên đến mức tranh luận về ngôn ngữ hay cuộc chiến về năng lực công nghệ.

DCI dẫn người lập trình và người dùng mã (đôi khi là cùng một người) vào một hộp thoại giúp nắm bắt các mô hình tinh thần trong mã. DCI cung cấp một ngôi nhà cho mô hình tinh thần của người dùng cuối trực tiếp trong mã trong ngữ cảnh và các lớp miền. Điều đó loại bỏ nhu cầu về cấp độ tài liệu bổ sung, loại bỏ cấp độ phân phối và biên dịch giữa người dùng cuối và người lập trình.

DCI là một cách tiếp cận đối với kiến ​​trúc hệ thống được đặc trưng bởi một số khái niệm hậu hiện đại:

1. Giá trị ý tưởng hơn vật thể : Các kiến ​​trúc sư của thế giới xây dựng từ lâu đã say mê với hình thức và chức năng. Cụm từ "hình thức theo sau chức năng" là một thành ngữ tiếng Anh bản ngữ đã được coi là một sự sai lệch trong nhiều thời đại. Các kiến ​​trúc sư đương đại sẽ không phê bình tư thế này và đưa ra các lựa chọn thay thế như: “Hình thức theo sau thất bại”, điều này gợi lên nhu cầu thay đổi và động lực trong việc hội tụ vào một kiến ​​trúc phù hợp.
2. Ưu tiên các chiến lược tổng hợp hơn các bộ phận riêng lẻ : DCI là về các chiến lược tổng hợp: cách nắm bắt chức năng và hình thức và tái tích hợp chúng dưới một mô hình tính toán trong thời gian chạy.
3. Chương trình nghị sự dựa trên phạm vi rộng, lấy con người làm trung tâm : các lớp dữ liệu DCI tương ứng với cấu trúc tổ chức miền và ngữ cảnh tương ứng với các sản phẩm phân phối ở cấp hệ thống. Nhắc lại Định luật Conway, cấu trúc này hỗ trợ quyền tự chủ của nhóm.
4. Tập trung vào sự thay đổi . Các hệ thống phức tạp được định hình bởi tất cả những người sử dụng chúng, và trong kỷ nguyên đổi mới hợp tác mới này, các nhà thiết kế phải phát triển từ việc trở thành tác giả riêng lẻ của các đối tượng hoặc tòa nhà, trở thành người thúc đẩy sự thay đổi giữa các nhóm người lớn. Sự nhạy cảm với bối cảnh, với các mối quan hệ và hậu quả là những khía cạnh chính của quá trình chuyển đổi từ phát triển không trí óc sang thiết kế chánh niệm.

Tôi đã tìm thấy cuốn sách tuyệt vời “ Kiến trúc tinh gọn để phát triển phần mềm nhanh nhẹn ” tập trung rất tốt vào chủ đề này. Ngày càng có nhiều dự án Agile đang tìm kiếm nguồn gốc kiến ​​trúc khi chúng phải vật lộn với sự phức tạp và quy mô - và họ đang tìm kiếm những cách thức nhẹ nhàng để thực hiện điều đó.