企業架構

最近我在亞馬遜上看到一些對 P of EAA 的負面評論，因為書中沒有提到企業架構。當然，這是有原因的——這本書是關於企業應用程式架構，也就是如何設計企業應用程式。企業架構是一個不同的主題，探討如何將企業中的多個應用程式組織成一個有條理的整體。

事實證明，我對企業架構相當憤世嫉俗。這種憤世嫉俗來自於企業架構計畫的常見生命週期。通常，它們會在 IT 團隊發起一項重大計畫時，以極大的榮耀和關注開始，這項計畫將帶來綜效、重複使用，以及透過打破應用程式孤島（和其他合適的類比）的煙囪效應而產生的所有其他好處。兩三年後，進展不大，企業架構團隊也收不到回電。再過一兩年，這項計畫就悄悄地消失了，但很快地，另一個計畫又開始了，而繁榮與蕭條的循環又再次開始。

那麼，為什麼這個循環會如此規律地發生？我想，參與這些計畫的大多數人會說，它們失敗的原因主要是政治因素——但他們經常忽略的是，這些政治力量是不可避免的。要在這些事情上取得成功，首先必須認識到這些政治力量的強大。

中央架構團隊的問題在於，它們是由 IT 管理部門推動的，但它們希望組織的應用程式是由業務需求推動的。如果一個應用程式團隊被告知要做一些對他們的應用程式沒有直接好處，但可以讓它更容易符合架構，他們自然會不願意去做。此外，他們還有王牌——業務贊助商。如果業務贊助商被告知，為了符合企業架構計畫，應用程式將延遲四個月才能出貨，那麼當應用程式團隊說不（拼寫為「我們稍後會處理」）時，他們就會有動力支持應用程式團隊。由於應用程式與提供業務價值直接相關，而中央架構團隊則不然，因此應用程式團隊獲勝。這些勝利導致企業架構計畫失敗。

為了避免這種情況，企業架構倡議必須承認並服從政治現實。

• 了解任何企業架構倡議的商業價值。
• 確保任何工作都受到商業價值的短期增長支持。
• 將應用程式的成本降至最低

思考此問題的一個好方法是，這些倡議不應過於著重於為應用程式建構一個總體計畫，而應更著重於提出整合應用程式的技術，無論它們如何組合在一起。（畢竟，應用程式邊界主要是社會建構，而且不太可能符合任何人的前瞻性計畫。）此整合架構應對應用程式團隊造成最小的影響，以便團隊能夠在商業價值合理的情況下提供小部分的功能。我認為您還需要專注於將應用程式之間的耦合降至最低的方法，即使這些方法的效率不如耦合度較高的方法。

這些原因往往使我傾向於採用訊息傳遞方法進行整合。雖然它有其缺點，但它可以對現有應用程式造成最小的影響。

順帶一提，企業應用程式架構可能會對企業整合產生重大影響。分層良好的應用程式，特別是具有良好的表示層與網域分離的應用程式，更容易串接在一起，因為您可以更輕鬆地透過服務公開應用程式功能。這不會對應用程式造成成本，因為良好的分層架構也能使應用程式更容易維護。然而，了解如何執行表示層與網域分離的應用程式開發人員太少了。整合小組可以執行的最佳工作之一就是提供教育和訓練，以協助他們執行此工作（如果他們採取Architectus Oryzus 而不是 Architectus Reloadus 的做法，這種方法最能獲得支持）。因此，從這個意義上來說，我的書與企業架構有很大的關係。