Kỹ thuật

Vài suy nghĩ về Chính phủ điện tử Việt nam (phần 2)

Vài suy nghĩ về Chính phủ điện tử Việt nam (phần 2)

(Bài đã đăng trên tạp chí Tin học & Đời sống 5/2012)

2- Kiến trúc, khung kiến trúc CPĐT.

CPĐT là một lĩnh vực mới bắt đầu phát triển từ cuối những năm 90 và hiện còn đang trong quá trình phát triển. Vì vậy có rất nhiều điều còn chưa rõ ràng, có nhiều cách hiểu, cách làm khác nhau. Dưới đây là vài ví dụ:

Khái niệm khung (framework) được hiểu khác nhau. Zachman định nghĩa khung 1 như một sơ đồ phân loại; TOGAF lại coi khung là “một phương pháp chi tiết và bộ công cụ hỗ trợ để phát triển một kiến trúc” 2, Roger Sessions coi khung kiến trúc “là một cấu trúc khung xương – skeleton structure” 3, kiến trúc FEA của Mỹ cũng được coi như một framework, v.v….

Ngay trong một loại khung kiến trúc, nội dung cũng khác nhau. Khung CPĐT của Uganda 4 có nội dung khá đơn giản, trong khi đó khung CPĐT của Mỹ 5 tương đối đầy đủ và phức tạp.

Trong CPĐT có nhiều loại khung: khung kiến trúc, khung pháp lý, khung kỹ thuật, khung tương hợp, v.v… Trong một khung lại có thể có các khung khác.

Vấn đề phức tạp, rối đến mức mà có chuyên gia phải viết cả một quyển sách “Làm thế nào để sống sót trong rừng rậm các khung kiến trúc” 6.

Vì vậy, mặc dù khung CPĐT do tư vấn nước ngoài xây dựng, nhưng về phía chúng ta cũng cần có những nghiên cứu nhất định để có thể ra đầu bài, hiểu, điều khiển và đánh giá, nghiệm thu được kết quả của tư vấn. Qua tham khảo một số công trình nghiên cứu trong nước, xin có vài đề xuất rút kinh nghiệm cho lần này.

Ý tưởng chung là đi vào một khu “rừng rậm” như đã dẫn ở trên, có nhiều góc nhìn khác nhau, nhiều phương pháp tiếp cận, nhiều loại công cụ. Cần chọn ra, tạo ra những cái của riêng mình, phù hợp với điều kiện đặc thủ của mình ngay trước khi bước vào khám phá nếu không muốn bị lâm vào tình trạng “chỉ thấy cây mà không thấy rừng”, hoặc bước vào rừng với hai bàn tay không, nhìn bằng con mắt người khác, phó mặc cho người dẫn dắt.

Dưới đây nêu lên vài điều cần lưu ý khi chọn phương pháp, công cụ “ đi rừng”, chưa bàn đến các vấn đề kỹ thuật cụ thể.

a) Chọn phương pháp luận để xây dựng khung CPĐT

Theo một nghiên cứu gần đây 7, khoảng 90% kiến trúc tổ chức (tạm dịch cụm từ enterprise architecture, mà kiến trúc CPĐT là một trường hợp riêng) được xây dựng dùng một trong 4 phương pháp luận (methodology) sau:

  • Khung kiến trúc Zachman (The Zachman Framework for Enterprise Architectures) 8: là một hệ thống phân loại (taxonomy), mô tả các thành phần kiến trúc phải có dưới góc nhìn khác nhau của những người liên quan. Nhưng có nhiều vấn đề quan trọng không được Zachman đề cập tới. Nó cũng không chỉ cách xây dựng một kiến trúc mới như thế nào.
  • Khung kiến trúc TOGAF (The Open Group Architectural Framework – TOGAF) 9: là một phương pháp (method) hướng dẫn chi tiết cách xây dựng một kiến trúc kèm theo các công cụ hỗ trợ, nhưng lại không chỉ cách làm thế nào xây dựng một kiến trúc tốt, cho nên kết quả có thể không như mong muốn.
  • Kiến trúc Chính phủ liên bang Mỹ (The Federal Enterprise Architecture – FEA) 10: không chỉ là 5 mô hình tham chiếu, mà còn có 4 tài liệu về phương pháp luận áp dụng và hướng dẫn từng bước. Vì vậy, FEA được xem là một phương pháp luận đầy đủ, kết hợp được cả hai phương pháp luận nói trên, có khung đánh giá kết quả. Mặc dù tên chính thức của nó là kiến trúc nhưng cũng được xem như một framework, kế thừa từ FEAF.
  • Phương pháp luận Gartner (The Gartner Methodology): Gartner là một công ty nghiên cứu và tư vấn về IT nổi tiếng 11. Phương pháp luận xây dựng kiến trúc của Gartner được đánh giá cao do uy tín và tay nghề (practise) của công ty 12 và do đó, phải do người của công ty thực hiện.

(Một nghiên cứu khác cho rằng hiện có 6 khung kiến trúc hàng đầu 13, nhưng điều đó chưa quan trọng ở đây).

