在MMN的宏观视图中，包括了三个过程环节：定义架构概图、架构全局分析以及构建概念模型。这是一个循序渐进的过程，是系统架构整体分析的逐步细化。这个过程的关键是找准架构分析的切入点。这正是定义架构概图所要解决的问题。定义架构概图需要明确架构目标、调查架构资源和分析用例场景。这三个活动可以是并行的，至少彼此之间是相互影响、相互作用的。如下图所示：
虽然这些活动是并行的，但从一开始明确架构目标才是最佳的选择，因为架构目标是整个架构过程所要努力达到的方向。不了解架构目标，搭建出来的系统架构再好，也可能不符合客户的需求。架构目标来源于需求，主要指客户或其他利益相关人提出的项目（产品）愿景。愿景表达了客户的目标以及对系统的期望。从愿景中我们可以获得许多架构分析所需要知道的知识，例如明确客户最期望达到的目标，以此可以确定场景与风险的优先级；了解客户的不同目标，可以由此识别系统客户的不同角色，明确不同的利益相关人的态度。
通过需求的愿景和范围，就可以确定架构的实现目标。识别架构目标，就需要了解是谁需要使用架构，理解架构的约束（技术约束、使用约束和部署约束）。如同架构在软件开发中起到的作用，架构目标一方面是业务需求和客户的要求，另一方面也是技术和应用系统的要求。架构目标是需求分析师、架构师和客户达成的一致共识，而一旦确立了架构目标，该目标就会成为团队的一致共识。
架构旨在为业务需求和技术需求之间搭建起相同的桥梁，并找到合适的方式实现这些需求。好的架构必须能够减少与技术解决方案相关的业务风险。它最好是灵活的，能够处理软硬件以及业务需求等的变化，考虑整体影响设计决策的因素，在质量属性之间权衡，并努力满足用户、系统和业务的需求，如图所示：
在了解用户的目标时，首先需要明确用户的分类，因为不同类别的用户，他们的关注点是不相同的。例如投资者或者管理层关注的目标，可能更多地是考虑组织因素，例如项目成本，周期与收益。如果是系统的使用者，则主要考虑业务因素，关心的是与自己工作相关的功能是否满足需求。如果是系统的运维成员，则主要考虑技术因素，例如系统的可维护性、健壮性、可扩展性、可伸缩性等质量属性。
在明确架构的业务目标时，我们并不需要了解每个细节功能的需求，而是关注业务的期望值。了解业务目标，不是要识别业务流程、业务规则或者业务所要处理的数据。例如业务目标提出了提升工作效率，改善工作质量的要求，确定了应该由系统自动完成的功能，明确对业务需求变化的处理。
系统的目标和技术直接相关，尤其是架构的质量因素。系统目标可能包含对系统规模、用户数、并发量等的要求。系统目标也可能对软硬件平台提出了约束性要求。
整体而言，架构应该：
1）公开系统的结构，但隐藏实现细节。
2）实现所有的用例。
3）试图满足不同涉众的要求。
4）满足功能需求和质量需求。
我曾经为一个集团公司开发类似ERP的系统。这个集团从事软件外包业务，它希望能够搭建一个平台，实现人力资源、客户资源与项目资源的整合。系统包括人力资源管理、客户关系管理和项目过程管理等主要模块。系统用户为集团的所有员工，但角色的不同，决定了他们关注点之间的区别。
在提出方案的开始阶段，我们注意到管理层用户对于系统的预期目标，那就是避免“信息孤岛”，实现资源的可控，以避免资源浪费，或者避免因为资源的缺乏而导致业务的流失。例如，客户方需要集团提供20名各个层次的Java开发人员，则市场部门在确定是否签订该合同之前，就需要通过系统查询集团的人力资源库，了解现有的人力资源是否匹配客户需求。如果匹配，还需要判断人力成本，以决定合同的标的。如果不具备，则需要人力资源启动招聘流程。管理人员可能还需要了解开发人员的闲置率，跟踪项目的进展情况，以及开发人员在项目中承担的职责和完成质量。
在进行需求调研的过程中，我们又了解到系统最终用户的诉求。例如人力资源部门的普通员工对于系统的要求非常简单，就是希望系统的操作方便快捷，最好能够提供导入Excel文件的支持。市场部则需要系统提供合同文件的管理功能，包括文件的上传下载。
通过对用户、业务和系统的需求分析，我们就可以初步确定架构目标。例如：
1）系统主要分为人力资源管理、客户关系管理和项目过程管理模块；三个模块共享同一个数据库；为达到重用目的，需要在这三个模块中抽取出公共模块，例如员工信息管理；
2）系统应达到辅助决策的功能，以满足管理者对资源的控制、分析、跟踪与查询功能；
3）系统具有良好的可用性；提供设计简洁的导航功能与菜单；能够与Office进行集成。系统需快速搭建原型，以更快地了解用户的反馈；
4）系统应基于角色与组织进行权限控制；
5）为部署的简单性，系统应采用B/S应用架构；
6）系统的业务组件应该是松散耦合的；
本文转自wayfarer51CTO博客，原文链接：http://blog.51cto.com/wayfarer/548139，如需转载请自行联系原作者
