1??前言

長期以來銀行在追求業(yè)務(wù)敏捷性的轉(zhuǎn)型過程中會在維護(hù)現(xiàn)有系統(tǒng)的同時不斷接收到各?種沖擊，?除了市場與競爭對手的沖擊，還包括各種轉(zhuǎn)型技術(shù)、方法和方向的沖擊。突?進(jìn)式轉(zhuǎn)型還是漸進(jìn)式轉(zhuǎn)型，科技如何和業(yè)務(wù)協(xié)作進(jìn)行轉(zhuǎn)型， 銀行內(nèi)外如何布局和循序?漸進(jìn)提升，這些都是需要結(jié)合行業(yè)和企業(yè)實(shí)際情況切實(shí)思考的問題。與互聯(lián)網(wǎng)企業(yè)不?同，銀行長期以來積累了大量已有系統(tǒng)， 而且“豎井”林立，數(shù)據(jù)不一致，功能與數(shù)?據(jù)冗余， 應(yīng)用邊界不清等問題長期存在， 而且所有這些都通過大量的“點(diǎn)對點(diǎn)”接口?進(jìn)行連接。這一切都給如何改善現(xiàn)有資源的重用性，提升業(yè)務(wù)敏捷性帶來了困難。

近些年來，隨著一些驅(qū)動力的變化，銀行業(yè)已經(jīng)啟動了新一輪數(shù)字化轉(zhuǎn)型過程。這些?驅(qū)動力包括：

.?業(yè)務(wù)設(shè)計技術(shù)方面的進(jìn)步，企業(yè)架構(gòu)從偏重技術(shù)逐漸走向業(yè)務(wù)為要，業(yè)務(wù)架構(gòu)?及業(yè)務(wù)模型越來越受到企業(yè)的重視。

.?技術(shù)平臺的進(jìn)步，以云為代表的技術(shù)平臺逐漸成熟，帶動了?ABCDEI(人工智能?AI, 區(qū)塊鏈?Blockchain, 云?Cloud, 大數(shù)據(jù)?Data, 邊緣計算?Edge?Computing,?物聯(lián)網(wǎng)?IoT)及?5G 的全面技術(shù)進(jìn)步。

.?業(yè)務(wù)管理意識的提升，?IT?與業(yè)務(wù)的不斷融合，?IT?也是業(yè)務(wù)。IT 自身也開始思?考結(jié)合開發(fā)運(yùn)營一體化?DevOps?來逐步貫通。

.?銀行在向?Bank 4.0?演進(jìn)，在?API?經(jīng)濟(jì)互聯(lián)互通下展開生態(tài)業(yè)務(wù)。 銀行和多個 行業(yè)縱橫交錯形成了“涌現(xiàn)”創(chuàng)新局面。 不少銀行已經(jīng)展開了開放銀行之旅。

銀行業(yè)架構(gòu)網(wǎng)絡(luò)（BIAN）正是在這一背景下應(yīng)運(yùn)而生的。 BIAN?是一個業(yè)界多方協(xié)作的?非營利性組織(bian.org)，由全球領(lǐng)先銀行，技術(shù)提供商， 顧問和學(xué)者組成。這個專??業(yè)人員網(wǎng)絡(luò)共同致力于降低銀行業(yè)務(wù)成本，并加快行業(yè)創(chuàng)新速度。?成員結(jié)合他們的行?業(yè)專業(yè)知識，定義了一個用以簡化和標(biāo)準(zhǔn)化核心銀行體系結(jié)構(gòu)的銀行技術(shù)框架。?同時?這一框架基于面向服務(wù)的架構(gòu)(SOA)原則， 所形成的整合模型為銀行提供了面向未來的?解決方案，以促進(jìn)?API?經(jīng)濟(jì)下的行業(yè)協(xié)作。

借助?BIAN?參考模型，銀行可以建立起業(yè)務(wù)能力“積木塊”，通過與現(xiàn)有系統(tǒng)進(jìn)行映射?和對接， 理清應(yīng)用之間的邊界。依托業(yè)界標(biāo)準(zhǔn)(如?ISO20022、FIBO?等)統(tǒng)一信息定義和?數(shù)據(jù)標(biāo)準(zhǔn)。參?BIAN?服務(wù)操作規(guī)范?API?的消息交互，從而達(dá)成面向服務(wù)的、松耦合的?未來銀行架構(gòu)。以此達(dá)成業(yè)務(wù)敏捷性的終極目標(biāo)。這也是目前國內(nèi)銀行紛紛建設(shè)業(yè)務(wù)??中臺、服務(wù)中臺的目的。

從架構(gòu)及技術(shù)角度看， BIAN?融匯了業(yè)界關(guān)于銀行業(yè)務(wù)模型(如?IBM IFW)和技術(shù)體系(如?API?和云)的積累、結(jié)合?SOA?架構(gòu)和微服務(wù)架構(gòu)理念，基于業(yè)務(wù)能力、組件及服務(wù)而形?成的銀行應(yīng)用之間互聯(lián)互通的技術(shù)標(biāo)準(zhǔn)。在過去近五年時間?BIAN?差不多以每年一個版本的速度在進(jìn)行演進(jìn)， 截至到?2020?年初最新版本為?v8.0

(https://bian.org/deliverables/bian-standards/bian-service-landscape-8-0/)，BIAN ??v9.0?計劃?2020?年?Q3?發(fā)布。國內(nèi)一些銀行也開始加入?BIAN?并結(jié)合?BIAN?來打造更為服?務(wù)化和生態(tài)化的銀行系統(tǒng)。

2??BIAN?理論基礎(chǔ)?????????????????????????????????????????????????????????

BIAN?是企業(yè)架構(gòu)思想在銀行的延伸，?BIAN?一直致力于開發(fā)出一種用于企業(yè)架構(gòu)設(shè)計，?業(yè)務(wù)能力(Business Capabilities)和相關(guān)服務(wù)操作(Service Operations)的方法。通?過選擇并組裝這些不同層面的“積木塊”來對銀行（或金融機(jī)構(gòu)） 進(jìn)行建模。由于BIAN?的設(shè)計是“規(guī)范的?”，這意味著面向任何金融組織的不同實(shí)施情況，它們可以以?一致方式進(jìn)行詮釋?？紤]到規(guī)范性設(shè)計定義以及松耦合架構(gòu)，BIAN?方法采用了面向服?務(wù)的架構(gòu)(SOA)方法。

2.1???BIAN?基于?SOA?體系架構(gòu)的優(yōu)點(diǎn)

盛行于本世紀(jì)初的?SOA?面向服務(wù)架構(gòu)體系在系統(tǒng)設(shè)計和實(shí)現(xiàn)方面的優(yōu)點(diǎn)已經(jīng)有很多文 ?檔進(jìn)行了充分論述。但是，隨著領(lǐng)域驅(qū)動設(shè)計(DDD-Domain Driven Design)，微服務(wù) ?架構(gòu)(Microservice Architecture)的不斷流行， 很多用戶將?SOA?逐漸打入“遺留”系?統(tǒng)或方法之列。更有甚者，認(rèn)為?SOA?就是單體(monolithic)架構(gòu)的代名詞。實(shí)際上?SOA?用“服務(wù)”一致性貫穿業(yè)務(wù)和技術(shù)的思路仍然是適用的，只是技術(shù)上的局限性， SOA?在?早期階段把更多重點(diǎn)放到了應(yīng)用整合服務(wù)整合以及流程整合方面。隨著技術(shù)的不斷進(jìn) ?步特別是隨著微服務(wù)、云原生技術(shù)以及?PaaS?平臺云的不斷成熟，?我們需要對?SOA?理論?體系?“溫故而知新”。結(jié)合目前這些前言技術(shù)更好地將“服務(wù)”理念向業(yè)務(wù)延伸， 真?正落實(shí)?SOA?的核心理念。筆者將一些關(guān)系較為密切的方法體系進(jìn)行了比較，供大家快 ?速參考。關(guān)于方法體系會在方法專題專門展開討論。

面向服務(wù)架構(gòu)?SOA?則通過“服務(wù)?”概念貫穿業(yè)務(wù)與 IT，打通了長期以來相對??隔離的三大領(lǐng)域：業(yè)務(wù)流程改進(jìn)、應(yīng)用設(shè)計與開發(fā)以及軟件的運(yùn)維。通過軟件?架構(gòu)及策略來支持業(yè)務(wù)的面向服務(wù)特征， 通過服務(wù)統(tǒng)一企業(yè)內(nèi)的業(yè)務(wù)能力，對?接現(xiàn)有?IT?系統(tǒng)的服務(wù)能力。?SOA?橫貫業(yè)務(wù)、 IT?及運(yùn)維，必須以業(yè)務(wù)模型為中??心來一致性執(zhí)行，否則會偏離業(yè)務(wù)本質(zhì)， 影響企業(yè)級實(shí)施效果。本質(zhì)上?SOA?更?多強(qiáng)調(diào)自頂向下的思路，也會結(jié)合自底向上這一方向。另外?SOA?繼承了面向?qū)?/span>象?(OO-Object Oriented) 及組件設(shè)計的很多理論體系，這些均體現(xiàn)在?SOA?設(shè)?計模式中。SOA?承接了業(yè)務(wù)架構(gòu)和業(yè)務(wù)模型，并滲透到應(yīng)用、技術(shù)以及運(yùn)維架?構(gòu)層面。

.?領(lǐng)域驅(qū)動設(shè)計(DDD-Domain Driven Design) 在貫徹企業(yè)架構(gòu)(業(yè)務(wù)架構(gòu))建立??通用語言的前提下，針對特定業(yè)務(wù)領(lǐng)域自始至終貫徹領(lǐng)域(業(yè)務(wù))驅(qū)動理念。將?業(yè)務(wù)模型(實(shí)體模型)與設(shè)計模式以及代碼有機(jī)緊密銜接在一起，更多采取了自?底向上的思路。在向整個企業(yè)級推廣時如果有企業(yè)業(yè)務(wù)架構(gòu)及業(yè)務(wù)模型的有力?支持，會產(chǎn)生更好的推廣效果。DDD?是?SOA?思想在某個業(yè)務(wù)領(lǐng)域的細(xì)化和延伸，適合應(yīng)用項(xiàng)目級來切入。

.?微服務(wù)架構(gòu)則是在數(shù)字化轉(zhuǎn)型下催生的新型分布式架構(gòu)，強(qiáng)調(diào)服務(wù)的職責(zé)單一、自治性和獨(dú)立演進(jìn)，業(yè)務(wù)上承接了?SOA?服務(wù)理念，但在技術(shù)上與分布式技?術(shù)、云、容器等緊密結(jié)合。因此微服務(wù)需要從?XYZ?三個維度全方位考慮， 即微?服務(wù)本身自治性的業(yè)務(wù)服務(wù)屬性、橫向擴(kuò)展屬性、數(shù)據(jù)分片屬性。 如果片面從技術(shù)角度看待微服務(wù)的技術(shù)特性， 會使微服務(wù)的效果大打折扣，例如微服務(wù)的?業(yè)務(wù)切分合理性。

因此有必要重新回顧?SOA?方法體系的要點(diǎn)，指導(dǎo)?IT?解決方案乃至“中臺”體系的設(shè)?計：

.?服務(wù)。通過服務(wù)貫穿業(yè)務(wù)和?IT?系統(tǒng)架構(gòu)， 通過對功能的封裝和暴露提升信息?流動性，以及更好的組織靈活性。

.?服務(wù)重用和共享?；诜?wù)的軟件設(shè)計和架構(gòu)可以有效減少開發(fā)和管理(運(yùn)維)?成本。

.?消息。基于消息的通信機(jī)制可以帶來廣泛的積極效應(yīng)，包括配置靈活性， 更易?于監(jiān)控和獲取洞察，更好的控制和安全性等。

.?復(fù)雜性。服務(wù)可以簡化軟件的復(fù)雜度，使得復(fù)雜性高的軟件更具適應(yīng)性， 也更?容易進(jìn)行方案整合。

自然， SOA?更為重要的理念在于貫穿業(yè)務(wù)和?IT。下圖示出了?BIAN?的基于?SOA?的業(yè)務(wù)設(shè)?計原則和技術(shù)?。

BIAN?的整個理論體系是基于?SOA?的，將“服務(wù)”向業(yè)務(wù)架構(gòu)層面進(jìn)行了延伸。通過對?銀行運(yùn)營服務(wù)能力的組件式切分和能力組件之間交互的定義，刻畫了銀行業(yè)務(wù)運(yùn)營實(shí)?踐。

.?BIAN?的服務(wù)能力組件是松耦合且獨(dú)立的 - BIAN?最核心的一個概念是服務(wù)域 ?(Service Domain)?。 服務(wù)域是業(yè)務(wù)能力的劃分單元，同時也是業(yè)務(wù)服務(wù)的封?裝單元。服務(wù)域之間相互獨(dú)立、松散且唯一，互不重疊，因此通過服務(wù)域中的?業(yè)務(wù)服務(wù)之間的協(xié)作可以進(jìn)行真實(shí)業(yè)務(wù)場景建模。

.?BIAN 服務(wù)域是完整全面的 - BIAN 立足于定義一個完整的銀行服務(wù)組件集?合，所有可能的業(yè)務(wù)活動都可以通過服務(wù)域之間的協(xié)作來完成。