Mỗi một phương pháp luận trên có ưu nhược điểm, điều kiện áp dụng riêng (và còn một số phương pháp khác 14). Việc lựa chọn một hoặc vài phương pháp hay tổ hợp các ưu điểm của nhiều phương pháp phù hợp với điều kiện nước ta phải là nội dung của một nghiên cứu riêng. Nhưng xét đến thực tế đội ngũ chuyên gia về kiến trúc tổng thể hiện nay, một trong những yêu cầu cần có là phương pháp luận phải có hướng dẫn áp dụng (method, guidance) rõ ràng, chi tiết và dễ hiểu.

Và điều quan trọng nữa, khi đã chọn phương pháp luận rồi phải theo đúng nó. Có những công trình nói là dựa vào TOGAF, FEA,… nhưng khi thực hiện chỉ dùng mỗi các mô hình tham chiếu là không đủ. Một ví dụ áp dụng pha sơ bộ của TOGAF vào CPĐT xem ở đây 15.

b) Chọn phương pháp để so sánh, đánh giá khung CPĐT

Khi đã có phương pháp luận, bước tiếp theo là so sánh, đánh giá một số khung CPĐT của các nước để rút kinh nghiệm và chọn ra một số mẫu. Nếu chỉ đơn thuần là liệt kê, mô tả kinh nghiệm các nước thì không đủ. Cần phải có phương pháp, tiêu chí để so sánh, đánh gíá khung CPĐT.

Mặt khác, xây dựng được một khung CPĐT rồi, làm sao biết nó tốt hay xấu để nghiệm thu? Cũng cần có phương pháp, tiêu chí thậm chí thang điểm theo yêu cầu đặt ra ban đầu.

Đã có một số công trình nghiên cứu về vấn đề này. Ví dụ: Roger Sessions 16 đưa ra nhiều tiêu chí để chấm điểm; Kostovska et al 17 đề xuất hẳn một phương pháp luận để đánh giá, v.v… Bộ Tài chính Phần lan có đưa ra một khung đánh giá hoạt động xây dựng CPĐT, mặc dù chưa đủ chi tiết theo nhu cầu của chúng ta, nhưng cũng đáng tham khảo 18

Phương pháp đánh giá khung CPĐT không đơn thuần chỉ là về mặt kỹ thuật. Nó phải thể hiện được đặc điểm cụ thể của quốc gia trong quá trình xây dựng CPĐT, thể hiện những trọng tâm cần nhấn mạnh và những mục tiêu đầu bài đặt ra cho việc xây dựng khung CPĐT. Ví dụ: nếu coi trọng cải cách hành chính hướng CPĐT thì phần mô hình nghiệp vụ phải được cho điểm số cao, nếu hướng tới phân quyền mạnh thì tính tương hợp phải được ưu tiên hàng đầu, v.v….. Các công cụ nói trên (phương pháp, tiêu chí, thang điểm hay khung) không phải là cố định, có thể tùy biến, sửa đổi, kết hợp để tạo nên một công cụ phù hợp với nhu cầu riêng.

Sau bước đánh giá, lựa chọn một cách có phương pháp như trên phải chỉ ra được cái khung ta cần có hình hài như thế nào, có những nội dung gì, chi tiết đến đâu, các mẫu đã chọn là gì và quan trọng nhất là tại sao lại quy định, chọn như vậy.

Tóm lại, đây cũng là vấn đề cần quan tâm và giải quyết trước khi bắt tay vào xây dựng khung CPĐT và là cơ sở để nghiệm thu.

c) Tính tương hợp và kiến trúc CPĐT

Ngay cả khi chưa có kiến trúc, một yêu cầu sống còn là các hệ thống ICT phải có tính tương hợp (interoperability) về mặt kỹ thuật: trao đổi thông suốt được dữ liệu với nhau và sử dụng được dữ liệu đó. Để đảm bảo tính tương hợp ở cấp độ này, các chính phủ thường ban hành một bộ chuẩn kỹ thuật hoặc khung tương hợp (interoperability frameworks) mà các hệ thống ICT nên hoặc phải tuân thủ.

Tuy nhiên theo nghĩa rộng của tính tương hợp: các cơ quan chính phủ làm việc được với nhau qua CPĐT 19 thì tương hợp kỹ thuật như nói trên là không đủ, CPĐT phải được xây dựng trên một kiến trúc chung 20, 21. Vì vậy có 3 cách để đảm bảo tính tương hợp: a/ Xây dựng đồng thời bộ chuẩn tương hợp và kiến trúc CPĐT 22, b/Xây dựng khung và/hoặc kiến trúc CPĐT trong đó một trong những nguyên tắc là đảm bảo tính tương hợp 23, tức là lồng ghép khung tương hợp vào nội dung kiến trúc hoặc c/Chia làm 2 giai đoạn: đầu tiên ban hành khung tương hợp (hoặc bộ chuẩn kỹ thuật), sau đó mới ban hành kiến trúc CPĐT 24.

Với đặc điểm tình hình cụ thể của Việt nam, cách thứ ba có vẻ hợp lý, kịp thời và khả thi hơn. Trong khi chờ đợi xây dựng và áp dụng khung và/hoặc kiến trúc CPĐT, cần có ngay một bộ chuẩn kỹ thuật tương hợp để tránh những phức tạp, tốn kém sau này. Đó là điều mà các quyết định và thông tư số 20/2008/QĐ-BTTTT, 01/2011/TT-BTTTT đã làm và cần tiếp tục hoàn thiện.

