做管理型软件产品一般都要经历架构阶段，而架构又可以简单分为业务架构和技术架构，对于架构方法，在我以前的blog中大量的介绍了TOGAF。
使用TOGAF的几个初衷
在我们开发软件时，如果你做过设计和架构工作，那么你会发现软件开发过程中其实存在很多断沟。
1.业务架构到技术架构的不一致
1.业务架构是一拨人做，技术架构师另一拨人做，结果做业务架构时缺少技术架构的考虑，而技术架构缺少服务于业务的意识，最终没有为业务服务。弄到最后业务架构和技术架构并不能很好的结合起来，导致还需要很多适配或反复工作。
2.还有一种情况是，业务架构做完之后扔给技术架构来实现，但是业务架构提供的东西并不全面，不能提供技术架构的输入，导致沟通效率极其低下。
2.业务架构到业务需求的不一致
1.有些公司虽然岗位分的清楚，但是方法并不清楚。业务架构是一套方法，需求分析是一套方法，甚至于没有方法，而是靠着个人能力去做，结果导致架构和需求交付物是独立的，业务架构的东西不能顺利转移到需求阶段
2.还有时候一个人就负责产品的业务，架构和需求一起做，这时候没有方法的指导，其实很容易迷失在业务细节。
过早的进入业务细节对于产品来说是及其危害的，因为产品架构还未明晰时进入细节只会浪费时间导致重心偏离方向。
3.业务架构和实现的不一致
1.业务架构采用的是业务语言，而技术实现采用的技术语言，两者不是同一个语言，很难做到顺利过渡，还需要再一次翻译，有时候甚至在实现阶段根本不看业务架构出来的东西
2.很少有开发人员清楚产品的业务架构，那么如何能够做出好的产品来？
4.开发产品时，开发问一句，"做这个对系统有什么价值？"结果发现需求根本无法追溯回系统的价值点上，有时连需求人员都不知道为什么做了这个功能。如果产品生命周期较长，中间换了好几拨人来做这个产品了，那么不仅是需求文档不能追溯，就是靠口头讲也讲不清。
从上面可以看书，现实中产品开发存在的隐性问题其实还是蛮多并且很严重的，我也都经历过。而解决这些问题就必须做到一下几点：
1.找到一个指导业务架构的方法和框架
2.结构化架构交付物才有可能把架构知识转移到开发环节
3.必须有一个业务开发平台来集成业务架构、技术架构和开发框架
业务架构和业务需求
TOGAF并没有太多内容来描述如何做业务需求，但是这是我们必须要做的事情。从上面的阐述能够发现，我是希望业务架构和业务需求能够有一种方法进行衔接的。其实业务架构和业务需求本身就不冲突，两者只是处在一个事物在不同层次的东西。架构关注的是更全面、概括、组织方面的东西，而需求关注的是用户关心的业务细节，业务需求是业务架构的进一步分析。
在研发峰会上我讲过一次使用TOGAF来做业务架构，下面是裁剪后的轻型迭代流程和交付物。其中的设计开发步骤中有Backlog，这个就是从业务架构和业务需求的产物。
在我写的敏捷方法之Scrum.pdf电子书中提到产品backlog是在项目开始的时候，由Product
Owner准备的一个根据商业价值排好序的客户需求列表。而在我们工作中，这个产品backlog如果要做到承上启下的作用，考虑到它来自于业务架构，而又服务于产品开发，所以我们会定义一些格式，例如考虑功能的抽象、721的分析以及与开发框架匹配的文档组织格式等。
以下的文档是根据我所做业务以及实现框架而做的格式，你可能需要根据你们自己的情况来制定属于自己的backlog格式。
制定Backlog的考虑点
1.由于流程可以动态变化，以静态的功能分解和信息结构作为backlog的主要输入
2.考虑软件产品线工程，进入开发前，设计产品的721
3.结合业务框架的模型抽取来编写业务实体以及功能
4.尽量结构化文档，不采用纯文字描述，逐步抽取出具有确定含义的文字
5.术语和规则作为sprint文档之外的重要文档
产品业务模块backlog
以下是实际工作中的一个示例：
- 按照子系统、业务模块来组织产品backlog
- 每个子系统和模块都附上唯一的编号，文档中任何地方都可以引用
- 输入、输出表达模块之间的关系，这个从业务架构的流程、功能分解中输入
- 执行者和目的对应业务架构的角色和价值点
- 范围、工具和技术属于业务需求内容
- 7/2/1是根据业务、市场来划分此模块是通用功能、可变功能还是定制功能
产品模块功能backlog
产品业务模块backlog大部分内容除了7/2/1之外，大部分内容只是业务架构的另一种表现形式而已。到了需求阶段，必须对产品业务模块backlog进行细化工作，那就是产品模块功能backlog：
- 按照业务模块、功能点来组织模块功能backlog
- 抽取公共业务功能、通用业务规则，例如列表模板、通用编辑方式、通用业务功能，这些通用规则和说明形成单独文档，作为技术架构的输入
- 业务规则列链接具体的业务规则说，业务规则的写法根据遇到的规则类型定义自己的结构化格式
- 功能点仍旧也要做721设计
- 对于非通用性的业务功能需要描述具体任务操作步骤以及价值点
- 加入关注的非功能性需求，我们现在只加入了效率
- 大多数情况下，这个文档的模块能够对应到开发中的实体，功能点能够对应到界面上的一个按钮或右键等，这样有利于以后转向模型驱动平台下使用设计器来进行产品开发
术语表
如果术语很多，可以进行分组编号
规则表
业务规则对系统来说是核心内容，这部分内容必须仔细查看。规则分析得是否正确、完整是系统实现的前提，每个业务需求通过抽取应该能够形成一些通性规则，对于通行规则可以作为技术框架的输入，由框架统一实现
一些问题
业务架构需要做到什么粒度？
架构是产品的上层框架，只需要到具体功能模块以及主要业务功能就行，具体的业务规则和异常处理都不需要考虑，那是需求分析的事情
业务架构是否需要做原型？
需要，只是会很粗，并且不在意具体的UE，但是需求阶段的原型应该可以从业务架构阶段的原型中细化下来
有没有统一的规则表模板？
不同业务的规则是不一样，不同小组的设计能力也是不一样，不同平台支持的规则DSL也是不一样的，这个需要根据自己的情况来定义自己的格式，但必须能够把规则描述清楚，做到自己、开发人员和测试人员都能一看就明白
需求阶段需要出以前的详细需求规格说明书吗？
对于内部来说不需要。但是必须要有原型，还有我上面说的几个文档，记住一定要保证同步。 |
