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

作者 Sadek Drobi译者 王丽娟 发布于 2008年2月25日 上午3时18分

社区

Architecture

主题

技术,

企业架构,

团队协作

标签

分布式团队

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

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

1. 返回顶部

   re

   2008年2月27日 下午8时55分 发表人 ma michael

   good, 很实用的好文章.

   回复

• 更早的 >