TOGAF的元模型中有很多多对多的关系，比较搞的是功能，流程，服务。

分层加入后难度就一下子上升了，用ER建模的思路，如要简化多对多关系，中培专家建议可以引入一个实体变为多个一对多，就可以了。

业务架构和业务需求

TOGAF并没有太多内容来描述如何做业务需求，但是这是我们必须要做的事情。从上面的阐述能够发现，我是希望业务架构和业务需求能够有一种方法进行衔接的。其实业务架构和业务需求本身就不冲突，两者只是处在一个事物在不同层次的东西。架构关注的是更全面、概括、组织方面的东西，而需求关注的是用户关心的业务细节，业务需求是业务架构的进一步分析。

业务规则对系统来说是核心内容，这部分内容必须仔细查看。规则分析得是否正确、完整是系统实现的前提，每个业务需求通过抽取应该能够形成一些通性规则，对于通行规则可以作为技术框架的输入，由框架统一实现一些问题。

业务架构需要做到什么粒度？

架构是产品的上层框架，只需要到具体功能模块以及主要业务功能就行，具体的业务规则和异常处理都不需要考虑，那是需求分析的事情。

业务架构是否需要做原型？

需要，只是会很粗，并且不在意具体的UE，但是需求阶段的原型应该可以从业务架构阶段的原型中细化下来。

有没有统一的规则表模板？

不同业务的规则是不一样，不同小组的设计能力也是不一样，不同平台支持的规则DSL也是不一样的，这个需要根据自己的情况来定义自己的格式，但必须能够把规则描述清楚，做到自己、开发人员和测试人员都能一看就明白。

需求阶段需要出以前的详细需求规格说明书吗？

对于内部来说不需要。但是必须要有原型，还有我上面说的几个文档，记住一定要保证同步。

不要夸大IT的作用

经常看到有企业对外宣传上了一个什么大系统，以此来对外说明自己借助于企业信息化而开始具备了一些竞争优势。企业信息化的确能够加强企业竞争优势，只是现在到处都提最佳实践，而又想有竞争优势，那就都开始定制化。定制化并不是一件轻松的事情，企业基本上都会花不少钱，那既然花钱了，而且还不少，那抱的期望自然也会比较大，这容易无形之下夸大了IT的作用。

如果从独立系统来看，我觉得带来一定的效率提升是不成问题的，毕竟软件企业也不是招摇撞骗的，当然有些政府项目除外。然而，如果你希望通过在上一个软件系统的同时，寄希望于专长搞技术的 IT厂商同时还帮你们制定企业战略，那我觉得这可能会令你们失望了，也许将来还要为之付出代价。

IT信息化是帮助企业运营的，而运营执行的是战略，从这个先后顺序来看，那就是IT是在战略规划之后，而且这是由两拨不通技能要求的团队来完成。我们不能把IT太高估了，他们并不是无所不能的，我倒不是说软件企业没有这种能力，只是术业有专攻，企业不能把一个管理上的问题直接简单转换成一个IT问题来解决，否则得到的解决方案也一定是一个IT方案，而不是解决管理的方案。我认为管理问题还是通过管理的方式来解决更好些，该做企业战略咨询的还得做咨询，该自己思考业务的还得自己规划，IT相对这些来说，更向是一个战略执行的工具而已，不能本末倒置，IT工作的输出绝对不会是战略，否则容易出漏子的。

中培不仅是国内IT培训领域的顶尖品牌，而且还是The Open Group在中国区的黄金会员；中培已获得The Open Group的正式鉴定授权，唯一以TOGAF认证培训为主导的黄金会员机构；TOGAF认证作为中培最具影响力的精品课程之一，已获多方面专家的认证。

想了解更多IT资讯，请访问中培教育官网：中培教育