.?BIAN 服務(wù)域是基本的(原子性的) - 服務(wù)域僅支持單一的業(yè)務(wù)目的。服務(wù)域是?業(yè)務(wù)服務(wù)的最小封裝單位，不包含更小更細(xì)的服務(wù)域，多個識別出的服務(wù)域可?能構(gòu)成服務(wù)域協(xié)作集群。

.?BIAN 服務(wù)域封裝了業(yè)務(wù)行為和業(yè)務(wù)對象 - 服務(wù)域是銀行系統(tǒng)“動態(tài)”行為模?式與“靜態(tài)”業(yè)務(wù)對象的一個結(jié)合體，進(jìn)一步對這些動態(tài)行為和靜態(tài)對象進(jìn)行?了標(biāo)準(zhǔn)化語義層面定義，從而可以準(zhǔn)確一致地對銀行業(yè)務(wù)進(jìn)行描述。

基于上面的業(yè)務(wù)運(yùn)營設(shè)計理念，BIAN?SOA?在進(jìn)行應(yīng)用調(diào)整時提供了更多可能性:

.?運(yùn)營能力重用?– 每個服務(wù)域構(gòu)成的獨(dú)立且唯一的運(yùn)營能力可以在企業(yè)范圍內(nèi)?進(jìn)行廣泛使用， 這提升了運(yùn)營能力的重用，將精力放到更需要資源的專業(yè)領(lǐng)域，改進(jìn)資源利用率和水平。

.?運(yùn)營靈活度提升?– 隨著更多業(yè)務(wù)功能通過共享服務(wù)方式對外可用，業(yè)務(wù)需求?和業(yè)務(wù)模式的變化可以通過服務(wù)的調(diào)整或重用來更容易地得到支持。在適當(dāng)?shù)?/span>?情況下， 可以通過生態(tài)協(xié)作由外部合作方也可以及時提供這些能力。

.?減少信息碎片化和不一致性?– 服務(wù)域作為一種?SOA 能力組件成為其所管控的?業(yè)務(wù)信息的單一來源。由于服務(wù)域?qū)ζ渥陨硭芸氐?/span>信息進(jìn)行了封裝，維護(hù)了?一個自治疆域。這一特性可以減少數(shù)據(jù)不一致性和碎片化。

.?性能優(yōu)化?– 每個服務(wù)域都肩負(fù)或?qū)崿F(xiàn)了一個明確定義的業(yè)務(wù)目的，其內(nèi)部能?力可以針對某個具體操作進(jìn)行優(yōu)化。

.?對分布式系統(tǒng)方案的支撐?– 基于圍繞服務(wù)域的設(shè)計框架，BIAN?可以將業(yè)務(wù)和?技術(shù)實(shí)現(xiàn)串接起來。因?yàn)榉?wù)域所定義的業(yè)務(wù)能力劃分是獨(dú)立且唯一的， 實(shí)現(xiàn)?了與其所封裝的業(yè)務(wù)角色相關(guān)的業(yè)務(wù)實(shí)體的全生命周期管理。基于這一自治理?念，?這些能力組件可以和分布式環(huán)境(如云和微服務(wù))很好配合在一起。

.?漸進(jìn)式演進(jìn) - 通過?BIAN?服務(wù)域可以建立全局統(tǒng)一的服務(wù)目錄，這樣可以將現(xiàn)?有銀行技術(shù)體系(如主機(jī)系統(tǒng)和企業(yè)服務(wù)總線?ESB)和新型的云及微服務(wù)體系從?整體上進(jìn)行映射。這樣便于企業(yè)從全局從業(yè)務(wù)高度進(jìn)行應(yīng)用布局和技術(shù)架構(gòu)演?進(jìn)和治理。

2.2???面向流程與面向組件的方法

談及?SOA?體系架構(gòu)的優(yōu)點(diǎn)有一點(diǎn)需要延伸說明一下。也就是面向流程與面向組件的方?法差異和各自的適用場景。

可以說處理邏輯與信息是應(yīng)用的兩大支柱，長期以來傳統(tǒng)銀行應(yīng)用更多采取了面向流?程的方法，圍繞流程或交易進(jìn)行相關(guān)業(yè)務(wù)信息的準(zhǔn)備和訪問。這樣做有不少優(yōu)點(diǎn)：

.?業(yè)務(wù)信息圍繞流程邏輯精確定義，相關(guān)信息專注在對流程及交易的支持上。

.?業(yè)務(wù)信息可以加以結(jié)構(gòu)化以確保高效訪問，可以為了性能對信息組織方式進(jìn)行加?工，這在主機(jī)應(yīng)用上很普遍。

.?通用的企業(yè)參考業(yè)務(wù)信息可以在可用的地方輕松整合。

然而，隨著此類應(yīng)用的長期演變，?多種流程和交易會交織在一起。相關(guān)信息結(jié)構(gòu)如果?缺乏數(shù)據(jù)治理也會重重疊疊，越滾越大， 也就是耦合性越來越高。這會造成：

.?跨企業(yè)模型邏輯業(yè)務(wù)信息視圖的碎片化， 從而導(dǎo)致處理及數(shù)據(jù)的不一致性。

.?不能輕易對設(shè)計進(jìn)行改變和增強(qiáng)以適應(yīng)變化。

隨著數(shù)字化轉(zhuǎn)型對應(yīng)用交付時間和頻度的要求不斷提升，上述面向流程這一體系架構(gòu)?的弱點(diǎn)逐步凸顯。而采取面向組件的方法可以較好應(yīng)對這一需求：

.?所有的業(yè)務(wù)信息治理管控功能都唯一地分配到相關(guān)的責(zé)任實(shí)體中，?分而?治之， 各行其責(zé)。

.?信息的業(yè)務(wù)上下文定義良好， 避免錯誤的推斷，即在不同的業(yè)務(wù)環(huán)境中使用的類?似類型的信息必須始終共享相同的信息值。

.?對信息完整的生命周期進(jìn)行管理， 確保執(zhí)行適當(dāng)?shù)膭幼饕跃S護(hù)信息的完整性和?流轉(zhuǎn)。

當(dāng)然， 面向組件甚至當(dāng)下較為流行的微服務(wù)方法也有其弱點(diǎn)：

.?提供對單一受管信息的訪問會帶來延遲或延遲的可能性，以及可能的訪問限制?和約束。為了改善這一點(diǎn)，從技術(shù)架構(gòu)層面會通過多種手段加以改善，如讀寫?分離，但這又會引入數(shù)據(jù)一致性和補(bǔ)償機(jī)制等復(fù)雜問題。

因此，兩種方法有著各自的適合場景，可以在加強(qiáng)治理的前提下結(jié)合使用。

流程信息模型最有可能適用于可以優(yōu)化信息訪問性能的后臺應(yīng)用。應(yīng)用程序之間的鏈?接和邊界比較穩(wěn)定，而且它們所引用的信息集中聚焦，這意味著業(yè)務(wù)信息的本地訪問?和共享通?？梢栽趩误w信息體系結(jié)構(gòu)中實(shí)現(xiàn)。在后臺應(yīng)用開發(fā)中也可以引入組件治理模型，這可能有助于協(xié)調(diào)應(yīng)用程序之間的公共信息關(guān)聯(lián)，以限制遺留應(yīng)用程序中的流?程和信息碎片。

組件信息模型最有可能適合前臺應(yīng)用。?前臺應(yīng)用可能訪問更廣泛的信息來源和服務(wù)。?所管控的信息模型支持在需要時靈活地以任意組合方式進(jìn)行連接和訪問。由于交換的?信息由每個服務(wù)域自主管理，因此可以根據(jù)需要確保其完整性。?組件信息模型所維護(hù)?的清晰的信息上下文、定義和屬性還可以跨業(yè)務(wù)地對所交換的信息值進(jìn)行正確解讀。

BIAN?更多采用了面向組件的方法，并在具體實(shí)施時和現(xiàn)有技術(shù)進(jìn)行了映射。當(dāng)然， 在?實(shí)踐過程中特別是近些年來微服務(wù)實(shí)踐過程中還有很多問題值得深入探討，如服務(wù)的?粒度問題，數(shù)據(jù)一致性問題等。這些從宏觀角度仍然需要兩種方法的結(jié)合來考慮。

2.3?BIAN?體系結(jié)構(gòu)

BIAN?可以與企業(yè)已經(jīng)或行將采用的企業(yè)架構(gòu)體系結(jié)合起來，豐富企業(yè)架構(gòu)的內(nèi)涵和具體可操作性。?BIAN?的整體架構(gòu)如下圖所示?。

可以看到，BIAN的整個服務(wù)全景視圖涵蓋了企業(yè)架構(gòu)的很多內(nèi)容， 形成了一整套架構(gòu)?資產(chǎn)，包括：

.?BIAN 元模型?(Meta Model)，基于ISO 20022元模型;

.?BIAN 業(yè)務(wù)術(shù)語?(Business Vocabulary);

.?BIAN 高階參考地圖: BIAN服務(wù)全景視圖?(BIAN Service Landscape);

.?BIAN 業(yè)務(wù)架構(gòu)?(Business Architecture);

.?BIAN 業(yè)務(wù)能力模型?(Business Capability Model);

.?BIAN 服務(wù)域定義?(Service Domain Definitions);

.?BIAN 服務(wù)操作定義?(Service Operations Definitions);

.?BIAN 業(yè)務(wù)場景定義?(Business Scenario Definitions);

.?BIAN 應(yīng)用程序接口/消息定義?(API/Message Definitions);

.?BIAN 信息架構(gòu)?(Information Architecture);

.?BIAN 業(yè)務(wù)對象模型?(Business Object Model), 完全與?ISO?20022一致

2.4???BIAN?在線資源

BIAN是一個開放模型體系，一個不錯的學(xué)習(xí)方式是直接訪問 bian.org 網(wǎng)站，另外一?個方法是從網(wǎng)站下載相關(guān)文檔來學(xué)習(xí)。下面我們結(jié)合實(shí)際網(wǎng)站 bian.org 瀏覽一下

BIAN的模型體系和文檔體系。

通過bian.org主頁下的 DELIVERABLE 入口進(jìn)入BIAN交付件入口，然后選擇 BIAN STANDARDS 進(jìn)入BIAN的標(biāo)準(zhǔn)。在DIGITAL REPOSITORY 即可進(jìn)入BIAN在線模型庫。

在BIAN STANDARDS 下的“BIAN HOW TO GUIDE”是BIAN 文檔的一個完整集合。其目標(biāo)?讀者主要是技術(shù)架構(gòu)師，BIAN成員及其他金融機(jī)構(gòu)。這些指南文檔對于細(xì)化BIAN全景??視圖背后的理論體系并進(jìn)行設(shè)計實(shí)踐很有幫助。這些文檔包括：

.?“BIAN How-to Guide?–?INTRODUCTION?TO?BIAN?V7.0”是一個整體How-to?文檔指南

.?“BIAN How-to Guide?–?DESIGN?PRINCIPLES?TECHNIQUES?V7.0”介紹了?BIAN的設(shè)計原則及技術(shù)

.?“BIAN How-to Guide?–?DEVELOPING?CONTENT?V7.0”介紹了BIAN標(biāo)準(zhǔn)體系?的開發(fā)

.?“BIAN How-to Guide?–?APPLYING?THE?BIAN?STANDARD?V7.0”簡要描述了?如何運(yùn)用BIAN

.?“BIAN How-to Guide?–?SEMANTIC?API?V7.0”是介紹BIAN API體系的文檔

下面先簡單瀏覽一下BIAN的在線模型庫?InSite??。下圖 的模型體系總圖中包含了三條主線：其中中軸線是BIAN的主線，包括了服務(wù)域及服務(wù)??操作、貫穿服務(wù)域的業(yè)務(wù)場景以及業(yè)務(wù)對象模型BOM。另外兩條線是近期BIAN標(biāo)準(zhǔn)的演?進(jìn)方向， 包括業(yè)務(wù)能力模型以及價值鏈模型。

在下面的概念說明中會結(jié)合這里的模型體系進(jìn)行說明。

3??BIAN?關(guān)鍵概念?????????????????????????????????????????????????????????

除了服務(wù)域(Service Domain)，BIAN?基于業(yè)界標(biāo)準(zhǔn)，如?ISO20022， SWIFT，IFX(Interactive Financial eXchange)，FIBO(Financial Industry Business?Ontology, EDM Council?與?OMG?聯(lián)合提出的金融業(yè)務(wù)本體模型)等引入了一組概念， 這?些概念或多或少與其他方法如企業(yè)架構(gòu)、面向服務(wù)架構(gòu)?SOA?有著映射關(guān)系。企業(yè)在參?照?BIAN?時可以結(jié)合企業(yè)現(xiàn)有的架構(gòu)體系概念進(jìn)行映射。下面我們結(jié)合?BIAN?的在線模?型庫展開分析和說明一下這些概念。

3.1???應(yīng)用對應(yīng)用(APPLICATION?2?APPLICATION)

也稱企業(yè)應(yīng)用整合(EAI-Enterprise Application Integration)。使用軟件及計算機(jī)?系統(tǒng)的架構(gòu)原則來進(jìn)行企業(yè)計算機(jī)應(yīng)用的整合。下圖清晰地說明了BIAN與幾個業(yè)務(wù)標(biāo)?準(zhǔn)以及A2A/B2B的相關(guān)關(guān)系。

另外，上圖很清晰地闡明了BIAN的關(guān)鍵側(cè)重點(diǎn)：

