久久久久久久久久久97_亚洲国产精品国自产拍久久_亚洲欧美激情另类_日本高清www免费视频_亚洲中文字幕一区二区_99久久精品国产色欲_欧美成人一二三区_久久久99精品_日韩高清免费av_久久久无码一区二区三区

　　中臺(tái)按消費(fèi)者（Consumer）調(diào)用的SLA來評(píng)價(jià)。比如一個(gè)模塊，在做之前，如何通過價(jià)值評(píng)價(jià)來決策做或者不做？

　　1、中臺(tái)本質(zhì)：企業(yè)架構(gòu)治理

　　盡管如今已經(jīng)步入了Microservices與Cloud Native階段了，但如果不是一家游戲類、照片類、音視頻類純數(shù)字化公司（據(jù)我觀察，這類公司是最早采用云計(jì)算技術(shù)的），我推崇還是搞清楚早期Microsoft的一篇架構(gòu)文檔中說明的三種架構(gòu)層次。為什么？就像早期熟悉云計(jì)算架構(gòu)必須看Amazon的技術(shù)白皮書一樣，作為企業(yè)服務(wù)領(lǐng)域的一哥，Microsoft的總結(jié)有極強(qiáng)的參考價(jià)值：

　　應(yīng)用架構(gòu)（Application Architecture），即系統(tǒng)技術(shù)架構(gòu)，通常表現(xiàn)為帶有數(shù)據(jù)庫(kù)的三層/多層技術(shù)架構(gòu)體系。

　　產(chǎn)品/項(xiàng)目架構(gòu)（Product/Project Architecture），后期又稱之為解決方案架構(gòu)（Solution Architecture），解決方案層與應(yīng)用層的區(qū)別在于，它是業(yè)務(wù)導(dǎo)向的，致力于提升應(yīng)用系統(tǒng)的業(yè)務(wù)質(zhì)量。

　　企業(yè)架構(gòu)（Enterprise Architechture），它其實(shí)是一個(gè)規(guī)劃過程，識(shí)別企業(yè)IT未來應(yīng)該達(dá)到的狀態(tài)，并實(shí)施一系列的計(jì)劃，使項(xiàng)目團(tuán)隊(duì)通過交付達(dá)成。

　　中臺(tái)如何應(yīng)對(duì)來自以用戶為中心的業(yè)務(wù)挑戰(zhàn)

　　以用戶為中心（Customer-centric）意味著向消費(fèi)驅(qū)動(dòng)的轉(zhuǎn)變。企業(yè)產(chǎn)品與服務(wù)的推出不再內(nèi)部可控，而是需要快速捕獲外部用戶的變化并響應(yīng)用戶的需求。曾經(jīng)有客戶問：業(yè)務(wù)部門一年復(fù)一年人員都沒有增長(zhǎng)，提需求的就是這些人，為啥我們的技術(shù)部門人員年年增長(zhǎng)還不能完成需求？原因就在于：提需求的人是沒有增長(zhǎng)，但提需求的節(jié)奏、頻率、變化都大大提升了。

　　2007年時(shí)還沒有Micoroservice架構(gòu)，后來由Netflix在整合移動(dòng)多屏及個(gè)性化時(shí)被實(shí)現(xiàn)。

　　中臺(tái)成功核心在于業(yè)務(wù)治理

　　Morgan在一篇文章《Adoption, rather than Architechure, is the high order bit for Architects》中指出，企業(yè)架構(gòu)最重要的是組織對(duì)齊。“對(duì)齊”是國(guó)內(nèi)某家企業(yè)跨部門溝通最愛用的詞，也充分體現(xiàn)了該企業(yè)強(qiáng)大的組織能力。

　　中臺(tái)與ESB的核心差異是什么？在于業(yè)務(wù)服務(wù)能力（Capability）的下沉。ESB是消息總線，解決系統(tǒng)異構(gòu)信息交換問題，而中臺(tái)集成的是各種服務(wù)提供方，解決業(yè)務(wù)能力共享的問題。中臺(tái)服務(wù)面向的顆粒度更細(xì)，更強(qiáng)調(diào)的是封裝完整的業(yè)務(wù)資源、邏輯和流程，每個(gè)服務(wù)有更強(qiáng)的自治性，而ESB的出現(xiàn)更單純地是為了解決系統(tǒng)層面的協(xié)作。比如說，早年企業(yè)針對(duì)銷售部門有一個(gè)訂單管理系統(tǒng)，后來針對(duì)售后部門又開發(fā)了一個(gè)服務(wù)管理系統(tǒng)，最后發(fā)現(xiàn)，售后需要回溯銷售合同的條款，一開始通過批量同步，還行；后面量大了，批量處理已經(jīng)延后了，就需要兩個(gè)系統(tǒng)更及時(shí)地同步。如果作為中臺(tái)架構(gòu)師，在業(yè)務(wù)資源識(shí)別時(shí)，最徹底的就是面向客戶建立全生命周期的產(chǎn)品管理服務(wù)體系。早期的共享信息數(shù)據(jù)（SID）模型就是這樣的架構(gòu)。

