API (Application Programming Interface) 這個名詞，相信許多人都曾經聽過，其主要目的就是提供一個系統與外界程式溝通的介面，使程式開發者能藉此使用該系統所提供的資源 (函式、資料等)，在不觸碰到核心的狀況下順利完成開發作業，並確保原系統的穩定性。
台灣許多軟體公司在累積了許多某類型專案經驗後，常會進而思考：「若將此類系統產品化，不僅可擁有自我品牌的軟體系統，往後更可利用它加速相同類型專案的開發；一舉兩得，何樂不為 ?」於是許多的軟體系統產品便隨之誕生 (如：ERP、CRM 等)。這種作法立意雖佳，但若未納入良善的擴充規劃，所造成後續的系統問題將是難以估計的。
多年前，某家本土軟體公司自行開發了一套應用軟體，幾位主事者也非常有心，分別成立了研發組與專案組。其中研發組負責此軟體新功能的開發；而專案組則負責用這套軟體製作客製化系統，並適時回饋客戶需求，做為研發組設計新功能的參考。看起來相當不錯的組織規劃，卻在一段時間後出現了狀況：專案組隨著所接案子數量的增加，漸漸感到原有產品功能的不足，而提出增加功能的需求；但研發組主管卻認為專案組所提的需求中，許多功能的畫面太過特殊，並不適合納入通版，因此只針對部分的需求進行新功能的設計。於是雙方漸行漸遠，最後兩組終因績效不彰而遭整併，菁英份子流失逾半，得不償失。
上述事例中，若該研發組主管具備 API 的規劃能力，並將專案組所提出的功能需求由資料面進行規劃，並改以 API 模式進行開發；而不是一味地想著要將其開發為具備 UI (User Interface) 的功能，相信結果必大為改觀。
當然，API 不是萬靈丹，並非所有的整合問題都可靠它來解決；但不可否認的，它在軟體產品的設計規劃上，的確佔有舉足輕重的戰略性地位。善用它，可使產品更為精簡、更易應用於同類型專案的開發；反之，則將造成系統缺乏彈性且不易整合，甚或導致該產品的失敗。殷鑒不遠，慎之！慎之！
