架构策略与原则

最近有不少的文章关注企业架构的角色及其与业务战略对齐的重要性。引用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深入地观察到许多公司的企业架构团队所面临的问题。遵循他的建议对于企业架构师和管理层来说都大有裨益。

\

查看英文原文:Architecture Strategies and Principles