Nay đến giai đoạn xây dựng khung CPĐT, cần chú ý đưa việc đảm bảo tính tương hợp theo cách a/ hoặc b/ ở trên.

d) Chọn công cụ kiến trúc

Vấn đề này tuy không vĩ mô như những cái đã bàn ở trên, nhưng lại rất quan trọng nếu muốn áp dụng kiến trúc thành công. Một kiến trúc cụ thể được xây dựng và áp dụng có liên quan đến các yếu tố: a/Kế thừa kiến trúc cấp trên, b/Sử dụng lại những phần có thể của các kiến trúc ngang cấp, c/Chia sẻ các phần có thể dùng chung cho các đơn vị khác, d/Sửa đổi, cập nhật liên tục theo quá trình phát triển, e/ Truyền đạt xuống các cấp dưới để triển khai tiếp, áp dụng vào các sản phẩm cụ thể, f/ Nhiều người, nhiều bộ phận tham gia xây dựng, xét duyệt, triển khai dưới nhiều góc nhìn khác nhau v.v…

Tất cả những điều đó không thể thực hiện được nếu không có một ngôn ngữ chung và các công cụ phù hợp được thống nhất trong toàn hệ thống. Tương tự như ngôn ngữ bản vẽ kỹ thuật và các phần mềm thiết kế trong kiến trúc xây dựng, có hai vấn đề dưới đây nên được chỉ rõ và thống nhất sử dụng:

1- Ngôn ngữ mô hình kiến trúc ( enterprise architecture modeling language )

Một kiến trúc có rất nhiều đối tượng quan tâm (stackeholders) dưới nhiều góc nhìn (viewpoint) khác nhau và gồm nhiều loại mô hình khác nhau. Để các đối tượng đó có thể hiểu, thông tin với nhau, cần có ngôn ngữ chung.

Hiện nay, chưa có một ngôn ngữ duy nhất cho kiến trúc tổng thể (enterprise architecture) nói chung và kiến trúc CPĐT nói riêng 25. Vì vậy một bộ các ngôn ngữ phù hợp với từng lĩnh vực kiến trúc CPĐT (ArchiMate, BPMN, UML,…) nên được chọn và quy định thống nhất trong toàn hệ thống.

Sau khi đã quy định, ví dụ mô tả các quy trình nghiệp vụ bằng BPMN, các đoạn văn mô tả dài lê thê, các sơ đồ vẽ tùy ý mỗi nơi một kiểu sẽ không được phép tồn tại nữa. Cũng giống như những người tham gia xây dựng một công trình có thể hiểu nhau, cùng làm dựa trên các bản vẽ xây dựng, những người tham gia xây dựng CPĐT sẽ dễ dàng hiểu nhau, cùng phối hợp trên nền một bộ ngôn ngữ mô hình kiến trúc CPĐT chung.

2- Phần mềm xây dựng kiến trúc (enterprise architecture tools)

Nói đến CPĐT tức là nói đến phần mềm là công cụ cơ bản của nó. Vì vậy, xây dựng, bảo trì một kiến trúc CPĐT cụ thể cũng không thể thiếu phần mềm công cụ. Lợi ích của việc dùng phần mềm công cụ có lẽ không cần phải bàn cãi.

Xây dựng CPĐT tức là áp dụng phần mềm, truyền thông vào các công việc, dịch vụ của chính phủ. Vậy thì khi xây dựng kiến trúc CPĐT chẳng có lý do gì không dùng các phần mềm xây dựng kiến trúc hệ thống có sẵn.

Nghiên cứu, lựa chọn một hoặc nhiều phần mềm xây dựng kiến trúc hệ thống là nhiệm vụ của một đề tài riêng, nên được thực hiện và quy định thống nhất trong toàn hệ thống. Một số gợi ý, danh mục có thể xem tại 26, 27

e) Mô hình phát triển

Xây dựng CPĐT, nhất là vào giai đoạn hiện nay bắt đầu dựa vào khung và kiến trúc, chúng ta giống như những người lần đầu tiên xây dựng một ngôi nhà riêng cho mình. Kiến thức, kinh nghiệm, đội ngũ chuyên gia đều rất thiếu. Vì vậy:

  • Việc sử dụng tư vấn kỹ thuật nước ngoài là cần thiết. Nhưng có lẽ tư vấn nước ngoài về quản lý quá trình triển khai (ví dụ: quản lý gói thầu xây dựng khung CPĐT nói trên) cũng nên có, nhất là với những dự án đầu tiên.
  • Trong mọi lúc, mọi nơi có thể, cần sử dụng các công cụ có sẵn. Như ví dụ đã nêu ở trên, để tìm hiểu so sánh kinh nghiệm xây dựng CPĐT các nước cũng cần có một khung đánh giá và các tiêu chí cụ thể. Thực tế một số công trình đã thực hiện chưa chú ý sử dụng công cụ, suy luận theo nhận thức chủ quan, thậm chí chọn công cụ rồi nhưng không theo đến cùng. Đó là một điều đáng tiếc.
  • Thách thức lớn nhất với chúng ta khi bước vào xây dựng, áp dụng kiến trúc CPĐT như đã nói ở trên là kiến thức, kinh nghiệm, đội ngũ chuyên gia đều rất thiếu. Vì vậy, mô hình phát triển kiến trúc CPĐT cho các địa phương, bộ, ngành nên theo hướng “phát huy trí tuệ tập thể”: a/ Công khai hóa quá trình triển khai và các kết quả từng bước trên Internet để mọi người có thể tham gia, b/Chia sẻ, cho phép sử dụng chung các kết quả đạt được và c/Tiến tới xây dựng được một cộng đồng CPĐT bao gồm người quản lý, người thiết kế, người sử dụng, người thử nghiệm, đánh giá, v.v…. ở trong và ngoài nước có thể trao đổi, chia sẻ kinh nghiệm và các kết quả kiến trúc công khai trên mạng (tất nhiên là trừ những phần “mật”).
    Tóm lại là theo mô hình phát triển “mở” tương tự như mô hình phát triển Phần mềm Tự do Nguồn mở. Với nguồn lực nhân sự còn thiếu và yếu, có lẽ đó là cách duy nhất đảm bảo thành công khi triển khai đại trà.

