读《Software Systems Architecture》（07）—— The Architecture Definition Process

作者：术子米德

2022 年 6 月 14 日
本文字数：1825 字
阅读完需：约 6 分钟

🤔☕️🤔☕️🤔

读《Software Systems Architecture》（07）—— The Architecture Definition Process
📖：架构定义过程（Architecture Definition Process），像水流一样，从开发最早，很多未清晰，就已经发源，持续流淌到项目结束。
🤔：过程（Process）vs 进展（Progress），差别是什么？前者是设定一个起点和终点，从起点到终点的整个的路径，或者所有可能的路径，叫做过程。后者是设定两个里程碑点，这两个点之间的变化，尤其是正向的变化叫做进展。所以说，谈过程的关键是要抓路径，有哪些路径可以走，以及如何走这些路径。
📖：指导原则【1】架构定义，驱动力必须来自利益相关方关注点，并且得有效平衡冲突和不兼容的关注点【2】有效沟通【3】始终贯彻执行【4】结构化输入-处理-输出，清晰定义和明确步骤【5】务实【6】灵活【7】不绑定实现技术【8】成为软件开发生命周期的一部分【9】对齐软件工程实践和质量管理标准。
🤔：利益相关方的关注点驱动架构，这一点粗看很有道理。只是没有实际操作的边界感。假设，一开始能够找出所有的利益相关方，并且各自的关注点能够准确表达，在如此理想的局面下，要做的就是把关注点进行分类和梳理。也就是说，这时候需要的是如何准确理解关注点，并且把加强目标、拖歪目标、拉翻目标的各方梳理出来。实际上，不会有这么理想的情况。一方面，不会有清晰的关注点，另一方面，区分关注点对目标的影响，也绝对不是按颜色划分一下棋子这么简单。
🤔：实际中的利益相关方，最容易识别的就是推动项目进展的人。最不容易识别的是无视项目进展的人，尤其是可以对项目资源进行调配、却一直游离在项目之外的人。如何识别出来并让他受益，说白了就是怎么拉进来一起干，这得时刻琢磨。还有就是，随着项目进展，受到新的关注后，会冒出新的利益相关方，他的出现很容易破坏现有的利益平衡。
🤔：让参与其中的人，都能够从中受益，这句话应该是正确的假话。尽量让参与其中的人，尤其是被项目影响的人，处境因此而不会变差，这该是务实的真话。关注处境的变化，就是在盯住技术效果的反馈，是否能通过这样的关注，发现技术作恶的情况。
📖：需求（+规格）——架构定义——创建（+设计）
🤔：需求的规格出来之前，架构在干嘛？以我的经验，需求到来，谁最先接收到需求，会影响到架构师参与的时刻点。如果组织输入需求，直接由架构方接收，这是我认为最理想的情况，架构方有全部需求的历史，新需求的到来，首先会跟历史对比，小功能需求，现有架构能满足，直接转设计即可，现有设计无法满足，此时就得开展架构级的需求分析，即此需求分析的结果，或多或少会影响现有的架构，架构得有所变动，才会推动实现设计。
🤔：另外，谈到需求，总是觉得它是外源性，即它来自客户。实际上，在一定积累的组织里，在有产品定义和规划的组织里，很多需求来自组织自身，有新特性、有旧改进，还有更多降本提效方面的需求。当然，更有所谓的产品经理追求的特性。
📖：Engage Stakeholders
🤔：把利益相关方喊来一起干，似乎是这么个意思，可是，人家为啥要来一起，过来就能捡白银嘛。同盟化利益相关方，咱们得利益分享，但不是杆秤分黄金。得同盟后，一起干出来可分的黄金。同盟这个词，表达更准确，利益在前方，一起开拓道路，才能一起走到利益的彼岸，才能够一起分黄金。这么说来，所谓的利益相关方，更应该盯住未来，尤其是加盟后，一起创造的利益。如果这么理解，怎么又跟合伙人有点类似。不过话说回来，合伙人不就是一起努力干，然后分享未来的利益嘛。
📖：Create Skeleton System
🤔：纸上写着画着总觉浅薄，还得来个骨感的系统，才能撑得起整个架构。其实，之前做过类似的事情，得把框架代码，以及框架里模块的代码写好，大家都拷贝框架，然后修改。那时以为，这样会遏制创造力。所以在半偷懒，半随性的驱使下，开启所谓架构指导下的开发。结果嘛，得分两方面谈。一方面，如果自己亲手评审每份代码，且严格遵守架构，那就成为杰出的架构看门人。另一方面，又是在半偷懒中，持续往懒惰方向腐化，高大上的说法，叫做符合人性中最小能量支持的基因特性。
📖：把自己设定为架构评审方，自己看自己的架构，没有明显问题，在其它方都没有意见之后。
🤔：自己评审自己，总是下不去手，原因只是自己想快点结束，因为已经在忍受模式。如果自己能进入创新的享受模式，怎么看自己的产物，怎么都不满意，持续想持续改，没有满足的尽头。体现出来是没完没了的折腾，就是因为不懂得进入享受自己创新的乐趣。