理想的架构并不总是和理想的技术相关

作者 Sadek Drobi 译者 王丽娟 发布于 2008年2月25日

领域

企业架构,

过程 & 实践,

架构 & 设计

主题

分布式团队 ,

团队工作 ,

技术 ,

企业架构 ,

敏捷 ,

架构

分享到

根据公认的定义，软件架构师的角色是定义“系统的宏观方面，这个系统则基于来自其利益相关方的投入。”这意味着架构师不能只由技术因素来驱动。他们需要记住不同利益相关方的需求，这往往制约着对技术和架构设计做出选择。

Phillip Calçado在他的blogpost上强调，除了系统用户和项目赞助商之外，软件开发团队也是一个重要的利益相关方，因为开发者会直接受到架构决策的影响。因此，尽管开发环境可能会限制架构师的选择，甚至会导致放弃对项目而言客观上最好的技术，但架构师还是应该考虑开发环境。

举例来说，Calçado强调考虑团队的技术背景是极其重要的：

试想你加入一个长期从事VB6开发的团队去开发一个新的网站。尽管你知道Ruby on Rails是完成这项工作最好的工具，但是没有人有Ruby on Rails的相关经验。而这个网站又必须在短时间内交付，没有时间进行培训。你还会主张选择最好的技术吗？

另一个限制因素可能会来自团队的分布，无论是不是物理分布。在Claçado举的例子中，为证券交易所经纪人开发的系统有三个部分——数据采集、用户交互和事务，其中每一个部分由不同的团队处理。从技术上讲，即使将系统设计为单一模块可能是最好的选择，但是架构师将不得不设计三个黑盒模块，以便“团队在完全独立的组里面工作。”

总的来说，Calçado强调道“收集那些受你的决定影响最大的小组的反馈、尊重他们的意见是很有必要的”。评论家Alberto Brandolini用“持续性架构（sustainable architecture）”的概念来支持同样的思路，持续性架构要求架构师保证他的“架构设计能由团队成员完成交付。”

将这种制约因素考虑在内对项目的成功是非常重要的。但是，这并不意味着因为团队在时间和技能可用度方面的约束和阻力，就一定要放弃那些真正为项目增值的技术。架构师的角色实际上是为引入变更创建策略，并将策略整合到设计当中：

[……]架构师应该在系统的线路图中包含一个移植方案。[……]举例来说，无论任何时候需要一段脚本或小程序，你就可以开始使用Ruby[或任何需要的技术]、慢慢引入新的Web开发平台。最重要的是，你应该对系统以后应该是什么样子、以及怎么实现它有一个清楚的认识。

查看英文原文：Ideal Architecture is not always about Ideal Technology or Techniques

译者 王丽娟 王丽娟，04年大学毕业后持续从事Java EE中间件产品的开发，现在主要关注Java技术及中间件产品在云计算环境中的发展趋势和应用。

相关厂商内容

保持某些系统的高可用性，是一些企业的重中之重，如何设计？

海量数据处理，海量视频分发，架构热点难点，尽在架构师峰会！

相关赞助商

ArchSummit全球架构师峰会报名启动！7折优惠，5月31日截止！

1. 返回顶部

   re

   发表人 michael ma

   good, 很实用的好文章.

   回复