01 业务架构很复杂！
相信很多人都已经知道TOGAF，或者学习过TOGAF了，不少人觉得考证容易掌握很难。其实，要掌握TOGAF也不难，只要我们有一个正确的期望，你要知道自己当前处于哪个段位，然后逐步提升。有了这个认识之后，你会发现业务架构其实就不复杂了，当然，你也不能指望自己一学就会。就算企业经过培训，大部分还是要在外部教练的帮助下才能正确的开展工作。但您真的使用业务架构之后就会发现，您在实践中的概念其实还是我们在上一篇《这么理解业务架构就对了！》中所介绍的那些元素。
业务架构其实是一门比较简洁的学科，只需要对基础原理有基本的了解即可开始实践。在工作中，业务架构团队和业务部门更有可能因为缺乏业务主题专业知识而无法进站，而并不会因为业务架构学科的困难而受阻。随着我们后面的学习，如果您将业务架构应用于复杂的业务场景时，这个更加明显。
02 业务架构很贵！
我们习惯了从IT出发进行能力提升，因为觉得搞定业务很难。另一方面，对于组织级项目，觉得只要从业务出发就基本是大工程了。公司高层可能会觉得：没有业务架构师，招人或培养人需要钱；没有方法论，引进方法可能需要做培训请咨询，这又是一笔不小的钱；另外对新方法是否靠谱心里没数，即使有成功案例，但自己走一趟可能就全是弯路，这个代价也不小……
其实，我们算一笔账。没有业务架构，我们白花了多少钱？？？从投资回报率的角度来说，与其他主要学科（例如没有真正的投资组合规划下的项目管理）相比，业务架构的成本其实很低。我们大家其实都知道，有多少项目是真正成功的？
另外，如果您真的投入并定义了良好健壮的业务架构，它可以为企业服务多年，只需要不断完善即可。如果您一定要说证明了有用采取实施，我觉得这个在较短的时间内几乎不可能实现，这正如我给企业做流程管理微咨询过程中讲到的：活动级别优化价值显而易见，但业务场景和业务模式优化的价值度量可能真的只能来自于高层的自我认知。当高层决定不改就解决不了问题，或者可能带来更大问题的时候，采用这个方法其实就不需要验证就可以决定了。
03 没有通用定义的业务架构方法！
业务架构其实是企业架构的一个重要架构领域，所以说业务架构也已经存在不少时间了。我在为什么需要企业架构师？中提到，我是在2009年开始践行企业架构的，那时EA谈到比较多的是“业务与IT的融合”，所以有些愿意琢磨的企业架构师就会去想业务架构应该是怎么样的。
下图是我在BangBA（business analysis）实践公开课中给大家分享的我之前工作中的一些方法论，可以看到业务架构其实有了好几个版本。
虽然是我们自己的企业最佳实践，但我们建立这些方法也是站在巨人肩膀之上的，例如TOGAF、CBM、PCF等。而8月初我给一个企业做的一个产品架构内训，可以看做是之前版本的一个升级，其中很多新思路就是引用的BIZBOK。
但我们知道，每个企业的实践方法一般不会对外发布的，所以学习起来成本较高。但现在我们已经知道了，BIZBOK是一种通用的业务架构方法，它定义明确，并在全球众多企业和行业中使用，只是目前在国内的应用还很少，掌握这个学科的咨询师也很少。IT帮也希望在未来5年能够培养一批业务架构师。
04 可以在有限的业务投入和承诺下建立业务架构！
我们在 这么理解业务架构就对了！ 中提到了业务架构来自业务，这就意味着只靠IT，或者业务只是参与的话，业务架构的结果就已成定论。
相信“中台”这个词听得不少了吧。我之前从不同角度写了两篇文章：《从企业架构角度说一下：中台》和《从技术角度杂说一下：中台》，后来就不怎么写了，因为写来写去您还是需要回过头来掌握早已存在的理论和实践。有多少冠名“中台”的部门，其实就是几个IT人员窝在自己的隔间里把框架搭建出来的，业务人员基本就是过客，这也为中台项目大部分很难满足预期期望埋下了隐患。
如果说企业架构，我在认证公开课开始都会给大家补充一张企业架构实践成熟度的图。较低级别的话，可能还真的是关注IT，这个时候您还可以争辩一下业务的投入和承诺重要性。但我们如果明确要做的就是业务架构，你需要从业务、产品甚至战略方面来谈架构，但如果缺乏与业务专家的频繁互动，出来的一定是不能反映业务的无效业务架构。这背后的很大一个演员，就是缺乏业务承诺和支持，所以我们谈到要做业务架构，就一定要有业务的投入和承诺，甚至可能是由COO来主导业务架构项目。
05 可以许可或购买业务架构！
我们可能会简单理解业务架构工作就是使用前面提到的能力、价值流等元素去描述业务模型，而现在又会有一些行业参考模型可以作为快速启动的“捷径”。但我们需要知道，对于给定的业务而言，业务架构是唯一的。参考的基本上都是共性的，而业务架构的目的是为了帮助企业战略落地，这必然是需要满足必要的差异化水平。
另外，每个企业都有自己的术语和结构，这都要求企业定制自己的业务架构来与竞争对手区分开来，只有这样才能提高客户价值交付并且持续创新脱颖而出。所以对于企业来说，您需要了解业务架构基本逻辑，掌握这个方法，知道如何一步一步的构建您的业务架构并加以利用。
06 企业不需要业务架构，因为已经了解了所有需要了解的业务！
有些业务部门会觉得不需要做架构，因为自己天天做着这些业务，不需要描述也能够一清二楚。假设这即使是真的，有没有想过当应用于跨业务部门、跨项目群或项目时，业务是否还能够清楚？应用的边界是否清晰？数据所代表的信息是否理解一致？…… 业务词汇、思维模式和利益相关者参与的视角在各个业务部门之间差异很大，并且通常是分散的。每个人都从一个角度或一个角度看待业务，这使得除了小问题之外的大的问题分析和解决都变得困难起来。这个时候我们会觉得一切好像都不透明起来。
而业务架构通过商业生态系统的整体设计，揭示了通常在给定业务部门或主管的视线中隐藏的问题，提升了业务的透明性，这给企业带来了极大的价值。
07 业务架构是一门IT学科！
业务架构代表业务，而不是数据、解决方案、应用程序或技术架构。因此，企业必须参与、理解和利用业务架构，才能利用该学科。任何将业务架构与IT架构混淆的人都需要了解其在战略对齐、计划管理和其他业务计划中的用法。
08 业务架构特定于项目群、项目或业务部门！
上图是TOGAF实践公开课的一张讲义。我首先要说的是，业务架构的确可以应用在特定项目群、项目或业务部门中。但我们需要明白，定义越狭窄，业务架构交付的价值就越低。这也就是IT帮常说的，以终为始，我们更要关注组织级的业务架构，而非项目级，这才是业务架构的应用基准，所以业务架构不应受项目或业务部门的限制。
难度是肯定比较大的，但一旦建立了业务架构基础，就可以反复利用结果，并随着该学科进入越来越多的业务领域而建立可持续的价值构建，这是值得去探寻的。
09 业务架构能力图是可交付成果！
如果不与业务架构的其他方面合并，则能力地图只是业务架构的一种交付物，其价值有限。没有价值流的能力就其价值和对业务的影响而言缺乏上下文。将整个业务架构集成到更广泛的业务实践和管理学科中，才能实现真正的价值。
10 业务架构是进行业务分析的理想名词！
业务分析通常在逐个项目的基础上定义解决特定业务问题的要求和解决方案。业务架构提供了跨项目组合的透明度，使业务分析人员可以更有效地执行并提供更好的解决方案。这两个学科是独特且截然不同的，并且业务分析师应该可以访问并利用业务架构。业务架构提供的透明性为一直努力调和不同，相互矛盾的业务观点的项目分析师带来了一套全新的、有价值的是视角。
可以看看我之前写的《业务架构师和业务分析师有什么不同？》
业务架构师业务分析师
Why找出业务单元的战略需要差距，设计实现这些需要的业务架构，并发起举措来实现这些差距开发和文档举措要解决的详细业务问题知识
How分析未来战略、捕获能力、建模内外部关系，开发跨职能路标来解决差距。不捕获系统需求。访谈现有利益相关者和专家来了解流程、信息和使用的系统，之后来解决特定问题。这个活动主要结果是系统需求文档。
When周期性业务战略、周期持续触发当问题被识别后及需要解决方案需求后触发
Who熟练掌握业务职能、商业等问题的业务或IT通才，必须具有很强的能力分析和建模技能了解信息和应用、需求分析、系统开发方法的通才，必须具有很强的IT需求捕获能力和建模能力。
What商业动机模型、价值流、业务场景、能力模型、热图、风险图等业务需求、业务规则、用例和详细的业务流程描述
11 业务流程是业务架构的一部分！
业务流程和业务架构是两个独立但相关的学科。它们的形式、功能和意图不同。业务架构使企业能够实现其业务模型，而流程使企业能够实现其运营模型。
但是，可以将这两个学科联系起来，以提供有关业务影响分析，将战略转换为可实施的计划以及业务改进的更全面的观点。
12 业务架构阻碍了组织的敏捷性！
之前也写过《数字化转型两大抓手：产品敏捷+企业架构》，可见而业务架构是企业架构的一个重要组成部分，可见业务架构并不是阻碍组织敏捷性，反而是增强敏捷性。单靠敏捷开发实践并不能使组织实现端到端的企业敏捷性。实际上，这些做法可能会加速错误解决方案的创建。业务架构提供了业务的通用思维模型，确保业务在做正确的事情，构架并加速解决方案的开发，并根据业务目标衡量结果。它还可以进行动态重新计划，以应对不断变化的外部条件。
业务架构并不妨碍组织的敏捷性，实际上是成功实现组织规模化敏捷性的必要，这也是为什么在例如SAFe等方法中可以看到最高层中有EA角色的存在。
