9:26, 28/02/2012
|
Để
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ó.
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).
 |
| 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 |
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ạ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.
Đ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â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ụ".
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.
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ụ.
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 3. Khung công tác với các phương pháp luận được hỗ trợ
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 đó.
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â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.
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".
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.
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.
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.
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
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.
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.
Không có nhận xét nào:
Đăng nhận xét