《架构师应该知道的37件事》

Posted by 高强 on May 22, 2021

总览

出版信息:格雷戈尔·霍培 - 2020.5

给你讲故事

  • 科学分析和故事的一个明显的区别就是后者能够激发情感

IT的50种形态

我想一个人可以像创业者那样有创新思维,像管理顾问那样制作幻灯片,像互联网工程师那样编写代码,还能像企业IT人员那样有政治技能。我会努力成为这样的人

架构师

架构师需要更广的知识面,包括组织和战略方面的能力,工程师则需要专攻可运行软件的交付

Martin Flower 的观点:”架构师最重要的任务之一就是消除软件设计中那些不可逆的决策“

企业里架构师的工作分为以下三个层面

  • 定义IT战略
  • 落实对IT蓝图的管控,以实现协调一致,降低复杂度,以及确保所有系统集成为一个有效整体
  • 脚踏实地地关注项目的实际情况

技能、影响力、领导力

一个成功的架构师必须有”三条腿“才能立足

  • 技能是实践架构的基础点,它需要知识以及应用知识的能力
  • 影响力用来衡量架构师在项目中应用技能后能给项目或公司带来多大的效益
  • 领导力确保了架构实践的状态能稳步向前推进,同时培养更多的架构师

影响力是通过架构实践给业务带来的效益衡量的,通常指增加的利润或降低的成本

他们应该通过传授知识和经验来指导初级架构师,还应该通过出版著作、公开授课、公开演讲、发布研究成果或撰写博客等方式,促进所在领域的整体发展

良性循环

每个架构师都应该知道,纵向扩展能力(变得更聪明)到一定程度就不起作用了,而且存在单点(就是你)失败的隐患,因此,你需要通过传授知识和经验给多个架构师来横向扩展

老话说得好:只有在给其他人讲解某个东西时,你才能真正地理解它。这句话同样非常适用于架构。做一场演讲或撰写一篇文章需要你整理和思考,这通常也会催生新的见解。

偏见

当我们希望规避某个负面事件时,往往会”感觉很幸运”,这种效应被称为损失厌恶

避免决策

架构师最重要的任务之一就是从设计中消除那些不可逆的决策

五问法

要先提醒你的同行,你不是在质疑他的工作或能力,而是你需要详细地了解系统和问题,只有这样,你才能发现潜在的缺失或偏差

反复追问才可以揭示出决策和假设

架构评审不仅仅要验证结果,也要验证结果背后的思考和决策。为了强调这个事实,评审团队应该要求任何提交架构评审申请的团队先提交一个架构决策记录

处理所有问题的研讨会

在大型企业提问的一个显而易见的问题就是,企业人员通常不知道、不会表达或者不愿意回答。 你的日程表会被一大堆研讨会的邀请塞满,然后你会变成所有团队口中的“瓶颈”,因为你无法参加他们的进度会议才导致他们的进度变慢。他们甚至没有说谎! 这种组织化的抵触行为就是【系统抗拒改变】的典型例子

请给我一杯热拿铁

我开始思考星巴克是如何应对这些挑战的,也许我们能从星巴克学习优秀的异步消息传递方案

事务

高吞吐的系统需要针对最优路径做优化,而不是在出错的时候为那些罕见的情况进行事务处理

规范化数据模型

任何不确定性(要豆奶还是脱脂奶)都会在“用户界面”由收银员解决,可以避免那些会增加咖啡师负担的冗长对话

定义软件架构

1995年David Garlan和Dewayne Perry给出的定义: 系统的组件结构、组件的相互关系,以及管控组件设计和长期演进的原则和指导方针

2000年,ANSI/IEEE标准1471选用的是下面的定义(2007年也被ISO/IEC 42010采纳): 系统的基础知识,包括它的组件、组件间的关系、环境以及管控系统设计和演进的原则

The Open Group为开放组体系结构框架(TOGAF)选择了其中的一个变体: 组件的结构、组件的相互关系,以及管控组件设计和长期演进的原则和指导方针。

