POC, Proof of Concepts, 從字面的意義來解釋的話，即為 “概念性的驗證”。

既然是需要驗證(Proof)，所以 POC 是一種 “解決方案(Solution)”，是針對 “概念” 所提出的解決方案，而架構的 POC，目的即在於擷取出最精要、核心的解決方案(Solution)，以作為解釋架構的概念依據。

我與 Ringle 聊到 POC，他原來對 POC 的認知是對客戶所提出的一種解決方案，所以主要滿足對象是 “客戶”。不過，對於架構的 POC，我不太認同對象是客戶，我會以為，會希望能透過某種概念性的解決方案，而對架構有整體、全貌性的認知者，那才會是架構 POC 的對象。

所以，誰負責撰寫架構 POC？ 我認為是 “架構師(Architect)”，誰想瞭解及驗證架構 POC？我以為是開發團隊所有成員與利益關係人(Stakeholder)。

架構 POC 的對象釐清後，再來是瞭解其呈現的具體樣貌是什麼樣子呢？底下是架構 POC 具化的幾個可能樣貌。

• 解決方案所需運用的相關技術(Framework, Pattern …)。
• 利用 UML 語法建構概念模型草圖(Sketch)，以表達某一解決方案。
• 利用模擬(Simulation)的方式提出解決方案。
• 可以被執行的原型 (Prototype)。

我個人傾向利用可以執行的原型(Prototype)來作為架構 POC 的具體樣貌，因為：

• 架構師以 “原型” 做為與開發團隊與利益關係人的溝通、達成共識的橋樑，然後才著手執行。透過原型，大家比較容易對概念(Concept)產生共鳴，並致力改變尚未成形的東西。
• 原型協助架構(Architecture)的建立，讓大家能容易看到整體、更具宏觀的角度來看待複雜系統。並因此而避免一頭就栽進種種的細節(Detail)。
• 原型可把目標清晰地描繪出來，並且讓每個利益關係人(Stakeholder)都更容易提供意見，進行改革。

而且，架構原型可以：

• 在架構落實以前，讓團隊成員能自由表達看法，並進行討論、提出建議。
• 讓團隊成員隨時表達意見，有機會影響你正著手進行的方案。
• 不斷加快前述兩個步驟(一般稱之為「快速建構原型」)。

對了，架構原型除了比較容易協助團隊成員一窺系統的整體全貌外，對系統內部的結構(Structure)分析與設計的呈現，也能有一番基本的認知。

所以，架構原型的內容，我會擺上表達整體系統的使用案例模型；實做兩、三個具代表性的使用案例，並畫上概念性的類別圖與循序圖；同時，我還會加上與 .NET or J2EE 等平台相依的細部類別與循序圖；實做面，確實可以產出可以執行的程式碼與測試碼；最後，我會利用簡單的 UI(User Interface) 作為執行畫面的呈現與說明。

原型，並非是 “粗糙”，或是 “應付性” 的，它是一個框，是可以被驗證的，但並非僅利用外表美美的圖形使用者介面來對系統作概念性的驗證。架構原型，反而不是重視圖形介面，它要強調的是一種對系統的整體觀與結構觀。至於圖形介面與企業流程的功能，反而不是那麼重視。精密與細節、正確性的工作，是對系統的整體有了正知與正覺，往正確的大方向走後，才確定要做的細節性工作，可以把它作對。人們，尤其是組織性的團隊，最常犯的錯誤是：「把不必要的事情作太好」。