Một hướng dẫn thiết thực để phát triển kiến trúc doanh nghiệp

Để phát triển một kiến trúc doanh nghiệp (EA) có ích, điều quan trọng trước tiên là cần hiểu được các câu hỏi mà bạn muốn trả lời với kiến trúc của bạn. Sau đó, dựa trên các câu hỏi này, bạn có thể phát triển một cách tiếp cận và xác định các mô hình mà bạn cần. Cuối cùng, bạn có thể thực hiện phân tích định lượng và định tính trên kiến trúc của bạn hoặc để xem có thể cải thiện nghiệp vụ ở đâu hoặc để xác định các thay đổi hoặc cải tiến cần thiết với kiến trúc đó. Bài này đưa ra một bản tóm tắt của một chương trình kiến trúc doanh nghiệp và các quy trình của nó.

Franki Schafrik, Kiến trúc sư doanh nghiệp cao cấp, IBM

Photo of Franki SchafrikFranki Schafrik có 17 năm kinh nghiệm về sử dụng Rational System Architect. Cô có 20 năm kinh nghiệm tư vấn về Kiến trúc doanh nghiệp với các khách hàng chính phủ và thương mại trên toàn thế giới. Cô dạy các phương pháp luận DoDAF và EA ở nhiều nước.



14 02 2012

Kiến trúc doanh nghiệp là một tổ chức lô-gic của một doanh nghiệp và dữ liệu hỗ trợ, các ứng dụng và cơ sở hạ tầng CNTT của nó, với các đích và các mục tiêu được xác định rõ ràng cho sự thành công trong tương lai của doanh nghiệp này. Một kiến trúc điển hình gồm có các sơ đồ hoặc các mô hình, cho thấy các khía cạnh của doanh nghiệp liên hệ với nhau như thế nào. Ví dụ, một biểu đồ tổ chức là một mô hình về cách các đơn vị nghiệp vụ liên hệ với nhau như thế nào.

Các doanh nghiệp cần có một kiến trúc "như hiện trạng" mô tả trạng thái hiện tại của nó và một kiến trúc theo kế hoạch cho thấy hướng phát triển của doanh nghiệp trong 1 đến 5 năm tới.

Kiến trúc doanh nghiệp sắp hàng các lĩnh vực chính sau đây. Lưu ý các ví dụ trong từng lĩnh vực:

  • Nghiệp vụ: Các quy trình, các chiến lược, các biểu đồ tổ chức và các chức năng.
  • Thông tin: Các mô hình khái niệm, lô-gic và vật lý của dữ liệu cho thấy những thông tin nào cần thiết và nó liên quan đến các thông tin khác như thế nào. Ví dụ, một khách hàng và một đơn đặt hàng.
  • Ứng dụng: danh mục các ứng dụng, các giao diện và các dịch vụ.
  • Cơ sở hạ tầng: Các sơ đồ khái niệm mạng, các mô hình tham chiếu công nghệ.

Để đạt được sự sắp hàng này, bạn mô hình hóa từng lĩnh vực then chốt theo phối cảnh riêng của nó và sau đó liên kết các mô hình từ mỗi phối cảnh. Ví dụ, mô hình hóa các quy trình nghiệp vụ từ góc độ nghiệp vụ. Không bao gồm những thứ như các ứng dụng. Sau đó, liên kết các quy trình nghiệp vụ với các ứng dụng hỗ trợ chúng, giúp bạn có được sự sắp hàng. Chúng ta làm điều này để đảm bảo rằng mọi quyết định đều dựa trên một nhu cầu nghiệp vụ; do đó, một ứng dụng không áp đặt cách thiết kế một quy trình nghiệp vụ.

Trong suốt bài này, chúng tôi giả định rằng bạn có một công cụ mô hình hóa để tạo ra kiến trúc của mình. Các thông tin thực hiện cụ thể trong bài này được dựa trên Rational System Architect (Kiến trúc sư hệ thống Rational).

"Chúng tôi đang làm kiến trúc ... để làm kiến trúc!"

