作者:道格·克劳福德(DougGrawford)
好的架构师能够将复杂性降低到最低限度,他在解决方案中给出的抽象,应该能够为更高的层次提供坚实基础,同时,还应该能足够务实地应付未来的变化。
优秀的架构师能够深刻理解变化带来的影响,这种影响不仅限于彼此隔离的软件模块之间,而且包括人与人之间,以及系统与系统之间。
变化有多种不同的表现形式:
- 功能需求的变化。
- 可扩展性需求的演进。
- 系统接口被修改。
- 团队人员流动。
- ……
软件项目中变化的广度和复杂性,是无法提前看得清楚,企图事前消解所有潜在冲突(bump)是徒劳无功的。但是,在确定沿途遭的冲突和项目成败之间的关系中,架构师扮演着关键角色。
管理变化并非架构师的的职责,但架构师要确保变化是可控的。
举例而言,高展分布式的解决方案,横跨了许多应用程序,依赖多种中间件(middleware)将各个部分胶合在一起。如果没有对依赖集(set of dependencies)进行准确跟踪或以某种可视化模型表现出来,业务流程的变化可能会造成重大的危害。如果变化会影响数据或破坏现有接口,其对下游的影响会尤为巨大。另个,现存的长时间运行中的有状态事务(long-running stateful transaction),在老版本流程下也必须要能成功完成。
这上例子可能有点极端,但高度集成的解决方案现在是主流。架构师需要在可用的集成标准、框架和模式中做出选择,这个例子无疑可以说明这点。为了能给客户提供一贯的支持,理解这些外围系统的变化将带来的潜在影响,显得至关重要。
幸运的是,有许多工具和技术可以用心咸轻变化的影响:
- 进行小规模的增量渐变。
- 构建可重复运行的测试用例,并经常运行。
- 让测试用例更易编写。
- 跟踪好依赖关系。
- 系统性(systematically)的行动,根据反馈信息作出进一步反应。
- 自动化重复的任务。
架构师必须评估变化对项目范围、时间和预算各个方面产生的影响,并准备好花较多时间在那些受影响最大的区域,即“沿途的冲突(a bump in the road)”上。通过衡量风险(measuring risk),可以知道该把宝贵时间花在哪里。
降低复杂性很重要,但降低复杂性并不等于简化处理。务必清楚认识解决方案中变化的类型和将来带来的影响,对中长期而言,这样做带来的回报是无法估量的。