ITPub博客

首页 > 数字化转型 > ERP > [转载]智能&大数据时代, 架构师思维的十个学习步骤&演练 By 高煥堂

[转载]智能&大数据时代, 架构师思维的十个学习步骤&演练 By 高煥堂

ERP 作者:risingsunczl 时间:2017-03-19 11:59:30 0 删除 编辑

架构师的第一步:学习两种抽象视角(Abstraction View)

  • 第一种抽象视角:架构师基于<变与不变分离>的视角,寻找<万变不离其宗>的宗,其宗(架构)的不变性带来简单性;让人们能透过掌握简单来驾驭复杂(多变),落实了架构师的职责。

  • 第二种抽象视角:架构师基于<形与内涵分离>的视角,由于不同内涵之间的<变与不变分离>已经由第一种视角所抽象了。这个视角可从内涵中抽像出共同之形,也可以(无中生有地)创造一种(Form)来容纳内涵(包括变与不变部分)由于我们常常拿船运业的集装箱(Container)来比喻<造形>;而拿形形***的货品来比喻其(集装箱)内涵(Content)。所以上述的第二种视角,又称为<集装箱式>抽象视角。

实战演练==>架构师集装箱式抽象视角


架构师的第二步:关心下层的变动自由度(没钱就改版,改版就有钱)

----架构像什么有两种常见的比喻。

  • 架构像房子的地基(1比喻):由于地基要稳定,上层房子才不会倒塌;因此这项比喻让架构师认为架构要稳定,上层的业务应用才会稳定可靠。这种比喻偏于寻找不变,而不是追求创新。

  • 架构像一棵树的树干(第2比喻):由于树根必须不断成长,拥有随环境而变动的自由度和活力;才能有效吸收更多水分和养分。这项比喻让架构师关心底层模块(Module)的变动自由度。具有活力的树根和树干,才能有效之撑上层业务应用的蓬勃发展。

实战演练==> 维护底层模块的变动自由度(第2比喻)


架构师的第三步:<系统架构控制力>支撑<商业竞争话语权>

----软件系统就像一个国家的军队,商业模式就像一个国家的实力。

  • 架构师的职责就是要在一个系统架构体系中,替自己公司的软件系统(或模块)在架构体系中,取得制高点、取得控制力。

  • 一个企业,如果在系统架构体系中,处于弱势地位的话;我们就很容易看出,它在商业竞争中,就难以取得话语权。

  • 例如,曹操留给后代极高的政治智慧:挟天子以令诸侯。系统架构师也能运用这项智能,来取得系统架构体系中的控制力或主导权,来支撑该公司商业竞争的话语权或强龙地位。再如,Android架构师运用HAL驱动框架,来争取众多硬件厂商的支持,让Android取得系统控制力,支撑Google的商业强势地位。

实战演练==> 掌以握<系统控制点>支撑<商业话语权>


架构师的第步:<用户体验>是让用户享受从简单中叫出复杂的满足感

----架构设计就是架构师从复杂中找出简单的设计过程。架构师从复杂中得出简单,其目的是要让开发者(Developer)能从简单中反过来掌握复杂;或者让用户(User)能从简单中叫出复杂,并获得其中的满足感。茲說明如下:

  • <用户体验是是让用户享受从简单中叫出复杂的满足感>这是苹果公司乔帮主(Jobs)的名言。因为智能化设备的功能内涵愈来愈复杂,如果缺乏有效的架构师来设计出简单,而让用户直接面对复杂,用户会感到害怕;就欠缺满足感。

  • 在科学上也是如此。例如,牛顿从很复杂的力学中总结出了f=ma公式,大家就能从这简单公式而去掌握复杂的力学了。爱因斯坦也一样,他从复杂的规律中找出简单的E=mc^2质能互换公式,大家就能从这简单公式而去了解复杂的质能世界了。

  • 为什么说它简单呢理由之一是:公式的元素不超过三个,比如说,牛顿力学公式里只有Fma三个元素;爱因斯坦的公式也一样,只有Emc三个元素。簡單的元素和公式(造形)卻蘊含極為複雜的內涵。

  • 同样地,EIT造形的要素,也刚好就是三个简单的元素和造形却蕴含极为复杂的内涵,简单而优雅的接口<I>带给开发者和用户享受掌握复杂的满足感。

实战演练==> 从复杂设计出简单,从简单来掌握复杂