　　建設(shè)中臺(tái)或任何企業(yè)級(jí)中心化的系統(tǒng)，需要權(quán)衡的就是如何協(xié)調(diào)不同使用部門之間的利益點(diǎn)。比如說，某些部門不希望花費(fèi)過多精力在系統(tǒng)建設(shè)上，那么組織提供的共享資源就很有用處；而某些部門希望能夠快速響應(yīng)經(jīng)常變化、個(gè)性化的需求，那么組織級(jí)平臺(tái)就可能拖累他們的節(jié)奏；而還有一些部門根本就不想與其它系統(tǒng)有依賴，那這樣的共享服務(wù)對(duì)他們而言就沒有存在的必要。

　　中臺(tái)并不神秘，當(dāng)企業(yè)想建設(shè)中臺(tái)時(shí)，首先應(yīng)當(dāng)考慮的是，業(yè)務(wù)部門的需求究竟是什么，他們希望改進(jìn)什么方面？他們及涉及的利益相關(guān)者愿意為這個(gè)改進(jìn)作出多大業(yè)務(wù)上的對(duì)齊？誰能夠承擔(dān)企業(yè)架構(gòu)師的角色？很多架構(gòu)師其實(shí)只是一個(gè)高級(jí)程序員，并不具備權(quán)衡（Tradeoffs）的能力和魄力。否則，這不應(yīng)該成為中臺(tái)項(xiàng)目，更好的處理模式是在解決方案或應(yīng)用層面尋找優(yōu)化措施。

　　早期的Connected Services Framework，在許多國(guó)外大型機(jī)構(gòu)中演進(jìn)成為Shared Services架構(gòu)。

　　2、為什么你無法復(fù)制中臺(tái)？

　　阿里巴巴業(yè)務(wù)本身就是平臺(tái)型、開放型，但僅僅因?yàn)闃I(yè)務(wù)形態(tài)，也不足說明非平臺(tái)型公司不能建中臺(tái)，畢竟建成后效率更高啊。但企業(yè)需要意識(shí)到，阿里巴巴成功建設(shè)中臺(tái)，原因有兩點(diǎn)：第一，是對(duì)現(xiàn)有資源的整合而不是新建；第二，由內(nèi)部團(tuán)隊(duì)驅(qū)動(dòng)而不是外部公司承接。

　　可重用的資源

　　中臺(tái)普遍采用服務(wù)、API來集成提供業(yè)務(wù)能力，許多企業(yè)第一步就是欠缺的，沒有這些服務(wù)和API；通常我們說的“服務(wù)化”，意思是把現(xiàn)有的組件封裝為Web Service，以提供更強(qiáng)的復(fù)用能力，比如說，一個(gè)Java的組件，只有Java的程序能調(diào)用，但封裝為服務(wù)之后，PHP/Node.js/iOS/Android全都可以支持了，就極大地提升了后端程序的復(fù)用性。

　　但事實(shí)上去到企業(yè)一看，很多系統(tǒng)連組件邊界都不清晰，這個(gè)服務(wù)化，其實(shí)在幫助企業(yè)進(jìn)行應(yīng)用架構(gòu)（Application Architecture）層面的模塊化梳理。許多企業(yè)連模塊化都不想做，就要一步上中臺(tái)，怎么辦，請(qǐng)外部公司空降PPT畫大餅、做培訓(xùn)、倉(cāng)促上馬半成品，結(jié)果可想而知。

　　運(yùn)行維護(hù)和保障：你有工程能力來建設(shè)中臺(tái)嗎？

