前言：管理者的Requirement-based、User-centered、Test-Driven视角只是通往最佳用户体验的众多<途径>之一，不是唯一途径。架构师基于互补视角(例如Vision-based、Design-driven、Architecture-centered)，很容易找到更好的途径来取而代之。如果架构师不能如此，就只沦为管理者的随从了，团队也将沉沦了。
古希腊建筑师师主张3个视角：功能、结构和美感。其中，美感包括结构之美，不局限于易用之美。所以我建议，最好能给设计学系学生开个新课程：，让软硬件架构师与设计系学生携手同游软硬架构设计，彩绘IT产品的未来。
本书缘由：高焕堂于2013年在日本退休之前，基于日本师徒制的要求而传承给下一代架构师的架构思考技术(俗称设计心法)。25年来他专精于A段(投资决策前)架构设计，退休闲暇将之写成中文，欢迎大家指教。
目录：請看目錄
欢迎访问 =>高老师的ADT技术论坛
高焕堂：MISOO(大数据.大思考)联盟.台北中心和东京(日本)分社.总教练
ee ee
[#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，最好与管理互补，应该体现<领导价值>，而不是<管理价值>了。
[#1811]@让您成为杰出架构师#IT+Design Thinking# <商业模式>是山洞里有金银财宝。<盈利模式>是心中有"芝麻开门"密码，且出来时候不会忘记它。更多新思维：http://t.cn/8FbhmdD
[#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的用户(也就是管理者)视角，是架构师的修练方向与管理者不能互补所致。
[#1820]@让您成为杰出架构师#IT+Design Thinking# 管理者习惯于采取 Requirement-based、User-centered、Test-Driven 视角；架构师就应该采取Vision-based、Design-driven、Architecture-centered视角。更多新思维：http://t.cn/8FbhmdD
[#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)被接受!!
[#1840]@让您成为杰出架构师#IT+Design Thinking# <做好APP（哪怕不是WebApp）本身是关键> 控制好别人的App可能也是关键。做好App只是做好小弟本份，能控制小弟才是大哥。更多新思维：http://t.cn/8FbhmdD
[#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)去调整团队的分工模式呢? 这是有效架构师的必修课。
[#1851]@让您成为杰出架构师#IT+Design Thinking# 个人知行合一的<知>会变成智慧(Intelligence)，而不是知识(Knowledge)。但是唯有<知识>才有力量：Knowledge is power。更多新思维：http://t.cn/8Fo3HIo
[#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.)”。画出来的设计都是美好的，但最好的设计仅是被翻译为优雅代码的那些，一个无法将愿景带入代码的架构师将无法了解这个急速变化行业所展示的深度。
[#1944]Kent Beck也属于，愿景-->架构设计-->Code。
[#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(大数据.大思考)联盟.台北中心和东京(日本)分社.总教练
ee ee
108
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
