By 高煥堂  2013/04/10

        新一代的<创新&敏捷架构设计>，又称为 <创新组合派架构设计>，其重视“未来性”。它以”组合”为目标，先定接口(Interface)来支持组合，并以接口包装内部的结构，让内部结构也是可以变动的，以便支持弹性地敏捷重构。例如，软件层的Socket接口可以是较稳定的，此接口的实现类内涵可变动，包括Socket接口在通信层的实践通信协议(如SOAP、WiFi、Zigbee、蓝芽等)都是可重构的，让系统具有高度敏捷性、未来性。
       

1、从<抽象思维派>到<创新组合派>架构设计

       由于架构设计有两个基本技艺：抽象与组合(封装)。因此衍生两个不同的架构设计流派：

  • 抽象思维派：致力于抽象出稳定、可靠、不变的共同性架构；亦即，追求<万变不离其宗>的宗。
  • 创新组合派：致力于组合出具体独特性的创新架构；亦即，追求<与众不同>的特质。

       相对上，新潮的<创新组合派>比较能陪伴你在移动互联网、云计算的潮流中，能如鱼得水、展现无比的创造力。通常，架构师都必须兼顾两者，仍然必须时时梳理和强化<抽象思维派>技艺，这是有效架构师的必备能力。
       <创新组合派>重视“未来性”。它以”组合”为目标，先定接口(Interface)来支持组合，并以接口包装内部的结构，让内部结构也是可以变动的，以便支持弹性地敏捷重构。例如，软件层的Socket接口可以是较稳定的，此接口的实现类内涵可变动，包括Socket接口在通信层的实践通信协议(如SOAP、WiFi、Zigbee、蓝芽等)都是可重构的，让系统具有高度敏捷性、未来性。
       <创新组合派>重视“落地性(可实现性)”，这也符合敏捷开发的原则，就是坚持一个美好的信念：
             “各项架构设计决策都必须能迅速落实为代码”。
       
       为了特别强调架构与代码两者之间的无隙缝衔接，高焕堂老师特别设计了EIT代码造形，让组合创新派的设计核心：接口(即EIT的<I>)能直接落实到代码。因之，EIT造形是架构与代码的优先交汇点。也能进一步，成为敏捷开发的起始点(Simple solution)；所以EIT被称为：从架构到代码的捷径。关于EIT造形的介绍，可参考网站: ( http://223.26.63.39/?p=138 )。
       <创新组合派>最传神的隐喻是，谷歌公司副总Marissa Mayer所提倡的：
              “创意爱上限制”(Creativity loves Constraint)。
       
       她说：”创新来自愿景与限制的互动”(Innovation is born from the interaction between constraint and vision)。限制迫使架构师重新审视愿景(Vision)，从不同观点切入，寻找新事物；同时也让其聚精会神、厘清思路；非常具有创新性。
       在软件开发领域中，上述的限制主要来自系统”需求”(Requirement)；需求是用来检验(Test)架构的。因此，需求在上述两个派别中，其扮演的角色是不一样的：

  • 抽象思维派：需求是架构设计的基础；所以又称为Requirement-based架构设计方法。
  • 创新组合派：愿景是起点，创新组合是目标，需求用来检验；所以又称为Test-Driven架构设计方法。

       此外，上述的创意主要来自设计思考(Design Thinking)模式，就是：溯因(Abductive)逻辑思考。无论是移动应用、物联网等都涉及愈来愈多的系统组合或整合。而软件开发(如敏捷方法)，愈来愈仰赖架构设计，所以架构师们亟需要去学习和领悟创意型的架构设计模式。
       俗语说，内行人看门道；专业的视角、专业的造形(Form)和模式(Pattern)就是其中之道。因此，希望您能以内行人的视角，领会设计思考、设计出未来性、落实为代码、且需求检验架构。于是，确保了架构设计的最佳性、可实现性和团队的敏捷性。

2、<创新组合派>架构设计的特色

2.1  仍然是以<抽象思维派>为基础

  • 抽象(思维)派：抽象出稳定、可靠、不变的共同性架构：
  • (创新)组合派：增添一个”合”元素，组合出具体独特性的创新架构：
  • “合”元素的影响：以”组合”为目标，先定接口(Interface)来支持组合，并以接口包装内部的结构，让内部结构也是可以变动的，以便支持弹性地敏捷重构。

2.2  架构设计决策的未来性

  • 架构师的职责是致力于现在决策，并让它能包容未来的变化，也就是让<目前决策>具有未来性。
  • 架构师不是去预测未来，不是去关心<未来决策>、或去替未来做决策。
  • 未来环境是善变的、市场需求也往往如流水般不可测；也就是因为它的未来的不可测性，所以我们需要优越的架构设计。
  • 例如上图所示，有两个软件模块：C(Client)模块与S(Server)模块；而且两者之间透过网络通信机制来互通。此时一般人会先去寻找标准的通信机制(如协议)，然后才开发C和S软件模块。这就是预测未来(通信途径)了，会让软件架构失去未来性，所以不是有效的软件架构设计思维

2.3  迅速落实为代码(Code)

  • Kent Beck曾说：”代码是设计(Design)与现实(Reality)的明暗交会处”。
  • 代码是架构的外貌：
  • 为了让架构与代码两者能无隙缝衔接，高焕堂老师设计了EIT代码造形，让接口(Interface)的设计，能够直接落实到代码：
  • 透过接口的落实为代码，及早检测(如TDD)，促进互联互通&信息共享

2.4  需求(Requirement)的角色

  • 抽象思维派：需求是架构设计的基础；所以又称为Requirement-based架构设计。这是Waterfall开发过程所仰赖的架构设计途径。
  • 创新组合派：愿景是起点，创新组合是目标，需求用来检验；所以又称为Test-Driven架构设计；或TDD( Test-Driven Development)方法：
  • 在TDD检验机制里，需求是架构设计的限制(Constraint)；而不是架构设计的基础。这反而让架构师获得更大的创意空间。
  • 所以，谷歌公司副总Marissa Mayer提倡：“创意爱上限制”(Creativity loves Constraint)。她说：”创新来自愿景与限制的互动”(Innovation is born from the interaction between constraint and vision)。限制迫使架构师重新审视愿景(Vision)，从不同观点切入，寻找新事物；同时也让其聚精会神、厘清思路；非常具有创新性。

2.5  创新的来源：设计思考(Design Thinking)

  • 需求善变的项目开发需要敏捷，敏捷需要搭配<创新组合型>架构设计师，架构师需要设计思考技巧，设计思考仰赖溯因(Abductive)逻辑推理能力。
  • 溯因推理是由观察现象(结果)到原因的猜测推导过程，沿着现象的特征往回追溯产生该现象之原因；它是除了演绎推理、归纳推理之外的第三种逻辑推理方法。运用这种方法去猜测现象的可能原因，受逻辑规则制约的程度较小，具有高度的灵活性，是一种颇具创造性的推理方法。如下左图所示。
  • 敏捷开发的幕后思维，就是 {溯因逻辑 + 迭代过程}，如下图所示。
  • 在一个企业(或公司)里，程序员、架构师和高层经里三者之间有着”战术引导战略”的重要关系。经理与架构师之间是：战略-战术关系；而架构师与程序员之间也是：战略-战术关系。敏捷方法，让”战术引导战略”的机制实际运行起来，例如TDD对代码(战术效果)检验的反馈，带动了架构的重构(战略调整)。
  • 传统上，关于”架构设计”往往比较重视”架构”而不是”设计”，因此对于设计思考、设计技术并不太重视；这常常导致：没有设计的架构。

3. 看待软件架构的十个重要视角

3.1  API = 话语权

  • API与UI不同
  • UI是App与用户的交互接口
  • API则泛指软件模块间的接口，可分为：
  •      SI：本架构与外部系统之间的接口
  •      PI：本架构与内部挿件(Plug-in)之间的接口
  •      一般API：本架构与应用程序(App)之间的接口
  • 掌握API定义权，就拥有话语权

3.2  应用框架 = 用来框住应用(App)的架构

  • 框架的基本组成元素：EIT代码造形(Form)
  • EIT造形的<I>就是API
  • 框架是鱼饵，API是鱼钩
  • 鱼饵是送人的礼物；送越多，拥有市场版图越大

3.3  框架(平台)调用App，不是App调用框架

  • 用户并非直接碰触软件(App)
  • App在软件架构里，其地位是最低的
  • 例如，从移动终端发信息给云平台时，云端的IaaS层先接到信息；然后才(调用PaaS服务)来将信息往上送；再调用SaaS层服务来将信息送上去

3.4  从<C/S API>到<端/云API>

  • API是分工的界线
  • 过去，Client与Server是由不同团队分工开发的：
  • 今天，谷歌、Facebook、微信等，改变了API、改变了分工，如下图所示：
  • 这称为跨<云&端>强龙企业

3.5  架构师做<分>的决策，开发者做<合>的任务

  • 肯德基餐厅的厨师做：庖丁(分)解鸡
  • 肯德基柜台人员则做：组(合)出全鸡、半鸡等套餐
  • 分得妙、就合得快
  • 分：无之以为用；合：有之以为利
  • 因<分>而得接口(Interface)，依据接口而快速组<合>

3.6  <分>的时间点：买主来到之刻

  • 平台(Platform)设计者，必须重视买主，而不是用户
  • 买主来到之前，先做分(即无之)
  • 买主来了之刻，才做合(即有之)

3.7  没钱就改版，改版就有钱

  • 拥有平台(Platform)者，常采取分层(Layered)架构，适合理的
  • 过去，上层模快(开发者)，常常要求下层必须稳定不变
  • 今天，上层模块不能要求底层的稳定不变，而是要处处维护底层变动的自由度；这样才能实现：没钱就改版(底层)，改版就有钱

3.8  如何跨(别人的软件)平台

  • 除了大家熟悉的HTML5/JS途径之外，还有没有其它跨平台的模式呢?
  • 目前的软件平台大多采框架(Framework)来提供API
  • 于是，我们的跨平台策略是：协天子以令诸侯
  • 这将别人(平台)的API，改变成为自己的API，掌握了API就有话语权

3.9   软件平台 + 通信网络平台

  • 软件平台与通信网络平台是两的层级
  • 网络平台是以电信网络为中心，后端(云端)和终端各挂在网络的两端；两者都是网络平台的插件
  • 软件平台则想办法让网络被包容起来，反过来让网络成为软件平台的插件；这是为什么三网融合可能帮三个软件平台抬轿的原故
  • 这种架构设计的关键思维是：不能将软件切分为端与云两块，且当成网络平台的插件
  • 软件平台就像集装箱(Container)，将复杂的通信网络、硬件接口、内容格式等包装起来，呈现出简单外形，让人们感到这些事物的可爱、好玩好摸好抱。并没有删除外在事物(如冰箱等)的复杂。而只消除人们心中的复杂感觉，达到简化目的。
  • 例如，Google公司的软件平台(含Android)正好横跨&控制整个互联网
  • 软件平台控制网络平台，而不是将软件切分为两块，分别挂在网络平台的两端：终端与云端。

3.10  项目管理：搭配敏捷(Agile)或RUP的跌代(Iteration)过程

  • 架构的一生：架构的主人是愿景(Vision)，架构的生母是问题(Problem)，架构的养母是现实(Reality or Constraint)，架构的养份是设计师的创意(Creativity)，架构的外貌是代码(Code)，架构的情人是需求(Requirement)，架构的岁月是迭代(Iteration)

 ~ end ~