.?側(cè)重應(yīng)用到應(yīng)用?(A2A)，與IFX和SWIFT側(cè)重B2B形成互補(bǔ)。近些年來隨著歐盟?PSD2(支付服務(wù)指令 Payment Service Directive 2)，TPP(Third Party?Provider第三方提供商)以及開放銀行API體系的整體發(fā)展態(tài)勢， BIAN的整體重?心也逐漸從A2A轉(zhuǎn)向A2A/B2B兼顧。

.?重心完全放在語義定義上?– 技術(shù)定義不包括在正式工作產(chǎn)品中， 這樣有助于?平衡其他已經(jīng)開展的行業(yè)工作。

.?BIAN遵循IFX，?以及OMG(Object Management Group)，ISO?20022和SWIFT標(biāo)?準(zhǔn)，與這些標(biāo)準(zhǔn)保持一致和溝通。

.?面向服務(wù)，而IFX， SWIFT，以及?ISO 20022 都是面向消息的。

.?UML(Unified Modeling Language) 是基礎(chǔ)技術(shù)， 在金融服務(wù)業(yè)使用廣泛。

3.2???服務(wù)全景視圖?(SERVICE?LANDSCAPE)

是涵蓋了每個已標(biāo)識服務(wù)域的參考模型， 300多個服務(wù)域以分組形式進(jìn)行組織，幫助從?全局角度來理解、識別和選擇。

3.3???業(yè)務(wù)區(qū)域?(BUSINESS?AREA)

BIAN中的最高階分類， 業(yè)務(wù)區(qū)域?qū)V泛的業(yè)務(wù)能力組合在一起。?就BIAN服務(wù)全景視圖?而言， 業(yè)務(wù)區(qū)域從一個側(cè)面定義了具有相似的應(yīng)用支持和特定信息需求的業(yè)務(wù)活動。

3.4???服務(wù)域?(SERVICE?DOMAIN)

服務(wù)域封裝了服務(wù)操作(Service Operation)或者業(yè)務(wù)服務(wù)，服務(wù)操作則定義了業(yè)務(wù)能?力積木塊之間的交互。服務(wù)域進(jìn)而在組織，過程和支持它們的相關(guān)信息系統(tǒng)方面進(jìn)行??了更為全面的定義。?盡管通常會將注意力集中在IT系統(tǒng)和系統(tǒng)接口上，但是這種關(guān)注??不應(yīng)掩蓋一個事實(shí)，即服務(wù)域代表了一種業(yè)務(wù)能力劃分， 企業(yè)可以將其人員，流程和??系統(tǒng)從業(yè)務(wù)層面一致性地進(jìn)行整合封裝。

3.5???業(yè)務(wù)領(lǐng)域?(BUSINESS?DOMAIN)

是介于業(yè)務(wù)區(qū)域(Business Area)和服務(wù)域(Service Domain)之間的一個層級，業(yè)務(wù)領(lǐng)?域(Business Domain)在更廣泛的業(yè)務(wù)區(qū)域中定義了一系列一致的能力。 在BIAN服務(wù)??全景視圖中，業(yè)務(wù)領(lǐng)域與金融服務(wù)業(yè)務(wù)中可識別的技能和知識相關(guān)。例如在銷售和服??務(wù)(Sales and Service)業(yè)務(wù)區(qū)域下包含了一系列與銷售和服務(wù)相關(guān)能力：具體渠道(Channel Specific)，跨渠道(Cross Channel)，市場營銷(Marketing)，銷售(Sales)，客戶關(guān)系管理(Customer Relationship Management)，服務(wù)(Serving)。下?圖示出了BIAN服務(wù)全景視圖中的層次結(jié)構(gòu)：業(yè)務(wù)區(qū)域、業(yè)務(wù)領(lǐng)域和服務(wù)域。

結(jié)合服務(wù)領(lǐng)域的概念， 可以進(jìn)一步進(jìn)行深入拆分銀行業(yè)務(wù)能力。例如客戶管理?(Customer Management)這一業(yè)務(wù)領(lǐng)域進(jìn)一步包含了12個服務(wù)領(lǐng)域：

.?客戶關(guān)系管理(Customer Relationship Management)

.?客戶產(chǎn)品/服務(wù)資質(zhì)(Customer Product/Service Eligibility)

.?客戶協(xié)議(Customer Agreement)

.?銷售產(chǎn)品協(xié)議(Sales Product Agreement)

.?客戶訪問權(quán)限(Customer Access Entitlement)

.?客戶行為洞察(Customer Behavioral?Insights)

.?客戶信用評級(Customer Credit Rating)

.?賬戶恢復(fù)(Account Recovery)

.?客戶事件歷史(Customer Event History)

.?客戶參照數(shù)據(jù)管理(Customer Reference Data Management)

.?客戶先例(Customer Precedents)

.?客戶主張(Customer Proposition)

上圖用BIAN元模型片段示出上述幾者之間的關(guān)系。業(yè)務(wù)領(lǐng)域可能會有嵌套，例如在業(yè)?務(wù)區(qū)域運(yùn)營與執(zhí)行下存在兩個較大的業(yè)務(wù)領(lǐng)域： 具體產(chǎn)品實(shí)現(xiàn)(Product Specific?Fulfilment)和跨產(chǎn)品運(yùn)營(Cross Product Operation)。這兩個業(yè)務(wù)領(lǐng)域下又各自包?含了較小的業(yè)務(wù)領(lǐng)域。

3.6???服務(wù)操作?(SERVICE?OPERATION)

業(yè)務(wù)對象的生命周期變動是通過服務(wù)域之間的服務(wù)操作(Service Operation)調(diào)用或執(zhí)?行動作來觸發(fā)的(也稱事件觸發(fā))，或者通過內(nèi)部調(diào)度機(jī)制根據(jù)條件或時間點(diǎn)定期進(jìn)行??觸發(fā)(也稱條件觸發(fā)和時間觸發(fā))?？梢詫⒎?wù)操作理解為具體的業(yè)務(wù)服務(wù)，目前BIAN??已經(jīng)識別了2,000多個。結(jié)合下圖的元模型和具體例子可以加深對服務(wù)操作的理解。服?務(wù)組(Service Group)實(shí)現(xiàn)了服務(wù)域(Service Domain)，服務(wù)組包含了多個服務(wù)操作(Service Operation)。服務(wù)操作涉及具體的業(yè)務(wù)服務(wù)，因此與前置條件?(precondition)、后置條件(post condition)和消息(Message)相關(guān)。

例如服務(wù)域客戶關(guān)系管理(Customer Relationship Management)包含了三個服務(wù)組：

.?CustomerRelationshipManagementPlan_Invocation?(客戶關(guān)系管理計劃-調(diào)?用)

.?CustomerRelationshipManagementPlan_Reporting?(客戶關(guān)系管理計劃-報告)

.?CustomerRelationshipManagementPlan_Origination?(客戶關(guān)系管理計劃-創(chuàng)?建)

在服務(wù)組 CustomerRelationshipManagementPlan_Invocation 下又包含了幾個具體服?務(wù)操作：

.?requestCustomerRelationshipManagementPlan?(請求客戶關(guān)系管理計劃)

.?recordCustomerRelationshipManagementPlan?(記錄客戶關(guān)系管理計劃)

.?terminateCustomerRelationshipManagementPlan?(中止客戶關(guān)系管理計劃)

同樣，在下圖用BIAN元模型將這幾個概念一起進(jìn)行說明。

3.7???功能模式(FUNCTIONAL?PATTERN)?與動作術(shù)語(ACTION?TERM)

每個服務(wù)域都有一個主導(dǎo)功能模式，也就是服務(wù)域所提供的業(yè)務(wù)功能的主要類型或特?征。例如：信用卡(Credit Card)和儲蓄賬戶(Savings Account)的主導(dǎo)功能模式是Fulfill(實(shí)現(xiàn)或履行-根據(jù)客戶要求進(jìn)行產(chǎn)品/服務(wù)的交付)，可售產(chǎn)品(Sales?Product)和商戶關(guān)系(Merchant Relations)的主導(dǎo)功能模式是Agree Terms(同意服務(wù)??條款)，網(wǎng)點(diǎn)貨幣投放(Branch Currency Distribution)的主導(dǎo)功能模式是Process(處?理)，ATM網(wǎng)絡(luò)運(yùn)營(ATM Network Operations)的主導(dǎo)功能模式是Operate(運(yùn)營)。目前?抽象出的功能模式共19個。每個具體服務(wù)操作則對應(yīng)了一個具體的動作術(shù)語(BIAN v8??共定義了17個動作術(shù)語)。每個主導(dǎo)功能模式包含了多個動作術(shù)語。

重用上面的例子，服務(wù)域客戶關(guān)系管理(Customer Relationship Management)的主導(dǎo)??功能模式是Manage(管理)。服務(wù)組CustomerRelationshipManagementPlan_Invocation?下的三個服務(wù)操作的動作術(shù)語Action Term分別是Request(請求)、Record(記錄)和中??止(Terminate)。

從上面的例子可以看出，動作術(shù)語刻畫了所提供服務(wù)的目的(例如請求、記錄或中止)。動作術(shù)語采用了類似MECE的設(shè)計原則，相互之間互不重疊， 而整體上覆蓋了任何?服務(wù)域所支持的主要服務(wù)交換類型。

BIAN v8建立了功能模式與動作術(shù)語之間的缺省組合關(guān)系(如下圖所示)。當(dāng)然在某些情?況下一些額外的服務(wù)操作會引入特定的動作術(shù)語，而與默認(rèn)組合關(guān)系不同，這是很正??常的。這一缺省組合的意義在于給開發(fā)人員了解API后面的銀行語義，幫助開發(fā)人員快?速了解相關(guān)業(yè)務(wù)領(lǐng)域(服務(wù)域)的主要功能和特征與服務(wù)操作(API)的組合關(guān)系。

上圖的橫欄是功能模式(共19個)，左側(cè)縱向是動作術(shù)語(共17個)。高亮顯示了控制記??錄(Control Record，服務(wù)域整個執(zhí)行過程中的全程記錄， 后面會介紹)實(shí)例化的5種類?型及其對應(yīng)的動作術(shù)語。這樣可以更好從“動”的一面了解銀行操作語義。

.?Create(創(chuàng)建)。創(chuàng)建什么呢？?通過動作術(shù)語來理解其語義， DIRECT(指導(dǎo))，MANAGE(管理)，ADMINISTRATER(管控)，DESIGN(設(shè)計)，DEVELOP(開發(fā))?？赡?/span>?涉及戰(zhàn)略計劃，管理策略，高階管控方案，設(shè)計方案，開發(fā)計劃。

.?Initiate(初始化/啟動)。啟動什么呢？?PROCESS(處理)，OPERATE(操作)，?MAINTAIN(維護(hù))，FULFILL(履行)，TRANSACT(執(zhí)行)，ADVISE(建議)，MONITOR(監(jiān)控)，TRACK(跟蹤)。一般涉及流程或動作。

.?Register(注冊/登記)。CATALOG(加入列表)，ENROLL(加入目錄)。

.?Evaluate(檢查以得到結(jié)論)。動作術(shù)語有AGREE?TERMS(協(xié)議條款)，ASSESS(評?估)。可能涉及度量(measurement)，測試(test)，條件(condition)，分析結(jié)??果(analysis)。

.?PROVIDE(提供)。ALLOCATE(分配)。涉及從庫存中進(jìn)行分配的資源/實(shí)物等。

3.8???業(yè)務(wù)場景?(BUSINESS?SCENARIO)

如任何流程模型一樣，?業(yè)務(wù)場景為響應(yīng)一個業(yè)務(wù)事件定義了一組服務(wù)域之間的交互鏈?接序列。同時，?業(yè)務(wù)場景也清晰定義了這一序列中相關(guān)的具體服務(wù)域，以及為執(zhí)行每?個動作而發(fā)生在服務(wù)域之間的交互。業(yè)務(wù)場景在BIAN中被分為兩類：

.?一階業(yè)務(wù)場景(Business Scenario First Order)。一階交互是業(yè)務(wù)場景的簡?單/受限形式，利用一階交互場景可以組裝更為復(fù)雜的端到端業(yè)務(wù)場景(Business Scenario End-2-End)以及線框圖(wireframe)。 它記錄了單個“主要”服務(wù)域?qū)υ撌录捻憫?yīng)， 并僅捕獲與該主要服務(wù)域和任何其他服務(wù)域?的一階服務(wù)交換。它顯示了所選服務(wù)域（主要服務(wù)域）如何根據(jù)業(yè)務(wù)事件調(diào)用?或委派任何服務(wù)域來進(jìn)行響應(yīng)，以便能夠處理事件。因此， 一階交互場景的主?要目的是識別服務(wù)域之間的服務(wù)操作連接，從而對這些連接模式進(jìn)行組合以便?支持更為完整/復(fù)雜的業(yè)務(wù)場景。?目前一階業(yè)務(wù)場景大多是根據(jù)經(jīng)驗(yàn)總結(jié)出來??的，因此并不是完整的銀行流程集合，但可以幫助開發(fā)人員理解整個服務(wù)域的?范圍及目的，從而更好地處理不同的業(yè)務(wù)需求。另外， 一階業(yè)務(wù)場景提供了服?務(wù)域所提供服務(wù)的某種上下文環(huán)境。當(dāng)前版本的一階業(yè)務(wù)場景已超過1000個。?下面是一個批量開工資戶(Open Salary Account)的例子。涉及到4個服務(wù)域(服務(wù)訂單Servicing Order, 對公往來戶Corporate Current Account, 相關(guān)?方數(shù)據(jù)管理 Party Data Management以及個人往來戶Current Account)。

