chương I này, học viên tập trung vào giới thiệu các kiến trúc HTTT, các khung quản trị kiến trúc HTTT và vai trò của chúng trong việc đáp ứng nhu cầu thực tế cũng như giải quyết bài toán xây dựng một kiến trúc khung cho từng tổ chức riêng biệt. Vai trò của kiến trúc và quản trị kiến trúc HTTT 1.1 Vai trò của kiến trúc HTTT Lĩnh vực khoa học máy tính trải qua sự kết hợp các vấn đề cùng với sự phức tạp của cấu trúc. Lúc đầu, sự phức tạp được giải quyết bởi người phát triển bằng cách lựa chọn các cấu trúc dữ liệu đúng đắn, phát triển các thuật toán và áp dụng các thuật toán để chia nhỏ các vấn đề. Thuật ngữ kiến trúc phần mềm liên quan đến sự mới mẻ của ngành công nghiệp này, nhưng nguyên tắc cơ bản của nó đã được áp dụng bởi các chuyên gia tiên phong trong ngành công nghệ phần mềm từ những năm 1980.
Các cố gắng ban đầu để nắm bắt và giải thích kiến trúc phần mềm của một hệ thống thường không chính xác và chưa được tổ chức rõ ràng. Nó được mô tả bởi các lược đồ "box and line" gồm một tập hợp các hộp và các đường kẻ. Trong những năm 1990, đã có một số nỗ lực tập trung để xác định và hệ thống hoá các khía cạnh cơ bản của môn học. Nhiều khái niệm của mẫu thiết kế (Design Pattern), kiểu dáng (styles), các ngôn ngữ đặc tả và luận lý hình thức (formal logic) đã được phát triển trong thời gian này.
[1] 5 Khái niệm "Kiến trúc phần mềm" tập trung vào việc giảm tải các phức tạp bằng cách trừu tượng hóa vấn đề và phân chia rõ trách nhiệm công việc. Tuy vậy, đến ngày nay vẫn chưa có một khái niệm thật chính xác và rõ ràng cho thuật ngữ "Kiến trúc phần mềm". Như vậy mặc dù khái niệm "Kiến trúc phần mềm" đã xuất hiện trong các giảng đường đại học và được đưa vào sử dụng trong ngành công nghệ phần mềm, nhưng việc nó vẫn chưa có các quy tắc, luật lệ chung và chưa rõ ràng nên thiết kế kiến trúc phần mềm vẫn là một sự pha tạp giữa "khoa học" và "nghệ thuật". Vẻ "nghệ thuật" của kiến trúc phần mềm được lý giải là do có sự xuất hiện của các yêu cầu phi chức năng của hệ thống mà phần mềm phải đáp ứng được các yêu cầu này, chẳng hạn như các yêu cầu về các thuộc tính chất lượng.
Ngoài ra, phần mềm còn phải thỏa mãn các yêu cầu khác như: khả năng chịu lỗi, tính tương thích với các phiên bản cũ của các phần mềm khác (backward compatibility), khả năng mở rộng, tính tin cậy, khả năng bảo trì, tính hiện hữu, tính bảo mật, tính dễ dùng, và một số các yêu cầu khác nữa. [3] Để chuyển các quan điểm, yêu cầu của người sử dụng sang kiến trúc phần mềm, cần phải tiến hành một số bước tìm hiểu, tham khảo các yêu cầu riêng và các sở thích riêng của từng loại người dùng phần mềm. Ngoài ra còn phải tìm hiểu, tham khảo các ý kiến của đội phát triển phần mềm, đội bảo trì phần mềm, đội kiểm thử, đội triển khai phần mềm. Vì lẽ đó, kiến trúc phần mềm phải là nơi thỏa mãn được các quan điểm, các yêu cầu của những nguồn khác nhau.
Và điều đó cũng đặt ra yêu cầu cho việc phải đảm bảo ngay từ giai đoạn xây dựng kiến trúc phần mềm, đã phải thỏa mãn các quan điểm, yêu cầu của những nguồn khác nhau; trước khi giai đoạn phát triển phần mềm được thực hiện. [2] Lý giải sự quan trọng của kiến trúc phần mềm Có ba lý do chính để giải thích tầm quan trọng của kiến trúc phần mềm: - Hỗ trợ việc giao tiếp Hỗ trợ việc giao tiếp với các thành viên trong dự án. Kiến trúc phần mềm tái hiện một vẻ bề ngoài trừu tượng của hệ thống. Với sự trừu tượng hóa hệ thống với 6 các khái niệm dễ hiểu, những thành viên trong dự án sẽ chỉ cần vận dụng các kiến thức cơ bản của mình về hệ thống trong việc tìm hiểu, dàn xếp, phối hợp làm việc, và bàn bạc trao đổi với nhau.
- Giúp ra quyết định sớm hơn Việc ra quyết định được thực hiện sớm hơn. Kiến trúc phần mềm biểu thị các quyết định thiết kế dành cho hệ thống. Như vậy các đội tham gia phát triển, triển khai, kiểm thử và bảo trì phần mềm cũng như các nhóm người dùng và các cấp quản lý sẽ có cái nhìn tổng quan hơn cũng như sớm hơn về hệ thống ngay từ khi nó còn sơ khai. Mỗi đội đó sẽ có các đóng góp ý kiến của mình, các đề xuất cũng như các phản bác của mình khi mọi chuyện chưa quá muộn.
Nếu không có quyết định sớm, thì khi phần mềm đã được xây dựng hoàn chỉnh hoặc khá hoàn chỉnh mà đột ngột xuất hiện các yêu cầu thay đổi từ phía nhóm này hoặc nhóm khác, ngoài việc gây trì trệ cho tiến độ công việc mà còn có thể gây ra tâm lý căng thẳng, mâu thuẫn giữa các đội tham gia trong dự án. - Tính khả chuyển cho hệ thống Kiến trúc phần mềm không phụ thuộc vào một ngôn ngữ cụ thể nào cả mà chỉ tuân theo một số chuẩn của các ngôn ngữ đặc tả nó. Ngoài ra, kiến trúc phần mềm khi được xây dựng cho một hệ thống, nó tạo thành một mô hình có sự gắn kết tương đối với hệ thống. Kiến trúc phần mềm còn chỉ ra cách thức mà phần mềm làm việc với hệ thống.
Do vậy, khi ta muốn chuyển phần mềm sang làm việc ở các hệ thống khác có những điểm tương đồng nhất định với hệ thống cũ thì phần mềm này cũng sẽ có các thuộc tính chất lượng và các yêu cầu chức năng được đảm bảo là không quá khác so với khi tồn tại ở hệ thống cũ.2 Quản trị kiến trúc HTTT Lĩnh vực nghiên cứu về Kiến trúc tổng thể (gọi tắt là EA – Enterprise Architecture) có thể coi bắt đầu từ năm 1987, khi J. Zachman công bố bài viết "một khung cho kiến trúc các hệ thống thông tin- A framework for Information System Architecture" trên tạp chí hệ thống của IBM (the IBM Systems Journal). Trong bài viết này, Zanchman chỉ ra cả thách thức và tầm nhìn của EA. Khung kiến 7 trúc hệ thống thông tin của Zachman sau đó sớm được đổi tên thành khung EA.
Trên cơ sở lí thuyết của mình, Zachman đã có đóng góp chính trong những nỗ lực đầu tiên của Bộ Quốc phòng Mỹ để tạo ra một EA. Nỗ lực này được biết đến là Khung kiến trúc kỹ thuật cho quản lý thông tin – TAFIM (Technical Architecture Framework for Information Management) được giới thiệu năm 1994. [11] Sau 25 năm phát triển đến nay đã có hàng chục khung/phương pháp luận kiến trúc hệ thống ra đời. Một trong những nơi áp dụng kiến trúc hệ thống mạnh nhất là các hệ thống chính phủ điện tử.
Nước Mỹ có Khung Kiến trúc Liên bang (FEAF) và Kiến trúc Hành chính Liên bang (FEA) áp dụng cho các cơ quan quản lý nhà nước. Bộ Quốc phòng Mỹ lại có kiến trúc riêng của mình DoDAF. Chính phủ Đức có Chuẩn và Kiến trúc cho Chính phủ điện tử SAGA. Nhiều nước khác cũng có khung/kiến trúc chính phủ điện tử của mình.
Đáng chú ý là Nga, một nước đi sau trong việc xây dựng chính phủ điện tử, đã chủ trương “xây dựng từng bước chính phủ điện tử bắt đầu từ phát triển kiến trúc hệ thống”. Tại Việt Nam, ngày 21/4/2015, Bộ Thông tin và Truyền thông có Văn bản số 1178/BTTTT-THH ban hành Khung Kiến trúc Chính phủ điện tử Việt Nam Phiên bản 1.vn/tin-tuc/1707/bo- thong-tin-va-truyen-thong-ban-hanh-khung-kien-truc-chinh-phu-dien-tu-viet-nam- phien-ban-1-0). Các doanh nghiệp lớn cũng là nơi xây dựng và áp dụng kiến trúc hệ thống mạnh mẽ. Trong danh sách 27 công ty được giải “Annual Enterprise & IT Architecture Excellence Award 2012” có thể thấy những tên tuổi lớn như Credit Suisse, Intel, v.v… Trong các công ty lớn hiện có một chức danh: Nhà kiến trúc doanh nghiệp (Enterprise Architect).
Các công ty tin học, tư vấn lớn cũng có các sản phẩm là các khung/phương pháp luận, giải pháp phần mềm, dịch vụ tư vấn xây dựng kiến trúc: IBM, Microsoft, Gartner,… Các công ty, tổ chức chuyên nghiên cứu về kiến trúc hệ thống liên tục phát triển, cập nhật sản phẩm của mình. Khung kiến trúc TOGAF phiên bản 1.0 (1995) 8 hiện đã có phiên bản 9.1 (2011), khung Zachman hiện có phiên bản 3.0, … Số lượng khung/kiến trúc hệ thống nhiều đến mức đã xuất hiện một hướng nghiên cứu: xây dựng các công cụ để người sử dụng có thể tìm kiếm, đánh giá, lựa chọn, sửa đổi các khung/kiến trúc phù hợp. [1] Các công cụ “vẽ” kiến trúc: cũng như kiến trúc xây dựng có ngôn ngữ chung là các bản vẽ xây dựng, kiến trúc hệ thống hiện nay cũng có nhiều loại ngôn ngữ mô hình kiến trúc (Enterprise architecture modelling language) khác nhau cần được lựa chọn trước. Toàn bộ kiến trúc mô tả bằng 1 ngôn ngữ sẽ giúp các “người liên quan” (stackeholders) hiểu được, chia sẻ được công việc cho nhau.
Ngoài ra, cũng có nhiều phần mềm hỗ trợ việc xây dựng kiến trúc hệ thống nhanh, chính xác và dễ sử dụng lại hơn là làm bằng tay. Trong thời gian qua, đã có nhiều phương pháp luận (methodology) về Kiến trúc doanh nghiệp được xây dựng. Tuy nhiên, hiện nay hầu hết các Kiến trúc doanh nghiệp được xây dựng dựa trên một số khung kiến trúc và phương pháp luận chính như: Khung Zachman (Zachman- Framework; Khung kiến trúc nhóm mở - TOGAF (Open Group Architectural Framework); Phương pháp luận Gartner (Gartner Methodology), FEA (của Mỹ), SAGA (của Đức), OIO (của Đan Mạch). Đối với đa số các cơ quan, không có phương pháp luận nào là hoàn hảo để xây dựng Kiến trúc doanh nghiệp, vì vậy đòi hỏi phải có sự chọn lọc, kết hợp nhiều phương pháp để đáp ứng nhu cầu của cơ quan, tổ chức.
Điều này nói lên, cũng như quy hoạch kiến trúc tổng thể cho các dự án xây dựng, kiến trúc hệ thống là nội dung cơ bản cần đi trước một bước khi phát triển một hệ thống thông tin lớn và phức tạp. Vậy khung kiến trúc doanh nghiệp là gì? Tại sao lại cần có nó Để thống nhất những vấn đề của tổ chức, tạo một khuôn khổ chung và đảm bảo tính tương thích của các hệ thống với nhau, chúng ta cần xây dựng và ban hành một khung kiến trúc hệ thống chung cho tổ chức. Có nhiều định nghĩa khung kiến trúc, dưới đây đưa ra một định nghĩa theo ISO/IEC/IEEE 42010: 9 “An architecture framework establishes a common practice for creating, interpreting, analyzing and using architecture descriptions within a particular domain of application or stakeholder community.