Web應用程式
Web和桌面應用程式相比有很多優勢，包括管理集中、升級容易，以及客戶端統一的特性。其唯一的不足之處是，如果你無法訪問服務器，它們常常就無法工作。但是，就是這個問題也被涉及到了，包括對連線斷開的Web 應用程式甚至是連線斷開資料庫的支援。
分層應用程式
在分層的解決方案中，元件按照功能被分層，不同的層常常位於不同的計算機上。在設計分層應用程式的過程中，當你把概念設計轉換成邏輯設計時，你會希望區分開它所需要的各種層。分層應用程式的巨大優勢包括其可伸縮性和易維護性。其不足之處就是複雜性的問題。
協作應用程式
最後也是最複雜的應用程式型別是協作應用程式。這種型別應用程式的一個例子是微軟NetMeeting的白板特性，它能夠允許多個使用者同時在白板上寫字畫畫。白板的所有使用者都能夠實時地看到任何變化。Visual Studio 能夠允許許多開發人員在同一時間開發同一個應用程式，因此它是協作應用程式的另一個例子。
邏輯、擴塊和基於元件的設計
一旦建立好了你概念設計的要點並辨別了按照這一概念所構建的應用程式型別，你就有了解決方案的基礎。然後你就可以開始設計組成可交付產品的真正元件和服務了。就和所有的設計元素一樣，元件和服務的定義在編寫程式碼以前都應該能夠被仔細地歸檔和考慮。
元件
如果你告訴某個程式設計師你需要一個元件，那麼你會獲得一個ActiveX控制元件、Java的類或者是的元件，具體是哪者要依據平臺的不同。但是如果你告訴一個軟體設計師同樣的事情，你會獲得不同的'東西。對於軟體設計師而言，元件就意味著任何一小塊解決方案，這個方案被作為一組功能和特性分離開來，並和這一解決方案的其他元件相關。例如，結構元件可以是一組資料儲存過程或者是能夠放在CD上的可重新分佈的客戶端程式。它也可以是使用者需要用來使用最終解決方案的一組技巧。你需要像設計師一樣思考元件，這樣才能充實你的元件設計。把商業條例整合到物件設計裡
不論你的解決方案是一組元件、一套服務或者兩者的組合，你都希望確保它整合進了機構的商業條例：這些條例會定義或者限制你解決方案所關注商業的特定方面。這一過程很容易就會成為導致整個解決方案失敗的地方。無論這個解決方案設計得有多穩固多周密，如果它違反了重要的商業條例——例如“每筆購買訂單都必須由管理層的一員認可”——它就會被認為是失敗的。
邏輯設計對PASS ME目標的影響
邏輯、模組和基於元件解決方案的設計的最後一部分會發生在設計過程的最後，並會向後延續一段時間。你有了一個可以接受的解決方案，但是現在你會希望確切地知道這個方案能夠在多大程度上滿足你的期望，甚至超過你的預期。這一階段就是你收集其優勢確定自己的解決方案是否滿足了PASS ME目標的時侯。它執行得是否良好?它是否能夠被需要訪問的人輕易地訪問到?它是否穩定和安全?它是否易於維護?它是否能夠滿足未來的要求?
