专业架构师，第 2 部分: 克服数据体系结构中的专业挑战

转自IBM：http://www.ibm.com/developerworks/cn/webservices/ws-soa-proarch2/index.html

引言

数据体系结构是一门新兴专业，重点关注跨多个部门系统甚至整个企业内的静态（数据建模）和动态（数据流）信息。数据架构师是所有形式的数据的管理人，包括从关系数据库到平面文件和从文档和内容到报告和事务数据的各种数据。这与企业体系结构及信息体系结构有一些重叠；企业体系结构寻找通过信息技术优化总体业务流程的方法，而信息体系结构寻找将信息作为用户体验的一部分（通常在 Web 上）表示信息的最佳方式。近来，各个组织都已经认识到从全局的角度管理数据（而不受当前处理这些数据的系统的影响）的重要性，因此对数据架构师的重要性的认识也得以提高。尽管这样，数据架构师在很多情况下从事其职业时还面临着很多实际的困难。其中大部分困难都与跟上新出现的各种其他软件架构师原则相关，从事所有此类职业的人都需要了解这些内容。

变化是催化剂

信息技术（Information Technology，IT）始终在不断发生变化。在某个给定年份，管理层可能重点关注独立的 N 层应用程序的投资组合，而另一年则关注企业资源规划（Enterprise Resource Planning，ERP）项目，再一年又关注面向服务的体系结构（Service-Oriented Architecture，SOA）。开发人员和管理人员不时发生着变化，业务合并以及行业趋势也在不断变化。跟上这些变化始终是 IT 工作最难的部分，也是 IT 工作最具挑战的原因，包括失败的项目和成本超支。最近的活动侧重于强调通过此类更改来维护组织数据的价值。Web 技术（包括 XML 和 SOA 等新兴技术）的成功充当了促进管理层对数据体系结构重视的“胡萝卜”，而法律法规要求（如美国的 Sarbanes-Oxley 法案）则充当了“大棒”——审计人员和合规官员现在会定期向管理层发出警报，提示可能必须长时间保留和管理数据记录，可能超过处理这些记录的应用程序的有用生命周期。这样做一直是很好的业务操作方法，现在已经成了一种固定做法。

数据架构师在企业内的广泛角色越来越受到决策者的重视。不幸的是，他们经常发现其要求和职责提高了，但并没有获得预期的资源或权力，而这个奇怪的组合可能非常危险，不仅对于个人的职业生涯如此，对组织的总体目标也具有危险性。耐用的数据体系结构通常要求对应用程序和业务流程进行细微的修改，而其在组织表中的位置经常不能强制进行这些更改。过去，ERP 项目经常伴随着以业务流程再工程（Business Process Reengineering，BPR）形式进行的大量更改，这些更改由管理层强制要求进行。大部分数据架构师没有可依赖的此类行政权力，即使他们对组织的要求比 ERP 少得多。这是一个十分严酷的事实，专业人士别无选择，只能一步一步地促进此类更改，每次只能取得很小的成功。

障碍

几乎没有必要对数据架构师在推行企业数据模型期间面临的各种困难和障碍进行全面的罗列。在我与同事的讨论中，我发现此类困难和障碍几乎无处不在，而且对其都非常熟悉。不过对障碍进行估计将仍然有用，可帮助制定进行下一步工作的有效策略。

“仅仅是数据而已”

数据体系结构中的缺陷始终会在集成项目期间体现出来。系统集成很长时间以来都被视为功能的融合，而不是信息的融合。程序管理人员的工作重点是代码和设计模式，而不是共享数据模型。集成两个应用程序的项目通常不会得到在两个原始数据竖井 (Silo) 上操作的合并应用程序，如图 1 中所示。所得到的大部分合并应用程序框架都在这些竖井上进行请求代理。在特别编程的“过去岁月”中，决策者经常说“这仅仅是代码而已”而否决软件体系结构的想法。现在，代码从设计和计划方面获得了很大的帮助，则可能又会听到这样的说法“这仅仅是数据而已”。不过针对其中某些部分（如关系数据）进行了重点设计，这些均得益于专业人士坚持不懈地进行宣传和推广。通常不会对系统中的所有数据类型进行这些考虑。现在需要进行更多的支持和倡导来推广这种意识，但坚持对此不予重视或者（更常见一些）一开始就融入其他部分的架构师只会发现，在意外情况下对项目的目标、资源或计划造成限制时自己的优先级被搁置一旁。

图 1. 数据竖井不会总在集成项目中合并

有争议的认知

