現在網路和分享這麼發達，你可以很容易的搜尋到很多公司或人分享出來的系統架構，舉凡 Stackoverflow、淘寶、百度或是其他公司實作一個解決方案的整體架構，用來當參考架構 (Referential Architecture) 是很棒的藍圖，不過它就只是個 "藍圖"，你所不知道的是他們花了多少錢去做，或許一個人用雲端也可以做到，但是並沒有減少它應有的成本，就像你不可能妄想用一台 VM (裡面即使跑得動十萬台 Docker Container) 來服務一億個使用者一樣。
同樣身為軟體架構師或開發者，當你看到這樣的架構圖時一定會開始熱血沸騰。
尤其是現在 Open Sources 解決方案如此多，雲端大行其道的氛圍下，任何人想要實現類似的軟體架構愈來愈容易了，同樣的，抽象化滲漏法則一直在不斷蔓延，在一個大型解決方案背後，即使它只提供了幾個簡單的 REST API，還是無法隱藏或省掉它應該要支付的成本，我所說的成本是指整體擁有成本 (Total Cost of Ownership, TCO)。這個成本可以分好幾個層面：資源的成本、整合資源的成本、學習與試誤的成本以及你看不到的隱藏成本。
首先是資源的成本 (Resource Cost)。就像日前很紅的新聞 Facebook 要關掉 Parse.com，Parse.com 是一個 Mobile Developer 很愛用的 Backend Platform，Mobile Developer 只要了解如何使用它的 API 就能造出一個 app 所需要的後台 (Azure 也有類似的 Mobile App)，但是你有辦法複製出和 Parse.com 一模一樣或類似的服務嗎？即使他們有公布其架構：
或許你會覺得在雲端上這麼多的資源，不論是 Azure, AWS 或是 Google Cloud，上面的資源都足以支撐這種架構，但是取得資源是一回事，怎麼把資源串起來又是一回事，取得資源只要上雲端供應商的管理介面，或是使用指令，再加上信用卡就能輕易取得，而且基本上是要多少有多少，例如你可以建個 1000 台 VM 在 AWS，或是建 100 個 Azure SQL Database 做分流，不過可別忘了，資源的獲取很容易，錢花得也很容易，一個能承載萬級 (甚至百萬級) 使用者的架構絕對沒有你想像中便宜。
第二種成本是整合資源的成本 (Cost of Resources Integration)，這在以專注核心能力的主的現代而言，軟體開發早已不是一個功能通吃，而是將各個功能分散成不同的元件來組合，在分散式系統中要找不同的元件相當容易，Open Source 當道的現代，Apache Foundations 提供那麼多的軟體元件，諸如玩大數據的 Hadoop、玩資料流分析的 Storm、玩巨量資料處理的 Spark 以及管理 Container 的 Mesos，哪個不是免錢的，但是免錢的背後是，你要花費更多的時間去學習並實驗如何將這些資源整合起來，就像前陣子媒體在說...矽谷流行的是 SMACK 架構 (Spark, Mesos, Akka, Cassandra 與 Kafka)。
說真的，就算你知道 SMACK 架構，有沒有足夠的能力將這幾個元件組合起來又是另一回事，為了要整合這些元件，要花費多少成本？找外面的專家可以，找公司內的員工可以，自學也可以，但不管是哪一種都要花成本，只是一個是花錢，另一個是花時間。
第三種成本是學習與試誤的成本 (Cost of Learn and Try/Error)。就像前面的 SMACK 一樣，要架設一個滿足需求的架構光是靠網路那些看起來成功的軟體架構圖是沒用的，每個架構圖內可都是經驗滿點，每個元件都有專屬的 Configuration 以及整合方式，就算再開放的平台也都有 API，如何使用這些 API 或 Configuration 組出你要的 Solution，可不是能隨意複製的東西，而且這裡面的含金量並不低，含金量的多寡取決於這套架構要用多少經驗值來組成，若是只光看架構圖就能生出架構，不好意思，那這樣的可替代性就會提高，可替代性是會侵蝕含金量的因素之一。
學習的成本是花在如何使用 API，這部份算是便宜的了，因為網路上都有很多文章可查，原廠通常也會有一套文件庫，只要有一點融會貫通的能力的話，學一套新的東西 (尤其是會了 MySQL 去學 SQL Server) 通常不會花太多時間。試誤的成本又能稱為撞牆成本，就是要用這些資源整合出你心裡想的架構，要撞多少牆，以及在撞牆之間會消耗的成本 (例如嘗試別人寫的作法)，例如 Azure Search 和 Azure DocumentDB 是很好用的搜尋與 Document-based NoSQL，但是真正在使用它來組出你想要的架構時，會撞多少牆你不會知道。軟體架構是一個有機體，在不同的適用情境下，即使用的是相同的資源，都還是有可能出現撞牆的情況，要找出拆牆或是繞過這個牆的方法所需要的成本 (通常是時間，請人來幫忙則是花錢)，就是撞牆成本。實作一個可用性分析的 PoC 的成本就是花在這裡，但如果不願意花這個成本，你會有很多事情不知道，這會大大影響日後的架構上線的營運。
最後的成本是隱藏成本 (Hidden Cost)，就是你無法在網路上那些分享的架構圖中看到的東西，網路分享的架構多半只會交代系統方塊圖以及使用的基礎元件，但他們基本上不會告訴你他們花了多少撞牆成本去組合出這樣的架構，因為那是商業機密，要做撞牆的事的通常都是 RD，基本上沒撞過牆的 RD 不能被歸為 RD。RD 的任務就是找出未來的可能性，而這樣的可能性也是撞出來的，這才是 RD 真正的價值所在，當然這也會是個賭注。除了撞牆成本之外，實際營運，以及營運期間引發的成本，你也不見得看得到；為了要滿足架構需求去額外開發的軟體元件 (例如 Microsoft 為了 SDN 客制了 Linux OS 做 Cloud Switch, Facebook 客制了 PHP 與 Linux 支援臉書需要的分散式架構) 也是要成本，這些成本在分享中基本上是看不到的，即便是 Stackoverflow，他們也還是針對他們的需求開發出像 Dapper 和 StackExchange.Redis 這些 Open Source 元件，那些元件也是需要成本的，不是隨便就能生出來。
所以，架構圖人人會畫，要畫張系統方塊圖對一個資深軟體工程師或是軟體架構師而言是輕而易舉的事，但他們只會給你看他們想讓你看的 (好像媒體做新聞一樣)，不該或不能讓你看的，抱歉，你啥都看不到，這也是 RD 和 PoC 重要的原因，在架構藍圖下找出可行的架構設計，再落實到系統開發上，這段期間隱藏了很多的成本，如果一個軟體公司的老闆不願意花錢投資在 RD，那基本上也不用去要求他們寫的軟體會有多好。只是就現實面考量，老闆還是會在意成本，因此現在很多架構都會採用整合 Open Source 元件來產生，但是就像我前面說的，如果連整合的成本以及學習試誤的成本都不想花的老闆，其實不跟也罷，尤其你如果是 RD 或是 RD 導向的架構師的話。