套件自訂

資訊科技部門常見的問題是，要透過建置自訂軟體或購買套件來提供功能。在我開始程式設計以來，關於如何做出這個選擇的爭論就一直持續著。我對此的基本立場建立在 UtilityVsStrategicDichotomy 上。簡而言之，這表示如果你支援的商業流程是你競爭優勢的一部分，你應該建置自訂軟體；如果不是，你應該購買套件，並調整你的商業流程以符合套件運作的方式。

儘管我的意見顯然很優秀，但似乎沒有很多公司這麼做。他們常常忽略這個二分法，這是一個問題。但我想在此關注的問題是，當他們購買套件時常見的陷阱。

你會注意到我在上面說「購買套件並調整你的商業流程以符合」。我這麼說是基於兩個原因。首先，如果你購買套件來支援實用商業流程，那麼在商業流程中沒有差異化，因此你最好以符合套件的方式執行該商業流程。當然，這是一個非常以軟體人員為中心的觀點。儘管團隊沒有執行可區分的作業，但他們仍然寧願用自己的方式執行，而不是用某些愚蠢的軟體套件想要執行的。作為一個相信人重於流程的人，我自然對這個觀點非常認同。

但是，這種自然行動的結果是，公司開始對套件進行大幅度的自訂……而這就是問題的開始。事實上，大多數套件的設計方式並非讓自訂真的可行，至少不是在顯著的規模上。它們通常缺少我的同事 Scott Shaw 所稱的「可交付性」，例如版本控制、測試和部署管線的支援。這使得變更容易出錯且難以控制。

如果您自訂的內容很小，您可以忍受這一點，但在許多情況下並非如此。最近一位同事遇到一個套件自訂，執行長達 300KLOC 的自訂程式碼。這比我們 Studios 產品套件的整個程式碼庫還要多，是我們一個大型客戶專案程式碼庫的兩倍，而該專案已經營運策略性業務長達十年。一旦您達到這些規模，您不能期望在沒有自訂軟體所使用的工具和流程的情況下進行管理。

當供應商釋出套件升級時，這個問題往往最容易浮現，您會發現升級涉及大量的禁止性工作，因為自訂會隨著升級而中斷。Gartner 最近估計，需要 5000 億美元才能將企業系統升級到最新版本（到 2015 年將上升到 1 兆美元）。這是一個很大的數字，但真正的成本是浪費在不值得自訂或透過純自訂路線可以更便宜的自訂上。

那麼您可以怎麼做呢？首先，我認為對公用事業功能的套件自訂採取強硬態度很重要。軟體方面的成本真的值得嗎？儘管敏捷方法對公用事業功能來說不太重要，但採取小步驟的概念很有價值。您是否可以最初不使用自訂來使用套件，並嘗試了解它在實際運作中的效果如何？人們自然會對改變感到不舒服，因為人們天生如此。但經過一段時間後，他們可能會發現他們認為重要的事情現在變得不那麼重要了。

我們可以更認真地了解自訂是如何完成的。有些方法比其他方法更難交付。尋找其他人在套件的舊版本上執行過類似程度自訂的人，並找出他們升級時需要做什麼。這可能有助於更真實地了解成本。一般來說，對於套件，我們應該將可升級性視為一級跨功能需求。

當您讓供應商自訂套件時，讓他們遵循客戶的交付實務非常困難。他們不遵循這些實務的風險很高，應將其納入您的風險規劃中。

許多組織嘗試限制他們使用的語言或架構數量。我們必須記住，許多這些可自訂套件實際上是另一種語言或平台。因此，任何反對採用另一種語言的論點也應同樣適用於套件自訂工作。

事實上，反對引入新語言的常見論點是，這使得難以找到該語言的開發人員。這個問題通常特別適用於套件，因為這些套件通常提供狹窄的職涯機會。此外，許多套件自訂工作的性質會阻止有能力的人，這使得更難找到對多語編程較為自在的優秀人才。使用套件而非在主流程式設計平台中進行自訂開發所涉及的聘僱人員困難成本，可能會高於任何成本節省。

與其自訂套件，不如看看該套件是否能透過有效 API 公開資料和功能，並為自訂功能撰寫自訂應用程式。人們通常不喜歡這樣做，因為這表示他們必須為相同工作流程的不同部分使用不同的應用程式。這可能是一個較小的負擔，而且可以使用網路介面縮小。供應商可能會讓這變得困難，因為這可能會減少鎖定，但協作容易性應為選擇與哪個供應商合作的重要考量。

但這裡有一個陷阱。自訂的主要來源之一是整合不同供應商套件。這是偏好單一供應商提供多個套件，而非挑選同類最佳的原因。挑選單一供應商可以更容易進行整合，因為讓整合正確符合他們的利益。如果這是一個公用事業功能，那麼同類最佳套件的價值本來就有限。

歸根結底，套件環境通常提供一個非常差的軟體開發平台。許多人往往認為，自訂和維持這些套件的最新狀態的成本要高得多。