Hình 1. Nếu bạn không có một mục đích, dự án của bạn sẽ thất bại
Một người đang đập bàn phím vào mũ của anh ta

Cách đơn giản nhất để đảm bảo rằng kiến trúc của bạn thất bại là không có một mục đích để làm kiến trúc. Tôi đã làm các dự án kiến trúc với hàng trăm khách hàng. Khi các dự án không thành công, tôi hỏi tại sao họ muốn tạo một kiến trúc doanh nghiệp. Họ trả lời, "Vì chúng tôi cần một kiến trúc!"

Bước 1. Xác định mục đích của kiến trúc của bạn

Bạn có thể xác định mục đích của kiến trúc của mình bằng cách hỏi các câu hỏi sau đây:

  • Những thông tin nào quan trọng với kiến trúc?
  • Cần chi tiết đến mức nào để hỗ trợ phân tích và ra quyết định?
  • Ai sẽ tạo hoặc sử dụng kiến trúc?
  • Lợi nhuận dự kiến của kiến trúc là gì?
  • Các lý do bảo trì là những gì?

Nếu bạn không thể trả lời được những câu hỏi này, dự án kiến trúc của bạn có thể sẽ thất bại. Không có một mục đích cụ thể, bạn có thể lãng phí hàng tháng vẽ các sơ đồ quy trình nghiệp vụ mà chẳng ai quan tâm đến. Hoặc bạn có thể vẽ các sơ đồ phức tạp về các giao diện ứng dụng mà không thể được trình bày cho các nhà quản lý cấp cao vì nó sẽ làm rối tung đầu họ.

Ví dụ, đối với một chuỗi khách sạn, các nhà quản lý khách sạn đã được xác định là đối tượng người xem kiến trúc doanh nghiệp.

Khi biết mục đích của kiến trúc, bạn có thể xác định phạm vi các mô hình và dữ liệu cần thiết để đảm bảo mọi người sử dụng kiến trúc của bạn cho các phân tích và quyết định nghiệp vụ.

Đừng quá nhiệt tình lao ngay vào kiến trúc. Thậm chí nếu bạn có một nhóm kiến trúc rất lớn và có kinh nghiệm, bạn sẽ không thể nắm bắt tất cả các thông tin về tổ chức của mình.

Ngoài ra điều quan trọng cần nhớ là kiến trúc toàn diện có thể làm rối những điều quan trọng. Ví dụ, chẳng có lý do nào nắm giữ 5.000 quy trình nghiệp vụ nếu chỉ có 50 trong số đó là quan trọng đối với nghiệp vụ của bạn. Hãy định rõ các câu hỏi nghiệp vụ quan trọng của bạn và sử dụng chúng làm trung tâm của dự án kiến trúc đầu tiên của mình.

Hình 2. Kiến trúc cung cấp một con đường để trả lời các câu hỏi
Người leo núi là người đầu tiên trên sườn dốc

Bước 2. Xác định các câu hỏi nghiệp vụ của bạn

Điều đầu tiên mà tôi làm với một khách hàng là thảo luận các câu hỏi trọng yếu với nghiệp vụ của họ; rồi giúp họ xác định những câu hỏi mà họ khó trả lời. Các câu hỏi sau đây là những câu hỏi mà nhiều khách hàng cần trả lời:

Mục đích làm kiến trúc của khách sạn là để cải thiện quá trình đăng ký nhận phòng và trả phòng để họ có thể trở nên cạnh tranh hơn.

  • Tác động của việc loại bỏ một ứng dụng là gì?
  • Tác động của di chuyển một vị trí là gì?
  • Những ứng dụng nào cần thiết để hỗ trợ một quy trình nghiệp vụ?
  • Tác động của việc thay thế các máy chủ là gì?
  • Những quy trình nào cần được phát triển để hỗ trợ một chiến lược mới?
  • Ở đâu có các khoảng hụt hẫng hoặc các dư thừa trong danh mục các ứng dụng của chúng ta?

