企业架构研究总结感想

企业架构研究总结（10）——写在中间的感想

 好几天没有接着更新这篇企业架构研究总结了，除了忙于其他事物之外，关于之前几篇文章的几条评论也让我思考良久，我觉得在继续对企业架构和企业架构框架理论进行进一步的介绍之前，有必要停下来对一些概念进行进一步的阐明。不过，这篇文章只是基于我个人理解而来，恐有所偏失，但欢迎批评指正。

 

      对于企业架构是否仅对大型组织或企业才有意义这个问题，我觉得这是一个非常有意思的问题，也是一个非常好的问题，因为在实践中好像也只有大型的企业或组织实现了或正在实现企业架构，很少见到中小型企业对这个方面产生兴趣，我想这至少是由于如下几个原因：

 

• 大型企业或组织本身结构复杂，并且其所面对的问题也通常比小型企业要复杂，因而复杂度管理方面的需求较小型企业或组织要迫切，而企业架构本质上正是一门复杂度管理方面的学问，因而从这方面将大型企业或组织会更加倾向于采用这方面的技术。
• 大型企业做事成本要高与小型企业，这不仅仅包括生产和维护本身的固有成本，还产生于在大型企业众多人员、角色之间产生的沟通成本，如果没有一个像企业架构这样的沟通基座，这些沟通往往会由于描述语言、描述方式或对描述对象的理解不同而导致非常大的额外成本支出。而对于相对简单的小企业来说，对这方面的成本损失的接受力往往要更强。
• 在决策方面，由于大企业情况复杂，如果不能对公司本身、外界环境以及他们之间的关系有着客观的认识，领导层很难保证决策的正确性，而将企业作为描述目标的企业架构正可在此提供有力的决策依据。对于相对简单的小企业来讲，既然是“一目了然”，那自然就没有动力去费力建设企业架构了。

 

      通观以上几点我们可以总结为：小型企业机动灵活，其所面对的问题往往是各领域内的实现或自动化问题，高效快速是其特点也是它的生存之道，时间对于他们的价值往往要高于其他方面的成本，因而在极端情况下，交出一个可能会返工的产品来换取时间都是可以接受的，而对于大型企业来讲事情却不完全一样了。但这就是说小型企业不需要企业架构或这方面的技术了吗？其实这个问题也困扰我很久，但就本人目前的认识来讲，至少有如下几个原因可以让小型企业也考虑企业架构方面的建设：

 

• 企业总是处在不停的变化之中的，因而持续发展的小企业也会有着业务复杂的一天，因而需要这样一种复杂度管理的技术来适应变化。
• 为名称所累，“企业架构”听起来就好像需要对整个组织或企业进行架构一样，好像天生就有着庞大繁杂的特性，不过实际上企业架构的建设并非必须在一开始就要把范围放到整个企业之上，企业架构的建设完全可以从企业的某个子组织或某一个具体问题开始，并且只要在企业中推行一贯的建设方法（架构框架）就可由小积大，并最终达成面向“企业”的企业架构。因而，企业大小只是企业架构复杂度方面的问题，而不是应该有或无的问题。
• 企业架构的建设应该是一个持续的过程，企业越庞大，其企业架构也必然会越复杂，建设成本也会越高，而如果是小企业，正是由于其相对简单，其企业架构也会较为简单，建设和维护成本也会低得多，因而在小企业成长为大企业之前建设企业架构，并推行一贯的建设和维护方法（架构框架）将会比成长为复杂度难以管理的大企业之后再去建设和维护企业架构要节省出大量的成本。因而从这一点来看，小企业恐怕比大企业更应该推行企业架构的建设。

 

      虽然有着上述几点理由，但可能还会有人觉得此系列文章之前介绍的几种企业架构框架理论内容过于理论化，并不实际，并且其步骤也较为繁琐，好像推行起来会很艰难。我觉得为了解答这方面的疑问应该进一步谈谈我对“架构”、“架构框架”、“企业架构”和“企业架构框架”这些概念的理解，至于文章写得太过理论，是否有用，我觉得本文立意就是要介绍几个比较重要的企业架构和企业架构框架理论，所以过于理论是无可避免了，不过这并没有什么不好，因为企业架构的确不是一般的开发技术，不是看过两篇就可以着手实施的，至于是否有用就是各位看官如何在“理论”基础之上进行实施的问题了，这是个见仁见智的问题。不过本人认为，这些理论并非空洞无物，他们中的每一种框架都为企业架构的定义、建设、维护和使用提出了非常实际的指导和实施步骤，只要沉心研究总会有所感触，我觉得有必要把本人对一些基本概念的理解总结出来，供大家参考（这些概念都可以从前面的《企业架构研究总结（2）——问题的由来和基本概念》中找到，这里仅谈本人的理解）：

 

