曾幾何時，企業(yè)架構(gòu)師要為了得到承認和支持而抗爭，但這種時候正在過去。大多數(shù)企業(yè)現(xiàn)在已經(jīng)意識到實現(xiàn)業(yè)務(wù)流程中敏捷性和效率需要業(yè)務(wù)目標、人力資源以及信息技術(shù)的結(jié)合。

EA的角色已經(jīng)拓展，從關(guān)注于將業(yè)務(wù)流程映射為抽象轉(zhuǎn)到映射為工作、工作流以及工作者的生產(chǎn)力。重要的一步是將軟件架構(gòu)設(shè)計引入EA里面，為了做到這一點，需要意識到軟件架構(gòu)演進的關(guān)鍵要素是工作流概念的轉(zhuǎn)移，然后在EA規(guī)劃當中進入事件驅(qū)動的概念，再按照領(lǐng)域?qū)⑹录成錇镮T服務(wù)，并將IT服務(wù)映射為軟件架構(gòu)、實踐以及產(chǎn)品。

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

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

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

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

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

大多數(shù)領(lǐng)域相關(guān)的EA討論聚焦在不同類型的領(lǐng)域上—比方說，安全、信息、IT基礎(chǔ)設(shè)施以及網(wǎng)絡(luò)等，許多組織在IT側(cè)也都有這些領(lǐng)域的體現(xiàn)。這意味著把EA跟軟件架構(gòu)綁定是功能性和架構(gòu)性IT域的聯(lián)合。功能性領(lǐng)域?qū)＜覒?yīng)該放到EA組織內(nèi)，從屬于總體EA，而架構(gòu)性領(lǐng)域?qū)＜覄t應(yīng)該是IT組織本身的一部分。

功能性領(lǐng)域需求之匯總應(yīng)該形成對軟件架構(gòu)設(shè)計的泛化模型的要求，然后提供給結(jié)構(gòu)性領(lǐng)域?qū)＜疫x擇。大多數(shù)情況下都會選出一個泛化的架構(gòu)給軟件，其中包括一些調(diào)優(yōu)以及每一個功能領(lǐng)域的功能相關(guān)的映射。這意味著軟件架構(gòu)設(shè)計可以形象地看作是“兩種類型的領(lǐng)域”的集體回憶來商定總體框架，然后再由每一位功能領(lǐng)域?qū)＜液徒Y(jié)構(gòu)領(lǐng)域?qū)＜议_會確定設(shè)計。在經(jīng)過最后的團隊評審之后，領(lǐng)域映射的最后一步就是轉(zhuǎn)化為軟件設(shè)計和技術(shù)選擇。

這一方案可以用各種辦法實現(xiàn)當前IT模型的演進。方法之一是讓領(lǐng)域?qū)＜覚z查傳統(tǒng)IT方案與新策略的差異來對過程提供指導(dǎo)。由于你原來的EA各種可能是以業(yè)務(wù)流程為終結(jié)的，所以那些流程可以被視為功能性領(lǐng)域，而架構(gòu)性領(lǐng)域?qū)＜胰缓缶涂梢愿鶕?jù)每一個功能性領(lǐng)域的新方案來調(diào)整步驟。這種做法適合于較早建立的事件樹在EA模型舊的業(yè)務(wù)流程終結(jié)點之間存在最少的交叉時使用。

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

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