Câu hỏi của bạn điều khiển nội dung kiến trúc của bạn. Nếu hầu hết các câu hỏi liên quan đến danh mục các ứng dụng của bạn, thì hãy tập trung vào xác định lĩnh vực ứng dụng. Nếu bạn cần hiểu rõ các quy trình của bạn hỗ trợ một chiến lược mới như thế nào, thì hãy tập trung vào lĩnh vực nghiệp vụ. Sau đó, bạn có thể bắt đầu mở rộng phạm vi kiến trúc của mình với các câu hỏi nghiệp vụ mới.


Bước 3. Xác định các giả định và các quy tắc nghiệp vụ

Bây giờ bạn đã xác định được đối tượng người xem, mục đích và các câu hỏi, bạn cần xác định các quy tắc nghiệp vụ ràng buộc hoặc giải thích các lĩnh vực được quan tâm.

Mọi nghiệp vụ đều có các quy tắc. Ví dụ, khi bạn nắm bắt thông tin về các quy trình nghiệp vụ quan trọng, bạn cũng phải nắm bắt bất kỳ các quy định hoặc các tiêu chuẩn của công ty đối với quy trình này. Một ví dụ về một quy định là HIPAA (Health Insurance Portability and Accountability Act - Đạo luật về Trao đổi và Trách nhiệm về Bảo hiểm sức khỏe), nhằm bảo vệ phạm vi bảo hiểm sức khỏe cho những người thay đổi việc làm. Theo đó một quy định của công ty sẽ được tạo ra để cho thấy công ty này đang đáp ứng các yêu cầu của HIPAA.

Bạn cần nắm bắt các giả định về kiến trúc của mình, ví dụ như "Thông tin ứng dụng mới sẽ được tải lên vào thứ Sáu" hay "Mỗi đơn vị nghiệp vụ có trách nhiệm ghi lại các quy trình nghiệp vụ".


Bước 4. Xác định khung công tác của bạn

Các khung công tác theo tiêu chuẩn công nghiệp sau đây có thể giúp bạn tạo ra một kiến trúc doanh nghiệp:

  • ToGAF
  • Zachman
  • EA3
  • DoDAF

Việc sử dụng một khung công tác tiêu chuẩn cung cấp cho kiến trúc của bạn một "bộ khung" nhờ đó bạn có thể xây dựng nên các mô hình của mình.

Một khung công tác cũng cung cấp hướng dẫn bạn cần nắm bắt những thông tin nào dựa trên các bên liên quan, những người sẽ sử dụng kiến trúc. Nó cung cấp hướng dẫn việc tổ chức thông tin nhưng không đề xuất một cách thực hiện cụ thể cho kiến trúc của bạn.

Có rất nhiều thông tin trên Internet về các khung công tác này. Khung công tác mà bạn chọn phụ thuộc vào mục tiêu kiến trúc của mình, kinh nghiệm của nhóm kiến trúc của bạn và liệu bạn có muốn làm theo một quy trình đã được định sẵn như TOGAF không hay chỉ cần giúp đỡ trong việc xác định cần sử dụng mô hình nào cho mục đích nào như trong Zachman.

Bạn cũng có thể kết hợp các khung công tác. TOGAF và Zachman thường được sử dụng với nhau.

Hình 3. Sự lựa chọn của bạn nên dựa trên mục đích của mình; đừng chọn ngẫu nhiên
Người leo nút dơ lên hai túi khác nhau

Làm thế nào để một khung công tác phù hợp với kiến trúc của bạn?

Một khung công tác cung cấp hướng dẫn cần mô hình hóa cái gì. Sau đó các phương pháp luận này được sử dụng để tạo các mô hình.

Một phương pháp luận là một bộ quy tắc giải thích cách mô hình hóa một cái gì đó. Ví dụ, phương pháp luận BPMN (Business Process Modeling Notation - Ký pháp mô hình hóa quy trình nghiệp vụ) cung cấp các quy tắc và các ký hiệu chính xác để mô hình hóa một quy trình nghiệp vụ.

Hình 4. Một khung công tác giúp lựa chọn phương pháp luận
Khung công tác Zachman và sơ đồ BPMN