.?端到端業(yè)務(wù)場景(Business Scenario End-2-End)，更為完整/復(fù)雜的端到端業(yè)?務(wù)場景。稍后在BIAN框架概覽部分會結(jié)合實(shí)例進(jìn)行說明。

上面介紹的概念和功能域與服務(wù)相關(guān)，在BIAN中另一條線是數(shù)據(jù)與信息。

3.9???業(yè)務(wù)對象模型?(BOM)

BIAN 當(dāng)前開發(fā)的業(yè)務(wù)對象模型與ISO 20022模型可以交叉引用。 BIAN BOM提供了每個?服務(wù)域所管控的更為詳盡的業(yè)務(wù)信息。下圖示出了BIAN BOM的一個例子， 也是我們上?面提到的服務(wù)域Customer Relationship Management 所涉及的業(yè)務(wù)對象。

由于業(yè)務(wù)對象可能跨服務(wù)域共享， 例如業(yè)務(wù)對象 CustomerContact?(客戶聯(lián)系)在Customer Relationship Management 進(jìn)行維護(hù)， 但可能為其他服務(wù)域的BOM所引用，?例如Contact Handler(客戶聯(lián)系處理),Channel Activity History(渠道活動歷史記?錄)，Customer Event History(客戶事件歷史)，服務(wù)事件歷史(Servicing?Event?History), Point of Service(服務(wù)場點(diǎn))，渠道活動分析(Channel Activity?Analysis)，Fraud Diagnosis(欺詐診斷)，Delinquent Account Handling(拖欠賬戶 處理)，Contact Dialogue(接觸對話)，Transaction Authorization(交易授權(quán))，Contact Routing(聯(lián)系路由)，Card Case(卡案件)，lead/Opportunity?Management(機(jī)會管理)，Customer Case(客戶案件)，Fraud Resolution(欺詐解決)，?EBranch Operation(電子網(wǎng)點(diǎn)運(yùn)營)，Card?Collection(卡托收)，Advanced Voice ??Operation(高級語音服務(wù)的運(yùn)營)等等。下圖示出了引用BOM的圖示。

這樣，通過服務(wù)域 BOM 逐步建立起企業(yè)級業(yè)務(wù)對象模型， 在業(yè)務(wù)層面進(jìn)行關(guān)鍵業(yè)務(wù)概?念的關(guān)系梳理。

3.10?資產(chǎn)/實(shí)體?(ASSET/ENTITY)

服務(wù)域相關(guān)的功能模式所作用于的業(yè)務(wù)資產(chǎn)或?qū)嶓w/對象。 是銀行可以擁有或影響其行?為的有形或無形的事物，例如客戶關(guān)系， 現(xiàn)金或支付能力。資產(chǎn)類型可以看作是業(yè)務(wù)??對象的某種分類。BIAN根據(jù)MECE法則(Mutually Exclusive Collectively Exhaustive?“相互獨(dú)立，完全窮盡”)對銀行資產(chǎn)進(jìn)行了分類和盤點(diǎn)。

結(jié)合功能模式(Functional Pattern)服務(wù)域?qū)嶋H上代表了作用于一類特定資產(chǎn)類型(Asset Type)實(shí)例上的某種商業(yè)行為模式(Functional Pattern)。下圖清晰表示了這?一“動靜”關(guān)系。

3.11?通用工件?(GENERIC?ARTIFACT)

功能模式描述了執(zhí)行的功能的類型。 為了使功能模式的作用更加清晰， BIAN引入了相?關(guān)的設(shè)計元素， 這就是“通用工件(Generic Artifact)?”。 通用工件描述了在跟蹤??服務(wù)域的操作從頭到尾完成其操作時使用/產(chǎn)生的工件/文檔的類型。下表顯示了為每??種功能模式定義的不同通用工件。

添加通用工件的一個好處是，通過引用一些更具體的內(nèi)容(名詞)來更好地描述功能模?式。?例如功能模式“跟蹤”不管跟蹤什么用“日志”來記錄。通用工件與所作用的資?產(chǎn)類型(Asset Type)結(jié)合在一起， 以定義服務(wù)域的控制記錄(Control Record)。這樣?就完整地記錄了服務(wù)域的目的(功能模式作用于資產(chǎn)類型以產(chǎn)生業(yè)務(wù)價值)以及其產(chǎn)生?價值的全過程(控制記錄將過程記錄在通用工件實(shí)例中)。

例如，處理資產(chǎn)類型“客戶關(guān)系(customer relationship)”并執(zhí)行功能模式“同意條?款(Agree Terms)”和相關(guān)通用工件“協(xié)議(Agreement)”的服務(wù)域具有控制記錄“客??戶關(guān)系協(xié)議(Customer Relationship Agreement)”。?只要銀行知道客戶并且客戶對??銀行有一定興趣，服務(wù)域就會為每個客戶創(chuàng)建并維護(hù)控制記錄（客戶關(guān)系協(xié)議）的實(shí)??例。另一個例子是ATM網(wǎng)絡(luò)，該網(wǎng)絡(luò)由“操作(Operate)”功能模式作用于通用工件“操作會話(Operating Session)”，從而產(chǎn)生控制記錄： ATM網(wǎng)絡(luò)操作會話?(ATM?Network Operating Session)。BIAN在模型庫中維護(hù)了資產(chǎn)/實(shí)體的分解結(jié)構(gòu)，已識別服務(wù)域的功能模式和相關(guān)的控制?記錄之間的關(guān)系。

3.12?行為限定符類型?(BEHAVIOR?QUALIFIER?TYPE)

為了給服務(wù)域的服務(wù)操作(Service Operation)和所管控的信息的規(guī)范提供足夠的細(xì)??節(jié)，服務(wù)域的行為特征被進(jìn)一步細(xì)分，這就是“行為限定符類型”?。行為限定符類型?定義了如何將功能模式(Functional Pattern)進(jìn)一步分解成多個組成元素。行為限定?符類型與功能模式在本質(zhì)上差異很大，而且與具體的服務(wù)域緊密相關(guān)。必要時使用行?為限定符可以闡明服務(wù)域及其所提供的服務(wù)的工作性質(zhì)， 更準(zhǔn)確地描述其其目的。行?為限定符也可以是定義由服務(wù)域管理的信息的更詳細(xì)規(guī)范的基礎(chǔ)。

行為限定符類型中的“類型”定義了行為細(xì)分的性質(zhì)應(yīng)該是什么樣的，但是細(xì)分工作?本身必須針對某個具體的服務(wù)域展開。

例如，服務(wù)域“干系方身份驗(yàn)證(Party Authentication)?”具有“評估(Assess)”功??能模式，其業(yè)務(wù)目的是“評估”個人身份是否正確。 “評估”功能模式的行為限定符?類型是“測試(tests)”。?那么具體的行為限定符就是服務(wù)域用來檢查身份而執(zhí)行的具?體測試類型（例如密碼檢查，生物特征測試等）。

再以“個人往來戶(Current Account)”服務(wù)域?yàn)槔?#xff0c;其中涵蓋了很多業(yè)務(wù)請求，例如?打印對賬單，發(fā)起轉(zhuǎn)賬，設(shè)置定扣業(yè)務(wù)等。為了清晰表達(dá)所請求的具體業(yè)務(wù)或產(chǎn)品特??性，可以使用產(chǎn)品特性作為行為限定符類型，而具體的銀行產(chǎn)品如支付、存取款、轉(zhuǎn)??賬等則是行為限定符。

下圖集中示出了功能模式、通用工件及行為限定符類型幾者的對應(yīng)關(guān)系。

管理服務(wù)域中對象的生命周期狀態(tài)。服務(wù)域在對具體資產(chǎn)類型(Asset Type)的實(shí)例執(zhí)??行功能模式(Functional Pattern)，從而行使其職責(zé)時利用控制記錄對每次執(zhí)行過程??自始至終進(jìn)行(狀態(tài)的)記錄和跟蹤。如果將服務(wù)域的動靜兩方面用“動賓”結(jié)構(gòu)來比??喻，控制記錄可以看成是對“動賓”執(zhí)行過程的記錄。從信息角度看資產(chǎn)類型及通用??工件的組合定義了服務(wù)域的控制記錄。?例如功能模式操作(OPERATE)的通用工件是操作?會話(Operating Session)，操作的作用對象或資產(chǎn)類型可能是ATM，這樣操作會話及 ?ATM構(gòu)成了操作ATM這一動作的全部控制記錄。開發(fā)人員對控制記錄的規(guī)約應(yīng)該非常感 ?興趣，因?yàn)槠浒朔?wù)域所管控的主要業(yè)務(wù)信息。并且控制記錄包含了非常廣泛的??信息， 既包含了控制處理所需的所有信息，也包含了任何可能會被引用到的信息， 如??服務(wù)域在完成一個工作周期期間所產(chǎn)生的任何信息。

3.14?分析對象?(ANALYTICS?OBJECT)

服務(wù)域中用來存放分析信息的業(yè)務(wù)對象。

3.15?BIAN?元模型

結(jié)合?BIAN?的整個元模型，可以加強(qiáng)對上面概念的理解。

4?BIAN?框架概覽????????????????????????????????

在上面介紹?A2A?的概念時提到， BIAN?的目標(biāo)是定義標(biāo)準(zhǔn)語義的服務(wù)操作?(ServiceOperations)，特別著重于金融機(jī)構(gòu)的內(nèi)部運(yùn)營以幫助改善銀行的內(nèi)部運(yùn)營績效。 ?雖??然?BIAN?的服務(wù)操作(Service Operations)涵蓋了所有類型的業(yè)務(wù)服務(wù)交互，但其重點(diǎn)?是基于系統(tǒng)的交互。因此其更為具體的一個潛在目標(biāo)是改進(jìn)銀行內(nèi)部應(yīng)用對應(yīng)用（A2A）的互操作性。

4.1???通過業(yè)務(wù)場景貫穿服務(wù)全景視圖

BIAN SOA?設(shè)計框架旨在包含任何一家銀行都可以運(yùn)用的所有業(yè)務(wù)功能。通常， 一家銀?行可能只需要此集合的一部分功能?；仡櫼幌路?wù)域這一關(guān)鍵概念，BIAN 開發(fā)了相應(yīng)?的設(shè)計原理和支持技術(shù)以將金融服務(wù)能力劃分為松散、?非重疊的 “服務(wù)域?(Service??Domain)”。?服務(wù)域的整個集合?BIAN?被稱之為服務(wù)全景視圖(Service Landscape)。

下圖示出了 BIAN 8.0?的服務(wù)全景視圖，?目前業(yè)務(wù)領(lǐng)域大約?30?多個，服務(wù)域大約?300?多個。這些服務(wù)域?qū)嶋H上類似業(yè)務(wù)架構(gòu)中的業(yè)務(wù)組件。

在概念部分介紹業(yè)務(wù)場景時用了一個一階業(yè)務(wù)場景的例子。下圖示出了一個端到端(E2E)業(yè)務(wù)場景的示例， 一個由企業(yè)往來戶執(zhí)行的支付請求。我用這個例子再把上面的?一些概念貫穿起來幫助大家加深對?BIAN?的基本概念的理解。

上圖以?UML Sequence Diagram?示出的業(yè)務(wù)場景涉及了?7?個類實(shí)例之間的交互，而這?7?個類分屬不同的服務(wù)域。

服務(wù)域之間的交互通過“服務(wù)操作”的提供和消費(fèi)進(jìn)行建模。實(shí)際上， 一個服務(wù)域可??以參與到任何業(yè)務(wù)場景之中。?但由于一個服務(wù)域始終實(shí)現(xiàn)唯一且獨(dú)立的業(yè)務(wù)目的(業(yè)務(wù)?功能積木塊)，它提供(和消費(fèi))的服務(wù)操作可以定義為一個相對固定或“有邊界”的集?合。

下圖示出了上例中的其中一個服務(wù)域?FinancialGateway(金融網(wǎng)關(guān))的例子。結(jié)合?BIAN?元模型可以很清晰地看到以服務(wù)域?yàn)橹行牡慕M織關(guān)系，包括：

.?服務(wù)域所歸屬的上層服務(wù)域(如?Payments)

.?服務(wù)域所歸屬的業(yè)務(wù)領(lǐng)域(如具體渠道?Channel Specific)

.?服務(wù)域所包含的服務(wù)(Service Operation)、服務(wù)組(Service Group)以及業(yè)務(wù)?對象(Business Object)

.?服務(wù)域的功能模式?Functional Pattern(如操作?Operate)

4.2???BIAN?的業(yè)務(wù)能力模型和價值鏈模型

通過上面的概念以及框架概覽可以看到?BIAN?的整個脈絡(luò)體系。?BIAN?從?2015?年?v4.0?演化到?2019?年的?v8.0?也一直在探索其他維度和方向。 業(yè)務(wù)能力(Business ?Capability)和價值鏈(Value Chain)是由服務(wù)全景視圖延伸出來的新方向。

下面我分別展開介紹一下。首先看看業(yè)務(wù)能力的概念。

