高老師的架構設計_雋語集(CC_1051)

時間 2019-12-14

原文原文鏈接

前言：從"Essence"(本質)這個字看物聯網的思惟侷限。天下物本質上就是多樣化的，IOT想把天下物組合於網絡上，是加法設計，物物通訊的多樣化也是本質性的，也只能加法、不能減法。英文的Essence是不可或缺之意；過分要求通訊統一(減法)會傷害物物通訊的本質(不可或缺的多樣化)；因此另尋他途作減法設計。html

我認爲，數字家庭裏的設備"模塊化"原本就是正確的方向。模塊化是作"分"的動做，是一種廠商的減法設計。問題是：對於家庭主人而言，如合將多個簡化的東東組"合"起來呢? 這是加法問題了。因而家庭主人須要有效的減法設計來支撐這個煩人的加法問題。因而，許多人又回到"訂定通訊標準"的烏托邦減法思路了。 git

本書原因：高煥堂於2013年在日本退休以前，基於日本師徒制的要求而傳承給下一代架構師的架構思考技術(俗稱設計心法)。25年來他專精於A段(投資決策前)架構設計，退休閒暇將之寫成中文，歡迎你們指教。程序員

歡迎訪問 =>高老師的ADT技術論壇安全

高煥堂：MISOO(大數據.大思考)聯盟.臺北中心和東京(日本)分社.總教練微信

ee ee網絡

<<看上一集-------看下一集>>架構

