A段架构师的思考技術(AA_1001) -ADT

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

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

[#1001]架构设计就是设计，设计就是层复杂到简单的过程；所以架构设计就是做减法。做减法的目的就是要给人们透过简单来叫出复杂的满足感。简单让人不会害怕复杂，有勇气面对未来环境的复杂多变，然后走出自己的个性和出路。

[#1002]减法设计的主要手艺是：把不必要的部分去掉。什么是"不必要"的部分呢? 就是"非本质性"(unessential)的部分。

[#1003]我认为，物联网领域人们最大的思维视角，局限于通信设备和数据传输；少了软件抽象层的视角；因为硬件设备没有抽象层的概念，但是软件的确有抽象模块，真正的代码并不抽象；我认为，这个视角可以化解许多物联网、数字家庭、智能城市项目的难题。

[#1004]@让您成为杰出架构师#有效减法设计#从物联网角度来看数字家庭和智能城市，最大的视角局限在于，人人都争先恐后作加法，加法出了问题时，唯一的减法设计就是：无线通信统一和标准化。然而，这项"唯一"的方法又如同乌托邦梦境。解决此困境之路是：以上层软件框架和接口来做有效的减法设计。更多新思维：

[#1005]在物联网的架构里，最常见的是分为三层：感知层、传输层和处理层。这个"层"的英文偏于"Tier"，而不是"Layer"。也就说，上述的三层，其实是底层(Bottom Layer)里的3个Tier。我建议，在物联网的架构里，至少要在建立Middle-layer和Top-layer才是健康的物联网概念(Conceptual )架构和系统(System)架构。

[#1006]在物联网的架构里，如果缺乏Middle-layer和Top-layer层架构，一个智慧城市就像只有木板床，而无弹簧床，各种创新业务将如同浮沙建塔，非常难以落到实处。

[#1007]@让您成为杰出架构师 #设计思考：有效减法设计# 亦即，追求<与众不同>的特质。你属于哪一派呢? 架构设计的主要流派有二：1) 抽象思维派：致力于抽象出稳定、可靠、不变的共同性架构；亦即，追求<万变不离其宗>的宗。2)组合创新派：致力于组合出具体独特性的创新架构。更多新思维：

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

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

[#1010]不只是在应用面，例如系统面的HTML5本身也需要做减法设计。为了帮App做减法(UI一致性)，HTML5和浏览器本身被迫一直在功能上做加法，来吸收智能化的多样性。因为本身过度做加法，伤害了效能本质。基于此，在去年北京HTML5开发者大会上，我就提出：HTML5追求高度跨平台，是不合理的"理想"。

[#1011]#设计思考：有效减法设计# 亦即，追求<与众不同>的特质。你属于哪一派呢? 架构设计的主要流派有二：1) 抽象思维派：致力于抽象出稳定、可靠、不变的共同性架构；亦即，追求<万变不离其宗>的宗。2)组合创新派：致力于组合出具体独特性的创新架构。更多新思维：

[#1013]<<智慧城市设计焦点在于智慧，而不在于城市>> Why? 未来的社会、科技、经济环境的变化，都是不可预测的，所以我们需要”智慧地”去做决策，让现在的决策具有未来性，而不是去替未来做决策，以免过度设计(Over-Design)城市的未来，反而”冻结”了城市的未来(Frozen Future)。

[#1014]@让您成为杰出架构师 <<如何化解数字家庭的信息孤岛问题>> 数字家庭是智慧城市里的重要业务区块，但信息孤岛情况处处可见，可做为城镇智慧化之路的借镜。数字家庭的信息孤岛，也就是智慧城市的信息孤岛；那么又如何预防或化解这种日益扩大的鸿沟呢? 更多新思维：

[#1015]使用高焕堂老师设计的xMCS系统模式，定义了系统架构层级的共同概念(Concept)和词汇，以秦代”书同文”途径来创造顶层设计的<简洁性>；进而提升团队之间的共识(Shared Understanding)，建立出系统互联互通的基础。

[#1016]基于xMCS模式所创造的简洁性，就可针对各系统之间互联互通的接口部分，以明确的软件代码来定义之；以唐代”诗同形”途径来提升顶层设计(和中层设计)的<明确性>。才能有效检验顶层设计的<可实现性>。

[#1017]目前对于互联互通的标准思维，偏于网络标准，还停留在基础的减法设计层面，就像秦国"书同文、车同轨"阶段。在面对更复杂的智慧城市时，我们需要更高境界的减法设计，就像唐代的"诗同形"。诗同形既不局限李白、杜甫的创意情境，又能互联互通，不亦美哉!!

[#1019]过度的标准化，可能会规范道内涵，而排斥别的内涵；这不是最佳的减法设计。例如，SOA的SOAP/Web Service就是一个例子，很容易局限了多样化的发展(产生排他性)，因而也限制了标准本身的发展。所以减法设计时，要仔细分辨形式(Form)与内涵的不同。

[#1020]非常可惜的是，愈多厂商提供各自<用户体验良好>的解决方案时，信息孤岛问题(即信息共享的鸿沟)就愈严重。想化解这个问题，首先必须了解到，透过网络标准和内容标准的制定做法，是不够的、无能为力的。

[#1021]<<解决方法：软件平台开源、接口开放>> 以行业型软件框架为平台，建立于OS和中间件之上，成为智能化数自家庭的<顶层设计>。基于行业的领域知识(如老龄健康、幼儿学习等专业知识)，建立一致化的顶层应用框架(Framework)，以开源开放的形式，持续汇集各方专家的共识；然后定订出行业型软件接口。

[#1022]@让您成为杰出架构师#架构师思维演练# <<自己发展OS操作系统?>> 操作系统是一个轿子，谁都做得出好轿子，但不一定人人都能乘轿子。如果自己做轿子，不能乘轿子，却去抬轿子(因为没人来抬轿)，就没意义了。更多新思维：

[#1023]也借镜于日本。一位日本电子业者提到1980年代成功开发了TRON操作系统：<日本开发TRON是为了反制大量来自美国的技术，但iTRON从未进军全球市场，也没有日本厂商因为押宝iTRON而赚大钱；后来iTRON的结局是只被应用在日本厂商制造、在日本市场销售的产品。>

[#1024]工信部3月初的研究报告白皮书指出：「我国行动操作系统的研发太依赖 Android 。」除了自己发展OS之外，我一直主张采取<跨平台>策略，更容易成功。在OS和中间件之上建立一层"行业型框架平台"，走开源开放API，透过API掌控App，力量足以与底层OS抗衡，进而掩护自己的OS。

[#1025]"行业型框架平台"与中间件(middle-ware)两者都建立于OS之上，到底它们又有何区别呢? 其微妙差异就在于"行业型"，也就是前者主要关注于纳入完整的上层领域知识(Domain Knowledge)，而后者关注于下层平台知识，包容其差异、抽象其共同性。两者互补，只是许多人没去厘清而已。

[#1026]为什么"行业型框架平台"，走开源开放API，透过API掌控App，就能够强力掩护自己的OS呢? 兹比喻：Android如同15年前的Windows；而"行业型框架平台"就好比当年的MS Office。试想，如果微软好好做Windows，而国人好好做 CN Office；结果会如何呢?

[#1027]Android本来就是技术海中的一股洋流，聪明人会借力使力，让它来推动大轮船、发电、洗刷海岸、借机捕鱼；不得已才需走对抗的下下策。

[#1028]到底"行业型框架平台"与中间件有何区别呢? 可以从智能城镇的视角来看，一个智慧城市包含数十个不同的行业区块(Business Area)，每个行业区块至今已经各自发展多年了，行业概念各自发展。于是，每一个区块都会有各自的"行业型框架平台"。至于中间件则是底层OS而定，数个区块的中间件最好是一样的。

[#1029]@让您成为杰出架构师 #敏捷顶层设计方法# "中层设计"是软件层，用意在于使用软件开发的TDD(Test-Driven Development)分法来检验顶层设计里的"接口"部分，为互联互通做优先的测试；提升顶层设计的可"落地"性。更多新思维：

[#1030]为什么，架构师必须建立中层的行业型软件开放(或标准)接口呢? 因为软件必须包容互联网&通信的标准与不标准接口。试想在{Client端软件，通信网路，Server端软件} 的系统结构中，许多人会先订定通信网路协议，然后才分别开发两端的软件，这很可能是灾难的开始。两项软件变成通信网路两端的插件(配件)了。

[#1031]为什么，架构师必须建立中层的行业型软件开放(或标准)接口呢? 因为让业务层的接口直接依赖于互联网&通信的接口是非常危险的；就如同火车与轮子之间没有弹簧一样；这种不合理性，使得国人尽管互联网服务业发达，还是受制于洋人的软件平台；但是许多人至今还视而不见。

[#1032]为什么我把智能电视、数字家庭和智慧城市三位一体去构思整体设计呢? 其实，从"智能"(即软件运算)的视角看，智能都是位于我所提出TSMC模式的元素里。其中的T是智能电视(TV)元素，S是Sensor(如RFID末梢端)，M是移动端(Mobile，包括手机和车载)，而C是Cloud端。家庭只是一个套件内含TV，城市是更大套件。

[#1033]智慧城市顶层设计是一个复杂系统的设计，分层(layer)是人们面对复杂的＂分而治之＂的模式之一。例如，物联网研究专家王建平在《八论物联网》中阐述的物联网“感知层-传输层-处理层”三层架构。我也分为三层：1)行业区块的服务接口规范层；2)行业型软件开放接口定义层；3)系统实践&开发层。

[#1036]我个人认为：IME属于开发方法，其目标偏于建造一个大型而复杂的系统；而EA属于架构框架，其目标偏于众多复杂系统之间的互联互通(对接)。换句话说，IME目标是开发一个大型的系统；而EA目标在于组合出一个SoS(System of systems)。

[#1037]基于SoS概念和业务合作观点；可规划出这业务区块里的组织单位之间的业务合作(Collaboration)关系，就成为顶层设计里的业务观点(Operational View)。同理基于SoS概念和系统互动观点；可规划出这业务区块里的许多系统单元之间的信息互动(Interaction)关系，就成为顶层设计里的系统观点(System View)了。

[#1038]于二十世纪初，爱因斯坦发表了简单公式：E=MC平方；让人们能理解复杂的质量、能量与光速之间的复杂关系。同理，我也尝提出一个简单顶层设计框架：{一个造形、一个模式、加一层设计} 来协助大家理解复杂的智慧城市规划和建置。

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

[#1040]专利是战略资源，一方面用来阻碍对手的战略资源的调度，来阻止对手战术的获利性。专利可以汇集己方的资源，让己方会赢的战术获利极大化。但是，有聪明人发明战略资源，却没发明配套的战术；没有可获利战术搭配，战略可能只是挂在墙壁上的口号而已。

[#1041]在传统的敏捷开发里，架构设计似乎都被视为手段，产出代码是目地。TDD则检验这个目地产出物，如果不合格就重新调整手段，也重新产出代码。其实，将上述目的和手段颠倒过来，也是可以的。透过检验不同角度的代码，来检验架构；逐渐从各种角度来优化(琢磨)架构，也是一件非常有意义的事。

[#1042]@让您成为杰出架构师 #敏捷顶层设计方法# 敏捷开发为何那么依赖架构师呢? 我认为敏捷迭代的背后有个架构设计迭代来支撑。例如，敏捷迭代的起点：simple solution就来自架构设计迭代的产出物(如附图)。了解这之后，你就不会觉得simple solution很神秘了。更多新思维：

[#1043]<<敏捷初期>>敏捷专家Fred George继续说道："Then I feel comfortable letting the rest of the programming team follow that pattern. That is the "architecture". 敏捷迭代的Simple solution来自架构师的精心构思与减法设计，并产出一种模式(又称造形)，称为架构。

[#1044]<<敏捷初期 >>敏捷专家Fred George说道：As an architect, I will implement the most difficult parts of a system. I call it "pioneering", the process where I see if an idea in my head actually is a good idea. I will always refine the idea in that first implementation.更多新思维：

[#1045]著名敏捷专家Fred George说道：The architect that doesn't carry his vision into code will never gain the insights that our changing industry exhibits. 架构师关注于Vision的落实为代码。敏捷产出代码(C)需要架构(A)、架构设计需要Vision(V)；那么，需求(R)的角色是什么? 是目的，还是手段呢?

[#1046]其实，架构师在减法设计出simple solution时，已经进行了无数次不明显的心智内的迭代了，这种迭代，就是"Mapping from vision to reality"，这个reality包括一般的外在需求、内心的审美、失败经验的限制、自我假设等等。

[#1047]什么是造形呢? 例如软件人员都熟知的类别(Class)，如图。其中的class 是造形，含有两种元素：属性(attribute) 和函数(function)。而Car是拿此造形来产出的实体物-- 一个有利(可换薪水)的类别。而class造形是有用的。您喜欢做有利，还是有用的呢?

[#1048]智能电视、数字家庭、智慧城市的三位一体化<中层设计>。智慧城市的愿景、战略规划：顶层设计、灵活战术：中层设计、基于EIT造形的整体开发<流程>、三位一体的中层设计五大块。阐述了智能电视、数字家庭和智慧城市，三位一体化中层设计的流程。

[#1049]顶层设计应该是指：Top-level Design或High-level Design；而不是Top-Layer 或Top-Tier Design。意味着不同的决策(Decision-Making)阶段的区别。其中，Top-level Design偏于投资决策前的(高阶)设计阶段；而Bottom-level Design则偏于决策后(已经立项了)的实践考虑的细节设计阶段。更多新思维：

[#1050]由于是决策依据，悠关于城市的永续发展，不能一次性的完美的、僵化的大型设计。所以顶层设计必须时时做出能承先启后的最佳设计。因此，顶层设计的过程本身就必须迭代的(Iterative)，依据大环境变化的反馈(Feedback)来触发迭代，带动设计的重构，调整出最适时的新设计来捕捉未来的机运。

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