如果僅在服務(wù)域?qū)用孢M(jìn)行研討而不向頂層全面企業(yè)業(yè)務(wù)設(shè)計層面進(jìn)行延伸，那么這種?服務(wù)域概念層面的研究并值得投入。業(yè)務(wù)規(guī)劃人員或戰(zhàn)略家可以在服務(wù)域概念分區(qū)之?上進(jìn)行更多層面或角度的探索和發(fā)現(xiàn)。這些更多層面或角度構(gòu)成了業(yè)務(wù)的“價值視圖”。詳細(xì)刻畫了業(yè)務(wù)交互以及動機(jī)(通過適時調(diào)用更多的服務(wù)域)，并將業(yè)務(wù)價值創(chuàng)?造和更多的通用業(yè)務(wù)績效度量與結(jié)果關(guān)聯(lián)起來。

可以借助業(yè)務(wù)價值層用于范圍廣泛的戰(zhàn)略規(guī)劃及企業(yè)投資決策活動。BIAN的業(yè)務(wù)能力 模型(Business Capability Model)意在將BIAN服務(wù)域與業(yè)務(wù)價值分析層聯(lián)系在一起。?下面我們通過概念定義來澄清兩者之間的關(guān)系和區(qū)別。

業(yè)務(wù)能力(Business?Capability)?– 業(yè)務(wù)能力表示業(yè)務(wù)在做什么，或者業(yè)務(wù)能做什 么，是一組業(yè)務(wù)功能的封裝。在BIAN中業(yè)務(wù)能力是一個比較新的發(fā)展方向，它表示了?一組應(yīng)用于特定對象用以實(shí)現(xiàn)特定目標(biāo)的一組一致的動作集。從業(yè)務(wù)架構(gòu)角度看，業(yè)?務(wù)能力是一組嵌套結(jié)構(gòu)，大多數(shù)達(dá)到3級。

服務(wù)域(Service?Domain)與業(yè)務(wù)能力(Business?Capability)的區(qū)別

這里需要體會和區(qū)分一下服務(wù)域和業(yè)務(wù)能力。?服務(wù)域表示松散的通用業(yè)務(wù)功能，更準(zhǔn)??確地說， 是執(zhí)行某些操作(例如維護(hù)客戶關(guān)系的參考信息或運(yùn)營一個網(wǎng)絡(luò))的能力。 ?對?“業(yè)務(wù)能力(business capability)?”的更為正式和完整的定義則描述了整個企業(yè)希望?在所定義的業(yè)務(wù)環(huán)境中可以做的事情，可以為此定義一些相關(guān)的價值或目的。因此，在BIAN中，業(yè)務(wù)能力定義為結(jié)合特定業(yè)務(wù)環(huán)境的執(zhí)行能力?？梢?/span>利用服務(wù)域執(zhí)行的業(yè)?務(wù)功能(business function)來支持具有不同業(yè)務(wù)上下文以及關(guān)聯(lián)的價值和/或目的的?不同業(yè)務(wù)能力4?。一個業(yè)務(wù)能力是一或多個服務(wù)域的組合， 一個服務(wù)域可以參與到多個?業(yè)務(wù)能力的建設(shè)中。

再舉一個例子將有助于闡明這種區(qū)別。?BIAN定義了一個服務(wù)域， 用于跟蹤/確定銀行?對客戶的信用評估（客戶信用評級）。該服務(wù)域可能涉及許多不同的業(yè)務(wù)能力，下面?是兩種可能的業(yè)務(wù)能力：

.?使產(chǎn)品與客戶匹配的能力

.?與客戶協(xié)商產(chǎn)品價格的能力

可以使用BIAN業(yè)務(wù)場景對上述每個業(yè)務(wù)能力進(jìn)行建模。?在這兩種情況下， 方案都將包?括對客戶信用評級的引用，但是盡管銀行擁有關(guān)于客戶信用的準(zhǔn)確信息， 但這一信息??對銀行的價值或影響在這兩種能力之間會有所不同。

配合下面的BIAN分層元模型?(https://bian.org/servicelandscape-8-0/views/view_29386.html) 可以很清晰地看到上面這些概念之間的關(guān)系。

在業(yè)務(wù)行為層面，銀行戰(zhàn)略(Banking Strategy)由業(yè)務(wù)能力(Business Capability)來?實(shí)現(xiàn)，與信息系統(tǒng)戰(zhàn)略(Information System Strategy)相關(guān)。核心概念服務(wù)域(Service Domain)實(shí)現(xiàn)了信息系統(tǒng)戰(zhàn)略， 同時與業(yè)務(wù)能力緊密相關(guān)，可以是多對多關(guān)?聯(lián)。通過?bian.org在線模型庫訪問業(yè)務(wù)能力，可以看到?BIAN?v8.0?能力地圖如下圖所示。

目前?BIAN?業(yè)務(wù)能力地圖是一個多級嵌套結(jié)構(gòu)， 大部分可以到三級。第一級是一個能力?分類，包括：

.?企業(yè)管理與控制(Enterprise Management and Controlling)，

.?產(chǎn)品與服務(wù)支持(Product and Service Enabling)

.?企業(yè)支持(Enterprise Enabling)

.?銀行運(yùn)營(Bank Operations)

.?客戶與銷售(Customer and?Sales)

.?渠道(Channels)

每個分類下又包含了能力分層結(jié)構(gòu)，如上圖示出的客戶管理(Customer Management)能?力結(jié)構(gòu)?？蛻艚换ス芾?Customer Interaction Management)是一個業(yè)務(wù)能力，指能夠?記錄，跟蹤，控制，組織與監(jiān)控事件的時間順序，交互點(diǎn)和客戶的其他行動，而與渠??道或會話無關(guān)。

這一能力之下又細(xì)分為六個基本業(yè)務(wù)能力：

.?客戶交互建立(Customer Interaction Establishment)，發(fā)現(xiàn)并建立新的客戶?互動的能力

.?客戶交互編排(Customer Interaction Orchestration), 監(jiān)督，規(guī)范和控制客?戶互動的能力

.?客戶體驗(yàn)管理(Customer Experience Management)，在客戶與組織交互時對客?戶行為， 感知和滿意度的理解能力

.?客戶交互監(jiān)控(Customer Interaction Monitoring)，跟蹤并記錄客戶交互過?程的能力

.?客戶交互信息管理(Customer Interaction Information Management)，收集，組織，跟蹤，報告或以其他方式傳播有關(guān)客戶的基本事實(shí)，統(tǒng)計信息，屬?性和信息的能力

.?客戶交互分析(Customer Interaction Analysis)，對客戶交互進(jìn)行審視以確?定交互模式以及其他有助于改進(jìn)的有意義的數(shù)據(jù)的能力

可見， ?BIAN?通過業(yè)務(wù)能力地圖提供了一個可以參考的業(yè)務(wù)能力分層結(jié)構(gòu)，?目前還在建?設(shè)過程中。不同企業(yè)也可以根據(jù)自身需要來定義自己的能力地圖。當(dāng)然，?對某個具體 ?能力還有有待于企業(yè)根據(jù)自身情況進(jìn)行具體定義的。例如在客戶體驗(yàn)管理中具備實(shí)時 ?記錄客戶手機(jī)?App?瀏覽軌跡并與呼叫中心進(jìn)行共享以便于客戶問題診斷和解決的能力 ?等。對業(yè)務(wù)能力進(jìn)行建模的結(jié)果是形成了一整套結(jié)構(gòu)化的高階業(yè)務(wù)需求為未來系統(tǒng)建 ?設(shè)提供輸入。

服務(wù)域的另一種布局選擇——BIAN?價值鏈視圖

BIAN?服務(wù)全景視圖(Service Landscape)的主要用途是作為一個完整的參考框架來組織?服務(wù)域集合，以此來發(fā)現(xiàn)和開發(fā)基本能力積木塊(服務(wù)域)。因此，?只要滿足完整性和 ?松散性， 可以創(chuàng)建不同的業(yè)務(wù)區(qū)域(Business Area)和業(yè)務(wù)領(lǐng)域(Business Domain)來 ?重新布局。也可以創(chuàng)建不同的布局來涵蓋所識別出的?BIAN?服務(wù)域， 并突出不同服務(wù)域?之間的關(guān)系。例如可以按照業(yè)務(wù)條線業(yè)務(wù)職能來組織，也可以按照業(yè)務(wù)部門來組織。

在?BIAN v8.0 剛剛推出了按價值鏈來布局的方式。價值鏈布局可以更為清晰地看出企?業(yè)的支持活動(業(yè)務(wù)管理 - 與圍繞和啟用為客戶提供產(chǎn)品和服務(wù)的核心“工廠”相關(guān)??的監(jiān)督， 定義， 開發(fā)和支持功能)和核心活動(產(chǎn)品與服務(wù)交付?– 包含了與交付給客??戶的產(chǎn)品和服務(wù)直接相關(guān)的核心“工廠”能力)是如何與企業(yè)的價值流動過程聯(lián)系在一?起的。

上圖示出了?BIAN v8.0?的服務(wù)域價值鏈布局。在上面服務(wù)全景視圖中列出的所有服務(wù)?域按價值鏈的分類體系重新進(jìn)行了分類。其中從第一級看核心活動包括： 運(yùn)營，產(chǎn)品，客戶和渠道；支持活動包括： 業(yè)務(wù)方向管理，財務(wù)及風(fēng)險管理，資源管理，業(yè)務(wù)?發(fā)展。同業(yè)務(wù)能力模型一樣，價值鏈模型也在演進(jìn)過程中，?因?yàn)閮r值鏈模型與生態(tài)價?值網(wǎng)建設(shè)密切相關(guān)， 大家可以密切關(guān)注。 下圖示出了矩陣式與價值鏈兩種布局下的組?織關(guān)系對照。盡管業(yè)務(wù)區(qū)域(Business Areas)與業(yè)務(wù)領(lǐng)域(Business Domains)的分類?方法有些許差異，但服務(wù)域沒有變化。

5?BIAN?的應(yīng)用??????????????????????????????????

BIAN?的理念和模型可以在不同場景下進(jìn)行運(yùn)用：

.?基于?BIAN?提供的標(biāo)準(zhǔn)業(yè)務(wù)模型視圖作為參照從業(yè)務(wù)到技術(shù)進(jìn)行一致性映射。

BIAN?在業(yè)務(wù)架構(gòu)層級進(jìn)行的定義，起到了承接高階業(yè)務(wù)模型/戰(zhàn)略和許多實(shí)現(xiàn)??級架構(gòu)視圖之間橋梁的作用。?BIAN?的服務(wù)全景視圖所提供的語義服務(wù)操作可以?一致性地映射到行業(yè)消息通信標(biāo)準(zhǔn)以及專有消息定義上。 BIAN?服務(wù)域的功能和?角色還可以與常規(guī)的實(shí)現(xiàn)級別的架構(gòu)視圖(例如流程和數(shù)據(jù)模型)進(jìn)行對應(yīng)。

.?將?BIAN?的設(shè)計應(yīng)用于不同的技術(shù)環(huán)境。BIAN 服務(wù)域和相關(guān)的服務(wù)操作定義了?業(yè)務(wù)功能分區(qū)及其之間的接口。這一關(guān)于業(yè)務(wù)行為的高階設(shè)計規(guī)約可以用于廣?泛的技術(shù)環(huán)境。其中三種主要考慮的環(huán)境是：作為一個框架更好地組織或調(diào)整?企業(yè)已有的“單體式”系統(tǒng)；作為一種設(shè)計用于采用企業(yè)服務(wù)總線(ESB)技術(shù)??的服務(wù)支撐應(yīng)用；作為一種“容器”服務(wù)分區(qū)模式用于高度分布的“云”技術(shù)?環(huán)境，特別是最近出現(xiàn)的微服務(wù)架構(gòu)。

.?使用?BIAN?來定義企業(yè)藍(lán)圖。 將?BIAN?服務(wù)域作為企業(yè)藍(lán)圖“積木塊”來搭建??企業(yè)藍(lán)圖。服務(wù)域的一個關(guān)鍵特性是其業(yè)務(wù)目的/角色不會隨時間而變化。服??務(wù)域的工作或?qū)崿F(xiàn)其目的的方式可以隨實(shí)踐和支持解決方案的發(fā)展而改變，但?其核心業(yè)務(wù)目的是穩(wěn)定的。 結(jié)果， 使用服務(wù)域定義的業(yè)務(wù)藍(lán)圖也高度穩(wěn)定，適合于不同類型的分析。包括：設(shè)置和跟蹤績效，繪制和評估業(yè)務(wù)覆蓋范圍，關(guān)聯(lián)行為屬性以更好地約定需求。 前面描述的業(yè)務(wù)能力地圖，服務(wù)全景視圖，?價值鏈模型都是藍(lán)圖的具體形式。

前面也提及在?bian.org提供了一組“How-To-Guide”，可以結(jié)合起來學(xué)習(xí)和應(yīng)用?BIAN 的主要思想和資產(chǎn)。其中：

.?BIAN?How-to?Guide?–?Introduction?to?BIAN?– 是整個文檔體系的?整體介紹。其核心理念已經(jīng)在上面的章節(jié)中結(jié)合在線模型庫進(jìn)行了介??紹。?BIAN的其他主要內(nèi)容體現(xiàn)在下面四個文檔中。

