Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 9

Một cách tiếp cận nhanh tới SOA nhanh hơn, rẻ hơn

Trong phần đăng cuối cùng của loạt bài này, hãy tìm hiểu một cách tiếp cận nhanh có thể giúp cho các công ty được hưởng các lợi ích của SOA như thế nào. Trong nền kinh tế hiện tại của chúng ta, các tổ chức đang phân tích kỹ lưỡng về dự án nào mà họ sẽ thực hiện còn dự án nào thì không. Danh tiếng của SOA đang có giá, cả về thời gian lẫn cả về tiền bạc, cũng không giúp gì trong việc khởi đầu các dự án mới. Trong bài này, hãy nghiên cứu cách các công ty có thể nhanh chóng bắt đầu được hưởng các lợi ích từ SOA bằng cách sử dụng tiếp cận nhanh.

Mikko Kontio, Giám đốc, Softera

Mikko Kontio có một nền tảng về phát triển và tư vấn phần mềm. Ông hiện là Giám đốc tại Softera, một công ty phát triển phần mềm tập trung vào các cổng kinh doanh và giải pháp tính cước viễn thông.



30 10 2009

Giới thiệu

Các phương tiện đang công bố các kết quả nghiên cứu nói rằng các tổ chức đang trì hoãn các dự án SOA của họ vì lo sợ rằng các chi phí sẽ cao hơn lợi nhuận. Bài viết này khảo sát tỉ mỉ một cách tiếp cận khác ở nơi mà các tổ chức có thể nhận được các lợi nhuận quan trọng nhất của SOA với một mức đầu tư ít hơn, và trong một thời gian ngắn hơn.

Hiện có rất nhiều tranh luận về việc liệu nhanh và SOA có đồng hành tốt với nhau hay không. Một số người nói rằng SOA đòi hỏi một cách tiếp cận tài liệu theo định hướng, rộng lớn hơn. Những người khác nói rằng, với cách tiếp cận nhanh, một nhóm có thể cung cấp những chức năng chính rẻ hơn và nhanh hơn. Không có bất kỳ lý do về cách tiếp cận nhanh không thể được sử dụng để cung cấp những lợi nhuận mà các tổ chức đang tìm kiếm với SOA.

Bài viết này không có ý định giới thiệu về SOA. Trong phần Tài nguyên có nhiều hơn về SOA.

Do các nhu cầu và lợi ích kinh doanh thực luôn là ưu tiên cao nhất, bài viết này trước tiên xem xét lại những lợi ích mà các tổ chức đang tìm kiếm từ SOA. Sau đó, chúng ta sẽ thảo luận một cách tiếp cận nhanh có thể được sử dụng như thế nào.


Tổng quan: Các lợi ích của SOA

SOA là thường được mô tả như là một kiến trúc mà trong đó các chức năng được nhóm lại xung quanh quy trình nghiệp vụ và các chức năng có thể được truy cập thông qua các giao diện. Có một số lợi ích mà các doanh nghiệp thường tìm kiếm với SOA, như sau.

Các ứng dụng không bị cô lập
Các giao diện làm cho nó vừa dễ dàng vừa có giá cả phải chăng để tích hợp các ứng dụng hiện có của tổ chức. Điều này làm giảm các giai đoạn làm việc thủ công, do đó tiết kiệm thời gian và tiền bạc.
Tích hợp các ứng dụng dễ dàng hơn
Các chức năng được cung cấp và cho phép tiếp cận từ các giao diện.
Chi tiết liên quan đến việc thực hiện được che
Các giao diện che dấu các chi tiết thực hiện, các công nghệ và các nền tảng, làm cho việc tích hợp dễ dàng hơn nhiều.

Vị trí của các ứng dụng cũng được trong suốt hơn. Một ứng dụng có thể là một ứng dụng C++, chạy trên Linux, trong khi một ứng dụng khác có thể là một REP được xây dựng tuỳ chỉnh chạy trên LAMP.