3- Lời kết:

Các ý kiến nêu trên đây chỉ có tính chất gợi mở, đặt vấn đề. Các tài liệu đã dẫn cũng chỉ để nêu vấn đề, tham khảo, không có nghĩa là tài liệu tốt nhất, còn rất nhiều tài liệu khác tương tự. Mỗi vấn đề đặt ra đều đòi hỏi được nghiên cứu đầy đủ, bài bản và sâu sắc hơn bởi một đội ngũ chuyên gia dù chỉ để ra đầu bài, hiểu, điều khiển và đánh giá, nghiệm thu được kết quả của tư vấn.

Trước đây, người viết bài này cũng mới tìm hiểu được một phần về chiến lược và kiến trúc doanh nghiệp điện tử với dự định áp dụng nhưng không có điều kiện thực hiện. Tuy vậy, cũng mạnh dạn đóng góp vì lợi ích chung. Xin cám ơn anh Lê Trung Nghĩa, bộ KHCN đã giúp nhiều tài liệu tham khảo.

Hy vọng là có ích. Mọi ý kiến xin gửi về địa chỉ phanvinhtri@gmail.com.

Tài liệu trích dẫn:

1‘About The Zachman Framework TM’ <http://www.zachman.com/about-the-zachman-framework&gt; [accessed 11 March 2012].

2‘TOGAF® 9.1’, p. 3 <http://pubs.opengroup.org/architecture/togaf9-doc/arch/index.html&gt; [accessed 19 March 2012].

3‘A Comparison of the Top Four Enterprise-Architecture Methodologies’ <http://msdn.microsoft.com/en-us/library/bb466232.aspx&gt; [accessed 18 March 2012].

4‘Uganda E-govt_framework_June 2010.pdf’ <http://www.nita.go.ug/uploads/Final%20Draft%20E-govt_framework_June%202010.pdf&gt; [accessed 28 March 2012].

5‘Federal Enterprise Architecture Framework’ <http://www.cio.gov/documents/fedarch1.pdf&gt; [accessed 7 April 2012].

6‘How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating … – Jaap Schekkerman – Google Sách’ <http://books.google.com.vn/books/about/How_to_survive_in_the_jungle_of_enterpri.html?id=k_9cUrpT4lsC&redir_esc=y&gt; [accessed 12 March 2012].

7‘A Comparison of the Top Four Enterprise-Architecture Methodologies’.

8‘Zachman International® – The Official Home of The Zachman Framework TM’ <http://www.zachman.com/&gt; [accessed 19 March 2012].

9‘TOGAF® 9.1’.

10‘Federal Enterprise Architecture (FEA) | The White House’ <http://www.whitehouse.gov/omb/e-gov/fea&gt; [accessed 14 April 2012].

11‘Why Gartner Is Critical To Your Business’ <http://www.gartner.com/technology/why_gartner.jsp&gt; [accessed 12 April 2012].

12‘The New Enterprise Architecture (Gartner)’ <http://www.gartner.com/pages/story.php.id.2226.s.8.jsp&gt; [accessed 12 April 2012].

13‘Comparison of the Top Six Enterprise Architecture Frameworks’ <http://www.cioindex.com/enterprise_architecture.aspx&gt; [accessed 16 April 2012].

14‘Enterprise Architecture (EA) Frameworks List | DesktopAuditing’ <http://www.desktopauditing.com/enterprise-architecture-ea-frameworks-list&gt; [accessed 19 March 2012].

15‘Dok_eGov-Basic-Concepts.pdf’ <http://147.86.7.23/wikigov/images/b/b0/Dok_eGov-Basic-Concepts.pdf&gt; [accessed 14 April 2012].

16‘A Comparison of the Top Four Enterprise-Architecture Methodologies’.

17‘Evaluation Methodology for National Enterprise Architecture Frameworks.pdf’ <http://www.ictinnovations.org/htmls/papers/ictinnovations2010_submission_20.pdf&gt; [accessed 20 March 2012].