. BIAN?How-to?Guide?–?Design?Principles&?Techniques?–?目標(biāo)讀?者是技術(shù)和業(yè)務(wù)架構(gòu)師。側(cè)重BIAN的理論和設(shè)計實(shí)踐，是理解BIAN方法?的不錯參考。

. BIAN?How-to?Guide?–?Developing?Content?–?這個目標(biāo)讀者是?BIAN?的工作組成員。側(cè)重解釋當(dāng)前工作方法和用于記錄BIAN標(biāo)準(zhǔn)內(nèi)容的不同?工具和模板。

.?BIAN?How-to?Guide?–?Applying?the?BIAN?standard?–?目標(biāo)是?BIAN?成員及?其他希望在不同的技術(shù)環(huán)境應(yīng)用?BIAN?的設(shè)計內(nèi)容的金融機(jī)構(gòu)。

.?BIAN?How-to?Guide?–?Semantic?API?– 概述了如何使用?BIAN?標(biāo)準(zhǔn)和相關(guān)內(nèi)?容為應(yīng)用程序接口（API）開發(fā)提供高級設(shè)計。?可以結(jié)合?BIAN API Platform ?Sandbox?(https://portal.bian.org/)?– 一個提供了?RESTful?端點(diǎn)定義的開源開 發(fā)者環(huán)境一起參考。目標(biāo)讀者是在?API?生態(tài)系統(tǒng)進(jìn)行開發(fā)和部署的業(yè)務(wù)和技術(shù)?架構(gòu)師。因此需要對?BIAN?的設(shè)計原則和內(nèi)容有基本理解。

需要注意的是這組文檔會隨著?BIAN?大版本演進(jìn)而不斷更新。下面我們以?Applying the?BIAN standard 及?Semantic API?為主抽取一下?BIAN?標(biāo)準(zhǔn)的應(yīng)用要點(diǎn)。

5.1???基于?BIAN?提供的標(biāo)準(zhǔn)業(yè)務(wù)模型視圖作為參照從業(yè)務(wù)到技術(shù)進(jìn)行一致性映射

從前面的介紹可以看到，BIAN?可以與企業(yè)架構(gòu)規(guī)劃一起結(jié)合進(jìn)一步從設(shè)計層面將業(yè)務(wù)?戰(zhàn)略層層貫穿貫徹下來。這體現(xiàn)在從業(yè)務(wù)到技術(shù)多個層次上：

.?業(yè)務(wù)架構(gòu)層面。?服務(wù)域定義了松散的操作分區(qū)， 實(shí)際上構(gòu)成了業(yè)務(wù)能力積木?塊。在?BIAN v9.0(2020 Q3)計劃完成所有?308?個服務(wù)域的定義， 可以結(jié)合BIAN?服務(wù)域來映射企業(yè)已有的業(yè)務(wù)架構(gòu)規(guī)劃。還可以結(jié)合?BIAN?業(yè)務(wù)能力地 ?圖、服務(wù)全景視圖和價值鏈構(gòu)造企業(yè)服務(wù)藍(lán)圖。利用?BIAN?服務(wù)操作構(gòu)造統(tǒng)一?的企業(yè)服務(wù)目錄。

.?信息/數(shù)據(jù)架構(gòu)層面。?BIAN?與一些金融標(biāo)準(zhǔn)(如?ISO20022,FIBO?等)相互參照，維護(hù)了一組業(yè)務(wù)語義詞匯。加之?BIAN?基于服務(wù)域提供了業(yè)務(wù)對象模型(BOM)，?基于此可以逐步建立起統(tǒng)一的企業(yè)級數(shù)據(jù)模型體系。統(tǒng)一的數(shù)據(jù)定義也有助于?服務(wù)域之間，企業(yè)內(nèi)外的服務(wù)交互。因此，服務(wù)域可以在數(shù)據(jù)架構(gòu)層面進(jìn)行延?伸，幫助進(jìn)行業(yè)務(wù)信息劃分，職責(zé)劃分， 有助于企業(yè)級數(shù)據(jù)治理工作的展開。

例如，信息在服務(wù)域/服務(wù)操作之間如何暴露，?數(shù)據(jù)格式在不同業(yè)務(wù)上下文中??的控制等。另外，BIAN?通過控制記錄和行為限定符類型/行為限定符等對業(yè)務(wù)?信息模型中的“動態(tài)”特性進(jìn)行了建模?？刂朴涗浫?/span>同服務(wù)域中的核心實(shí)體生?命周期記錄儀， 全程記錄了圍繞核心實(shí)體的業(yè)務(wù)價值實(shí)現(xiàn)過程。行為限定符則?對服務(wù)域?qū)?yīng)的功能模式落實(shí)到服務(wù)操作層面進(jìn)行了細(xì)節(jié)刻畫。

.?應(yīng)用架構(gòu)層面。將?BIAN?服務(wù)域作為邏輯能力框架與現(xiàn)有銀行應(yīng)用進(jìn)行對照，幫助理清應(yīng)用邊界以及沖突的部分，有助于應(yīng)用和服務(wù)的更好封裝。由于?BIAN?服務(wù)域的松散性和唯一性，可以更專注地提升和優(yōu)化銀行具體專業(yè)領(lǐng)域能力。?在提升服務(wù)“外部化”和重用的同時，減少緊耦合架構(gòu)帶來的技術(shù)和運(yùn)營的妥?協(xié)/折衷， 踐行?SOA?共享服務(wù)中心的理念。在向應(yīng)用架構(gòu)翻譯時需要結(jié)合應(yīng)用 ?架構(gòu)原則和目標(biāo)進(jìn)行更深層次的考慮，特別要結(jié)合數(shù)據(jù)架構(gòu)統(tǒng)一考慮，例如功?能與數(shù)據(jù)的映射關(guān)系， 是邏輯組件獨(dú)立但數(shù)據(jù)共享，還是數(shù)據(jù)分開組件獨(dú)立運(yùn)?營等。

.?基礎(chǔ)設(shè)施層面。服務(wù)域進(jìn)而可以映射到更為底層的支持技術(shù)基礎(chǔ)設(shè)施上。技術(shù)?基礎(chǔ)設(shè)施層面基本上都提供運(yùn)行實(shí)例隔離或分區(qū)機(jī)制，如容器、虛擬機(jī)等。因?此服務(wù)域與相關(guān)的應(yīng)用模塊只要有相似的運(yùn)行特征都可以共享同一類型的技術(shù)?設(shè)施。考慮到不同服務(wù)域之間的交互時， 特別是在分布式服務(wù)框架、微服務(wù)體?系架構(gòu)逐漸流行時需要在服務(wù)域交互層上考慮更多關(guān)于流量、路由、服務(wù)發(fā)現(xiàn)?和注冊等方面的優(yōu)化?？紤]到互聯(lián)網(wǎng)金融類應(yīng)用的交互特點(diǎn)，還要考慮共享數(shù)?據(jù)的訪問和優(yōu)化問題(是否需要緩存)、數(shù)據(jù)一致性問題(ACID 還是?BASE)等。

但?BIAN?并非要事無巨細(xì)，無所不包。?BIAN?的一個理念是保持與實(shí)現(xiàn)無關(guān)并支持規(guī)范定?義， 因此?BIAN?設(shè)計必須限制在概念級別。BIAN?提供了概念性組件設(shè)計，并提供了一些?指南，說明在需要更全面的邏輯設(shè)計和物理規(guī)范的開發(fā)中如何解讀這些指南。BIAN?的??概念設(shè)計意在僅僅提供足夠的細(xì)節(jié)來與開發(fā)對接，通過采用標(biāo)準(zhǔn)的應(yīng)用模塊/邊界來支?持基于組件的開發(fā)并改進(jìn)互操作性?；诮M件的應(yīng)用設(shè)計與?SOA?實(shí)現(xiàn)方法高度吻合，可以在實(shí)際實(shí)現(xiàn)過程中映射到不同的技術(shù)環(huán)境中。

通過下面的范圍示意圖可以更為清晰地看到這一點(diǎn)。BIAN?更多關(guān)注概念需求，包括前??面介紹的服務(wù)藍(lán)圖，服務(wù)域定義， 業(yè)務(wù)場景及協(xié)作線框圖，?以及業(yè)務(wù)對象模型?BOM。關(guān)?于?BOM?再做一些說明， ?BIAN?將服務(wù)域信息屬性與現(xiàn)有的行業(yè)概念對象模型(如ISO20022)進(jìn)行匹配，以便更為一致地對業(yè)務(wù)信息進(jìn)行解讀。但由于現(xiàn)有模型的一些差?距及失配，BIAN?還是維護(hù)了一套自己概念性的業(yè)務(wù)對象模型(BIAN BOM)。

在邏輯設(shè)計層面，本質(zhì)上解決了概念性需求接下來“如何”實(shí)現(xiàn)的問題。在實(shí)際設(shè)計?過程中，?隨著更多信息的收集和注入，?BIAN?在邏輯設(shè)計層面可以進(jìn)行擴(kuò)展。開發(fā)人員?可以將這些邏輯設(shè)計擴(kuò)展加入到服務(wù)域概念需求以及語義控制記錄屬性中，這些邏輯?設(shè)計擴(kuò)展可以以任何適當(dāng)?shù)男问匠霈F(xiàn)以滿足開發(fā)環(huán)境和部署技術(shù)的具體要求。

BIAN?列出了可以采用的邏輯設(shè)計選擇的一般性指南，但為了保持實(shí)現(xiàn)的獨(dú)立性， 應(yīng)避?免定義太多的細(xì)節(jié)信息。設(shè)計擴(kuò)展的一般類型包括：

.?差異- 添加特定于高級或差異化行為支持的細(xì)節(jié)、考慮規(guī)模要求的細(xì)節(jié)（對于?大型企業(yè)）、處理地緣政治特定需求的細(xì)節(jié)。

.?設(shè)計選項(xiàng)?– 在可用的可能工作方法之間進(jìn)行選擇，例如支持交互處理與離線?處理，或支持不同的交付渠道。

.?組織安排?– 處理特定的地理分布和組成企業(yè)的不同業(yè)務(wù)線

.?非功能需求?– 應(yīng)用運(yùn)行目標(biāo)定義，如性能和安全。

物理規(guī)約涵蓋了用于服務(wù)域功能實(shí)現(xiàn)的實(shí)際代碼和數(shù)據(jù)模式。BIAN?標(biāo)準(zhǔn)是實(shí)現(xiàn)無關(guān) ?的，因此不會涉及服務(wù)域的任何物理屬性。也就是說，當(dāng)將?BIAN?用于組件/容器類型?部署時， 有一些更為具體的操作屬性可以幫助確定最適合的軟件體系結(jié)構(gòu)和公共設(shè)施?類型。

可以考慮的軟件方法和設(shè)施列表包括：

.?消息隊(duì)列和事件?– 服務(wù)交換及服務(wù)觸發(fā), 包括適用于所有服務(wù)域類型的序列?化，安全及彈性恢復(fù)功能。

.?(有限)狀態(tài)機(jī)?– 適用于控制記錄及其子分區(qū)的生命周期管控， 子分區(qū)必要時?由行為限定符類型來定義。

.?事件驅(qū)動處理?– 與狀態(tài)機(jī)設(shè)計一起使用時有利用事件驅(qū)動設(shè)計的巨大潛力。?可以應(yīng)用于控制記錄(及其行為限定符定義的子分區(qū))的具體屬性及其相關(guān)的規(guī)?則/策略， 或者控制記錄狀態(tài)或狀態(tài)轉(zhuǎn)移模式。

.?工作流管理?– 可以廣泛應(yīng)用于大多數(shù)服務(wù)域類型。在一些情況下可以適當(dāng)進(jìn)?行工作流“嵌套”以與行為限定符類型形成的控制記錄分解層次結(jié)構(gòu)一致。

.?規(guī)則引擎?– 與工作流管理常一起使用， 規(guī)則引擎也有廣泛應(yīng)用的可能。

.?數(shù)據(jù)管理設(shè)施?– 特別是在服務(wù)域管控自身自治性數(shù)據(jù)存儲庫的同時，需要廣?泛的數(shù)據(jù)管理設(shè)施。?高級數(shù)據(jù)管理功能可能用于具體的高度分布式環(huán)境中（用?于復(fù)制和恢復(fù)）?。

.?分析及報告設(shè)施?– 廣泛應(yīng)用的通用分析及報告。

.?命令及控制?–?由于每個服務(wù)域都可以充當(dāng)自己的操作單元，因此有可能開發(fā)?與服務(wù)域一致的標(biāo)準(zhǔn)跟蹤和報告設(shè)施，以幫助實(shí)現(xiàn)服務(wù)域之間的指揮和控制結(jié)?構(gòu)。

當(dāng)在?SOA?中作為容器實(shí)現(xiàn)時， 一些設(shè)施可以應(yīng)用在所有服務(wù)域分區(qū)。一些設(shè)施可能更?適于某些特定的功能行為模式。例如，“處理/流程(Process)”類型的服務(wù)域更適合?使用工作流管理。

5.2???將?BIAN?的設(shè)計應(yīng)用于不同的技術(shù)環(huán)境