Kéo dài liên tục tuổi thọ của các ứng dụng hiện có
Bằng cách tiếp tục kéo dài tuổi thọ của các ứng dụng hiện tại, các doanh nghiệp có thể tiết kiệm tiền. Thông thường, những lý do quan trọng nhất để thay thế các ứng dụng hiện tại là: các chi phí bảo trì tăng cao, các khó khăn do tích hợp hoặc tính năng bị hạn chế. Bằng cách tạo ra các giao diện, bạn có thể làm cho các vấn đề tích hợp trở nên dễ dàng hơn và mở ra nhiều giải pháp mới cho các chức năng bị hạn chế.
Tái sử dụng giao diện hiện có
Lợi ích này sẽ chỉ cụ thể hoá sau khi tổ chức đã xây dựng một vài giao diện và các ứng dụng. Nếu các giao diện đã được thiết kế đúng, các chức năng của chúng có thể được tái sử dụng khi xây dựng mới các giao diện, tích hợp hay các ứng dụng.
Đáp ứng nhanh cho các nhu cầu nghiệp vụ
Với sự giúp đỡ của các giao diện và việc tái sử dụng các chức năng hiện có, bạn có thể đáp ứng nhanh hơn với các nhu cầu nghiệp vụ. Một số các nhu cầu nghiệp vụ được quan tâm nhiều nhất là để:
  • Mang dữ liệu hiện có hoặc chức năng theo cùng với nhau để sử dụng chúng trong các ứng dụng khác. Các dữ liệu có thể được tập hợp từ hai hay nhiều ứng dụng hoặc nó có thể đơn giản là dữ liệu nguyên tử (địa chỉ của khách hàng) mà nó được hiển thị cho các khách hàng trong ứng dụng Web tự chăm sóc.
  • Sử dụng các ứng dụng khác để cập nhật dữ liệu trong các ứng dụng hiện có. Ví dụ, ứng dụng tự chăm sóc cũng có khả năng cho phép người dùng cập nhật địa chỉ hiện tại.
  • Để các đối tác cập nhật dữ liệu.

Rõ ràng là một số lợi ích chỉ có thể có sau khi thực hiện một sự đầu tư lớn. Tuy nhiên, bạn có thể đạt được một số lợi ích với các khoản đầu tư nhỏ hơn và trong một khung thời gian ngắn hơn.

Chủ đề phổ biến trong các nhu cầu của doanh nghiệp đã mô tả ở trên là công ty muốn cung cấp các chức năng cho những người dùng hiện tại hay người dùng mới như là giao diện mới, chẳng hạn như trang Web hoặc cổng (portal) di động. Thông thường, những người dùng là mới, hoặc họ đã đang thực hiện một quy trình theo một cách khác nhau. Một trong những trình điều khiển quan trọng trong các trường hợp như vậy là cần phải làm giảm các chi phí (đây là các chi phí của việc chạy quá trình hiện tại).

Trong tình hình kinh tế hiện nay, một số công ty đang nghĩ về việc trì hoãn các dự án SOA của họ do chi phí cao. Nếu họ tiếp tục sử dụng các quy trình cũ, họ sẽ thực hiện được việc tiết kiệm và lợi nhuận kinh doanh mà giải pháp mới sẽ mang lại.

Phần tiếp theo nghiên cứu cách tiếp cận nhanh, sẽ làm cho một doanh nghiệp có thể bắt đầu được hưởng các lợi ích của SOA.


Cách tiếp cận nhanh với các lợi ích SOA

Một số người nói rằng, các nhóm nhanh đã quá liên quan đến các việc phân phối ngắn hạn và họ không quan tâm đủ đến kiến trúc. Nếu nhóm sử dụng một cách tiếp cận nhanh, không nhất thiết hàm ý họ đã quên kiến trúc (và xây dựng các chức năng chỉ cho các yêu cầu quan trọng nhất). Nhóm nhanh có thể tập trung trước tiên vào kiến trúc tổng thể và phác thảo đại khái hình ảnh của kiến trúc tương lai. Do các yêu cầu có khả năng thay đổi trước khi xây dựng hầu hết các kiến trúc hoặc các giao diện, hình ảnh lớn đó có thể được duy trì ở mức cao. Điều này là chính xác ở nơi mà chúng ta có thể nhận thấy một trong hầu hết các lợi ích trực quan của cách tiếp cận nhanh này.

Với các cách tiếp cận dựa vào truyền thống hoặc tài liệu, nhóm phát triển có thể dành nhiều thời gian đi sâu vào các chi tiết của hình ảnh lớn (mà trong giai đoạn sau sẽ thay đổi). Nếu bạn có một kiến trúc tổng thể chi tiết, bạn có nhiều khả năng đánh giá tổng chi phí để thực hiện toàn bộ kiến trúc. Những con số này thường có thể ảnh hưởng đến việc ra quyết định của các nhà sản xuất. Đây là một cách suy nghĩ nguy hiểm vì hai lý do:

  • Bạn không phải thực hiện toàn bộ kiến trúc.
  • Bạn nên bắt đầu được hưởng những lợi ích sau lần cài đặt lần đầu tiên được tung ra.

