




版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認(rèn)領(lǐng)
文檔簡介
現(xiàn)代企業(yè)架構(gòu)白皮書目錄目錄 4折射出本輪數(shù)字化轉(zhuǎn)型中以“業(yè)務(wù)平臺化”為代表的企業(yè)現(xiàn)代化趨勢 5新的問題將業(yè)務(wù)平臺化內(nèi)涵向前演進 8經(jīng)典的企業(yè)架構(gòu)框架已不足夠應(yīng)對業(yè)務(wù)平臺化中的新問題 面向以業(yè)務(wù)平臺化為代表的企業(yè)現(xiàn)代化轉(zhuǎn)型中的新問題,發(fā)布現(xiàn)代企業(yè)架構(gòu)框架 2.現(xiàn)代企業(yè)架構(gòu)框架(ModernEnterpriseArchitectureFramework-MEAF) 2.1企業(yè)架構(gòu) 2.4現(xiàn)代企業(yè)架構(gòu)框架設(shè)計原則 2.5現(xiàn)代企業(yè)架構(gòu)框架元模型總覽 203.1業(yè)務(wù)架構(gòu)元模型綜述 3.2業(yè)務(wù)架構(gòu)元模型應(yīng)用 3.3業(yè)務(wù)架構(gòu)元模型補充說明 4.1應(yīng)用架構(gòu)元模型綜述 434.2應(yīng)用架構(gòu)元模型應(yīng)用 5.1數(shù)據(jù)架構(gòu)元模型綜述 535.2數(shù)據(jù)架構(gòu)元模型應(yīng)用 586.1技術(shù)架構(gòu)元模型綜述 6.2技術(shù)架構(gòu)元模型應(yīng)用 平臺化”2020年是“黑天鵝”集中爆發(fā)的一年,也是數(shù)字多項研究調(diào)查顯示,60%以上的受訪高管們(參考文獻1、2),在疫情之后,都充分意識到數(shù)字化的對比中,也均顯著優(yōu)于競爭對手(參考文獻2)。ThoughtWorksOTho1)以互聯(lián)網(wǎng)巨頭中臺化為原點,延伸到以零售、金融、電信為代表的傳統(tǒng)行業(yè)數(shù)字化建設(shè),中臺實踐正在進入到深水區(qū)零售行業(yè)金融行業(yè)公司時間阿里巴巴2015年12月宣布全面啟動“中臺戰(zhàn)略,構(gòu)建符合大數(shù)據(jù)時代的“大中臺、小前臺”組織機制和業(yè)務(wù)機制組織架構(gòu)調(diào)整,“扎根消費互聯(lián)網(wǎng),擁抱產(chǎn)業(yè)互聯(lián)網(wǎng)”,在技術(shù)上開面建設(shè)中臺美團2018年11月嘗試打通各個業(yè)務(wù)之間的數(shù)據(jù),實現(xiàn)用戶端的賬戶統(tǒng)一,實現(xiàn)用戶數(shù)據(jù)中臺京東2018年12月發(fā)布組織調(diào)整,采用“中臺”的組織概念,中臺部門已TOB為主,包搭建“直播大中臺”,“直播大中臺”將抖音、西瓜視頻和火山小視頻三個短視頻產(chǎn)品抽出、ThoughtWorks之一。(參考文獻4、5)當(dāng)行業(yè)越來越重視客戶一建設(shè)業(yè)務(wù)中臺。(參考文獻4、5)電信行業(yè)對IT新技術(shù)與工程實踐的關(guān)注和引入。過去5年,2)ThoughtWorks在以上行業(yè)中臺建設(shè)的深入實踐認(rèn)為,“中臺”不是目的,而是手段,“平臺化”向業(yè)務(wù)的再演進,是本輪數(shù)字化建設(shè)中的重要趨勢·零售多品牌集團型企業(yè):關(guān)注如何通過中臺建設(shè),實現(xiàn)集中管控前提下營銷能力在多品牌復(fù)用資管)場景的能力抽取與模式復(fù)用,實現(xiàn)對于OThoughtWorks,Inc.AlIRights中臺建設(shè)“不是”廣義軟件中臺建設(shè)“不是”廣義軟件對于企業(yè)業(yè)務(wù)模式端到端的ThoughtWorks1)如何抽離多業(yè)務(wù)線共享的解決方案和能力,集中管控和演進,以避免重復(fù)投資?新業(yè)務(wù)如何基于企業(yè)已有的解決方案和能力快速組裝上線,以支撐業(yè)務(wù)快速迭代ThoughtWorksOThoughtWorks,Inc.AIights2)如何合理地劃分IT系統(tǒng)邊界,以得到隨“需”而變的響應(yīng)力·如何組合應(yīng)用構(gòu)建塊成為合適粒度的獨立可部署單元,盡可能減少功能、運行層面的變3)如何適當(dāng)拆分過于集中的分析類數(shù)據(jù)處理職責(zé),以緩解規(guī)?;瘮?shù)據(jù)分析處理瓶頸?數(shù)據(jù)想要形成分析類價值,背后需要經(jīng)過攝取(Ingest)-加工(Process)-能力包裝(Serve)4)如何在富技術(shù)時代進行平臺型技術(shù)架構(gòu)選型及設(shè)計?ThoughtWorks1)以企業(yè)架構(gòu)框架方法進行業(yè)務(wù)平臺設(shè)2)經(jīng)典的框架更注重概念的完整性,工程實操性仍顯不足,且對業(yè)務(wù)平臺化的新問題均沒有特定的設(shè)計和考慮而從Moddling(建模)開始,到Process(流程),評定開始從M(中)轉(zhuǎn)向L(低),其中和落地的ThoughtWorksArtifactsTraceabilityNoation:H:highconsideratHLLLMHMHLLLMMMMLMLMMMLandcleardeseription;M:mediumconsiderationorlitledescription;L:lowconsid(圖1.3-2企業(yè)架構(gòu)框架對比)(參考文獻6)MMMLML這張表格出自2015年的一篇學(xué)術(shù)文章(參考文獻6),在這之后的5年時間里,各框架也均不同程以避免重復(fù)投資?新業(yè)務(wù)如何基于企業(yè)能力快ThoughtWorksOThoughtworksInc.ThoughtWorks260年代,截至目前已有接近六十年的發(fā)展歷程,法論工具,例如Zachman、TOGAF、DoDAF等,多注意力和資源聚焦于產(chǎn)品(系統(tǒng))架構(gòu)層面,關(guān)ThoughtWorks架構(gòu)這個概念源于建筑等其他行業(yè),隨著計算機行業(yè)的興起,這樣的概念也被引入到了信息技術(shù)行業(yè),用于IT系統(tǒng)的設(shè)計。在信息技術(shù)領(lǐng)域大體上主要分為兩個粒度,即:系統(tǒng)架構(gòu)也被稱為企業(yè)架構(gòu)規(guī)劃(enterprisearchitectureOThoughtWorks,InTypesofeaterprsearchitoctureframes(圖2.2-1企業(yè)架構(gòu)框架列表)(參考文獻10)業(yè)數(shù)字化發(fā)展的需求和新技術(shù)新趨勢,勇于跳出2.4現(xiàn)代企業(yè)架構(gòu)框架設(shè)計原則·戰(zhàn)略與業(yè)務(wù)價值驅(qū)動(業(yè)務(wù)驅(qū)動over技術(shù)驅(qū)動)則,無論是框架本身的設(shè)計還是應(yīng)用框架進行企業(yè)級的架構(gòu)規(guī)劃,都需要始終遵循此規(guī)則,使每一個架構(gòu)決策都能回溯到企業(yè)的戰(zhàn)略方向和業(yè)務(wù)ThoughtWorks本框架在設(shè)計過程中的所有元模型定義和方法建視角(viewpoint)和視圖(View):ThoughtWorks階段規(guī)范約束組織用展點思景原則模式?jīng)Q策體現(xiàn)了在一類視角(Viewpoint)下對其關(guān)注的架構(gòu)在現(xiàn)代企業(yè)架構(gòu)框架(MEAF)的設(shè)計上,我們最大化的延續(xù)和集成了經(jīng)典企業(yè)架構(gòu)框架對于視角 (Viewpoint)和視圖(View)的劃分,當(dāng)前版本下面就將根據(jù)不同的視圖(View)以元模型ThoughtWorksOThoughtWor3現(xiàn)代企業(yè)架構(gòu)框架—業(yè)務(wù)架構(gòu)3.1業(yè)務(wù)架構(gòu)元模型綜述業(yè)務(wù)架構(gòu)(BusinessArchitect所示:--=二=-=二=-----7『7------=二_5======『7———一3.2.1現(xiàn)代業(yè)務(wù)架構(gòu)典型問題3.2.2什么是可共享復(fù)用的能力?與服務(wù)的規(guī)劃成為企業(yè)級業(yè)務(wù)架構(gòu)規(guī)劃的關(guān)注要ThoughtWorksOThoughtworks,Inc.AlRiL于該模板快速定制某個具體業(yè)務(wù)的特定流程和能ThoughtWorksOThoughtWorks,Inc.AIRightsReserved.23解決方案:是平臺針對一類共性業(yè)務(wù)的端到端過程設(shè)計的能力模板;可基于該模板快速定制某個具體業(yè)務(wù)的特定能力和流程,從而達到業(yè)務(wù)模式級別復(fù)在業(yè)務(wù)梳理階段:對企業(yè)業(yè)務(wù)、流程、組織、業(yè)務(wù)服務(wù)和業(yè)務(wù)規(guī)則進行細致完整地梳理,作為后續(xù)模業(yè)務(wù)身份建模和能力建模4個步驟完成企業(yè)能力的業(yè)務(wù)業(yè)務(wù)組合管理業(yè)務(wù)群模式設(shè)計1流程建模業(yè)務(wù)服務(wù)4能力建模解決方案設(shè)計能力組件設(shè)計基礎(chǔ)能力設(shè)計23業(yè)務(wù)身份識別(圖3.2-3識別和構(gòu)建能力的過程)·領(lǐng)域建模:負(fù)責(zé)基于流程建模結(jié)果,識別領(lǐng)域事件和領(lǐng)域?qū)ο?,并劃分子域的邊界;領(lǐng)域?qū)ο髽?gòu)成了提供可復(fù)用能力的基本單元,對領(lǐng)域為了提取可復(fù)用的能力,首先需要識別共性業(yè)務(wù),然后將同一類共性的業(yè)務(wù)抽象提煉出通用流程,并階段活動任務(wù)步驟業(yè)務(wù)群規(guī)則提取共性業(yè)務(wù)步驟規(guī)則可變點規(guī)則通用流程自底向上逐層抽象提煉階段活動業(yè)務(wù)組合管理(圖3.2-4流程建模的總體實現(xiàn)機制)領(lǐng)域是指組織的業(yè)務(wù)范圍以及在其中所進行的活發(fā)送了某些消息目前比較常用的領(lǐng)域事件識別方法是“事件風(fēng)暴·邀請業(yè)務(wù)專家(或領(lǐng)域?qū)<?和技術(shù)專家共同·確定起始事件和結(jié)束事件,事件以“XXX已的哪個方向開始梳理事件(正向或逆向)。該事件真的需要在系統(tǒng)實現(xiàn)的時候考慮嗎?是?倉儲倉儲投訴訂單投訴庫存庫存庫存?zhèn)}儲3.2.3.2.2領(lǐng)域?qū)ο笞R別領(lǐng)域?qū)ο?,通常包?但不限于):的事物(例如訂單);ThoughtWorks域?qū)ο蟮姆诸?聚合根、實體、值對象)和戰(zhàn)術(shù)層域事件最相關(guān)(或隱含的)的業(yè)務(wù)概念,并將數(shù)量,單數(shù)還是集合)上的一致性,通過重命商品商品商品庫存庫存商品庫存訂單已投訴已接受處理貨物已處理訂單已撤銷已創(chuàng)建(圖3.2-10子域的類型)異化競爭力,是整個業(yè)務(wù)的盈利來源和基石,如果核心域不存在那么整個業(yè)務(wù)就不能運作。對于核心和做嚴(yán)謹(jǐn)良好的設(shè)計。撐核心域運作的問題,其重要程度不如核心域,但具備強烈的個性化需求,難以在業(yè)內(nèi)找到現(xiàn)成的解決方案,需要專門的團隊定制開發(fā)。內(nèi)非常常見,所以很可能有現(xiàn)成的解決方案,通過購買或簡單修改的方式就可以使用。子域劃分的主要步驟如下:·根據(jù)“每一個問題子域負(fù)責(zé)解決一個有獨立業(yè)務(wù)價值的業(yè)務(wù)問題”的視角出發(fā),可以通過疑問句的方式來澄清和分析子域需要解決的業(yè)務(wù)問題,例如“如何進行庫存管理?(英文描述文以切割圖像的方式劃在一起,并以“XXX子域”的形式對每個子域進行命名?!じ鶕?jù)三種類型的子域定義,共同結(jié)合業(yè)務(wù)實際(或者參考設(shè)計思維中的電梯演講),確定每個子域的子域類型。子域劃分的示例如下:(支撐)(核心)貨(圖3.2-11子域劃分的示例)ThoughtWorks(圖3.2-12業(yè)務(wù)身份的組成部分)對象的屬性);這些領(lǐng)域?qū)ο蠹捌鋵傩杂脕矶x業(yè)屬性1“條件規(guī)則1000”“條件規(guī)則1 (例如=‘金卡會員’)”“條件規(guī)則1(例如<100天)”“條件規(guī)則2(例如=‘銀卡會員’)屬性1條件規(guī)則1(圖3.2-13業(yè)務(wù)身份解析機制)括領(lǐng)域?qū)ο蟮膶傩?。OThoughtWorks,Inc.AIRightsReserved.(圖3.2-14能力建模的過程順序)3.2.3.4.1基礎(chǔ)能力與擴展點設(shè)計驟”,確定其對應(yīng)的領(lǐng)域?qū)ο?注意,該領(lǐng)域·基礎(chǔ)能力的輸入與輸出建議對象化,以規(guī)范使用訂單履行ThoughtWorks從以上定義可以看出,解決方案的核心是對共性業(yè)務(wù)進行識別提取和對業(yè)務(wù)全部能力進行模板化ThoughtWorksOThoughtWorks,Inc.AIRightsReserved.34展模建模能力法參見前面所述。3.2.4如何復(fù)用能力,實現(xiàn)新業(yè)務(wù)快速上3.2.4.1多層級復(fù)用復(fù)用能力基礎(chǔ)能力多個能力消費者,主要下,多個渠道客戶端使用同一個服務(wù)端能力低能力復(fù)用能力組件基礎(chǔ)能力業(yè)務(wù)場景中的某一小要求適中,需要一定的擴展機制中復(fù)用能力組件基礎(chǔ)能力提供多個連續(xù)或關(guān)聯(lián)的能力,支持不同業(yè)務(wù)場景的多個能力消費者高,由于需要支持不同流程的差異化需求,必須有靈活的擴展機制高ThoughtWorksOThoughtworks,Inc.AlRig能力又能進一步組裝成更大粒度的可復(fù)用能力組-P-業(yè)務(wù)流程復(fù)用業(yè)務(wù)流程復(fù)用支撐基額力:是時a子操n,成一個上單-相的質(zhì),比0:創(chuàng)后單,am2A等.r-=-1-ThoughtWorksOThoughtWorksOThoughtWorks,Inc.AIkightsReserved.37新業(yè)務(wù)全流程新業(yè)務(wù)全流程能力組件擴展實現(xiàn)擴展實現(xiàn)擴展實現(xiàn)擴展實現(xiàn)能力組件新業(yè)務(wù)A能力組件XX擴展點能力組件(圖3.2-20復(fù)用解決方案快速定制新業(yè)務(wù))復(fù)用解決方案的主要步驟如下:認(rèn)擴展實現(xiàn)。·開發(fā)基礎(chǔ)能力的擴展實現(xiàn)。實現(xiàn)業(yè)務(wù)需求。平臺側(cè)新增開發(fā)任務(wù),修改或者新增基礎(chǔ)能力、能力組件和解決方案;然后應(yīng)用側(cè)按上述過程完成定制使用。3.3業(yè)務(wù)架構(gòu)元模型補充說明 一-一企業(yè)各主營業(yè)務(wù)和輔助業(yè)務(wù)的關(guān)系結(jié)構(gòu)及運作模業(yè)務(wù)業(yè)務(wù)組合管理場景:是面向用戶提供價值的端到端業(yè)務(wù)場景。規(guī)則4—應(yīng)用架構(gòu)ThoughtWorks●Thou包含多個.包含多個.使用實現(xiàn)4.2應(yīng)用架構(gòu)元模型應(yīng)用OThoughtWorks,Inc維度界內(nèi),變更計劃和所需資邊界內(nèi),集成、·變更實現(xiàn)難度高,質(zhì)量保障困難或耗時常伴隨著高成本的跨團隊溝通協(xié)調(diào)運行·受限于物理邊界,無法將·基礎(chǔ)設(shè)施升級、維度故障隔離在局部區(qū)域,因需調(diào)整應(yīng)用的容量,造成資源浪費降低整體性能時,不會產(chǎn)生理解和認(rèn)知上的歧義(二義性),限4.2.2.1應(yīng)用組建模OThoughtworks,Inc.AlR在結(jié)構(gòu)上,應(yīng)用組包含了多個應(yīng)用(物理邊界)。應(yīng)用組常常對應(yīng)到數(shù)字化產(chǎn)品級別,例如CRM系理應(yīng)用、客戶忠誠度管理應(yīng)用);在業(yè)界流行的按織兩部分成果的輸入。在從0到1的應(yīng)用架構(gòu)設(shè)計我們可依此快速建立一個兩級的應(yīng)用組,這個結(jié)構(gòu)并不精確,但足夠我們進行下一4.2.2.2應(yīng)用組件建模邊界),向下,就是代碼實現(xiàn)層面的結(jié)構(gòu)設(shè)計了。支撐某個流程或流程中的一段活動決策證據(jù)出專業(yè)意見周期,只負(fù)責(zé)加工給出·驗證:如發(fā)票是否逾期的客戶·計算:計價、導(dǎo)航路化的整合信息周期,只負(fù)責(zé)加工給出系統(tǒng)中的配置功能規(guī)則的開關(guān)化ThoughtWorksOThoughtWorks,In個<<應(yīng)用組件>一是盡可能避免依賴容易變化的組件。盡管可以定義契約,但容易變化的組件容易打破先前定義<<應(yīng)用組件>><<應(yīng)用組件>>……實現(xiàn)……》<<應(yīng)用組件>>結(jié)賬適配器<<應(yīng)用組件>>支付支付成功<<擴展點>>支付<<應(yīng)用組件>>4.2.2.3應(yīng)用建模另一種情況是某個應(yīng)用組件不能調(diào)整容量或者非常信息體統(tǒng),其生命周期一般只有6-12個月,且變4.2.2.5應(yīng)用服務(wù)與擴展點建模果在業(yè)務(wù)架構(gòu)采用了“能力建?!?見3.2.3.4能OThoughtWorks,Inc.AlR使用,當(dāng)付救后訂單放行的擴展點<應(yīng)用件>總結(jié)來說,應(yīng)用服務(wù)和擴展點是對邊界概念的加強,幫助我們理解跨邊界的交互。4.2.2.6邊界劃分結(jié)果和依據(jù)的可視化由若干個方框組成,代表一個應(yīng)用或應(yīng)用組件。由我們建議將邊界劃分的結(jié)果及過程依據(jù)保存下來并可以開放給授權(quán)人員訪問。這是因為我們常常見到這樣的問題:“新的功能應(yīng)該放在哪個應(yīng)用實現(xiàn)?”晰,職責(zé)模糊,或者是邊界劃分的結(jié)果及依據(jù)丟失了。常見的現(xiàn)象是我們看到一張張應(yīng)用架構(gòu)全景圖,解決這個問題的難點是如何簡練、清晰地描述應(yīng)用應(yīng)用組件增加職責(zé)描述是一個不錯的起點,但僅用文字描述可能存在歧義。我們建議通過建立應(yīng)用架構(gòu)與業(yè)務(wù)架構(gòu)、數(shù)據(jù)架構(gòu)的構(gòu)建塊映射來解決這個問題。ThoughtWorksOThoughtworks,Inc.AlRigh使用余使用實現(xiàn)/提供使用操作實現(xiàn)我們推薦為每個應(yīng)用組/應(yīng)用/應(yīng)用組件建立自己架構(gòu)的設(shè)計風(fēng)格產(chǎn)生變化),從而將技術(shù)變化隔離組件名稱試駕安排門檻驗證5—數(shù)據(jù)架構(gòu)數(shù)據(jù)架構(gòu)描述的是企業(yè)經(jīng)營過程中所需數(shù)據(jù)的結(jié)角(業(yè)務(wù)、應(yīng)用,數(shù)據(jù)、技術(shù)),而數(shù)據(jù)架構(gòu)是數(shù)數(shù)據(jù)服務(wù)數(shù)據(jù)服務(wù)實現(xiàn)了..數(shù)據(jù)組件使用了..技術(shù)服務(wù)應(yīng)用組件數(shù)據(jù)對象使用了...使用了..5.2數(shù)據(jù)架構(gòu)元模型應(yīng)用5.2.1平臺化趨勢對數(shù)據(jù)架構(gòu)提出的新挑戰(zhàn)ThoughtWorks用來評估業(yè)務(wù)運行表現(xiàn)(度量、分析、預(yù)測),或這個模式對于業(yè)務(wù)場景簡單的企業(yè)環(huán)境工作得不5.2.2如何適當(dāng)拆分過于集中的分析類數(shù)據(jù)處理職責(zé),緩解規(guī)模化瓶頸數(shù)據(jù)源數(shù)據(jù)應(yīng)用場景中心化的數(shù)據(jù)平臺ThoughtWorksOThoughtWorks,Inc.AIRightsReserved.54取(Ingest)-加工(Process)-能力包裝(Serve)5.2.2.1數(shù)據(jù)對象和數(shù)據(jù)組件建模據(jù)湖內(nèi)。般對應(yīng)數(shù)據(jù)流水線,其將數(shù)據(jù)對象作為加工的輸入<<運行數(shù)據(jù)對象>轉(zhuǎn)化以…作為輸入以..為輸出ThoughtWorksOThoug5.2.2.2數(shù)據(jù)服務(wù)建模發(fā)團隊負(fù)責(zé)相對簡單的度量分析也是可想象的空以使用了..使用了.以…為輸出實現(xiàn)了為輸出貼源層貼源代表緊靠數(shù)據(jù)源,某個業(yè)務(wù)場景自身的業(yè)務(wù)運營分析需求,其需要的絕大部分?jǐn)?shù)據(jù)原料就在支撐這個業(yè)務(wù)場景的應(yīng)用中,需求和實現(xiàn)相對穩(wěn)定。例如,銷售線索響應(yīng)的前置時間趨勢,其依賴的主要數(shù)據(jù)原料是銷售線索的跟進事件,它們就在銷售線衍生層在貼源層之上的是衍生層,這里的分析類場景需要整合多個數(shù)據(jù)源的數(shù)據(jù)原料,往往需要經(jīng)過多次中間處理,實現(xiàn)難度較高,并且需求和實現(xiàn)相對容易變化。例如,整合多個數(shù)據(jù)源的客戶行為數(shù)據(jù),為那么,將貼源層的度量分析工作交由負(fù)責(zé)該數(shù)據(jù)源的應(yīng)用開發(fā)團隊,可進一步使得專職大數(shù)據(jù)團隊可以集中精力承擔(dān)衍生層的工作,從而緩解規(guī)?;款i。這個舉措目前的瓶頸是專業(yè)知識和工具。因為即使是貼源層,我們?nèi)匀唤ㄗh按照運行類、分析類場景區(qū)分?jǐn)?shù)據(jù)集的建模方式,分析類數(shù)據(jù)集往往為了存儲時間相關(guān)的不可變事實,有更大的數(shù)據(jù)量,還是需要使用大數(shù)據(jù)技術(shù)棧來存儲和加工的。只是前者到后者的加工過程現(xiàn)在由同一個團隊負(fù)責(zé),減少跨所幸的是,在專業(yè)知識層面,貼源層的建模相對簡單,標(biāo)準(zhǔn)也容易對齊。而工具層面,對大數(shù)據(jù)基礎(chǔ)設(shè)施提出了更高的自助服務(wù)要求,如果企業(yè)選擇了云作為解決方案,主流云廠商都提供了托管的大數(shù)目前對于企業(yè)級數(shù)據(jù)架構(gòu)尤其是分析類場景的去的DataMesh(數(shù)據(jù)網(wǎng)格,參考文獻8)也逐漸被社區(qū)采納和實踐,我們在企業(yè)級數(shù)據(jù)架構(gòu)框架元模型上的設(shè)計也為企業(yè)響應(yīng)這樣的趨勢提供了基礎(chǔ)和彈性。分析預(yù)分析預(yù)(圖5.2-5貼源層與衍生層示例)—技術(shù)架構(gòu)等上層架構(gòu)設(shè)計意圖的開發(fā)實施方案的結(jié)構(gòu)化描架構(gòu)方案模型架構(gòu)方案模型OThoughtWorks,Inc.AllRights技術(shù)架構(gòu)元模型是對技術(shù)架構(gòu)組成要素的抽象建6.2技術(shù)架構(gòu)元模型應(yīng)用設(shè)計ThoughtWorks技術(shù)組件其他模型領(lǐng)域參考模型領(lǐng)域擴展模型業(yè)務(wù)、應(yīng)用、數(shù)據(jù)ThoughtWorksOThoughtwor架構(gòu)模式元模型技術(shù)策略模型技術(shù)策略模型愿景、原則、m文領(lǐng)域參考模型領(lǐng)域擴展模型沉淀技術(shù)經(jīng)驗(圖6.2-3技術(shù)架構(gòu)元模型的應(yīng)用)在架構(gòu)咨詢過程中,我們看到很多由不良架構(gòu)引發(fā)的問題現(xiàn)象,分析背后的核心因素時,都指向了一個關(guān)鍵原因,即缺少前期對架構(gòu)設(shè)計需求的系統(tǒng)性分析。當(dāng)技術(shù)團隊被問到為什么使用某種設(shè)計思路,為什么使用某種技術(shù)組件時,得到回答往往跟其自身的主觀經(jīng)驗有很大關(guān)系。這帶來的重要影響是架構(gòu)質(zhì)量與設(shè)計者經(jīng)驗密切相關(guān),而經(jīng)驗的傳遞成本很高,架構(gòu)決策過程中的信息基本都被丟棄,只留下架構(gòu)設(shè)計結(jié)果,導(dǎo)致架構(gòu)最終難以演進和迭代。因此我們在技術(shù)架構(gòu)元模型中增加了架構(gòu)模式元模型,引入模式分析的方法對架構(gòu)的設(shè)計過程進行建模。解讀。問題描述了架構(gòu)需求背后要解決的實際問題是什么,例如業(yè)務(wù)中臺中如何保證前臺獲得一致的服務(wù)等級承諾(SLA)。上下文描述了與問題相關(guān)的背景信息,例如問題產(chǎn)生的背景是什么,需要考慮什么樣約束條件,期望達到什么樣的效果等等。ThoughtWorksO多租戶架構(gòu)在業(yè)界有標(biāo)準(zhǔn)化的成熟模型可以參考,因此我們可以將其作為參考架構(gòu),再結(jié)合上下文中的需求背至此我們通過以上四個元模型元素描述了對架構(gòu)設(shè)計過程的建模,實際應(yīng)用中,每一個元素可以根據(jù)企業(yè)的架構(gòu)設(shè)計規(guī)范,建立對應(yīng)的參考模型(分類、圖示、描述)用以規(guī)范架構(gòu)過程的產(chǎn)出物標(biāo)準(zhǔn),這里暫不進行展開。設(shè)計意圖輸入影響因素輸入技術(shù)平臺題問題分析輸入技術(shù)服務(wù)上下文技術(shù)組件沉淀技術(shù)經(jīng)驗其他模型匹配最佳實踐模式7(圖6.2-5架構(gòu)方案模型)在復(fù)雜的平臺型技術(shù)架構(gòu)中,是否能夠?qū)軜?gòu)元素做準(zhǔn)確的識別和直觀的描述,直接影響架構(gòu)設(shè)計方案是否被易于理解、使用和管理。在現(xiàn)實世界中,結(jié)構(gòu)化是我們理解、記憶和描述復(fù)雜事物的最佳方式,我們希望將其應(yīng)用在架構(gòu)設(shè)計中來增強架構(gòu)的表現(xiàn)力,因此我們在設(shè)計時對元模型的主要考量因1.架構(gòu)元素的職責(zé)明確且易于理解2.架構(gòu)元素的職責(zé)之間相互正交相對于經(jīng)典技術(shù)架構(gòu)元素,我們?nèi)趸诉壿嫛⑽锢砩系姆诸?,使用帶有明確職責(zé)屬性的分類方式定義架構(gòu)元素,同時我們對元素的職責(zé)進行了符合平臺化特征的重新定義,最終組成輕量的結(jié)構(gòu)化的描述ThoughtWorks
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 小學(xué)語文三年級下冊單元測試卷
- 促進文化傳承保護承諾書9篇范文
- 土木工程測量數(shù)據(jù)記錄與管理方法
- 智慧家居節(jié)能環(huán)保承諾書8篇
- 瓦斯抽采管線路徑安裝標(biāo)準(zhǔn)規(guī)范
- Oracle EBS系統(tǒng)核心應(yīng)用教程
- 五年級科學(xué)晝夜變化教學(xué)反思
- 團隊溝通會議會議紀(jì)要內(nèi)容詳實版
- 2025年中學(xué)教師資格考試《綜合素質(zhì)》教育教學(xué)反思與試題解析與案例分析試卷
- 2025年醫(yī)保知識考試題庫及答案:醫(yī)保政策宣傳與政策試題卷
- 污水井鋼板樁支護施工及基坑土方開挖專項方案
- 急救知識試題+參考答案
- 酒店蔬菜供貨合同模板
- 【青松雪】幾何最值36問-解析版
- 《海底隧道技術(shù)講義》課件
- 心理健康講座(課件)-小學(xué)生心理健康
- MOOC 耕作學(xué)-沈陽農(nóng)業(yè)大學(xué) 中國大學(xué)慕課答案
- 《商業(yè)文化》課件-第3章 古代商賢及其商業(yè)文化
- 小兒結(jié)核病教案
- 奈雪的茶國際商業(yè)計劃書
- 我的家鄉(xiāng)滕州市宣傳簡介
評論
0/150
提交評論