我們用許多模型來設計、開發、部署和管理技術解決方案。其中一些模型包括商業案例（business cases）、用例（use case）圖解、實體關系模型、對象模型、代碼、測試套件、開發計劃、邏輯數據中心模型和異常管理計劃。軟件生命周期方法已經努力發展成可以自動化的從“上游”模型產生“下游”模型，甚至可以在不同的模型間保持同步。 簡要描述了建�？臻g，概覽了當前的發展，這些都可以在整個技術生命周期中提高模型的使用效率。

　　模型是真實世界中對象和系統的 “簡化”抽象,可忽略大小、細節和外觀(例如，一個關注成本或持久性，而忽略不相關系統因素的模型)。 在信息技術解決方案的開發中，模型被用來控制復雜度，并在客戶、解決方案和系統架構師、開發者和運營人員之間傳達系統需求。

　　以工程項目大量使用的模型為例：用例模型可表達系統的高級功能需求和需要被支持的角色；風險模型可通過盡早地在項目周期中規避風險來優化工作；實體關系模型捕捉被解決方案管理的基本信息，并且提供將其適當分解為表格、對象和服務的建議；邏輯系統模型組成了開發和運營之間的通信基礎；邏輯系統模型可以進行需求和解決方案策略的早期確認，等等。

　　所有這些模型都使項目參與者能在最終系統的開發和管理中發揮其專長。所有這些模型都通過盡早避免誤解和疏忽來減少項目的代價和風險。建模工具和框架通過在各個級別的方案設計中提供更高級別的追溯性、可視性和說明性促進了商業部門和信息技術團體的合作。

　　在整個的軟件生命周期-從開發概念形成到運營和管理中，微軟關注如何使模型更有使用價值。由于歷史原因，在生命周期中通行的僅有的模型是含義模糊、冗余和很不完善的模型，而且是使用系統源代碼所描述。系統模型之間的不協調經常在組織內部和其間造成理解和溝通錯誤，導致項目和系統的失敗。

　　微軟的目標是讓所有的項目參與者--技術人員，專家和管理者都能夠獲取公司組織系統最適時、精確和有效的描述，并表達為各自熟悉的語言。微軟的意圖是使所有的項目參與者--從商業分析員到數據架構師，還有安全專家和網絡工程師，在解決方案的開發過程中盡可能的發揮他們的專長，盡量減少信息和知識的損失。

　　某些模型力圖在多個抽象層面上描述一個完全的系統。另外的模型則著重于系統的某些特定方面，諸如怎樣保持安全性，或者從系統的各個方面跟蹤性能表現。某些模型與解決的創建和開發過程有關，還有一些則預測并分析其在運營中的行為。

　　用例圖有可能是軟件工程中的最簡單的“完全”模型：系統的用例集合建立了對系統功能的展望，為系統用戶確定角色，并且提出了對運營的需求。用例可以發展成商務過程模型，派生出詳盡的需求模型，數據模型，對象模型，和最終的可編輯模型。 這些模型的層疊使人們聯想起軟件工程中熟悉的“瀑布”的概念。

　　系統建模的一個更好的概念是一系列的鎖定。不是隨隨便便的，被工具支持的系統化過程應該在良好的管理下從一個模型遞交給下一個模型。 遞交過程應該是平滑可預見的。 最重要的是，這些遞交應該是雙向的。用例應可以被轉換成為商業過程模型，而商業過程模型也應該是能轉換成用例的(雖然由于信息損失，你不能全保真的完成從客觀到抽象再到客觀的完整轉換周期)。理想情況下，這種映射的階梯流要允許所有描述系統的模型之間的同步。

　　在項目中支持這些相互映射模型的集合，將產生模型驅動 (model-driven development MDD)的開發模式。 在MDD中，模型成為開發過程中的最重要的原材料之一。 當一個系統架構模型允許或禁止橫跨企業數據中心安全區域的信息路徑時，這個模型就指導和約束了服務模型，很有可能影響服務設計。當數據架構模型確定數據訪問方法，工具就產生代理代碼和語言捆綁。MDD并不是一種全新的想法；成功的實現了模型同步的例子包括，多視圖數據建模工具，它可以使圖例化模型，基于實體的模型，和相關的數據架構都保持同步，還有就是可以在開發中保持外觀和代碼模型一致性的集成開發環境設計器。 我們可以從這些案例中汲取成功經驗以大大擴寬MDD的應用范圍。