Hãy xem xét tất cả các ứng dụng trong tổ chức điển hình. Một số trong chúng được sử dụng hàng ngày bằng cách nạp vào của người sử dụng, trong khi những ứng dụng khác không được sử dụng thường xuyên và chỉ có một vài người dùng. Việc tạo ra sự khác biệt giữa hai loại ứng dụng này không khó. Tập trung hoạt động trên các ứng dụng SOA với nhiều người dùng hơn và sử dụng cao hơn là rõ ràng. Các phạm trù ứng dụng càng khó là những thứ dùng hàng ngày, nhưng chỉ có một vài người dùng. Liệu các quy trình là gay cấn (như báo cáo, hoặc khả năng hiểu biết của doanh nghiệp) hay không hoặc chúng sẽ thực hiện tốt cách mà chúng có không?

Nên thận trọng để nhanh chóng duyệt tất cả các ứng dụng và chọn những cái thực sự có vấn đề. Chỉ mất vài giờ để nhanh chóng phác họa kiến trúc tổng thể cho các giao diện và các chức năng chính của chúng. Sau đó bạn sẽ biết các phần tử (hay các khối xây dựng) là gì khi bắt đầu xây dựng các giải pháp đầu tiên của bạn. Đừng lo lắng nếu các giao diện được phác thảo sẽ thay đổi trong tương lai.

Sự lựa chọn của bạn về giải pháp đầu tiên là rất quan trọng, vì bạn muốn cho biết các chủ doanh nghiệp nhận được các kết quả không quá lâu. Khi bạn đánh giá nhu cầu kinh doanh có thể, hãy chọn cái gì đó tương đối dễ dàng để thực hiện. Khi sử dụng nhu cầu kinh doanh đã đề cập trước đây, một trường hợp điển hình sẽ cần cho phép khách hàng kiểm tra và cập nhật các chi tiết địa chỉ của họ. Tùy thuộc vào số lượng người dùng có thể, điều này là tương đối dễ dàng và nhanh chóng thực hiện. Tuy nhiên, nếu việc cập nhật các chi tiết địa chỉ đã thực hiện từ trước theo cách thủ công và số các thay đổi là cao, số tiền tiết kiệm có thể đáng kể. Đây sẽ là một nhu cầu kinh doanh lý tưởng cần được thực hiện.

Nhóm phát triển có thể xem xét các ứng dụng hiện có mà chúng có chứa các chi tiết địa chỉ, quyết định các ứng dụng nào trong số chúng là chủ hoặc đơn giản quyết định cập nhật thông tin tới tất cả chúng. Nhóm phát triển sau đó sẽ điều tra những khả năng để cập nhật dữ liệu, chẳng hạn như:

  • Sử dụng các giao diện mở hiện có, như các giao diện HTTP, SOAP, RMI hoặc giao diện khe cắm.
  • Sử dụng các giao diện giữa các ứng dụng hiện có, chẳng hạn như các thành phần Java.
  • Thu nhận và cập nhật dữ liệu trực tiếp tới cơ sở dữ liệu (chắc chắn rằng bạn không phá vỡ bất cứ quy tắc xác nhận hợp lệ).

Nếu rõ ràng sẽ có hàng đống các việc tích hợp lớn hay các việc tích hợp khó khăn vào các dạng ứng dụng khác nhau, thì đánh giá một sản phẩm tích hợp là khôn ngoan. Chúng có thể là quá đắt (và phức tạp) đối với các ứng dụng nhỏ, ngân sách nhỏ, nhưng chẳng bao lâu sau những lợi thế sẽ bắt đầu xuất hiện.

Nhiều lần, các công ty xây dựng các cổng (portal) Web để sử dụng thông tin từ các ứng dụng hiện có. Cổng sẽ là một cách tuyệt vời để thực hiện các chức năng cập nhật địa chỉ. Nhóm phát triển có thể xây dựng theo sự phát triển bằng cách: nhận lấy một sản phẩm cổng (nguồn thương mại hoặc nguồn mở); phác thảo và thực hiện các chức năng cơ bản của việc cập nhật địa chỉ tại cổng đó; thực hiện các giao diện; và tích hợp nó tất cả lại với nhau. Kích thước của ứng dụng khá nhỏ, do đó nhóm phát triển có khả năng thực hiện nó với thời gian hợp lý, tùy thuộc vào các ứng dụng hiện có và công nghệ của họ.

