三、架构设计的过程
本人经历过不少项目，一些项目的架构设计负责人能力很强，接到活之后，马上一头扎进设计，抽象出一堆玄玄乎乎的概念，讲得人晕头转向的，让人觉得高深莫测，但是，在会议上却被涉众提的一些简单的问题问得很仓促，究其根本，还是漏考虑了涉众的需求，被人提问而又缺乏准备，是不是很多人有类似的经验？：）
我们还经常遇到的场景是设计人员通常为一些模型、概念争论不休，公说公的英俊，婆说婆的漂亮，其实模型概念这东西就像人的人生观和世界观，是人对世界和人生的主观认识，可能随着年龄阶段的变化而变化，而且有时候没有绝对的对与错，就像有些人喜欢金戈铁马，有些人喜欢与世无争，我们很难说谁一定是对的一定是错的！遇到这种清醒时，我建议停下争论，争论方各自拿出实际的业务场景来检验模型，哪个模型对场景的满足度更好，实现成本更低则更好，如果两个都挑不出刺儿，随便选一个即可。
还有一些架构设计人员喜欢创造一些与众不同的概念，让人看上去显得高深莫测。我觉得如果一个架构师能够用最少的语言、文字把问题和方案讲清楚，那才是真正的有水平！你让人晕头转向的时间既是项目的成本，因此，我们创造概念词汇的时候，需要从涉众的角度出发，我这里的意思不是盲从涉众语言词汇，而是说出发点从涉众角度出发，如果涉众原本使用的语言不够准确，我们可以跟他们一起探讨，定义更合适的概念词汇。
还有一个就是对软件竞争力的认识。有人通过包装一堆玄玄乎乎的概念来显得很高深莫测，试图通过这种方式让人觉得有竞争力，我认为，竞争力首先是要跟对手比，其次一定是涉众能感知的，能够涉众带来正向价值的，比如省多少成本，端到端业务流程节约多少时间。
我认为遵循一个科学的架构设计过程跟上篇提到的软件架构4+1视图法是架构设计的两个法宝，一个指导思维、定义输出，另一个指导如何来做，相辅相成，确保架构设计人员全面而正确的理解需求，做好需求平衡、设计平衡，设计出实用的、能落地的架构。
下面我会按顺序讲解架构设计的过程，以及每个步骤具体要做的事情。
3.1 确定涉众
一般来讲，涉众包括客户（资方）、承接方（劳方）、用户。我们通常找到代表某一类型的涉众群体的代表人：客户代表、劳方代表、用户代表等。访谈的时候直接找代表进行。
3.2 确定系统边界
对于要明确实现某种标准的软件系统，通常确定边界非常容易，直接按标准圈定的scope分析即可，比如像SIPServlet容器，是要求遵从JSR168规范的，那么软件系统的Scope就是JSR168规定的Scope，但是也有例外，比如客户或者劳方明确指定要复用一个现有的实现了部分功能的系统或组件，那么Scope就不同了。对于没有标准的软件系统，就需要分别访谈客户代表、承接方代表确定系统边界。为什么要访谈承接方代表呢？因为承接方代表往往是劳方领导，领导肩负企业战略达成的使命，很有可能对系统提出比客户更多的要求。举个例子，某客户需要一个SIP通信协议栈，以实现三方通话的业务，但是劳方领导认为，后续ICT融合是趋势，我们构建的系统要支持ICT融合应用部署和运行，支持业务标准JSR168规范。
3.3 软件需求收集
软件需求可分为二类：
功能需求（即业务用例）：描述Actor（用户或系统）可基于软件系统做什么事，要符合什么业务规则；
非功能性需求又可分为两类：
质量属性：质量属性指软件系统的品质，可分为运行期质量属性与开发期质量属性。
运行期质量属性包括
（1）性能：性能是指软件系统及时提供相应服务的能力。具体而言，性能包括速度、吞吐量和持续高速性这三方面的要求。
（2）安全性：指软件系统同时兼顾向合法用户提供服务，又阻止非授权使用功能的能力。
（3）易用性：指软件系统易于使用的程度。
（4）可用性：可用性与易用性不相同。可用性指系统长时间无故障运行的能力。
（5）可伸缩性：指当用户增加时，软件系统维持高服务质量的能力。
（6）互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
（7）可靠性：软件系统在一定时间内无故障运行的能力。
（8）健壮性：也称容错性。是指软件系统在异常情况仍能够正常运行的能力。
开发期质量属性包括：
（1）易理解性：是指系统设计能被开发人员理解的难易程度。
（2）可扩展性：为适应新需求或者需求变化，为软件增加功能的能力。有些时候，称之为灵活性。
（3）可重用性：重用软件系统或其中一部分的能力的难易程度。
（4）可测试性：对软件测试以证明其满足需求规约的难易程度。在实际的项目中，主要指进行单元测试等难易程度。
（5）可维护性：修改Bug，增加功能，提高质量属性。
（6）可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。
约束：规定开发软件系统时必须遵循的限制条件，如要基于什么操作系统，要基于什么开发语言等等。
对于功能需求，可找系统的直接使用用户代表，对其进行访谈，收集其要基于系统做的事情，可按照标准的用例模板，在访谈的过程中引导用户代表。之后，绘制业务用例视图，并针对每个业务用例，使用标准的用例模板将功能需求编档，通常叫用例规约。
对于非功能性需求，可找软件系统的涉众，依据下面的模板，引导涉众，收集其对相应质量属性的要求：
总结：本阶段需要输出业务用例视图，业务用例规约，非功能性需求。
待续。。。