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

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

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

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

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

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

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

大多數(shù)領(lǐng)域相關(guān)的EA討論聚焦在不同類(lèi)型的領(lǐng)域上—比方說(shuō)，安全、信息、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)該形成對(duì)軟件架構(gòu)設(shè)計(jì)的泛化模型的要求，然后提供給結(jié)構(gòu)性領(lǐng)域?qū)＜疫x擇。大多數(shù)情況下都會(huì)選出一個(gè)泛化的架構(gòu)給軟件，其中包括一些調(diào)優(yōu)以及每一個(gè)功能領(lǐng)域的功能相關(guān)的映射。這意味著軟件架構(gòu)設(shè)計(jì)可以形象地看作是“兩種類(lèi)型的領(lǐng)域”的集體回憶來(lái)商定總體框架，然后再由每一位功能領(lǐng)域?qū)＜液徒Y(jié)構(gòu)領(lǐng)域?qū)＜议_(kāi)會(huì)確定設(shè)計(jì)。在經(jīng)過(guò)最后的團(tuán)隊(duì)評(píng)審之后，領(lǐng)域映射的最后一步就是轉(zhuǎn)化為軟件設(shè)計(jì)和技術(shù)選擇。

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

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

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