TOGAF:从业务架构到业务需求

做管理型软件产品一般都要经历架构阶段,而架构又可以简单分为业务架构和技术架构,对于架构方法,在我以前的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也是不一样的,这个需要根据自己的情况来定义自己的格式,但必须能够把规则描述清楚,做到自己、开发人员和测试人员都能一看就明白
  • 需求阶段需要出以前的详细需求规格说明书吗?
    对于内部来说不需要。但是必须要有原型,还有我上面说的几个文档,记住一定要保证同步。

发表评论