社区圆桌会议：敏捷性与架构

整个访谈共分为三个部分，本文截取了其中部分内容，登录 OTN ArchBeat 随身播即可获取完整的对话内容。

Oracle Linux 高级产品经理。（德国汉堡）

School-Pay Solutions Inc. 支付系统架构和设计部门技术负责人（加拿大安大略省多伦多市）

Oracle 总监，专精于旧有系统现代化。Tom 与人合著了多本书籍，其中包括 《Migrating to the Cloud: Oracle Client/Server Modernization》（由 Syngress 出版）。（马萨诸塞州波士顿）

Oracle 企业架构师。（华盛顿）

我来说一说最近碰到的一件事吧，是关于企业架构内功能的概念问题。我认为辨别功能、为功能建模以及在功能之间建立通信很重要。但有些人对此感到失望，他们说：“哎，企业架构师成天就只会谈论功能。”功能类似于图表上的盒子。就好像，这是一个盒子，盒子里装有非常详细、非常重要的资源。

我看到了在功能级将资源映射出来的价值，但有意思的是那些人却始终看不到这一点。他们希望看到详情，所以当他们看到的仅仅是一些功能映射之类的东西时，就会感到非常恼火。但有些人就非常喜欢功能映射，这实际上就是人们看待问题的角度问题。有趣的是万物都存在两面性，所以有人感到很愤怒也是很自然的事情。不同的人有着不同的期待，所以他们看不到功能映射的价值。

我最近的经历都与敏捷方法有关。就像 Pat 说的那样，现在的情况是许多人不希望在企业级看到架构。他们希望迅速跳到详情部分，因而忽略了非常重要的一点，那就是，如果架构不正确，如果不能正确规划功能和关键信息，再往后，整个结构就有可能彻底倒塌。

在实践中，我时常体会到“敏捷”就是“冲动”的代名词，很少人关心如果把“敏捷性”置于顶级会导致什么结果。许多人认为是否先进行规划再放入盒子没那么重要：“只要能快速地将资源放在一起就行。”最后，您会看到，因为没有充分规划好这些盒子之间的通讯方式，您无法真正地置入更多资源。

因此，您认为敏捷性和架构之间存在冲突？

是的。不幸的是，人们往往将“敏捷性”看作是非常迅速、非常快的代名词，很少人懂得应该做到真正意义上的“敏捷”，而不只是“冲动”为之。

这就是导致根本分歧的核心原因，从企业架构的角色出发和从解决方案架构的角色出发将得出不同观点。我们全都这样 — 我们是技术人员。我们全都希望跳进解决方案，或者谈论所使用的协议。我们经常这样做，所以就习以为常了，但人们希望转到另一级别。Karina 说的对，如果高级别盒子放置的位置不正确，那么你所构建的解决方案就不可能长期有效，或者说对于总体方案而言没什么太大价值。

这真是太有趣了。我刚在计算机杂志上看到了一篇有关这个主题的评论。文章编辑仔细思考了近期遭遇失败的几个德国大型 IT 项目。在启动这些项目之前，相关人员确实规划了总体方案并制定了详细计划，并在几年时间内投入了数百万欧元的巨额资金，然而项目却未取得任何实质性进展。最后得出的解决方案也不尽如人意。

然后，他将该项目与其他项目（大多是政府运营的项目）作了比较，这些项目采取的方式是首先启动小型敏捷项目，然后开始逐步搭建，而且在项目执行期间也不避讳重新设计或重新构建解决方案。我认为是应该注意总体架构，但不应该过度设计它。我认为也可以把架构和敏捷方式结合起来考虑。只需要确保处理好这两个级别就行了。

无论是敏捷项目、长期项目，还是企业架构，我看到的比较多的情况是，往往要根据现有可用资源和当前的潮流趋势来决定将使用的技术或采用的解决方案。小型项目趋向于这种方式，是因为人们想尽快完成这些项目。所以，如果周围有人懂 Ruby on Rails 和 MySQL，或者了解 NoSQL，就会使用这些技术来交付项目。

