記得在學校畢業前有一門必修課，叫 Digital Transformation，主要是利用個案來探討資訊科技對於企業甚至政府的影響：在這些個案中，主角都因為科技的變化而遭逢了一些問題，有的是傳統產業想要升級，有的則是國家的港口想要轉型，在這些個案中，對於資管的學生來說，科技，幾乎就是唯一的解答。所以甚至會看到有些不太認真的組，提出: “該公司應採用 Java 相關的 Web 技術來設計系統” 給 1995 的公司。的確，有些公司的問題，確實是只要等待科技稍微進步一點 (例如，BlackBerry 機的出現)，就會比較容易解決，但是實際上，管理上的問題並沒有這麼簡單，這也是同樣的技術，用在不同的公司，會有完全不同下場的主因。

前陣子聽到主管討論到把公司的每一個網站元件都切成獨立元件的問題。在工程師的完美世界裡面 (或是有一些 SOA 的宣傳文件裡面)，每一個 Service 都應該可以獨立運行，彼此之間只要界定好介面訊息，撰寫和維護各元件的工作應該就可以切開給不同的人 (或組) 負責；”負責” 代表權和責，某人要為它負責，當然需要確保這部份元件運作正常；既然他要負責，而且我們已經有完美的介面，自然其他人也應該尊重這個封裝，不應該去動他的程式碼。

幾乎所有老經驗的程式設計師都會同意，loosely coupled 和封裝可以減少很多問題，只要…我們不考慮效率的問題。

企業在軟體開發上的效率就是…

…當別人的元件有 legacy bug，你有 solution，而你又是修掉這個 bug 最大的受益者，你可以進去改；
…為這個元件加上一個特殊的 case，就可以做另一種客戶的生意，而你的部門又是接到這個單最大的受益者，你可以進去改；
…當別的元件已經寫好的另一個函式完全可以處理你想要做的事，你不用另外再建立相同的程序只因為你們沒辦法互通；

當然，那些顧問們也可以找出許多反對這些動作的理由，但這也只是證明了，技術問題完全不是你該不該允許選擇這樣做的關鍵；反之，公司文化和管理才是最大的問題。

例如，與其去問說，有沒有可能定義出完整的 Interface 給這兩個 Services 來銜接，倒不如問，當目前的 Interface 沒辦法處理這個狀況時，組織間溝通的時間需要多長？若把目前已知的狀況當作 Cache，討論出新解法並改完程式的時間叫 cache miss penalty，依據記憶體設計的原理，我們都知道單單提高 Cache Hit Ratio 是不夠的。商業流程永遠在變，所以不可能會有 100% 的 Hit Ratio，但是有些組織卻會有無限久的 Cache Miss Penalty Time！

很顯然的，要處理公司內部之所以會有很長的 Cache Miss Penalty Time，並不是什麼新技術就可以處理的… 組織的無效率和門戶之見，永遠才是產出大問題的主因。