BIAN?作為一種邏輯設(shè)計提供了關(guān)于銀行業(yè)務(wù)服務(wù)域以及其下業(yè)務(wù)服務(wù)操作的一個完整??且規(guī)范的服務(wù)目錄。這一服務(wù)目錄將銀行、客戶、第三方合作方都緊密聯(lián)系起來，構(gòu) ?成了新型生態(tài)銀行互聯(lián)互通的基礎(chǔ)。同時，這一服務(wù)目錄在不同業(yè)務(wù)交互場景不同語 ?境下也賦予了不同的含義，因此這一服務(wù)目錄不是單純的技術(shù)?API，而是包含了業(yè)務(wù)含?義的語義?API?服務(wù)。當(dāng)面對客戶和第三方時銀行在這一語義服務(wù)層的封裝下可以看作 ?是一個“黑箱”，其具體實(shí)現(xiàn)技術(shù)對外屏蔽。如果進(jìn)入到銀行系統(tǒng)內(nèi)部， SOA?的理念在?與具體技術(shù)環(huán)境結(jié)合時可以有不同的選擇。

在描述如何在不同的技術(shù)環(huán)境中應(yīng)用?BIAN?之前， 有必要對服務(wù)域的規(guī)范進(jìn)行細(xì)化以便?與不同的技術(shù)實(shí)現(xiàn)對接。從業(yè)務(wù)層面看，服務(wù)域行使著一定的業(yè)務(wù)角色并通過其提供??的服務(wù)操作參與到其他業(yè)務(wù)活動中，或者根據(jù)需要從其他服務(wù)域訂閱服務(wù)操作。這種??描述是一種基于服務(wù)的實(shí)現(xiàn)，但是相同的業(yè)務(wù)功能也可以在不太靈活的傳統(tǒng)技術(shù)環(huán)境??中實(shí)現(xiàn)。在該技術(shù)環(huán)境中，連接是點(diǎn)對點(diǎn)的，而不是通過某些基于服務(wù)的靈活機(jī)制(如?服務(wù)總線，服務(wù)的發(fā)現(xiàn)和注冊)來實(shí)現(xiàn)。

從設(shè)計層面看， 上圖示出了服務(wù)域的兩個主要組成部分：功能核心(functional core)?和“服務(wù)化”打包器(“service enabling” wrapper)。打包器主要用來處理與其他??服務(wù)域的交互， 如上圖所示。需要區(qū)分服務(wù)域的這兩個方面，因?yàn)檫@兩個方面在不同??技術(shù)環(huán)境將以不同的方式進(jìn)行實(shí)現(xiàn)和解釋。

從技術(shù)環(huán)境層面看，銀行由于長期積累， 存在多種不同技術(shù)環(huán)境共存的情況，其典型??環(huán)境包括：1)基于主機(jī)(Host-大致代表了?IBM?主機(jī)及各類小型機(jī)環(huán)境)的核心業(yè)務(wù)系統(tǒng)?環(huán)境； 2)SOA?時代打造的基于消息隊(duì)列/企業(yè)服務(wù)總線的應(yīng)用互連環(huán)境； 3)新型微服務(wù)?容器云平臺環(huán)境。

5.2.1?????常規(guī)核心業(yè)務(wù)應(yīng)用的合理化

BIAN?服務(wù)域可以用來評估現(xiàn)有應(yīng)用組合，用服務(wù)域劃分來識別業(yè)務(wù)應(yīng)用之間的業(yè)務(wù)邏?輯及業(yè)務(wù)信息的碎片及重疊。因?yàn)?/span>?BIAN?服務(wù)域作為一個穩(wěn)定的框架定義了不重疊的功?能分區(qū)， 這些分區(qū)可用于評估現(xiàn)有/核心應(yīng)用的疆域，從而找到不足之處。大多數(shù)現(xiàn)有?銀行核心業(yè)務(wù)應(yīng)用涵蓋了多個但不同的服務(wù)域集合，因此直接進(jìn)行應(yīng)用程序與應(yīng)用程??序進(jìn)行比較意義不大，因?yàn)閮蓚€應(yīng)用通常具有不同的功能范圍。 ?由于在將應(yīng)用映射到?服務(wù)域時服務(wù)域不會重疊，因此通過服務(wù)域和現(xiàn)有應(yīng)用的一一映射，然后合并所有服??務(wù)域的評估結(jié)果，可以直觀看到現(xiàn)有應(yīng)用的情況。包括下圖示意出的重疊、差距/空白?以及錯位。

關(guān)于功能冗余問題，?對于絕大多數(shù)核心業(yè)務(wù)應(yīng)用來說，可能會發(fā)現(xiàn)下圖這種模式。 ?由?于銀行應(yīng)用是逐一建立起來的， 某些應(yīng)用邏輯和/或業(yè)務(wù)信息可能涵蓋了不少其他服務(wù)?域的內(nèi)容(即使是很少的內(nèi)容)。通過服務(wù)域映射可以形成下圖中部?as-is?現(xiàn)狀功能分??布圖，然后逐步過渡到下圖右側(cè)的?to-be?理想狀態(tài)。這樣通過服務(wù)外部化逐漸剝離耦??合的應(yīng)用，將應(yīng)用之間的邊界清晰化。同時保證應(yīng)用業(yè)務(wù)目的更加明確和專注，從而??有利于進(jìn)行業(yè)務(wù)服務(wù)自治。這是技術(shù)層面踐行松耦合、分布式或微服務(wù)架構(gòu)的關(guān)鍵。

銀行應(yīng)用中有很多領(lǐng)域容易落在多個服務(wù)域中， 特別是與客戶信息、客戶關(guān)系管理、?客戶服務(wù)相關(guān)的部分，?以及許多共享的后臺功能。利用服務(wù)域的松散性，非重疊特性?可以更好地指導(dǎo)共享服務(wù)功能建設(shè)(國內(nèi)也稱之為“中臺”)，可以幫助減少同步開銷。?在這種環(huán)境下?BIAN?更多是用作參考評估框架。

5.2.2????基于企業(yè)服務(wù)總線的應(yīng)用互連/主機(jī)翻新架構(gòu)

第二種技術(shù)環(huán)境是對現(xiàn)有核心主機(jī)系統(tǒng)進(jìn)行服務(wù)化改造，其目的是支持對功能和數(shù)據(jù)??的共享訪問。通過服務(wù)化技術(shù)(如企業(yè)服務(wù)總線?ESB)來提供對已有主機(jī)系統(tǒng)的訪問，同?時基于?ESB?上所封裝的服務(wù)可以進(jìn)行應(yīng)用組裝， 如下圖所示。

ESB?環(huán)境是?SOA?初級階段建設(shè)的產(chǎn)物。?在沒有任何組織藍(lán)圖或企業(yè)架構(gòu)來指導(dǎo)服務(wù)的范?圍和內(nèi)容的情況下， 企業(yè)?SOA?建設(shè)容易傾向于定義相對細(xì)粒度的服務(wù)，?以提供對共享 ?實(shí)用程序的功能訪問。這些細(xì)粒度的服務(wù)可以通過提供可重復(fù)使用的軟件實(shí)用程序來 ?改善新業(yè)務(wù)應(yīng)用的開發(fā)，但這種方法有一些挑戰(zhàn)：

.?缺乏業(yè)務(wù)架構(gòu)和業(yè)務(wù)模型建設(shè) - 軟件實(shí)用程序的重用并不總是能推動業(yè)務(wù)功??能的合理化或重用。這也是歷史上?SOA?建設(shè)的一個難題，不認(rèn)真對待?SOA?方向?可能走偏。

.?復(fù)雜且非系統(tǒng)化的服務(wù)庫 -?由于服務(wù)的粒度很細(xì)，因此可能導(dǎo)致重疊，龐大??而復(fù)雜的服務(wù)集合，從而難以對其進(jìn)行分類，維護(hù)和引用。目前國內(nèi)一些銀行?的服務(wù)種類已經(jīng)上萬， 里面有不少這樣的情況。由于歷史原因，不同渠道不同?產(chǎn)品的同類服務(wù)由不同服務(wù)實(shí)例來實(shí)現(xiàn)。當(dāng)進(jìn)入到微服務(wù)/服務(wù)網(wǎng)格技術(shù)體系??后這一混沌情況會造成新的復(fù)雜性，使得新技術(shù)的引入難以或無法預(yù)期體現(xiàn)到?業(yè)務(wù)價值上。

.?專有服務(wù)?–?由于服務(wù)的顆粒度較細(xì)，所定義的服務(wù)可能包含了特定主機(jī)應(yīng)用?的專有功能。這些功能因?yàn)榕c特定系統(tǒng)相關(guān)，從而在面對多個不同主機(jī)源封裝?并組裝服務(wù)時的簡便性受到影響。

.?同步?– 如果主機(jī)系統(tǒng)只是簡單進(jìn)行了服務(wù)化， 而沒有在藍(lán)圖或設(shè)計的指導(dǎo)下?減少主機(jī)系統(tǒng)之間的冗余和沖突， 則功能和數(shù)據(jù)的可追溯性問題仍然存在。

換句話說，技術(shù)層面的“解耦”不能替代業(yè)務(wù)層面的解耦。利用?BIAN?服務(wù)域及其服務(wù)?操作來定義?ESB?的服務(wù)目錄， 由于服務(wù)域的高度穩(wěn)定性可以通過服務(wù)域下操作服務(wù)的??實(shí)現(xiàn)來逐步消除應(yīng)用程序中的冗余，并大大減少應(yīng)用同步的開銷。在有?ESB?或服務(wù)目??錄這種類型的技術(shù)環(huán)境中，可以用到?BIAN?服務(wù)域的功能核心和服務(wù)打包器組件(如在??ESB?平臺進(jìn)行服務(wù)打包)。同時由于在這種技術(shù)環(huán)境下已經(jīng)細(xì)化到了服務(wù)操作層面，?需?要參考?BIAN?模型在三個層面進(jìn)行映射:服務(wù)域、服務(wù)操作和業(yè)務(wù)信息。下圖示出了這??一環(huán)境下的?ESB?服務(wù)如何與主機(jī)系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)/消息結(jié)構(gòu)進(jìn)行映射。

5.2.3????松耦合的分布式/云平臺

第三類技術(shù)環(huán)境是高度靈活，分布式的云平臺以及微服務(wù)架構(gòu)。?這種類型的環(huán)境可以?看作是從?ESB?環(huán)境到“純”面向服務(wù)架構(gòu)的過渡。在?ESB?上所映射呈現(xiàn)出的功能被獨(dú)??立的業(yè)務(wù)功能“容器”所取代，這些容器可以通過網(wǎng)絡(luò)作為自治服務(wù)中心進(jìn)行相互協(xié)??作。?這種“松散耦合”的高度分布式網(wǎng)絡(luò)服務(wù)環(huán)境的一些主要操作特征包括：

.?功能獨(dú)立運(yùn)行?– 每個服務(wù)中心都可以充當(dāng)獨(dú)立的功能“容器”， 并具有自己?的內(nèi)部處理邏輯，數(shù)據(jù)存儲和狀態(tài)管理。 ?它會按照自己的計劃/時間運(yùn)行，調(diào)?用其他服務(wù)并在認(rèn)為適當(dāng)時響應(yīng)外部事件。

.?通過服務(wù)調(diào)用進(jìn)行通信?– 服務(wù)中心之間的交換/交互全部通過服務(wù)操作調(diào)用?進(jìn)行。

.?所需的信息精度級別各不相同?– 兩個協(xié)作的服務(wù)中心可能只需要在更近似的?語義級別上同意/協(xié)調(diào)信息元素的含義。這減少了對機(jī)器可表示數(shù)據(jù)采用通用??數(shù)據(jù)格式和結(jié)構(gòu)的要求。

.?交易所使用基于隊(duì)列和事件的機(jī)制?–?網(wǎng)絡(luò)服務(wù)中心異步運(yùn)行。?當(dāng)一個人向??另一個人請求服務(wù)時， 它可以繼續(xù)執(zhí)行其他任務(wù)，并在收到請求時監(jiān)視響應(yīng)并?采取行動。 操作也應(yīng)考慮“例外?”處理，即如何處理延遲，丟失或錯誤的響??應(yīng)(和請求)。以及微服務(wù)架構(gòu)中的例外運(yùn)營模式，如斷路器、水密艙等。

高度分布式環(huán)境中的業(yè)務(wù)執(zhí)行通常是事件驅(qū)動的。 某些事件會觸發(fā)一個中心的活動，?然后根據(jù)需要調(diào)用其他服務(wù)中心的服務(wù)。然后，?這些“輔助”服務(wù)中心也可能又會呼?叫其他服務(wù)中心，然后才能做出響應(yīng)。?初始觸發(fā)的處理可能會導(dǎo)致整個網(wǎng)絡(luò)上許多服?務(wù)交互的“級聯(lián)”反應(yīng)，直到完成所有必要的處理和響應(yīng)， 并且網(wǎng)絡(luò)達(dá)到新的穩(wěn)定狀?態(tài)為止。 這種服務(wù)之間這種分布式協(xié)同(Choreography)方式與?ESB?總線中心式的編排?(Orchestration)方式有很大不同。

應(yīng)該說， 微服務(wù)這種服務(wù)協(xié)同方式更接近“純”面向服務(wù)架構(gòu)，因此?BIAN?服務(wù)域可以?與上述服務(wù)中心“容器”一一對應(yīng)。服務(wù)域規(guī)范的兩個組成部分都會用到。功能核心??定義了容器的角色，概述了容器所需的內(nèi)部功能。服務(wù)打包器則處理網(wǎng)絡(luò)中的服務(wù)啟??用、服務(wù)/狀態(tài)管理和目錄/連接處理等。服務(wù)打包器包含必要的邏輯，?以確保服務(wù)域??了解其可能調(diào)用的所有其他服務(wù)域的狀態(tài)。通常會使用某種形式的隊(duì)列和事件管理來??實(shí)現(xiàn)自身提供的服務(wù)操作和被(其他服務(wù)域)調(diào)用的服務(wù)操作。下圖示出了云平臺方案??經(jīng)?？吹降木W(wǎng)狀連接形態(tài)。

