文章图片
作者|肖然出品|CSDN（ID：CSDNnews）
我们在之前的文章中介绍了（OrganizationStructureModeling）的基本思想和框架 。 针对企业架构的落地实施 ， 分别从价值建模、领域建模和组织建模三个层面完成业务架构、系统架构和技术架构的持续构建 。 三个建模过程域强调能够通过跨专业的协同 ， 建立更多上下游的互动 ， 从而能够在协作的过程中让共同的语言体系得到持续的养成 。

文章图片
（DEAM框架中“组织建模”的位置）
在技术架构层面 ， 仍然存在着不少“只要图纸画的好 ， 剩下只是代码问题”的偏见 。 真正经历了大型软件项目的老兵们都知道最难的并不是第一次画图纸的问题；而是随着时间推移 ， 不断增加的新需求的持续实现问题 。 面对着前期架构设计上并没有预期到的需求 ， 如何能够在系统持续迭代过程中保持架构的完整性 ， 是一个巨大的挑战 。
走进一个3-5年的系统 ， 很容易发现不但架构上没有了完整性 ， 甚至于过去的需求都没有人讲的清楚 。 看似面面俱到的需求文档仅仅是一种幻象 ， 实际的系统功能早已和过时的文档相去甚远 。 所以在技术架构上 ， 和业务及领域一样 ， 我们必须关注“演进性” 。 我们需要把过去静态的“盒子图”变成具有牵引性的“认知地图” 。
我们都知道地图是具有坐标体系的 ， 比如大家常用的导航是根据全球通行的经纬度坐标；而物体在地图上放置的位置有对应的具体含义 ， 在正北体系的地图中 ， 我们知道北京应该放到天津的左上方 ， 代表着北京在天津的西北方向 。 同样道理在看待软件架构时 ， 我们应该构建一个带有坐标系的地图 ， 而且这个地图还必须考虑一个核心维度——时间！

文章图片
（视图和地图的最大区别在于地图上物体的放置位置是有显式意义的 ， 比如根据全球共识的经纬度坐标体系 ， 每个国家、每个城市都有自己固定的地图位置 。 ）
下面就让我们一起来看看如何构建起技术架构层面的这张可持续管理的“技术架构地图” 。
逆康威定律的思考首先让我们来辩证一下这张地图上应该放什么“物体” ， 或者引用金融行业最基础的问题：地图上的“标的物”是什么？
如果不假思索 ， 大多数人会说是系统、服务这样的技术模块 ， 但康威定律在这方面给了我们非常不一样的思考——组织形态决定产品形态：
Conway’slaw:Organizationswhichdesignsystemsareconstrainedtoproducedesignswhicharecopiesofthecommunicationstructuresoftheseorganizations.
——MelvinConway(1967)
康威定律明确了组织设计的产品/服务等价于这个组织的沟通结构 。 经过一系列的实验证明 ， 针对同一个用户需求 ， 产出软件的内部组件数是同参与设计和开发人数成比例的 。 然而 ， 这也就意味着组织架构一旦形成 ， 其生产制造的系统或产品的内部架构就固定了 。 从一个时间点出发这不是问题 ， 因为我们可以有专家针对当下已知情况设计出相对完善的架构 。
但如果市场和客户需求发生变化 ， 就会和现有架构产生不匹配 。 随着变化的日积月累 ， 我们会发现开发新功能越来越艰难 ， 到最后甚至于一些功能在现有架构上根本就无法支持 。 这样的经历相信很多软件研发组织都有切身感受 ， 甚至不少组织正在经历着这样的架构“腐化” 。
由此业界也提出了所谓的“逆康威定律” ， 就是要通过保持组织结构的灵活性来高效响应外界的持续变化——即通过改变组织结构来驱动软件系统内部架构的调整 ， 从而能够在持续变化的环境中保持内外部的匹配 。