“架构师方法论”，构建软件灵魂所必知必会的

 

前言

“架构师”指的是负责系统架构的个人、团队或组织机构。它不仅需要技术能力，还需要行业知识、沟通软技能的和架构方法论等综合素养。“架构师”非技术专家，也不是项目经理，而是具有优秀沟通能力的共识促进者，是以结果为到导向以实现客户需求的人，可以说是通才、杂家。作为项目经理，了解相关工作也有重要借鉴意义。我们拿“某科技局发票管理系统”项目中的解决方案应用做以讲解。并结合解决方案中的重要工作件对方法论的应用作了论述。

客户分析要做好

“架构师”是这样一个角色，向上配合销售经理、向下服务项目经理。架构师（个人或团队）在项目早期扮演重要的角色，旨在建立合理的IT技术应用设计以实现客户业务问题的解决方案，最终那些被验证的解决方案逐渐形成架构，如系统组建、应用组件和流程组件等。取决于项目的大小，架构师团队扮演的角色也可能会有所不同。作为架构师团队的一员，在该项目中，架构师的主要任务是运用方法论的知识，收集和分析完成客户早期项目模型，建立客户“解决方案”。

首先，我们要与客户建立联系，要从感情上、组织组成上与客户建立某种关系。所以我们绘制了“客户组织架构图”。我们了解到客户最高领导层对项目十分重视，成立了联合项目组负责推进。经过信息收集，我们对该项目组的地位和其组成成员做了分析和定位。我们发现信息中心刘主任对项目具有巨大的影响力，而另一位职位较高的副局长对项目参与热情不高，其中一位科长并不参与意见但是负责喝酒。我们建立了初步的用户沟通策略，并绘制“客户权力分配图” (注：该图是内部交流绝对保密资料) ，如下：

 

 

图1 用户组织机构权力分配图

项目定义-构建灵魂

项目定义，是项目的最高宗旨，是我们和客户所共同认可的终极目标。是项目章程中的重要内容，也是将来我们在任何阶段我们与客户沟通时，所秉承的依据。在项目的初期，该定义可能会不断修改，并臻于完善。

在本阶段，我们可以将项目定义为：通过建立一种机制，改善纳税人频繁到税务局办理发票相关业务的现状。

 

IT环境描述 –构建生态环境

IT环境是指的客户企业架构规划、现有IT系统、以及目标应用所处位置和概览。它包括客户的标准、原则及现有系统的既有规范等。在本项目中，我们分析了如下信息：

信息化标准：科技总局标准、省局标准及信息管理应用手册。

客户外部系统：需要与现有的“税务征收管理”系统对接，并保证发票购销、税款交纳、票证管理、税务登记操作与“征收管理系统”保持一致性。

用户环境：

第一类，纳税人：我们将他们再次细分为委托代开受托人、自备电脑打印机开票纳税人、无设备开票纳税人、自由验真查询人等几种。分别为在图中提供适用的软、硬件系统。

第二类，税务机关内部人员：局领导、大厅审批人员、平台服务人员。主要使用人员为：大厅服务人员。他们既要为委托代开受托人的购票、税款征收、票证上缴做初始和结算服务，又要为开票纳税人提供在线购票、发票使用过程中的支持和购销审核。

第三类，其他服务人员。这里包括负责网上购买发票的同城快递员、无线服务的提供商工作人员等。与系统没有直接发生关系的角色，没有在系统上下文环境中体现。

经过全面IT环境信息收集，建立了客户IT环境的描述。在本项目中，我们绘制了客户“上下文环境图”如下：

 

图2 网络开票系统上下文环境图

 

“干系人”分析 –准确定义需求

干系人（stakeholder），就是与项目发生直接、间接联系的所有人员或组织机构的通称。干系人的期望，就是我们需求和未来交付物的标准。干系人又分为主、次两类。主要干系人的期望代表了项目最终的架构轮廓，要重点考虑。在本项目，我们对项目干系人做了分析并按照影响力进行了排序，排在前三位的干系人是：1.陈主任(报销人) 2.李科长（局方用户）3.纳税人（外部用户）。

