现在是伦敦的冬天，你可能已经猜到了，一整天都在下雨。在这种天气里，我们做不了太多别的事情，除了上网冲浪。这也正是我所做的，而且我在微软的Inside Architecture BLOG里发现了Nick Malik大约一年前写的一篇文章，相当不错。这篇博文最有意思的地方在于作者回应了我的博客，也就是我从架构主体的观点分析IEEE 1471标准的那一篇。下面就是Nick的阐述以及我的评论：

　　Michael的结论“是一种视角和观点，而且很喜欢IEEE 1471标准，是因为这是一种描述而不是架构和企业架构的 定义。”恕我直言，我认为Michael并没有抓住要领。IEEE-1471并没有定义具体的企业架构，也没有抽闲企业架构元模型。它定义了架构本身的概念。为了将这些改建集合，中间还有很多过程需要理解。说IEEE-1471没有定义EA就像是说“哺乳动物概念不能定义我的猫一样。”

　　这条评论在后面很好地解释了IEEE-1471：任何架构的概念模型，尤其是微软采纳了。我很高兴这条信息表达的方式很直接。但这是Nick的观点。

　　IEEE 1471（根据标准本身）的五条原则之一是：“架构和架构描述不是一回事” ，而且IEEE 1471可以替代“IEEE架构最佳做法，描述集中软件系统。不是吗？”在我的博文中，我仅试图解释架构主体从架构描述中脱离出来了。并不是要探讨“具体的企业架构，或者抽各项企业架构元模型，”作为反对标准的论据。因为这没什么意义。

　　我的本意如下：

　　a）如果仅依靠外部的观点，事物定义模糊、不完全或者甚至不正确。这样的观点并不会成为事物的核心，但是可以轻易混淆主体动机。

　　b）基于企业架构定义设计EA，主观上充分考虑利益相关者是通向地狱最直接的方式（尽管它可能是黄金途径）。每一个利益相关者需要能够以其个人的方式看到EA，但这并不意味着EA为了在任何时刻取悦利益相关者而必须改变。这将会是企业战略和个人意愿之间的鸿沟。因此，利益相关者的观点必须用由内而为的信息来处理，而不是倒过来。

　　c）EA是什么和企业架构要做什么是不同的。EA的主体和管理是什么。后者包含满足利益相关者目标的元素。

　　我的目的相当简单，至少，比IEEE 1471标准简单。让我来改述一下Nick所说的：

　　“我的建议是：不要将概念企业架构定义成一套观点，而是用‘描述’具体化EA模型为理想元模型上的一套观点。因为这些观点有目的性。了解了这个目的，来温和EA利益相关者的关注点。”