曾幾何時，企業架構師要為了得到承認和支持而抗爭，但這種時候正在過去。大多數企業現在已經意識到實現業務流程中敏捷性和效率需要業務目標、人力資源以及信息技術的結合。

EA的角色已經拓展，從關注于將業務流程映射為抽象轉到映射為工作、工作流以及工作者的生產力。重要的一步是將軟件架構設計引入EA里面，為了做到這一點，需要意識到軟件架構演進的關鍵要素是工作流概念的轉移，然后在EA規劃當中進入事件驅動的概念，再按照領域將事件映射為IT服務，并將IT服務映射為軟件架構、實踐以及產品。

在典型的EA方法論中，架構師聚焦業務流程為建模的最后時刻。這種辦法跟面向服務架構、服務總線以及工作流處理可以很好地對應，后者直到最近都還是軟件架構設計的中流砥柱。但互聯網和云計算的引入侵蝕了IT對“工作流”愿景的支持。今天，優選的方案是把軟件考慮成一組臨時搭配的微服務組合，這樣可以服務于每一個員工的產品需求。在這種軟件模型下，軟件激活的驅動力不是線性流，而是事件。

盡管“業務流程”就是“業務流程流”的概念與事件結構或者說微服務架構存在脫節似乎十分明顯，但卻沒有充分反映到大多數的企業架構方法論上面。EA的業務流程輸出往往是前置到業務流程流里面，在把EA需求轉化為IT需求時往往傾向于工作流思維。事后再把對基于云和微服務的現代軟件架構演進和設計方案的理解放到今天的EA方法論里面不是不可能，但很難以一種一致且有組織的方式來做到。要做到這一點，開發者需要拒絕把業務流程視為EA的最后一環的觀念，相反要聚焦到業務事件上面。

在邏輯上企業已經是事務驅動的了，這意味著它們要對外部事情，如下訂單來做出響應，然后產生其他東西來驅動合作伙伴活動，如下達發貨通知等。這些都是業務事件，也是一切業務活動的常見驅動，從這些來看，它們是EA的一個合理的關注點。但是今天的EA更多的是描述流程而不是事件，而這種流程描述會把EA跟可能已經過時的軟件架構設計綁定到一起。

業務事件是企業的驅動力或者是一個企業對另一個企業的輸出，對它的描述要依據它在業務上代表著什么而不是用它來做什么來定義。它是事件樹的起點而不是轉發流。每一個事件或者事務都會催生出一系列必要的內部事件和事務。比方說訂單可能會纏身“存貨檢查”事件和“信用檢查”事件。這些都可以表示為初始事件的分支，跟往往描述事情順序的傳統EA流不一樣的是，事件樹僅聚焦于關鍵關系上。

可視化為事件樹“森林”的業務能夠為軟件架構設計提供有用的洞察。比方說，許多主要事件都會自然而然地滋生出一批相關的二級事件—信用檢查、客戶訂單管理甚至CRM這些都是相關的二級事件。這些關聯事件在業務功能的層面上組成了領域，反過來也會成為固化的企業架構與軟件架構的連接點。事件驅動EA把架構從對工作流的依賴中解放了出來，而領域則在獨立事件分析和軟件方案之間建立了連接。

大多數領域相關的EA討論聚焦在不同類型的領域上—比方說，安全、信息、IT基礎設施以及網絡等，許多組織在IT側也都有這些領域的體現。這意味著把EA跟軟件架構綁定是功能性和架構性IT域的聯合。功能性領域專家應該放到EA組織內，從屬于總體EA，而架構性領域專家則應該是IT組織本身的一部分。

功能性領域需求之匯總應該形成對軟件架構設計的泛化模型的要求，然后提供給結構性領域專家選擇。大多數情況下都會選出一個泛化的架構給軟件，其中包括一些調優以及每一個功能領域的功能相關的映射。這意味著軟件架構設計可以形象地看作是“兩種類型的領域”的集體回憶來商定總體框架，然后再由每一位功能領域專家和結構領域專家開會確定設計。在經過最后的團隊評審之后，領域映射的最后一步就是轉化為軟件設計和技術選擇。

這一方案可以用各種辦法實現當前IT模型的演進。方法之一是讓領域專家檢查傳統IT方案與新策略的差異來對過程提供指導。由于你原來的EA各種可能是以業務流程為終結的，所以那些流程可以被視為功能性領域，而架構性領域專家然后就可以根據每一個功能性領域的新方案來調整步驟。這種做法適合于較早建立的事件樹在EA模型舊的業務流程終結點之間存在最少的交叉時使用。

如果新的EA模型會將IT變革為一組廣泛分布的服務時，最好的辦法是看看每一個舊的業務流程，從中找出哪個映射到新的事件樹最容易。也就是說要找到包含一組事件單集的流程。這些流程可以轉化為事件驅動模型，所得結果將會用來做出可用于選擇后續EA業務流程目標的服務的詳細清單。

這種軟件架構演進最關鍵的一點是不要掉進過去的陷阱里面。EA軟件架構設計的影響極其重大，因為它改變了員工可以利用的工具。事件和服務驅動方案的靈活性依賴于對當前的IT流程解耦，而不是不經意間延續下去。