通过Techopedia Staff，2016年11月16日
总结：主持人Eric Kavanagh与Robin Bloor，Dez Blanchfield和IDERA的Ron Huizenga讨论了数据建模在敏捷开发中的重要性。
您目前尚未登录。请登录或注册以观看视频。
埃里克·卡瓦那（Eric Kavanagh）：好的，女士们，先生们。 欢迎再次回来。 现在是美国东部时间星期三4:00。 这意味着该是热门技术的时候了。 确实是的。 我叫埃里克·卡瓦纳（Eric Kavanagh），我将成为您的主人。
对于今天的话题，这是一个老歌，但一个好东西。 每天都会变得越来越好，因为它正在塑造我们的数据管理世界，“敏捷环境中的数据建模”。确实有一张关于您的幻灯片，请在Twitter @eric_kavanagh上打我。 我们真的应该把它放在幻灯片上。 我得继续下去。
所以这一年很热。 数据建模一直存在。 它确实是信息管理业务的核心和灵魂，它设计数据模型，试图理解业务模型并使它们与您的数据模型保持一致。 那确实是您要尝试的方法，对吗？
数据模型从根本上代表业务，那么所有这些新数据源如何改变游戏规则？ 我们将对此进行查找。 我们将研究如何以敏捷的方式掌握一切。 当然，这就是当年的话。
Robin Bloor与我们在一起，我们的首席分析师Dez Blanchfield从澳大利亚悉尼来访，而IDERA的高级产品经理Ron Huizenga是我的长期朋友，在该领域的杰出演讲者，知道他的东西，所以不要害羞，问一下他是个难题，乡亲，都是难题。 这样，我将让Robin成为主持人，并将其拿走。
罗宾·布洛尔博士：好的。 好的，谢谢你，埃里克。 我不得不说关于建模的想法，我认为我实际上已经进入了IT领域，从某种意义上说，我记得在我工作过的一家保险公司中，有一个人进来给我们提供了一切关于如何对数据建模的研讨会。 因此，我们考虑的是30年，是30年吗？ 甚至比35年前更长。 长时间的建模实际上已经成为该行业的一部分，并且当然与走秀的女士们没有任何关系。
我想说的是我和Dez谈论的事情，因为我们通常会做的事情，而我只是认为我将对建模进行总体概述，但是这已经成为现实，这已经变得显而易见。
您知道，大数据的现实，我们有更多的数据，更多的数据源，在过去的三到四年中，我们已经拥有进入方程式的数据流，并且已经开始占有更大的份额，并且更加需要了解数据，并且随着新数据的增加和使用更多数据结构的变化率的提高。
这是一个艰难的世界。 这是一张照片，实际上是我们大约三年前绘制的，但是基本上，一旦您将流加入混合中，并且您有了数据精炼，数据中心，数据链接之类的概念，就会发现存在从某种意义上说，它并没有多大动静。 然后是数据，流，并且您已经拥有所有事务性应用程序，再加上如今，您已经拥有了事件，应用程序中可能发生的事件，事件数据流，并且如今，每个人都在谈论的lambda架构是真正的仅影响整个数据领域。
如今，我们考虑存在数据层。 数据层以一种虚拟方式存在，从某种意义上说，它的很大一部分可能位于云中，并且可以分布在数据中心之间，也可以存在于工作站上。 在某种程度上，数据层是无处不在的，从某种意义上说，无处不在的过程正在以一种或另一种方式尝试处理数据并移动数据。 但是，在移动时也要知道它是什么，这很重要。
如果我们从最一般的角度来看数据建模，那么在这种堆栈的底部，您将拥有文件和数据库。 您有数据元素，其中包含键，元素定义，别名，同义词，特定的物理格式，然后我们有了此元数据层。
关于元数据的有趣之处在于，元数据完全是数据如何获得其含义的方式。 如果您实际上没有元数据，那么充其量只能猜测数据的含义，但是您会遇到很多困难。 元数据需要存在，但意义具有结构。 我不想讨论意义哲学，但是即使在我们处理数据的方式中，人类思想和语言也有很多复杂之处，它们并不容易在数据中表达自己。 但是，即使就我们在世界上实际处理的数据而言，元数据也具有含义和元数据的结构–一条数据与另一条数据相关，什么时候将它们放在一起以及什么时候将它们放在一起意味着什么？重新结合其他数据，要求我们对其建模。 仅记录事物的元数据标签还不够好，实际上您必须记录每个结构的含义以及结构之间的关系。
然后，我们在顶层有业务定义，该层通常是试图在元数据之间传递含义的层，这是一种数据定义的形式，可以容纳在计算机上组织数据的方式和人为的含义。 因此，您拥有该层中存在的业务术语，定义，关系，实体级别的概念。 而且，如果我们要在这些层之间保持不连贯性，那么就必须进行数据建模。 这不是真正的可选。 就自动化而言，您实际上可以做得越多越好。 但是，因为它与含义有关，所以很难交替使用。 捕获记录中的元数据并能够从一系列含义中获取它很容易，但是它并不能告诉您记录的结构或记录的含义或记录的上下文。
因此，我认为这就是数据建模的目的。 注意事项：数据Universe越复杂，就需要对其建模的越多。 换句话说，这有点像我们在世界上不仅添加了更多实例，这些实例与数据记录相对应，而且实际上我们通过捕获越来越多的事物上的数据在世界上增加了意义。 它变得越来越复杂，我们必须要理解。
从理论上讲，存在一个数据世界，我们需要一个数据视图。 实际上，实际的元数据是数据世界的一部分。 因此，这不是一个简单的情况。 开始建模是自上而下和自下而上的。 您需要双向构建，其原因是数据对计算机和进程具有意义，必须对其进行处理，但是它本身具有意义。 因此，您需要一个自下而上的含义，它满足需要访问数据的软件的需求，并且需要自上而下的含义，以便人类可以理解。 元数据模型的构建不是，也永远不可能是一个项目。 这是一项持续的活动–应该在存在的每个环境中都是一项持续的活动。 幸运的是，有很多环境，实际上并非如此，事情因此而失控。
展望未来，随着技术的发展，建模变得越来越重要。 那是我的意见。 但是，如果您看一下IoT，尽管它引入了新的维度：移动设备位置的维度，但我们对移动设备的了解比以往更多。 一旦您接触到物联网，我们将研究以前从未真正要做的非凡数据问题，我们需要以一种或多种方式正确了解我们所拥有的东西，我们如何对其进行汇总，从聚合中获取意义方面我们可以做的事情，当然，在处理聚合后我们可以做什么。
我想这就是我所说的足够。 我将转达给Dez Blanchfield，他将完全说出其他话。
Dez Blanchfield：谢谢。 总是要遵循一个艰难的举动，但这是我们同意的话题，并且在演出前的戏ter中简短地谈到了这个话题，如果您提早拨打电话，您可能会发现一大堆很棒的宝石。 其中一种外卖食品，我不想窃取这一特殊产品的风头，但如果您没有抓住它，我想与我们分享的售前戏the中的一种食品只是关于以下主题：数据的旅程，这让我震惊，实际上是在考虑数据在一代生命周期（年，月，周，日，时，分，秒）中在不同上下文中所经历的旅程，并写下来，这让我很吃惊。定位在该上下文中。 我是运行代码的开发人员，还是数据专家，并且正在考虑每个元素的结构和格式以及元数据，或者系统和业务与之交互的方式。
仅需注意，这是一个有趣的小收获，但是无论如何，让我继续学习。尤其是数据设计，这是我用来谈论所有数据，尤其是应用程序或数据库基础结构开发的短语。 我认为数据设计这个词在我脑海中很好地抓住了所有这些。 如今，当我们谈论数据设计时，我们谈论的是现代敏捷数据设计，而我的观点是，不久前开发人员和数据专家就独自工作了。 他们处于自己的筒仓中，设计作品从一个筒仓转到另一个筒仓。 但是这些天，我的观点非常多，不仅是情况有所改变，而且还必须改变。 这是必要的，那就是应用程序–开发人员以及围绕数据处理的开发工作的一切，负责架构，字段和记录，位置以及数据库系统和基础架构，建模以及整个管理的相关设计元素的设计师挑战。 现在这是一项团队运动，因此我的照片是一群人从一架飞机上跳下来作为一个团队，播放着人们从天而降的视觉上有趣的图像。
第三，发生了什么事？ 好吧，有几位先生在1986年写的一篇文章，我拼命地试图称呼他们，我想这是我的名字，竹内广孝和野中郁次郎，他们发表了一篇名为“移动Scrum Downfield”的文章。这种从Scrum活动中赢得橄榄球比赛的方法论的想法是，每个人都聚集在一个地方，并且两个团队本质上将头锁定在一种称为Scrum的东西中，以尝试控制球并将其打到场上。到达尝试线并用球触地，得到一个点，称为三叉戟，然后重复此过程，您会为团队获得更多分。
这篇文章发表在1986年的《哈佛商业评论》上，奇怪的是，它实际上引起了很多关注。 由于它引入了令人惊叹的新概念，因此受到了很多关注，下面是其正面的屏幕截图。 因此，他们从游戏橄榄球中摆脱了混乱的概念，并将其引入业务，特别是在设计和项目交付（特别是项目交付）游戏中。
与我们之前在瀑布方法中使用的PRINCE2或PMBOK之类的东西相比，scrum的工作为我们提供了一种新的方法论，您知道，执行此操作，此操作，该操作并依次跟踪并连接周围的所有点，这取决于您拥有什么，或者在完成第一部分之前不要做第二部分，因为它取决于第一部分。 它给我们提供了一种新的方法，该方法更加灵活一些，这是术语的来历，它是关于我们如何交付事物的，尤其是围绕设计和开发基层项目交付。
一些关键租户（正如我继续介绍的那样）围绕scrum的关键租户。 它引入了建立不稳定的想法，即如果您考虑到对混沌的恐惧，那么实际上世界就处于混乱状态，但是行星已经形成，这很有趣，因此，建立不稳定，反弹的能力和仍然实际上使事情起作用，自组项目团队，通过非常负责任的开发来实现利益重叠，通过项目交付的过程，学习的组织转移来进行不同类型的学习和控制。 那么，我们如何从业务的一部分中获取信息，并将其从有想法但不开发代码或不开发数据库和基础结构，但将数据传输给那些人的人那里转移到另一部分？ 特别是有时间限制的结果。 换句话说，让我们做一段时间，或者一天24小时，或者一周或几周，然后看看我们能做什么，然后退后一步看看。
因此，如果您原谅这个双关语，那确实是项目交付中的一个新游戏，它的三个核心组成部分将变得有意义，因为我们在此进行得更深入–有一个产品：所有这些人都有想法并拥有需要完成某件事以及围绕它们的故事。 使用敏捷模型来获取故事的开发人员，并使用scrum方法通过日常演讲来讨论故事并了解他们需要做什么，然后继续进行下去。 然后，人们就听说了Scrum大师，他们对整个过程进行了监督，并充分理解了驱动它的方法。 我们都已经看到了这些图像，这些图像是我在右侧贴满墙壁和白板的便条纸的，它们被用作看板墙。 如果您不知道看板是谁，那么我邀请您参加Google，看板先生是谁，以及为什么这确实改变了我们将事物从一面移到另一面但实际上是在项目中的方式。
一目了然，Scrum工作流可以做到这一点：它收集了组织想要做的事情的清单，通过一系列我们称为“冲刺”的事情来运行它们，这些冲刺被分为24小时，一个月的时间，然后得到这个递增的输出系列。 这是对项目交付方式的一个重大变化，直到那个阶段才交付，因为其中的一部分就像美国军队一样，在很大程度上开发了称为PMBOK的东西，例如不把坦克带入实地的想法。直到您将子弹放进东西为止，因为如果野战中的坦克没有子弹，那就没用了。 因此，第一部分将子弹放入战车中，第二部分将子弹置于战场中。 但是，不幸的是，开发世界中的开发人员所发生的一切都以某种方式掌握了这种敏捷方法论，并且如果您对双关语宽恕，则冲刺了一下。
总是发生什么事情，当我们想到敏捷时，我们通常想到的是开发人员，而不是数据库，而与数据库世界有关。 这是一个不幸的结果，因为现实是敏捷不仅限于开发人员。 实际上，在我看来，敏捷一词通常错误地仅与软件开发人员相关联，而不是与数据库设计人员和架构师相关联。 在软件和应用程序开发中，与设计，开发，操作和维护以及数据基础结构（尤其是数据库）相关的所有事情始终面临着同样的挑战。 此特定数据类型中的参与者包括数据架构师，成型者，数据库基础结构的管理员，管理员以及实际的数据库本身，直至业务和系统分析师和架构师，他们坐下来思考系统的方式和业务运营，以及我们如何通过这些流程传输数据。
我经常提出这个话题，因为这是我一直以来的沮丧，因为我非常认为，数据专家现在必须（不应该）必须密切参与项目交付的每个组成部分，尤其是开发。 对于我们而言，那么，我们实际上并不是在为自己提供最佳结果的最佳机会。 我们经常不得不回头再考虑这些事情，因为存在一个场景，我们正在构建一个应用程序，而我们发现开发人员并不总是数据专家。 使用数据库需要非常专业的技能，尤其是围绕数据的技能，并需要积累经验。 您不会在一夜之间立即成为数据库专家或数据知识专家。 这通常是源于一生的经历，当然也包括《今日密码》中的罗宾·布洛尔博士（Robin Bloor）之类的人，他写得相当丰富。
在很多情况下（这很不幸，但这是现实），这个问题有两个部分，那就是软件开发人员对数据库专家没有什么了解，并且建立了数据库设计建模所需的技能，而模型开发仅仅是专家对数据如何进入以及如何进行旅程的组织以及它应该或不应该看起来的样子进行工程设计的基础，或者毫无疑问地，这种吸收和理解通常是为软件开发人员设置的本机技能。 我们面对的一些常见挑战（仅在上下文中）包括诸如核心数据库设计本身的基本创建，维护和管理，记录数据和数据库基础结构，然后重用这些数据资产，架构设计，模式生成，模式的管理和维护以及它们的使用，共享有关为何以特定方式设计此模式的知识，以及随着时间的推移所带来的优缺点会导致数据随时间，数据建模和类型而变化我们应用于系统的模型和流经它们的数据。 数据库代码生成及其继续集成，然后围绕它们建模数据，然后更快速地访问以控制数据周围的安全性，数据的完整性是我们在保持数据完整性的同时移动数据，周围是否有足够的元数据，销售人员应该查看表中的所有记录，还是只看到发送信息的地址，名字，姓氏？ 然后当然，最大的挑战是对数据库平台进行建模，这本身就是完全不同的对话。
我非常认为，考虑到所有这些因素，才能使这一切必不可少，因此至关重要的是，数据专家和开发人员都必须拥有适当的工具，并且这些工具能够以团队为中心进行项目交付，设计，开发和日常运营维护。 您知道，诸如数据专家和软件开发人员之间跨项目的协作，围绕数据库本身，数据，模式，记录来自何处，这些记录的所有者的所有事物的单一事实或单一事实来源之类的事情。 我认为，在当今时代，这绝对至关重要，我们将使数据成为必不可少的必杀技，必须使用正确的工具，因为现在挑战太大了，无法手动完成，如果有人如果要迁入或离开一个组织，对于我们而言，很容易不遵循一个人可能建立的相同流程或方法，而这并不一定会转移这些技能和能力。
考虑到这一点，我将直接前往IDERA的好朋友那里，了解该工具及其如何解决这些问题。
Ron Huizenga：非常感谢，感谢Robin和Dez确实做好了准备，在我刚才谈到的几件事中，您会发现有些重叠。 但是它们确实为我将要从数据建模角度讨论的一些概念奠定了非常坚实的基础。 当我是数据建模和数据架构顾问以及团队时，他们所说的许多事情都与我的经验相呼应–既是早期的瀑布，也随着我们在其中使用敏捷的项目而演变为更现代的产品提供解决方案的方法。
因此，我今天要谈论的是基于这些经验以及对工具的理解以及我们在此过程中可用来帮助我们的工具中的某些功能。 我要简要介绍的是，我不会详细讨论Scrum。 我们只是对它有一个非常好的概述。 我将在以下方面进行讨论：什么是数据模型？它对我们真正意味着什么？ 以及我们如何在组织中启用敏捷数据建模器的概念，例如，我们如何与数据建模器互动，在冲刺期间建模器和架构师的参与程度，他们应从事的活动类型是什么？ ，并以此为背景，我们真正用来帮助简化这项工作的一些重要建模工具功能是什么？ 然后，我将做一个总结，只谈谈参与数据建模师的一些商业价值和好处，或者我实际上要讲的故事是，关于没有使数据建模师完全参与项目的问题，我将基于多年前我参与的实际项目的经验和前后图像的缺陷图表向您展示。 然后，我们将总结其他几点，然后再提出一些问题和答案。
简而言之，ER Studio是一个非常强大的套件，其中包含许多不同的组件。 数据架构师，这是数据建模者和架构师花费大部分时间进行数据建模的地方。 还有一些其他组件我们今天将不再讨论，例如我们为某些UML建模进行业务建模的业务架构师和软件架构师。 然后是存储库，我们在其中签入并共享模型，我们允许团队在这些模型上进行协作并将其发布到团队服务器，以便参与项目的多个利益相关者受众可以实际看到我们从数据角度以及我们在项目交付本身中正在做的其他事情重新创建。
我今天要重点关注的是从Data Architect中看到的一些事情，因为与基于存储库的方面进行协作非常重要。 尤其是当我们开始谈论诸如变更管理之类的概念时，不仅对于敏捷开发项目，而且对于未来的任何类型的开发都是必不可少的。
因此，让我们先讨论一下敏捷数据建模器。 正如我们在本演讲的前面提到的那样，一定要让我们充分参与敏捷开发过程的数据建模人员和/或架构师。 现在，历史上发生的事情是，是的，我们已经从开发的角度真正考虑了敏捷性，并且发生了很多事情，实际上导致了这种情况的发生。 部分原因是开发本身展现出来的方式的本质。 随着敏捷开发的开始，我们开始采用自组织团队的概念，如果您喝了Kool-Aid有点过于纯净，而您却在极端编程方面，对诸如自组织团队，很多人都认为这意味着，我们需要的是一组可以构建完整解决方案的开发人员。 无论是开发代码，代码背后的数据库还是数据存储，一切都移交给了开发人员。 但是随之而来的是，您会失去人们所拥有的特殊能力。 我发现最强大的团队是由不同背景的人组成的团队。 例如，由强大的软件开发人员，数据架构师，数据建模人员，业务分析师和业务利益相关者共同组成，共同协作以开发出最终解决方案。
我今天也要谈论的是，我将在一个开发项目的背景下进行此操作，在该项目中，我们正在开发一个显然也要与之关联的数据组件的应用程序。 但是，在这样做之前，我们确实需要退后一步，因为我们需要意识到很少有Greenfield开发项目可以集中精力仅在该开发项目内部进行数据的创建和使用， 。 我们需要退后一步，从数据角度和流程角度来看整个组织的观点。 因为我们发现的是我们正在使用的信息可能已经存在于组织中的某处。 作为建模者和架构师，我们将其加以揭示，以便我们知道从何处从项目本身中获取信息。 我们也知道所涉及的数据结构，因为我们拥有设计模式，就像开发人员为其代码设计样式一样。 而且，我们还需要从整体组织角度出发。 我们不能只在正在构建的应用程序上下文中查看数据。 我们需要对数据进行建模，并确保我们将其记录下来，因为它的使用寿命远远超出了应用程序本身。 这些应用程序来来往往，但我们需要能够查看数据并确保其健壮和结构合理，不仅适用于应用程序，还适用于报告活动，BI报告以及与其他应用程序（内部和内部）集成的决策。在我们组织之外。 因此，我们需要查看数据的整个概况，以及数据的生命周期，并了解整个组织中从摇篮到坟墓的各种信息旅程。
现在回到实际的团队本身以及我们实际需要如何工作，瀑布方法被认为太慢而无法交付结果。 因为，正如油箱示例中指出的那样，这是一个接一个的步骤，并且通常花费太长时间才能提供可行的最终结果。 现在要做的是，需要有一种迭代的工作方式，在这种方式中，我们逐步开发它的组件，并随着时间的流逝逐步完善它，以便为每个冲刺生成可用的代码或可用的工件。 重要的是团队中的技术利益相关者和业务利益相关者之间的协作，因为我们正在协作，以将这些用户故事驱使成为可实现的代码愿景以及支持该代码的数据。 而且敏捷数据建模器本身经常会发现我们组织中没有足够的建模器，因此一个数据建模器或架构师可能同时支持多个团队。
而另一方面，即使我们确实有多个建模者，也需要确保我们拥有一个正在使用的工具集，该工具集允许同时进行多个项目的协作并共享这些项目数据工件以及检入和检出功能。 我将很快进行详细介绍，因为我们已经在上一节中进行了介绍。 敏捷的真正前提是，您要根据积压的情况，故事或需求进行处理。 在迭代中，我们作为一个团队进行协作。 通常，根据组织的不同，通常需要进行两周或一个月的冲刺。 以及每天的审查和站立会议，这样我们就消除了障碍，并确保我们在各个方面都向前迈进，而不会因为停顿而停滞不前。 在这些冲刺中，我们希望确保我们在每个冲刺的一部分中产生可用的交付物。
只是稍微不同了一点，将其进一步扩展，scrum是我将在这里更具体讨论的方法，而我们基本上只是通过其他一些方面来扩展了先前的图片。 通常有一个产品待办事项列表，然后有一个sprint待办事项列表。 因此，我们有一个整体待办事项列表，在每次sprint迭代开始时，我们都会简化说：“我们将如何构建此sprint？”这是在sprint计划会议中完成的。 然后，我们分解与之相关的任务，并在每天进行的那些为期1-4周的冲刺中执行这些日常任务。 在执行此操作时，我们正在通过燃尽图和燃尽图来跟踪进度，以基本跟踪尚待构建的内容与要构建的内容，以建立像我们的开发速度这样的东西，我们是否要使我们的安排所有这些类型的事情。 所有这些都是在sprint中不断进行详细说明的，而不是花几个月的时间才发现您将要提出的建议很短，您需要延长项目进度。 非常重要的是，作为整个团队的一部分，最后要进行sprint审查，并进行sprint回顾，因此在开始下一次迭代之前，您需要先审查自己所做的事情，并且正在寻找可以使用的方法。通过下一次改进。
就可交付成果而言，这基本上是一张幻灯片，总结了冲刺中发生的典型事件类型。 而且它是非常以开发为中心的，所以我们在这里看到的很多事情，例如功能设计和用例，进行设计代码测试，当我们在这里查看这些框时，我都不会进行介绍。无论从哪方面讲，它们都是面向开发的。 而隐藏在这里的事实是，我们还需要拥有与之并驾齐驱的数据可交付成果，以支持这项工作。 因此，每次查看待办事项，需求和用户故事之类的内容时，我们都需要查看我们要做的开发工作，需要做的分析工作，如何做的工作。数据设计或数据模型，诸如业务词汇表之类的东西如何处理，以便我们可以将业务含义与我们所生成的所有工件相关联？ 因为我们需要在每个冲刺中生成那些可用的交付物。
有人会说我们需要在每次冲刺结束时产生可用的代码。 不一定是这样，这是从最纯粹的开发角度来看的，但是在很多情况下-尤其是在开始时-我们可能会出现诸如sprint零之类的事情，我们只专注于站起来，做一些事情，例如制定测试策略地点。 在开始填写细节之前，先进行高级设计，然后再开始吸引其他受众，然后随着团队的不断前进，确保我们有一套清晰的入门故事或要求。 总是会有一点准备时间，因此很多时候我们会得到零冲刺甚至零零冲刺。 在我们全面交付解决方案之前，可能尚处于启动阶段。
让我们在这种情况下非常简短地讨论数据模型。 人们想到数据模型时，通常会认为数据模型是不同信息之间如何结合的图片，而这仅仅是冰山一角。 为了充分体现您真正想要进行数据建模的精神（无论是在敏捷开发还是其他方面），您需要认识到，如果正确完成，数据模型将成为数据在组织和企业中含义的完整规范。如何在后端数据库中部署它。 当我说数据库时，我不仅指我们可能正在使用的关系数据库，还指在我们喜欢大数据或NoSQL平台的当今体系结构中。 还有那些大数据存储，因为我们可能会在消费信息方面将许多不同的数据存储组合在一起，并将其引入我们的解决方案中，以及我们如何将这些信息持久化或保存到解决方案中。
在给定应用程序的上下文中，我们可能同时使用多个数据库或数据源。 非常重要的一点是我们希望能够有一个完整的规范，因此，这对冲刺组织的观点，物理构造在我们实际定义数据的方式，数据之间的关系方面的逻辑规范是一个逻辑规范。您的数据库，参照完整性约束，检查约束以及您通常考虑的所有那些验证部分。 描述性元数据非常重要。 您如何知道如何在应用程序中利用数据？ 除非您可以定义它并知道它的意思或它来自何处，以确保您在这些应用程序中使用了正确的数据-确保我们具有正确的命名约定，完整定义，这意味着不仅要使用完整的数据字典，表，但包含这些表的列，以及有关我们如何利用该表的详细部署说明，因为我们需要建立此知识库，因为即使完成此应用程序，此信息也将用于其他计划，因此我们需要确保我们已经为将来的实现提供了所有文档。
再次，我们深入探讨诸如数据类型，键，索引之类的内容，数据模型本身体现了许多正在发挥作用的业务规则。 这些关系不仅仅是不同表之间的约束； 它们通常可以帮助我们描述真正的业务规则是关于数据的行为方式以及如何将其作为一个紧密的单元一起工作。 当然，价值限制非常重要。 当然，现在，诸如数据治理之类的事情就是我们不断处理的事情，并且它正变得越来越普遍。 因此，从数据治理的角度来看，我们还需要研究一下，我们在这里定义什么？ 我们想要定义诸如安全分类之类的东西。 我们正在处理什么类型的数据？ 什么将被视为主数据管理？ 我们正在创建哪些交易商店？ 我们在这些应用中利用了哪些参考数据？ 我们需要确保在我们的模型中正确捕获了该信息。 还有数据质量方面的考虑，某些信息对组织而言比其他信息更重要。
我参与了一些项目，其中我们用新的业务流程替换了十几个旧系统，并设计了新的应用程序和数据存储来替换它们。 我们需要知道信息的来源。 对于最重要的信息，从业务角度来看，如果您查看我在此处获得的此特定数据模型幻灯片，您会发现这些特定实体中的底部方框只是一小部分，实际上已经能够捕获业务价值。 对于组织内这些不同结构的这些类型的事物而言，是高，中还是低。 而且我还捕获了诸如主数据类之类的东西，它们是否是主表，是否为引用，是否为事务性。 因此，我们可以在模型中扩展元数据，从而为我们提供数据本身以外的许多其他特征，这确实帮助我们开展了原始项目之外的其他计划，并将其推向前进。 现在一张幻灯片中有很多内容，我将相当快地浏览其余内容。
现在，我将快速讨论数据建模器在我们处理这些不同的sprint时会做什么。 首先，是sprint计划会议的正式参与者，我们在其中记录用户故事，致力于在该sprint中交付内容，并弄清楚如何组织和交付它。 作为数据建模者，我也正在做的事情是，我知道我将与不同的开发人员或不同的人在不同的领域工作。 因此，我们可以拥有的重要特征之一是，当我们在做数据模型时，我们可以将数据模型划分为不同的视图，无论您称其为主题领域还是子模型，这都是我们的术语。 因此，在构建模型时，我们还将以不同的子模型视角展示该模型，因此不同的受众只会看到与他们相关的内容，因此他们可以专注于他们正在开发和提出的内容。 因此，我可能会让某人在应用程序的调度部分上工作，我可能会让其他人在订单输入上工作，在此我们可以在单个sprint中完成所有这些工作，但是我可以通过这些子模型为他们提供观点适用于他们正在研究的领域。 然后，这些汇总到整个模型和子模型的整个结构中，以提供不同的观众所需的视图。
从数据建模角度来看，我们想要拥有的基本要素始终是我们可以回溯的基准，因为我们需要做的一件事是，无论是在冲刺结束时还是在冲刺结束时在几个sprint中，我们想知道我们从哪里开始，并且总是有一个基线来知道什么是给定的sprint中的增量或差异。 我们还需要确保可以快速周转。 如果您是以数据建模师的身份参加的，但以传统的看门人角色说“不，不，您不能那样做，我们必须首先完成所有这些工作”，当您真正需要时，您将被排除在团队之外积极参与所有这些敏捷开发团队。 这意味着在进行给定的冲刺时，有些事情会从马车上掉下来，您可以在以后的冲刺中将它们捡起。
例如，您可能专注于数据结构只是为了使开发顺利进行，例如我正在谈论的订单输入单。 在以后的冲刺中，您可能会回来并围绕已创建的某些工件填充数据，例如数据字典的一些文档。 您不会一次完成全部定义。 您将继续逐步处理可交付成果，因为当开发人员忙于构建应用程序和围绕这些数据存储的持久性时，有时您可以与业务分析师一起填写该信息。 您想要促进而不是成为瓶颈。 我们与开发人员合作的方式有很多。 对于某些事情，我们拥有设计模式，因此我们是一个完整的参与者，因此我们可能会有一个设计模式，可以说我们将其放入模型中，然后将其推送到开发人员的沙箱数据库中，然后他们可以开始使用它，并要求对此进行更改。
开发人员可能还在其他领域进行工作，他们正在从事某些工作，正在对某些事物进行原型设计，因此可以在自己的开发环境中进行尝试。 我们使用他们一直在使用的数据库，将其放入我们的建模工具中，与我们拥有的模型进行比较，然后解决并将更改推回给他们，以便他们可以重构其代码，从而遵循正确的数据结构我们需要的。 因为他们可能创建了我们在其他地方已经拥有的某些东西，所以我们确保它们使用正确的数据源。 我们只是一直迭代到冲刺，以便获得完整的数据可交付成果，完整的文档以及我们正在生成的所有这些数据结构的定义。
在良好交付方面，我参与的最成功的敏捷项目是我们的哲学，即对整个物理数据库规范的所有更改进行建模。 从本质上讲，数据模型将成为您正在使用的已部署数据库，用于我们正在创建的任何新事物，并且如果我们从其他外部数据库中使用数据，则该模型具有对其他数据存储的完整引用。 作为其一部分，我们将生成增量脚本，而不是每次都生成完整的脚本。 而且，我们正在利用我们的设计模式，使我们能够与正在使用的不同开发团队一起快速完成任务。
同样在sprint活动中，还是比较/合并的基准，所以让我们采用对每个更改建模的想法。 每次进行更改时，我们要做的就是对更改进行建模，并且非常重要的是，直到最近（实际上，直到我们重新引入）数据建模才缺少的是关联建模的能力任务和您的可交付成果，以及实际上导致这些更改发生的用户案例和任务。 我们希望能够像开发人员签入他们的代码一样，参考我们拥有的用户故事来签入模型更改，这样我们就知道为什么我们首先进行更改，这就是我们要做的事情。 当我们这样做时，我们将生成增量DDL脚本并将其发布，以便可以将其与其他开发交付品一起使用并检入我们的构建解决方案中。 同样，我们可能有一个模型或与多个团队合作。 正如我所说的，有些事情是由数据建模者发起的，其他事情是由开发人员发起的，我们在中间碰头，提出了总体最佳设计，并将其推向前进，并确保在我们的设计中正确进行了设计整体数据结构。 我们必须保持纪律，以确保我们在数据模型中拥有所有正确的构造，包括诸如空值和非空值，引用约束，基本上是检查约束之类的东西，以及我们通常会想到的所有这些东西。
现在让我们谈谈一些帮助我们完成此工作的工具的屏幕截图。 我认为重要的是拥有该协作存储库，因此我们作为数据建模者可以做的事情（这是后台数据模型的一部分）是在我们致力于确保能够仅处理我们需要能够更改的对象，进行修改，生成DDL脚本以用于我们在重新签入时所做的更改。因此，我们可以做的就是在ER Studio中，我们可以检出要处理的对象或对象组，而不必检出整个模型或子模型，我们可以仅检出我们感兴趣的那些东西。 在那之后，我们想要的是在结帐时或在结帐时–我们都做到这两种方式，因为不同的开发团队以不同的方式工作。 我们希望确保将其与驱动需求的用户故事或任务相关联，并且与开发人员将在其中开发和检查其代码的用户故事或任务相同。
因此，这是我们变更管理中心之一的几个屏幕的非常简短的片段。 这样做是什么，我在这里不做详细介绍，但是您看到的是用户故事或任务，并缩进了每个您看到的实际变更记录的下方–我们在创建自动变更记录时我们进行签入和签出，我们也可以在该更改记录上添加更多描述。 它与任务相关，我们可以像您期望的那样对每个任务进行多项更改。 当我们进入该更改记录时，我们可以查看它，更重要的是，我们实际更改了什么？ 对于这个特殊的问题，我在其中突出显示了一个更改类型，当我查看实际更改记录本身时，它已确定了模型中已更改的各个部分。 我在这里更改了几个属性，对其进行了重新排序，并带来了需要更改的视图，这些视图也依赖于这些视图，因此它们将在增量DLL中生成。 它不仅在基础对象上建模，而且像这样的高性能建模工具也可以检测必须通过数据库或数据模型中的从属对象波动的更改。
如果我们正在与开发人员一起工作，并且我们在几项不同的操作中进行了此操作，那就是在他们的沙箱中进行操作，并且我们想比较并查看差异在哪里，我们将在右侧和左侧的位置使用比较/合并功能侧。 我们可以说：“这是我们的模型在左侧，这是他们的数据库在右侧，向我展示这些差异。”然后，我们可以选择如何解决这些差异，无论是将内容推送到数据库中还是他们在数据库中拥有的一些东西我们带回到模型中。 我们可以双向进行，以便我们可以同时双向更新源和目标，然后生成增量DDL脚本以将这些更改部署到数据库环境本身，这非常重要。 我们还可以做的是，我们还可以在任何给定时间使用此比较和合并功能，如果我们正在拍摄快照，我们总是可以将一个sprint的开始与另一个sprint的开始或结束进行比较，这样我们就可以看到在给定的开发冲刺或一系列冲刺中完成的操作的完整增量更改。
这是一个变更脚本的非常快速的示例，任何使用数据库的人都会看到这种类型的东西，这就是我们可以将代码作为变更脚本推出的原因，以便我们确保保留这里的东西。 为了减少混乱，我从这里撤出的是我们也对这些alter脚本进行了处理，因为我们假设这些表中也有数据，因此我们还将生成DML，该DML将提取临时表的信息并也将其推回到新的数据结构中，因此我们不仅在研究结构，而且也在研究那些结构中可能已经包含的数据。
快速讨论自动化构建系统，因为当我们经常进行敏捷项目时，我们正在使用自动化构建系统，在该系统中，我们需要一起检查不同的交付项以确保我们不会破坏我们的构建。 这意味着我们要同步交付的内容，我签入的与DDL脚本有关的更改脚本需要签入，相应的应用程序代码需要同时签入，而现在许多开发人员的开发当然不是通过针对数据库和此类事物的直接SQL完成。 我们经常使用持久性框架或构建数据服务。 我们需要确保对这些框架或服务所做的更改完全同时签入。 他们进入某些组织的自动化构建系统，如果构建中断，那么在敏捷方法中，我们必须先动手进行甲板修复，然后才能继续前进，以便在进一步之前知道我们有一个可行的解决方案。 在我参与的一个项目中，我们将其推向了极致–如果构建中断了，我们实际上已连接到我们与业务用户位于同一地点的多台计算机，那么我们的红色指示灯就会闪烁像警车的顶部 如果构建失败，那些红色闪烁的灯会开始熄灭，我们知道一切都在甲板上：修复构建，然后继续进行操作。
我想谈谈其他事情，这是ER Studio的一项独特功能，当我们尝试为这些持久性边界的开发人员构建这些工件时，它确实有帮助，我们有一个称为业务数据对象的概念，它使我们能够如果您以这个非常简单的数据模型为例，则可以使我们封装持久性边界所在的实体或实体组。 作为数据建模者，我们可能会想到诸如采购订单标题，订单对齐以及其他详细表之类的东西，这些东西会以我们构建数据的方式与之相关联，因此我们的数据服务开发人员需要了解事物如何持久保存在这些不同的数据上结构。 我们的开发人员正在考虑将采购订单作为整体对象，以及与他们如何创建这些特定对象的合同是什么。 我们可以公开该技术细节，以便构建数据服务器的人员可以看到其下面的内容，并且可以使其他受众免受复杂性的影响，从而使他们只能看到不同的更高级别的对象，这也非常适合与企业进行通信分析师和业务利益相关者在谈论不同业务概念之间的相互作用时也是如此。
这样做的好处还在于，我们可以有建设性地扩展和折叠这些对象，以便我们可以维护高阶对象之间的关系，即使它们起源于业务数据对象本身所包含的结构。 现在，作为建模者，进入sprint的结尾，在sprint结束时，我需要做很多事情，我称之为下一次sprint的内部管理。 我创建的每个冲刺都称为“命名发行版”，这为我提供了发行版结束时的基准。 因此，这就是我的基准，所有这些基准或我创建并保存在存储库中的命名发行版都可以用来进行比较/合并，这样我就可以始终将其与其他任何sprint的sprint的给定结尾进行比较。了解整个数据模型在整个过程中所做的更改非常重要。
我还从冲刺的开始到结束再次使用比较/合并来创建增量DDL脚本。 我可能已经签入了一堆增量脚本，但是如果需要，我现在有一个可以部署以站立其他沙箱的脚本，因此我只能说这是一次冲刺开始时的情况，请推送通过它，建立一个数据库作为沙箱，以开始下一个冲刺，我们还可以使用这些东西来执行独立的QA实例之类的事情，最终我们当然希望将更改推到生产中，因此我们有很多事情要做同时。 再一次，我们完全参与了sprint的计划和回顾，回顾确实是汲取的教训，这非常重要，因为像现在这样，您可以在敏捷过程中快速前进，您需要停下来并庆祝成功。 找出问题所在，在下一次改进它的同时，还要庆祝正确的事情并在接下来的冲刺中继续前进，并以此为基础。
我现在要非常快速地谈论业务价值。 很多年前，我参与了一个项目，起初是一个敏捷项目，这是一个极端的项目，所以这是一个纯粹的自组织团队，只有开发人员在做所有事情。 长话短说，该项目一直停滞不前，他们发现他们花在修复和修复已发现的缺陷上的时间越来越多，而不是在推出更多功能上，实际上，当他们基于在燃尽图上，他们将不得不将该项目延长六个月，而费用却很高。 当我们研究它时，解决问题的方法是利用一个适当的数据建模工具，并由一个熟练的数据建模人员来参与项目本身。
如果您查看此特定图表上的垂直条，它显示的是累积缺陷与累积对象，而我正在谈论的是创建的数据对象或构造，例如带有约束条件的表和那些类型的东西（如果您查看）在引入数据建模器之前，缺陷的数量实际上已经超过了，并开始在该时间点之前所产生的实际对象数量上形成一定的差距。 在第21周之后，即数据建模人员进入时，根据要解决的问题对数据模型进行了重构，然后作为项目团队的一部分开始进行建模，随着该项目的进行而进行的更改。 而且您看到了一个非常快速的转变，在大约一个半小时内，我们看到正在生成和构造的对象和数据构造的数量急剧增加，因为我们是使用数据建模工具而不是开发人员的手来生成的在环境中构建它们，它们是正确的，因为它们具有适当的参照完整性和它应该具有的其他构造。 缺陷水平抵制那些几乎平坦的缺陷。 通过采取适当的措施并确保完全进行数据建模，该项目可以按时交付，并且质量更高，实际上，如果不采取这些步骤，该项目将根本无法交付。 如果您要让合适的人担任正确的角色，那么就有很多敏捷失败，还有很多敏捷成功。 我非常支持将敏捷作为一种运筹学学科，但是当您继续进行敏捷类型的努力时，您需要确保您拥有项目团队所涉及的所有合适团队的技能。
总而言之，数据架构师和建模人员必须参与所有开发项目。 它们确实是将所有内容结合在一起的粘合剂，因为作为数据建模者和架构师，我们不仅了解给定开发项目的数据结构，而且还了解组织中数据的位置以及我们从何处获取数据以及如何获取数据将在我们正在研究的特定应用程序本身之外使用和利用。 我们了解复杂的数据关系，能够继续前进以及从治理的角度映射文档并了解完整的数据格局是至关重要的。
就像制造业； 我来自制造业。 您无法在最后检查质量–您需要在设计的前期和整个过程中将质量构建到内部，而数据建模是一种始终以高效且经济高效的方式将质量构建到设计中的方法。 再说一遍，要记住的事情-这不是陈词滥调，而是事实-应用程序来来往往，数据是至关重要的公司资产，它超越了所有这些应用程序边界。 每次您放入一个应用程序时，可能都会要求您将数据保留在以前的其他应用程序之外，因此我们只需要记住它是我们不断维护的重要企业资产。
就是这样！ 从这里我们将提出更多问题。
埃里克·卡瓦纳（Eric Kavanagh）：好，我先把它交给罗宾。 然后，Dez，我确定您有几个问题。 把它拿走，罗宾。
罗宾·布洛尔博士：好的。 老实说，敏捷开发方法从未遇到过任何问题，在我看来，您在这里所做的事情非常有意义。 我记得我看过1980年代的某些事情，这实际上表明，实际上，如果您让错误持续到某个特定阶段之外，那么您实际上遇到的问题就是项目失控。 如果您无法正确完成该阶段，修复起来将变得越来越困难，所以您在这里要做的一件事-我认为这是幻灯片-但您在这里要做的一件事在我看来，零冲刺绝对重要，因为您实际上是在努力将可交付成果固定在那里。 而且，如果您没有固定交付物，那么交付物就会改变形状。
那是我的看法。 这也是我的观点–我真的没有任何异议，认为您必须先进行一定程度的详细数据建模，然后再进行操作。 我想让您尝试做的是因为我没有完全了解它，只是根据项目的规模，流程如何，谁，您知道，在哪里出现问题，解决了吗？ 因为我认为这张幻灯片几乎是它的核心，如果您能对此进行详细说明，我将不胜感激。
Ron Huizenga：好的，我将使用几个示例项目。 实际上，这是通过让合适的人员参与并进行数据建模而脱离的，这实际上是确保更好地理解设计并且我们显然具有更好的实现设计的一种方式。通过建模的方式。 因为当您对其进行建模时，您知道可以从工具的后部和外部生成DDL以及所有内容，而不必像人们通常直接进入数据库环境那样坚持进行构建。 开发人员会发生的典型事情是，他们会去那里，他们会说，好吧，我需要这些表。 假设我们正在做订单输入。 因此，他们可以创建订单标题和订单明细表以及这些类型的东西。 但是他们经常会忘记或忽略以确保约束表示外键关系。 他们可能没有正确的密钥。 命名约定也可能会令人怀疑。 我不知道我进入一个环境的次数，例如，您看到一堆名称不同的不同表，但是这些表中的列名就像ID，Name或其他，所以它们如果没有确切的表，那确实失去了上下文。
因此，通常在进行数据建模时，我们将确保对所有在DDL中生成的构件都应用正确的命名约定。 但是，总体而言，要具体说明项目本身的性质，我是在谈论相当大的计划。 其中一个是1.5亿美元的业务转型项目，其中我们更换了十几个旧系统。 我们有五个不同的敏捷团队同时进行。 我有一个完整的数据体系结构团队，因此我的团队中的数据建模人员已嵌入到其他每个应用程序领域团队中，并且我们与一群了解主题的内部业务专家一起工作，需求本身的用户案例。 我们在每个团队中都有业务分析师，他们实际上是在对业务流程进行建模，包括活动图或业务流程图，以帮助他们在与其他用户充实之前，进一步丰富用户的故事。
然后，当然，在此之上构建应用程序代码的开发人员。 而且我们还与之合作，我认为是由四个不同的系统集成供应商在构建应用程序的不同部分，一个团队正在构建数据服务，另一个团队在一个领域中构建应用程序逻辑，而另一个则具有专业知识。在另一个业务领域中，正在该领域中构建应用程序逻辑。 因此，我们与从事此项目的人员进行了全面的协作。 尤其是其中一个，我们在团队中有150人在岸上，团队中还有150个在岸上的资源正在协作进行为期两周的冲刺，以将其淘汰。 为此，您需要确保在所有汽缸上射击，并且每个人在其可交付成果方面都保持了良好的同步，并且您进行了频繁的重置以确保我们完成了所有必要工件的交付在每次冲刺结束时。
Robin Bloor博士：令人印象深刻。 关于这点的更多细节–在该项目结束时，您是否最终得到了整个数据区域的完整MDM映射，我称之为？
Ron Huizenga：我们拥有一个完整的数据模型，该模型被所有不同业务领域之间的分解分解。 就完整定义而言，数据字典本身有点不足。 我们定义了大多数表； 我们已经对大多数列进行了定义，以确切说明其含义。 有一些不存在，有趣的是，其中许多是来自旧系统的信息，在项目范围本身结束之后，这些信息仍被记录为一组项目本身之外的工件，因为这是组织今后需要维持的东西。 因此，与此同时，组织对数据治理的重要性有了更多的看法，因为我们看到了那些遗留系统和我们试图利用的遗留数据源中的许多缺陷，因为它们没有文献记载。 在许多情况下，我们只有需要逆向工程的数据库，并试图找出其中的内容以及信息的用途。
Robin Bloor博士：它的特定方面并不令我感到惊讶。 数据治理是一个非常现代的问题，我认为，实际上，有许多工作应该在历史上就数据治理进行。 从来没有因为您可以不这样做而逃脱。 但是随着数据资源的不断增长，最终您无法做到。
无论如何，我会转到Dez，因为我认为我已经分配了时间。 德兹？
Dez Blanchfield：好的，谢谢。 通过这整个过程，我正在观察并思考自己，我们正在谈论看到敏捷在许多方面用于愤怒。 尽管有负面的含义； 我的意思是积极的。 您能否给我们一个场景，我的意思是，我可以在两个地方看到这是一个完美的场景：一个是新项目，只需要从第一天开始就可以完成，但是根据我的经验，我总是认为，通常当项目变得足够大而在很多方面都需要这样做时，将两个世界粘合在一起是一个有趣的挑战，对吗？ 您能为我们提供一些成功故事的见解吗，您已经在组织中找到了成功的故事，很明显，他们已经在两个领域产生了些许冲突，并且您已经能够成功地提出这样就可以将大型项目放在一起，否则它们可能会走上正轨？ 我知道这是一个非常广泛的问题，但是我只是想知道是否有一个特定的案例研究可以指向您所说的地方，您知道，我们将所有这些都放在了适当的位置，因此所有开发团队都与数据团队，而我们已经解决了一些本来可以沉没的事情？
Ron Huizenga：可以肯定的是，事实上，一个项目恰好是一个管道项目，这是我提到的，在涉及数据建模人员之前和之后，我在该图表上显示了有缺陷的地方。 通常，并且有一些先入为主的概念，特别是如果从纯粹的开发角度来看事情是从哪里完成的，那么只有开发人员才能参与这些敏捷项目来交付应用程序。 因此，在那里发生的事情当然是，他们确实脱离了轨道，尤其是他们的数据工件，或者他们正在生成的数据可交付成果，在质量和真正解决整体问题上都没有达到标准。 经常会有这样的误解，即数据建模人员会减慢项目速度，并且如果数据建模人员的态度不正确，他们也会这样做。 就像我说的那样，您一定会迷失-有时有些数据建模人员会表现出传统的网守态度，即“我们在这里控制数据结构的样子”，而这种思维方式必须消失。 任何参与敏捷开发的人，尤其是数据建模人员，都必须扮演促进者的角色，以真正帮助团队前进。 最好的说明方法是通过首先对变更进行建模来快速向团队展示他们的生产力。 再次，这就是为什么我谈论合作。
我们可以先建模一些东西，然后生成DDL推送给开发人员。 我们还想确保他们不会觉得自己受到限制。 因此，如果有正在处理的事情，请让他们继续在开发沙箱中工作，因为这是开发人员在自己的台式机或其他数据库上进行工作以在进行测试的地方进行一些更改的地方。 然后与他们合作，说：“好吧，一起使用。”我们将其引入工具中，我们将对其进行解决，然后将其推向前进，并为您提供可以部署它以更新您的脚本的脚本。数据库，以将它们升级到随着我们继续前进而受到实际认可的真实生产视图。 您可以快速地解决这个问题。 我发现自己的日子很充裕，我只是在来回地与不同的开发团队进行迭代，查看更改，比较，生成脚本，使它们运行，而一旦我们完成，我就能轻松地与四个开发团队保持联系取得了动力。
Dez Blanchfield：我想到的一件事是，我每天进行的很多对话都是关于这辆货运火车从我们那儿来的， -机器和物联网。 而且，如果我们认为我们目前在企业中的当前环境中已经拥有大量数据，那么您知道，如果我们暂时将独角兽放在一边的时候，我们知道Google，Facebook和Uber拥有PB级的数据，但是在传统企业中，我们谈论的仍然是数百TB和大量数据。 但是，在我看来，这辆货运列车正传给各组织，而Robin Bloor博士早些时候提到了物联网。 您知道，我们有大量的网络流量，社交流量，现在有了移动性和移动设备，云已经爆炸了，但是现在我们有了智能基础设施，智能城市而且整个数据世界都爆炸了。
对于一个日常组织来说，一个中型到大型组织坐在那里，看到这个痛苦的世界临到他们而又没有立即制定的计划，您只想用几句话就可以总结出一些收获？向他们询问何时何地需要开始对话，以考虑将其中一些方法论应用到位。 他们需要多早开始计划几乎坐起来并注意，并说这是适当的时间来准备一些工具并训练团队并进行有关vocab的对话以应对这一挑战？ 故事中有多晚为时已晚或何时为时过早？ 您看到的某些组织的情况如何？
Ron Huizenga：对于大多数组织，我想说的是，如果他们还没有这样做，并使用像这样的强大工具调整数据建模和数据体系结构，那么他们要做的时间就是昨天。 因为有趣的是，即使在今天，当您查看组织中的数据时，我们组织中的数据也很多，通常来说，根据我们已经看到的一些调查，我们有效使用的数据还不到百分之五当我们跨组织查看时。 借助IoT甚至NoSQL，大数据-即使不仅仅是IoT，也只是一般的大数据-我们现在开始吸收来自组织外部的更多信息，这一挑战越来越大每时每刻。 我们有机会解决这一问题的唯一方法就是帮助我们了解数据的含义。
因此，用例有些不同。 我们发现自己正在做的是，当我们查看这些数据时，我们正在捕获它们，我们需要对其进行逆向工程，查看其中的内容，无论是在我们的数据湖中，还是在我们的内部数据库中，综合得出数据是，对其应用含义和定义，以便我们可以了解数据是什么。 因为直到我们了解它是什么，我们才能确保我们正确或适当地使用它。 因此，我们确实需要了解这些数据是什么。 另外，不要这样做，因为就消耗所有这些外部数据而言，您可以确保您有一个支持使用此外部数据的用例。 专注于您需要的东西，而不仅仅是尝试拉动和利用以后可能需要的东西。 首先专注于重要的事情，然后逐步进行学习，然后您将开始使用并尝试从外部理解其他信息。
一个完美的例子是，我知道我们在谈论物联网和传感器，但是许多组织中甚至在物联网出现之前，实际上许多类型的组织就一直存在相同类型的问题。 任何拥有生产控制系统的人，无论他们是管道公司，制造公司，还是任何基于流程的公司，只要他们使用控件执行大量的自动化操作，并且正在使用数据流之类的东西，他们试图消耗掉的这些数据，弄清楚了我的生产设备中发生了什么事件以发出信号-发生了什么事情以及何时发生？ 在庞大的数据流中，只有他们感兴趣的特定信息或标签，它们需要筛选，综合，建模和理解。 并且，他们可以忽略其余部分，直到真正了解它为止，然后，他们可以扩展范围，将越来越多的范围引入范围，如果这是有道理的。
Dez Blanchfield：的确如此。 我要引出一个问题，这个问题来自一个叫埃里克的绅士，我们一直在私下讨论。 我只是问过他的允许，请他同意。 因为它很好地引导了这一点，所以请总结一下，因为我们现在要花点时间，我将转交给Eric。 但是另一个埃里克（Eric）的问题是，假设一家初创企业的所有者熟悉并理解围绕建模术语的独特挑战是合理的，还是应该交给其他人进行解释？ 那么，换句话说，一家初创企业是否应该有能力，准备好并愿意并且有能力专注于并实现这一目标？ 还是他们应该购物并邀请专家参加的事情？
罗恩·休曾加（Ron Huizenga）：我想简短的答案确实取决于情况。 如果这是一家没有真正了解数据库的数据架构师或内部建模人员的初创公司，那么最快的启动方法就是让具有咨询背景的人对此领域非常了解，并且可以他们去。 因为您会发现-实际上，我在进入产品管理的黑暗面之前所做的很多工作都是这样做的-我将以顾问的身份进入组织，带领他们的数据架构团队，这样，他们就可以重新定位自己并培训他们的员工如何做这些事情，以便他们维持下去并继续执行任务。 然后，如果可以的话，我将继续下一个约会。 有很多人这样做，他们拥有很好的数据体验，可以使他们前进。
Dez Blanchfield：这是一个很重要的要点，我完全同意这一点，并且我相信Robin Bloor博士也会。 尤其是在初创企业中，您将专注于作为中小型企业，因为它希望将其作为初创企业本身的一部分来构建，并希望自己成为企业的一部分，因此您可能不需要成为所有方面的专家，那么好的建议。 但非常感谢您，精彩的演讲。 真的很棒的答案和问题。 埃里克（Eric），我将退回给您，因为我知道我们可能已经过去了十分钟，而且我知道您希望紧贴我们的时间范围。
埃里克·卡瓦纳（Eric Kavanagh）：可以。 我们至少有几个很好的问题。 让我丢给你。 我认为您已经回答了其他一些问题。 但是，来自一位与会人员写的一个非常有趣的观察结果和问题是，有时敏捷项目的数据建模人员没有完整的长期情况，因此他们最终在冲刺中设计了东西，然后不得不在冲刺三或四中重新设计。 这看起来适得其反吗？ 您如何避免这种事情？
Ron Huizenga：敏捷的本质就是您不会在给定的sprint中获得绝对正确的一切。 这实际上是敏捷精神的一部分，它是：与之合作–您将在要在给定sprint中处理代码的地方进行原型设计，并对它进行改进。 这个过程的一部分是当您交付最终用户看到的内容时说：“是的，这很接近，但是我确实还需要做一些额外的工作。”因此，这不仅会影响功能设计代码本身，但通常我们需要在这些特定事物下修改或添加更多数据结构，以交付用户所需的内容。 那就是所有公平的游戏，这就是为什么您确实要使用高性能的工具，因为您可以非常快速地建模并在建模工具中进行更改，然后为数据库生成DDL，开发人员可以使用该DDL进行交付变化更快。 您将不必再对数据结构进行手工编码，而使他们专注于他们最精通的编程或应用程序逻辑。
埃里克·卡瓦纳（Eric Kavanagh）：完全有道理。 我们还有其他几个人只是问一些具体问题，这些问题如何与工具紧密联系在一起。 我知道您花了一些时间来浏览示例，并且已经展示了一些有关如何实际推广其中一些内容的屏幕截图。 在整个冲刺过程中，您在组织中经常看到这种情况，而在正常情况下，事物在其中徘徊并花费更多时间的传统过程却有多少？ 从您的角度来看，Sprint风格的方法有多普遍？
罗恩·休曾加（Ron Huizenga）：我认为我们正在越来越多地看到它。 我想说，大概在过去的15年中，我已经看到越来越多的人意识到他们确实需要更快地交付产品。 因此，我已经看到越来越多的组织跳上敏捷的潮流。 不一定全部； 他们可能从几个试点项目开始，以证明它是可行的，但是有些项目仍然非常传统，并且坚持使用瀑布法。 现在，好消息是，这些工具当然在这些组织中也可以很好地用于这些类型的方法论，但是我们拥有该工具的适应性，因此，那些愿意加入的人可以在工具箱中找到这些工具。他们的指尖。 诸如比较和合并之类的东西，诸如反向工程能力之类的事物，因此他们可以看到现有的数据源是什么，因此它们可以真正地进行比较并非常快速地生成增量DDL脚本。 当他们开始拥抱敏捷并看到他们可以提高工作效率时，他们拥抱敏捷的意愿会进一步提高。
埃里克·卡瓦纳（Eric Kavanagh）：好吧，伙计们。 我刚刚在聊天窗口中发布了幻灯片的链接，因此请检查一下； 这对您来说有点麻烦。 我们确实提供了所有这些网络广播，以供以后查看。 随时与您的朋友和同事分享。 罗恩（Ron），非常感谢您今天的宝贵时间，您一直很高兴能参加此次演出-一位真正的业内专家，很显然您知道您的知识。 因此，感谢您和IDERA，当然还要感谢Dez和我们自己的Robin Bloor。
伙计们，我们借此向您告别。 再次感谢您的时间和关注。 感谢您坚持75分钟，这是一个很好的信号。 好的节目主持人，下次我们会与您联系。 再见。
