最近有不少的文章关注企业架构的角色及其与业务战略对齐的重要性。引用 Chris Curran 的描述：
EA 经常背离了它的初衷，这是因为大部分的关注都放在“EA”本身，而不是它的产出上。即要更多的关注于一个健壮的协作的业务计划，让 EA 本身退到幕后。
在企业架构战略–艰苦摸索而得的 16 条经验的讨论中，Curran 写到：
业务部门与 IT 伙伴之间良好的可靠与信赖能够预测 EA 是否成功。可靠性通常能够通过开展联合的战略计划工作来获得，每次一个项目。
Curran 接下去讨论了五个常见的架构谬说：
-
企业架构是 IT 用来对其技术进行规划的。根据 Curran 的说法，技术只是企业架构的组件之一：> … 一个良好的 EA 项目，首先开始于对业务单元及功能的任务 (目标，量化指标，某种形式的战略) 进行良好的表达，并以此作为基础理解哪些是需要的业务能力，然后搭建起业务和技术的蓝图和规划。
另一方面，对于试图将大部分精力花在构建这样的一个蓝图上的作法，他提出要审慎：
一个穷尽的企业层次蓝图几乎是不可能实现的——它太大了同时也不会有人买帐…最好的策略是将导向明确的企业蓝图与业务单元和领域的蓝图综合起来。
-
没法对企业架构进行衡量。在 Curran 看来，能够正确衡量的唯一企业架构就是业务驱动型的：> 能够并且应该被衡量的是在开发与规划过程中所交付的按优先次序的业务能力。一旦这些能力被交付，与其相关的业务指标也相应的得到衡量。
他继续表示，EA 应当以两种方式进行衡量：所交付的业务能力与核心服务的成本：
将 EA 作为资产衡量——提供服务需要的代价是什么，而通过交付业务能力能够从中得到什么回报？
-
架构师只是拿架子罢了，他们不干活。Curran 认为，技术驱动方式的一个副产品，就是架构小组花了太多时间去与供应商洽谈，撰写白皮书和实现那些完成之日遥遥无期的技术原型：> 做架构的公司最好将大部分的架构师作为核心团队成员“分配”到项目中去。这样，相反地，他们才能把日复一日的不断发挥专长。
他甚至还为架构师们应当投入到项目工作中的 (平均) 时间作了定义：
架构师必须作为核心团队成员分配到项目中 (60% 以上的 EA FTE 总数)，而不是作为“顾问”。
-
企业架构与 SDLC(软件生命周期) 无法一起使用。在 Curran 看来：> 方法与治理必须集成到现有的工作流程中 (例如，项目审批，SDLC）而不是一个全新的覆盖。
否则的话架构流程将是孤立的，而不是集成到日常工作的企业活动中：
在两个地方应当有 EA 流程，紧跟高层的业务策略方向和优先级，嵌入到计划项目以及 SDLC 管理流程中，保证每个项目中都能按计划设想实现跨系统的蓝图。因此，要促进 EA，不仅必须与 SDLC 搭配起来，还要兼顾所有其它的计划和项目级别的流程和方法。
以 Curran 的经验来看：
高效的团队能够将一致的，正式化的 EA 融入到 SDLC 中，并能为每一个项目将蓝图详尽的转化为启动的架构，对成本和资源作出准确的估计。
他同时还写到：
成熟的组织将 40% 的目标时间花在 EA 资源策略计划上，60% 花在 SDLC 栈上。而花更多时间在 SDLC 栈上通常是错误的。
-
如果你遵循 SOA，你就不需要 EA。Curran 解释了一些公司尝试采用一些特别的架构风格，比如 SOA 或云计算来推动其企业架构。而最终有可能会形成“一刀切”的结果，并把这种风格用到每一个架构决策上。 > …如果由业务引导 EA，能带来合适的计算模型和风格。选择 SOA 模型仅能满足一小部分的技术架构，而对于整个 EA 蓝图中的某些业务领域却无法满足。
Curran 深入地观察到许多公司的企业架构团队所面临的问题。遵循他的建议对于企业架构师和管理层来说都大有裨益。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论