Desmond D’Souza和Alan Cameron Wills的大作: 有关任何系统的设计决策,能让实现者和维护者免于不必要的创造行为。

决策制定就是架构师工作的重要部分。

架构决策

我认为这就是架构。它做出并记录了重要的决策。决策是受系统所在的环境影响的

关键决策无须复杂

就事后来看,重大的架构决策可能是显而易见的,而且这并不会降低决策的价值

符合目标

一个架构不能简单地定性为“好”或“坏”。更合适的说法是:架构是否符合应用目标

对于架构师而言,一个关键的任务是评估环境和识别候选设计所隐含的约束或假设

通过测试

系统架构不必异常复杂,但是,它必须包含重大决策,而且这些决策要记录下来并且基于清晰的原理。

每个系统都是完美的

系统化思考主要关注系统的行为,而不是系统的结构

反馈回路

系统化思考基于反馈回路等方式来关注和理解组件间相互关联的行为

有组织的复杂性

杰拉尔德·温伯格通过把世界划分为三个区域,强调了系统化思考的重要性。

  • 有组织的简单性

    人们充分理解的运作方式,我们可以精确地计算系统的行为

  • 无组织的复杂性

    它无法让我们准确理解系统在干什么,但是因为行为是无组织的,所以我们可以将系统看作一个整体来观察,而不需要理解系统组件间的交互

  • 有组织的复杂性

    理解结构和系统组件间的交互很重要,但是系统太复杂,无法用一个简单的公式来求解

系统效应

有限理性是诺贝尔奖获得者Habert A. Simon 提出的一个术语,用来描述这样的效应:人们通常只在他们能看到的环境中理性行动

影响系统行为

事件是系统行为的结果,而系统行为又由系统结构决定

公开透明能有效地矫正有限理性,因为它能扩展人民的界限

为了避免公地悲剧,我们需要合理控制资源的使用,比如在市区安装停车计费表以进行收费

系统抗拒改变

系统对改变的抗拒会让系统具有可预见性和稳定性,但是也会让主动改变系统变得困难

简单化和灵活性

最好的抽象能够解决和封装问题中最难的部分,同时仍能为使用者保留足够的灵活性

简单的事情应该简单,但依旧保有完成复杂事情的可能

合适的语言

而实际上应该禁止使用图形用户界面,因为它们不能很好地集成到软件生命周期里, 不可测试,而且容易出错

我本来想要的,但又不敢

架构师的职责就是让广大受众理解所做的决策和假设会带来的影响

写作可以延伸到更多受众

写作是一种可以让我们知道自己的思考是多么草率的一种自然的方法

笔杆子比枪杆子更强大,但仍敌不过企业政治

沟通是个强大的工具,在你的组织里,有些人会竭尽全力去控制它。因此,你不仅要明智地选择目标, 也要确保“弹药”充足

重点突出胜过面面俱到

寻找一个足够大但有意义,足够小但可理解,足够内聚但仍可讲得通的内容范围才是我们的目标

兴奋

如果你觉得在严肃的工作讨论中说令人兴奋有些无聊,那就请回头看看亚里士多德。2300多年前他就指出,一篇好的演讲要基于:理法,即事实和推理;人品:即信任和权威;情感:即共鸣的情绪!大多数的技术演示会包含 90% 的理法,9% 的人品和 1% 的情感

聚焦目标

糟糕的是,其实没人对你的工作过程感兴趣,人们想要看到你取得的成果

给银行劫匪画像

有些人能够构建系统,但并不意味着同样的人也擅长以直观的方式展示系统架构。因此,帮助这些人绘制系统图像是很有价值的事情。我把给别人绘像的架构师比作刑侦肖像专家

每个人都看到罪犯

–知道一件事、能够把它表达出来以及能够绘制出来,是三种截然不同的技能–

系统隐喻