[#1051]許多人認爲架構設計要基於用戶的需求(Requirements)，然而當用戶需求不穩定而多變時，又該如何下手作設計呢? 答案是：以問題(Problem)和願景(Vision)爲出發點，"設計"出初期架構(Simple Solution)，展開敏捷迭代過程。在願景指引下，探索複雜謎題(問題)，而減法設計出"簡單"的Solution。框架

[#1052]通常人看到專利，第一個反應是想避開它。專利發明人都是聰明人，卻不善長說服別人避開不如合做，由於不善長於以戰術引導戰略(專利創意)。一項戰略性的專利，若是搭配其戰術的發明，就很是有說服力了，專利就價值連城了，如LED燈的發明專利。less

[#1053]@讓您成爲傑出架構師#敏捷頂層設計方法# 爲何敏捷開發團隊會很依賴架構設計呢? 由於敏捷認爲需求是善變的，不宜走過去Waterfall方法的Requirement-based途徑。需求是測試的基礎，不是代碼開發的基礎。http://t.cn/8Fo3z3r

[#1054]專利是戰略資源，一方面用來阻礙對手的戰略資源的調度，來阻止對手戰術的獲利性。專利能夠聚集己方的資源，讓己方會贏的戰術獲利極大化。可是，有聰明人發明戰略資源，卻沒發明配套的戰術；沒有可獲利戰術搭配，戰略可能只是掛在牆壁上的口號而已。

[#1055]<過程(Process)：基於敏捷開發(Agile Development)原則>此方法的頂層設計過程是基於當今最流行的敏捷(Agile)開發原則。以敏捷的測試來帶動設計團隊進行迭代(Iterative)過程。以測試結果的反饋(Feedback)激發各參與人員(Stakeholder)的反思、討論與重構設計，讓頂層設計止於至善。

[#1056]<決策分析(Decision Analysis)：基於AHP方法>採用經常與EA框架配的AHP決策分析方法，來評估頂層設計裏的重要決策。以確設計決策的<最佳性>。

[#1057]<需求檢驗(Requirement Test)：基於TDD方法> 以敏捷的<測試驅動開發>(TDD, Test-Driven Development)來帶動整個設計團隊進行迭代過程。這迭代過程，會不斷重構頂層設計，來知足用戶的功能性需求。

[#1058]因而，架構(&Vision)成爲代碼開發的起點(Simple solution)。這個起點就是一個起始架構，來自架構師的設計。

[#1061]《設計大變革》有兩個甚至在規劃專業界也默認接受可是極其錯誤的觀念：一是規劃要具有前瞻性甚至有的提出要預判超前十年二十年，那都是胡扯的意淫。連當下的完整信息數據都沒有，還想去判斷若干年後各類狀況，連今天城市人口信息狀況都不瞭解還要去判斷將來變化無窮的城市人口生活生存狀態，實是空想。

[#1062]@讓您成爲傑出架構師#架構師的反思練習# A段架構師思考技術的造成途徑有二：1)本身實踐時的思惟、視角與反思；2)學習別人的設計思惟。傑出與平凡之間的差異就在因而否培養本身的思考邏輯和知識體系。更多新思惟：http://t.cn/8FbhmdD

[#1063]平臺(操做系統)是轎子，無限(線)感知、雲計算、大數據都是轎子的配件，甚至互聯網、通訊機制都是(轎子的)配件；但是有許多人認爲"互聯網"或"雲平臺"是轎子! 觀點不同呀!!

[#1064]@讓您成爲傑出架構師#架構師的反思練習# <<互聯網是中心嗎?>> 自從2009年4月，我在北京舉辦第一屆"亞太Android技術大會"，就鼓吹國人要推行Android，但要採起"挾天子以令諸侯"策略，陪育各行業的強龍，我稱之小強龍；深耕軟硬結合，軟件人員不宜只作App。更多新思惟：http://t.cn/8FbhmdD

[#1065]自從我在北京舉辦第一屆"亞太Android技術大會"(2009)，當時就已經發現幾乎全部國人都把互聯網視爲平臺(Platform)，全力開發互聯網插件(如物聯網、雲計算、海量數據等)。而沒有換個視角：其實互聯網也是一個插件而已。例如重新娘花轎來看，道路(互聯網)只是花轎的配件而已。彷佛沒人想過要上去坐轎子。

[#1066]我認爲是你們把通訊層級的互聯網視爲平臺(Platform)的緣故；而忽略了軟件層級的真正平臺。君不見，當今的物聯網產業仍然是典型的互聯網是核心、是平臺、是轎子的觀點，其實互聯網只是真實轎子的一項配件而已。觀點決定策略、策略決定行爲、行爲決定結果。

[#1067]@讓您成爲傑出架構師#架構師的反思練習# <<互聯網是中心嗎?>> 咱們只想作雲和端，洋人作平臺。雲端和終端都是插件(Plugin)，Android是平臺(Platform)。插件只是配角，平臺是主角。作雲和端只是<利用>互聯網；作平臺是<控制>互聯網。利用互聯網省錢；控制互聯網花錢。更多新思惟：http://t.cn/8FbhmdD

[#1068]#互聯網只是配件，不是平臺# 我認爲是你們把通訊層級的互聯網視爲平臺(Platform)的緣故；而忽略了軟件層級的真正平臺。君不見，當今的物聯網產業仍然是典型的互聯網是核心、是平臺、是轎子的觀點，其實互聯網只是真實轎子的一項配件而已。觀點決定策略、策略決定行爲、行爲決定結果。

[#1069]把通訊層級的互聯網視爲平臺(Platform)，<利用>互聯網來賣配件(如RFID)，當小弟。重視軟件層級的真正平臺，則<控制>互聯網，當家做主。

[#1070]工信部電信研究院稱：Android佔國內86.4%市場份額，我國移動操做系統研發對 Android 存在嚴重路徑依賴。1）核心技術和路線受到谷歌嚴格的控制，並時刻面臨谷歌的商業歧視，2）我國移動操做系統起點低、起步晚、3）谷歌已經造成龐大的生態系統了，4）知識產權受制於外人。

[#1071]回覆電視空移: 中國字：<容易>就是要包容改變，事情纔會容易。易就改變，通訊層是底層，最爲善變，必須用軟件來包容它，纔會容易。可是，太多人都想把萬事萬物掛到互聯網(如物聯網)。甚至把軟件掛在善變的互聯網上，就危如累卵、永無寧日了；產業也沒法成長茁壯了。電視空移:這個分析精典。

[#1072]我一直都百思不解：爲何你們都看到道路(通訊層的互聯網)，而沒看到上層轎子(軟件層平臺)；更沒看到轎裏的新娘子；這樣怎能娶到老婆呢?

[#1073]@讓您成爲傑出架構師#架構師的反思練習# <<互聯網是中心嗎?>> 應該要反思本身爲何被 "互聯網思惟" 綁架了10多年，還在爲綁架者說情，反過來責怪Android。反思本身爲何一直注視道路地面(底層的網絡平臺)，不離開地面，又如何上轎(上層軟件平臺)當新娘子呢? 更多新思惟：http://t.cn/8FbhmdD

[#1074]懂得注視道路(通訊層的互聯網)的人是轎伕；懂得注視上層轎子(軟件層平臺)和轎內新娘子的人，是新郎倌。

[#1075]<<不滿國內移動操做系統現狀:嚴重依賴安卓>> 國人務實，喜歡<看得見模得着>的底層通訊平臺架構(互聯網)，洋人務虛，喜歡<看不見模不着>的上層軟件平臺架構(Android)。是喜歡不喜歡的問題，不是能不能的問題；也不是時機的問題，有爲者亦如果。

[#1076]只有底層網絡平臺，是不夠的；還要軟件平臺，並且軟件平臺控制網絡平臺，而不是將軟件切分爲兩塊，分別掛在網絡平臺的兩端：終端與雲端。善於處理雲端大數據，也是善於推磨的樸人；而不是享福的員外。

[#1077]@讓您成爲傑出架構師#架構師的反思練習# <<互聯網是中心嗎?>>你們都知道：想找出迷宮遊戲的路徑，從出口反向尋找是最有效的，<逆向思惟>是支撐有效<減法設計>的必備心理條件。正推思惟沒法簡化迷霧，加法設計又迷上迷，可能掉入深淵而不自知。更多新思惟：http://t.cn/8FbhmdD

[#1078]國人思惟的嚴重誤區：互聯網是平臺，軟件是平臺的插件。因而，軟件被切分爲終端軟件與雲端軟件；分別插掛在互聯網的兩端。而Google公司的軟件平臺(含Android)正好橫跨&控制整個互聯網；國人的軟件變成Google軟件平臺的兩端插件；淪爲洋人的附庸!!

[#1079]我一直百思不解：咱們學打算盤，利用了算盤，終究會想拋棄算盤；武林大俠楚留香練劍，終究也把劍拋掉了，練成彈指神功。反觀，國人利用互聯網10多年，早就該拋調"互聯網是中心"的古老思惟，才能理解Android控制全局的前因後果。至今，絕大多數人對互聯網的信仰和膜拜，已經失去反思一下的動力了。

[#1080]要說服國人去拋棄<互聯網是中心>的信仰；可能比數百年前，哥白尼說服人們放棄<地球是宇宙中心>，還要困難多了。由於心中的宇宙就是互聯網，心想Android只是一顆彗星而已，不值得重視。回憶2007年我在西班牙巴賽羅訥市上班，一見到Android即將上市，不久就辭掉工做回來海峽兩岸大力鼓吹Android。

[#1081]回覆傻瓜阿狸: 懂得離開轎伕的角色，變成乘轎者，才真正懂轎子(互聯網)。 //傻瓜阿狸:用戶比程序員更懂互聯網? //高煥堂:懂得注視道路(通訊層的互聯網)的人是轎伕；懂得注視上層轎子(軟件層平臺)和轎內新娘子的人，是新郎倌。

[#1082]懂得拋棄算盤的人才真正懂珠算；懂的拋棄劍，如楚留香者，才真正懂劍。懂得非戰者，纔是善戰者。還持有"互聯網是中心"思惟者，可能都還不是真的懂互聯網!!

[#1083]從底層通訊網路而觀之，互聯網是中心。國人基於這樣的思惟，5年後會又一次受制於洋人，由於國人擅長<正推思惟>和<加法設計>；洋人則擅長<逆推思惟>和<減法設計>。例如，高速雲計算、海量數據、無限(線)感知等。國人應該靜下心來反思本身的<固>有思惟，省得5年後長嘆技不如人。

[#1084]#好文章推薦# <三星已經意識到，下一個重要領域在於軟件。> <將來硬件和軟件將進一步整合> 軟件是上層平臺，互聯網是下層平臺。http://t.cn/zYnTTdJ

[#1085]@讓您成爲傑出架構師#頂層設計&減法設計# 軟件平臺就像集裝箱(Container)，將複雜的通訊網絡、硬件接口、內容格式等包裝起來，呈現出簡單外形，讓人們感到這些事物的可愛、好玩好摸好抱。並無刪除外在事物(如冰箱等)的複雜。而只消除人們心中的複雜感受，達到簡化目的。更多新思惟：http://t.cn/8FbhmdD

[#1086]在智慧化潮流中，軟件會陸續進入家庭中，那麼咱們如何看待這個Smart潮流呢? 軟件會讓家庭複雜化? 仍是簡化呢? 相似的問題也曾出現於手機智能化的初期階段，結果人們選擇了"以軟件簡化了的複雜手機"，而不是"簡陋的手機"。這項歷史，提示了什麼?

[#1087]排斥家庭設備的太多智能化，是想維持身外物(如TV)的簡陋易用；歡迎家庭設備的智能化，是想透過軟件創造身內(心中)的簡單感受，但維護身外物(如TV)的多樣化和生命活力。

[#1088]軟件平臺與網絡平臺是兩的層級，網絡平臺是以互聯網爲中心，雲端和終端各掛在互聯網的兩端；二者都是互聯網平臺的插件。軟件平臺則想辦法讓互聯網被包容起來，成爲軟件平臺的插件；這是爲何三網融合可能幫三個軟件平臺擡轎的原故。

[#1089]今天的 <軟件+家庭> 相似於 20年前的 <軟件+企業>；遙想當年的企業(尤爲是辦公室)多少IT豪傑逐鹿中原(企業辦公室)，但終究歸於MS-Office的一統天下。以古鑑今，以互聯網爲平臺的網絡層級思惟，可能也將臣服於Family的"MS-Office"的軟件平臺思惟之下。

[#1090]在穿戴式移動設備上爲成爲IT產業的主戰場以前，<家庭>這個熟悉的主戰場(IT業的墳場)還是兵家必爭之地。如何創建<軟件平臺+互聯網平臺>的雙層平臺，將是贏家必備的系統架構設計。其中成敗的關鍵思惟是：不能將軟件切分爲端與雲兩塊，且當成網絡平臺的插件；這樣家庭就成爲插件了。

[#1091]@讓您成爲傑出架構師#頂層設計&減法設計# 開放智能家庭的標準軟件接口，與當今的新興移動互聯網應用業務(如微信、Line等)緊密銜接，讓數字家庭擺脫過去的被動接收信息，改變爲主動推送信息到家人、小區等。以移動互聯網對接的需求帶動本產業的總體發展。更多新思惟：http://t.cn/8FbhmdD

[#1092]數字家庭(Digital Family)與智能家庭(Smart Family)有何區別呢? 前者偏於物，後者偏於人。家庭裏的人是什麼角色? 是數字內容的消費者(被喂之內容和信息的對象)，或者在既定範圍內有一點點選擇內容的權力，或者能與這個互動、創意和作夢呢?

[#1093]以行業型軟件平臺，弭補現有中間件的不足。在與智能城市的其它行業(如醫療保健、公共交通等)對接過程當中，將各行業的專業知識歸入行業型軟件平臺。基於行業型軟件平臺來提供總體性的服務跟蹤。

[#1094]以行業型軟件平臺，往下整合大小硬件及通訊設備，促進主硬件搭配小硬件的營銷模式；往上大力支撐第三方應用開發廠商；往水平方向，與智能城市的其它行業(如醫療保健、公共交通等)緊密對接、互聯互通。

[#1095]創建<雲端、家庭、移動(手機、車載)>三層組合的新型產品及服務模式。例如，讓股票分析師、外語老師能在家裏的智能電視裏，執行他本身的應用軟件，從家外的股票雲平臺取得股票數據，在家裏分析以後，從智能電視將分析建議信息推送到手機的微信畫面上。

[#1096]<雲端、家庭、移動(手機、車載)>三層組合的新型產品及服務模式。強力支持股票分析師、中醫師等師字輩的智能型人物，在最溫暖、最熟悉的客廳裏跑本身的Android App，產生本身的智能數據，推送到本身的學生，獲取收入。這是智能電視(家庭)的美好服務和商機。

[#1097]<雲端、家庭、移動(手機、車載)>三層組合的新型產品及服務模式。在本身的家裏，跑本身的App，處理本身的數據，作本身的飯，泡本身的茶，服務本身的online客戶。乃人生一大樂事也。

[#1098]【智能城市的<頂層設計>並非<上層設計>】頂層設計應該是指：Top-level Design 。其偏於投資決策前的A段架構設計階段，作爲城市政府立項投資決策的評估依據；而Bottom-level Design則偏於決策後的B段架構設計階段。<頂層設計>並非<上層設計>(Top-layer design)。請參閱文章：http://t.cn/8FQwifc

[#1099]面對全世界最巨大&複雜、又必須持續將來發展的中國智慧城鎮規劃，惟有力求減法設計纔能有效包容複雜多變。"敏捷"作過程的減法；而"詩同形"是作架構的減法。你們都知道，惟有簡單，才能消除懼怕，纔能有勇氣理解複雜、迎接將來。

[#1100]@讓您成爲傑出架構師#加法設計：無限創新# 有了願景和架構的指引，讓人們的思考連結到更多的未知(Unknown)新事物。基於減法設計，讓人們更有勇氣面對複雜。透過迭代和反饋的去蕪存菁，讓人們更具備信心去經營將來、捕捉新機會。所以，激發出更多的新型商業模式和策略。更多新思惟：http://t.cn/8FbhmdD

[#1101]我國古代秦國的"書同文、車同軌"都是在作減法設計，才能整合幅員遼闊的中國。這相似如今IT產業每天談論的"標準"。然而，通常人很容易誤解，標準又分爲"形式"標準與"內涵"標準；並且是相對的。例如，秦國"書同文、車同軌"與唐代的"詩同形"相比，前者較偏內涵，後者偏形式。

[#1102]爲何頂層架構設計須要減法思惟呢? 由於架構就是一個容器(Container)，業務麪包容人們慾望的複雜多變，軟硬件上包容技術創新的多變。架構要力求減法設計，像集裝箱同樣簡單，又包容複雜的天下萬務。惟有簡單架構，才能面對大數據的將來。

[#1103]<<產業垂直整合，來支撐產品減法設計>> 「十年之前的正統觀念是，那樣的垂直整合已是盛景再也不。」手機行業諮詢公司Alekstra分析師特洛•庫伊蒂寧（Tero Kuittinen）說道。「而後的結果是，只有兩家公司（三星和蘋果）進行了垂直整合，隨後就接管了整個手機行業。

[#1104]達芬奇說：簡單是複雜的終極形式(Simplicity is the ultimate form of sophistication) —Leonardo da Vinci。

[#1105]三星的減法設計：Samsung’s Designer said: "Remove instead of add, as most beautiful things in life is simple."

[#1106]減法；Don’t just remove to remove. Remove the unessential through thoughtful reduction. (不要爲減法而減法。充分運用減法思惟去審視以後，將非本質性的功能刪除。)

[#1107]你們都知道，架構至少分爲兩層：業務架構和系統架構。其中，業務架構須要創新，因此偏向加法設計思惟；而系統架構要承上啓下，像樹幹同樣，偏向於減法設計思惟。試想，10年前紅極一時SOA架構，將二者抽象成爲單一的Service觀點，業務層受到限制(受限於網絡思惟)，推行起來常遇到阻力。

[#1108]@讓您成爲傑出架構師#頂層設計&減法設計# 智慧城市頂層設計必須作減法設計，才能支撐大數據加法問題頂層設計的「設計」一詞原本就要減法，從複雜中找出簡單，才能面對複雜。更多新思惟：http://t.cn/8FbhmdD

[#1109]高煥堂老師所提出的頂層設計方法論。適用於智慧城市、數字家庭，以及大型SoS系統設計，例如公共交通、旅遊休閒、醫療健康等不一樣業務區塊的頂層設計；並促進不一樣業務區塊或系統之間的互聯互通、信息共享、並避免信息孤島。

[#1110]架構設計不只要適應將來的變化，並且要讓企業、組織、產品或系統在將來多變的需求趨勢、時尚空間裏取得市場的競爭話語權。頂層設計團隊的職責是致力於如今決策，並讓它能包容將來的變化，也就是讓<目前決策>具備將來性。

[#1111]規劃一個智慧城市的美好將來，須要進行許許多多的如今決策。如何確保如今決策的將來性呢? 除了頂層設計團隊的新視野、好眼光和洞悉力以外；還能夠藉重更多專家來協助客觀地評估各類設計方案或將來的投資計劃。如此，讓智慧城市達到高度創新、又客觀可靠的美好境界。

[#1112]當咱們相信目前決策會影響一個城市的將來發展軌跡時，頂層設計團隊不斷在尋覓多條行得通的途徑，而後透過能量化的客觀性分析，讓各界專家們共同關注和投入，一塊兒評選出<最具備將來性>的途徑，作爲一個城市的將來投資和發展藍圖。

[#1113]#架構設計思惟練習# 攸關係統設計質量的人員有：老闆、設計團隊、外界的專家、用戶。老闆提供願景、設計團隊提出架構、外界專家提供決策評覈準則、用戶提供需求測試。這些安排，可參考高煥堂老師的架構設計方法。

[#1114]惟有減法設計才能持續支撐加法設計；單獨加法設計很容易超越人們的管控能力；複雜的本質將引入失控的臨界點。

[#1115]AHP是一項很是著名的決策分析工具；並且是最常與頂層設計EA框架相互搭配的。例如，如何確知某個設計或投資方案適合於該智慧城市呢? 就可用AHP來評估這項適用性。AHP是個頗有趣又頗有用的東西，它提供一個有效的方法去進行復雜的決策，不管在通常生活、商業或學術研究上，有很精采應用。

[#1116]@讓您成爲傑出架構師#智慧城市的敏捷頂層設計# 微軟公司常用AHP來評選軟件開發項目，作爲投資的決策依據，不知國內軟件公司有人使用AHP來評估?更多新思惟：http://t.cn/8FbhmdD

[#1117]頂層設計並非要開發一個全新的大型軟件系統；而是釐清ToBe架構與現有系統(As-is)架構之間的落差；這項落差就是將來投資的標的。因此頂層設計是攸關如今的決策，要決定將來城市投資的目標。頂層設計是要支持投資決策；而不是去支持建置一個大型IT系統。

[#1118]因爲頂層設計是要支持投資決策；而不是去支持建置一個大型IT系統。因此頂層設計經常會使用AHP層次分析法來評選最佳的投資方案。

[#1119]頂層設計偏於決策前的工做，來讓現今決策能具備將來性。實踐層設計是決策後(決定投資)的工做。因爲時間的切割，使得實踐層設計&開發階段的"敏捷"跌代機制沒法覆蓋到頂層設計。那麼，又如何能讓敏捷的TDD能用來檢驗頂層設計的"可實現性"呢? 基於這項理由，我提出了"中層設計"階段；來解決此問題。

[#1120]AHP用來確保頂層設計的"最佳性"；而中層的TDD用來確保頂層設計的"(信息化)可實現性"。因而，依循個人模式，可確保能規劃出：具備可實現性的最佳解決"頂層設計"。

[#1121]"中層設計"是軟件層，用意在於使用軟件開發的TDD(Test-Driven Development)分法來檢驗頂層設計裏的"接口"部分，爲互聯互通作優先的測試；提高頂層設計的可"落地"性。

[#1122]因而，我首創了一個新的層級：中層設計。這個<中層設計>是行業型軟件接口定義層，用意在於使用軟件開發的TDD(Test-Driven Development)分法來檢驗頂層設計裏的<接口>部分，爲互聯互通作優先的測試；提高頂層設計的可落地性。

[#1123]在頂層設計階段，依循敏捷途徑，以測試驅動引導出持續地反饋與迭代的中層設計(即軟件接口開發)過程。經由敏捷TDD機制來執行接口軟件，實際檢測信息交換的所需的軟硬結合設備，以及相關通訊機制。產出計算機可執行的軟件接口控制代碼，就是中層設計的做品了。

[#1124]來自軟件行業的敏捷開發，讓軟件開發團隊變敏捷了。我則讓智慧城市的頂層設計團隊變敏捷了。那麼，如何將敏捷價值觀擴大到各行各業呢? 例如，讓廚房裏的廚師團隊出菜工做變得敏捷呢?

[#1125]我百思不解，爲何有些物聯網領域的人士，將感知端(Sensor端)和雲端二者當作掛在互聯網兩端的模塊。好像一條河流的兩岸是掛在河流的兩邊。若是換個視角，在河流兩岸各創建一個橋墩，而後拉一座吊橋跨越河流，景象就不同了，河流可能就從心中被抽象掉了。物聯網人士彷佛能夠換換觀點，才能以簡馭繁。

[#1126]@讓您成爲傑出架構師#智慧城市的敏捷頂層設計# 敏捷軟件開發須要擴大到數字家庭或智慧城市頂層設計的決策；數字家庭或智慧城市頂層架構設計須要更具備敏捷性。二者相輔相成。更多新思惟：http://t.cn/8FbhmdD

[#1127]目前智慧城市的規劃大可能是從物聯網角度去思考，可是物聯網領域的人士彷佛都崇尚作"加法"，無線(限)感知、擴大寬帶、海量數據儲存。卻不過重視隨着信息化、智能化潮流，只靠"加法"是無解的。在互聯網平臺上再創建一個軟件平臺來封裝互聯網，作"減法"才行。太過於"物"實，只會把智慧城市搞得複雜難解。

[#1128]#頂層設計# 是什麼? 不是什麼? 頂層設計是要支持投資決策；而不是去支持建置一個大型IT系統。頂層設計關注的是「互通「(Inter-operationality)；而不是穩定、可靠、不變的「共通性「(Commonality)。因此頂層設計不是去設計<中間件>(Middleware)。

[#1129]#頂層設計# 是什麼? 不是什麼? 智慧城市的頂層設計並不是徹底是<由上而下＞(Top-Down)進行的；而是＜從中間往上＞(Middle-Up)的。我建議採用AHP決策分析法來確保頂層設計的<最佳性>

[#1130]#頂層設計# 是什麼? 不是什麼? 我首創了一個新的層級：中層設計。這個<中層設計>是行業型軟件接口定義層，用意在於使用軟件開發的TDD分法來檢驗頂層設計裏的<接口>部分，爲互聯互通作優先的測試；提高頂層設計的<可實現性>。

[#1131]我提出了智慧城市頂層設計框架："一個造形、一個模式、加一層設計"。"一個造形、一個模式、加一層設計"就是：一個EIT軟件造形、一個MCS系統(軟硬結合)模式、加上中層設計。

[#1132]一個模式：例如醫院體系就是一個HMCS模式，Hospital + Mobile + Cloud + Sensor 四個元素所組合而成的SoS(System of systems)。

[#1133]智能城市的各業務區塊深度依賴信息化系統來互聯互通，因此各區塊採用企業架構(Enterprise Architecture，簡稱EA)的系統框架方法來呈現其信息化系統架構，成爲其區塊頂層設計的核心，是一種有效的途徑。

[#1134]一開始感受現有視角、觀念和模式並沒有法克服將來複雜而多變的系統(如智慧城市)；而直覺隱隱約約告訴我有個更好的視角、能夠反思來驅逐舊觀點；就是到了該閉關時刻了。新視角帶來新觀念，歸入新元素來重構新模式。閉關只不過如此而已，沒什麼神祕的。

[#1135]敏捷架構設計與EA(Enterprise Architecture)架構設計結合起來，發揮敏捷的神韻。我稱之爲：敏捷EA。敏捷思惟和過程的適用性，並不侷限於軟件行業範疇而已，也適用於各行業的規劃、設計、開發與建置等團隊合做活動；包括數字家庭、智慧城市的頂層設計和中層設計。

[#1136]敏捷思惟的核心是：以跌代(Iterative)過程帶動反饋；以反饋促進溝通(與合做)。這項思惟很是適合於頂層設計，持續地帶動城市的創新和將來發展性。基於這種思惟層面的一致性，也就很容易將敏捷原則與EA(Enterprise Architecture)框架相互結合起來，讓智慧城市的設計更具敏捷性和將來性。

[#1137]#敏捷架構設計# 因爲智慧城市頂層和中層設計都必須具有將來性，此時敏捷思惟裏的迭代、反饋與溝通(合做)，都是城市設計過程當中必須具有的<敏捷性>。敏捷頂層架構設計與敏捷實踐開發，實際上是能夠分階段，而且能無縫隙組合的(如附圖)。如此，讓更多軟件行業以外的專家們能參與敏捷過程，促進更多溝通。

‘

[#1138]@讓您成爲傑出架構師#智慧城市的敏捷頂層設計# 若是能將敏捷原則應用到智慧城市的頂層設計和中層設計，更能將城市智能化過程當中的合做參與人員，擴大到市政規劃和決策層。將對將來智慧城市實施階段的<敏捷軟件開發>項目的順暢與成功是很是有幫助的。更多新思惟：http://t.cn/8FbhmdD

[#1139]因爲智慧城市設計是攸關將來的規劃，而將來新情境下的各項需求，只是規劃決策中的將來可能事實，而不是現實需求。因爲這種規劃段需求與決策的相互依偎關係，使得頂層架構設計須要更大的敏捷性，其過程也須要更多迭代性和人員的溝通(合做)性。因而，將傳統軟件開發的敏捷思惟和原則擴大到智慧城市的頂層

[#1140]朱少民老師的評語：高老師的「思路有創新，也符合敏捷思想，先造成基礎，根據目標不斷迭代，直至勝利。」意味着，架構設計也能夠更敏捷，敏捷開發的迭代產出也能夠是架構藍圖，不必定侷限於代碼。您認爲呢? 十多年前，我已經是Kent Beck的粉絲，信奉其價值觀如Feedback is priceless。

[#1141]敏捷開發過程的主要概念是：1)最簡方案(Simplest solutions); 2) 迭代過程(Iterative process); 3)重構(Re-factoring); 4) 持續整合(Continuous integration)。其中的最簡方案，看似簡單倒是最難把握。在個人<<高煥堂的架構設計心法三部曲>>裏，說明起來既抽象、哲學又美學。

[#1142]軟件代碼、IT產品、人員等都是智能城市的重要元素。只有軟件代碼和軟件開發團隊敏捷起來，彷佛還不夠；若是城市頂層架構設計和架構師們都敏捷起來；是否是將來的城市纔會更青春活潑(敏捷)呢?

[#1143]#架構設計&頂層設計# 從<業務架構層>到<系統架構層>的減法設計。此時採起<xMCS系統模式>來協助減法設計，讓業務架構層面的變幻無窮面貌下，能取得系統設計層面」書同文」，基於共同的概念和術語(如<M>、<C>和<S>等元素種類名稱)，來減化複雜性，提高系統的互通性。

[#1144]@讓您成爲傑出架構師#架構設計&頂層設計# 頂層設計常見迷思是：沒有釐清"互通性"與"共同性"的微妙差異。通常人經常誤認爲創建共同性(如創建共同平臺)，是實現"互通性"的有效手段；其實否則。由於，城市裏各區塊已經有了各自系統或平臺了，已經沒有機會從新創建一個新的共同平臺了。更多新思惟：http://t.cn/8FbhmdD

[#1145]#架構設計&頂層設計# 從<系統架構層>到<中層設計>的減法設計。此時採起<EIT軟件造形>來協助減法設計，讓系統架構裏的互通接口規範部分，能落實微軟件代碼，並取得軟件接口設計上的」詩同形」，就像唐詩三百首同樣，據有共同的造形(Form)，卻能包容無限意境的詩人心靈感觸。

[#1146]在進行頂層設計時，最多見的迷思是：沒有釐清"互通性"與"共同性"的微妙差異。通常人經常誤認爲創建共同性(如創建共同平臺)，是實現"互通性"的有效手段；其實否則。由於，城市裏各區塊已經有了各自系統或平臺了，已經沒有機會從新創建一個新的共同平臺了。所以，創建共同性來實踐互通性，每每並不可行。

[#1147]@讓您成爲傑出架構師#架構設計&頂層設計# 頂層設計常見迷思是：沒有釐清"互通性"與"共同性"的微妙差異。通常人經常誤認爲創建共同性(如創建共同平臺)，是實現"互通性"的有效手段；其實否則。由於，城市裏各區塊已經有了各自系統或平臺了，已經沒有機會從新創建一個新的共同平臺了。更多新思惟：http://t.cn/8FbhmdD

[#1148]#架構設計&頂層設計# 在智慧城市的任何一個業務區塊，在其業務架構(Operational View)層面，都有本身的商業模式、獲利策略、業務功能、以及產品或服務等。可是，在幕後的系統架構(System View)裏，任何系統幾乎均可以歸類到3項元素之一，這3項元素就是：Cloud, Mobile和Sensor。

[#1149]"互通性"的英文是Inter-Operationality，直翻是"互操做性"是IT人員熟悉的。可是在智能城市領域裏，其頂層設計主要任務是：互聯互通、信息共享和避免信息孤島，因此我採用"互通性"，以便凸顯出這是頂層設計階段的議題，而不是下層IT系統建置階段才考慮的議題。

[#1150]#架構設計&頂層設計#<<架構(Architecture)：基於EA和SoS原理>> 此方法是基於企業架構(EA, Enterprise Architecture)框架和SoS(System of System)的原理而設計出來的。其設計文件包括願景敘述、業務架構、系統架構和中層(架構)設計。更多新思惟：http://t.cn/8FbhmdD

[#1151]@讓您成爲傑出架構師<目標：互聯互通、信息共享、避免信息孤島> 由高煥堂提出的頂層設計方法。適用於智能城市的各業務區塊(Business Area)設計，例如數字家庭、公共交通、旅遊休閒、醫療健康等業務區塊的頂層設計；並促進不一樣區塊、系統之間的<互聯互通和信息共享>，以免產生信息孤島。更多新思惟：http://t.cn/8FbhmdD

[#1152]#架構設計&頂層設計# 智慧城市的範疇跨越了許多不一樣的業務區塊(Business Area)、產業技術和專業知識，又深度依賴信息化技術。因爲，各業務區塊或產業(如數字家庭、醫療服務、公共交通、食品安全等)的信息化應用視角和深度並不盡相同，因此各業務區塊(或產業)各有其獨特視角的頂層設計來呈現其特殊需求

[#1153]智慧城市的頂層設計並不是徹底是<由上而下＞(Top-Down)進行的；而是＜從中間往上＞(Middle-Up)的。其步驟是：1)各業務區塊先分頭進行頂層設計。2)將各份頂層設計藍圖，呈交市政府。3)市政府覈對其可能重複投資的部分；以及違背互聯互通的部分；而後展開協調和修正。5)合併成爲智慧城市頂層設計藍圖了。

[#1154]@讓您成爲傑出架構師#架構設計&頂層設計# 要建造一個智慧城市，誰都知道要切分紅許多塊。切分爲多個區塊，只是爲了分而治之而已，並無其它用意。不一樣區塊，攸關不一樣專業知識或能力，一般由不一樣的人員或業務單位(Business Unit，簡稱BU)來擔任或執行有關的業務功能(Business Function)。更多新思惟：http://t.cn/8FbhmdD

[#1155]智能城市的各業務區塊深度依賴信息化系統來互聯互通，因此各區塊採用企業架構(Enterprise Architecture，簡稱EA)的系統框架方法來呈現其信息化系統架構，成爲其區塊頂層設計的核心，是一種有效的途徑。

[#1156]<是否能夠top-mid-top的次序>。"top-mid-top次序" 和 "mid-top-mid-top"都同樣，只是出發點差一步而已。只要不是一直停留在top或mid就是了。這也是我把敏捷開發價值觀延伸到上層設計的理由之一。

[#1157]針對各業務區塊而進行各自的頂層設計。這些區塊性頂層設計只是手段，其目的是要產出各自的藍圖，而後匯合、審覈、協調而融合成一個總體的智慧城市頂層設計藍圖。一旦總體城市的頂層設計出爐了，就能回頭來修正各業務區塊的頂層設計，讓各區塊頂層設計都不要違背城是頂層設計。

[#1158]因爲智慧城市的許多業務區塊(Business Area)必需要互聯互通。而數字家庭是其中的一個區塊；所以數字家庭裏的開放型行業軟件接口變得很是重要。不能只依賴通訊層級的通用性(不分行業)技術接口來解決複雜問題了。

[#1159]依具EA(Enterprise Architecture)框架(如MoDAF)的原則，從專業知識最集中的位置出發是最適當的。例如，城市公共交通，專業知識密集於公交車BU ，就從它出發；只是其起點，即便方向不盡然正確，反正會往上(UP)再返回修正；往上UP時會把最新專業知識帶上去，實現<戰術引導戰略>.

[#1160]要建造一個智慧城市，誰都知道要切分紅許多塊。理由是：切分爲許多區塊部分(Part)，分而治之，是合理的作法。可是如何確保城市的總體(Whole)和諧狀態呢? 其中，最基本的要求就是：這些區塊部分之間要分工合做，也就是互聯互通(Inter-Operationality)，避免掉入一個城市卻到處是信息孤島的窘境。

[#1161]<治而分之，分是手段，治是目的。> yes, 把各Part治理好以外，還要確保Whole的總體和諧，這是頂層設計的主要目的。

[#1162]@讓您成爲傑出架構師#架構設計迷思# 頂層設計關注的是"互通"(Inter-operationality)；而不是穩定、可靠、不變的"共通性"(Commonality)。更多新思惟：http://t.cn/8FbhmdD

[#1163]回覆AgileCoach:爲了啓下，每每須要對上"循循善誘"用心引導(如同相夫教子)一番，如同古代的"承相"，除了"承"以外，還要"相"一番。這就是我一直提到的：有效架構師都擅於"以精湛的戰術引導戰略"。

[#1164]在古代，國家的頂層設計都是"承(丞)相"所作的事；現在在城市規劃上，架構師也扮演丞相的角色(可參閱柳宗元寫的 <<梓人撰>>)。其中的"相"字並非對下屬的命令；而是對上的"循循善誘"。就如同好妻子要能 "相夫教子"；相是對丈夫(上)，教是對孩子(下)。因此，架構師須要"以戰術引導戰略"。

[#1165]<<頂層設計並非共同部分>>智慧城市涵蓋不一樣的業務區塊，例如數字家庭、醫療服務、公共交通、食品安全等。各業務區塊各有其獨特性的頂層設計來呈現其優點及特點。就像咱們經常看到不一樣的建築物各有不一樣的總體設計，例如學校、四合院、教堂、醫院、倉庫等都各有其頂層設計(即總體設計)。

[#1166]頂層設計關注的是"互通性"；而不是"共通性"。因此接口(Interface)的規範是核心；頂層業務接口，加上中層的軟件接口，來包容底層互聯網&通訊協議和技術的多變，則是頂層&中層設計的重心。

[#1167]因爲頂層設計關注的是"互通性"；而不是"共通性"。過去的Requirement-based架構設計途徑，從需求或企業流程中；抽象出穩定不變的共通結構的傳統思惟，並不適用。"追求不變，以不變來應變"的傳統思惟，並沒有法創造城市的將來性。

[#1168]頂層設計的內容就涵蓋了：目前決策、將來投資和To-be架構。那麼，咱們又如何選擇最好的決策、評估最好的投資、實踐最美好城市呢? 除了頂層設計人員的主觀評估以外，咱們還須要仰賴定量、定性的分析方法和工具來協助評選出最好的設計決策和投資方案。

[#1169]<這又是個雞蛋問題，究竟是先有雞仍是有蛋？市場一直都在，關鍵你是否作出來好東西。> 沒錯，別忘了，經常作出了最好的補老鼠器，老鼠也滿街跑；但是沒有上街埔老鼠的"門票"，你又如何回收投資呢?

[#1170]@讓您成爲傑出架構師回復智慧無限黃清華:<互聯網發展神速，就是有統一的標準。沒有統一標準，咱們桌面上要有10幾個瀏覽器去瀏覽不一樣的網站。物聯網這個行業目前泡沫很嚴重... > 沒有上層的行業性軟件接口來支撐頂層商業模式，只有互聯網通訊層標準，而無商業模式，是很是不務實的。更多新思惟：http://t.cn/8Fo3HIo

[#1171]我常百思不解：許多人堅持"物聯網就是把物掛在互聯網的標準接口上"的簡單概念，而排斥更多的軟件層和業務層設計；沒有上層的行業性軟件接口來支撐頂層商業模式，只有互聯網通訊層標準，怎能找到商業模式和獲利策略呢?

[#1172]著名軟件專家Fred Brooks(「人月神話」一書做者)在40年前就說道：」軟件的複雜性是本質性的，並不是表象而已。」(The complexity of software is an essential property, not an accidental one.)

[#1173]@讓您成爲傑出架構師#架構設計迷思# EIT造形的主要用途是：提高內在能力、管理外在變化和複雜。當咱們心懷EIT單純造形去看待Android系統框架時，也會發現其單一造形所創造出來的總體之美。原來，複雜外貌來自於EIT造形的簡單組合。更多新思惟：http://t.cn/8Fo3HIo

[#1174]於十七世紀中，牛頓提出了簡單公式(即造形)：F=ma；讓人們能輕易理解物體運動的複雜<關係>。於二十世紀初，愛因斯坦發表了簡單公式：E=MC平方；讓人們能理解複雜的質量、能量與光速之間的複雜關係。簡單的」EIT」軟件造形；則讓人們能理解Android多層框架體系裏的複雜關係。

[#1175]簡單的」EIT」軟件造形；則讓人們能理解Android多層框架體系裏的複雜關係。有了架構設計造形的<簡單性>，人們就很容易理解軟件的複雜關係，進而提高了掌握軟件系統複雜多變的能力，惟有熟諳此道，才能創造架構和產品的<將來性>。

[#1176]從複雜設計出簡單，從簡單理解複雜；複雜與簡單彼此息息相關，在其交錯變化韻律中，抓住將來意想不到的機會。

[#1177]<跨平臺>是擺脫問題的糾纏，<軟硬結合>是邁向目標的雄心，<測試>是創意與限制的心心相印(Creativity loves constraints)。沒有EIT造形的簡單，咱們就沒法理解上述三者的複雜。

[#1178]著名專家Fred Brooks(<<人月神話>>一書做者)在40年前就說道：「軟件的複雜性是本質性的，並不是表象而已。」並不是全部的本質都是簡單的。那麼，咱們該如何面對本質性的複雜呢? 答案是：設計出簡單之形(form)，提高咱們處理複雜本質的能力。

[#1179]道有簡單的目地：和諧；也有它的複雜的行爲：恆變。簡單和複雜都是道的本質(Essence)。道有其複雜本質，就必須尋覓或設計出簡單的理論(形式)，讓人們能透過簡單的理去<理解>其本質性的複雜。因此你們就稱爲之<道理>。

[#1180]@讓您成爲傑出架構師#架構設計迷思# 萬一性的假設，讓你在迷霧遍及的原野中，能沉着冷靜，隨時預備有意外情況出現，多是機會，也多是陷阱。更多新思惟：http://t.cn/8Fo3HIo

[#1181]道的本質是和諧與恆變。這項本質對人而言，是複雜的；只能用心去領悟感覺，感官沒法把握，語言也沒法描述。那麼，人們就設計出一個簡單造形(Form)，內含兩個元素：陰和陽。此造形表達出道的和諧與恆變的本質，通稱爲<太極>。

[#1182]萬一性假設的優勢是：預見失敗。有效架構師不會專一於避免失敗，而是認知到，沒有人是存心要失敗的，可是失敗是不免的。失敗是很可能的事，能洞悉本身和對手的失敗是架構師的職責，由於可以預見失敗，才能放眼將來。

[#1183]如此，培養你的瞬間洞察力(Flashes of Insight)，快速發現事實，作出有將來性的決策，既能擺脫疑雲糾纏，又能捕捉機會，繼續向前推動。

[#1184]機會是投手，設計是捕手。若是一件設計可以在將來捕捉到更多機會，表示其設計決策更具備將來性。本文介紹4項<假設性思惟>，協助你達成這個目標。你將能夠從複雜中，領悟(設計)出簡單，讓簡單提高你掌握複雜的能力，捕捉複雜裏所蘊藏的機會。

[#1185]@讓您成爲傑出架構師#架構設計迷思# 在迷霧叢林裏，以設計造形爲<地圖>；而所觀想(Visualize)的願景(預見的成功)爲<北極星>。二者指引團隊發掘小路徑(戰術)，調整大方向(戰略)，讓戰略與戰術相輔相成。更多新思惟：http://t.cn/8Fo3HIo

[#1186]身爲架構設計師，你的職責就是：讓你的團隊或企業在歷經迷霧的過程當中，沉着冷靜探索別人未到過的小徑，持續投入熱情去開墾，綜觀全局和洞悉細節的演變，讓瞬間出現的幸運草(機運)種子，迅速萌芽長大。

[#1187]架構師要與技術人員共同尋找會贏的戰術，而後與管理人員協調攸關的戰略資源，將會贏的戰術效益極大化。簡單的設計造形，就如同迷霧叢林的地圖般，很是有助於讓技術和管理人員理解混沌和變化的本質性規律，消除疑慮，提高團隊的信心和行動力。這屬於走入迷霧以前的預備動做。

[#1188]在迷霧叢林裏，以設計造形爲；而所觀想(Visualize)的願景(預見的成功)爲。二者指引團隊發掘小路徑(戰術)，調整大方向(戰略)，讓戰略與戰術相輔相成；就會是贏家了。

[#1189]在迷霧叢林裏，以設計造形爲<地圖>；而所觀想(Visualize)的願景(預見的成功)爲<北極星>。二者指引團隊發掘小路徑(戰術)，調整大方向(戰略)，讓戰略與戰術相輔相成；就會是贏家了。這相似於古今中外，人們喜歡觀天文、看地理的思惟。

[#1190]茲用一個三角形，依順時針方向繞一圈來表示整個設計和建置流程。首先，從願景出發，願景愈清晰動人，愈能激發總體團隊和用戶的信心和憧憬。對於用戶而言，願景是目標。然而，對於設計團隊而言，願景不只僅是目標，並且是一個重要<手段>。咱們把它當作整個流程的起點，而後推導出整個整個流程和活動。

[#1191]頂層設計(Top-level design)概念是源自於系統工程學。其含義是自高端開始(Top-down)的整體構想(Vision)，而後引導出系統開發的理念一致、功能協調、結構統1、資源共享、部件標準化等統籌規範。換句話說，頂層設計是指理念與實踐之間的藍圖。

[#1192]@讓您成爲傑出架構師#架構設計迷思與解惑# <<高煥堂的架構設計工法：如何支撐智慧城市的頂層設計。更多新思惟：http://t.cn/8Fo3HIo

[#1193]幅員愈廣大的國家，頂層設計的規模愈大(例如數據量，網絡帶寬等)，其中層設計愈重要。就如同樹木通常，長得愈高大的樹，其樹幹的重要性就愈顯着。

[#1194]每一臺智能電視的中層設計和EIT造形是一致的，但各自內涵不相同，發揮獨特性。每個數字家庭的中層設計和EIT造形是一致的，但內涵不相同，發揮獨特性。同理，每個智慧城市的中層設計和EIT造形是一致的，但各自內涵能夠不一樣，發揮區域優點。

[#1195]因而，小的智能電視、中的數字家庭、與大的智慧城市，三者也能夠有一致的中層設計和造形。如此，更創造出一個無以倫比的總體和諧之境。

[#1196]基於EIT造形的複用性，人人都能依循EIT造形(如唐詩之形)、撰寫其代碼(如詩裏的文字)、充實其意境(如悲歡離合)。讓原來邏輯嚴肅的IT世界，增添了很多詩情話意的美感。回顧中國歷史，秦朝的書同文、車同軌，加上唐朝的<詩同形>，開啓了國力雄厚、文創鼎盛的年代。

[#1197]因爲中國是一個幅員廣大的國家；基於區域性優點的發展，頂層設計不宜對戰術(「具體可操做性」)層面作嚴格性規範。因而特別強調戰術的彈性(Flexibility)、複用性(Reusability)和類似性(Similarity)，很是有助於維持願景和戰略的有效性和穩定性。

[#1199]在 {Android + HTML5} 環境裏開發應用軟件時，若是咱們想要開發"行業框架"(Domain-Specific Framework)；那麼，咱們該用JS語言來撰寫框架，仍是用Java來撰寫框架呢? 其選擇的理由是什麼?

[#1200]@讓您成爲傑出架構師{雲+終端}的2-tiered思惟，一直讓許多物聯網項目陷入泥遭而不能自拔。雲有軟件，終端也有軟件；兩端透過互聯網來連結；看似真理般的事實，倒是一大迷思。由於互聯網是通訊，並不是軟件。因此兩端的軟件被切分了，不是一個有機的軟件整合體(像人體通常)，因此弊病滋生了。更多新思惟：http://t.cn/8Fo3HIo

歡迎訪問 =>高老師的ADT技術論壇

高煥堂：MISOO(大數據.大思考)聯盟.臺北中心和東京(日本)分社.總教練

ee ee

<<看上一集-------看下一集>>