18‘Overview of Enterprose Architecture Work in 15 Countries’ <http://www.vm.fi/vm/en/04_publications_and_documents/01_publications/04_public_management/20071102Overvi/FEAR_ENGLANTI_kokonaan.pdf&gt; [accessed 16 April 2012].

19‘Undp-gif-overview.pdf’, p. 1 <http://www.ibm.com/ibm/governmentalprograms/undp-gif-overview.pdf&gt; [accessed 20 March 2012].

20‘Undp-gif-overview.pdf’, p. 2.

21‘Interoperability Frameworks and Enterprise Architectures in Egovernment Initiatives in Europe and the United States’, p. 13 <http://www.upv.es/~lguijar/nova/investigacio/pubs/Guijarro2007SelfArchive.pdf&gt; [accessed 29 March 2012].

23‘Danish White Paper on Enterprise Architecture’, p. 41 <http://en.itst.dk/it-architecture-standards/publications/whitepaper-on-it-architecture/whitepaper.pdf&gt; [accessed 13 April 2012].

24‘Interoperability Frameworks and Enterprise Architectures in Egovernment Initiatives in Europe and the United States’, p. 20.

25‘Enterprise Architecture Tool Selection Guide V6.3.pdf’ <http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v6.3.pdf&gt; [accessed 16 April 2012].

26‘Enterprise Architecture Tools, Institute For Enterprise Architecture Developments (IFEAD)’ <http://www.enterprise-architecture.info/EA_Tools.htm&gt; [accessed 16 April 2012].

27‘Enterprise Architecture Tool Selection Guide V6.3.pdf’.

Về nền tảng M$.

Đặt vấn đề : Muốn ủng hộ Phần mềm tự do nguồn mở (FOSS) thì trước hết cần nghiên cứu kỹ đối thủ của nguồn mở là nguồn đóng,  mà Trùm Sò là chú Táo khuyết Apple và chú Biu M$, vậy nên tìm hiểu xem các chú ấy có cái gì hè ?  :-D
Đây là phần chú Biu M$

Only Microsoft brings you a complete set of innovative
platforms and technologies that help you shape the future.  Whether you develop
for mobile, desktop, or the cloud–you are always playing in a single universe
of devices and services. It’s time to go exploring.

Chỉ M$ mới mang đến cho bạn một bộ hoàn chỉnh các nền tảng sáng tạo và công nghệ, giúp bạn định hình tương lai. Cho dù bạn phát triển phần mềm cho điện thoại di động, máy tính để bàn, hoặc điện toán đám mây – bạn luôn được chơi trong một thế giới các thiết bị và dịch vụ thống nhất. Hãy để chút thời gian khám phá…

(Chú Biu gáy to ghê)


Featured platforms and tools



Windows logo

Windows
Reach more people on more devices in 200 markets worldwide.
Visit the Dev Center



Windows Phone logo

Windows Phone

Discover the fastest-growing mobile OS on the market.

Visit the Dev Center

 

Windows Azure logo

Windows Azure

Need a cloud-based backend for your app? We’ve got you covered.

Visit the Dev Center


Office logo

Office

Develop productivity apps in their native environment—locally or in the cloud.

Visit the Dev Center



Xbox logo

Xbox

Imagine your game on more than 76 million consoles worldwide.

Visit the Dev Center

 

Visual Studio

Create a new breed of applications with these powerful tools.

Visit the Dev Center


Cloud and server


Windows Server logo

Windows Server

Discover the power and scalability of a Cloud OS.

Visit the Dev Center

 

SQL Server image

SQL Server

Turning big data into big insights begins here.

Visit the Dev Center


Windows Azure SQL logo

Windows Azure SQL Database

From backup to backend, cloud database applications are changing business.

Visit the Dev Center


BizTalk Server image

BizTalk Server

Extend your existing apps and connect cloud applications, mobile devices, and
external partners.

Visit the Dev Center


Business and enterprise


SharePoint logo

SharePoint

Apps that revolutionize work on the most popular collaboration platform in the
world. 

Visit the Dev Center



Exchange logo

Exchange

146 billion e-mails are sent per day. How will you enable better communications?

Visit the Dev Center



Lync logo

Lync

Tomorrow’s workplace is anywhere you are. Add your vision to the future.

Visit the Dev Center

 

Microsoft Dynamics logo

Dynamics

Resource planning is essential to companies and organizations. The only thing
missing is your idea.

Visit the Dev Center


More resources


Take a step:



Success stories
See how easy it is to develop with Microsoft—and how it pays off.
Watch now



Get social

Connect with tech advisors. Get some perspective. Attend an event.

Jump in



Get started

Kick off your project with Microsoft’s development tools. 

Download now




Serious fun

Ready to turn your game idea into reality?

Here’s your roadmap

Dev centers

 

 

Learning resources

Community

Support

Programs

ADM and the Zachman Framework


Introduction | The Zachman Framework | Mapping TOGAF to the Zachman Framework


This chapter provides a mapping of the TOGAF Architecture Development Method (ADM) to the Zachman Framework.

Introduction

A number of architecture frameworks exist, each of which has its particular advantages and disadvantages, and relevance, for enterprise architecture. Several are discussed in Other Architectures and Frameworks .

