在他的新博文——企业架构价值的命题——Richard Veryard 探讨了企业架构（EA）的价值。
关于企业架构，有传统的观点（EA 即 IT 规划），也有新兴的观点（EA 即企业战略 ）。EA 的价值命题已经打开了一个……关于企业架构团队未来可能的发展方向及其要担负的多种使命的讨论。
在 Richard 看来，讨论 EA 价值命题的关键问题之一是时间尺度。一方面，EA 团队的典型任务是通过对新业务和技术能力的研究和发展从而为企业带来长远利益。这种 EA 方向的问题在于企业要花很长时间才能衡量和实现这种（长远）利益。另一方面，EA 团队经常被分派去带领企业项目，目的是提高 IT 项目的成功率。
Richard 指出了让 EA 和项目过分紧密结合的两大问题：
问题之一是视角问题。如果 EA 与项目结合太紧密，那么 EA 的视角与项目视角有何区别呢？如果项目正做错某事，EA 怎能从项目本身的视角来解决该问题呢？此外，EA 对业务需求的理解很难与优秀的项目业务分析员有太大差别。如果 EA 不再从长远考虑，那么它的价值很大程度上只能基于这样的假设：架构师们可能比业务分析员拥有更多的知识和经验，以及工具和技术上的优势……另一个问题是预见项目风险和确保项目成功的工作（在企业内部）严重重复，在一个大的 IT 组织里，我们可能有项目管理、程序管理、IT 治理、工具和方法、品质管理（控制和保证）和企业架构等团队，每个都具备自己的“知识体系”，所有的团队都尽力阻止项目失败（和损失信用）。此时，“仓筒”（silo）这个词在脑海中浮现 [译者注：团队之间孤立，无知识共享]。
这个话题还直接关系到谁是 EA 的真正客户这一问题
……给 EA 付工资的 CIO 或 CFO？还是业务线管理及 IT 项目的经理们（他们被要求“为了自己的利益”而在 EA 上花费时间和精力，却往往并不感激 EA 的殷勤款待）？
这个话题在 Richar 的另一博文—— EA：整体思考，局部行动——中也有讨论。
他指出，关于 EA 的角色有很多观点：
- Nigel Green > 如果你说的 EA 指的是 Forrester 定义的 Business Technology 的话，我认为是全局的……EA 关心的是业务转型而不仅仅是 IT
- Anders Østergaard Jensen > EA = S + B + T，从这个公式可以看出 EA 是全局的。
- Colin Wheeler > 我认为 EA 是一个逻辑框架，在这个框架中业务可以做合理的决定，对我而言无疑是全局的。
按照 Richard 的说法，将 EA 的局部和全局的理想结合起来是由 Tom Graves 建议的，Tom 引用了 Patrick Geddes 的口号：整体思考，局部行动
全局！只有 IT 本身就太狭隘了……EA 要是不是全局的就会给 IT 带来问题。局部行动（IT），全局思考（EA）。在 IT 系统中应用 EA，但始终心系全局。“和大多数一样，Tom 始终坚信全局的重要性。” EA 是企业的架构，而非 IT 的架构——IT 只是实现，别无其他——丢掉 IT 中心主义！！
Richard 这样总结他的博文：
很明显，在现实（企业架构师在 IT 部门感到沮丧）和理想（企业架构师企业内被广泛尊重）之间存在着鸿沟。尽管我们赞同 Chris Potts 的说法，EA 应该是一种企业战略，但大多数公司离这个目标还有一段路要走。思考将来没有错，但是某些企业架构师也已经找到了一份日常工作。
企业架构和架构师的角色总体还在不断发展中。90 年代初，架构师很少，他们大多也是优秀工程师，并且不愿参与人员管理。到了 90 年代末，架构师成了一个时尚的 IT 职业。现在，IT 界有着各种各样的架构师，从 J2EE 架构师、“某产品”架构师到安全架构师。接着，最高级别的架构师，企业架构师就出现了。对架构师角色的定义一直以来众说纷纭，不同公司的定义有差异，它可以是从业务战略到技术导师的任意角色。结果，这个角色的定义非常模糊，对于问题“EA 到底是什么？EA 的发展的，变化的等式是什么？”，始终没有答案。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论