作为IT架构师，很可能经常会发现自己处于进退维谷的境地—前有业务目标，后有IT系统。这两方面都具有规模大、不易改变和灵活性差的特点，制定业务目标的人员和开发系统的人员不一定了解彼此的工作内容和成果。
业务人员使用一种语言来表达他们希望实现的业务目标，而开发人员则使用另一种语言来表述技术要求。而这就是我们为了实现高效率而需要着手处理的问题:理解这两种语言并执行必要的转换，以便 IT 能反映业务的需求，并能在适当的时候对业务目标进行更改，使其与 IT 的能力相适应。这并不是一个容易完成的工作，但这正是您能够获得很大利益的原因。
一个词:用例
在业务用例中，参与者是干系人，而系统则是业务本身。
用电影《毕业生》中的方式，我只想对你说一个词:用例。很多年来，我们都将用例用于对应用程序进行建模。现在，在面向服务的体系结构 (SOA) 中，我们也使用这个概念来对业务进行建模。
在Alistair Cockburn的《Writing Effective Use Cases》一书中，他将用例定义为“系统干系人之间就系统的行为达成的协定”。用例必须适合所定义的系统范围，能够代表此情况下使用系统的主要参与者的观点，且能够在一致的抽象层次上表示参与者的系统使用情况。
例如，股票交易Web站点的一个用例是“购买股票”，允许用户通过此站点购买股票。该用例描述了客户进行何种操作以及站点如何响应，而暂时忽略了站点将如何实际实现此行为。
可以将用例用于对服务进行建模;我将此称为服务用例。当用例描述服务时，参与者就是服务使用者，而系统则为服务提供者。与任何用例一样，此时的重点是服务提供者提供何种行为，而不是如何实现该行为。
还可以将用例用于对业务进行建模。在业务用例中，参与者是干系人——业务用户（如客户或员工，甚至股东或政府监管人员），而系统则是业务本身（生产产品并将其销售给客户的公司）。业务如何开展？客户希望业务如何开展？他们愿意为何种服务或产品付费？员工需要业务如何开展才能完成各自的工作？关键在于，这些干系人如何与公司进行交互，这些都是业务用例。
获得了业务用例后，则可以随后将其链接起来，以形成业务流程—公司可以执行的过程。这些流程本身就是业务用例，而复杂的业务用例可以被视为业务流程。简单地讲，这些流程显示了公司要做什么以及如何做。如前面所述，流程以及每个流程中的步骤都对服务进行建模。
通过用例将公司或公司的一部分建模为由服务组成的业务流程后，随后的目标就是尽可能多地实现流程和服务的自动化。实现这种自动化的应用程序是采用面向服务的体系结构的应用程序，而现在正在进行 SOA 实践。
记录流程
如果客户不了解业务，架构师有效定义系统要求的几率都很小。
笔者在与客户讨论新程序或开发工作时，会立即了解业务干系人是否出席或派代表出席。然后，我会希望得到记录良好的业务流程和数据要求。除非相关工作是一片“处女地”，否则一定会对新应用程序或功能支持的原有的业务流程和将来的业务流程有良好的理解。不管采用哪一种方式，如果客户不了解业务，架构师有效定义系统要求的几率就很小。
笔者个人非常赞同开发业务场景来记录业务流程，业务场景允许在整个业务问题的上下文中标识系统要求。
确定了将来的业务需求后，如果能维护一份功能和非功能行式项目要求的列表，也很有好处。我极力赞同使用工具来管理要求;为了达成此目的，我建议使用 IBM Rational RequisitePro。
通过使用根据业务场景确定的初始要求集，我们就可以开始定义系统行为的过程了。为此，可以召开联合应
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