　　比如最簡(jiǎn)單的一個(gè)問題，中臺(tái)上一個(gè)服務(wù)有多個(gè)消費(fèi)者，如何進(jìn)行版本升級(jí)？?jī)?nèi)部組件如何做到灰度部署？如何回滾？事實(shí)是，關(guān)于服務(wù)要不要有版本編號(hào)，版本編號(hào)到底是不是一個(gè)值得采納的工程實(shí)踐，業(yè)界都還在踩坑、爭(zhēng)論。運(yùn)轉(zhuǎn)中的中臺(tái)，復(fù)雜度超過一般的系統(tǒng)運(yùn)行維護(hù)，沒有規(guī)范、沒有自動(dòng)化、沒有云平臺(tái)管理能力的企業(yè)，很難玩轉(zhuǎn)中臺(tái)。即使空降一個(gè)中臺(tái)系統(tǒng)，落后的管理方式也只能將高鐵按照大巴時(shí)刻發(fā)車。

　　3、如何穩(wěn)步走向服務(wù)化戰(zhàn)略

　　茅臺(tái)這張PPT問題在哪里？在于沒有給出路徑。

　　與“中臺(tái)”這個(gè)名詞相比，我們還是更喜歡使用面向服務(wù)的戰(zhàn)略來表述以用戶為中心的未來IT架構(gòu)轉(zhuǎn)變。

　　用戶驅(qū)動(dòng) 顯性化中臺(tái)業(yè)務(wù)價(jià)值

　　更個(gè)性化、更快地響應(yīng)最終用戶的請(qǐng)求，尤其是外部用戶的請(qǐng)求，應(yīng)該是中臺(tái)構(gòu)建的業(yè)務(wù)價(jià)值目標(biāo)。如果中臺(tái)僅僅是優(yōu)化內(nèi)部業(yè)務(wù)，由于業(yè)務(wù)價(jià)值不明確，或難于衡量，將可能導(dǎo)致不及預(yù)期、難于協(xié)調(diào)一致多個(gè)部門，所以由外部用戶感知的業(yè)務(wù)價(jià)值驅(qū)動(dòng)，更能有效地落地業(yè)務(wù)資源與流程的整合。

　　比如說，利用用戶旅程分析工具，將過去用戶需要面對(duì)多個(gè)業(yè)務(wù)人員的流程優(yōu)化為一項(xiàng)自助式服務(wù)，并支持在移動(dòng)端、PC端和終端多處完成。定義用戶服務(wù)請(qǐng)求的監(jiān)控指標(biāo)改進(jìn)，包括業(yè)務(wù)處理時(shí)間、業(yè)務(wù)流量、交易量，等，即決定了此項(xiàng)優(yōu)化的業(yè)務(wù)價(jià)值。

　　團(tuán)隊(duì)自治 構(gòu)建高效面向業(yè)務(wù)服務(wù)的基層文化

　　如果你的團(tuán)隊(duì)并不能真正理解服務(wù)化/中臺(tái)的好處，如此龐大的工程不可能真正落地。因?yàn)橹行幕南到y(tǒng)建設(shè)涉及的范圍太廣了，一條規(guī)范不能被正確執(zhí)行，都會(huì)留下后期調(diào)用的隱患。

　　讓過去涉及到多個(gè)業(yè)務(wù)協(xié)作的系統(tǒng)團(tuán)隊(duì)進(jìn)行合作，設(shè)計(jì)出新的解決方案，讓他們直接面向業(yè)務(wù)部門收集的反饋，或用戶使用的行為指標(biāo)、報(bào)告作出響應(yīng)。

　　如果發(fā)現(xiàn)在這個(gè)團(tuán)隊(duì)中，他們依然還需要依賴第三方的人、系統(tǒng)來解決問題，那么自治式還不夠好，需要進(jìn)一步解除依賴。雖然這在許多金融機(jī)構(gòu)聽起來不太可能，但如果這些問題都解決不了，誰又能真正承諾最終交付的中臺(tái)服務(wù)能夠高效響應(yīng)呢？

　　服務(wù)管理 一步步加強(qiáng)中心團(tuán)隊(duì)治理能力

　　隨著服務(wù)越來越多，需要有專門的服務(wù)管理團(tuán)隊(duì)，接手服務(wù)基礎(chǔ)設(shè)施、目錄，并完善監(jiān)控和運(yùn)營(yíng)治理。可以為服務(wù)管理團(tuán)隊(duì)設(shè)立服務(wù)規(guī)劃部門，一步一步為企業(yè)的服務(wù)化/中臺(tái)戰(zhàn)略進(jìn)行未來狀態(tài)的導(dǎo)引。

　　總結(jié)

　　中臺(tái)不是一個(gè)新事物，也并不神秘。重視中臺(tái)，說明中國(guó)的企業(yè)開始意識(shí)到企業(yè)架構(gòu)帶來的巨大能效優(yōu)勢(shì)，供我們制定更加合理的轉(zhuǎn)型提速節(jié)奏。