However, there is no accepted industry standard method for developing an enterprise architecture. The Open Group goal with TOGAF is to work towards making the TOGAF ADM just such an industry standard method, which can be used for developing the products associated with any recognized enterprise framework that the architect feels is appropriate for a particular architecture. The Open Group vision for TOGAF is as a vehicle and repository for practical, experience-based information on how to go about the process of enterprise architecture, providing a generic method with which specific sets of deliverables, specific reference models, and other relevant architectural assets can be integrated.

To illustrate the concept, this section provides a mapping of the various phases of the TOGAF ADM to the cells of the well-known Zachman Framework.

The Zachman Framework

The Zachman Framework for Enterprise Architecture, sometimes simply referred to as the “Zachman Framework”, has become a de facto standard for classifying the artifacts developed in enterprise architecture. It is a logical structure for classifying and organizing the design artifacts of an enterprise that are significant to its management. It draws on a classification scheme found in the more mature disciplines of architecture/construction and engineering/manufacturing, used for classifying and organizing the design artefacts relating to complex physical products such as a building or an aircraft. Zachman adopts this classification scheme to the design and construction of information systems.

The Zachman Framework comprises a 6×6 matrix.


The columns represent various aspects of the enterprise that can be described or modeled; and the rows represent various viewpoints from which the aspects can be described. Thus each cell formed by the intersection of a column and a row represents an aspect of the enterprise modeled from a particular viewpoint. The architect selects and models the cells that are appropriate to the immediate purpose, with the ultimate objective of modeling all the cells.

The six viewpoints are:

  1. The Scope (Contextual) viewpoint – aimed at the planner
  2. The Business Model (Conceptual) viewpoint – aimed at the owner
  3. The System (Logical) viewpoint – aimed at the designer
  4. The Technology (Physical) viewpoint – aimed at the builder
  5. The Detailed Representations (Out-of-Context) viewpoint – aimed at the subcontractor
  6. The Functioning Enterprise viewpoint

The six aspects – and the interrogatives to which they correspond – are:

  1. The Data aspect – What?
  2. The Function aspect – How?
  3. The Network aspect – Where?
  4. The People aspect – Who?
  5. The Time aspect – When?
  6. The Motivation aspect – Why?

Although the Zachman Framework applies to enterprises, the Framework itself is generic. It is a comprehensive, logical structure for the descriptive representations (i.e., models or design artefacts) of any complex object, and it does not prescribe or describe any particular method, representation technique, or automated tool.

The strength of the Framework is that it provides a way of thinking about an enterprise in an organized way, so that it can be described and analyzed. It also enables the individuals involved in producing enterprise information systems to focus on selected aspects of the system without losing sight of the overall enterprise context. In designing and building complex systems, such as enterprise systems, there are simply too many details and relationships to consider simultaneously. At the same time, isolating single variables and making design decisions out of context results in sub-optimization, with all the attendant costs and risks. The challenge is the same whether the system is physical (like an aircraft) or conceptual (like an enterprise system). How do you design and build it, piece by piece, and step by step, such that it achieves its purpose without losing its value and raising its cost by optimizing the pieces and sub-optimizing the overall?

Mapping TOGAF to the Zachman Framework

The scope of the four architecture domains of TOGAF align very well with the first four rows of the Zachman Framework, as shown in the following mapping of these domains.


Several domains overlap in the above diagram: the earliest domain to address a cell has precedence in the coloring scheme.

The mappings of the individual phases of the ADM are shown in detail below.

Note:
In addition to the mappings to specific cells given below, the detailed representations and functioning enterprise viewpoints (the lowest two rows) of the Zachman Framework are also addressed and represented in TOGAF, through the Architecture Governance Framework (see Architecture Governance Framework), and through ADM deliverables such as the various Architecture Contracts (see Architecture Contracts). These ensure the validity and viability of the delivered solutions to meet the business needs.

Preliminary Phase: Framework and Principles

The outputs of this phase are:

  • Framework DefinitionZF: Business/Function (model of the architecture development process)
    [R2,C2]
  • Architecture principlesZF: Scope/Data, Scope/Function, Scope/Network, Scope/People, Scope/Time, Scope/Motivation
    [R1,C1; R1,C2; R1,C3; R1,C4; R1,C5; R1,C6]
  • Restatement of, or reference to, business principles, business goals, and business driversZF: Composite of: Scope/Motivation, Business/Motivation
    [R1,C6; R2,C6]

Phase A: Architecture Vision