我们需要强调架构的目标。架构是为了给每个人提供一个连贯的工作故事,一个易于在业务和工作人员之间共享的故事。通过要求隐喻,我们很可能得到一个容易沟通且精心制作的架构。

演示技巧:图

你需要的“精髓”:团队还有其他可选的设计吗?方案之间的差异是什么?你是根据什么设计原则判定某个方案比其他的好?系统的主要模块是什么,它们又是怎么交互的?你是如何查找性能瓶颈的,又从中学到了什么?

组织

好的架构师不仅要理解系统组件之间的关系,而且要清楚在这个称为组织的大型动态系统里人际和部门间的关系

控制只是假象

当别人说的是你想听的东西的时候,你会觉得自己在掌控着局面

反馈中的问题

听说西瓜状态的这个词的人都明白:这些项目对外展示的状态是“绿色”的,但内部其实是“红色”的,这就意味着,他们表面上进展顺利,实际上却存在严重的问题

普鲁士人并不笨

知识差距是期望知道和实际知道之间的缺口,校准差距是计划和行动之间的缺口,效果差距是行动的期望效果和实际效果之间的缺口

预警系统

只有你把控制看作向目标引导同时又补偿外部影响的方法,再加上对系统行为的仔细观察,控制才能不再是假象

避免同步点 – 会议无法扩展

从系统设计角度看,会议有另一个麻烦的特性:它要求多个人(绝大多数情况下)在同一时间出现在同一个地方。在软件架构中,我们把这称为“同步点”,大家都知道它是吞吐量的最大障碍之一。同步点几乎总是意味着某些参与者或组件在等待其他参与者或组件(他们就是这样才变得“同步”),这种等待限制了系统的吞吐量

快速与敏捷

敏捷方法是通过频繁的重新校准和拥抱变化来达成正确的目标,而不是试图预测环境和消除不确定性

转型

架构化思考会帮助你像理解复杂系统一样理解组织。良好的沟通技能可以帮助你获得支持,而领导技能则是持久变革不可或缺的要素

最后,IT架构技能可以让你实现必要的技术变革,这些变革能让组织以不同的方式运作

当我们提及IT转型时,说的不是增量式的进化,而是对技术全景图、组织机构设置和企业文化进行根本性的重建。

为了能影响组织的持续变革,你需要明白以下事项

  • 组织如果没有痛苦就不会改变
  • 如何通过展示更好的做事方式来引导变革
  • 为什么组织需要以速度经济而不是规模经济的方式思考
  • 为什么无限循环是数字化组织不可或缺的组成部分
  • 为什么过度购买IT服务是个谬论
  • 如何通过减少排队时间来让组织提速
  • 如何能让组织从新的维度思考

转型的各个阶段

为了说明一个人或一个组织在改变他们的习惯时需要经历的阶段,我举个某人从吃垃圾食品转变为健康生活的例子。在没有科学证据的情况下,我快速列出如下10个阶段

  • 你吃垃圾食品,因为它们很好吃
  • 你认识到吃垃圾食品对自己不好,但是你还是继续吃,因为它们确实很好吃
  • 你开始看夜间电视减肥节目,同时还吃着垃圾食品,因为它们真的很好吃
  • 你从夜间电视节目里采购了一部神奇的健身器械,因为用它减肥看起来很容易
  • 你用了几次这部器械,发现锻炼真的很艰苦。更糟糕的是,在使用这部器械的两周里,你并没有获得明显的健身成果。由于失望,你吃了更多的垃圾食品
  • 你强迫自己坚持锻炼,即使那样很艰苦,然后瘦身成果慢慢地显现了,但你还是会吃一些垃圾食品
  • 你强迫自己吃得健康些,但是你发现健康食品并不好吃
  • 你实际上开始喜欢上蔬菜和其他健康食品了
  • 你开始对运动上瘾了。你健身的动机已经从减肥变成了做自己真正喜欢的事情了
  • 朋友们都在问你是如何做到的。你现在已经变成了激励其他人的榜样。变化是渐进发生的,需要付出大量的时间和心血