在项目中，有的干系人是隐藏干系人，在我们早期接触时可能并不存在，但却可能是对项目起关键作用的人。比如在本项目中的“纳税人”用户，在早期可能会被忽略。但他是目标系统使用最多的人，也是要服务的最终用户。事实证明，后来需求分析时“纳税人”是讨论最多的对象。在项目分析的任何阶段，我们要注意挖掘隐含信息，并充分沟通识别真正有效信息。在这一点，感兴趣的读者可以参考“IBM架构方法论”进一步专题了解。

“用户”和“客户”的区别。有时候我们误以为付钱的就是客户，但我们忽略了客户也有他的客户。客户付钱买了软件也是要给他的客户用的，如果我们交付的产品给他的客户带来了困扰，那么项目常常是失败的。比如在本项目中，真实的使用者是：各类纳税人、办税服务厅的税务干部。而不仅是签字付钱的税务局的局长和主任。

在本项目中，主要的三个干系人代表了核心需求的三方。对他们需求的分析，在一定程度上代表了系统最终的架构。经过与核心干系人的沟通和初步分析，我们形成了初期的需求列表，并把最重要的五个在这里做一下列举，以利于后面的分析比对：

需求描述相关干系人频繁的跑税务局购买发票带来诸多成本上扬，局方和纳税人均有强烈需求改善本问题局方、纳税人等所有人最短的时间掌握纳税人使用发票的情况，只有发票信息全面及时网络发票才有实际应用的意义刘主任、李科长、局方手工开具发票是否避免。手工开具发票的信息入库困难，验真难度大，发票开具也很复杂。局方希望取消该方式。刘主任、李科长、局方能不能保证信息安全，作为财务活动，信息的安全、交易活动的可靠是很重要的

刘主任、纳税人等所有人

能不能与现有的核心征管系统即时对接。发票信息、报税信息、税款信息等都要与征收管理系统即时对接刘主任、李科长、局方

表1 核心干系人需求列举

在这里需要注意“需要”和“需求”的区别。客户常常从自己的角度出发，讲述他们心目中的目标系统，但客户不是专业人员，也可能会忽略他们习以为常的认为不必描述的内容。所以“架构师”要运用软技能帮助客户正确的提出需求，找到他们真正的“需要”，而避免让客户一味提“要求”。最重要的是，“架构师”是对多个干系人需求平衡的掌握者，是一致意见达成的促进者。只有帮助客户正确得提出需求，才能保证项目的顺利实施。

 

架构迭代思想 –小步快跑

架构建立的过程是不断迭代的过程，后面的分析因为掌握了更加全面的信息，不免要对前面的架构决策做出修改，事实上每个阶段完成以后都要对前面的架构定义给以迭代，并对文档进行更新。在本项目中，我们通过对客户需求的进一步分析，更加明确了项目的定义，所以我们对项目定义做了修改。

项目定义：建立一套纳税人足不出户使用发票服务的机制和信息化支撑系统。

非功能性需求 –不可忽视的需求

非功能性需求，是指软件产品为满足用户业务需求而必须具有除功能需求以外的特性。随着技术的日新月异，软件开发的门槛越来越低，功能性需求的实现已经不再向以前那样复杂。然而常常听到客户对“客户体验”、“使用流畅”、“不宕机”等非功能需求提出很多问题，也成了决定成败很大的关键。我们也经常看到许多合理解决方案，当真正将它们用于大型系统的实际环境，灾难性的故障通常是不重视或忽略了系统的非功能性需求造成的。非功能性需求不一定解决“我想要我的系统实现这种功能”，而是解决“如何使这个系统能在实际环境中运行”。在本项目中，我们也着重对非功能需求做了分析，如：

可用、易用性 客户构成复杂，跨行业、跨地域、计算机操作水平不一，有经过财会高等教育的专家，也可能有半文盲商业从业者。所以系统要最大限度地遵循理解简单、操作明确的傻瓜式操作风格，随时可以获取操作引导，对误操作要有高预防性和高可恢复性。

