Lost in Translation
       雖然IT團隊反應迅速，但他們通常帶來"電話效應"――IT給商業計劃的執行帶來的阻力和它帶來的利益一樣多。不幸的是，在開發團隊完全理解商業決策規則並實現之前，規則已經改變了。在軟體進入市場前，它已經過時了，需要進行重構以滿足新的業務需求。如果你是一個開發人員，你會知道我在說什麼。再也沒有比在需求變動的情況下構造軟體讓開發人員更沮喪的事情了。作為軟體開發人員，你必須比業務人員更瞭解業務，有時還要了解更多。
       試想一下你是一位商業決策者。假如公司的成功依賴於你對於市場趨勢敏銳的洞察力，它常常幫助你領先於競爭者利用變化的市場環境獲利。每天你都會得到更多更好的市場資訊，但並不要緊。完成新產品開發可能需要6－9個月，在此期間，對於市場大膽和敏銳的洞察和資訊優勢可能已經浪費了。而且，當產品釋出時，有這樣幾種可能：產品沒有什麼吸引人的特性，預算超支，過了產品的最佳釋出期限，或三者兼而有之。
       情況可能還會更糟，在完成產品開發時，市場環境和規劃產品開發時相比，已經發生了根本變化。現在你必須要遵守新的規則，你已經喪失了你的邊際優勢，而且設計軟體的五人中的三人已經離開了公司。你必須給接手的新人重新講解複雜的業務。如果事情不順利，你可能發現自己要對付一個缺少文件，並且你完全不瞭解的遺留應用。
       你的戰略在哪出現了問題？你在哪裡應該可以做到更好？最近的輕量級軟體過程，如極限程式設計，敏捷軟體開發等都在強調自動單元測試和軟體功能優先順序的重要性。除此之外，還有其他的原則，你的開發團隊可能也很熟悉，這些原則可以幫助他們對需求的變動作出迅速反應並縮短專案的開發週期。這些原則的大多數，如系統分解，多年前就已經出現，並得到了Java平臺的支援（如JMX等），還有如面向物件和角色建模，已經內建在Java語言中。
       但Java仍然是一門相當年輕的語言，而且Java平臺遠遠還沒有完備。當前在Java社群，一個引人注目的新技術是，分離商業決策者的商業決策邏輯和應用開發者的技術決策，並把這些商業決策放在中心資料庫，讓它們能在執行時（即商務時間）可以動態地管理和修改。這是一個你值得考慮的策略。
       為什麼你的開發團隊不得不象商業經理人一樣，在程式碼中包含複雜微妙的商業決策邏輯呢？你怎樣才能向他們解釋決策推理的微妙之處呢？你這樣做是否謹慎呢？可能不是。象bottom line一樣，某些東西在解釋的過程中丟失了。為什麼要冒這樣的風險，讓應用程式碼或測試程式碼錯誤地表達你的商業決策邏輯呢？如果這樣做的話，你怎樣檢查它們的正確性呢――難道你自己想學習如何程式設計和編寫測試程式碼，或者你的客戶會為你測試軟體？你一方面要應付市場，一方面要應付軟體程式碼，這實在太困難了。
       如果能將這些商業決策規則集中地放在一個地方，以一種你可以理解的格式定義，讓你可以直接管理，而不是散落在程式碼的各個角落，那該有多好。如果你能把商業決策規則獨立於你的軟體程式碼，讓開發團隊作出技術決策，你將會獲得更多好處。你的專案開發週期會更短，軟體對於變動的需求更靈活。