A段架构设计_隽语集(IT+設計思考

前言：管理者的Requirement-based、User-centered、Test-Driven视角只是通往最佳用户体验的众多<途径>之一，不是唯一途径。架构师基于互补视角(例如Vision-based、Design-driven、Architecture-centered)，很容易找到更好的途径来取而代之。如果架构师不能如此，就只沦为管理者的随从了，团队也将沉沦了。

古希腊建筑师师主张3个视角：功能、结构和美感。其中，美感包括结构之美，不局限于易用之美。所以我建议，最好能给设计学系学生开个新课程：，让软硬件架构师与设计系学生携手同游软硬架构设计，彩绘IT产品的未来。

本书缘由：高焕堂于2013年在日本退休之前，基于日本师徒制的要求而传承给下一代架构师的架构思考技术(俗称设计心法)。25年来他专精于A段(投资决策前)架构设计，退休闲暇将之写成中文，欢迎大家指教。A段架构师是处于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工程师。这样架构师就没有活存的空间了。

欢迎访问 ==>高老师的博客网页

高焕堂：MISOO(大数据.大思考)联盟.台北中心和东京(日本)分社.总教练

ee ee

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

A段架构设计_隽语集(IT+設計思考_1801)相关推荐

A段架构设计_隽语集(IT+設計思考_1601)
前言:多机整合的商业意义.如果T有200万销售量,捆绑了t1 和t2一起销售,就能带动t1和t2的产量,降低其成本,提升其利润,提升T的竞争力(可稍降价) :这称为<硬硬结合>.然而捆绑销 ...
A段架构设计_隽语集(IT+設計思考_1901)
前言:软件接包产业的框架战略,就是分为三层:1)APP, 2)框架, 3)框架幕后模块. 然后,<将APP转包出去.将框架赠送出去.取得模块复制权>.框架就如同万里长城,控制塞外行为.保护 ...
A段架构设计_隽语集(IT+設計思考_1701)
前言:许多人没有发现<平台(Platform)>一词的涵意逐渐在改变中,就像Application(应用程序)一词的涵意也在改变中.例如,在Android环境里,许多人分不清App与APK ...
A段架构师_隽语集(IT+設計思考_2001)
前言:"设计"就是从假「设」(Hypothesis)而推演出来的可实现的「计」画(Achievable Plan).这个假设我们对未来的设想,也就是还不知道如何实现的空中楼阁.美国 ...
A段架构师_隽语集(IT+設計思考_2101)
前言:使用"框架的插件管理器" 管理好业务逻辑插件,包括:插件定义.插件创建.插件配对.插件Callback(含同步与异步)等等.然后,让 HTML5幕后的WebView事件能传递 ...
A段架构设计_隽语集(Business Thinking _1101)
前言:由于中国是一个幅员广大的国家:基于区域性优势的发展,顶层设计不宜对战术("具体可操作性")层面做严格性规范.于是特别强调战术的弹性(Flexibility).复用性(Reus ...
A段架构设计_隽语集(Business Thinking _1301)
前言: 就内容产业而言,让硬件和软件两个产业的创新能量,能够成为内容产业创新的助力,是多么的重要呀! 过去,内容产业只想屏蔽软硬件平台的创新差异化来降低内容的调整成本. 内容产业如何帮助硬件产业呢? ...
高老师的架构设计_隽语集(DD_1801)
前言:管理者的Requirement-based.User-centered.Test-Driven视角只是通往最佳用户体验的众多<途径>之一,不是唯一途径.架构师基于互补视角(例如Vis ...
高老师的架构设计_隽语集(CC_1201)
前言: 平台(操作系统)是轿子,不一定要自己做轿子,会做好轿子的人处处都有,但是要我们自己能坐上轿子爽快一下才算数:而且坐上去之后,有人争先恐后来抬轿才算成功.如何忽悠别人来大力抬轿(且心甘情愿)是心 ...

A段架构设计_隽语集(IT+設計思考_1801)

A段架构设计_隽语集(IT+設計思考_1801)相关推荐

最新文章

热门文章