浅析架构师工作流程及成功关键

在这里，我们将从一个架构师的角度，来说一下架构师工作的一个大概流程。当然，架构人员的积累，绝不是简单的几句就能形容的。

讲了软件架构设计的内容与思想、成功架构的标准关键与策略，现在大家迫切需要知道的是，按照前面的内容已开始了软件架构的设计之旅，但软件架构究竟需要设计到什么样的程度才是符合要求的呢？

在讨论这个问题前先看看困扰我们这个问题的软件架构现状是怎么设计出来的。拿到软件需求后，经过一翻囫囵吞枣式的通读(而且是一边看一边脑子里飞速的转达：这块按我的经验应该如何实现)，然后打开建模工具，根据需求上提到的几块功能模块要求，画上几个用例与时序图；再从需求中摘下几个事物建立类，填上类的属性，又从时序图中分出几个函数方法，最后(基本上想也不用想)根据经验，依MVC分几层，套用已有的示例将最近新学的几个流行的框架添加上去。这就完成了架构，不过公司要求写架构设计文档，所以又翻出架构设计文档模板，发现还少了几部分内容。不要紧，一边写一边看别人的文档是怎么写的，依葫芦画瓢。评审了，打开文档或模型，指着用例图、时序图几乎是按需求文档解释了一遍：你看系统包括这些功能，每个功能是这样一步步完成的。什么？这就是软件需求文档拷贝过来的？你没有看到系统分层了吗？不是选择了框架吗？什么？这一层/模块与下一层模块是怎样通讯的、有什么参数、按什么格式？这不是到了伪代码级了吗？不是还有详细设计吗？架构设计把这些都定义出来，还要详细设计做什么？架构设计需要详细到这种地步吗？你们是评审员，你说的不管对不对都有理，按你说的我进行改一下。评审员，你看一下文档改得符合你的要求吗？哪儿不行你说，我按你说的写，或者你写一篇样板我仿着写？几经周折，评审人员疲备了，老板急了，怎么架构设计超时这么久了还在改？架构人员诉苦：我都架构设计完成了，评审人员老说不行，我以前本来没有这么规范过，又不知道评审人员心中的架构文档究竟应写到什么程度才算合格。老板找到评审人员：你看工期这么紧，他们也没有写过这么规范的文档，只要架构设计完成了就行了，或者一边开发一边补文档？结果许多影响全局的设计决策本应由架构设计来完成，却纺统统留到了后边，最终到了大规模并行开发时才发现，不得不由程序员临时碰头决定"将就一下"。

大家不要笑，说我过于夸张了。这是我在一家公司负责过程改进与质量保证时的真实情况。我个人认为，软件架构必须设计达到以下四个必须、一个不一定：

首先，软件架构是用来沟通的，软件架构必须满足软件项目所有步众代表都有自己立场与视角的模型、文档说明，且这些模型文档说明仅清晰包含自己立场与视角关注与有关的事物，不能有任何遗漏，也最好不要有多余。

其次，软件架构的每一步都是决策过程，而且关键需求决定架构，软件架构必须充分清楚地表达出这些决策与决策理由。众多的需求中为什么这些需求是关键需求？为满足这些关键需求，采用了什么样的关键机制、核心技术与第三方框架？什么选择这些关键机制、核心技术与第三方框架而不选用其它的？为什么说它们是可行的？

再则，软件架构必须为以后的开发提供足够的指导与限制，因此软件架构必须确定系统各元素间的关系、职责、交互接口与协作机制。仅仅划出几个层与层中包含的元素而不约束它们间的关系、职责、交互接口与协作机制，就如同一个公司，它的组织结构图就挂在墙上――再清晰不过了，但如果接口不清、机制不明，来了任务、出了事情不清楚找谁、如何汇报、怎样处理。

然后，软件架构必须突出强调通信机制、持久化机制和消息机制等公用模块的深入设计。通信机制、持久化机制和消息机制等公用模块较多的涉及软件的不同部分之间的交互，对系统的功能实现、非功能满足等成功因素起着举足轻重的作用。

最后，由于软件项目的不同、开发组织结构的不同、开发团队情况的不同，软件架构的设计粒度是不一定的。比如，航天航空领域中的软件系统对系统的可靠性等质量属性要求非常高甚至可以认为是荷刻，这种情况下对架构的设计详细程度的要求也会比较高；象IBM这样的大的团队中又有小的团队共同开发，架构的设计粒度到子系统级就足够了，各个小团队精通的技术各不相同，可以让其对子系统采用敏捷开发，对缩短工期、人尽其材有好处；有类似项目经验或项目团队所有成员整体技术水平较高的团队架构粒度可适当粗犷，而分布团队或涉及外包的情况则更强调架构的明确性。总之，架构设计对软件的不同部分的设计程度不应是整齐划一的，特别是具体的业务功能模块在架构设计中往往设计程度不深。