目前在微服務(wù)架構(gòu)領(lǐng)域快速演進(jìn)的服務(wù)網(wǎng)格(Service Mesh)技術(shù)如?Istio，和?BIAN?服?務(wù)域的功能拆分有類似的理念。如下圖?Istio?示意圖所示， SvcA，SvcB?專注于業(yè)務(wù)核心功能， 運(yùn)行在專屬容器中。除了核心功能之外的功能，如路由連接，安全，監(jiān)控遙?測，策略控制能均剝離到另外的專屬機(jī)制?sidecar?上。

當(dāng)然， BIAN?與云結(jié)合主要還是體現(xiàn)在業(yè)務(wù)層面，如?SaaS?上。?SaaS?的關(guān)鍵在于業(yè)務(wù)的 ?標(biāo)準(zhǔn)性規(guī)范性， ?BIAN?服務(wù)域恰好為銀行之間， 銀行與服務(wù)提供商之間在業(yè)務(wù)層面進(jìn)行?無縫銜接提供了橋梁。配合云平臺可以搭建起圍繞銀行生態(tài)的超級平臺?。

目前不少國內(nèi)銀行已經(jīng)通過生態(tài)云、金融云平臺將自身的銀行能力向外輻射和輸出。

同時，積極展開生態(tài)合作，通過云平臺托管合作伙伴的應(yīng)用。配合?BIAN?標(biāo)準(zhǔn)可以進(jìn)一?步將多個云平臺進(jìn)一步織成更大的生態(tài)網(wǎng)絡(luò)，基于?BIAN?標(biāo)準(zhǔn)的?SaaS?統(tǒng)一對外(消費(fèi)者)服務(wù)接口，同時和各個銀行及服務(wù)提供商以標(biāo)準(zhǔn)接口在語義層面對接。進(jìn)一步延伸?這一理念，可以改變國內(nèi)外銀行之間的“服務(wù)”對接方式。配合技術(shù)層面的“平臺”?技術(shù)如區(qū)塊鏈， 可以從業(yè)務(wù)到技術(shù)打造更為統(tǒng)一的全球性生態(tài)平臺。

5.2.4????三種環(huán)境結(jié)合運(yùn)用

如前所述，大多數(shù)銀行的應(yīng)用組合都結(jié)合了上面所有三種類型的環(huán)境。?BIAN?服務(wù)的一?個優(yōu)勢是可以在任何這些技術(shù)環(huán)境中對?BIAN(銀行業(yè)務(wù))進(jìn)行一致的解釋。在每種情況??下服務(wù)域功能分區(qū)都以相同的方式來進(jìn)行概念定義和邏輯設(shè)計。?因此，模型可以促進(jìn)?在不同環(huán)境中開發(fā)和運(yùn)行的業(yè)務(wù)應(yīng)用之間的集成。

另外，需要注意的是： 盡管分布式微服務(wù)架構(gòu)看上去接近“純”面向服務(wù)架構(gòu)。但其?畢竟是有代價的，坦率講企業(yè)需要從業(yè)務(wù)價值， 總擁有成本全面考慮技術(shù)選擇。在這?種情況下，BIAN?這一統(tǒng)一邏輯模型的指導(dǎo)和治理意義更為重大。

在新舊系統(tǒng)交替過程中，可以用?BIAN?來整理概念需求，作為演進(jìn)參照框架統(tǒng)一業(yè)務(wù)需?求，業(yè)務(wù)架構(gòu)。進(jìn)一步指導(dǎo)邏輯設(shè)計和物理規(guī)約設(shè)計。?例如，在整個演進(jìn)或轉(zhuǎn)型過程??中，隨時根據(jù)各個層次的具體需求來進(jìn)行對應(yīng)和調(diào)整。某些情況下可以采用更為靈活??的方式。在銀行系統(tǒng)現(xiàn)代化改造時，一些應(yīng)用開始以云的方式進(jìn)行開發(fā)和部署。其邏??輯設(shè)計過程與傳統(tǒng)面向過程/流程的方式有不少區(qū)別，但邏輯數(shù)據(jù)模式仍然可以與傳統(tǒng)?系統(tǒng)進(jìn)行映射和參照。在物理數(shù)據(jù)庫層面甚至也可以根據(jù)性能、吞吐量、容災(zāi)等要求??進(jìn)行共享。在云系統(tǒng)完全達(dá)到要求時再考慮逐步進(jìn)行物理分離。這樣在銀行系統(tǒng)演進(jìn)??過程中可能出現(xiàn)“雙層架構(gòu)”，并且這一架構(gòu)可以以服務(wù)域為單位進(jìn)行展開。

5.3???BIAN?語義?API

API?是“服務(wù)”概念的進(jìn)一步延伸。在業(yè)務(wù)上?Open API?已成為企業(yè)向外進(jìn)行能力輻射?的抓手之一，API?已成為一種特殊的銀行產(chǎn)品。因此?API?戰(zhàn)略也是銀行的產(chǎn)品戰(zhàn)略之??一。目前銀行正在加大?Open API?的建設(shè)力度， 配合?B2B?通信網(wǎng)關(guān)以及?SaaS?戰(zhàn)略， 構(gòu)?成了完整的?B2C(對消費(fèi)者)、B2D(對開發(fā)人員)和?B2B(對合作伙伴)的生態(tài)渠道層。在?技術(shù)層面?API?采用了更加靈活的?Restful?風(fēng)格， 更好適應(yīng)多語言編程(polyglot

programming)及微服務(wù)趨勢。同時也在?API?的生命周期管理、API?運(yùn)營(監(jiān)控和流控)、?API?安全、社區(qū)、API?開發(fā)人員網(wǎng)絡(luò)、?API?沙箱全面加強(qiáng)。

BIAN?的整個設(shè)計理念基于?SOA?的面向服務(wù)體系架構(gòu)，因此在支持?API?解決方案方面有?著天然的銜接性，這表現(xiàn)在：

.?支持新興行業(yè)方法?– 包括?Open API?的開發(fā)和采用微服務(wù)架構(gòu)

.?支持行業(yè)標(biāo)準(zhǔn)?– BIAN?服務(wù)域和服務(wù)操作為銀行業(yè)務(wù)的組件化和服務(wù)化提出了?行業(yè)標(biāo)準(zhǔn)定義。同時?BIAN?與?ISO20022、FIBO(OMG?及?EDM Council?推出的銀行?業(yè)務(wù)本體模型)等均有對照呼應(yīng)

.?支持增量采用/遷移?– 可以分階段逐步實(shí)施和采用?BIAN?解決方案

5.3.1?????BIAN??語義?API?是與具體物理實(shí)施無關(guān)的?REST?風(fēng)格?API

BIAN 服務(wù)域下的服務(wù)操作很好詮釋了?API(Application Programming Interface)的初?衷。服務(wù)域清晰劃分了應(yīng)用(Application)的邊界，服務(wù)操作則針對?Programming

Interface。進(jìn)而，為了更好地支持?API?及微服務(wù)架構(gòu)， BIAN?服務(wù)操作定義與?REST?架?構(gòu)風(fēng)格進(jìn)行了映射，這樣可以幫助開發(fā)人員更好更準(zhǔn)確地理解和使用?BIAN API。

REST(Representational State Transfer?表征狀態(tài)轉(zhuǎn)移)是分布式超媒體系統(tǒng)廣泛采用

的一種架構(gòu)風(fēng)格， 專門為?web?服務(wù)而開發(fā)。?其所提出的六個指導(dǎo)性架構(gòu)約束

(Architecture Constraints，包括客戶服務(wù)器， 無狀態(tài)， 緩存， 分層系統(tǒng)，應(yīng)需代

碼，統(tǒng)一格式接口)同時兼顧了互操作性和應(yīng)用通信的性能。REST?通過使用一組預(yù)定義?的無狀態(tài)操作集合提供了對“資源?”的訪問。?而資源采用?URI(統(tǒng)一資源定位符)進(jìn)行識?別，服務(wù)請求的響應(yīng)結(jié)果體現(xiàn)在消息的有效載荷(payload)中。?有效載荷可以表示為不?同格式， 如?JSON，XML，HTML。HTTP?則是最常見的通信協(xié)議，?HTTP?的動詞/方法，即

GET, PUT, POST, PATCH, DELETE?則對應(yīng)了對資源的?CRUD(創(chuàng)建?Create，讀取

Retrieve，更新?Update?及刪除?DELETE)操作。

從資源角度?REST?定義了四種資源典型類型：

.?Documents?– 單個資源，如一個對象實(shí)例或數(shù)據(jù)庫記錄?？梢允褂脗鹘y(tǒng)層次

化命名結(jié)構(gòu)來進(jìn)行引用。例如?http://api.example.com/building-??????????management/office-buildings/{building-Id}?。表征狀態(tài)通常會將實(shí)例的特?性值進(jìn)行組合。

.?Collections?– 表示了服務(wù)器端管理的資源目錄或資源集合。?collection 決?定什么時候來應(yīng)需創(chuàng)建一個新的資源實(shí)例。例如

http://api.example.com/building-management/office-buildings。

.?Store?– 客戶端管理的資源庫。 store?并不創(chuàng)建新的資源實(shí)例但可以來使能一?個?collection。例如?http://api.example.com/cart-??????????????????????management/users/{id}/carts?。

.?Controller?– 專用于處理步驟性的概念。?REST API?依賴?controller 來執(zhí)行?與應(yīng)用具體相關(guān)的動作，有輸入/輸出及參數(shù)，這些動作邏輯上不能與?CRUD?標(biāo)?準(zhǔn)方法簡單映射。例如?http://api.example.com/cart-????????????????????management/users/{id}/cart/checkout?。

前面提到服務(wù)域運(yùn)作的整個生命周期記錄在控制記錄中，因此通過?REST API?來進(jìn)行調(diào)?用時會與控制記錄以及組成控制記錄的通用工件進(jìn)行交互。這里存在服務(wù)域功能模

式、通用工件以及?RESTful?典型類型之間的映射，如下圖所示。

涉及步驟性執(zhí)行處理邏輯的通用組件一般會對應(yīng)?Controller，如步驟(Procedure)，操

作會話(Operating Session)，協(xié)議維護(hù)(Maintenance Arrangement)，協(xié)議履行?(Fulfillment Arrangement)，交易(Transaction)，建議(Advice)，狀態(tài)監(jiān)控

(State),日志跟蹤(Log)。涉及集合或目錄的歸在?Collections，如目錄條目

(Directory Entry)，成員注冊(Membership)。其他的單一實(shí)例則歸在?Document。

BIAN?的服務(wù)操作規(guī)約與具體實(shí)現(xiàn)無關(guān)， 在與?REST?映射時?REST API Endpoint?成為最細(xì)?的一個映射層次。Endpoint?實(shí)際上就是定位具體服務(wù)操作的?URI，URI?的層次結(jié)構(gòu)也展?示了?BIAN?資源定位的層次結(jié)構(gòu)。如下圖所示， 從控制記錄(根)開始，緊接著行為限定?符分層結(jié)構(gòu)，然后是動作術(shù)語(這里需要注意?REST URI?通常不建議包含動作，因此動 ?作術(shù)語會轉(zhuǎn)為名詞方式)，最后是業(yè)務(wù)對象。

讀者可以訪問 portal.bian.org 搜索?BIAN?語義?API?的具體信息。

通過?API Catalog?可以瀏覽?BIAN?的?API 目錄，下載相關(guān)文檔及代碼。

5.3.2?API?在不同技術(shù)環(huán)境下的實(shí)現(xiàn)方式

與上面介紹到的三種技術(shù)環(huán)境相對應(yīng)，?API?在不同技術(shù)環(huán)境下有不同的實(shí)現(xiàn)方式：直連?核心系統(tǒng)(Direct to Core)，將后端主機(jī)系統(tǒng)打包封裝(Wrapped Host)，分布式微服 ?務(wù)架構(gòu)(Distributed Microservice)。這三種方式在?BIAN?所定義的邏輯服務(wù)目錄下可?以共存。如下圖所示， 銀行可以根據(jù)這三種方式的特點(diǎn)在不同階段進(jìn)行合理選擇。

下表列出了三種不同的技術(shù)實(shí)現(xiàn)方式及其各自的特點(diǎn)。

5.3.3?????BIAN?API?開發(fā)方法是一個系統(tǒng)過程

API?是?BIAN?的主要演進(jìn)方向之一，是編制數(shù)字化銀行生態(tài)的關(guān)鍵?？此坪唵蔚?/span>?API?實(shí)?際上涉及整個銀行內(nèi)外，業(yè)務(wù)與?IT?的整體規(guī)劃和協(xié)作。因此?BIAN API?的開發(fā)方法是?一個系統(tǒng)化過程。

1)?通過線框圖?Wireframe(服務(wù)域之間的協(xié)作集群)劃定服務(wù)域的范圍以及周邊邊?界

2)?借助業(yè)務(wù)場景 Business Scenarios 定義?API?訪問的業(yè)務(wù)上下文