Một khung công tác giúp tổ chức các lĩnh vực chủ yếu của kiến trúc và xác định các khung nhìn mà bạn cần mô hình hóa, ví dụ như phối cảnh và dữ liệu cần thiết để trả lời các câu hỏi nghiệp vụ.

Chuỗi khách sạn đã quyết định sử dụng khung công tác Zachman.

Bất cứ khi nào có thể, hãy sử dụng một phương pháp luận tiêu chuẩn công nghiệp chứ không phải là một cái gì đó "cây nhà lá vườn". Các phương pháp luận tiêu chuẩn công nghiệp có các bộ quy tắc và các cách tiêu chuẩn để mô hình hóa. Hầu hết các phương pháp cây nhà lá vườn không nắm bắt được thông tin theo cách có ích bởi vì bộ quy tắc không được định nghĩa rõ ràng, dẫn đến cho phép mọi người mô hình hóa cùng một thông tin theo nhiều cách khác nhau. Điều này cũng ảnh hưởng đến việc phân tích bởi vì thông tin không được nắm giữ theo một tiêu chuẩn.

Nhiều mô hình được sản xuất để hỗ trợ khung công tác dựa vào kiểu thông tin bạn cần.

Hình 5. Khung công tác với các phương pháp luận được hỗ trợ
Khung công tác, phương pháp luận và hệ phân cấp mô hình

Bước 5. Tạo một siêu mô hình

Một siêu mô hình là một khung nhìn trừu tượng về kiến trúc của bạn. Nó cho thấy dữ liệu mà bạn đang cố gắng nắm bắt và các mối quan hệ giữa các dữ liệu. Đây là nơi mà bạn thấy được sự sắp hàng, dựa trên các câu trả lời cho các câu hỏi nghiệp vụ của bạn.

Ví dụ, nếu bạn cần biết ứng dụng hỗ trợ một quy trình nghiệp vụ nhất định, thì phải có một mối quan hệ giữa hai cái đó trong siêu mô hình của bạn. Nếu không, sẽ không có kết nối nào giữa các dữ liệu, bạn không thể trả lời câu hỏi nghiệp vụ của mình và kiến trúc không dùng được.

Lưu ý rằng bạn không cần một mối quan hệ trực tiếp giữa tất cả mọi thứ trong siêu mô hình của mình và bạn chỉ cần liên kết những thứ này với nhau để có các mối quan hệ logic. Ví dụ, việc liên kết một phòng ban trong tổ chức với một công nghệ không có ý nghĩa gì cả, nhưng việc liên kết một công nghệ với một ứng dụng lại có ý nghĩa. Một công cụ mô hình hóa tốt, ví dụ như Rational System Architect hỗ trợ duyệt qua siêu mô hình để tạo các báo cáo phức tạp. Vì vậy, trong ví dụ về siêu mô hình này, bạn có thể báo cáo về phần cứng hỗ trợ một chức năng nghiệp vụ cho dù không có một mối quan hệ trực tiếp trong siêu mô hình đó. Trong một siêu mô hình bạn có thể có khả năng duyệt đi từ một chức năng nghiệp vụ, đến một quy trình nghiệp vụ thuộc sở hữu của chức năng đó, đến một vị trí của quy trình nghiệp vụ đó, đến một ứng dụng đang hỗ trợ mà quy trình này cần đến và cuối cùng đến các công nghệ hỗ trợ ứng dụng đó.

Hình 6. Ví dụ về các mối quan hệ (siêu mô hình)
Các câu hỏi nghiệp vụ và siêu dữ liệu

Siêu mô hình của bạn cần có các đặc tính sau đây:

  • Các mối quan hệ giữa các phần tử kiến trúc. Ví dụ, một quy trình nghiệp vụ đến một ứng dụng.
  • Các định nghĩa của các phần tử. Ví dụ, ý nghĩa của thuật ngữ "ứng dụng" và bạn sẽ nắm bắt các đặc tính nào.
  • Khả năng truy tìm nguồn gốc cho các câu hỏi nghiệp vụ. Ví dụ, nếu câu hỏi của bạn là "Các ứng dụng nào hỗ trợ các quy trình nghiệp vụ nào?" Bạn biết rằng bạn cần có một quy trình nghiệp vụ và một ứng dụng trong siêu mô hình của bạn, với một mối quan hệ trực tiếp hoặc gián tiếp giữa chúng.

