Jason Bloomberg最近在博客中问道：“为什么没有人做企业架构(Enterprise Architecture)呢?”他说：
解决方案架构师应该在实施解决方案之前完成解决方案的架构设计。Java架构师和.NET架构师做得事情应该先于编程人员。你不能先实施架构再设计架构，只能先设计再实施……可是，企业架构(Enterprise Architecture)却往往从现有企业开始……当今企业架构师的角色主要面对当前企业，修补其中的问题。好吧，也许不全是这样，但却要做某种程度的改进。将企业架构从当前的“糟糕的”状态扭转到“***的”状态，在这一状态下事情会变得更好。
Bloomberg认为，虽然解决现有企业的问题既重要又高尚，但是这并非企业架构的工作：
架构不是解决问题，而是为设计活动建立一套***实践。
所以，在他看来，没有人在真正地做企业做架构。企业在不断成长，
每个企业家都知道这个基本道理。当企业***坐下来，为新的商业投资制定方案时，如果组织(organization)大到可堪称企业(enterprise)，他们也许永远也不敢对它做全面的架构设计，因为这里面有太多未知的东西。相反，他们却喜欢建立一个不断成长的框架。播散种子，为之浇灌、除草及施肥。如果运气好的话，沿着这条路走下去，也许能收获一个不错的、健康的、不断发展的企业架构。但是最终的架构看上去可能与最初设想的样子相去甚远。
Bloomberg继续说到，这与企业架构(Enterprise Architecture)的概念有很大差异，企业架构要定义并建立一组***实践，通过它们去实现企业预期的最终目标。问题是：
发展企业……意味着它会像任何生物体的生长一样，没有确定的最终状态。一粒橡果最终将会长成橡树是确定的，但是这棵橡树到底长成什么样子，确实无法计划的。相反，橡果的DNA决定了会长出橡树这一基本属性，但是其他的东西就取决于后天的变化了。这类变化确定了复杂系统的特征：系统具有各种变化的属性，但这些属性综合起来却不同于任何部分的属性。就像生物界的机体依赖于变化一样，企业的发展同样依赖它。
Bloomberg认为，改变企业架构的目标是没有意义的，相反应该引入一些新原则：
也许，应该为架构的变化确定***实践了。毕竟，如果我们可以对传统系统做架构，为何不能对复杂系统做呢?……我们到底能否找到实际做企业架构的方法?毕竟，企业架构需要的是复杂的、系统的方法。***，还得看“能不能那样做企业架构(Enterprise Architecture)”。
JP Morgenthal在这篇帖子的评论中说道，问题不在于企业架构的原则，而在于企业架构(Enterprise Architecture)这个词本身：
……企业架构这个词如果换成多维度架构(multi-dimension architecture)可能更好。后者更好地抓住了该活动的本质，而且没有将它限定在某个特定的范围内——范围视任务的大小而定。我一贯认为业务与多维度架构保持着紧密联系。人们设计的解决方案包括业务流程、工作流、应用、用户体验、网络连通、灾备/恢复等;但是，思考系统的任何一个部分可能对其他部分造成的影响时，还有哪些东西呢?对我而言，这才是最初创造企业架构(Enterprise Architecture)这个差劲词汇的本意所在。
我们是可以评论企业架构这个词是好或是坏，但是，而现在当人们已经接受了这个叫法的时候去改它，显然不是一个好建议。其结果只能是带来更多的迷惑和论战。根据IEEE标准1471-2000对于软件密集型的系统架构的描述，IEEE建议：
架构是对系统、系统的内部组件、组件之间的关系、与外部环境间的关系、指导其设计和发展的原则等方面的基本组织。
此定义丝毫没有谈到最终状态——它所关心的是人们改进和发展系统时所遵循的原则，这与Bloomberg和Morgenthal所提出的定义非常相近。不过，根据该定义，为了使企业符合合适的架构原则，而对他尽心修补和改进即是架构。
【编辑推荐】
