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

前言：管理者的Requirement-based、User-centered、Test-Driven視角只是通往最佳用戶體驗的衆多<途徑>之一，不是惟一途徑。架構師基於互補視角(例如Vision-based、Design-driven、Architecture-centered)，很容易找到更好的途徑來取而代之。若是架構師不能如此，就只淪爲管理者的隨從了，團隊也將沉淪了。html

古希臘建築師師主張3個視角：功能、結構和美感。其中，美感包括結構之美，不侷限於易用之美。因此我建議，最好能給設計學系學生開個新課程：，讓軟硬件架構師與設計系學生攜手同遊軟硬架構設計，彩繪IT產品的將來。網絡

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

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

[#1801]<<軟硬結合商業模式設計的常見思惟誤區>>許多軟件開發企業一想到與硬件產品進行軟硬結合，幾乎都當即提出問題：硬件廠商願意付錢買個人軟件嗎? 這是軟件人員最多見的思惟誤區。事實上，軟件廠商必須主動提出：不須要硬件廠商出任何一塊錢。理由是：軟件是來替硬件增值的，而不是徒增硬件廠的成本。大數據

[#1802]各軟件企業如何設計本身的商業模式，而不是我來替他設計。我只能引導，而不能代勞，由於各商業模式都是策略，與各企業所處的環境息息相關。網站

[#1803]<<軟硬結合商業模式設計的常見思惟誤區>> 若是您仍是沒法想通軟硬結合商業思潮，不彷做個比喻：軟硬結合裏的硬件廠與軟件企業雙方，若是拿<木瓜與鳥>來比喻，你會認爲硬件廠是木瓜仍是小鳥呢? 你會認爲軟件企業是木瓜樹仍是小鳥呢? 木瓜樹曾經向小鳥收取費用嗎?

[#1804]<軟硬結合促成硬硬結合> 若是H廠商的智能TV提供一個USB硬件接口，能夠外接攝像頭(Camera)，而且提供H廠商獨特的API，讓App開發者來撰寫涵蓋TV+Camera的獨特性App。因爲App發揮了TV和Camera的獨特性，就能透過TV銷售渠道去帶動Camera的銷售量。除了Camera以外，血壓計等也都能成爲TV的配件。

[#1805]<這非易事，受不少環境或條件影響>。也所以，因此須要架構師與架構設計。

[#1806]@讓您成爲傑出架構師#IT+Design Thinking# 例如，想創建一棵樹，用戶(如同樹梢的一隻瓢蟲)很是關心樹葉，並想象樹幹(就是outside-in)；那麼，架構師就可特別關心樹幹和樹枝，想象如何支撐數葉和瓢蟲(就是inside-out)。二者的視角拉的愈大，對總體的設計和建置是愈有益的。更多新思惟：http://t.cn/8FbhmdD

[#1807]Aullyxiao: 「高架構師不要圍繞着跑，才能創造更具獨特性的產品，給與更好的。」，這樣咱們就能夠引導用戶，而不是追趕用戶，這非易事，受不少環境或條件影響。

[#1808]1. <努力分析它們的複雜關聯，並抽象出穩定的架構關係> 2. <乾脆把他們塞進一隻集裝箱裏> 二者都是想得到一個抽象而簡單的次序(Order)。前者偏於科學解析，後者偏於藝術設計。有效的架構師要兼具兩種能力，並擅於聯合運用。

[#1809]身爲架構師最常被問的基本問題是：如何處置應用之間的業務流程(包括業務規則、業務邏輯、業務活動)變化。若是這些擅變複雜流程，就像一推夾雜在一塊兒的鞋子、襪子、衣物等，那麼你會如何面對呢? 努力分析它們的複雜關聯，並抽象出穩定的架構關係呢? 仍是乾脆把他們塞進一隻集裝箱裏呢?

[#1810]<Leader與Owner是在事務中的兩種不一樣的體現管理價值與風格的角色。> 既然是Leader，最好與管理互補，應該體現<領導價值>，而不是<管理價值>了。

[#1812]拿破崙的軍隊越過阿爾埤斯山進軍羅馬，人家問他是如何帶領軍隊的，他回答：我是Leader，而不是Director。領導與管理事互補而均衡的，領導不該該歸入到管理的小腳裏。

[#1813]一個成功的軟件公司，其領導體系是持久而穩定的。可是管理體系就不是，當公司不賺錢，管理體系就該換新；公司賺大錢而被併購時，管理體系也會換新。

[#1814]架構師有系統架構師、產品架構師、產業架構師等一個體系。這個體系經常被總經理、部門經理、項目經理等管理體系所切割了。把一個體系塞入令一個體系的小腳裏，形成管理掛帥、客戶&需求掛帥。難怪沒有辦法進行跨公司、跨產業的整合，例如深圳軟、硬、互聯網產業龐大，卻沒法媲美韓國三星。

[#1815]架構師遊手好閒，夾雜太多管理思惟，每每壓縮本身發揮&活存的空間。好的架構師經常不是好經理；好經理每每不是好架構師。二者思惟和角色很是互補。許多人忽略這個關鍵而維妙之處。

[#1816]在大陸習慣性稱謂裏，都把管理者(Manager)稱呼爲<領導>，經常混淆了Leadership、Management二者。其實二者的觀點和視角是互補的，徹底不一樣的職責範圍。例如，法國拿破崙軍隊越過阿爾埤斯高山，進軍意大利。有人問：他的軍隊如何克服該嚴峻的挑戰呢? 拿破崙回答：I am a leader, but not a director。

[#1817]在西方思惟裏，Leadership和Management是有很清晰的區分的。二者的觀點和視角是互補的，徹底不一樣的職責範圍。例如，10多年前，第一次波灣戰爭時，美國軍隊最高將領：蘇麗文四星上將，寫了一本書：HOPE IS NOT A METHOD，書裏就將Leadership和Management區分的很是清析。

[#1818]我發現設計師們忙於多媒體IT系統的<軟交互>UI設計，我很是詫異：這些設計師們只站在一個咖啡館的櫃檯邊研究用戶體驗，卻不肯意進入悶熱廚房去看看<廚師體驗>，更不肯意去工廠裏，看看咖啡機制造的<工程師體驗>。不徹底的體驗，不完美的做品!!

[#1819]<互相瞭解和信任>只要從架構師自己修養出發便可，管理者的職責和技能都已經很清析了。架構師本身該如何修練，都是向管理者學習，習慣於requirement-based, user-centered的用戶(也就是管理者)視角，是架構師的修練方向與管理者不能互補所致。

[#1821]然而必須獨尊一個主視角，不然團隊成員難以互補，不容易有好的Collaboration。

[#1822]管理者的Requirement-based、User-centered、Test-Driven視角只是通往最佳用戶體驗的衆多<途徑>之一，不是惟一途徑。架構師基於互補視角(例如Vision-based、Design-driven、Architecture-centered)，很容易找到更好的途徑來取而代之。若是架構師不能如此，就只淪爲管理者的隨從了，團隊也將沉淪了。

[#1823]古希臘建築師師主張3個視角：功能、結構和美感。其中，美感包括結構之美，不侷限於易用之美。因此我建議，最好能給設計學系學生開個新課程：<IT軟件和硬件架構設計之旅>，讓軟硬件架構師與設計系學生攜手同遊軟硬架構設計，彩繪IT產品的將來。

[#1824]@讓您成爲傑出架構師從我訪問許多所大學的設計學院，發現師生們忙於IT<軟交互>UI設計，設計師們只站在一個咖啡館的櫃檯邊研究用戶體驗，卻不肯意進入悶熱廚房去看看<廚師體驗>，更不肯意去工廠裏，看看咖啡機制造的<工程師體驗>。表面上關心客戶體驗，但並不關心其<供應鏈>!! 更多新思惟：http://t.cn/8FbhmdD

[#1825]將設計思惟侷限於<UI軟互動>是設計專業人員的自我設限，也是IT產業的自我設限，兩個產業都是極大損失。

[#1826]身爲架構師，其觀點(或視角)應該與用戶是互補的。例如用戶看系統(或產品)都是採outside-in視角；因而架構師就不該該獨尊此一視角，而尋覓一個儘可能互補的視角，例如採起inside-out視角。因而用戶體驗師與架構師就互補了；就像公司的領導者與管理者各採起不一樣視角，對公司最有益了。

[#1827]我一直但願<IT架構師>能與<專業設計師>多攜手帶領這個不斷開發和經營的戰略性過程。此過程就是屬於<A段(規劃段)架構設計>。

[#1828]蘋果公司前首席設計師 Robert Brunner在其書：<<相當重要的設計>>裏寫到：<你必須由內而外(outside-in)的總體設計而不是添枝加葉。設計並非一項你應用在實體或機械物品上的活動或過程。你正在設計的是客戶體驗的供應鏈。> 同理，只關注<軟交互>只是添枝加葉而已。

[#1829]蘋果公司前首席設計師 Robert Brunner在其書：<<相當重要的設計>>裏寫到：<一般偉大產品的成功之道並非從草圖和定義開始的，而是以一個點子開始，造成一條切實可行的路；而後對此不斷開發和經營，這是一個有意而爲的戰略性過程。>IT架構師與設計師如何與帶領此過程?

[#1830]我2012年參加6個城市#MPD#架構師峯會，發現產業界專一於B段架構設計。因爲設計專業人員的<自我設限>，致使IT架構師戰略思惟的<空白缺憾>；若是能結合雙方，就能大幅提高IT產業的架構師和設計師地位和價值了。

[#1831]@讓您成爲傑出架構師 蘋果公司前首席設計師 Robert Brunner在其書：<<相當重要的設計>>裏寫到：<將客戶所想融入設計之中>。客戶所想所要的就是俗稱的<需求(Requirements)>。同理，設計不是來自需求(Requirement-based)，設計不是去實踐需求而已，而是需求檢驗設計，而後融入於設計之中。更多新思惟：http://t.cn/8FbhmdD

[#1832]蘋果公司前首席設計師 Robert Brunner在其書：<<相當重要的設計>>裏寫到：<蘋果開發iPod是一道門戶，能夠通向價值非凡且不斷髮展的客戶體驗，這是一個與以往產品的重大區別。> 同理，設計專業人員專一於<軟交互>只是打掃門口，而不是參與或帶領去不斷髮展客戶體驗。

[#1833]軟硬結合強調的是<跨產業整合商業模式>，傳統PC&企業應用(例如航空業)如何發揮終端硬件的特點，創造應用產業與終端產業的結合與共贏。

[#1834]蘋果公司前首席設計師 Robert Brunner在其書：<<相當重要的設計>>裏寫到：<直觀地關注產品行爲，不僅是研究產品的外觀，而是研究它如何發生、如何操做、以及如何運行。> 這也凸顯了目前設計專業人員只關注於<軟交互>是遠遠被拋棄在產業潮流以外了。

[#1835]架構師也是設計師，只是出身於IT 本業，並不是設計專業。二者攜手帶領企業走向Design-driven。

[#1836]#IT+Design Thinking# 我經常把需求比喻爲女生，而設計則是男生；談戀愛時，女生檢驗男生然後融入(嫁給)男生。不過，大多數人都把它們的角色倒過來，把設計融入(嫁給)到需求中，不需檢驗，只要夫唱婦隨便可，只是這種大同世界一直沒有出現過。更多新思惟：http://t.cn/8FbhmdD

[#1837]許多人認爲HTML5最寶貴的是跨平臺，追求徹底跨平臺纔將HTML5發揮到極致。我認爲是烏托邦想法，例如一部汽車，追求整部汽車的通用性是烏托邦，反而只追求<引擎>跨平臺，<輪胎>則不跨平臺。因而，我創了EIT，<E>就是引擎，<T>就是輪胎。

[#1838]@讓您成爲傑出架構師#IT+Design Thinking# EIT的基本思惟是：把輪胎拔掉，犧牲<輪胎>跨平臺的利益，來換取<引擎>更加跨平臺的利益。取得最大的總體跨平臺利益，由於引擎價值較高，創造它的更多跨平臺機會，是較聰明的抉擇。更多新思惟：http://t.cn/8FbhmdD

[#1839]YES, 跨平臺是商業策略的一環。簡單(Simple)道理，卻很不容易(Not Easy)被接受!!

[#1841]蘇震巍:我以爲吧,最寶貴的,也是最大的意義確實是跨平臺,沒有之一,但如何發揮HTML5關鍵仍是要看基本功和應用的各項要素,跨平臺只是一個橋樑而已,完美的東西是不存在的。

[#1842]不能再做<應用VS.平臺>的垂直二分法，也不能再保持<Client VS. Server>的水平二分法了。一架飛機的上層客艙座椅和下層輪胎都是不適合跨平臺，以便創造中間層的引擎的高度跨平臺。並且頭(Client)尾(Server)都有上中下層呢!!

[#1843]商業策略涉及了<組織評臺>與<軟件(技術)平臺>。二者互相支撐，才能成爲贏家。Apple支持HTML5技術，但也不太但願HTML5 App能跨出IOS平臺!!

[#1844]<下層是被跨的，中層是實現跨的，上層是受益跨的>。你們都想跨別人，結果什麼都跨不成了。例如足球人人想射門，球隊穩輸無疑。

[#1845]智能TV與通常TV不一樣；通常TV不能跑軟件，智能TV幕後是計算機。視頻網站提供音視頻內容。視頻網站像市場，通常TV像餐桌；智能TV像<廚房+餐桌>。

[#1846]<真正要作到跨平臺>對哪一個產業有利呢? 有人獲利可能就有人失利，只強調單方利益，變成均貧社會。<真正要作到跨平臺>的大同社會還沒出現過。

[#1847]@讓您成爲傑出架構師#IT+Design Thinking# 家家戶戶均可以有一個平臺(Platform)，這個平臺是軟件平臺、也是硬件平臺、也是內容平臺、也是居家物聯網平臺、甚至是三網融合的通訊平臺。這個平臺是什麼? 其見仁見智，且兵家必爭。那麼，身爲架構師，你如何設計這個平臺架構呢? 更多新思惟：http://t.cn/8Fo3HIo

[#1848]HTML5/PhoneGap框架可支持開發行業領域平臺，不只可用來開發Web App而已。若是咱們是這個行業平臺開發者，可能不但願其所支持的App跨平臺吧(老大哥總不喜歡他的小弟隨意跳槽吧)。你們都喜歡跨別人的平臺，可是若是咱們是平臺開發者，又如何呢?

[#1849]電視機硬件是你們熟悉的東西，這硬件遇見內容(Content) 仍是很熟悉的；可是這硬件遇見軟件，變能<智能TV>，你們彷佛變得不熟悉它了；可能更弄不董HTML5 + Smart TV到底爲什麼物了。

[#1850]因爲架構師(architect)偏於<物>(產品或系統)的設計，而經理們(manager)偏於<人和事>。因此架構師最大的挑戰在於：如何調整團隊的分工合做模式。由於掌握團隊機制的是經理，不是架構師。那麼架構師憑什麼說服經理們(多是Boss)去調整團隊的分工模式呢? 這是有效架構師的必修課。

[#1852]人人都知行合一，社會總體低智能。我的知行不合一，社會知行才合一。例如，文藝復興時代，英國牛津大學開始教授終身搞知(知識)，大批年輕學生學習後搞行。當時正處中國知行合一時代，人人都<智慧+篤行>，誰搞知識呢? Knowledge is power, 沒知識就沒國力。

[#1853]＜我的知行分離＞能代來＜社會知行合一＞，是社會進步的動能源頭，也闡述大學教授爲什麼必須終身職的原理。

[#1854]HTML5天生麗質，具備天賦的跨端、跨雲、跨平臺之美。Android開源的平臺和開放的框架API，帶給全球終端產業的軟硬結合機會，激發了無窮的創新力量。Android + HTML5成爲力與美的最佳拍檔。

[#1855]@讓您成爲傑出架構師依據經濟學說，徹底競爭市場的商業策略空間較小，而徹底壟斷的策略空間也不大。反而是不徹底競爭、也不徹底壟斷的市場策略，就百花齊放了。一樣地，不徹底跨平臺、不徹底封閉的(Android TV + HTML5)力與美兼容幷蓄的平臺，卻蘊育出廣闊的架構設計空間與商業策略機會。更多新思惟：http://t.cn/8Fo3HIo

[#1856]許多人都認爲TV是終端，而沒有想到 Android TV也能夠是雲，而不僅是端而已。HTML5也能擺在終端，而不僅能擺在雲端而已。當Android TV亦端亦云，而HTML5既在雲又在端。Android TV + HTML5則是端雲整合&軟硬結合，，呈現出不少架構設計，也激發了各類可能的商業策略。

[#1857]依據經濟學說，徹底競爭市場的商業策略空間較小，而徹底壟斷的策略空間也不大。反而是不徹底競爭、也不徹底壟斷的市場策略，就百花齊放了。一樣地，不徹底跨平臺、不徹底封閉的(Android TV + HTML5)力與美兼容幷蓄的平臺，卻蘊育出廣闊的架構設計空間與商業策略機會。更多新思惟：http://t.cn/8Fo3HIo

[#1858]當軟件公司與硬件廠商談合做(例如軟硬結合)時，軟件公司都會但願硬件廠商能付錢給軟件公司。若是拿天然界的<木瓜與小鳥>的關係來比喻軟硬件廠商的二者關係；試想，身爲一位架構師，你會將軟件公司當作小鳥或木瓜? 你會將硬件廠商視爲小鳥或木瓜呢? Why? 更多新思惟：http://t.cn/8Fo3HIo

[#1859]關於這個˙問題，我舉一個福特汽車的例子。100多年前，福特汽車的銷售人員，作完客戶需求調研以後，回報給公司說：<客戶須要的是一匹更快的馬>。此時身爲架構師該如何面對呢? 架構師要試圖幹掉這項需求，而後想辦法設計出汽車，比馬跑得快，由於他不能帶領福特工程師去弄出更快的馬!

[#1860]@讓您成爲傑出架構師 #IT+Design Thinking# 關於<<架構師要先試圖找理由去否認(幹掉、刪除)客戶、老闆、或團隊的需求>>，我也不得再也不舉孔明在<隆中對>裏，開場就幹掉劉備的需求：統一天下。孔明寫到：<操擁兵百萬，挾天子以令諸侯，不可與之爭峯也>。接着，還刪除了劉備的第二項需求：二分天下。好的架構師該如是也!!

[#1861]我強調：架構師要先試圖找理由去否認(幹掉、刪除)客戶、老闆、或團隊的需求；而不是一直找理由去支持(或證明)本身的看法。這也引發許多人的質疑；我只好舉出麥肯錫顧問公司的拿手絕招就是<刪除法>(英文的MECE)，也就是俗稱的<架構簡法設計>。更多新思惟：http://t.cn/8Fo3HIo

[#1862]這很相似麥肯錫的操做方法和諮詢顧問營利模式，產品就是one-page proposal。 //@於忠東_諮詢式培訓:如何操做，這樣企業如何盈利？如何造成產品？

[#1863]@讓您成爲傑出架構師#IT+Design Thinking# 依據波灣第一次戰爭時，美國軍隊4星上將 Sullivan的<<Hope is not a method>> 一書，願景、目標、方向是屬於規劃段，獲利思惟主導。周愛民原來的<大道至簡>偏於生產段(成本思惟)，新書則擴大到規劃段而已。更多新思惟：http://t.cn/8Fo3HIo

[#1864]在#深圳MPD#架構師峯會，周愛民老師來到個人課堂上，並送我一本他的新書：<<大道至易>>。此書的序言裏，第一句話就提到我：<臺灣的高煥堂先生曾說架構的要旨是：以序容易。> 我這是在凸顯架構師的心境：架構師不能心中討厭變(易)，想刪除它，而後留下穩定、不變的基礎平臺；這是不對的心境!

[#1865]在<人月神化>一書原做者Brooks在30多年前就提出來：軟件的變化(易)的複雜性(Complexity)猛獸是沒有銀彈能夠制服的。他說：這複雜性是軟件本質的，不可刪除的。他提出軟件架構與概念一致性(Conceptual Integrity)的重要。現在，還有多少架構師夢想去刪除<易>，而不是包<容>易，因此作軟件很不<容易>!

[#1866]關於我在#深圳MPD#峯會所說<<架構師要先試圖找理由去否認(幹掉、刪除)客戶、老闆、或團隊的需求>>，我要在解釋，這是架構師的重要心境：要力圖找證據去刪除、否認需求，這只是在於去蕪存菁而已，而不是非要幹掉需求不可。對於沒有足夠證據能刪除的需求，還是欣然接受的。

[#1867]若是架構師面對需求，如同跪接聖旨；面對變化(易，如Android硬件平臺的多變)卻視如寇讎，欲除之然後快，而後留下穩定、不變的結構或平臺。這就不是架構設計了。我則提出，架構師反而要力圖刪除客戶、老闆、或團隊提出的需求，而且要去喜好變化，<容>納<變(易)>，纔是架構設計。

[#1868]許多人認爲本質是簡單的、不變的，因此架構師應該去分析變與不變、而後呈現其簡單的不變性。這種認知可能有錯，試想愛因斯坦發現了E=MC^2不變定律，他發現(Discover)定律，並不設計(Design)該定律。因之，若是架構師的職責是架構的<設計>，就不應走分析、不變的<發現>之路。

[#1869]我主張先設計，先想<合>，後<分>析。從願景而設計，帶動分析事實，刪除不合理的設計和需求。分析不只僅解析需求，理解需求的手段也不只是分析而已，設計也是。

[#1870]中國古代的高智慧：庖丁解牛，也是依據架構而<分>，面對需求而<合>。思惟之別，不是現今的中西方之別而已。

[#1871]波灣第一次戰爭時，美國軍隊4星上將 Sullivan 將軍，寫了一本書：<<Hope is not a method>> 他把架構、目標、方向歸於<領導職>，不屬於<管理職>。而周愛民把領導規於管理以內。這是視角的區別。也多是大陸地區習慣於把管人的都稱領導，致使領導(Leader)與(Director or Manager)是不區分的。

[#1872]其實，#MPD#峯會已是當今軟件技術論壇裏，最具備<設計>品味的了。各大城市的軟件產業也都熱情支持，只是MPD還<不敢>像韓國三星同樣說：咱們MPD就是賣設計的，咱們MPD就是要教你如何賣設計(再也不賣產品)。不過，在個人MPD架構師專場裏，我替MPD說了：我來教大家如何賣設計，由於架構師就是設計師。

[#1873]@讓您成爲傑出架構師客戶需求不該該視爲真正的需求，客戶指望只是架構師處理願景、作規劃(架構設計)時的一項參考而已，架構設計以後才能產生一項產品或系統開發的需求規格(Spec)。只是許多架構師都位於生產段，而不是位於規劃段。更多新思惟：http://t.cn/8Fo3HIo

[#1874]糧草徵收維：< 老師不只是一個工程師，更一個商人。他對一些事情的見解頗有獨特的看法，這個深度不是我如今能達到的，我還須要時間去理解他說的一些話。他這是把我忽悠了麼？仍是我智商真的不夠呢？>

[#1875]許多人經常論證：<若是事前不分析...，不標準化...，就不可能...>。意味着：不作A就不可能有B或作B。這是對的，可是談的是<作>而不是<設計>，設計是虛思惟，作是實勞力。例如，一棟大廈建築，<沒作地基，就不可能建第100層>是對的；可是先設計第100層，倒是正確的。架構設計思惟與開發管理思惟互補。

[#1876]在肯德基餐廳裏，實務面是先<作>分解(雞)，而後客人來了，才<作>組合的動做。這是合理的。只是，這是管理者、執行者的事，不是架構師的事。架構師，先構<想>如何才能讓櫃檯人員合快，反推而去<想>如何才能讓廚師分得妙。但架構師自己並不親自<作>分與合的動做，只是構思設計而已。

[#1877]在深圳#MPD#峯會的架構師專場，另外一位講師周愛民老師也來到個人課堂上，並送我一本他專心寫作一年的新書：<<大道至易>>。此書的序言裏，第一句話就提到我：<臺灣的高煥堂先生曾說架構的要旨是：以序容易。> 想不到，多年前對他先前的書：<大道至簡>的一句評語，卻激發他的這本新書。

[#1878]@讓您成爲傑出架構師蔡德輝_IT質量管理前沿：看了周愛民《大道至易》。架構，是工程中如何在高層構建系統來知足其需求。而管理，則是經過計劃、組織、領導、控制來保證目標的實現。書中將架構上升到管理與技術的平衡，成爲目標與方向的主體，合適嗎？管理與技術應該平衡，但目標和方向是管理與技術同時要考慮的。

[#1879]著名架構師周愛民老師於4年前送我<大道至簡>一書，幾天前他與我見面，說到個人<<容易(包容改變)>說，引起了他寫了一本新書：<大道至易>。架構師設計容器去包容人(需求)、[#1880]內容與機器(硬件平臺)的改變，作容器是簡單的，可是架構師要隨變而作出不一樣容器，要創意、設計並不簡單，更況且要去駕馭改變呢!

[#1881]<我其實一直都不大理解，爲何您熱衷於這些不嚴謹的比喻，來把把許多簡單清晰的道理說得複雜了，模糊了呢?> 我也期盼有人多幫咱們講講<簡單清晰的道理>，可是也只有周愛民老師喜歡談談<大道至簡>、<大道至易>的簡易道理呀!!

[#1882]@讓您成爲傑出架構師#IT+Design Thinking# 以個人多年經驗，一位架構師參與A段時，會發現A段市場、產品人員擅於情報分析，但不擅長技術細節。所以Coding等技術細節卻成爲架構師與其它A段人員互補的基礎，也是存在的價值。不擅加利用敏銳的技術細微洞悉能力，就不能在A段立足了。更多新思惟：http://t.cn/8Fo3HIo

[#1883]周愛民老師也寫了兩大本書：<<大道至簡>>和<<大道至易>>來闡述軟件開發的<許多簡單清晰的道理>，看來兩大本書仍是講不完<許多簡單清晰的道理>呀! 要把<許多簡單清晰的道理>講清楚，誰能作到呢?

[#1884]<作A段規劃者，須要作B段生產的經歷爲基礎嗎？> 我認爲很須要，就如同架構師須要有持續coding的。<具體A段和B段架構師定義，可否說說呢？> A段是投資決策前，B段是投資決策後。

[#1885]從韓國三星公司的團隊架構來看，專業設計師和架構師都是貫穿A、B兩段，就如同足球隊的中峯同樣，貫穿全場。而不是由市場部和工程部來切分爲前、後場，這樣讓架構師集中於後場，力求節省成本，這彷佛不適合於當今的產業競爭潮流。

[#1886]#架構師思惟練習# 昨天我在深圳的#MPD#技術峯會與一百多位IT業界架構師交流時，我提到：架構師不要圍繞着<用戶需求>跑，才能創造更具獨特性的產品，給與更好的<用戶體驗>。許多人不解我所說，今天還有人問我這個問題。

[#1887]@讓您成爲傑出架構師#IT+Design Thinking# 我實在納悶，不管是在深圳MPD課堂內，或在此微薄裏，我一直想把議題聚焦於<設計>，然而你們都經常把議題轉移到<需求>；卻不知，聚焦於<設計>，能夠設計別人；專一於<需求>經常被設計了；你會選擇觀注於設計或需求呢? 更多新思惟：http://t.cn/8Fo3HIo

[#1888]Great, 用戶的<需求>，<要求>，<想要的>，<須要的>區別開來；將<用戶體驗>，<用戶需求>也區別，應該有助於人們的領會...。

[#1889]我前日訪問韓國三星時，你們談到目前Apple 對三星提出訴訟大多在「設計」上着墨，例如英國法院在7 月撤銷Apple 對三星平版計算機外觀設計徹底模仿的訴訟，認爲「三星的外型設計沒有Apple好看(Cool)，不會讓消費者分不清產品差異」。

[#1890]<怎麼感受就是戰略架構，而不是技術架構>偏於A段的架構設計呀!!@讓您成爲傑出架構師#IT+Design Thinking# 需求用來刪除，修改不合理的設計，設計序來包容各類變化。設計是主導的獲利思考過程，而需求則是被主導的成本思考的過程。更多新思惟：http://t.cn/8Fo3HIo

[#1891]這回深圳MPD峯會，我談了A段(規劃段)架構師與B段(生產段)架構師，深感國內架構師屬於B段居多。反觀我上回拜訪韓國三星產品架構師時，卻大可能是談A段的架構設計，參與人員多爲市場、設計、產業趨勢等。我但願更多架構師參與A段事務，多點獲利思惟，不要只懷成本思惟。

[#1892]只要分清楚領導與管理的行了，架構師是領導職，並沒有資源；經理是管理職，擁有資源(人和事)。只是許多架構師想爭奪資源，不擅互補；就被邊緣化了。

[#1893]流沙河魚: 設計是從無到有的思考過程，而需求則是知足別人的思考的過程。

[#1894]仍是有人問我在深圳MPD談設計專業的問題。就如，三星也很清楚目前「三星設計」與善於創新的apple 的差距，其實早在2006 年，李建熙會長也提出「創新經營」的概念，可是礙於東西方文化的差別，設計的創新性與apple 相比，仍顯不足。爲了拉近設計創新不足所形成的差距，三星作了很是多的調整與努力。

[#1895]@讓您成爲傑出架構師#IT+Design Thinking# 先觀注願景，以需求來刪除某些願景，設計願景得實現計劃，舊稱爲，引導細節的需求分析，細節需求刪除細節設計。通過需求過濾的就是好的設計。在知足成本需求下，盡情追求獲利極大化。這樣描述願景、架構、需求、設計的互動關係。更多新思惟：http://t.cn/8Fo3HIo

[#1896]<對某些公司來講，「客戶至上」就行，其它免談。結果客戶提出許多不合理需求，都要員工來實現。你說不合理？客戶出錢給你，誰敢說財神爺提出的需求是不合理的呢？>這就是架構師被困在生產段的龍困淺灘窘境。

[#1897]@讓您成爲傑出架構師麥當勞、肯德基面在顧客提出炸雞需求時，以<合>待之(半雞=一支雞腿+一隻翅膀+一塊雞胸)；全聚德烤鴨，則以<分>待之(在客人面前切烤鴨)。前者以合(設計)爲主導，後者以分(解析)爲依歸。這不能解釋爲：前者有成熟行業，或者前者有秉賦特異的架構師! 而是思惟侷限了本身。更多新思惟：http://t.cn/8Fo3HIo

[#1898]在深圳MPD架構師峯會，周愛民老師來到個人課堂上，並送我一本他的新書：<<大道至易>>。此書的序言裏，第一句話就提到我：<臺灣的高煥堂先生曾說架構的要旨是：以序容易。> 我這是在凸顯架構師的心境：架構師不能心中討厭變(易)，想刪除它，而後留下穩定、不變的基礎平臺；這是不對的心境!!

[#1899]<分仍是比合要容易的多，合須要的是創意和想象力、創造力，而分則比較機械的思惟>。是的，因此我寫了一本新書：<<如何開發Android應用框架：採用EIT門派途徑>就是以<合>爲主導。

[#1900]管理與領導分離，經理司管理(偏於人&事)；架構師司領導(偏於物)。A段架構師與Product Manager互補；B段架構師與Production Manager互補。架構師偏於物，左邊銜接專業設計師，右邊銜接IT工程師。這樣架構師就沒有活存的空間了。

[#1901]@讓您成爲傑出架構師#IT+Design Thinking# 架構師遊手好閒，夾雜太多管理思惟，每每壓縮本身發揮&活存的空間。好的架構師經常不是好經理；好經理每每不是好架構師。二者思惟和角色很是互補。許多人忽略這個關鍵而維妙之處。更多新思惟：http://t.cn/8Fo3HIo

[#1902]<每每看一我的是否是有漏洞>。因此一個成功的王者身旁老是有個高明的策士(架構或戰略規劃師，如張良)，下降失誤漏洞。

[#1903]@讓您成爲傑出架構師彭濤--科技園：在中國，不是看一我的多麼能一往無前，不少時候，每每看一我的是否是有漏洞，才決定一我的可以走多遠！

[#1904]@讓您成爲傑出架構師#IT+Design Thinking# 硬件來保護軟件的複製權，同時透過軟件來創造硬件的增值，支撐軟硬件的創意設計，說得好，一直以來技術的創新曆來都不缺，缺的是針對某種需求的解決方案，而軟硬結合的方式現在更爲明顯。更多新思惟：http://t.cn/8Fo3z3r

[#1905]以我觀之，軟件外包產業的困境源頭在於：<耕者無其田>。也就是：軟件開發者沒有軟件複製的權利，軟件複製是無本生意，這無本生意賺錢機會(看似合理地)被拿走了；開發者註定只有當長工的份，這種不合理性，一日不化解，接包產業前景就黯淡一日，耕者心理浮躁、質量粗躁。

[#1906]#IT+Design Thinking# 以一張桌子來比喻就會比較清晰了。將桌子分爲三層：1)桌上，2)桌板，3)桌腳。用戶業主所要的是桌上(的APP服務)。桌板(框架)並不是來自業主需求，而是架構師無中生有的，因此只能免費贈送。更多新思惟：http://t.cn/8Fo3z3r

[#1907]TRIZ方法能協助人們找出化解衝突的、創新的問題解決之道，也就解決之形(form)，或稱爲pattern。從人類既有的創新patterns中概括出幕後的meta-pattern，是TRIZ的絕妙之處。

[#1908]爲何香港人們將軟件設計與開發視爲<勞力密集>的低階工做呢? 可能把軟件看成描述複雜的商業需求和行爲，或者表達複雜的硬件運算邏輯。港人最熟悉洋人思惟了，但沒有留意到，洋人擅長將軟件視爲<駕馭>複雜世界行爲的最佳工具。我認爲<軟件+設計+金融>是港人持續風華的三寶。

[#1909]在古典的框架思惟裏，經常懷着<通用性、穩性不變>的角度去看框架；但不必定要抱着此觀點，所以框架設計與抽象不必定相關聯。我即將出版一本新書：<如何開發Android行業框架>就在闡述這個新觀點，我稱之爲：EIT門派觀點。

[#1910]@讓您成爲傑出架構師#IT+Design Thinking# 由於移動互聯網不斷複雜化，那個國度能創做中間造形，就能擁有<駕馭>複雜的能力和槓桿點，就能有話語權、成爲贏家。軟件框架是贏家的尚方寶劍，而框架EIT造形則是劍術葵花了。更多新思惟：http://t.cn/8Fo3z3r

[#1911]<<EIT造形>> 當咱們心懷幾合學裏的橢圓造形去看太陽系星球運行時，會發現其單一造形所創造的總體之美。一樣地，咱們心懷楓葉造形去看待楓葉林時，也會發現其所創造出來的總體美。以此類推，咱們心懷EIT造形去看待Android框架時，也會發現其所創造出來的總體之美。

[#1912]在軟件框架(Framework)上，咱們也創造了一個造形，也只有三種元素：引擎(Engine)、接口(Interface)和輪胎(Tire)。這種造形就簡稱爲EIT造形。這個名稱是來自「把輪胎拔掉而得汽車框架API」的理念

[#1913]<EIT>>其依循<信息侷限性>法則，這項造物法則，提高了掌握天然界複雜多變的能力，惟有熟諳此道，才能創造架構和產品的將來性。

[#1914]許多框架開發者擺脫不了「App開發者」的觀點：把買主和用戶視爲「大員外」，而開發者變成「長工」，就以員外的「需求」爲依歸。因爲App原本就該緊密跟隨員外的需求，而原本意圖去「框住」App行爲的框架卻也跟隨着員外需求而跑，那框架就沒有存在的意義和價值了。

[#1915]爲何要重視框架呢? 由於互聯網的兩端：雲端與終端，都在極速複雜化，逐漸地掌握話語權的不是雲和內容端，也不在終端和硬件，甚至也不在通訊和運營方，而是在於軟件平臺方，其中軟件平臺又包括操做系統和框架，後者纔是山海關，既壤外又安內，乃兵家必爭之地也。

[#1916]俗語說：<哀莫大於心死。> 若是咱們認定<甲方乙方好像原本就不存在平等地位>那就真的沒解了。美國軟件公司(如微軟)都握有<訂價權>或<複製權>，何以國內軟件開發者或公司就天生自我放棄呢?

[#1917]@讓您成爲傑出架構師像武漢、大連等以軟件<接包代工>爲主的產業園，其困境在於軟件開發的<需求、時程和預算>三者都受制於業主，沒有任何話語權，<供需>雙方沒法立於平等地位，人才質量和產品質量都沒法確保，逐漸成爲扶不起的產業模式。若是你身爲架構師，你會如何化解其困境呢?更多新思惟：http://t.cn/8Fo3z3r

[#1918]俗語說：哀莫大於心死。若是咱們認定<甲方乙方好像原本就不存在平等地位>那就真的沒解了。美國軟件公司(如微軟)都握有<訂價權>或<複製權>，何以國內軟件開發者或公司就天生自我放棄呢?

[#1919]一個真正的軟件產業要有完善機制，確保護軟件開發者能保有對軟件複製的<獲利分紅>機會。若是開發者對於開發以後<無限複製>利潤沒有任何分紅機會，這樣的產業不宜稱爲<軟件>產業，由於失去了<軟件>的精神和本質。

[#1920]接包代工(即俗稱的軟件外包服務)如同<代孕生子>，只是幫別人生小孩。我一直建議，在武漢軟件產業策略裏，應該關注於如何主動替這些生母爭取<小孩歸屬權>，否則軟件外包產業對軟件從業人員來講，其惟一的價值只是<練習生小孩>罷了。

[#1921]<從願景發現未知>例如你已經有了火鍋，想象你的願景：吃一餐美味火鍋。爲了實現願景，須要<火鍋+大筷子+大湯勺>，因而發現了目前尚未的未知事物：大筷子和大湯勺。

[#1922]培養創意思惟。首先反思假設(assumption)而刪除一些已知(known)，進而發現未知(unknown)。以後，從願景導出架構，在架構引導下，對現實事物做組<合>，發現發現未知(unknown)。未知激發新的創意。

[#1923]<軟硬產品整合>意味着幕後必須<軟硬產業整合>。例如，蘋果開發iOS平臺軟件和設計硬件，而後與亞洲硬件製造業，進行產業整合；並與全球第三方APP軟件開發產業；進行跨產業整合，才實現了完美的軟硬產品整合。

[#1924]<軟硬產品整合>意味着幕後必須<軟硬產業整合>。兩個產業整合本應是一件簡單的事情，可是要讓雙方衆多參與者都能先互信，然後互惠互利，簡單但耗時，有時候如相親，還得憑緣份、一見傾心才OK。

[#1925]俗語說：哀莫大於心死。若是咱們認定<甲方乙方好像原本就不存在平等地位>那就真的沒解了。美國軟件公司(如微軟)都握有<訂價權>或<複製權>，何以國內軟件開發者或公司就天生自我放棄呢?

[#1926]軟件接包產業的框架戰略，就是分爲三層：1)APP, 2)框架, 3)框架幕後模塊。而後，<將APP轉包出去、將框架贈送出去、取得模塊複製權>。框架就如同萬里長城，控制塞外行爲、保護關內自主性。擅用框架技術，能有效化解接包代工產業的成長難題。

[#1927]@讓您成爲傑出架構師 我建議軟件外包產業的新策略是：以框架(Framework)將軟件分爲：1)APP，2)框架，3)框架的幕後模塊。而後，將APP再轉包、贈送框架、取得模塊複製權。其中，APP再外包的目的是要創造<強龍/地頭蛇>商業模式，來創建本身的生態鏈。可是，框架和幕後模塊就不宜轉包出去。更多新思惟：http://t.cn/8Fo3z3r

[#1928]對於軟件模塊(component)來講，最具備價值的在於它是否能自主地抽換，也就是可否實現：<沒錢就改版、改版就有錢>的機會。軟件模塊價值不在於它的複用(reuse)，複用只是消極的節省成本思惟，而不是積極的獲利思惟。通常而言，接包代工產業都是成本思惟，強調複用，現在必須從新檢視對模塊複用的迷思。

[#1929]三星於2013年結束Bada平臺智能手機的開發；Galaxy S III已經從新將重點放在Android智能手機上。> 我去年針對Bada提出一個見解：臺灣IT產業不會推出本身的軟件平臺，倒是最開放的競爭市場；Bada沒法得到臺灣的青睞，就只能退出市場。

[#1930]韓國三星的短板在於：沒有采起<強龍/地頭蛇>產業模式，而是比蘋果更封閉的自我整合，其bada系統很難以成爲共同平臺。

[#1931]軟件框架(Framework)將軟件架構分爲三層：1)應用(Applications)，2)框架自己，3)框架幕後的模塊(Components)。因而：應用再轉包、框架免費贈送、取得模塊複製權；一切就能改觀了。

[#1932]<框架和幕後模塊不宜轉包出去>的理由之一是：在系統層面上，讓本身擁有總體架構的控制力，維持與業主關係的主導權；以避免將APP轉包出去，也丟了與業主的關係，失去強龍地位。

[#1933]@讓您成爲傑出架構師#IT+Design Thinking# 我喜歡將<軟件本業>與<軟件服務業>分開；就如同將飛機本業與航空業分開同樣；基於此觀點，目前中國沒有飛機業(沒有波音、空巴)，可是航空業很發達。同理，杭州軟件本業薄弱，但軟件服務業很發達。更多新思惟：http://t.cn/8Fo3z3r

[#1934]用心討論互聯網、硬件和服務，卻忘了<軟硬結合>創造終端不同凡響，惟有掌控水龍頭才能讓水庫賺錢，惟有鄉村能包圍城市。平臺軟件控制一切，纔是老大；互聯網、硬件和服務只是小弟。

[#1935]若是你也認同：能夠將一個外包軟件系統視爲由：APP、框架和(幕後)模塊三種設計元素所構成。那麼身爲架構師(便是一種IT設計師)，你會如何定義這些元素的角色及它們之間的關係呢?

[#1936]當你從生產段架構師，轉移到規劃段架構師時，會發現架構獨特化是產品不同凡響的基礎。獨特架構來自何方呢? 問用戶嗎? 回答得都是通常性的使用需求，該如何呢? 很簡單，來自敵方的意圖(Intent)加上我方的意圖和願景，就能得出獨特性了。這就是我在mpd鼓吹願景派架構設計的理由。

[#1937]@讓您成爲傑出架構師#IT+Design Thinking# 框架的關鍵任務是去給上層(或稱AP)一個骨架，規範、限定了上層的型狀。「基於獨特的架構，只讓人們作微小的修飾、裝潢而已。許多軟件架構力求通用性，放縱AP彈性發展，是邁向災難的第一步」。更多新思惟：http://t.cn/8Fo3z3r

[#1938]<軟硬結合+設計>不只僅是傳統的工業設計，講求風格和審美而已。"軟硬結合+設計"能夠比喻爲"劉備+孔明"可讓劉備搖身一變而黃袍加身!!

[#1939]網絡服務業賺到錢，軟件開發者賺到錢? 軟件和硬件兩個產業都貧窮，服務業還能生存? 這就是總體沉淪的夢想!

[#1940]架構師創意思惟：知己知彼==>know unknowns。知己：凡思假設(assumption)，捕捉本身的願景(vision)。知彼：洞察敵方意圖(intent)，擬訂本身意圖。基於<願景、自以意圖、敵方意圖>的引導而找出本身所不知道的(know unknown)。

[#1941]基於<願景、自以意圖、敵方意圖>而創建初期架構，在架構的引導下找出本身所不知道的(know unknown)，反過來精緻化架構，不斷循環下去。

[#1942]只是<反思>假設，而不是否認或確定它。反思以後，天然解開原來的心結和執着，就會<否認>原來的設計，就是re-design了，就產生設計品的創新了。

[#1943]數據堂：最好架構師都在寫代碼。Kent Beck曾經寫道：「代碼就是設計與殘酷現實之黃昏的交匯(Code is when design meets the harsh reality of dawn.)」。畫出來的設計都是美好的，但最好的設計僅是被翻譯爲優雅代碼的那些，一個沒法將願景帶入代碼的架構師將沒法瞭解這個急速變化行業所展現的深度。

[#1945]@讓您成爲傑出架構師#IT+Design Thinking# 願景是假想，可來自四面八方的人。例如，對孔明設計三國策略(即隆中對)而言，願景是從劉備而來：要統一天下、當皇帝；願景大可能是沒法實現的，有些是可實現的。但在想願景時，還沒必要去關心它是否可實現。更多新思惟：http://t.cn/8Fo3z3r

[#1946]<軟硬結合 + 設計>至關於<劉備 + 孔明>。 <設計 + 軟硬結合>至關於<孔明 + 劉備>。二者有很微妙的差別。

[#1947]<IT(軟硬結合) + 設計> 表示設計是IT的外環光芒，讓IT產品從通常石頭姚身宜變而成爲<鑽石>；換句話說，就是將科技作成文化。反之， <設計+IT>則意味着將文化作成科技。

[#1948]<軟硬結合 + 設計>至關於<劉備 + 孔明>。 <設計 + 軟硬結合>至關於<孔明 + 劉備>。二者有很微妙的差別。

[#1949]@讓您成爲傑出架構師#IT+Design Thinking# 架構師不是先肯定創意，纔去想架構或框架。一開始都是假想，而後試圖從假想連線到架構(可實現的計劃)，能找到連線的假想，纔算得上創意。更多新思惟：http://t.cn/8Fo3z3r

[#1950]<IT(軟硬結合) + 設計> 表示設計是IT的外環光芒，讓IT產品從通常石頭姚身宜變而成爲<鑽石>；換句話說，就是將科技作成文化。反之， <設計+IT>則意味着將文化作成科技。

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