Bước 6. Xác định các mô hình cần thiết trong kiến trúc

Bây giờ bạn đã xác định được các câu hỏi nghiệp vụ của mình, khung công tác của mình và siêu mô hình mà bạn cần để trả lời các câu hỏi của mình, bạn cần tìm ra cần vẽ những mô hình nào.

Sử dụng một quy trình nghiệp vụ làm một ví dụ, có nhiều tiêu chuẩn công nghiệp hỗ trợ việc mô hình hóa các quy trình nghiệp vụ, ví dụ như BPMN và các lưu đồ. Hãy chọn phương pháp luận mô hình hóa của bạn dựa trên các tiêu chí sau:

  • Đối tượng người xem. Các nhà quản lý hiểu các sơ đồ đơn giản như BPMN; các nhà phát triển phần mềm thường thích các sơ đồ tuần tự UML hoặc các sơ đồ trường hợp sử dụng.
  • Các phần tử của siêu mô hình. Nếu trong siêu mô hình của mình, bạn cần hiểu dữ liệu trong khi nó liên hệ các quy trình nghiệp vụ, thì hãy xem xét việc sử dụng BPMN để mô hình hóa dữ liệu đó. Nếu thay vào đó, bạn chỉ lo lắng về trình tự của các bước quy trình thì hãy xem xét việc tạo ra một lưu đồ.

Sau khi biết đối tượng người xem và nội dung mà bạn muốn mô hình hóa thì bạn có thể xác định các sơ đồ mà bạn cần tạo ra. Trong ví dụ trên do bạn cần thông tin về các quy trình nghiệp vụ và các giao diện hệ thống, bạn có thể chọn các mô hình sau:

  • BPMN (nắm bắt các quy trình nghiệp vụ)
  • Kiến trúc hệ thống (nắm bắt các ứng dụng)

Với ví dụ khách sạn, chúng cần trả lời câu hỏi nghiệp vụ "Các ứng dụng nào hỗ trợ quy trình nghiệp vụ nào?"

Điều quan trọng cần nhớ là bạn không thể sử dụng một sơ đồ duy nhất để mô hình hóa tất cả mọi thứ trong kiến trúc doanh nghiệp của bạn. Hơn nữa, việc tách các khung nhìn kiến trúc, ví dụ như khung nhìn ứng dụng khỏi khung nhìn nghiệp vụ, là một cách làm thực hành tốt nhất. Nếu bạn cố gắng mô hình hóa cả hai khung nhìn trong cùng một sơ đồ, thì nó thường gây ra sự nhầm lẫn và không nắm bắt thông tin một cách có ý nghĩa.

Hình 7. Sử dụng các mô hình trả lời các câu hỏi nghiệp vụ để kiến trúc có ích
Các sơ đồ và sự liên kết đặc tính tạo ra một báo cáo

Xem ảnh lớn hơn của Hình 7.

Hình 8. ... chứ không phải mô hình hóa vị mô hình hóa
Người leo núi trên một cột băng

Như Will Gadd đã nói, "Có gì đó hiện ra và chẳng làm điều gì có ích mà tôi thấy rất hấp dẫn".

Sử dụng các công cụ thích hợp

Một công cụ hoặc phương pháp luận mô hình hóa duy nhất không cung cấp một giải pháp đầy đủ. Bên cạnh một công cụ để phát triển các mô hình, bạn cũng nên có các công cụ để xuất bản, quản lý các yêu cầu và hiển thị trên bảng điều khiển. Một bảng điều khiển trình bày thông tin kiến trúc doanh nghiệp của bạn dưới dạng các biểu đồ dễ hiểu giống như các biểu đồ chia bánh và biểu đồ thanh.

