對於主要由應收款業務模型驅動的公司而言，其核心的業務功能之一是輸入、跟蹤和記錄訂單。在這方面比較出色的公司可以伸縮它們的機構，並提高它們的利潤，而不會遇到基礎架構的限制。當訂單處理很麻煩、容易出錯或不一致時，公司將因為直接的成本和降低的生產效率而蒙受經濟上的損失。
在我的公司 Myers Internet，核心的業務事項圍繞著建立客戶基礎，為 Myers 提供持續的服務並幫助它在客戶問題出現時解決問題。公司正使用許多不同的系統來處理訂單輸入和實施周期的各個方面。這些系統既不是彼此集成的，也不具備確保每一份訂單都得到正確記帳的機制。
Myers 訂單跟蹤系統 (MOTS)
就像其它許多機構一樣，Myers 從一個小型公司成長為一個中型公司，同時在它的整個成長期間始終保留了相同的過程和系統。大多數這些過程在建立時，所有的事務處理都通過電子郵件、紙質記錄和實地拜訪來人工地完成。5 或 6 年前，Myers 的一個工程師利用 Allaire 的 Cold Fusion 和一個 Microsoft SQL Server 數據庫組裝了一個系統來跟蹤訂單實施，這個系統稱為 MOTS (Myers 訂單跟蹤系統)，它允許銷售和帳目管理部門輸入訂單，然後由支持、工程、設計、信息系統和會計部門實施這些訂單。雖然這個系統是向前邁進的重要的一步，但它仍然留有許多人工的步驟，並且沒有和任何其它的業務系統集成在一起。
大概在同一時間，還創建了一個系統，在這個系統中客戶和銷售代表可以在線訂購 Myers 網站的產品。這個系統可以創建新的 Web 站點，並計算提供的 Web 站點程序包的安裝和重復性費用的總和。然後它發送電子郵件給各個部門，各個部門可以將訂單輸入到 MOTS 中，並在帳目管理系統中創建記帳信息。
體系結構障礙
這種類型的體系結構飽受幾種系統問題之苦。在 Myers，較明顯的問題之一包括啟動訂單跟蹤所需的人工數據輸入，以及作為這種人工過程的結果而產生的錯誤。另一個問題是公司中的訂單輸入、訂單跟蹤和記帳系統之間的脫節、訂單丟失、信息遺漏和其導致的錯誤。
另一個僅偶而出現的問題是 MOTS 系統本身有內在的缺陷。由於編寫 MOTS 的方式，可以輸入沒有部門分配信息或者丟失了部門分配信息的訂單。當這種情況發生時，訂單最終將在系統中丟失。當訂單丟失時，准確、及時的記帳就更難實現了。
隨著業務的成長，體系結構中的缺陷變得越來越明顯，並且隨著客戶和訂單數量的增加，丟失和錯誤輸入的訂單出現的頻率越來越高，從而給公司收入帶來了難於估量的影響。此外，人工輸入的數據的數量導致了延遲和處理效率低下。
由於在實施機構內對收入的影響加大和效率降低，很明顯必須要有一個替換系統來將一切聯系起來，並提高效率和降低錯誤率。舊系統圖示如下。
圖 1：舊的系統體系結構
該圖顯示了需要人工數據輸入的所有區域。由於這些系統都不是集成的，所以數據丟失或失真的可能性非常大。全局需求馬上變得明顯起來。訂單系統需要直接和實施跟蹤系統聯系起來。該系統需要安全保護來防止訂單在未經處理之前脫離系統。需要保持精確性，以確保准確的記帳和正確的訂單實施。系統需要使內部成本最小化。所以，要達到那個目的，需要快速地創建系統，但系統必須擁有完整的功能。
雖然一個好的訂單輸入和跟蹤系統可以幫助降低成本，但它本身並不創造收入。
深入結構
在開始模式設計之前，需要解決一些基本的體系結構問題。第一個底層的技術需求是系統必須可配置，且無需額外的編碼。本質上，這意味著需要把工作嵌入到數據庫中，而不是用解釋/處理代碼來進行硬編碼。第二，數據庫需要包含足夠的信息，以便能夠表現訂單輸入界面的主要(和可更改)的方面以及實施處理。
在努力解決上述問題的過程中，該系統逐漸適合於兩個部分 — 訂單輸入和訂單跟蹤，並在兩者之間提供了明確定義的聯系。訂單輸入系統需要知道如何用准確的產品代碼、折扣和定價條款來表示訂單。訂單實施系統需要知道如何跟蹤各種類型的任務、相關的作業和各個部門，以處理和記錄每份訂單。最後，需要定期和可預測地把訂單轉化成實施作業。下圖顯示了目前存在的新系統的結構。