奇怪的是，伴随着“仅仅是数据而已”问题，您经常会发现对数据控制权的争议。重要的数据趋向于来自一个部门所开发的应用程序，但最终需要与其他人进行共享。目标为实现数据控制权共有化的集成项目经常会出现利益方面的边界争议。如果没有精心的设计，数据最终会锁定在一个部门的视角内，降低它在其他方面的价值，但要协商形成一个中立的设计很困难，有时候所存在的争议会破坏项目。

技术障碍

仅次于组织方面障碍的是似乎看起来并不存在的技术障碍，但对于任务、数据版本控制、并发性（锁定）和生命周期管理而言，这决不简单。定义和应用业务规则（应该对数据进行定型）仍然非常困难，并且也很难提供虚拟化技术来让数据用户访问此构型。由于认知不同（不同部门可能希望采取不同的锁定策略或声明周期规则），解决所有这些技术问题的难度更大，而且由于人们的普遍轻视（认为“这仅仅是数据而已”），可能难以找到所需的各种资源来应对挑战。

 

回页首

下一步

将眼睛仅仅放在障碍上，将永远达不到目的。数据架构师可以采取很多策略来进一步增强自己在企业的影响。

形成支持人群

建立数据体系结构的最简单做法是寻找朋友。所有专业人士交互都是以协商的方式进行，务必让主要决策者站在您的一边。这样做不仅能够获得支持，还能够提高受到其他管理人员重视的机会。有时候决策者存在从众心理，不愿意被看作负面影响的来源。您可以寻找有大量成功项目经验、在之前的工作甚至目前的职位涉及大量数据体系结构方面工作的管理人员。了解主要决策者的背景是在说明您所提供的价值时保持他们兴趣的关键。或许，您的支持者可以是其团队从项目获益最多的管理人员。有效的数据体系结构当然应该努力为整个组织带来好处，但经常可以更清楚地向关注某类问题的组表明您可以如何提高其工作效率。首先考虑此类团队并没有任何错误或存在任何欺骗。我所遇到的一个危险策略是考虑将供应商作为支持者。集成项目经常由考虑了供应商（有效集成所涉及的软件或服务）的管理人员负责进行。我们可能会禁不住尝试将数据体系结构针对供应商的计划进行调整，以提高性能，但此类调整很少真的有效。大部分软件和集成服务都是在考虑供应商的组织模型的情况下设计的，大部分都喜欢对您的组织施加一定的 BPR，而不会对其自己的工具进行调整来满足客户的独特需求。

构建桥梁

不同的部门可能具有不同的观点，但最终都希望找到一起协作的方法。帮助他们共享数据可在成本减少、成本避免方面带来实际的价值，而且在某些情况下甚至还能促进收益增长——例如，如果您的工作带来了之前未利用的针对客户的交叉销售和提升销售机会。鼓励治理委员会关注关键共享数据，并清楚地说明数据流如何推动流程，从而利用管理人员希望控制业务流程的意愿。这可能并不像您所想象的那么困难。通常，不愿意提供更多实际资源的相同管理人员会很愿意加入某个实践委员会。在这样的跨功能组内进行亲密沟通，可以让您感受到可通过组织确定数据体系结构。构建这样的桥梁通常与高层战略项目相关，其涉众来自多个部门。

迭代、迭代……重复

对于大多数架构师而言，企业级项目似乎都难以实现，但在执行这些项目的过程中最开始往往要更多地做一些微不足道的工作。如果在小型战略项目（例如，用于进行促销的电子商务网站）中发现了机会，则可以重点针对涉众需求，您要么侧重于说明从长远来看及时提供可用数据的重要性，要么侧重于说明简化数据流预期可以在多大程度上提高工作效率。在这种情况下有一两个支持者将非常有帮助。如果能够在项目计划中找到立足点，则可以在设计中融入前瞻思想。如果项目成功，请确保向涉众反馈，并重点突出您的设计的实际好处，甚至还应该说明以后与其他系统可能的集成而带来的好处。这样他们就可能成为您继续进行下一个项目的支持者。进行了一系列此类项目后，可能就获得了能满足多个部门需求的数据模型，然后就可以进行规模更大的工作了。您还可能获得采用多次迭代来处理一些技术困难的好处，从而能进一步将解决方案推广到更大的范围内。

 

回页首

总结

最近兴起的每个专业领域几乎都是由于面临本文中讨论的问题而出现的。数据架构师很容易在面对这样问题的时候感到受压制，但务必要将眼光放在积极的方面。组织正以前所未有的方式关注数据在整个企业中的角色，尽管最初有困难，但对这一领域的未来会带来种种好处。通过在管理层中寻找支持者、弥合部门间的差异并通过仔细选择的项目获得小成功来加分，专业数据架构师可以通过逐渐将其对企业承诺的好处变成现实来为以后打好基础。