发动机调优

当你想改变一个公司的行为时,需要看看其他“发动机”,即员工和他们的组织方式。这样做并不轻松,却是唯一行之有效的方法

不变革的痛苦

但安于当前状态是阻碍变化的主要力量,这反而会带来更大的不确定性

引导变革

想要成功,你需要坚定的信念,并坚持不懈

拖拉机超过了赛车

应用不同的方式引导变革时,有一点特别危险,那就是已经存在的且效率低下的方法通常更适合当前的环境。这就是系统抗拒改变的一种表现形式,它会让你精心设计的软件、硬件或开发方法受到旧有方式的打机

盲人乡

随着时间的推移,复杂的组织系统会适应特定的模式,并会主动抵制变革。如果你想改变系统的行为,就必须改变系统本身

可预测性的价值和成本

过分追求可预测性会导致另一个著名的现象:堆沙袋。通过高估时间线和成本来规划项目和预算,以便更容易地实现他们的目标

创新者的窘境

大多数创新产品在早期阶段无法与现有产品的性能和盈利能力相媲美。因此,传统的预算流程可能会拒绝有希望的新想法,这就是由克莱顿·克里斯坦森所命名的创新者的窘境的现象:颠覆性技术可能会遭受拒绝,因为它们最初不能满足市场的需求。然而,当颠覆性技术随后超越了现有技术时,就会对那些没在早起阶段投资这些技术的组织造成威胁。

文化变革要由内而发

John Roberts 将组织的描述特征划分为PARC – 人员、架构(结构)、例程(流程)和文化。重组和流程再造可以相对容易地改变系统的架构和例程,但是文化变革必须由公司的领导层来灌输

一些排队论知识

利特尔法则的公式是 T=N/x ,它表示在一个稳定的系统中,总处理时间 T (包括等待时间)等于系统中的项目数量N(队列中的项加上正在处理的项)初一处理速率

在一条线上生活

IT架构需要专业的权衡:灵活性带来复杂性,解耦增加延迟,分布式组件引入通信开销

更高的自由度

众所周知,测试只能证明存在缺陷,而不能证明没有缺陷

改变曲线的形状

但这正是数字化公司所取得的成就:它已经大幅度调整了曲线,以实现IT产品在交付过程中前所未有的速度,同时还保持了功能的质量和系统的稳定性。他们是怎么做到的呢?一个重要的因素是遵循速度优化的流程,而不是资源利用率或进度可预测性的流程

质量是什么

生活在数字化世界的公司不会假装知道客户需要什么,因为他们正在打造全新的解决方案。他们不会询问客户想要什么,而是观察客户的行为。根据观察到的行为,他们会快速调整和改进产品,通常会使用A/B测试来试验新功能

架构IT转型

因此,要带领组织进入未来的数字化世界,就需要对底层技术及其在竞争优势上的应用程序有透彻的理解

组织的主要竞争资产就是自身的快速学习能力。外部顾问和供应商可以提供给帮助,但不能代替组织自身的学习能力。因此,架构师需要驱动或者至少支持从组织内部发起的转型

在数字化颠覆时代,IT架构师的工作变得更具挑战性:不仅要与更快的技术演进保持同步,而且要精通组织工程和理解企业战略,此外,与上层管理者沟通现在也成为了架构师本职工作的一部分

就像电影《黑客帝国》一样,人们可能会发现自己置身于新的数字化现实中,但这可能并不完全符合他们的预期。我知道的一次架构师会议就充分地展现了这一点:会议期间,一位架构师声称,要让转型的尝试获得成功,就要让架构师的生活更轻松些。如果改变公司的IT环境,只是为了让一个人的生活变得更轻松,那注定会让人失望,也难以引进数字化未来。

当我发现有人不作为的时候,我首先倾向于比较温柔的方式,然后“逐渐加重”沟通语气