如何编写业务架构如何编写业务架构
1.背景
大型2B系统复杂度很高，目前业界一般会被拆分成业务需求、技术实现两部分加以讨论。基于对大量失败项目失败原因的分
析统计：导致大型2B项目失败的因素，需求分析、逻辑设计相关问题占到80%以上，而由纯技术因素导致失败的情况几乎微
乎其微。而需求分析经常遇到的一个问题是，懂业务的人不懂技术，懂技术的人不懂业务，业务逻辑实现与技术实现混杂在一
起导致双方的沟通出现大量不确定因素，导致需求未必理解一致；实现规划也未必一致。决策层需要在项目开始前做出决策，
需要判断一个系统规划是否具备可行性，其中无技术背景人员可能不清楚实施方案是否可行。通过一些深度分析，我们提出
了“业务架构”这个概念来解决这个问题，那么什么是业务架构？一个业务架构应该包括哪些内容？通过怎样的路径去完成一个
业务架构呢？ 以下是笔者对一段时间的业务架构工作的思考和总结。
本文试图给出:
业务架构的准确定义
业务架构的构成元素
完成业务架构的基本方法
2.业务架构是什么？
2.1 传统解决方案的描述方式
缺点：无技术背景的商务分析人员、产品经理缺少对实现的了解
2.2 业务架构描述方式
2.2.1 特性与优点
它是一种架构层面的”大图“，，便于快速理解一个复杂系统，核心需求如何实现，整个体系如何整合，满足关键需求的关键机
制是怎样的？关键系统性的内部能力和支撑机制有哪些？它是对复杂系统的一种高度抽象。通过这样的描述，完成了系统的问
题定义和领域划分。
同时业务架构也提供最基本的设计
脱离技术实现，描述业务实现
只描述重大架构性元素
高抽象度
根据特点，可以看到它的优点是：
资源评论