Nếu công cụ kiến trúc của bạn có thể tùy chỉnh, thì các tùy chỉnh câu hỏi sẽ thay đổi cách công cụ này được dự kiến để được sử dụng. Tùy chỉnh quá nhiều thường là một dấu hiệu cho thấy bạn đang sử dụng công cụ hoặc cách tiếp cận sai. Cũng nên nhớ rằng tùy chỉnh tạo thêm gánh nặng quản trị kiến trúc.

Một số khách hàng tùy chỉnh các công cụ kiến trúc để tạo mô hình riêng của họ. Đây không phải là một cách tiếp cận thực hành tốt nhất, đặc biệt là nếu "mô hình" là một sơ đồ duy nhất chiếm toàn bộ một bức tường có chứa tất cả các thông tin về kiến trúc của bạn. Thay vì tạo giấy dán tường, hãy tạo các báo cáo. Không phải tất cả mọi thứ đều cần được hiển thị trên một sơ đồ.

Con người cũng quan trọng như các công cụ khi tạo một kiến trúc. Một người duy nhất không thể là một chuyên gia trong mọi khía cạnh của kiến trúc. Hãy phát triển một đội ngũ có kiến thức sâu rộng để hỗ trợ kiến trúc. Để có một danh sách các đặc trưng lý tưởng của một nhóm kiến trúc, hãy xem bài đầu tiên trong loạt bài Hãy khai thác tối đa giá trị từ nhà tư vấn kiến trúc doanh nghiệp của bạn.


Bước 7. Tích hợp kiến trúc

Hãy liên kết dữ liệu mà bạn đã nắm giữ với nhau dựa trên các mối quan hệ mà bạn đã xác định trước đó. Không một công cụ kỳ diệu nào làm được điều này, bất kể những người chào hàng có nói gì. Và đúng là các liên kết mối quan hệ thực sự khó làm nếu không có một kho lưu trữ. Nếu ai đó gợi ý rằng dự án có thể làm điều này bằng cách sử dụng một bảng tính, thì bạn hiểu cần tìm dự án khác để tiếp tục làm việc.

Nếu bạn đang có các kiến trúc cho các dự án hoặc các tuyến nghiệp vụ và bạn muốn tạo ra một kiến trúc doanh nghiệp, thì cách tiếp cận đơn giản nhất là điền vào kiến trúc doanh nghiệp của bạn từ dưới lên. Hãy lấy kiến trúc hiện có và rút ra các phần tử chung đưa vào một kho lưu trữ. Khi tiếp tục tiến lên, hãy cố gắng tiêu chuẩn hóa các mô hình và thuật ngữ được sử dụng trong toàn tổ chức, vì tất cả mọi người sử dụng cùng một tên cho một tổ chức, ví dụ như tiêu chuẩn hóa, dùng "Tài chính" chứ không dùng các biến thể như "Phòng Tài chính", Kế toán, Kế toán & Tài chính.

Nếu đây là kiến trúc doanh nghiệp đầu tiên của bạn, hãy sử dụng một kế hoạch chi tiết phổ biến trong toàn tổ chức của bạn sao cho một kiến trúc đã được tạo ra cho một tuyến nghiệp vụ sử dụng cùng một khung công tác, thuật ngữ và các mô hình như kiến trúc doanh nghiệp. Bằng cách đó bạn có thể làm báo cáo trong toàn doanh nghiệp.

Phân tích kiến trúc

Hình 9. Tiết kiệm một ít năng lượng để phân tích!
Một người đang bình phục sau khi leo núi

Nếu bạn không dành thời gian để phân tích kiến trúc, thì sẽ không có thời gian để phân tích nó. Nếu bạn không phân tích nó, thì tại sao bạn lại xây dựng nó? Bước quan trọng này thường bị bỏ qua trong lúc lập lịch biểu. Hãy dành ít nhất 50% thời gian được phân bố để phát triển một mô hình dùng để phân tích; điều này bao gồm cả việc xem xét lại mô hình để kiểm tra và xác nhận hợp lệ nó.