架构师的第步:创意爱上限制,即需求检验设计

----无论是移动应用、物联网等都涉及愈来愈多的系统组合与创新。而软件开发愈来愈仰赖架构设计,所以架构师们亟需要去学习和领悟创意型的架构设计模式。這種新模式中,最传神的隐喻是,谷歌公司副总Marissa Mayer提倡的

        “创意爱上限制"(Creativity lovesConstraint)

她说:"创新来自愿景与限制的互动"(Innovation is born from the interactionbetween constraint and vision)。限制迫使架构师重新审视愿景(Vision)从不同观点切入,寻找新事物;同时也让其聚精会神、厘清思路;非常具有创新性。这引导出架构设计的两个观点:

  • 观点1:架构来自需求。其意味着,基于需求而设计。也就是传统的Rewquirement-based架构设计。

  • 观点2:架构基于愿景(Vision)的引导,来自架构师的创意其意味着,基于愿景而设计,需求用来检验架构。一旦创意设计<爱上>了需求的限制,架构(设计)自然心甘情愿地满足需求(限制)

既然是观点,本身就没有对错。架构师同时拥有多个观点,常常会带来更多创意的。

实战演练==> 创意爱上限制,需求检验设计


架构师的第六步:练习假设性思维然後”Mappingfrom vision to reality”

----愿景是对未来成功情境的想象,含有浓厚的假设性(梦想)。基于假设情境而设计,常常让许多人感到不安。由于,架构师的职责是设计一个有效架构,既能支撑业主的愿景(Vision),又能满足现时环境(Reality)的需求限制。也就是,架构师要找出一条从愿景映射到现实的一条连线(Mapping from vision to reality),让其它团队成员能依循这条线而去实现该假设性愿境(梦想),于是梦想成真了。在迈向智能化的大数据时代,熟练假设性思维是很关键的,理由是:

  • 由于数据量的庞大和异型化(Different Fomat),如迷雾一般,欲取的市场竞争优势,如同想从大迷宫里找到出口,最有效的途径是:基于(假设性)想象多个最可能的出口,然后逆向推理,倒过来寻找出有效的路径(线)

  • 苹果公司乔帮主(Jobs)的名言:你不可能在眺望未来时把生活中的每个点连接起来,只有回顾时能才连点成线。许多人并不知道,他所提的就是架构师的关键任务:找到愿景(Vision)与现实(Reality)间的连线。这是有效架构师必备修练。

实战演练==> 练习<假设性思维>和 Mapping from vision to reality


架构师的第步:清晰而明确表述接口(Interface)

----基于前面第一步的两个视角而抽象,都产生了<分离>的动作。分()是手段,而()合是目的。分离动作则产生了接口,做为后续组合的依据。分得愈美妙就能组得愈快速。分与合两项动作,往往时间点不同,执行者也不同;属于跨时空、跨团队的分工。因而,主导分()的架构师,必须清晰地表述接口,并明确传达给担任()合的人员。那么,又如何清晰表述接口呢有效的途径是:擅用<EIT造形(Form)>。兹说明如下:

EIT造形是由3个类(Class)所构成的。分别以<E><I><T>来代表之。从架构师角度上,<I>属于主角,而<E><T>是配角。搭配两个配角,才能将<I>表述的完整而清晰。就如同英语,搭配了主词(Subject)和受词(Object) 两个配角,就能够将动词(Verb)表述得更完整而清晰。例如,

  • Play---没有主词和受词,动词<play>就显得意义不够清晰。

  • (play) 绣球---有了主词和受词,动词<play>就显得意义很清晰。

  • 老师(play) 钢琴---有了主词和受词,动词<play>就显得意义很清晰。


