作者：AWS 企業策略師 Gregor Hohpe
您是否該購買核心軟體應用程式，還是自行建置？ 傳統意義上，高層使用簡單的規則回答此問題：建置使業務與眾不同的部分；購買其餘部分。在客戶期望快速變化的環境下，IT 決策不再那麼簡單，今日的差異必將成為未來的商機。了解雲端技術如何為您的 IT 架構開闢新的選擇，甚至可能無需詢問購買與建置的問題。
建置的限制
當明智的高層面臨艱難的 IT 決策時，他們會採用啟發式方法，即協助他們形成判斷、做出決策並找到複雜問題解決方案的簡單策略或心理過程。許多組織使用啟發式方法來回答此關鍵問題：我該購買核心軟體應用程式，還是自行建置？ 他們參考的簡單規則是：如果功能將讓我們脫穎而出，那就應該建置。但是，如果無法，則應購買。
這是一個不錯的起點，但是 IT 不是那麼簡單。自我建置的軟體受三個經常被忽略的限制所限：
這是一種機會成本。
您的開發人員花在建置自訂專案上的時間，是他們原本能投入到其他地方產生商業價值的時間，例如，開發另一種產品。這就是為何您必須考量其實際成本 (例如薪酬和設備) 以及其機會成本 (可能是其數倍) 的原因。向廣泛的客戶群銷售商業軟體的經濟性，增加了在內部建置更便宜的系統之可能性。例外情況可能是商業軟體附有許多您不需要的功能。幸運的是，這些類型的系統很少。
軟體是鏈條中的一環。
商業價值並不是由軟體開發單獨產生的。基於功能清單的自訂軟體僅是您價值鏈中的第一環。您還將需要一個生態系統，能具備相符的透明度、支援系統和敏捷程序。設想您已建置自訂前端，但後端系統的變化速率過慢。在此情境下，您的軟體工程師在等待交付新功能時毫無進展。或者您的功能清單在對使用者最有價值的環節留下了空白。甚至要意識到您的清單不完整，您需要高度的透明度。以更有用的功能更新清單，您將需要同等高度的敏捷性。
您仍在投資其中。
許多組織考量建置自己的軟體以享有自主權，因為若能自行建置軟體，則可隨心所欲地使用，對吧？ 不完全對；您仍然受制於系統的複雜性和資產價值，而這只是您自己創造的一個。例如，將系統移植到新技術可能比商業軟體更難。資源限制可能會限制您實作的功能。
簡單的購買或建置決策終究無法如此簡單。與每個 IT 決策一樣，它需要經過仔細的解釋和鑑別。做出明智的決策需要的，不僅僅是一個簡單的規則或啟發式方法。這就是為何「思考」是具有最高投資回報之一的 IT 活動。
作者簡介
Gregor Hohpe
AWS 企業策略師
在 Amazon Web Services 擔任企業策略師一職時，Gregor Hohpe 常建議技術領導者轉變自家技術平台和組織。憑藉他作為新加坡政府 Smart Nation Fellow 和 Allianz SE 首席架構師的經驗，他將企業戰略與技術決策聯繫起來，而彼此相輔相成。他樂於在書中分享對於架構和結構的看法，包括 The Software Architect Elevator (軟體結構升降舵) 和 Cloud Strategy (雲端策略)。
閱讀購買與建置部落格系列
邁出下一步