構建軟件的時候，我們經常碰到一些技術相關的約束，特別是在大型組織裡。
- 批准的技術清單 ：許多大型組織都有一個允許用於構建軟件系統的技術清單，目的是限制組織必須支持，運行，維護和購買許可證的技術。如果你想使用任何不在清單上的技術，通常有一個漫長的例外流程，需要提出正式的申請。然而，我仍看到有團隊為了能在Java項目中使用Groovy或者Scala而偷偷引入額外的JAR文件！
- 現有系統的互操作性 ：在大多數組織中，你的軟件需要整合已有的系統，而實現整合的手段往往非常有限。除此之外，就是別的系統需要和你構建的系統整合。在這些情況下，你可能會發現，組織性的約束規定了你可以用於整合的協議和技術。一些我合作過的投資銀行就有他們自己內部用來在軟件系統間交換交易信息的XML結構。我可不會用「簡潔」和「易用」來描述它們！
- 目標部署平台 ：構建一個全新的軟件系統時，目標部署平台通常是影響技術決策的主要因素之一。這包括嵌入式設備、微軟的Windows或Linux服務器的可用性，以及雲。是的，即使這個我們稱為雲的神奇的東西，也有約束。舉個例子，每個「平台即服務」（PaaS）提供的都不同，對某些東西，比如本地磁盤操作，你的軟件能做什麼，不能做什麼，大多數都有限制。如果你不明白這些約束，部署時，陪伴你的很可能是焦慮的返工。
- 技術成熟度 ：有些組織樂於採用有風險的尖端技術，擁抱這種進步帶來的風險。其他組織本質上則保守得多。
- 開放源代碼 ：同樣的，有些組織仍然不喜歡使用開源項目，除非它跟IBM或微軟這樣的名字扯上關係。我曾經在一個高街銀行1 的項目中工作，該銀行拒絕使用開源項目，卻樂於使用來自一個非常著名的技術品牌的Web服務器。那是偽裝過的開源Apache Web服務器。這樣的組織在遇到問題的時候就喜歡沖人大喊大叫。開源許可證的混亂也阻礙了一些組織完全採用開源項目。如果你曾試圖解釋GPL和LGPL的區別，可能已經目睹過這種情況。
- 供應商「關係」 ：就像生活中的很多事情，不是你知道什麼，而是你認識誰。很多合作關係仍然是供應商請CTO（Chief Technology Officer，首席技術官）吃喝玩樂，在高爾夫球場上「達成」的。如果你曾為大型組織工作，也好奇為什麼你的團隊被迫使用一些明顯不合格的東西，原因可能就是這個！
- 過去的失敗 ：2000年前後，我帶著用Java RMI——一種允許通過Java虛擬機進行遠程方法調用的技術——構建解決方案的提案走進一家銀行。我遇到了很大的阻力，因為這家銀行已經「嘗試過它，不管用」。那個設計到此為止，任何討論都沒能改變他們的主意。由於過去的失敗，Java RMI在這樣的環境下被封殺。最終我們轉而構建了一個框架，通過HTTP將序列化的Java對像傳給一群Java Servlets（變相重新發明輪子）。
- 內部知識產權 ：當你需要找到一個庫或框架來解決所面臨的問題，很可能已經有符合你需要的開源或商業產品。然而對有些人來說這還不夠好，你必須使用組織自己內部的日誌庫、持久化框架或通信基礎設施服務。這種情況並不罕見，不管它們是否真能正常工作。最近我聽說一個組織構建了自己的CORBA2 實現。
1 一般而言，各大城市都有一條或者數條商業大街（high street），街上遍佈各種銀行、商店、郵局、警察局、超市、快餐店等。在英國，位於這類街上的銀行被稱為「高街銀行」（high street bank），主要是提供便民服務，也稱為「零售銀行」。因此這類銀行允許的貸款額度就比較小。——譯者注
2 Common Object Request Broker Architecture，通用對像請求代理架構，是由OMG（Object Management Group，對像管理組織）定義的標準，旨在促進部署於不同平台的系統間通信。——譯者注