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所提出的定义非常相近。不过，根据该定义，为了使企业符合合适的架构原则，而对他尽心修补和改进即是架构。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。