----搭配了两个配角(主词和受词),主角(动词)的涵意就显得更完整而清晰了。同理,架构师只要采用EIT造形,就能将接口表述得完整而清晰了。[歡迎光臨高煥堂的博客首頁:http://www.cnblogs.com/myEIT/ ]。

实战演练==> 清晰而明确表述接口(Interface)


架构师的第步:尽快对接口进行检验和测试

----基于EIT造形属于代码层级的造形,能迅速实现为软件代码,并进行电脑的实际执行、检验和测试。软件的编程开发是一件费时的事情,等待各层面的细节设计&代码开发之后,才进行系统模块之间的检验和整合测试,往往会将检验和测试工作时辰延后,这将大幅升高系统整合的风险与提高项目开发的整体成本。尤其像Android平台的终端<软硬整合>产品开发,硬件需要迅速与软件进行整合设计(Co-Design),才能有效降低软硬整合的风险,缩短开发时程,并提高产品可靠性。擅用EIT造形,将很容易落实这个步骤的任务,如下说明:

  • EIT造形的<I>是主角,架构师必须清晰而明确定义之。至于<E><T>都是配角,开发者可以做<假模块(Mock)>来实现<E><T>配角,进行对<I>的模拟测试。就如同飞机架构师会设计<风洞>来模拟测试飞机的机翼一般。

  • 目前市场上,有许多测试环境提供了Mock-based的整合测试工具,能迅速开发出 Mock<E>Mock<T>来测试<I>,非常有助于落实这个步骤的任务了。

  • 例如,想测试ClientServer模块之间的真实接口<I>。就能设计Mock<E> Client衔接;并且设计Mock<T>来与Server衔接;于是既使CleintServer两个模块都还没开发,也能迅速开发出 Mock<E>Mock<T>来测试真实接口<I>

实战演练==> 尽快对接口进行检验和测试


架构师的第九步:设计<通用性>接口,成为框架(Framework)核心要素

----架构师如何给自己创造重构的自由度,以及支持开发者重构的空间,是框架设计的关键议题。这种自由度,决定于架构师是否能仔细分辨出:关注<未来的决策>与关注<今天决策的未来性>的微妙差异了。愈是能关注<今天决策的未来性>,而不是关注<未来的决策>,就愈能创造未来重构的自由度。例如,EIT造形和框架的主角都是接口<I>,愈是关注<目前决策的未来性>时,就愈会想去设计通用性(General)<E><I>来包容未来<T>的多变化。而一群<E&I>的巧妙组合,就成为框架了。通用性接口有两层意义:

  • 容纳买主需求(或选择)的未来变化,或容纳新买主的新选择。兹拿汽车来做比喻,当买主买了车子之后,未来随时可以改变选择(沙滩、公路或高山)。例如,买主未来决定将车子要到沙滩上跑时,只要更换新轮胎就行了;这展现出架构师目前决策的未来性。

  • 限制买主的选择范围。买主抉择的改变,表现于应用软件(App)上,架构师设计通用性接口来<框住>各种App,限制买主的抉择空间,才不会失控。这些通用性接口的有机整合体,就称为软件框架(用来框住App的架构)

实战演练==> 演練_设计通用性接口


架构师的第十步:有效减法设计,才能开放加法(设计)

----幅员愈大的国度、大数据应用愈发达的国度,加法(设计)的幅度就愈大。加法设计幅度愈大,系统的复杂性和差异化就愈显着,此时标准化和统一化的呼声就愈高。无论是标准化或统一化,都意味着加法设计的大量推进,导致系统复杂而难以驾驭;因而要求架构师提出有效的减法设计方案,从复杂中设计出简单,让人们能简单中来掌控复杂。就架构师而言,基于有效减法的架构设计,才能开放人人去做加法设计。兹说明如下:

  • 秦朝时代唯有书同文、车同轨的有效减法设计,才能开放加法,整并六国成唯一个大国。

  • 唐朝的诗叫做七言绝句,如姑苏城外寒山寺,夜半钟声到客船,一首诗四个句子,每一个句子七个字,它的韵律有两个平平仄仄平平仄,仄仄平平仄仄平,这是唐诗的主要造形(Form)

  • 秦朝的<书同文、车同轨>,加上唐朝的<诗同形>,有效的减法设计,创造了大一统(加法)的辉煌国度。

  • 君不见,在前面各步骤里,诸如:从复杂中设计出简单、以需求检验设计等都是基于有效的减法设计,一方面给设备供货商一个开放的加法设计空间;另一方面则让用户享受从简单(来自减法设计)中叫出复杂的满足感。

  • 此外,在前面各步骤里,诸如:EIT造形、通用性接口和软件框架(框住某些东西)等,则是减法设计的实践技术;基于这些有效的减法设计途径,才能大幅开放加法设计;因而落实了:从简单中掌握复杂。[歡迎光臨高煥堂的博客首頁:http://www.cnblogs.com/myEIT/ ]。

实战演练==> 有效减法设计,才能开放加法

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/653579/viewspace-2135620/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 没有了~
请登录后发表评论 登录
全部评论
  • 博文量
    130
  • 访问量
    1793345