高老师的架构设计_隽语集(CC_1051)

前言：从"Essence"(本质)这个字看物联网的思维局限。天下物本质上就是多样化的，IOT想把天下物组合于网络上，是加法设计，物物通信的多样化也是本质性的，也只能加法、不能减法。英文的Essence是不可或缺之意；过度要求通信统一(减法)会伤害物物通信的本质(不可或缺的多样化)；所以另寻他途做减法设计。

我认为，数字家庭里的设备"模块化"本来就是正确的方向。模块化是做"分"的动作，是一种厂商的减法设计。问题是：对于家庭主人而言，如合将多个简化的东东组"合"起来呢? 这是加法问题了。于是家庭主人需要有效的减法设计来支撑这个烦人的加法问题。于是，许多人又回到"订定通信标准"的乌托邦减法思路了。



本书缘由：高焕堂于2013年在日本退休之前，基于日本师徒制的要求而传承给下一代架构师的架构思考技术(俗称设计心法)。25年来他专精于A段(投资决策前)架构设计，退休闲暇将之写成中文，欢迎大家指教。

目录：請看目錄

欢迎访问 =>高老师的ADT技术论坛

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

ee ee

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

[#1051]许多人认为架构设计要基于用户的需求(Requirements)，然而当用户需求不稳定而多变时，又该如何下手做设计呢? 答案是：以问题(Problem)和愿景(Vision)为出发点，"设计"出初期架构(Simple Solution)，展开敏捷迭代过程。在愿景指引下，探索复杂谜题(问题)，而减法设计出"简单"的Solution。

[#1052]一般人看到专利，第一个反应是想避开它。专利发明人都是聪明人，却不善长说服别人避开不如合作，因为不善长于以战术引导战略(专利创意)。一项战略性的专利，如果搭配其战术的发明，就非常有说服力了，专利就价值连城了，如LED灯的发明专利。

[#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)，然后引导出系统开发的理念一致、功能协调、结构统一、资源共享、部件标准化等统筹规范。换句话说，顶层设计是指理念与实践之间的蓝图。

[#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

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