The outputs of this phase are:

  • Approved Statement of Architecture Work, including in particular:
    • Scope and constraintsZF: Scope/Data, Scope/Function, Scope/Network, Scope/People, Scope/Time
      [R1,C1; R1,C2; R1,C3; R1,C4; R1,C5; R1,C6]
      Note:
      The Scope/Motivation cell is presumed to be addressed by strategic business planning activities outside the scope of the Architecture Vision.
    • Plan for the architecture work
  • Refined statements of business principles, business goals, and strategic driversZF: Scope/Data, Scope/Motivation
    [R1,C1; R1,C6]
  • Architecture principles (if not previously existing)ZF: Scope/Data, Scope/Function, Scope/Network, Scope/People, Scope/Time, Scope/Motivation
    [R1,C1; R1,C2; R1,C3; R1,C4; R1,C5; R1,C6]
  • Architecture Vision/Business Scenario, including:
    • Baseline Business Architecture, Version 0.1ZF: Business/Data, Business/Function, Business/Network, Business/People, Business/Time, Business/Motivation
      [R2,C2; R2,C2; R2,C3; R2,C4; R2,C5; R2,C6]
    • Baseline Technology Architecture, Version 0.1ZF: System/Data, System/Function, System/Network, System/People, System/Time, System/Motivation
      [R3,C2; R3,C2; R3,C3; R3,C4; R3,C5; R3,C6]
    • Target Business Architecture, Version 0.1ZF: Business/Data, Business/Function, Business/Network, Business/People, Business/Time, Business/Motivation
      [R2,C2; R2,C2; R2,C3; R2,C4; R2,C5; R2,C6]
    • Target Technology Architecture, Version 0.1ZF: System/Data, System/Function, System/Network, System/People, System/Time, System/Motivation
      [R3,C2; R3,C2; R3,C3; R3,C4; R3,C5; R3,C6]

Phase B: Business Architecture

The outputs of this phase are:

  • Statement of Architecture Work (updated if necessary)
  • Validated business principles, business goals, and strategic driversZF: Scope/Data, Scope/Function, Scope/Network, Scope/People, Scope/Time
    [R1,C1; R1,C2; R1,C3; R1,C4; R1,C5; R1,C6]
  • Target Business Architecture, Version 1.0 (detailed)
    • Organization structure, identifying business locations and relating them to organizational unitsZF: Scope/Network, Scope/People, Business/Network, Business/People
      [R1,C3; R1,C4; R2,C3; R2,C4]
    • Business goals and objectives, for each organizational unitZF: Scope/Network, Scope/Time, Business/Network, Business/Time, Business/Motivation
      [R1,C3; R1,C5; R2,C3; R2,C5; R2,C6]
      Note:
      The Scope/Motivation cell is presumed to be addressed by strategic business planning activities outside the scope of the Business Architecture.
    • Business functions – a detailed, recursive step involving successive decomposition of major functional areas into sub-functionsZF: Scope/Function, Business/Function
      [R1,C2; R2,C2]
    • Business services – the services that each enterprise unit provides to its customers, both internally and externallyZF: Business/Function, System/Function
      [R2,C2; R3,C2]
    • Business processes, including measures and deliverablesZF: Business/Function, Business/Time
      [R2,C2; R2,C5]
    • Business roles, including development and modification of skills requirementsZF: Scope/People, Business/People
      [R1,C4; R2,C4]
    • Correlation of organization and functions; relate business functions to organizational units in the form of a matrix reportZF: Scope/Function, Scope/Network, Scope/People, Business/Function, Business/Network, Business/People
      [R1,C2; R1,C3; R1,C4; R2,C2; R2,C3; R2,C4]
  • Baseline Business Architecture, Version 1.0 (detailed), if appropriate
  • Views corresponding to the selected viewpoints addressing key stakeholder concerns
  • Gap analysis results
  • Technical requirements (drivers for the Technology Architecture work): identifying, categorizing, and prioritizing the implications for work in the remaining architecture domains; for example, by a dependency/priority matrix (e.g., guiding trade-off between speed of transaction processing and security); list the specific models that are expected to be produced (e.g., expressed as primitives of the Zachman Framework)ZF: System/Motivation
    [R3,C6]
  • Business Architecture Report
  • Updated business requirements

Note:
The Business/Data cell is covered by the Data and Applications Architectures.

Phase C: Informations System Architectures: Data Architecture

The outputs of this part of Phase C are:

  • Statement of Architecture Work (updated if necessary)
  • Baseline Data Architecture, Version 1.0, if appropriate
  • Validated principles, or new data principles (if generated here)ZF: Scope/Data, Scope/Network, Scope/People, Scope/Time
    [R1,C3; R1,C4; R1,C5]
  • Target Data Architecture, Version 1.0:
    • Business data modelZF: Business/Data
      [R2,C1]
    • Logical data modelZF: System/Data
      [R3,C1]
    • Data management process modelsZF: System/Function, System/People
      [R3,C2; R3,C3]
    • Data entity/business function matrixZF: Composite of Business/People, System/Data, System/Function
      [R2,C4; R3,C1; R3,C2]
    • Data interoperability requirementsZF: Composite of System/Data, System/Function, System/Network, System/People
      [R3,C1; R3,C2; R3,C3; R3,C4]
  • Viewpoints addressing key stakeholder concerns
  • Views corresponding to the selected viewpoints; for example:
    • Data dissemination viewZF: Composite of System/Data, System/Function, System/Network, System/People
      [R3,C1; R3,C2; R3,C3; R3,C4]
    • Data lifecycle viewZF: Composite of System/Data, System/Function, System/Time
    • Data security viewZF: Composite of System/Function, System/Data, System/Network, System/People, System/Time
    • Data model management viewZF: Composite of Business/Data, System/Data, Business/Time, System/Time
  • Gap analysis results
  • Relevant technical requirements that will apply to this evolution of the architecture development cycleZF: System/Motivation
  • Data Architecture Report, summarizing what was done and the key findings
  • Impact Analysis
  • Updated business requirements, if appropriate

