企业架构到底是什么?

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

Via:Infoq

 

收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部