Biểu đồ ngữ cảnh hoạt động Cách bổ sung biểu đồ ngữ cảnh hệ thống và giúp bạn thiết kế các khía cạnh kỹ thuật của một hệ thống Vito Losacco ([email protected]) Kiến trúc sư quản trị CNTT IBM 06 11 2009 Trong nhiều năm, các kiến trúc sư và các nhà phân tích ứng dụng đã sử dụng biểu đồ ngữ cảnh hệ thống (System Context Diagram - SCD) như một công cụ mạnh để chia sẻ khung nhìn mức cao của một hệ thống. SCD cung cấp chỉ một khung nhìn chức năng của hệ thống, một khung nhìn mà sau này dẫn đến mô hình ca sử dụng. Để xác định toàn bộ hệ thống theo sự phát triển, các yêu cầu không chức năng phải được tính đến. Các NFR tạo một khung nhìn khác về ngữ cảnh của hệ thống: biểu đồ ngữ cảnh hoạt động, sau đó chuyển tiếp tới mô hình hoạt động. Trong bài viết này, hãy tìm hiểu về một kỹ thuật để bổ sung SCD với một biểu đồ ngữ cảnh hoạt động hướng không chức năng. Giới thiệu Chúng ta đã luôn luôn muốn tính đơn giản của một biểu đồ ngữ cảnh hệ thống (SCD). Bạn có thể vẽ nó ở phía trước một khách hàng và chỉ trong vài phút đạt tới một sự hiểu biết chung về phạm vi của một dự án, các vai và thậm chí cả các ca sử dụng chính mà hệ thống đã thể hiện. Nếu chúng ta là các nhà báo và phải mô tả các tin tức thay cho một hệ thống, SCD của chúng ta trả lời Ai và, như lát cắt đầu tiên, Cái gì. Nhưng, SCD sẽ không trả lời các câu hỏi Ở đâu, Khi nào, Như thế nào và Bao nhiêu. Nếu không có các thông tin này ngữ cảnh hệ thống của chúng ta chỉ định nghĩa được một phần. Nhiệm vụ phân tích ban đầu phải tập trung vào chỉ nội dung chức năng. Ngay cả kiến trúc chức năng có thể bị ảnh hưởng bởi cách giải quyết các yêu cầu không chức năng (NFRs). Không có sự khác biệt nào về khái niệm giữa các yêu cầu chức năng và không chức năng, vì cả hai đều là các biểu hiện của động lực theo một trong các bên liên quan, hoặc những người có ảnh hưởng, trong hệ thống theo định nghĩa. Xem Tài nguyên để biết thêm thông tin về các mô hình động lực kinh doanh. © Copyright IBM Corporation 2009 Biểu đồ ngữ cảnh hoạt động Nhẫn hiệu đăng ký Trang 1 của 13 developerWorks® ibm.com/developerWorks/vn/ Rozanski và Woods phân loại các bên liên quan khác nhau, những người quan tâm đến một hệ thống công nghệ thông tin (CNTT) như: Những người thu nhận Giám sát việc đấu thầu hệ thống hoặc sản phẩm. Những người định giá Giám sát sự thông nhất của hệ thống theo các tiêu chuẩn và quy định của pháp luật. Những người truyền đạt Giải thích về hệ thống cho các các bên liên quan khác về các tài liệu hướng dẫn và các tài liệu đào tạo. Các nhà phát triển Xây dựng và triển khai hệ thống từ đặc tả kỹ thuật (hoặc lãnh đạo các nhóm thực hiện như vậy). Các nhà bảo trì Quản lý sự tiến triển của hệ thống khi nó đang hoạt động. Các nhà cung cấp Xây dựng hoặc cung cấp phần cứng, phần mềm hoặc cơ sở hạ tầng mà hệ thống sẽ chạy trên đó. Nhân viên hỗ trợ Cung cấp sự hỗ trợ cho những người sử dụng sản phẩm hoặc hệ thống khi nó đang chạy. Các nhà quản trị hệ thống Vận hành hệ thống khi nó đã được triển khai. Các nhà thử nghiệm Thử nghiệm hệ thống để đảm bảo nó thích hợp để sử dụng. Những người dùng Xác định các chức năng hệ thống và cuối cùng bắt đầu sử dụng nó. Tại nơi đặt một khung công tác Enterprise Architecture (EA - Kiến trúc doanh nghiệp), các yêu cầu của các bên liên quan đã được xác định trong chính EA. Chúng nên được tính đến như là đầu vào chính. Nếu không, việc phỏng vấn các bên liên quan có thể là một cách tốt để nắm bắt các nhu cầu của họ. Các nhu cầu cần được phân loại theo chức năng hoặc các NFR. Các NFR nên được phân loại theo các đặt tính (mục tiêu) và các ràng buộc (đã cho). Các đặt tính không chức năng có thể được các bên liên quan xếp loại theo tầm quan trọng cảm nhận được của chúng (từ VH = Rất cao đến VL = Rất thấp). Phân loại các yêu cầu Nhiều nguyên tắc phân loại đã được đề xuất để tổ chức các NFR: các đặt tính thời gian chạy và thời gian không chạy, các ràng buộc kinh doanh và kỹ thuật, phạm trù ISO9126, v.v. Bài viết này sử dụng một sự phân loại hơi khác một sự phân loại dựa trên khái niệm "nhu cầu chính". Theo cách tiếp cận của chúng ta, các NFR là những gì mà các bên liên quan cần từ hệ thống theo thiết kế. Các yêu cầu đó sẽ tạo hình hệ thống từ điểm hoạt động của khung nhìn. Mỗi yêu cầu có thể được một số lớp của các bên liên quan thể hiện, nhưng nó thường đến từ một nguồn chính. Ví dụ, một đối tượng "các trang mỗi giây" là một yêu cầu cho: • Những người thu nhận, những người phải tính đến và xác minh nó trong quá trình mua sắm. Biểu đồ ngữ cảnh hoạt động Trang 2 của 13 ibm.com/developerWorks/vn/ developerWorks® • Các nhà phát triển và các nhà bảo trì, những người phải tiếp cận và duy trì đích được thiết lập. • Các nhà quản trị hệ thống, những người phải theo dõi và đo hiệu năng thời gian chạy. Tuy nhiên, ngay cả khi hình như rất kỹ thuật, nhu cầu các trang mỗi giây cuối cùng được bắt nguồn từ Số lượng các giao dịch kinh doanh cho mỗi nhân viên lễ tân, một dòng về nghiệp vụ (LOB) hoặc người sử dụng cần. Theo như một hướng dẫn, chúng ta sẽ sử dụng các phân loại sau cho các NFR: Phụ thuộc vào vai Các yêu cầu đại diện cho các nhu cầu của những người sử dụng hệ thống (con người hay không) và có thể được tiếp tục phân loại như: • Người sử dụng hay các hệ thống bên ngoài cần các đặc tính hệ thống tương tác với hệ thống, như được trình bày trong SCD. • Người quản lý dịch vụ CNTT đòi hỏi các đặc tính hệ thống, ví dụ như một tập của các vai chuyên ngành (con người và hệ thống) quản lý các hoạt động của hệ thống theo thiết kế. Các vai có thể yêu cầu một NFR trở thành một sự ràng buộc của vai, mà hệ thống phải tuân theo. Hãy suy nghĩ về các sự ràng buộc như là các NFR không thể đàm phán (mặc dù đôi khi chúng có thể bị loại bỏ). Độc lập với vai Các yêu cầu hệ thống đại diện cho các đặc tính hệ thống không thể bám chặt vào một vai nhưng vào một trong những bên liên quan khác. Một số các NFR có thể thuộc về cả hai các loại vai phụ thuộc lẫn vai độc lập cùng một lúc. Ví dụ, an ninh đồng thời có thể là một yêu cầu cho một lớp người sử dụng cụ thể và một chuẩn cho doanh nghiệp. Các NFR độc lập với vai mà hệ thống phải tuân theo có thể trở thành các ràng buộc của độc lập với vai. Nói chung, các NFR có thể được xếp loại bởi tầm quan trọng cảm nhận được của các bên liên quancủa chúng, cho cả hai loại, nhưng các ràng buộc sẽ được xác định thông qua một câu lệnh (như chuẩn hoặc quy định được đáp ứng). Sự phân loại này có lợi thế của kiểu gõ trực tiếp vào SCD và do đó cho phép, như bạn sẽ thấy sau này, một sự biểu diễn tương tự. Lĩnh vực của các NFR Điểm khởi đầu trong danh sách các NFR là quy tắc phân loại ISO 9126. Do mục đích cuối cùng là xây dựng một biểu đồ ngữ cảnh hoạt động để điều khiển sự phát triển của mô hình hoạt động (OM) của hệ thống, các sửa đổi sau đây đã được thực hiện theo danh sách ISO 9126. • Để đơn giản, thường sử dụng Sự đáng tin cậy như là sự kết hợp của: • Tính chắc chắn. • Có khả năng khôi phục lại. • Khả năng chịu lỗi. Biểu đồ ngữ cảnh hoạt động Trang 3 của 13 developerWorks® ibm.com/developerWorks/vn/ Thường sử dụng Tính tiện lợi như là tập của: • Tính học được. • Tính hiểu được. • Tính hấp dẫn. • Đã bỏ tính thực dụng và tính tương tác (mà đơn giản xác định rằng một hệ thống bên ngoài là một vai của SCD của chúng ta), do cả hai đều có tác động rất ít đối với việc định nghĩa của OM. Đã bỏ tính ổn định, tính dễ thay đổi và tính thay thế, do cùng một lý do. • Sự tuân thủ an ninh được bổ sung như là một yếu tố quan trọng cho các thiết kế hệ thống hiện nay. • Bổ sung một tập các ràng buộc có liên quan đến kinh doanh để phân loại các đầu vào của LOB có thể ảnh hưởng đến OM: • Các chính sách kinh doanh (chính sách hành vi kinh doanh là các ràng buộc có liên quan đến quyết định kinh doanh của LOB, ví dụ sự hỗ trợ khách hàng theo nhiều kênh). • Lĩnh vực kinh doanh (các chính sách cấu trúc kinh doanh là các ràng buộc trực tiếp dẫn đến từ các chính sách của ngành công nghiệp hoặc các chính sách về lĩnh vực, chẳng hạn như giờ mở cửa cho các cửa hàng). • Lịch biểu/Ngân sách đề cập đến các ràng buộc về tài chính của dự án. • Các vị trí là các ràng buộc về các vị trí phải được hệ thống phục vụ. Danh sách này có thể được mở rộng, phụ thuộc vào dự án. Thu thập các NFR Do ngữ cảnh hoạt động, như là ngữ cảnh hệ thống, sẽ được xác định rất sớm trong quá trình phân tích, đừng trông đợi các mục tiêu định lượng chính xác cho hầu hết các NFR -- chỉ cần các định tính. Khi thu thập thông tin từ các bên liên quan, bạn có thể cần cung cấp khung nhìn, định lượng nhiều hơn mặc dù là nhân tạo, của các yêu cầu để tránh tất cả các NFR bị đánh giá là Rất cao. Khi sử dụng hiệu năng như là một ví dụ, bạn có thể yêu cầu các bên liên quan xem thời gian đáp ứng chấp nhận được sẽ thấp hơn một giây, thấp hơn hai giây, v.v không. Với tính sẵn sàng, câu hỏi có thể là liệu hệ thống phải sẵn sàng 24x7, 24x6 hay 12x6 không. Điều quan trọng là phải hiểu rằng bạn có thể sử dụng chỉ các giá trị đại diện, tùy thuộc vào kiểu hệ thống theo thiết kế. Để cho kiến trúc sư CNTT đưa ra như là một tập đại diện của các giá trị. Việc định lượng các NFR thực sẽ diễn ra sau trong chu trình thiết kế (trừ khi các yêu cầu này là các ràng buộc thực sự cho hệ thống). Danh sách kết quả của các NFR, thể hiện trong Hình 1, có thể được dùng để tập các nhu cầu của các bên liên quan. Biểu đồ ngữ cảnh hoạt động Trang 4 của 13 ibm.com/developerWorks/vn/ developerWorks® Hình 1. Phân loại các NFR Các bên liên quan được tổ chức thành ba nhóm chính: • Các vai SCD. • Các bên liên quan, người tương tác với các vật phẩm của hệ thống (thời gian chạy hay thời gian phát triển), như là các nhà phát triển. • Các bên liên quan, người tương tác chỉ với quá trình giới thiệu hệ thống trong ngữ cảnh kinh doanh, như là những nhà định giá. Những yếu tố đầu vào đó sẽ được hợp nhất trong bảng trong Hình 2, bảng này trình bày ma trận các NFR của hệ thống và bố trí biểu diễn biểu đồ ngữ cảnh hoạt động. Biểu đồ ngữ cảnh hoạt động Trang 5 của 13 developerWorks® ibm.com/developerWorks/vn/ Hình 2. Ma trận các NFR của hệ thống Hãy xem cách kiến trúc sư trưởng của chúng ta có thể khai thác biểu đồ ngữ cảnh hoạt động và ma trận các NFR hệ thống để cung cấp một khung nhìn chưa xác định công nghệ đầu tiên của kiến trúc hoạt động. Nếu công việc mô hình hóa thành phần không có sẵn, các kỹ thuật khác như Ma trận các yêu cầu xung đột không thể sử dụng được. Biểu đồ ngữ cảnh hoạt động Biểu đồ ngữ cảnh hoạt động là điểm khởi đầu để thiết kế các khía cạnh kỹ thuật của hệ thống. Để giúp giải thích các khái niệm, kịch bản sau đây bao gồm một công ty giả định bắt nguồn từ một việc kinh doanh bất động sản, như trong Hình 3. Hình 3. Biểu đồ ngữ cảnh hệ thống mua nhà Biểu đồ ngữ cảnh hoạt động Trang 6 của 13 ibm.com/developerWorks/vn/ developerWorks® Khách hàng muốn bắt đầu một khả năng mua nhà, với khả năng cung cấp mọi dịch vụ đơn lẻ theo một số cách: tổng đài điện thoại, Internet hoặc trong quầy hàng. Môi trường công ty bao gồm một văn phòng chính và một nhà kho tại một địa điểm riêng biệt. Tổng đài điện thoại thuê ngoài. Kiến trúc sư trưởng thu thập các NFR từ các bên liên quan, dẫn đến các bảng trong Hình 4. Chỉ có nguồn chính với một yêu cầu nhất định được hiển thị. Hình 4. Ví dụ về các đáp ứng của các bên liên quan Các đáp ứng sau đó đã được hợp nhất vào trong ma trận các NFR hệ thống trong Hình 5. Biểu đồ ngữ cảnh hoạt động Trang 7 của 13 developerWorks® ibm.com/developerWorks/vn/ Hình 5. Ví dụ về ma trận các NFR hệ thống Bảng trên cho thấy rằng các bên liên quan đã gán tầm quan trọng tương đối cho các yêu cầu. Một số trong chúng cũng đã được phân loại như là các ràng buộc hệ thống. Biểu đồ ngữ cảnh hoạt động trong Hình 6 biểu thị các thông tin giống nhau trong một bản vẽ đồ họa. Chỉ các yêu cầu có tầm quan trọng Cao và Rất cao được hiển thị. Các đặc tính (màu đỏ) và các ràng buộc (màu xanh dương) được kết nối với các vai có nguồn gốc hoặc đến ranh giới của hệ thống, trong trường hợp chúng là chung cho tất cả các vai. Các đặc tính và các ràng buộc không bắt nguồn từ một vai cụ thể được xếp thẳng hàng ở bên trái của hình như là các đặc điểm của hệ thống. Hình 6 cho thấy một cách ngắn gọn các kỳ vọng khác nhau mà các vai phải có về hệ thống. Biểu đồ ngữ cảnh hoạt động là một sự trợ giúp rất tốt để giải thích và xác nhận sự phức tạp của hệ thống đối với khách hàng. Ví dụ, với cả Internet và các quán hàng, tính tiện lợi là một mối quan tâm chính và sẽ có thể yêu cầu một giao diện kênh cụ thể, trong khi các hoạt động 24x7 là một sự ràng buộc chỉ với tùy chọn Internet. Biểu đồ ngữ cảnh hoạt động Trang 8 của 13 ibm.com/developerWorks/vn/ developerWorks® Hình 6. Biểu đồ ngữ cảnh hoạt động mua nhà Kiến trúc sư trưởng bây giờ có thể khai thác biểu đồ ngữ cảnh hoạt động và ma trận các NFR hệ thống để cung cấp một khung nhìn công nghệ trung lập đầu tiên của kiến trúc hoạt động. Đặc tính của vai cụ thể có liên quan đến các NFR chuyển thành các yêu cầu trên các nút khái niệm hỗ trợ cho vai đó. Thông thường, điều này bao gồm nhiều nút và một số nút phải hỗ trợ nhiều hơn một kiểu vai. Tất nhiên, việc đòi hỏi nhiều hơn các yêu cầu áp dụng cho các nút chung. Việc sử dụng thông tin được cung cấp với các điều kiện cần thiết của các Vị trí và một số các ràng buộc về kết nối, bạn có thể dự thảo một sự phân vùng ban đầu cho các thành phần hạ tầng chính của hệ thống. Bạn biết nơi đặt các nút khái niệm, mà cuối cùng sẽ lưu trữ các thành phần hỗ trợ các chức năng mức ứng dụng: • Vị trí thời gian chạy trung tâm của hệ thống sẽ lưu trữ các dịch vụ ứng dụng chính (CN_App Svcs) cần một dịch vụ tích hợp AAA để tái sử dụng hệ thống AAA hiện có (một sự ràng buộc đã nêu) và một giao diện dịch vụ tích hợp (CN_Old WH Interface Svc) để cho phép sự tương tác với giao diện hiện có của kho hàng. • Đại diện cửa hàng, người sử dụng Internet và Tổng đài điện thoại yêu cầu các giao diện kênh cụ thể, tiện lợi rất cao, đề xuất sự phân tách hệ thống. Có lẽ chấp nhận một công nghệ khác nhau cho biểu diễn các giao diện theo thứ tự. • Hãy xem xét một nút khái niệm, cho phép dịch vụ quản lý, để đáp ứng yêu cầu hoạt động cao cho vai của nhà quản lý dịch vụ CNTT • Tổng đài điện thoại, tại một địa điểm ở xa có kết nối tin cậy thấp, đòi hỏi các hiệu năng Rất cao. Nó có thể được hỗ trợ bằng cách lưu trữ nhanh các bản sao cục bộ của dữ liệu 'khó thay đổi' (tương tự như các mô tả và hình ảnh của một danh mục) thông qua một hệ thống riêng. Biểu đồ ngữ cảnh hoạt động Trang 9 của 13 developerWorks® ibm.com/developerWorks/vn/ • Để đảm bảo khả năng tương tác với hệ thống thẻ tín dụng, bạn cần thêm các nút theo khái niệm cổng chuyên dụng. Hình 7 cho thấy kiến trúc hoạt động khái niệm kết quả của hệ thống của chúng ta. Hình 7. Một lát cắt đầu tiên của kiến trúc hoạt động Bắt đầu từ khung nhìn này và với đầu vào từ mô hình thành phần mức ứng dụng, kiến trúc sư CNTT cơ sở hạ tầng trực tiếp đưa vào chi tiết mô hình hoạt động cuối cùng của hệ thống, như sau. • Các nút có độ tin cậy được đặt tới Cao hoặc Rất cao sẽ hàm ý hạ tầng được co cụm hoặc cân bằng. • Nhu cầu hiệu năng sẽ yêu cầu các kết nối và các máy chủ thích hợp từ đầu đến cuối. • Các yêu cầu cho một hệ thống an ninh cao, vì thế bạn phải "bịt kín", với một nhà cung cấp an ninh, tất cả các giao diện bên ngoài (các mạng Internet và mạng bên ngoài như các cơ quan tín dụng hoặc công ty tổng đài điện thoại) và các giao diện với các khu vực không an toàn của mạng nội bộ, chẳng hạn như nhà kho và các cửa hàng. • Đích sử dụng nguồn tài nguyên sẽ đòi hỏi một hoạt động lập kế hoạch phù hợp trong các giai đoạn sau. Bằng cách sử dụng các đặc tả kỹ thuật của các NFR tại mức vai hệ thống, cách tiếp cận này chỉ ra những nét chính trong bài viết này cho phép tạo hình cơ sở hạ tầng chính xác hơn. Bạn có thể tránh, ví dụ, cung cấp các tài nguyên mà không chứng minh bằng các nhu cầu thực tế của một vai. Kết luận Trong bài viết này bạn đã học về kỹ thuật để bổ sung một biểu đồ ngữ cảnh hệ thống nổi tiếng với một biểu đồ ngữ cảnh hệ thống có định hướng không theo chức năng. Biểu đồ ngữ cảnh hoạt động là điểm khởi đầu để thiết kế các khía cạnh kỹ thuật của hệ thống, bao gồm cả cơ sở hạ tầng hỗ trợ. Biểu đồ ngữ cảnh hoạt động Trang 10 của 13 ibm.com/developerWorks/vn/ developerWorks® Lời cảm ơn Các tác giả cảm ơn Philippe Binet, kỹ sư xuất sắc của IBM GTS tại Ý, Piero Sguazzero, kỹ sư xuất sắc của IBM SWG tại Ý và Raffaele pullo, Kiến trúc sư CNTT chấp hành của IBM GTS tại Ý, về sự động viên và các ý kiến có giá trị của họ cho bài viết này. Biểu đồ ngữ cảnh hoạt động Trang 11 của 13 developerWorks® ibm.com/developerWorks/vn/ Tài nguyên Học tập • Phân tích các yêu cầu cho các hệ thống phần mềm phức tạp theo một cách mới, toàn diện (developerWorks, 02.2009): Tìm hiểu cách các yêu cầu chức năng và không chức năng là ngược với lực lượng được xử lý tương tự như các lực lượng trong các cấu trúc kỹ thuật dân dụng. • Kiến trúc các hệ thống phần mềm: Làm việc với các bên liên quan khi sử dụng các Quan điểm và các Phối cảnh của Rozanski và Woods là một hướng dẫn hướng-người thực hành một kỹ năng để thiết kế và triển khai thực hiện các kiến trúc có hiệu quả cho các hệ thống thông tin. Nó vừa là một sự giới thiệu truy cập dễ dàng đến kiến trúc phần mềm và vừa là một sổ tay hướng dẫn vô giá về các thực hành tốt nhất đã có từ lâu. • Nhóm các quy tắc nghiệp vụ trình bày rõ ràng các câu lệnh và các tiêu chuẩn hỗ trợ về tính chất và cấu trúc của các quy tắc nghiệp vụ, mối quan hệ của các quy tắc nghiệp vụ với cách tổ chức một doanh nghiệp và mối quan hệ của các quy tắc nghiệp vụ với các kiến trúc hệ thống. • Mô hình động lực kinh doanh: Quản trị kinh doanh trong một thế giới hay thay đổi (09.2007) đề cấp đến phần 'động lực' của khung công tác Zachman. • N. Nayak, M. Linehan, A. Nigam, D. Marston, J.-J. Jeng, F. Y. Wu, D. Boullery, L. F. White, P. Nandi, J. L. C. Sanz. Kiến trúc kinh doanh cốt lõi cho một doanh nghiệp hướng dịch vụ" (Tạp chí IBM Systems, tập 46, số 4, 2007) tập trung vào kiến trúc kinh doanh cốt lõi, tập các phần tử thiết yếu trong từng lĩnh vực trong năm lĩnh vực và các mối quan hệ lẫn nhau giữa các phần tử này. • Tìm hiểu thêm về Tiêu chuẩn ISO 9126. • Định nghĩa các yêu cầu không chức năng (Tư vấn Bredemeyer) trình bày các khái niệm và các cuộc thảo luận quan trọng khi nắm bắt các yêu cầu không chức năng theo cách mà chúng có thể điều khiển các quyết định kiến trúc và được sử dụng để xác nhận hợp lệ các kiến trúc. • Một cách tiếp cận của IBM Rational với Khung công tác Kiến trúc của Bộ Quốc phòng (DoDAF) Phần 1: Khung nhìn hoạt động (developerWorks, 03.2006) trình bày một tổng quan về Khung công tác Kiến trúc của Bộ Quốc phòng (DoDAF) và mô tả các sản phẩm Khung nhìn hoạt động (OV) của nó. Lấy sản phẩm và công nghệ • Tải về phiên bản đánh giá sản phẩm IBM và nhận được các bài thực hành của bạn trên các công cụ phát triển ứng dụng và các sản phẩm phần mềm trung gian từ DB2®, Lotus®, Rational®, Tivoli® và WebSphere®. Thảo luận • Đọc developerWorks blogs và dành tâm trí cho cộng đồng developerWorks. Biểu đồ ngữ cảnh hoạt động Trang 12 của 13 ibm.com/developerWorks/vn/ developerWorks® Đôi nét về tác giả Vito Losacco Vito Losacco là một kiến trúc sư quản trị CNTT với các hệ thống công nghệ toàn cầu của IBM ở Italia. Sau tám năm làm việc tại các phòng thí nghiệm phát triển của Rome, năm 1998 ông tham gia vào IGS với các vai trò kỹ thuật và lãnh đạo trong các dự án của khách hàng lớn, tập trung vào các hoạt động CNTT và các thiết kế của các giải pháp kiến trúc cơ sở hạ tầng. Ông hiện đang có vị trí kỹ thuật trước bán hàng như là ITSA của các cam kết lớn, cam kết giữa ngành công nghiệp và giữa các LOB. Vito đã là một người phát ngôn tại Hội nghị II về an ninh toàn cầu của IBM năm 2003 và người phát ngôn của TLE trong năm 2008 © Copyright IBM Corporation 2009 (www.ibm.com/legal/copytrade.shtml) Nhẫn hiệu đăng ký (www.ibm.com/developerworks/vn/ibm/trademarks/) Biểu đồ ngữ cảnh hoạt động Trang 13 của 13