優秀的制造企業，一定有一個先進的DT架構
2018-06-05 來源： 評論：0摘要：數字化轉型已經成為傳統企業的必然選擇。隨之而來的業務場景、用戶習慣和行為在迅速變化，許多傳統行業線上業務出現急速增長。
數字化轉型已經成為傳統企業的必然選擇。隨之而來的業務場景、用戶習慣和行為在迅速變化，許多傳統行業線上業務出現急速增長。
金融行業的移動支付、互聯網理財等，汽車制造行業的營銷、電商、售后服務等線上業務比例迅速提高。IT團隊業務開發、迭代都以每月、甚至每周來計，需要7*24小時響應，這些給系統開發和運維帶來極大挑戰。
傳統行業對于IT效率的變革需求以及業務模式的創新導致系統更新頻繁，應用復雜度也急劇上升，傳統架構不堪重負。因此，架構轉型成為了一些企業數字化過程中的最大難點。
近期，為了準備雪浪大會，鈦媒體記者走訪調研了近200家制造企業，深入一線去了解他們的真實痛點。
調研結果顯示，在系統支撐方面，排在前四的難題分別為：系統復雜性越來越高、運維管理復雜度高；打造一支全棧運維團隊困難；線上訪問壓力大；設備采購維護成本高。
ThoughtWorks是一家技術類咨詢公司。這家公司長期致力于從全球不同的區域，服務于不同的客戶，在不同的業務模式下面做不同的項目。成功的案例包括德國戴姆勒公司的營銷、電商、售后服務如何由消費者主導實現數字化在線、美國視頻網站Netflix的系統架構演進式發展等。
通過全球項目經驗的積累和實踐， ThoughtWorks總監級咨詢師Neal Ford提出演進式架構的概念，將“可演進性”作為新的架構特征加入到系統中，讓它在系統演進時為其他特征（比如上文提到的業務需求、性能、安全性、可擴展性等）提供保護。這便是演進式架構，它使我們可以兼顧多個架構維度進行引導式的增量變更。
不久前，Neal Ford帶著新書《Building EvolutionaryArchitectures: Support Constant Change》來到中國進行宣講。鈦媒體記者借此機會與Neal Ford進行了深度交流，為企業傳統架構的迭代升級提供一種新的思考方式。
NealFord帶著新書《Building Evolutionary Architectures: Support Constant Change》以及他的新的Idea“演進式架構”在QCon大會演講
01在不破壞原有IT架構的前提下進行“演進”
在傳統企業軟件開發流程中，經常需要面臨改動，有來自用戶需求的改動，有來自市場的改動以及為了一些潛在機會而產生的改動等。
這些改動要求企業能夠快速做出調整。但不幸的是，事情并不總是如我們所愿。
這是因為企業的業務應用經過多年IT建設，系統非常龐大，難以更改。例如企業傳統SAP、汽車制造企業里傳統DMS以及MES等，要改動其中任何一小部分，都需要重新部署整個應用。敏捷開發和快速交付更無從談起。
另外，傳統企業在長期的IT建設過程中，通常大量使用外包團隊，這導致采用的技術棧之間差異較大，統一管控和運維要求更高。需要運維7*24小時全天候值守、在線升級，并快速響應。
而在此時脫穎而出的微服務架構，讓傳統企業眼前一亮，它具備諸多優勢，例如獨立開發、獨立部署、獨立發布，去中心化管理，支持高并發高可用，支持豐富技術棧，企業可以根據需要靈活技術選型。
NealFord認為，微服務是支持演進行為的眾多架構之一。
“微服務是后DevOps革命時代出現的第一種全新架構風格。它是第一個全面擁抱持續交付的工程實踐，也是演進式架構家族的一員。演進式架構以支持增量的、非破壞的變更作為第一原則，同時支持在應用程序結構層面的多維度變化。不過，微服務僅僅是支持某些演進行為的眾多架構之一。”
而演進式架構則在微服務架構基礎上增加了兩點思考——既要滿足企業應用的真實場景，還要符合技術的演進。
首先，創建演進式架構，應當滿足企業應用的真實場景。
這也回答了我們文章的問題——為什么演進式架構被譽為最好的迭代模式？因為這種架構不會破壞原有傳統軟件包，而是將傳統IT架構演進到微服務架構上。
NealFord在《演進式架構》中也提到，“對于一個大的軟件包，一個大的單體的應用，如果做微服務轉型，肯定不是把這個大的單體應用直接干掉不要，建一個新的微服務平臺出來，而更傾向于一種做法，即我怎么能夠從SAP、DMS這樣一個傳統軟件包的模式， 一步步的把它演進到一個微服務架構上，這是演進式架構要解決的一個重要問題”。
原本對傳統企業來講，SAP、DMS以及MES這類傳統軟件包等本身是封閉的，企業購買這樣的軟件包最大的一個出發點是來降低自己的IT成本去實現IT能力。但是在數字化轉型的大趨勢下，創新又成為企業最主要的訴求。
ThoughtWorks從技術的角度出發，認為更應該照顧企業真實的應用場景，定制化地開發軟件，或者說，從定制化的軟件平臺下開發出獨特的業務模型。
同時，演進式架構符合技術的演進。
NealFord認為，微服務本身是一種架構的模式或者是一種架構的風格，而這種架構風格正好是演進式架構的一些原則和實踐的最佳體現。“比如業界經常做微服務轉型的時候會說，微服務本身的力度或者微服務本身的范圍應該是什么樣的，而我認為演進式架構可以幫助企業將一個微服務的架構在力度的層面、在整個架構體系上能夠不斷地去演進。”
NealFord向鈦媒體表示，這種技術演進方向有兩個：“第一個方向是這種增量式的演進，讓系統能夠做到增量式的演進或者增量式的變更，而這本身作為演進式架構定義中的第一個維度，它是天生要解決這個問題。
第二個方向，它叫做指引式的演進或者向導式的演進，向導式的演進就是說我在一個系統里面希望能夠提升它的性能，我怎么能向著我們想要的性能方面去演進，所以它定義了一個適應度函數（fitness function），通過適應度函數可以幫助我們的架構的開發人員明確地認知我現在想要的這個方向是不是我現在架構所演進的方向，是不是我想要的方向，然后它可量化地告訴我的開發者，我離現在這個目標到底還有多遠，它是這樣一種模式。所以面對企業不斷增加的應用需求，它天生可以解決企業增量式、迭代式開發的一種訴求。”
然而，微服務也不可避免地表現出它的劣勢——它會帶來系統的各種復雜度、運維要求更高等諸多難點。對于團隊來說，搭建微服務架構上手難，運維效率低，運維成本高。
另外，創建微服務還可能帶來團隊之間溝通上的沖突——微服務需要與DevOps（Development&Operations）同步推進。當微服務被分割成一個個獨立的業務模塊后，服務間通信接口設計非常重要。如何科學地將系統部署到服務器上，保證各個服務高效運行，更是難點。
02演進式架構符合傳統企業轉型需求
“當我們談演進式架構的時候，其實是有很多不同的原則。這些原則都很嚴格，而微服務某種程度上展現出了一些演進式架構的原則。例如我們在談微服務的時候，主要是想用它來快速應對頻繁的需求變更，因此微服務所承載的期望便是讓我們能盡可能快的適應變化，演進式架構中所倡導的進化性與此不謀而合。”
NealFord補充道，關于可進化性存在一個理解誤區——開發者要非常聰明的想到所有可能出現的變化，并且為所有的這些可能的變化寫好代碼，哪怕到頭來根本就沒變。但其實，可進化性并不同于可維護性，“不是說要怎么預測未來，而是一種隨時準備響應變化的狀態，而不管你是否提前就設想好了這些變化。”
在今天來看，其實演進式架構本身是有一定基礎的，當企業想采用演進式架構這種模式的時候，需要以敏捷的開發模型、敏捷的開發方式、持續交付的開發基礎設施或者是持續交付的開發實踐以及DevOps的實踐來作為整個架構的基礎。如果企業沒有這樣的基礎，實際上是很難做到演進式架構的，而演進式架構本身它也是要求在整個企業開發的流程和模型上需要敏捷、持續交付，要去做DevOps。
據Neal Ford介紹，目前在業界采用演進式架構企業不僅有美國視頻網站Netflix公司，還有很多ThoughtWorks參與或者是合作的公司都在采用演進式架構中的一些實踐。只不過在這之前并沒有把它定義成演進式架構或者是適應度函數，而是把它定義成fitness function。
而在這些傳統企業中，很多企業是通過持續交付流水線，通過對于架構、對于測試體系的一些追求，對于架構本身的轉型，一直在實踐著演進式架構的模式。因為它們恰恰滿足了演進式架構的一些特點，例如：
第一是模塊化和耦合。邊界劃分明確的組件，顯然可以給希望做出非破壞性變更的開發人員以更大的便利。而毫無架構元素的混亂架構就無法做到演進式變更，因為它缺少模塊化。另外不適當的耦合將變更導向難以預料的方向，從而阻礙演化。而演進式架構都支持一定程度的模塊化，這種模塊化通常體現在技術架構層面（例如經典的分層架構）。
第二是圍繞業務能力組織。現在越來越多的成功架構都以在領域架構層的模塊化為特色。基于服務的架構與傳統的SOA主要區別在于模塊劃分的策略，SOA是嚴格按照技術層進行模塊劃分，而基于服務的架構則傾向于按業務領域劃分。
第三是試驗。試驗是演進式架構給商業交付帶來的最大價值之一。從操作角度來講，可以采用A/B測試等常見的持續交付實踐對應用進行低成本的、微小的變更。微服務架構常常是圍繞服務之間的路由來定義應用程序的。通常微服務架構圍繞服務之間的路由來定義應用程序，允許同一個服務的多個版本同時運行。這反過來也使得試驗和現有功能的逐步替換成為可能。最終，這使得企業業務可以花更少的時間去猜測待辦故事項，從而投入到假設驅動開發中。
而在國內，通過鈦媒體記者近期的走訪發現，大部分傳統企業架構還不能實現敏捷開發、持續交付等，要實現數字化轉型，首先就需要對企業傳統架構做轉型。
NealFord表示，對于企業傳統架構的轉型，首先要把企業自己基礎的工程實踐能夠搭建起來，使原來采購軟件包的模式能夠向新的模式做轉型。
“比如說在持續交付層面，如果一個企業不是在做持續交付的轉型，那企業在做精益企業（或數字化）轉型的時候，第一步要做的事情就是要有一個持續集成的轉型，把自動化的基礎設施能夠搭起來。這是基礎能力，不僅僅是向演進式架構轉變，更企業在做數字化轉型時必備的一些能力。”
03大數據、AI技術都將被引入演進式架構
“目前在演進式架構中已經引入了很多AI的實踐，比如說在一些企業里面會用TensorFlow去寫一個框架，幫助他去分析在網絡傳輸這一層里面，從安全的角度是不是有一些模式可以被快速地發現，有一些安全的點或者是有一些安全的攻擊的行為是不是可以從網絡傳輸這一層來用AI來做分析和發現。它也希望未來可以通過把目前AI技術應用所處的層面逐漸往上提，提到不同服務之間傳輸信息的層面上、是不是可以利用AI找到這樣的模式，能夠幫助我們企業識別出來我的安全風險。” Neal Ford認為，在當下最時髦的AI技術，在未來可能會被更多地引入演進式架構中，加入到整個企業架構適應度函數的設計，或者是在架構演進的過程中利用AI的能力做更多的事情。
“同樣對于大數據大數據或者是數據型的項目，演進式架構中可以應用在一些場景中。比如說演進式架構里面去定義企業最關注的適應度函數、最關注的架構設計要素。而每一個要素都可以通過適應度函數把它定義下來，我認為每個架構應該有自己非常獨特的或者是特定的適應度函數，或者是這種架構規則的新的定義，就好像我們寫unittest和寫functional test是一樣的。因為你是根據某一個項目去寫的，而不會把這個項目的規則直接搬到另一個項目上去。”
無論是傳統架構還是演進式架構，系統本身在市場上是有競爭者的。Neal Ford也坦率地說，如果是利用這個系統直接去賺錢的企業或者是組織，這樣的企業會首先采用演進式架構的模式。而往往一個企業當它先開始采用演進式架構這種模式的時候，這種架構一開始對企業的影響并沒有那么大。“只是簡單的在企業流水線上布一個適應度函數或者是布一個架構檢查的腳本，其實就已經在采用演進式架構當中的實踐了，但是顯然這種實踐對于人和組織來講并沒有什么太大的改變。”
“但是如果企業想充分發揮演進式架構帶來的好處，那對于整個團隊的組織結構肯定是要發生一些變化。比如說企業的組織結構應該能夠更好地支撐業務的敏捷性轉型、企業的組織結構應該更好地降低我在團隊不同成員之間的波動，我能夠讓團隊是一個相對比較穩定的團隊。同時我的團隊能夠支撐DevOps這樣一些實踐的追求或者應用。”
這就像1967年康威提出的“康威定律”， 企業需要關注怎么組織團隊結構，以及不同的團隊結構可能影響到最終的系統形態。只有團隊對服務有很好的所有權意識，團隊做出來的微服務才是這種松耦合的獨立服務。康威定律在1967年被提出來，但是真正被業界采納其實是在近幾年有了微服務以后，團隊才開始采用康威定律。“所以說這件事情相對來看會有一個比較長的周期。其實在業界已經有了這樣一些原則在那里了，但是真正的被企業界所應用還是需要一定時間的。“Neal Ford表示。
相關熱詞搜索：數字化 制造業
相關文章
- ·國家數字化設計與制造創新聯盟成立2018-03-30
- ·企業把握“數字中國”的六種方式2018-04-03
- ·劉九如：必須在卡脖子的地方下大功夫2018-06-15
- ·重磅！國家數字化設計與制造創新中心落戶武漢2018-09-05
- ·如何以數字化變革推動我國制造業高質量發展？2018-10-24
評論排行
- ·AM先進制造業·高端沙龍(4)
- ·2016（第四屆）先進制造...(0)
- ·洪杰：航空發動機面臨競...(0)
- ·2017（第五屆）先進制造業大會(0)