• 首先是“架构”。就我本人的理解来看，架构的本质并非是要解决领域内的具体问题，而是复杂度管理，用于将所面对的复杂客观对象、问题或解决方案的复杂度进行有效的分解和管理，并尽量减轻内外变化所产生的影响。领域问题的解决靠的是相关的解决方案，同样一个问题可以有不同的解决方案，虽然他们的目标是一致的，但由于各自架构的不同，各个解决方案的灵活性、坚固性和扩展性均不相同，因而我们在为解决方案选择架构的时候关注的并不是其是否可以解决目标问题，更多是对架构所带来的灵活性、坚固性和扩展性与相应成本之间进行权衡。正是由于架构并不面向领域中的实际问题，我想这可能是大家觉得其太过理论化的原因之一吧。
• 再来说说“企业架构”。顾名思义，“企业架构”可以理解为以企业为描述目标的架构，不过企业这一对象太过繁杂，更别说在企业架构领域内企业这一词也不单指我们常说的公司。从前述可知，架构的目标在于对目标问题的解决方案的复杂度进行分解和管理，那么对于“企业”来讲，企业架构所要管理的又是企业哪个方面的复杂度呢？就我个人理解，这一问题的答案是企业中的IT与业务的协调问题。从《企业架构研究总结（2）——问题的由来和基本概念》可知，虽然IT技术在企业中获得极大的应用和发展，但是其与业务发展的不平衡也逐渐显现，技术人员们往往强调了技术的先进性和超前，而忽略了业务的需要，甚至有时候IT技术甚至充当了放大器的作用，将决策的错误加倍放大，因而才需要将两者的发展进行协调。在这一方面，国外已经在几十年前就开始了研究，而这也就是企业架构理论的由来。由此可见，与领域内的各种解决方案及其架构相比，企业架构所面对的并不是具体领域（业务、应用、数据及技术）内的实现问题，而且即便是IT与业务相协调这一问题也有着不同的理论和最佳实践对其进行支持，但通过何种架构才能分解和管理这一问题及其解决方案的复杂度呢？我想这才是企业架构的目标，而且这应该也是大家觉得其太过理论化的重要原因吧。
• 再来说一下“架构框架”和“企业架构框架”。从名字可知，“企业架构框架”是以“企业架构”为目标的框架，那什么是“架构框架”呢？从我现在的理解出发，简单的说，架构框架就是用来创建、维护和/或使用架构的方法论。本系列文章截止到目前所论述的Zachman和FEAF其实都是企业架构框架，这里面论述了建设、维护和/或使用企业架构的方法。“架构框架”和“架构”之间的关系就像数学、物理知识和爱因斯坦质能公式之间的关系一样，前者提供了各种各种分析和运算方法，而后者是这些方法在某个领域内的产物。其实与企业架构理论相比，我倒是觉得企业架构框架明确了企业架构的内容和建设步骤及方法，是将企业架构落实的工具和方法，相对不应该那么空洞无物，不过如果忽视了企业架构的意义，恐怕企业架构框架也会觉得太过虚无缥缈。此外，由于业界的企业架构框架理论往往综合了多个组织和企业的实践经验，并天生具有高度抽象性，因而乍一看会给人一种过于庞杂的印象，其中步骤繁多，涉及到的企业架构内容也非常繁杂，但有一点需要说明，诸如TOGAF等有名的企业架构框架标准并非强制让人硬性照搬，相反鼓励使用者根据自己企业或组织的需要对框架理论进行定制和裁剪，因而强行照搬从某一方面倒违反了标准的精神，并且采用这种强搬的方式进行企业架构建设，也往往会让小企业望而却步，其实不然。
• 最后我想说一下我对（企业）架构和（企业）架构框架之间关系的一点理解。架构框架由于其通用性和抽象性，因而往往显得过于庞杂，使得使用者往往会觉得采用如此繁琐办法产生出的企业架构也必会复杂无比，难于维护，其实方法复杂并不代表结果复杂，就像前面提到过的质能公式一样，结果是如此简单，但是其产生过程和涉及到的方法却不是一般人能够明晰的。所以，如果觉得自己的组织或企业非常简单，而认为采用繁杂的企业架构框架建设和维护的企业架构必会非常复杂的想法是不太可取的，因为架构代表的是客观事物，如果组合或企业简单，那么其架构也不会过于复杂，更何况架构框架也是可以根据实际情况进行定制的了。

 

      罗嗦一堆，如有不确，希望指正。本人之后将继续总结联邦企业架构FEA（不是FEAF哦，虽然都来自美国联邦政府，但是就像企业架构和企业架构框架的区别一样，前者是企业架构实例，而后者是企业架构的建设方法，大家可以将FEA看作是企业架构在美国联邦政府的一个应用），有兴趣的话请继续关注。