软件工程的灵感经常来自建筑学. 造房子过程中, 设计师通过研究地基环境来理解建造的需求. 他们分析不同的建筑组件, 如水管, 炉灶, 窗, 门等, 来决策哪里应该用标准组件, 哪里则需要定制. 设计师需要对每个组件以及整体估算价格, 并绘制施工蓝图, 提供设计规格说明.
作为一个软件架构师, 你也可以采取类似造房子的方式. 你和IT, 市场以及管理人员协作, 理解架构需求, 分析现成组件是否满足需求, 还是需要自己定制开发一部分. 然后架构师需要提供一个设计图, 明确软件的功能以及对应的成本.
当然, 这种软件工程类比建筑设计的前提假设是: 软件是精确的. 这是不正确的, 而且历史上我们为这个错误的假设付了太多的代价. 现在我们知道, 通过敏捷迭代的方式来快速响应变更, 是一个更为现实的做法. 所以让我们调整下对于软件架构的类比, 不要比喻成建筑设计, 儿是比喻成自然景观设计.
一个园丁和客户协作指定一个计划, 了解现有的地表条件. 对于景观的最终愿景达成一致后, 园丁可以开始计划工作. 有些地方你可以将现有花草数目全部拔除, 推到重建, 从零开始; 另外一些地方, 则需要基于现有环境特点来做设计. 一旦基础地面清理工作完成, 你可以开始朝目标工作了.
景观是有生命的. 随着时间发生变化. 无论你多么认真设计初始规划, 自然的增长总是抵抗完美的控制. 把所有东西拔掉从头再来先然是不合理的举动, 更合理的做法是适应这种成长. 对于希望长得更茂密的部分的施肥促进, 对于过多的枝叶进行修剪, 对于不需要的野草连根拔起. 园丁按照自然的规律进行调整, 逐步培育出目标景观.
软件也是有生命的. 软件随着时间增长积累, 且必须应对业务的不停变化的需求. 软件是由人构建的, 因此在时间压力下, 会采用现有的工具, 以交付有功能价值, 但是实现和初始计划不太一样的东西. 作为一个软件架构师, 你有一些选项: 你可以像一个建筑工程师, 设计完美精确的设计图, 通过行政命令, 项目进度面板来管理; 或者你可以采用园丁的模式, 鼓励你希望的模式和策略, 修剪或者消灭那些不希望的.
一个优秀的架构师拥抱软件的自然增长的特性. 观察培育组织内的各种进行中的开发工作, 推广采用稳健模式的优秀系统, 通过培训的方式, 扩大好的做法在不同团队中的使用. 识别出运行糟糕的系统, 并帮助他们迁移或者重构. 一个优秀的架构师适应环境工作, 接受现状, 遏制控制和专权的欲望.