領先的 CIO 正在構建“剛剛好”的企業架構，以平衡速度與長期戰略洞察力，以實現更好的業務價值。
在 Vault Health，首席技術官 Steve Shi 開始企業架構 （EA） 工作，他對整個 IT、應用程式、系統和資料基礎架構進行了現場調查，但將其限制在兩週內，並針對每個功能進行一小時的採訪。
Shi 說，客戶，無論是員工還是為產品或服務付費的人，都必須“喜歡”這種最低可行的 EA 方法的結果。“如果你沒有得到客戶的認可，你就會失去動力，如果你失去動力，在最小可行的釋出之後繼續迭代就更難了，”他說。
像許多 IT 領導者一樣，施正試圖在未使用的複雜架構研究和缺乏足夠範圍和深度以提供持久價值的簡陋 EA 報告之間取得平衡。找到這種平衡需要緊貼業務需求，削減繁重的工作，適當地確定專案範圍，並設定和執行正確的架構標準和原則。以下是熟悉該流程的 CIO 推薦的五個步驟。
貼近業務
與業務利益相關者保持密切溝通是瞭解最小可行企業架構在哪裡可以最好地幫助業務並隨著業務需求的變化為持續的 EA 評估提供資金的唯一途徑。
在 Carrier Global Corp。，CIO Joe Schulz 透過業務指標來衡量 EA 的成功，例如員工生產力如何受到應用程式質量或服務中斷的影響。
Schulz 說：“我們不會將企業架構視為一群看門人，他們在本質上對某件事情應該如何工作有更多的理論性。”他使用 EA 工具 LeanIX 生成的報告和見解來描述生態系統的互連性以及整個產品組合的系統功能，以識別冗餘或差距。這使得智慧建築和冷鏈解決方案的全球供應商能夠“使許多決策民主化……（以）在我們的組織中發揮所有最佳思維和投資能力。”
破產技術和服務公司 Stretto 的首席技術官 George Tsounis 建議使用 EA 來“建立信任和透明度”，方法是告知業務領導者當前的 IT 支出以及平臺與業務戰略不一致的領域。他說，這使得未來與 EA 相關的對話“比企業架構師在孤島中工作並且沒有這種關係要容易得多”。
修剪繁文縟節
冗長的問卷調查和模板驅動的訪談是 EA 工作中常見但通常不受歡迎的一部分。最低可行的 EA 從業者建議消除任何不能提供基本資訊並允許使用者反饋的問題。
雲超大規模企業 Amazon Web Services 的企業戰略總監 Gregor Hohpe 建議從“重量級、主要是單向”的 EA 流程轉變為與業務使用者進行更簡單、更快和迭代的對話。
在金融服務公司 State Street，全球首席架構師 Aman Thind 試圖透過只提出精確且相關的問題而不是 EA 模板中的所有問題來簡化 EA 流程。他說，專注於最重要的問題可以將架構審查和提交所需的時間減少至少一半，並使流程更加有效。例如，SaaS 應用程式用來提供使用者介面的框架不如確定使用者如何與其互動的身份和訪問管理程式重要。
除了使用自動合規檢查和自助服務平臺外，Hohpe 還建議消除“大量被忽略的標準列表”，召開審查會議，所有檔案都根據各自團隊的首選結果進行逆向工程，“調整”會議增值主題，以及“從從未用於決策的重量級 EA 工具生成巨大的掛毯”。
在數字醫療保健公司 Vault，Shi 發現應用程式可觀察性工具 New Relic 透過提供對整個架構的即時可見性，在加速 EA 工作方面很有價值。
他還使用新的術語和流程來避免常見的減速，並讓人們意識到他的新穎方法。一個例子是“網站報告”，它要求使用者設想最終的 EA 產品。這有助於定義關鍵要求，例如應用程式必須支援的事務數量和流程型別，“來自客戶端並向後工作”。Shi 沒有使用要求使用者預先就關鍵技術決策達成一致的“一次性完成”流程，而是要求他們確認或修改“開發假設”，例如系統每天必須支援的資料庫呼叫數量。他說，這種方法可以加快就資料庫等元件的選擇達成一致。
在應用程式推出期間，Shi 避免使用通用專案計劃，而是採用他所謂的“特定宏排序計劃”，即圍繞里程碑（如 alpha 和 beta 測試及其相關的驗證里程碑）構建的步驟。這為部署的每個階段定義了業務方面的成功，例如收入或使用者採用率以及從降低持續支援成本的支援流程中吸取的經驗教訓。他說，這也提醒每個人，“在我們知道架構已經交付了可衡量的客戶價值之前，專案不會結束。”
範圍正確
在一個最小可行的 EA 專案中承擔太多，在完成之前它就會過時，交付結果太晚，無法滿足並從商業領袖那裡獲得未來的資金。將其縮小太多，將無法提供充分利用 IT 投資所需的技術和業務的全面檢視。達到適當的平衡通常需要專注於業務中的一個應用程式或痛點，或者由於新的業務或監管需求而導致需求快速變化的領域。
Gartner Inc。 副首席分析師 Nolan Hart 將適當的 EA 範圍稱為“最少數量的可交付成果，例如觀點、參考模型和設計模式，有助於確保及時、合規地交付產品和解決方案。”他建議，與其花太多時間瞭解當前架構，不如“首先了解你想要的結果”。他說，“永遠、永遠、永遠地迷失記錄你當前功能失調的架構”是沒有價值的。
Shi 建議最小可行的 EA 考慮“從使用者介面到將系統連結到資料架構的 API 的所有內容，而不是單個孤立的元件或服務。”他說，提議的架構還必須能夠在生產規模上進行測試，並且能夠處理與它所取代的系統相同的峰值需求。
適當的範圍也適用於 EA 組織。Carrier 不是專門的 EA 團隊，而是為 CRM、現場服務、ERP、分析和數字工廠功能等關鍵需求建立了卓越中心。Schulz 說，這些中心提供了核心元件的簡化基礎，使其能夠快速創新，而無需進行 EA 練習來評估每個業務部門的單獨平臺。
如果企業中的一個小組對最小可行的 EA 專案不感興趣，“還有很多其他人會花時間，”Hart 說。將該需求與 EA 團隊的技能相匹配，以確定“您可以提供的三到五種服務，以用最小可行的方法交付這些業務成果”。
制定和執行標準
Tsounis 說，實施設計原則以及關注業務需求有助於縮短“關於哪種解決方案最佳的哲學爭論”。他鼓勵的原則包括“始終嘗試建立儘可能簡單的解決方案，不要過度設計，允許在整個組織中最大限度地重用，在構建新東西之前利用已建立的架構設計模式以及基於雲的服務。”
Thind 說，網路安全、資料治理、生產管理和部署最佳實踐等領域的參考架構和標準提供了“現成的劇本”，可以有效地構建健壯、合規和彈性的可組合應用程式。此類架構由“定義非常明確……在 API、可擴充套件性和互操作方式方面”的微服務構建，允許企業在不影響任何其他微服務的情況下替換任何微服務，從而建立面向未來的設計。
Hohpe 說，一些標準扼殺了創新，而另一些則促進了創新。例如，統一介面對於建立易於適應的架構至關重要。然而，過於嚴格的標準會導致糟糕的技術選擇。他記得有一個應用程式團隊選擇 XML 作為元件介面而不是更快的通訊協議。當被問及原因時，該團隊回答說架構團隊需要它，顯然沒有考慮 XML 解析對應用程式效能的不利影響。
從某個地方開始
如果不出意外，Thind 說，任命一名“……首席架構師，一名高管評估整體標準、整體治理、整體平臺和應用程式設計的整體紀律。僅僅擔任這個職位就表明了架構對整個公司的重要性，並灌輸了我們建立高效和創新 IT 組織所需的正確行為。”
開始一個最小可行的企業架構可以從簡單地“盤點”開始，Thind 說，識別超支，例如“為什麼我們有六個不同的應用程式用於相同的流程，五個不同的合同（用於）相同的 BI 工具，多個市場資料合同範圍相同，24×7 Hadoop 叢集用於月度報告，等等。”但即使是這種最低限度的可行努力也能帶來巨大的好處。“只要確保將正確的工具用於正確的工作，並且圍繞它們的使用進行標準化和最佳實踐，就可以對底線產生相當大的影響，並減少技術債務，減少支援需求，並允許更快的創新，”他說。