A段架构设计_隽语集(Business Thinking _1101)

前言：由于中国是一个幅员广大的国家；基于区域性优势的发展，顶层设计不宜对战术(“具体可操作性”)层面做严格性规范。于是特别强调战术的弹性(Flexibility)、复用性(Reusability)和相似性(Similarity)，非常有助于维持愿景和战略的有效性和稳定性。基于EIT造形的复用性，人人都能依循EIT造形(如唐诗之形)、撰写其代码(如诗里的文字)、充实其意境(如悲欢离合)。让原来逻辑严肃的IT世界，增添了不少诗情话意的美感。回顾中国历史，秦朝的书同文、车同轨，加上唐朝的<诗同形>，开启了国力雄厚、文创鼎盛的年代。  

  

本书缘由：高焕堂于2013年在日本退休之前，基于日本师徒制的要求而传承给下一代架构师的架构思考技术(俗称设计心法)。25年来他专精于A段(投资决策前)架构设计，退休闲暇将之写成中文，欢迎大家指教。A段与B段架构设计的区别是：A段算计敌人，B段设计自己。例如，B段心想如何设计<轿子>(如Android平台)；A段则心想如何设计<别人>(如硬件厂商)来抬我们的轿子。 

目录：請看目錄  

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

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

ee                                                                                 ee

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

  

[#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]#架构设计&顶层设计# 从<业务架构层>到<系统架构层>的减法设计。此时采取来协助减法设计，让业务架构层面的千变万化面貌下，能取得系统设计层面”书同文”，基于共同的概念和术语(如、和等元素种类名称)，来减化复杂性，提升系统的互通性。

 

[#1144]@让您成为杰出架构师#架构设计&顶层设计# 顶层设计常见迷思是：没有厘清"互通性"与"共同性"的微妙差别。一般人常常误认为建立共同性(如建立共同平台)，是实现"互通性"的有效手段；其实不然。因为，城市里各区块已经有了各自系统或平台了，已经没有机会重新建立一个新的共同平台了。更多新思维：http://t.cn/8FbhmdD

 

[#1145]#架构设计&顶层设计# 从<系统架构层>到<中层设计>的减法设计。此时采取来协助减法设计，让系统架构里的互通接口规范部分，能落实微软件代码，并取得软件接口设计上的”诗同形”，就像唐诗三百首一样，据有共同的造形(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

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