企业架构也可能如此。每个人都有着这样的宏伟计划 — 我们要使用 UCS 刀片服务器、我们可能要用到 Oracle 数据库，然后计划使用 Glassfish 作为中间层。但是，之后时常会出现异常。然后，人们就会抱怨旧有架构及其现有基础架构太庞大了，支持了过多不同技术。我看到大多数公司犯着 20 年前犯过的相同错误，这真是太让人失望了。

宏伟愿景和可能永远无法实现的东西之间需要平衡一下。但是，你们必须制定这样的计划。你们无法否认这个事实，那就是必须跳出习以为常的操作，尝试一些新事物。Tom 说得非常对 — 你们已经习惯使用过去常用的技术或方法。但是你们习惯使用的方法无法带领你们进入下一级别。绝对不可能。困难在于：“嘿，我们真的全都习惯这样做。”但是，这种操作方式可能并不适合下一阶段。

那么，您将如何使利益相关方摆脱他们习惯使用的级别？我认为，特别是现在，在推动企业发展的过程中出现了这么多的新技术（云计算、面向服务、大数据、移动计算大爆炸），有关习惯性这方面的总体想法要抛到九霄云外去。

如果您想要有一席之地，如果您想要能够应对当前业务生态系统的实际问题，先不管 IT 中发生的情况，您就要将舒适性放到一边，说：“好吧，我们要如何处理这些事情？”

我和利益相关方进行过深入探讨，我认为最好的方法是创建功能原型。如果分配一定数量的资源来创建功能原型 — 但不是在生产系统中，有可能是在查询系统中运行，或是在开发系统中运行 — 然后将其演示给利益相关方看，他们就会明白我们可以做这件事情。我们可以朝这个方向发展。这比纸上谈兵强多了。与直接投放到生产系统相比，占用的资源显然会少很多。

我认为通过功能原型，他们可以看到数据移动，可以看到工作原理。有时，我们甚至可以演示给现在的客户看，以便他们发表意见，告诉我们“是的，我真的喜欢这个特性。添加这个特性怎么样？”然后，我们就可以在原有基础上构建并逐步移至生产系统中，从而不会破坏事务现状。这就是我们处理旧有系统的方式。

因此更多的是增量更改，而不是一次性完成大规模、爆发式修改。

是，我同意功能原型的想法，而不是爆发式，因为爆发式就从来没有成功过。你必须有一个爆发式的方法，一开始头脑中就有一个目标，然后战略性地接近目标。我要补充的另一件事是培训。例如，就拿新技术来说。当人们不熟悉某件事物时，总是害怕它。这是很自然的。

您所要做的东西，无论它是一项技术、方法，还是任何其他东西 — 我们作为企业架构师要做的还包括销售。我们推销自己。我们推销方法。我们推销技术。但有时我们需要培训人员，去教导人们某一特定的东西（SOA、大数据等等）为什么这么重要。

我们花一点时间培训做决策的人员。向他们展示他们所需要了解的东西。这样，对于功能原型的情况而言，他们可以真实地看到它起作用，而不是产生条件反射。他们可以理解它，而不只是对它进行一些毫无知识的猜测。

我们生活在 API 的时代，当我们创建功能原型时，可以立即打开许多 API，然后让合作伙伴来尝试。这样就可以见到他们的反馈。例如，他们可能会告诉您某项服务对他们不起作用，因为它不能直接装入他们已有的系统。

在原型级别对此进行更改将比后来尝试推动他们与您的产品集成容易的多。这样，后续的培训问题以及与其产品集成的问题要轻松得多，因为当您尚在开发过程中时，他们就有机会直接加入反馈。

这使我想起了开源场景中相当流行或常见的两句话。一句是：“你必须尽早发布、经常发布”。另一句是：“不要担心，麻烦就麻烦”。把东西快点推出去，不要花过多时间追求完美。有的是时间，只要确实发布了版本，就开动起来了。