Hãy phân tích định lượng cũng như phân tích định tính. Toán học là quan trọng, đặc biệt là cho biết lợi nhuận. Phân tích định lượng có thể được sử dụng để hiển thị các nút nghẽn cổ chai trong một quy trình, tiết kiệm thời gian, tiết kiệm chi phí và loại bỏ các sự dư thừa nếu bạn sử dụng một phương pháp tiêu chuẩn công nghiệp, ví dụ như BPMN. BPMN là "có cấu trúc" bởi vì nó có một bộ quy tắc bạn không thể vi phạm. Các quy tắc đó đảm bảo bạn có thể thực hiện phân tích như mô phỏng một sự thay đổi với một quy trình nghiệp vụ để xem thay đổi đó có tiết kiệm thời gian hay tiền bạc không hoặc có một tác động tiêu cực như gây ra một nút nghẽn cổ chai chẳng hạn.

Phân tích định tính được thực hiện bằng cách xem xét một mô hình để tìm ra ở đâu có các vấn đề tiềm ẩn. Ví dụ, nếu bạn có một quy trình nghiệp vụ có phản hồi về một phần đầu của quy trình đó, đây thường là một dấu hiệu cho thấy cần phải làm lại công việc. Việc loại bỏ các vòng lặp phản hồi trong một quy trình là một cách để cải thiện nó..

Sau khi bạn hoàn thành việc phân tích, hãy chia sẻ các kết quả. Mọi người sẽ thấy giá trị trong kiến trúc nếu họ tìm hiểu cách sử dụng nó. Việc tạo báo cáo là quan trọng, do đó khi lựa chọn một công cụ kiến trúc doanh nghiệp, hãy chắc chắn nó có một khả năng tạo báo cáo mạnh.

Đừng quên - bạn cần một kế hoạch trò chơi

Hình 10. Phát triển kế hoạch trò chơi của kiến trúc doanh nghiệp
Mọi người đang xem bản đồ trước khi leo núi

Mọi người thường quên có rất nhiều vấn đề quản trị cần được giải quyết để bắt đầu và hỗ trợ một dự án kiến trúc doanh nghiệp (EA). Một số các vấn đề quản trị cần được giải quyết gồm có:

  • Cách triển khai kiến trúc doanh nghiệp?
  • Triển khai nó ở đâu (trang web, v.v..)?
  • Ai ở trong nhóm kiến trúc?
    • Các ban thẩm tra
    • Quản lý dự án
    • Quản trị
  • Ai sẽ sử dụng thông tin?
  • Ai sẽ có quyền truy cập thông tin?
  • Sẽ làm theo các tiêu chuẩn nào?
    • Các quy ước đặt tên
    • Mã màu

Có một "EA" trong nhóm

Hình 11. Một nhóm EA tốt đảm bảo cho sự thành công
Một nhóm leo núi đang ngồi xung quanh lửa trại

Bạn không thể tạo kiến trúc trong chân không. Bạn phải được chuẩn bị để làm việc với những người ngoài nhóm EA, nếu không kiến trúc của bạn không thể được thông qua và được sử dụng. Ngoài ra hãy đảm bảo rằng các bên liên quan (ví dụ như những người đang trả tiền cho bạn để xây dựng một kiến trúc hoặc những người đang giúp đỡ bạn xây dựng kiến trúc) có tham gia vào việc ra quyết định của bạn.

Quản trị là cần thiết để ra quyết định. Quản trị giúp định nghĩa các quy tắc và các chiến lược mà bạn sẽ sử dụng cho kiến trúc. Một ví dụ là quản trị việc đặt tên các tuyến nghiệp vụ trong tổ chức của bạn không để người này gọi phòng "Kế toán" còn người khác gọi là phòng "Tài chính". Quản trị cũng xác định những mô hình nào đã sẵn sàng để được phát hành dưới dạng "đã phê duyệt". Các ban tiêu biểu cần thiết để có một EA thành công gồm:

  • Ban thẩm tra kiến trúc.
  • Ban cấu hình và kiểm soát.
  • Các hướng dẫn quản trị (Ví dụ, ai có thể tạo ra các mô hình, quy trình phê duyệt là gì, quy trình cho một yêu cầu thay đổi là gì).