Phase C: Informations System Architectures: Applications Architecture

The outputs of this part of Phase C are:

  • Statement of Architecture Work (updated if necessary)
  • Baseline Applications Architecture, Version 1.0, if appropriate
  • Validated application principles, or new application principles (if generated here)ZF: Scope/Function, Scope/Network, Scope/People, Scope/Time
  • Target Applications Architecture, Version 1.0:
    • Process systems modelZF: System/Function
    • Systems/place modelZF: System/Network
    • People/systems modelZF: System/People
    • Systems/time modelZF: System/Time
    • Applications interoperability requirementsZF: Composite of System/Data, System/Function, System/Network, System/People, System/Time, System/Motivation
  • Viewpoints addressing key stakeholder concerns
  • Views corresponding to the selected viewpoints; for example:
    • Common applications services viewZF: Composite of System/Data, System/Function, System/Network, System/People, System/Time
    • Applications interoperability viewZF: Composite of System/Data, System/Function, System/Network, System/Time
    • Applications/information viewZF: Composite of System/Data, System/Function, System/Network, System/Time
    • Applications/user locations viewZF: Composite of System/Network, System/People
  • Gap analysis results
    • Areas where the Business Architecture may need to change to cater for changes in the Applications ArchitectureZF: Composite of Business/Data, Business/Function, Business/Network, Business/People, Business/Time
    • Identify any areas where the Data Architecture (if generated at this point) may need to change to cater for changes in the Applications ArchitectureZF: Composite of Business/Data, Business/People, Business/Time
    • Identify any constraints on the Technology Architecture about to be designedZF: System/Motivation
  • Applications Architecture Report, summarizing what was done and the key findings
  • Impact Analysis
  • Updated business requirements, if appropriate

Phase D: Technology Architecture

The outputs of Phase D are given below, first by relevant individual step, and then as a composite for the whole phase.

Step 1: Create a Baseline Description in the TOGAF Format

The outputs of this step are:

  • Technology Architecture principles (if not existing)ZF: Scope/Data, Scope/Function, Scope/Network, Scope/People, Scope/Time, Scope/Motivation
  • Target Technology Architecture, Version 0.2:
    • Technology Architecture – Constraints
    • Technology Architecture – Architecture Principles
    • Technology Architecture – Requirements Traceability, key questions list
    • Technology Architecture – Requirements Traceability, criteria for selection of service portfolio
    • Technology Architecture Model, Version 0.1ZF: Technology/Function, Technology/Network

Step 2: Consider Different Architecture Reference Models, Viewpoints, and Tools

The outputs of this step are:

  • Target Technology Architecture, Version 0.3
    • Technology Architecture – Architecture Viewpoints
      • Networked computing/hardware viewZF: System/Network, Technology/Network
      • Communications viewZF: Composite of: System/Network, System/People, Technology/Network, Technology/People
      • Processing viewZF: System/Data, System/Function, System/Network, System/People, System/Time, Technology/Data, Technology/Function, Technology/Network, Technology/People, Technology/Time
      • Cost viewZF: Technology/Motivation
      • Standards viewZF: Technology/Motivation
    • Technology Architecture – ConstraintsZF: System/Motivation

Step 3: Create an Architectural Model of Building Blocks

The outputs of this step are:

  • Target Technology Architecture, Version 0.4
    • Technology Architecture Model
      • Networked computing/hardware viewZF: Technology/Network, System/Network
      • Communications viewZF: Composite of: Technology/Network, Technology/People, System/Network, System/People
      • Processing viewZF: Technology/Network, Technology/Time, Technology/People, Technology/Data, Technology/Function, System/Network, System/Time, System/People, System/Data, System/Function
      • Cost viewZF: Technology/Motivation
      • Standards viewZF: Technology/Motivation
    • Technology Architecture – change requests and/or extensions or amendments to be incorporated in an organization-specific Architecture Continuum

Step 4: Select the Services Portfolio Required per Building Block

The outputs of this step are:

  • Target Technology Architecture, Version 0.5
    • Technology Architecture – target services (a description of the service portfolios required also known as an Organization-Specific Framework)ZF: Technology/Network, Technology/Time, Technology/People, Technology/Data, Technology/Function, Technology/Motivation
    • Technology Architecture – change requests and/or extensions or amendments to be incorporated in an organization-specific Architecture Continuum

Step 8: Conduct a Gap Analysis

The outputs of this step are:

  • Target Technology Architecture, Version 1.0:
    • Technology Architecture – gap reportZF: Composite of Technology/Data, Technology/ Function, Technology/Network, Technology/People, Technology/Time, Technology/Motivation

Composite Mapping for Phase D


For more detailed information on the Zachman Framework, refer to any of John Zachman’s publications, or the Zachman Institute for Framework Advancement (ZIFA) (www.zifa.com).
return to top of page


Navigation

The TOGAF document set is designed for use with frames. To navigate around the document:

  • In the main Contents frame at the top of the page, click the relevant hyperlink (Part I, Part II, etc.) to load the Contents List for that Part of the TOGAF document into the Secondary Index frame in the left margin.
  • Then click in that Contents List to load a page into this main frame.

return to top of page


Downloads

Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063.