e-化的 Business 系統的特色即在於強調分散式(Distributed)的架構。而分散的系統又必須整合以建構完整的企業服務(Business Process)，並期能達成快速組裝流程來因應顧客的需求(Requirements)。

在現今新潮流的分散式系統的特色又凸顯了：

● 每個 Site 是為整體系統的子系統(Sub System)的一份子。

● 子系統之間有依存性(Dependency)的關係，此種關係是為一種動態的服務需求來建立的。而提供動態的服務則以 Web Service 來串連。

● 子系統很有可能是各種異質性的系統建構的，所以不能僅使用某種廠商所提供的分散式技術，而必須採取更具標準化的分散式交換資訊的標準。所以這更凸顯了以 XML、SOAP(Simple Object Access Protocol)等元素所組成的 Web Service 的價值：XML 提供了結構化來訂定資料交換的標準 ; SOAP 提供了架構於 HTTP 之上的一種簡易交換資料的通訊協定，利用 URL 即可在不知所提供服務的系統的實體位置狀況下，此稱之為位置的透明化(Transparent)，能以簡單的 領域名稱(Domain Name) 命名來與對方溝通。

● 不能假設所有的子系統都是由自己來建立的，有可能有些子系統是需要外包(Out Sourcing) ; 或有些子系統是已既存的(Legacy System)。所以對於子系統之間的整合，我們是強調於介面(Interface)上的整合，而不是與內部的實體系統來聯繫。可以想成每個子系統都是一個可以獨立運作的有機體，有機體之間是利用觸角來相互溝通。此觸角(Interface)是對外溝通的唯一管道，對於有機體內部的結構，外部的系統不需也不必知道其細節。

分散式系統具備了上述的特色，這使得我們對於分散式系統的分析及設計上的開發流程(Development Process)，勢必做一些修正，其主因在於傳統的分析設計假定於：

● 將欲開發的問題領域(Problem Domain)看待為一個完整的系統。

● 因為看待成為完整的系統，所以都假設從分析、設計乃至實做不太考量到分散式的問題，也因如此，就可能僅會是一張完整的類別圖(Class Diagram)。

● 傳統的分析都是建基於從已知的需求來取得領域上的知識，並據此來建構類別圖。但是提供 Web Service 的分散式系統，常常必須在不知道 User 需求的前提下，也要能提供服務。如何在未知需求的情況下來分析系統，就變成了是分析師非常大的挑戰了。

先整合各分散的子系統，將其觸角連結起來，以快速提供動態完成的服務給顧客是分散式系統最大的特色。相對於不同以往先假設一個完整的系統，再去切分再整合的手藝有著完全不同的開發流程的思維。

所以在不違背 RUP(Rational Unified Process)的基本精髓下，我們需考量修正 RUP 的開發流程步驟來因為現實分散式系統的架構。

在此，提供了所謂兩段式 RUP 的開發流程：

第一階段先將焦點集中於各分散的子系統的整合，以建立一致性的架構(Architecture)。這也正符合了 RUP 的最重要的基本準則：Architecture Centric(First)！

然後第二階段則依據在最抽象的整體架構思維上，從外部的 Actor(如顧客)所觸發(Trigger)的 Use Case的需求分析上，可以據此來得出許多個小的 Use Case 分佈在各子系統上，串結合作以達成顧客的 Goal。開發團隊，就針對此，來針對各個 Sub System各自帶開，各自表述，依 RUP 的四大階段及紀律(Discipline)來做分析及設計，以實現(Realize)該 Sub System 所負責的 Use Case。

此兩段式的 RUP 開發流程是以反覆式(Iterative)的方式來漸進循環的。也就是說，先建立整體的雛形架構(Architecture)後，每個負責實做子系統的團隊必須定時的回報(Feed Back)以驗證該整體架構的一致性及完整性。如此反覆循環，才有可能建立一致性、整體性、和諧的分散式系統。