执行业务建模以设计自己的业务时才增值。如果只是构造现有组织的图以得到系统需求，则没有必要定义业务体系结构。
全局性业务架构建模的主要步骤如下：
1.生成业务体系结构的预览
业务体系结构概述在项目生命周期的早期创建，可能与建议的制定一样早。它通常是以图的形式，使用一些非正式的表示法或演示图板技术进行描述。它代表业务建模工作背后的意图和理念。起领导作用的业务流程分析人员通常与项目出资方协作
2.生成业务体系结构概述。
概述图必须指示业务的主要元素及业务的环境，例如团队、业务工具和外部影响源（例如，法规实体、合作伙伴和子市场）。概述图常常不着重于如此处所述的整个业务体系结构。而是由大型工作（例如业务流程再造（BPR）项目）考虑整个业务体系结构。业务体系结构的表示法在概念：业务体系结构中进行了描述。
考虑业务体系结构的目的及其目标用户是有用的。这确保了描述和表示业务体系结构的方式适合于必须理解它的人员。目标用户可以分类到关心不同方面的不同的组中。这些组中的每一个组会对工作产品：业务体系结构文档的不同体系结构视图感兴趣。
此时，业务体系结构概述是临时的第一稿。 不能基于此概述图作出任何承诺。初始概述图可以作为工作产品：业务体系结构文档的一部分包含，也可以不包含，这取决于它给内容增添什么价值。
3.描述影响业务体系结构的因素
确定业务中的约束和趋势，以及业务的环境，它们可能对业务的结构或者工作方式有重大影响。当定义业务体系结构时，必须分析这些因素，以确保业务能在合理的时间内适应可能的变更，并抵抗住其他种类的影响。值得考虑的因素包括业务策略和趋势，以及可能的将来事件，它们将影响组织的每一部分或激进地变更其重要的核心部分。另外，要考虑可能必须非常快速进行的变更，以及可能在将来要施加的约束（这些约束可能改变业务的执行方式或带来新的机会），这一点很重要。
考虑发生这些事件或变更的可能性，并尝试使它们对业务的影响为人所见。一旦您了解了可能性和影响，您就可以划分这些因素的优先级，并作出关于如何处理最高优先级问题的决策。处理每项变更的可用选项有：
•准备对变更作出快速响应。
•在变更已发生的情况下采取行动。
•将变更可能产生的影响降到最小。
•忽略变更发生的可能性。
将您的结果记录在工作产品：业务体系结构文档中关于体系结构推动因素和约束的部分中。
4.概括高级组织
确定将构成组织的高级分组。它们可以是部门、事业部或业务单位，这取决于您的组织使用的术语。当在业务分析模型（如果您有一个非常大而且复杂的业务模型）中确定一组初始工作产品：业务系统时，这些高级分组可以用作输入。
如在工作产品：业务远景中所定义，考虑项目的范围。对于组织中在范围以外的部分，没有必要探索它们的详细信息。另请参阅概念：对大型组织建模。
高级组织的草图应包含在业务体系结构文档的组织结构视图中。另请参阅指南：业务体系结构文档中关于组织结构视图的部分。
5.识别业务系统
识别并简要描述正在建模的业务中的业务系统。 业务系统其实只对大型的复杂业务模型有用。 根据业务建模场景以及您工作的范围，您可能决定完全不使用业务系统。
业务系统代表组织内相对独立的能力。它定义了一组职责，以及履行这些职责的业务工作者、业务实体和业务事件。在这种方式下，业务系统是组织的结构部分（例如一个部门），但区别在于：业务系统内唯一允许的 交互是通过预定义的职责。例如，考虑饭店里的服务窗口，或者带有服务目录的 IT 支持部门。在这两个例子中，均有预定义的交互。例如，如果您走到饭店后面试着从厨房中某人处取一份菜，将发生什么情况？ 类似地，如果您请求计算机支持技术人员为您预订航班，将发生什么情况？ 我们使用业务系统来禁止与其内部的业务工作者和业务实体发生除指定交互以外的任何交互。这允许我们将大而复杂的业务模型进行分区，以便能着重于详细描述模型的一部分，而又能了解它在整体中的位置。
就哪些业务系统（如果存在）应包含在模型中进行讨论并达成一致。一些业务系统可能在业务用例实现的环境中描述得不够详细。其他则可能提供重要输入或接收输出，在这些情况下应将它们作为业务参与者进行建模。这意味着它们在正在建模的业务之外。
您可能想要指示业务系统如何参与业务用例，而不显示业务系统内业务工作者和业务实体之间的内部交互。如有必要，您可以“放大”业务系统，以将内部协作作为业务用例的一部分显示。
6.确定关键抽象 － 业务工作者和实体
对于到客户的关键接口以及（适用情况下）业务系统之间的关键接口，必须确定主要工作产品：业务工作者和工作产品：业务实体。这还对定义每个业务系统的目的以及系统的能力有帮助。目的和能力的清晰定义有助于更好地理解业务系统在业务用例实现中必须担当的角色。这样的定义还有助于揭示业务系统必须与其他业务系统交互的方式。
7.概述划分了优先级的业务用例实现
确定哪些工作产品：业务工作者和工作产品：业务实体参与执行每个划分了优先级的业务用例。它们形成业务用例的业务用例实现。对于大而复杂的业务模型，可用业务系统之间的交互表示业务用例的实现。
流程实现的草图应包含在业务体系结构文档的组织视图中。另请参阅指南：业务体系结构文档中关于组织结构的部分。
8.定义分发（地理）视图
此视图描述部署业务的地理位置，以及组织结构和功能在这些位置上的分发。位置视图对于评估时间和距离对业务流程的影响很有用。可以简化流程，或者可以重构组织本身，以消除协调分布式任务的开销。而且，每个位置的唯一属性（例如法规、资源、可访问性或图像）可以影响在该处部署特定业务活动的决策。船舶也可以视为位置。定义地理视图的流程由以下任务组成：
•确定执行业务活动的主要位置（国家／地区或城市）。
•确定这些位置之间的依赖关系和通信路径。
•将业务系统（从组织视图）映射到这些位置。
•评估每个位置关于在该处执行的业务活动的正面和负面的性质。
•评估分发对业务用例的总体影响。
•探索简化业务用例或者重构组织以消除开销的影响。
9.定义人力资源（工作者）和文化视图
定义业务的人力资源方面的流程包括以下任务：
•考虑组织内部存在的能力概要情况。定义将来必需的能力概要情况，或者定义对现有概要情况的必要更改。将来的业务要求雇员独立性更强还是更弱？ 他们需要更高还是更低的教育程度？
•讨论教育需要。定义两个长期培训计划以克服当前能力和期望能力概要情况之间的差别，以及与新的业务流程的引入相关联的所有初始培训需要。
•定义在适当的位置存在或者需要放在适当位置以提高技能水平的所有机制（奖励结构、实习生计划、导师计划或其他刺激因素）。讨论每一个的优缺点。
•探索由于职责的改变或加强沟通的需要而在组织中重新定位个人的可能性。
描述业务的文化方面的流程包括以下任务：
•确定文化的属性。
•确定这些属性中哪些对于组织是关键的，且必须保持原状。
•讨论哪些属性必须更改。
•确定已存在哪些机制来保持和发扬文化。讨论关于新的或更改的机制的设想。
•定义要为引入任何您认为必要的更改而采用的途径。
此步骤的结果应记录在业务体系结构文档的人力资源视图中。另请参阅指南：业务体系结构文档中关于人力资源视图的部分。
10.评估结果
检查业务体系结构文档，验证您的工作是否处于正轨。请参阅核对表：业务体系结构文档。
本文转自肖勇 51CTO博客，原文链接：http://blog.51cto.com/xiaoyong/251454 ，如需转载请自行联系原作者