Nếu bây giờ bạn nhìn vào bức tranh lớn, nhóm phát triển đã bắt đầu cài đặt kiến trúc tổng thể. Thay vì thực hiện nó một tầng mỗi lần, họ đang giải quyết một nhu cầu kinh doanh thực một lần. Cả người kinh doanh lẫn nhóm phát triển đã học được nhiều về các ứng dụng hiện có, các tắc nghẽn có thể có và thực hiện các giao diện và các ứng dụng. Bây giờ họ có nhiều khả năng đề xuất các dịch chuyển tới nhu cầu kinh doanh.

Khi các nhà kinh doanh và nhóm phát triển chọn bước thực hiện kế tiếp, bước này có thể là cập nhật phát hành đầu tiên hoặc một ứng dụng mới nhắm tới một nhu cầu kinh doanh khác nhau, thì kiến trúc này sẽ là cần thiết. Do kiến trúc này đã chỉ là một bản phác thảo, nên thay đổi nó không phải là một việc lớn.


Kết luận

Bài viết này nghiên cứu tỷ mỉ các lợi ích của SOA và cách các tổ chức có thể nhận được những lợi ích thực với thời gian và tiền ít hơn. Bạn có thể sử dụng cách tiếp cận nhanh để tung ra một cái gì đó cụ thể mà doanh nghiệp có thể sử dụng. Như mọi khi, điều này là không thể cho mọi tình huống hoặc cho mọi tổ chức, mà bạn có thể biến dự án SOA bị từ chối thành một dự án được chấp nhận.

Các dự án SOA tiêu biểu liên quan đến các cổng Web theo cách này hay cách khác hoặc tại chính tổ chức đó (tự chăm sóc, bàn trợ giúp) hoặc theo các giải pháp của đối tác của họ (cổng đại lý bán lẻ, thương mại điện tử). Bằng cách thực hiện những nỗ lực đầu tiên theo chiều dọc, từ cổng thông qua giao diện đến các ứng dụng hiện có, thay vì theo chiều ngang (một lớp một lần), doanh nghiệp có thể tung ra các ứng dụng dựa trên SOA đầu tiên của họ nhanh hơn và bắt đầu tận hưởng lợi nhuận.

Tài nguyên

Học tập

  • Xem các phần khác của loạt bài này về việc chấp nhận phát triển nhanh:
    • Phần 1, "Phát triển nhanh có đúng với tổ chức của bạn không?" (developerWorks, 03.2008)
    • Phần 2, "Hiểu biết về các khía cạnh khác nhau" (developerWorks, 04.2008)
    • Phần 3, "Vai trò của các bên liên quan đến nhanh" (developerWorks, 05.2008)
    • Phần 4, "Sử dụng các câu chuyện của người sử dụng để xác định các yêu cầu dự án" (developerWorks, 06.2008)
    • Phần 5, "Áp dụng các câu chuyện của người sử dụng trong một dụng cụ lập kế hoạch tài chính dựa vào Web" (developerWorks, 07.2008)
    • Phần 6, "Quan điểm của người muat" (developerWorks, 09.2008)
    • Phần 7, "Các phương thức để đánh giá nỗ lực làm việc trong sự phát triển nhanh" (developerWorks, 11.2008)
    • Phần 8, "Mô hình hóa theo cách của bạn cho một quy trình nhanh tốt hơn" (developerWorks, 12.2008)
  • "Amazon’s SOA strategy: 'just do it'" (06.2006) mô tả cách đặt cược tốt nhất của bạn là để chỉ thoát ra ở đó và bắt đầu thực hiện nó. Và giữ nó đơn giản - rất đơn giản.
  • Đọc cuộc thảo luận của Wikipedia về SOA.
  • Agile Software Construction của John Hunt thảo luận sản xuất phần mềm nhanh cũng như việc mô hình hóa.
  • Mô hình hóa nhanh nghiên cứu phương pháp luận mô hình hóa.
  • Đọc cuộc thảo luận của Wikipedia về Scrum.
  • Đọc về các nguyên tắc của SOA trong Service-Oriented Architecture (SOA): Concepts, Technology, and DesignService Oriented Architecture For Dummies.
  • Đọc nhiều hơn về ScrumQuản lý dự án thích nghi bằng cách sử dụng Scrum.
  • Trong khu vực Kiến trúc trên developerWorks, hãy nhận tài nguyên mà bạn cần để đặt các kỹ năng của bạn trong vùng kiến trúc.
  • Duyệt qua cửa hàng sách công nghệ với các sách về các chủ đề kỹ thuật này và khác.

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ừ IBM® DB2®, Lotus®, Rational®, Tivoli® và WebSphere®.

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=441887
ArticleTitle=Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 9
publish-date=10302009