Càng có nhiều người tham gia vào hỗ trợ kiến trúc, sẽ càng có nhiều cơ hội tốt hơn để nó được sử dụng.

Một vài lời khuyên cuối cùng

Nếu việc này dường như khó khăn, đó là bởi vì nó khó khăn. Tuy nhiên, nó có thể cũng báo cho biết rằng bạn đang làm một cái gì đó không đúng với một trong hai khía cạnh sau đây:

  • Các mô hình. Ví dụ, sử dụng một mô hình BPMN để nắm bắt các giao diện ứng dụng.
  • Các bên liên quan. Ví dụ, những người không quen với một quy trình nghiệp vụ cung cấp đầu vào và sự phản hồi chứ không phải những người thực sự thực hiện quy trình.

Học cách để tách các phản ứng chính trị khỏi kiến trúc

  • "Không ghi lại điều đó! Sau này mọi người sẽ biết chúng ta đang làm những điều sai!" – Đây là một phản ứng phổ biến với kiến trúc doanh nghiệp. Nhưng không có ý nghĩa gì khi ghi lại cái nhìn thế giới lý tưởng hóa vì bạn sẽ không thể lên kế hoạch về cách sửa chữa mọi thứ trong tương lai.
  • "Tổ chức của tôi đang sử dụng một phương pháp khác để nắm bắt kiến trúc của chúng tôi". – Luôn có một tuyến nghiệp vụ trong mỗi tổ chức mà tôi đã làm việc không muốn phát triển kiến trúc của họ theo cách tiêu chuẩn. Không ai là ngoại lệ. Chẳng ai có lý do chính đáng để không làm mọi thứ theo tiêu chuẩn. Cách tiếp cận tốt nhất để đối phó với tình hình này là đào tạo cho những người tối dạ muốn làm theo cách khác ấy. Nếu họ cảm thấy thoải mái và hiểu người ta mong chờ ở họ những gì, họ sẽ sẵn sàng làm theo tiêu chuẩn. Nếu điều đó thất bại, tùy chọn duy nhất của bạn là ngăn họ lại.

Sử dụng kiến trúc để phá vỡ sự lãnh đạm

  • "Chúng tôi không thể nói chuyện với những anh chàng đó, bạn biết đấy, họ là những người phát triển phần mềm". – Ở hầu hết các công ty, có những người nhận thấy thật khó nói chuyện với các nhà phát triển phần mềm. Họ là những người tốt một khi bạn bắt đầu hiểu biết họ. Và thái độ của họ đối với bạn sẽ thay đổi một khi họ khám phá ra họ có thể giao tiếp dễ dàng với bạn dùng các hình ảnh thay vì 500 trang tài liệu yêu cầu vô nghĩa.
  • "Tôi muốn cung cấp cho bạn dữ liệu đó, nhưng trước tiên tôi cần hỏi người quản lý của mình đã. Thế nếu tôi không gặp bạn nữa thì sao?" – Một số người tính đến an toàn việc làm khi giấu giếm thông tin. Bạn không thể sa thải Barney vì ông ta là người duy nhất hiểu các ứng dụng của bạn được nối với nhau như thế nào. Các tuyến nghiệp vụ khác có thể không muốn chia sẻ thông tin do sợ rằng bạn sẽ sử dụng nó để sa thải người làm. Hãy xử lý các tình huống này bằng cách giải thích bạn sẽ sử dụng thông tin như thế nào và nó sẽ mang lại lợi ích cho người cung cấp thông tin như thế nào. Nếu bạn đang sử dụng thông tin cho các mục đích xấu, ví dụ như sa thải người làm, chắc chắn bạn sẽ thấy sự sụt giảm mạnh số người sẵn sàng cung cấp thông tin cho bạn.

Đặc biệt cảm ơn Joe Josephson, First Ascent Press www.firstascentpress.com, vì đã cung cấp các hình ảnh và Will Gadd, www.gravsports.com, vì đã cung cấp hình ảnh và các đoạn trích dẫn.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Rational
ArticleID=793481
ArticleTitle=Một hướng dẫn thiết thực để phát triển kiến trúc doanh nghiệp
publish-date=02142012