高安全性 系统处于互联网环境，涉及国家安全保密数据及客户隐私信息。必须要提供一种高度安全防护模式，多重安全措施的可行性方案。另外，应有冗余备份、应急处理、均衡负载等可靠保证措施，系统应用具有较强的容错性、健壮性等。

高效、稳定性 系统在全市集中的运行模式下，要确保系统的高效稳定运行。响应时间要短，处理速度要高，各项性能指标应达到标准的时限要求。互联网环境复杂，接入服务商之间竞争网间隔离现象严重，复杂的网络环境下要保证系统的有效、稳定的可使用性。

功能性需求 -庖丁解牛

功能需求项目最终要实现的可交付成果的检验标准，是项目过程最主要的工作之一。功能需求通常分为业务需求、功能操作需求、系统需求、业务规则等几类，功能需求是功能性需求分解要秉承“无限穷尽，互不重叠”的原则进行。无限穷尽，就是要做到功能定义到明确、可执行。例如：软件项目常将功能划分为一个可以单独开发的模块；互不重叠，就是要做到分解无重叠项。该处所定义的分解，在下个规划周期里面要变成的项目计划。编写项目计划时，不可以同时有两人执行子项的存在。当然，取决于项目的大小，早期需求分析时，可以将范围级别定义得高一些，但务必涉猎齐全。

在本项目中，我们首先将系统分为五大部分，1.从属于税务机关的“发票服务管理系统”，部署在税务机关内网。2.为委托代办受托人使用的“发票代开系统”，部署在互联网。3.纳税人终端用户使用的“网络发票开票客户端”，由纳税人自行下载安装。4.由纳税人使用的“开票一体机”，集成软、硬件一体的网络开票机。5.面向公众开发的“综合验真查询平台”。

在以上五大部分的基础上做了更进一层的分解，并最终形成项目功能分解结构表，在这里我们就不再一一列举。值得一提的是，因为项目的复杂度高，我们在下次分解时仅分解了一层，仅达到满足与客户的交流的程度。后续资产转移给了项目经理和业务经理在实施阶段完成，并转化为了详细项目计划。

功能性需求定义时，我们建议大家将关键业务的用例图尽可能得绘制出来。在本项目中，在关键业务上我们绘制了部分用例图，用于客户的交流过程中的详细分析和探讨。

 

 

图3 网络发票客户端发票使用流向用例图

 

 

客户的用例图是指，使我们对系统或其组成部分功能有了一个整体的认知的标准图示。我们可以知道有哪些参与者会与系统发生交互，每一个参与者需要系统为它提供什么样的服务。“用例”描述的是参与者与系统之间的对话，但是对话的细节并不必要在用例图中表述出来。上图是一个基于IBM Rational UML的用例模型所绘制的“网络发票客户端”发票流向用例图举例。

技术架构 -架构概览

基于上述业务功能的概述需求，我们对系统的整体技术架构做了定义。并绘制了“架构概览图”。该图提供一个针对架构以及建议IT系统的高层次的共享视图，是探索并评估其他可能的架构设计选项的一种工具。它表达了在一个可控的设计思想下，一系列IT系统或者企业架构的候选模块。包括候选子系统、组件、结点、链接、数据存储、用户信息以及外部系统。也可以提供一些备选的设备选用方案，比如本项目中，针对大规模信息存储，我们建议使用IBM小型机作为存储方案。

图4 网络发票系统架构概览图

总结

在本项目中我们做了很多的应用尝试，我们理解到随着我国信息化程度越来越高，功能性设计并不能构成有竞争差异，我们增大了非功能性需在方案制定中的份量。

在为客户打造“核心竞争力”方面我们从多个角度进行了思考：比如，站在客户的角度上，思考如何为客户解决他的客户的问题？他的竞争对手是谁？如何为客户建立“核心竞争力”？

在初期应对客户的需求，市场上类似产品的解决方案提供商有很多，客户的选择也很多，竞争也越来越激烈。遵循一定的方法，利用成熟的理论提供的好的、成熟的系统架构思想就可以做出优秀的架构解决方案。