在开始深入研究架构模型之前，我们首先要清楚模型的准确定义。许多架构师经常将模型和图混为一谈，但它们的意义并不完全相同。要理解它们之间的区别，以及为何模型要比图更有用，对我们来说至关重要。

模型是采用形式化方法对系统或系统部分的一种规范。那什么是形式化方法呢?形式化方法是指用精确数学符号来描述事物的方法，而精确数学符号指的是语法(或结构)和语义(或含义)规则都有明确定义的符号。典型的精确数学符号便是算术等式，加法符号(即“+”)的语法是公认的，其语义定义也很清晰(即将“+”符号左边的数字增加到“+”符号右边的数字上)。加法符号还有其他关联的语义，比如传递属性和互逆属性，这些语义也都具有清晰的定义并且得到公认。因此所有熟悉算术的人在看到“+”符号时，对其含义都会有共同的认知。

与之相比，图是对事物的图形化表示。有些图也可能具有形式化语法，但是它们在数学上却是不精确的。例如，任何人都可以使用Microsot Visio之类的绘图软件来生成对系统或企业的图形化描述，但是这些图的语义定义并不明确，并且充满歧义。被某个用户用作Web服务器的图标可能会被另一个用户用作数据库服务器，我们只能通过明确的图例(用于指定图中使用的图标所代表的内容)来减少歧义。此外，图中元素之间的关系也不明确，元素的许多内容都没有被定义，比如，Web服务器可以连接到哪些元素，以及它们之间是如何连接的。由于未明确指定元素之间的关系，因此对图执行自动化分析很困难，只能在一定范围内或一定概率上产生准确的结果。虽然图在向人们传递思想方面具有独特的优势，但其固有的低准确性问题导致很难对其进行自动化分析。

许多企业架构活动的重点都放在图的生成上，因为与正规的模型相比，图更易于生成，而且对于管理者而言图也更容易理解。使用 Glify、Balsamiq、Microsoft Visio或其他工具可以创建各式各样的图，但它们并不是模型，也不能使用自动化方法对其进行分析。并且由于它们与实际系统和接口之间的关系精准对应，因此每次更新系统时都必须手动对图进行更新。手动更新图需要花费大量的时间和资源，而这些资源本来可以投人到对企业更有意义的工作中。

请不要被前面有关形式化方法的讨论吓到。市面上有各式各样的建模工具，这些工具能够让架构师们更加轻松便捷地构建精确数学模型。这些建模工具通常提供了对建模方法的抽象，不再使用数学语言而是使用图形符号来描述架构。简而言之，这些建模工具屏蔽了数学的细节，使架构师能够更加专注于全局。总体而言，市场上大多数建模工具都对常用的建模语言(如UML、SySML等)提供了良好的支持，这使得架构师可以专注于对何建模，而不是如何建模。

在1979年5月发表的一篇论文中，数学家乔治·博克斯提出“所有的模型都是错误的”。这是因为任何模型无论多么精确，都是对其所代表事物的一种抽象，而抽象本身就是错误的，因为它缺少了原始事物的某些细节。如果不缺少任细节，那它就是副本而不是模型了。当执行建模任务时，必须要确定模型在哪里会出错，但是，同样也不要忘了博克期名言的下半句“但是其中一些有用”。建模中最棘手的问题是确定模型的哪一部分可能出错，同时确保模型仍然有用。

我们将企业架构称为企业的一个模型，这种说法并不完全正确。实际上，企业架构并不是一个单独的模型，它是一系列相关模型的集合。模型集合中的每一项都是对企业某方面(例如，企业的信息系统)的描述，当然，企业也有未进行建模的某些方面，也就是说，架构师决定了企业架构的哪些部分是错误的，因而未对其进行描述。企业架构师的任务就是要确定必须要对企业的哪些部分进行建模，以使得架构有用。

除了决定要对企业的哪些方面进行建模之外，架构师还必须决定模型的详细程度。对于组成企业架构的模型，架构师必须决定哪些部分需要进行精确的构建，哪些部分可以简化乃至忽略。同样，架构师也需要确定每个模型的错误程度,即模型的哪些方面是最重要的，哪些方面可以抽象表示。

没有严格的规则来指导对何进行建模以及每个模型的详细程度。决定对何进行建模（以及达到何种详细程度）更像是一门艺术，而不是一门科学、它会随着环境的变化而变化。例如，将开发系统模型作为系统架构的一部分时，该模型必须精确定义系统将要执行的操作，并且准确地描述最终系统将如何运行。但是，正如前面所说的，企业架构并不需要详细到这种程度，在企业架构中，这样的详细程度会造成资源的浪费。

虽然在确定对何进行建模时并没有严格的规则，但通常我们可以借鉴一些经验，其中最有用的一条是:应当针对待解决的特定问题进行建模。也就是说，当架构师或管理者需要更好地理解企业的某些方面时，可以创建该方面的模型，该模型需要足够详细以回答架构师或管理者的问题，但仅此而已，除了回答这些问题所需的细节之外，创建另外的细节都是在浪费精力，并且随着时间的推移，维护模型所需的工作量会不断增加。

为了说明这个概念，我们来看一个简单的例子:假定公司管理层想弄清楚公司需要从外部获得数据的种类和数量，这个问题可以通过对公司系统中获取外部消费数据的接口进行建模来解决。仅对此问题而言，对公司内部系统之间的接口进行建模则是多余的工作，因为公司内部系统之间交换的数据并不在本问题讨论范围之内。当然，可能会有其他的理由需要对那些内部接口进行建模，但是，对于回答上面那个问题,内部接口建模不会有任何帮助。

另一个好的经验是，要为整个企业中需要标准化的事项进行建模。首先，这将是大有益处的，因为它为所需标准化的事项提供了独立的规范，该规范可以被系统的实施团队重复使用，为实施团队节省一些工作，也能让不同的实施团队更容易创建相互兼容的功能版本(如果不同的实施团队从同一企业模型中仍然创建了不兼容的版本，那么就说明该模型还不够详细)。其次，创建独立模型能更容易地评估企业整体的一致性，每个实施方案都能够按照相同的模型进行评估。

例如，对用户面言，普遍存在的问题是不同的系统往往需要相互独立的用户名和密码，用户需要记住所有的用户名和密码，并且能够区分其对应于哪个系统，这是一项困难的工作。为了改善这种情况，企业可以决定所有系统都使用公共身份验证组件，在企业的层面上创建此组件的独立模型的工作量会比各个实施团队分别针对自己的设计创建此类型的工作量更少。

我们要讲的最后一个经验是:合理确定单个模型尺寸。数量众多的小型模型会使得管理工作变的困难，数量少但复杂的模型会让人难以理解，合理确定模型尺寸就是对这两种情况的一种平衡。一般面言，如果某个组件的定义明确，并且可以对其进行独立分析，那么它的大小就可能适合建独立的模型。请注意，模型不必设计得很复杂，只要可以回答架构师和管理者的问题即可。

总面言之，创建架构模型时要努力达到的效果就是：模型有用。正如乔治·博克斯所说的那样，“模型往往是错误的”，那是模型的固有特征，但是，这并不意味着模型就没有用处。确保模型有用是架构师的首要任务。