アジャイル環境でのデータモデリング

取り除く： ホストのエリック・カバナが、アジャイル開発におけるデータモデリングの重要性について、Robin Bloor、Dez Blanchfield、およびIDERAのRon Huizengaとともに説明します。

あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。

エリック・カバナ： さて、ご列席の皆様。おかえりなさい。水曜日の東部標準時で4時。それは、Hot Technologiesの時代を意味します。はい、確かに。私の名前はエリック・カバナです。あなたのホストになります。

今日のトピックでは、それは昔ながらの良いものです。「アジャイル環境でのデータモデリング」というデータ管理の世界を形作っているため、毎日良くなっています。本当にあなたのスライドがあります。@ eric_kavanaghで私を見つけてください。本当にそのスライドに載せるべきです。それに乗らなければなりません。

だから暑い年。データモデリングは永遠に続いています。本当に情報管理ビジネスの中心であり、データモデルを設計し、ビジネスモデルを理解し、データモデルに合わせようとしています。それは本当にあなたがしようとしていることですよね？

データモデルはビジネスを基本的な方法で表しますが、これらの新しいデータソースはすべてゲームをどのように変えていますか？それについて調べるつもりでした。アジャイルな方法で物事を把握する方法を見つけるつもりでした。そしてもちろん、それは今年のことばです。

ロビンブロアーズ、チーフアナリスト、デズブランフィールドがオーストラリアのシドニーから電話をかけ、ロンフィゼンガはIDERAのシニアプロダクトマネージャーを呼んでいます。長年の友人であり、この分野で優れたスピーカーである彼は、難しい質問、人々、難しい質問。それで、Robinをプレゼンターにして、取り上げます。

ロビン・ブロア博士： はい。エリック、ありがとうございます。モデリングについては言わなければならない、私は実際にそれが存在する前にITの世界にいた、私が働いていた保険会社で覚えているという意味で、私たちは男を入れて私たちにあらゆる種類を与えたデータのモデル化方法に関するワークショップの。約30年を見ていましたが、30年ですか？それよりもさらに長いかもしれません。35年前かもしれません。長い、長い時間のモデリングは実際には業界の一部であり、もちろんキャットウォークの女性とは何の関係もありません。

私が言いたいのは、私たちが普段やっていることは私とデズが異なることについて話しているからであり、Idがモデリングの一般的な概要を説明すると思ったのですが、これには現実があります。

ビッグデータの現実があります。より多くのデータ、より多くのデータソースがあり、過去3〜4年で方程式に入力されたデータストリームがあり、その大部分を占め始めています。データを理解する必要性の高まりと、追加されるデータが増え、使用されるデータ構造が増えるという変化率の増加。

難しい世界です。ここにその写真があります。これは実際に約3年前に描いたものですが、基本的には、ミックスにストリーミングを含めて、データ精製、データハブ、データリンクなどのアイデアを得ると、データがあることがわかります。あまり動かないという意味で、本当に安静にしています。そして、データ、ストリーム、およびトランザクションアプリケーションのすべてを取得し、さらに今日ではイベント、アプリケーションで発生し、必要なイベントデータフローを取得し、今日では誰もが話しているラムダアーキテクチャによって、本当に影響を与えていますデータの全フィールドのみ。

そして今日では、データ層があるという点で考えています。データ層は一種の仮想的な方法で存在し、その一部はクラウド内に存在し、データセンター全体に広がり、ワークステーション上に存在できるという意味です。データ層は、ある程度、どこにでもあり、その意味で、データを処理してデータを移動しようと何らかの方法で試みているプロセスがどこにでもあります。しかし、移動するときにそれが何であるかを知ることも大事です。

最も一般的な意味でデータモデリングを見ると、この種のスタックの下部にファイルとデータベースがあります。キー、要素定義、エイリアス、同義語、特定の物理フォーマットを持つデータ要素があり、このメタデータレイヤーがあります。

メタデータの興味深い点は、メタデータはデータがその意味を完全に取得する方法であるということです。実際にメタデータを持っていない場合、せいぜいデータの意味を推測することができますが、あなたには非常に多くの困難があります。メタデータはそこにある必要がありますが、意味には構造があります。意味の哲学に行きたくはありませんが、データを扱う方法においても、人間の思考と人間の言語には多くの洗練があり、データでは簡単に表現できません。しかし、私たちが実際に世界で処理するデータに関しても、メタデータにはメタデータの意味と構造があります。つまり、あるデータと別のデータ、およびそれらがまとめられたときの意味と、他のデータと結合されたときの意味データ、我々はそれをモデル化することを要求します。モノにメタデータタグを記録するだけでは十分ではありません。実際には、構造ごとの意味と構造間の関係を記録する必要があります。

次に、最上位層にビジネス定義があります。これは通常、メタデータ間で意味を転送しようとする層です。これは、コンピューター上でのデータの編成方法と人間の意味に対応するデータ定義の形式です。そのため、その層に存在するビジネス用語、定義、関係、エンティティレベルの概念があります。そして、これらのレイヤーの間に一貫性がない場合、データモデリングが必要です。本当にオプションではありません。それを自動化するという点で実際にできるほど、より良いことです。しかし、それは意味と関係があるため、代替するのは本当に難しいです。レコード内のメタデータをキャッチし、一連の意味からメタデータを取得するのは十分簡単ですが、レコードの構造やレコードの意味やレコードの意味はわかりません。

私の意見では、これがデータモデリングの目的です。注意点：データユニバースが複雑になるほど、モデル化の必要性が高まります。つまり、データレコードに対応するもののインスタンスを世界に追加するだけでなく、実際にはより多くのもののデータをキャプチャすることで世界に意味を追加しているようなものです。私たちが理解しなければならないことは、ますます複雑になっています。

理論上はデータの世界があり、それを見る必要があります。実際には、実際のメタデータはデータユニバースの一部です。したがって、それは単純な状況ではありません。モデリングの開始はトップダウンおよびボトムアップです。両方向に構築する必要があり、その理由は、データはコンピューターとプロセスにとって意味があり、それを処理する必要があるが、それ自体が意味を持つということです。したがって、データにアクセスする必要があるソフトウェアを満たすボトムアップの意味が必要であり、人間が理解できるようにトップダウンの意味が必要です。メタデータモデルの構築は、プロジェクトになることはありません。継続的な活動–存在するすべての環境で継続的な活動であるべきです。幸いなことに、多くの環境があり、実際にはそうではなく、それに応じて物事が制御不能になります。

今後、テクノロジーの進歩に伴い、モデリングの重要性が増します。それが私の意見です。しかし、IoTを見ると、私たちは以前よりもモバイルを理解できますが、新しい次元が導入されました。モバイルのある場所の次元です。 IoTに到達したら、これまで実際に実行する必要がなかった異常なデータの問題を調べていましたが、何らかの方法で、取得したもの、集計する方法、実行できることを正確に理解する必要があります集計から意味を取得するという点で、そしてもちろん、それを処理したときにそれで何ができるかという点で。

これで十分だと思います。 Dez Blanchfieldに話を進めるつもりです。

デズ・ブランフィールド： ありがとうございました。従うのはつらいことですが、これは私たちが同意し、プレショーバンターでこのことについて簡潔に語ったトピックです。早めに電話をかけると、おそらくたくさんの素晴らしい宝石を見つけたでしょう。持ち帰りの1つであり、この特定のものの雷を盗みたくありませんが、私が共有したい私たちのプレショーバンターからの持ち帰りの1つは、あなたがそれを捕まえなかった場合に、データの旅のトピックの周りにありました、そしてそれは、データが世代の生涯を回る別の詐欺-年、月、週、日、時間、分、秒-の旅について考えて実際に書き留めて、データの詐欺はその詐欺の中に位置する。 Imがコードを実行している開発者であるか、Imがデータスペシャリストであり、Imが各要素の構造と形式およびメタデータについて考えているかどうか、またはシステムとビジネスがそれとやり取りする方法です。

注意すべき興味深いちょっとしたお話ですが、とにかく飛び込んでみましょう。特にデータ設計とは、データのすべて、特にアプリケーションまたはデータベースインフラストラクチャの開発について話すために使用するフレーズです。データ設計とは、頭の中ですべてをうまく捉えた用語だと思います。最近、データデザインについて話すとき、現代のアジャイルデータデザインについて話します。私の意見では、開発者とデータの専門家が一人で働いたのはそれほど昔ではありませんでした。それらはそれぞれのサイロにあり、デザインの断片はあるサイロから別のサイロに移りました。しかし、最近では非常に多くの意見があります。変更されたケースだけでなく、変更する必要があります。それは一種の必需品であり、それはそのアプリケーションです-開発者と、データを扱う開発の周りに行うこと、スキーマとフィールドとレコードの関連する設計要素と場所とデータベースシステムとインフラストラクチャ、モデリングと全体の管理を行うデザイナーその周りの挑戦。それは今ではチームスポーツであり、したがって、空を転がる人々の視覚的に興味深い画像を再生するためにチームとして行動する飛行機から飛び出す多くの人々の私の写真です。

第三に、これがどうなったのですか？ 1986年には、私が必死に正義を尽くそうとした2人の紳士によって書かれた記事があります。竹内博隆と野中I次郎は、「スクラムダウンフィールドを動かす」というタイトルの記事を作成しました。このスクラムアクティビティからラグビーの試合に勝つという方法論のアイデアです。全員が1か所で動き回り、2つのチームが基本的にスクラムと呼ばれるものでヘッドをロックし、ボールをコントロールしてフィールドでプレーします。トライラインに着き、ボールで地面に触れて、トリンと呼ばれるポイントを獲得します。このプロセスを繰り返して、チームのポイントを増やします。

この記事は1986年にハーバードビジネスレビューで公開されましたが、不思議なことに実際に多くの注目を集めました。それは驚くべき新しい概念を導入したので多くの注目を集めました、そして、ここにそれの正面のスクリーンショットがあります。そこで彼らは、このスクラムの概念をゲームラグビーから取り除き、特にデザインとプロジェクト配信、特にプロジェクト配信のゲームでそれをビジネスに持ち込みました。

スクラムが行ったことは、以前にウォーターフォール方法論と呼ばれていたPRINCE2やPMBOKのような方法論と比較して、新しい方法論を提供してくれました。周りにあるすべてのドット。これはあなたが持っていたものに依存するか、パート1に依存するためパート1を完了するまでパート2を実行しないでください。それが私たちに与えたのは、もう少し機敏になる新しい方法論であり、それは用語の由来であり、物事をどのように提供するか、特に設計と開発の草の根プロジェクトの提供に関するものです。

キーテナントの一部は、スクラムのキーテナントの周りにあります。カオスの恐怖について考えると、世界はカオスの状態にあるが、惑星は形成されたので、興味深いので、不安定性を構築し、少し跳ね返る能力、実際には、物事を機能させる、プロジェクトチームを自己組織化する、非常に責任ある開発による好意の重なり、プロジェクト実施の旅を通じたさまざまな種類の学習と制御、学習の組織的移転。それでは、ビジネスのある部分から情報を取得し、アイデアはあるがコードを開発していない、またはデータベースやインフラストラクチャを開発せずにデータを別の人に転送する方法を教えてください。そして、具体的にはタイムボックス化された結果。つまり、24時間のように1日間、または1週間または2、3週間の間、これを行い、何ができるかを確認してから、戻って見てみましょう。

だから、もしあなたがしゃれを許せば、これは本当にプロジェクト配信の新しいゲームであり、3つのコアコンポーネントであり、ここで少し進んでいくと理にかなっています。製品があります。何かを成し遂げる必要性とそれを取り巻く物語。スクラム方法論を使用してストーリーを議論し、何をする必要があるかを理解し、それから先に進んでそれを実行するというアジャイルモデルで日々のスタンドアップを通じて操作する開発者。その後、人々は、この全体を監督し、それを推進するのに十分な方法論を理解しているスクラムマスターのことを聞きました。右側のポストイットノートでいっぱいのホワイトボードの右側にあるこれらの画像を見てきましたが、それらはかんばんの壁として使われていました。カンバンが誰なのかわからない場合は、カンバン氏が誰であるか、そしてそれが文字通りではなくプロジェクト内で壁から物事を一方から他方へ移動する方法が変わった理由をGoogleに招待します。

一見すると、スクラムワークフローはこれを行います。組織が実行したいことのリストを取得し、ssと呼ばれる一連の処理を24時間、1か月の期間に分割して実行します。この一連の増分出力を取得します。プロジェクトの実施方法が大幅に変更され、その段階まで実施されました。その一部は、PMBOKと呼ばれるものの開発に多大な貢献をしたアメリカ軍のように流れます。現場に戦車が弾丸を持っていない場合、それは役に立たないので、あなたが物に弾丸を入れるまで。したがって、パート1は戦車に弾丸を置き、パート2は戦車をフィールドに置きます。ただし、残念ながら、開発の世界の開発者に何が起こったのかは、このアジャイルな方法論をどうにかして手に入れて、もしあなたがしゃれを許せばすぐに実行されました。

常に起こったことは、アジャイルについて考えるとき、私たちは通常、データベースではなく開発者のことを考え、データベースの世界に関係することです。アジャイルは開発者に限定されないという現実があるため、残念な結果でした。実際、私の見解ではアジャイルという用語は、データベース設計者やアーキテクトではなく、ソフトウェア開発者にのみ誤って関連付けられていることがよくあります。ソフトウェアとアプリケーションの開発で直面するのと同じ課題が、データインフラストラクチャ、特にデータベースの設計と開発、運用とメンテナンス、そしてそのためのあらゆることに直面します。この特定のデータキャストのアクターには、データアーキテクト、成形業者、管理者、データベースインフラストラクチャの管理者、実際のデータベース自体が、ビジネスおよびシステムのアナリストやアーキテクト、座ってシステムの仕組みを考える人などが含まれます。ビジネスの運営と、これらを介してデータをどのように流してきたか。

これは、データスペシャリストがプロジェクト配信のすべてのコンポーネント、特に開発に密接に関与しなければならない（すべきではない）という見方を非常に重視しているという点で、私の不断のフラストレーションであるため、定期的に取り上げるトピックです。そうしないと、本当に良い結果を得るための最良のチャンスを与えてくれません。シナリオが存在し、アプリケーションの構築に着手し、開発者が必ずしもデータの専門家ではないため、これらのことについてよく考え直さなければなりません。データベースの操作には、特にデータに関する非常に専門的なスキルが必要であり、経験を積むことができます。すぐにデータベースの第一人者やデータ知識の専門家になるだけではありません。これは多くの場合、生涯の経験から来たものであり、確かに本を非常に豊かに書いたコード・トゥデイのロビン・ブローア博士と同類のものです。

多くの場合（そして残念ながら現実ですが）、このコインには2つの部分があります。つまり、ソフトウェア開発者はデータベーススペシャリストに関して独自のブラックアウトを持ち、データベース設計モデリングに必要なスキルを構築します。データがどのように入力され、データがどのように移動するか、どのように見えるべきか、またはそうでないか、またはソフトウェア開発者向けに設定されたネイティブスキルで取得されていることを間違いなく理解していることに関する、グルエンジニアリングの基本です。そして、私たちが直面する共通の課題のいくつかは、簡単に言えば、コアデータベース設計自体の基本的な作成と保守、管理、データとデータベースインフラストラクチャの文書化、それらのデータ資産、スキーマ設計の再利用、スキーマの生成、スキーマの管理と保守、およびそれらの使用、このスキーマが特定の方法で設計されている理由に関する知識の共有、およびそれに伴う長所と短所が、時間の経過に伴うデータの変化、データモデリング、およびタイプを引き起こす私たちがシステムに適用するモデルと、それらを流れるデータ。データベースコードの生成と統合を行ってから、それらの周りのデータをモデル化してから、データのセキュリティを制御するためにより迅速にアクセスします。データの整合性は、整合性を維持しながらデータを移動します。それは、販売がテーブル内のすべてのレコードを見るべきか、それとも住所、名、あなたが投稿にある姓だけを見るべきか？そしてもちろん、最大の課題は、それ自体がまったく異なる会話であるデータベースプラットフォームのモデリングです。

私は、このすべてを可能にするためにこのすべてを念頭に置いて、データの専門家と開発者の両方が適切なツールを持ち、それらのツールがチーム中心のプロジェクト配信が可能であることが絶対に重要であると非常に考えています設計、開発、および継続的な運用保守。データ専門家とソフトウェア開発者の間のプロジェクト間での共同作業、データベース自体、データ、スキーマ、レコードの出所、それらのレコードの所有者に関するドキュメントに関するすべての単一の真実の情報源。私はこの日と年齢において絶対に重要だと思います、私たちはこのデータのirを王にするつもりです、私たちが手動でそれを行うには挑戦が大きすぎるので、適切なツールを設置しなければなりません1つの組織に出入りする場合、1人の人が設定するのと同じプロセスや方法論に従わないことはあまりにも簡単であり、必ずしもそれらのスキルや能力を今後移転するわけではありません。

それを念頭に置いて、IDERAの私たちの良き友人に向かい、そのツールと、それがこれらのこと自体にどのように対処しているかについてお聞きします。

ロン・フィゼンガ： 本当にうまくステージを設定してくれたロビンとデズの両方に感謝します。そして、私が話してきたいくつかの事柄に少し重複が見られるでしょう。しかし、彼らは私がデータモデリングの観点からお話しするいくつかの概念の非常に強固な基盤を実際に設定しました。そして、彼らが言ったことの多くは、私がチームとともにデータモデリングとデータアーキテクチャで働くコンサルタントだったときの私自身の経験を反映しています。初期のウォーターフォールと、アジャイルを使用するプロジェクトでよりモダンな製品への進化の両方ソリューションを提供する方法論。

そのため、本日お話しするのは、これらの経験に基づいており、ツールの見方と、その旅に沿って支援するために利用するツールの機能の一部です。非常に簡潔に説明するのは、スクラムについてはあまり詳しく説明しません。それが何であるかについて、本当に良い概要がありました。データモデルとは何か、そしてそれが本当に私たちにとって何を意味するのかという点で説明します。また、組織でアジャイルデータモデラーの概念を有効にする方法、データモデラーとの関わり方、モデル作成者とアーキテクトのsへの参加、彼らが取り組むべき活動の種類について、そしてその背景として、私たちが本当にその仕事をより簡単にするのに利用する重要なモデリングツールの機能のいくつかは何ですか？次に、少しまとめて、データモデラーを関与させることのビジネス上の価値と利点、または実際に話をする方法について少し説明します。データモデラーがプロジェクトに完全に関与していないという問題と、長年前に関与した実際のプロジェクトの前後のイメージの経験と欠陥チャートに基づいて、それを示します。そして、さらにいくつかのポイントを要約し、それに加えて質問と回答を行います。

非常に簡単に言えば、ER Studioは非常に強力なスイートであり、さまざまなコンポーネントが含まれています。データアーキテクト。データモデル作成者とアーキテクトがほとんどの時間をデータモデリングに費やす場所です。プロセスモデリングを行うビジネスアーキテクトや一部のUMLモデリング用のソフトウェアアーキテクトなど、今日はまったく話さない他のコンポーネントもあります。次にリポジトリがあり、ここでチェックインし、モデルを共有し、チームがそれらでコラボレーションしてチームサーバーに公開できるようにして、プロジェクトに関与している複数の関係者オーディエンスが実際に私たちの成果物を見ることができるようにしますデータの観点だけでなく、プロジェクトの配信自体で行っている他のことからも再作成します。

私が今日焦点を当てるのは、Data Architectから見るいくつかのことです。これは、リポジトリベースの側面のコラボレーションを持つことが本当に重要だからです。特に、アジャイル開発プロジェクトだけでなく、今後のあらゆるタイプの開発に不可欠な変更管理などの概念について話し始めるとき。

それでは、アジャイルデータモデラーについて少し話しましょう。プレゼンテーションの前半で言及したように、アジャイル開発プロセスに完全に携わるデータモデラーやアーキテクトを配置することが不可欠です。さて、歴史的に起こったことは、はい、開発の観点からアジャイルについて本当に考えてきたということです。実際にそれを引き起こす原因となったいくつかのことがあります。その一部は、開発自体の展開方法の性質に起因するものでした。アジャイル開発が始まり、この自己組織化チームという概念から始めたので、Kool-Aidを少し純粋すぎて、極端なプログラミングの側面にいた場合、次のようなものの非常に文字通りの解釈がありました多くの人が意味すると解釈される自己組織化チーム、私たちに必要なのは、ソリューション全体を構築できる開発者のグループです。コード、データベース、またはその背後にあるデータストアの開発を意味するかどうかにかかわらず、すべてが開発者に委ねられました。しかし、それで起こることは、人々が持っている特別な能力を失うことです。最も強いチームは、さまざまなバックグラウンドの人々で構成されているチームであることがわかりました。強力なソフトウェア開発者、データアーキテクト、データモデラー、ビジネスアナリスト、ビジネス利害関係者の組み合わせなど、すべてが連携して最終ソリューションを実現します。

私が今日話しているのは、データコンポーネントも関連付けられるアプリケーションを開発する開発プロジェクトのコンの中でこれを行うことです。ただし、その前に後退する必要があります。なぜなら、その開発プロジェクト自体内でのみ制限されるデータの作成と消費に完全に焦点を合わせているグリーンフィールド開発プロジェクトはほとんどないことを認識する必要があるからです。。一歩後退して、データの観点とプロセスの観点から全体的な組織の観点を検討する必要があります。なぜなら、私たちが利用している情報は、組織のどこかにすでに存在している可能性があるからです。モデラーおよびアーキテクトとして、私たちはそれを明らかにし、プロジェクト自体のどこから情報を入手するかを知っています。開発者がコードのデザインパターンを持っているのと同じようにデザインパターンを持っているため、関連するデータ構造も知っています。また、全体的な組織の観点も考慮する必要があります。作成しているアプリケーションの詐欺のデータを見るだけではできません。データはモデル化され、文書化されていることを確認する必要があります。これは、データがアプリケーション自体を超えて存続するためです。これらのアプリケーションは行き来しますが、データだけでなく、アプリケーションだけでなく、アクティビティを報告する意思決定、BIレポート、他のアプリケーションへの統合、内部およびデータの堅牢性と構造化を確認する必要があります私たちの組織の外部にも。そのため、データの全体像とそのデータのライフサイクルとは何かを検討し、組織全体のゆりかごから墓場までの情報の旅を理解する必要があります。

さて、実際のチーム自身と私たちが実際に仕事をする方法に戻ると、ウォーターフォール方法論は結果を出すには遅すぎると認識されていました。なぜなら、タンクの例で指摘したように、それは次から次へとステップであり、実行可能な最終結果を提供するのに時間がかかりすぎることが多かったからです。私たちが今やっていることは、そのコンポーネントを徐々に開発し、使用可能なコードや使用可能なアーティファクトを作成する時間をかけて作業を繰り返す反復作業スタイルが必要だということです。重要なのは、チーム内の技術関係者とビジネス関係者とのコラボレーションです。これらのユーザーストーリーを実装して、コードとそのコードをサポートするデータの実装可能なビジョンを実現します。また、アジャイルデータモデラー自体は、組織内に十分なモデラーがいないため、1人のデータモデラーまたはアーキテクトが複数のチームを同時にサポートしている場合があります。

また、他の側面として、複数のモデラーがいる場合でも、同時に飛行中の複数のプロジェクトのコラボレーションとそれらの共有を可能にするツールセットを使用する必要があります。データアーティファクトとチェックインおよびチェックアウト機能。これについては、前のセクションで既に説明したので、すぐに説明します。アジャイルの本当の前提は、バックログ、ストーリー、または要件に基づいて物事をベースにしているということです。繰り返しの中で、私たちはグループとして協力しています。通常、組織に応じて2週間または1か月が非常に一般的です。また、毎日のレビューとスタンドアップミーティングにより、ブロッカーを排除し、さまざまな分野で作業を中断することなくすべての側面を前進させることができます。そして、これらの機能では、すべての機能の一部として使用可能な成果物を確実に作成する必要があります。

それを少し変えて、さらに拡張して、スクラムがここでより具体的に説明する方法論であり、基本的には、前の写真を他のいくつかのファセットで拡張しました。通常、製品のバックログがあり、その後にバックログがあります。全体のバックログがあり、すべての繰り返しの始めに、「このsを構築する予定はありますか？」と言うために切り詰め、それはs計画会議で行われます。次に、それに関連付けられているタスクを分割し、それらの1〜4週間の日課で実行します。それを行っているときに、基本的に構築するために残されているものと、開発速度などを確立するために構築しているものを追跡するために、バーンアップチャートとバーンダウンチャートを使用して進捗状況を追跡していますスケジュール、これらすべての種類のもの。これらはすべて、数か月先に進んで、あなたが不足することを知り、プロジェクトのスケジュールを延長する必要があることを見つけるのではなく、sの間に継続的に精緻化されます。そして、非常に重要なことは、その一部として、チーム全体で、最後にレビューとして、そして回顧としてあるので、次のイテレーションを開始する前に、あなたがしたことをレビューして、改善できる方法を探しています次回から。

成果物に関しては、これは基本的にssで行われる典型的なタイプの事柄を要約したスライドです。そして、それは非常に開発中心ですので、機能設計やユースケース、設計コードテストの実行、ここでこれらのボックスを見るときなど、私たちがここで見るものの多くは、それらを通り抜けるつもりはありませんどんな詳細レベルでも、それらは非常に開発志向です。そしてこの下に埋もれているのは、この取り組みをサポートするためにこれと連動するデータ提供物も必要であるという事実です。そのため、バックログ、要件、ユーザーストーリーなどを確認するたびに、実行する必要がある開発要素、分析する必要がある要素、および方法について検討する必要があります。データデザインやデータモデル、ビジネス用語集など、ビジネスの意味を、作成しているすべての成果物に関連付けることができますか？なぜなら、これらの有用な成果物を毎秒作成する必要があるからです。

一部の人々は、すべてのの最後に使用可能なコードを生成する必要があると言うでしょう。それは必ずしもそうではありません、それは最も純粋な開発の観点からですが、特に最初の段階では、ゼロに近いものを持っていることがあります。場所。詳細の記入を開始する前に開始するための高レベルの設計と、他の聴衆とのエンゲージメントを開始し、チームとして前進する前に、明確な開始ストーリーまたは要件のセットがあることを確認します。準備時間は常にわずかなので、ほとんどの場合、ゼロまたは1がゼロになります。ソリューションの提供に全力を尽くすまでには、ほんの少しのスタートアップ段階かもしれません。

このコンのデータモデルについて簡単に説明します。データモデルについて考えるとき、データモデルは、さまざまな情報がどのように結び付いているかを示す写真であると考えることがよくあります。これは氷山の一角にすぎません。データモデリングへのアプローチ方法（アジャイル開発など）の精神を完全に具現化するには、データモデルが正しく行われれば、そのデータが組織で意味するものの完全な仕様になることを認識する必要があります。バックエンドデータベースでの展開方法。データベースとは、使用しているリレーショナルデータベースだけでなく、ビッグデータまたはNoSQLプラットフォームが存在する今日のアーキテクチャで、それらを呼び出すことを好みます。また、これらのビッグデータストアは、情報の消費とソリューションへの持ち込みの点で多くの異なるデータストアを組み合わせている可能性があります。また、情報をソリューションから保持または保存する方法も同様です。

特定のアプリケーションで複数のデータベースまたはデータソースを同時に使用する場合があります。非常に重要なのは、完全な仕様、つまり組織の観点としてこれが何を意味するのか、実際のデータをどのように定義するかという観点からの物理的な構成要素の論理的な仕様、データベース、参照整合性制約、チェック制約、通常考えられるすべての検証要素。記述的なメタデータは非常に重要です。アプリケーションでデータを活用する方法をどのように知っていますか？それを定義して意味を理解できない場合、またはそれがどこから来たのかを知って、それらのアプリケーションで正しいデータを消費していることを確認しない限り、正しい命名規則、完全な定義、つまりこれらのテーブルを構成する列ではなく、これらのテーブルを構成する列と、このアプリケーションが完了した場合でもこの情報は他のイニシアチブに使用されるため、このナレッジベースを構築する必要があるため、その使用方法に関する詳細な展開メモ将来の実装のためにすべてが文書化されていること。

繰り返しになりますが、データ型、キー、インデックスのようなものに取りかかります。データモデル自体には、多くのビジネスルールが組み込まれています。関係は、異なるテーブル間の単なる制約ではありません。多くの場合、データがどのように振る舞うか、まとまりのあるユニットとしてどのように連携するかについての真のビジネスルールを説明するのに役立ちます。そしてもちろん、値の制限は非常に重要です。もちろん、私たちが絶えず対処しているものの1つは、データガバナンスのようなものです。それで、データガバナンスの観点から、ここで何を定義しているのかを見なければなりませんか？セキュリティ分類などを定義したいと思います。どのような種類のデータを扱っていますか？マスターデータ管理と見なされるものは何ですか？作成しているトランザクションストアは何ですか？これらのアプリケーションでどの参照データを利用していますか？モデルで適切にキャプチャされることを確認する必要があります。また、データ品質に関する考慮事項もあります。組織にとって、他の情報よりも重要な情報があります。

私は、12を超えるレガシーシステムを新しいビジネスプロセスに置き換え、それらに代わる新しいアプリケーションとデータストアを設計するプロジェクトに携わってきました。情報の発信元を知る必要がありました。ビジネスの観点から、最も重要な情報については、ここにあるこの特定のデータモデルのスライドを見ると、これらの特定のエンティティの一番下のボックスは小さなサブセットであることがわかります。実際にビジネス価値を獲得することができました。組織内のこれらのさまざまな構成要素に対するこれらのタイプの事柄について、高、中、または低かどうか。また、マスターデータクラス、マスターテーブルであるかどうか、参照であるかどうか、トランザクションであるかどうかなどもキャプチャしました。したがって、モデル内のメタデータを拡張して、データ自体以外の多くのその他の特性を提供することができます。これは、元のプロジェクト以外の他のイニシアチブで実際に役立ち、それを推進します。これが1つのスライドにたくさん含まれていたので、これらの残りの部分についてはかなり迅速に説明します。

これらの異なるssを実行する際に、データモデラーが何をするかについて、すぐに説明します。まず第一に、ユーザーのストーリーを取り上げ、その中に何を配信するかをコミットし、それをどのように構築して配信するかを考えている計画セッションの完全な参加者です。データモデラーとしてもやっていることは、異なる開発者や異なる人々と別々の分野で仕事をするつもりだということです。したがって、私たちが持つことができる重要な特性の1つは、データモデルを実行しているときに、そのデータモデルをサブジェクトエリアまたはサブモデルと呼ぶかどうかに関係なく、異なるビューに分割できることです。したがって、モデルを構築する際に、これらのさまざまなサブモデルの観点でもモデルを表示しているので、さまざまな視聴者は自分に関連するものだけを見ることができるので、開発や提案に集中できます。したがって、アプリケーションのスケジューリング部分で作業している人がいるかもしれませんし、単一のsでこれらすべてを行っているオーダーエントリで作業している人もいるかもしれませんが、これらのサブモデルだけで視点を与えることができます彼らが取り組んでいるエリアに適用されます。そして、それらは全体的なモデルとサブモデルの構造全体にロールアップし、さまざまな視聴者に必要なものを表示します。

私たちが持ちたいデータモデリングの観点からの基本は、常にできるベースラインを持っていることです。なぜなら、できることが必要なことの一つは、それがasの終わりか終わりかであるからです。いくつかのss、私たちはどこから始めたのかを知りたいと思っており、常に与えられたsで生成したものの差分または差が何であるかを知るためのベースラインを持っています。また、迅速な対応ができるようにする必要もあります。データモデラーとして登場するが、「いいえ、いいえ、できません。まずこのすべてを行う必要があります」と言う従来のゲートキーパーの役割では、本当に必要なときにチームから除外されます。これらすべてのアジャイル開発チームに積極的に参加すること。つまり、特定のsを実行しているワゴンからいくつかのものが落ち、後のssでそれらを拾います。

例として、開発を進めるためだけにデータ構造に焦点を当てることができます。たとえば、私が話していたオーダーエントリピースです。後で、作成したアーティファクトの一部に関するデータディクショナリのドキュメントのように、戻ってデータを入力できます。その定義をすべて1つずつ完了することはできません。開発者がアプリケーションとそれらのデータストア周辺の永続性の構築に忙しいときに、ビジネスアナリストと連携して情報を入力できる場合があるため、成果物を徐々に増やしていきます。ボトルネックにならないようにします。開発者と協力するさまざまな方法があります。設計パターンがあるため、完全な参加者であるため、モデルに配置するという設計パターンがあり、開発者のサンドボックスデータベースにプッシュしてから、作業を開始し、それに変更を要求します。

開発者が取り組んでいる他の分野があるかもしれません、彼らは彼らが取り組んでいる何かを手に入れて、彼らは彼ら自身の開発環境でいくつかのことを試してみようといくつかのことをプロトタイプ化しています。彼らが作業してきたデータベースをモデリングツールに取り込み、所有しているモデルと比較してから、変更を解決してプッシュして戻すことで、適切なデータ構造に従うようにコードをリファクタリングできます。それが必要です。彼らがすでに他の場所に持っていたものを作成した可能性があるため、適切なデータソースで作業していることを確認します。私たちはこれをsに至るまでずっと繰り返し続けているので、完全なデータ成果物、完全なドキュメント、および作成しているすべてのデータ構造の定義を取得できます。

非常に優れた配信に関して私が携わった最も成功したアジャイルプロジェクトは、完全な物理データベース仕様に対するすべての変更をモデル化するという哲学を持っていました。基本的に、データモデルは、私たちが作成している新しいもののために作業している展開されたデータベースになり、他の外部データベースから消費している場合、他のデータストアの完全な参照を持ちます。その一環として、毎回完全な世代を作成するのではなく、増分スクリプトを作成しています。そして、私たちはデザインパターンを利用して、作業しているさまざまな開発チームと物事をスムーズに進めるという点で、私たちにその素早い上昇をもたらしています。

sアクティビティでも、比較/マージのベースラインになりますので、各変更のモデリングのアイデアを考えてみましょう。変更を行うたびに、私たちがしたいことは、変更をモデル化することであり、非常に重要なこと、最近までデータモデリングに欠けていたもの、実際には、それを再導入するまで、モデリングを関連付ける機能です実際にそれらの変更を発生させるユーザーストーリーとタスクを含むタスクと成果物。開発者がコードをチェックインするのと同じように、モデルの変更をチェックインできるようにしたいので、私たちが持っているユーザーストーリーを参照して、最初に変更を加えた理由を知ることができます。それを行うとき、インクリメンタルDDLスクリプトを生成してポストし、他の開発成果物でそれらをピックアップしてビルドソリューションにチェックインできるようにします。繰り返しますが、1つのモデルがある場合や、複数のチームで作業している場合があります。先ほどお話ししたように、データモデラーによって作成されたものも、開発者によって作成されたものもありますが、全体的に最適な設計を考え出すために途中で集まり、それを適切に設計するようにします全体的なデータ構造。 nullおよびnot null値、参照制約、基本的にチェック制約など、通常考えられるすべてのことを含め、データモデルに適切な構造をすべて確保するという規律を維持する必要があります。。

これを行うのに役立ついくつかのツールのスクリーンショットをいくつかご紹介しましょう。私が重要だと思うのは、その共同リポジトリを持つことです。そのため、データモデラーとしてできること（これはバックグラウンドでのデータモデルの一部のスニペットです）は、できることを確認したいことに取り組んでいるときです。変更できるようにする必要があるオブジェクトだけを操作し、変更を加え、チェックイン時に行った変更に対してDDLスクリプトを生成します。それで、ER Studioでできることは、例です。作業するオブジェクトまたはオブジェクトのグループをチェックアウトできます。モデルまたはサブモデル全体をチェックアウトする必要はありません。興味のあるものだけをチェックアウトできます。その後、チェックアウト時またはチェックイン時のいずれかでやりたいと考えています。開発チームが異なると作業方法も異なるため、両方の方法で実行します。私たちは、それを、この要件を推進しているユーザーストーリーまたはタスクに関連付け、それが開発者がコードを開発およびチェックインするユーザーストーリーまたはタスクと同じであることを確認したいと考えています。

そのため、変更管理センターのいくつかの画面の非常に短いスニペットがここにあります。これが何をするのか、ここでは詳しく説明しませんが、表示されるのはユーザーストーリーまたはタスクであり、実際の変更レコードを表示している各ユーザーの下にインデントされます。チェックインとチェックアウトを行い、その変更レコードにさらに説明を加えることができます。これはタスクに関連付けられており、期待どおりにタスクごとに複数の変更を加えることができます。そして、私たちがその変更記録に入ったとき、私たちはそれを見て、さらに重要なこととして、実際に何が変わったのかを見ることができますか？この特定のものについて、ハイライトされたストーリーでは、1つのタイプの変更が行われ、実際の変更レコード自体を見ると、変更されたモデルの個々の部分が識別されています。ここでいくつかの属性を変更し、それらの順序を変更し、それらに依存する変更が必要なビューを乗せて持ち込み、インクリメンタルDLLで生成されるようにしました。ベースオブジェクトのモデリングだけでなく、このような強力なモデリングツールは、データベースまたはデータモデルの依存オブジェクトにも波及する必要がある変更を検出します。

開発者と作業していて、サンドボックスで何かをしているときに2つの異なることを行い、違いがどこにあるかを比較して確認したい場合は、右側と左側の比較/マージ機能を使用します側。「左側にモデルがあり、右側にデータベースがあり、違いを示してください」と言うことができます。その後、データベースに何かをプッシュするかどうかにかかわらず、それらの違いを解決する方法を選択できます。データベースにあるものがモデルに戻ってきます。双方向に移動できるため、ソースとターゲットの両方を同時に双方向に更新し、増分DDLスクリプトを生成して、それらの変更をデータベース環境自体に展開できます。これは非常に重要です。また、いつでもこの比較およびマージ機能を使用できます。途中でスナップショットを撮っている場合は、あるものの開始と別の開始または終了を常に比較できるので、特定の開発または一連のssで行われたものの完全な増分変更。

これは、alterスクリプトの非常に簡単な例です。データベースで作業している人なら誰でもこのタイプのものを見ることができます。これは、alterスクリプトとしてコードから押し出すことができるためです。ここで物事を保持します。混乱を減らすためにここから取り出したのは、これらの変更スクリプトでも行うことです。これらのテーブルにもデータがあると想定しているため、一時テーブルの情報をプルするDMLも生成します。それを新しいデータ構造にも押し戻します。そのため、構造だけでなく、それらの構造にすでに含まれているデータも調べています。

自動化されたビルドシステムについて非常にすばやく話をします。なぜなら、アジャイルプロジェクトを頻繁に行っているときは、ビルドを壊さないようにさまざまな成果物を一緒にチェックインする必要がある自動化されたビルドシステムで作業しているからです。つまり、成果物を同期し、DDLスクリプトで説明した変更スクリプトをチェックインする必要があります。対応するアプリケーションコードを同時にチェックインする必要があり、現在の多くの開発者開発はもちろんそうではありませんデータベースとそのタイプに対してダイレクトSQLで行われます。多くの場合、永続フレームワークを使用したり、データサービスを構築しています。これらのフレームワークまたはサービスの変更が正確に同時にチェックインされるようにする必要があります。一部の組織では自動ビルドシステムに入り、アジャイル方法論でビルドが壊れた場合は、先に進む前にすべての手作業でそのビルドを修正するため、先に進む前に有効なソリューションがあることがわかります。そして、私が関わったプロジェクトの1つで、これを極端なものにしました。ビジネスユーザーと同じ場所にある地域の多くのコンピューターに実際に取り付けられていたビルドが壊れた場合、パトカーのトップのように。そして、ビルドが壊れた場合、それらの赤い点滅ライトが消え始め、それがすべてのデッキにあることがわかりました：ビルドを修正してから、私たちがやっていることを続行します。

他のことについてお話したいと思いますが、これはER Studioのユニークな機能です。これらの永続性境界の開発者としてこれらのアーティファクトを構築しようとする場合、ビジネスデータオブジェクトと呼ばれる概念があり、この非常に単純化されたデータモデルを例として見ると、永続性境界が存在するエンティティまたはエンティティのグループをカプセル化できます。データモデル作成者として、注文書のヘッダーと注文の整列、およびそれを構築する方法でそれに結びつく他の詳細なテーブルのようなものを考える場合、データサービス開発者はそれらの異なるデータに物事がどのように持続するかを知る必要があります構造。私たちの開発者は、発注書のようなものを全体的なオブジェクトとして考えており、それらの特定のオブジェクトの作成方法との契約は何であるかを考えています。データサーバーを構築する人々がその下にあるものを見ることができるように技術的な詳細を公開し、他のオーディエンスを複雑さから保護して、異なる高レベルのオブジェクトを見ることができます。さまざまなビジネス概念の相互作用についても話しているときは、アナリストとビジネス関係者。

また、これらのビジネスデータオブジェクト自体に含まれるコンストラクトに由来する高次オブジェクト間の関係を維持できるように、これらを建設的に展開したり折りたたんだりすることも素晴らしいことです。モデラーとして、最後に、最後の最後に、私はやらなければならないことがたくさんあります。それを次のsのハウスキーピングと呼びます。名前付きリリースと呼ばれるものを作成するたびに、リリースの最後に現在持っているもののベースラインが得られます。つまり、これは今後のベースライン、リポジトリで作成して保存するすべてのこれらのベースラインまたは名前付きリリースであり、比較/マージを行うために使用できるため、他のsのsの任意の終わりと常に比較できますデータモデルに対する変更がその過程でどのようなものであったかを知ることは非常に重要です。

また、sの最初から最後まで、compare / mergeを再度使用して、デルタDDLスクリプトを作成します。たくさんのインクリメンタルスクリプトをチェックインしたかもしれませんが、必要な場合は、他のサンドボックスを立ち上げるために展開できるスクリプトがあるので、これが1つ目の最初にあったものであると言えます。それを経て、次のsから開始するサンドボックスとしてデータベースを構築します。また、これらのことを使用してスタンドアローンQAインスタンスのようなことを行うことができ、最終的にはもちろん、変更を本番にプッシュして、複数のことが行われるようにします同時に。繰り返しますが、私たちは計画と回顧に完全に参加します。回顧は本当に学んだ教訓であり、それは非常に重要です。なぜなら、あなたはアジャイルの間に非常に早く進むことができるので、今のように成功を止めて祝う必要があるからです。何が間違っているのかを把握し、次回は改善してください。また、次のssで前進し続けるときに、うまくいったことを祝福し、それらに基づいて構築してください。

私は今、ビジネス価値について非常に迅速に話します。私は何年も前にアジャイルプロジェクトとして始めたプロジェクトがあり、それは極端なプロジェクトだったので、すべてを行っているのは開発者だけである純粋な自己組織化チームでした。簡単に言えば、このプロジェクトは行き詰まっており、特定された欠陥の修正と修正に、より多くの機能をプッシュするよりも、実際に見て、バーンダウンチャートで、彼らは莫大な費用でプロジェクトを6か月延長する必要がありました。そして、私たちがそれを見たとき、問題を修正する方法は、プロジェクト自体に関係する熟練したデータモデラーで適切なデータモデリングツールを利用することでした。

この特定のチャートのこの垂直バーを見ると、これは累積的な欠陥と累積的なオブジェクトを示しており、私が見ているのは、制約やそれらの種類のテーブルなど、作成されたデータオブジェクトまたは構成についてですデータモデラーが導入される前は、欠陥の数が実際に超過しており、その時点までに生成された実際のオブジェクトの数に対してわずかなギャップが生じ始めていました。 21週間後、つまりデータモデラーがやって来て、多くの問題を修正するために何があったかに基づいてデータモデルをリファクタリングし、プロジェクトチームの一部としてモデリングを開始しました。。そして、開発者のスティックビルディングではなくデータモデリングツールから生成しているため、約1.5年以内に、生成および構築されているオブジェクトおよびデータコンストラクトの数が大幅に増加したことがわかりました。それらは環境内にあり、適切な参照整合性とそれが持つべき他の構成要素を持っているため、正しいものでした。ほぼフラットラインに対する欠陥のレベル。適切なアクションを取り、データモデリングが完全に関与するようにすることで、プロジェクトは予定よりもはるかに高い品質で納品されました。実際、これらの手順が実行されなければ、プロジェクトはまったく納品されませんでした。アジャイルの失敗はたくさんあります。また、適切な人を適切な役割に任せれば、アジャイルの成功もたくさんあります。私は運用の規律としてアジャイルを大いに支持していますが、アジャイルタイプの取り組みを進める際には、プロジェクトチームとして関与するすべての適切なグループのスキルがあることを確認する必要があります。

要約すると、データアーキテクトとモデラーはすべての開発プロジェクトに関与する必要があります。データモデラーやアーキテクトとして、特定の開発プロジェクトのデータ構成だけでなく、組織内のデータの存在場所や、そのデータのソースおよび入手方法も理解しているため、これらは本当にすべてを結び付ける接着剤です私たちが取り組んでいる特定のアプリケーション自体の外部で使用され、利用されます。複雑なデータの関係を理解しており、前進すること、そしてガバナンスの観点からマップドキュメントを作成し、データの全体像がどのように見えるかを理解することが最も重要です。

製造のようなものです。私は製造業のバックグラウンドから来ました。最終的に品質を何かに検査することはできません。設計の品質を前もって通していく必要があります。データモデリングは、その品質を設計に効率的かつ費用対効果の高い方法で組み込む方法です。。繰り返しになりますが、これは些細なことではありませんが、真実です-アプリケーションは行き来し、データは重要な企業資産であり、アプリケーションのすべての境界を超えています。アプリケーションを挿入するたびに、以前に来た他のアプリケーションのデータを保存するように求められる可能性があります。そのため、これは重要な企業資産であり、長期にわたって維持していることを覚えておく必要があります。

以上です！ここから、さらに質問をします。

エリック・カバナ： いいでしょう、まずロビンに投げてみましょう。それから、デズ、質問がいくつかあると思います。ロビン。

ロビン・ブロア博士： はい。正直に言うと、アジャイル開発方法に問題は一度もなかったので、ここであなたがしていることは非常に理にかなっているように思えます。 1980年代に、プロジェクトが制御不能になるという点で実際に遭遇する問題は、通常、特定の段階を超えてミスを持続させた場合に起こることを示したものを見たことを覚えています。その段階を正しく行わないと修正するのがますます難しくなるので、ここで行っていることの1つは、スライドであると思いますが、ここでしていることの1つです私の意見では、ゼロは絶対に重要です。なぜなら、あなたは本当に成果物をそこに固定しようとしているからです。また、成果物を固定しないと、成果物の形が変わります。

それは、私の意見です。私の意見でもあります。データモデリングを特定の詳細レベルに到達させる前に取得する必要があるという考えについて、私は本当に議論をしていません。完全に理解できなかったので、試してみてほしいのは、これらのプロジェクトの1つを、そのサイズ、フローの方法、誰が知っているか、問題が発生した場所、彼らは解決されましたか？私はこのスライドがその中心であると思うので、もう少し詳しく説明していただければ幸いです。

ロン・フィゼンガ： 確かに、いくつかのサンプルプロジェクトを使用します。実際に適切な人を関与させ、データモデリングを行うことで復活したレールは、設計がよりよく理解され、明らかにより良い実装設計ができることを確実にする方法でしたそれをモデル化することにより、途中で。なぜなら、それをモデル化するとき、DDLとすべてをツールの外から生成できるからです。人々がデータベース環境に直行するのと同じように、これをビルドし続ける必要はありません。そして、開発者で起こる典型的なことは、彼らがそこに行き、彼らが言った、大丈夫、これらのテーブルが必要だということです。注文入力を行っているとしましょう。そのため、注文ヘッダーと注文詳細テーブル、およびそれらのタイプのものを作成する場合があります。しかし、外部キー関係を表すために制約が存在することを確認することを忘れたり、怠ったりすることがよくあります。キーが正しくない可能性があります。命名規則も同様に疑わしい場合があります。たとえば、さまざまな名前のさまざまなテーブルがたくさんある環境に行った回数はわかりませんが、それらのテーブルの列名はID、Nameなどですまさにそれが何であるかの表なしで詐欺を本当に失いました。

そのため、通常、データモデリングの際には、DDLで生成されるすべてのアーティファクトにも適切な命名規則を適用するようにします。しかし、プロジェクト自体の性質についてより具体的に言うと、一般的に言えば、かなり大規模なイニシアチブについてです。そのうちの1つは、1億5000万ドルのビジネス変革プロジェクトで、1ダース以上のレガシーシステムを置き換えました。 5つの異なるアジャイルチームが同時に進行していました。完全なデータアーキテクチャチームがあったため、他のアプリケーションエリアチームのすべてにチームのデータモデラーを組み込み、主題を知っている社内のビジネスエキスパートの組み合わせで作業していました。要件自体のユーザーストーリー。アクティビティ図またはビジネスプロセス図を使用して、実際にビジネスプロセスをモデリングしている各チームにビジネスアナリストがいました。これにより、ユーザーがチームの残りの部分で消費される前に、ユーザーストーリーをより具体化できます。

そして、もちろん、その上にアプリケーションコードを構築していた開発者。そして、私たちも一緒に仕事をしていましたが、アプリケーションのさまざまな部分を構築しているのは4つの異なるシステム統合ベンダーであり、一方のチームはデータサービスを構築し、もう一方はアプリケーションロジックを1つの領域に構築し、別のチームは専門知識があったと思います別のビジネスエリアでは、そのエリアでアプリケーションロジックを構築していました。そのため、このプロジェクトに取り組んでいる人々の全体的なコラボレーションがありました。特にその1つには、チームの陸上に150人のスタッフがいました。チームの沖に150人のリソースがあり、2週間の協力でこの問題を解決していました。そして、それを行うには、すべてのシリンダーで発砲していることを確認する必要があり、誰もが成果物が何であるかに関して十分に同期されており、必要なすべてのアーティファクトの配信が完了していることを確認するために頻繁にリセットされました毎秒の終わりに。

ロビン・ブロア博士： それは印象的です。それについてもう少し詳しく説明すると、プロジェクトの最後に、データ領域全体の完全な、MDMマップと呼ばれるものができましたか？

ロン・フィゼンガ： 完全なデータモデルがあり、すべての異なるビジネスエリア間で分解されました。完全な定義という点では、データディクショナリ自体は少し不足していました。ほとんどのテーブルが定義されています。ほとんどの列は、それらが意味するものとして定義されていました。存在しなかったものもありましたが、興味深いことに、それらの多くは、プロジェクト範囲自体の終了後も引き続きキャリーフォワードセットとして文書化されていたレガシーシステムからの情報です。プロジェクト自体の外にあるアーティファクト。これは、組織が今後維持する必要があるものであるためです。そのため、組織はデータガバナンスの重要性の観点を大幅に高めました。これは、これらのレガシーシステムと、ドキュメント化されていないため消費しようとしているレガシーデータソースに多くの欠点があるためです。多くの場合、データベースをリバースエンジニアリングし、そこに何があり、情報が何のためにあるのかを把握する必要がありました。

ロビン・ブロア博士： その特定の側面は、私を驚かせません。データガバナンスは非常に現代的な関心事です。実際、データガバナンスに関して歴史的になされるべき仕事がたくさんあると思います。それは決してあなたがそれをしないことで逃げることができるからです。しかし、データリソースが成長し、成長したため、最終的にはできませんでした。

とにかく、時間を割いていたと思うので、私はデズに渡ります。デズ？

デズ・ブランフィールド： はい、ありがとうございます。この全体を通して、私は、アジャイルが多くの点で怒りの中で使われるのを見ることについて話していることを見て、自分自身に考えています。それは否定的な意味合いを持っていますが;私はそれを前向きに意味した。シナリオを教えていただけますか？つまり、これが完璧なセットであることがわかる2つの場所があります：1つは、初日から行う必要がある新しいプロジェクトですが、私は常に、私の経験では、プロジェクトが大きくなり、多くの方法でこれが必要になる場合、2つの世界を接着するのは興味深い課題ですよね？あなたが組織に入った場所で見たいくつかのサクセスストーリーへの洞察を与えてもらえますか？それらが2つの世界のわずかな衝突を持ち、あなたが首尾よく置くことができたことが明らかになりますこれを実施し、大規模なプロジェクトをまとめて、それ以外の場合はレール上で行っていた可能性のある場所に配置しますか？私はそれが非常に幅広い質問であることを知っていますが、あなたが言うことができる特定のケーススタディがあるのかと思っているだけです、あなたが言った場所を指します、あなたは知っています、私たちはこれをすべて配置し、それはすべての開発チームをまとめましたデータチームと私たちは、そうでなければボートを沈めたかもしれない何かに対処しましたか？

ロン・フィゼンガ： 確かに、実際にパイプラインプロジェクトであった1つのプロジェクトは、データモデラーが関与する前後の欠陥を含むチャートを示した場所をほのめかしたものです。多くの場合、先入観があります。特に純粋に開発の観点から物事が紡がれる場合、アプリケーションを提供するためにこれらのアジャイルプロジェクトに関与するのは開発者だけです。したがって、そこで起こったことは、もちろん、彼らが軌道から外れて、特にそのデータ成果物、または彼らが生産していたデータ成果物が、品質と実際に物事に対処するという点でマークを下回ったことです。そして、データモデラーはプロジェクトを遅くするという誤解が非常に頻繁にあり、データモデラーが正しい態度を持たない場合はそうなります。私が言うように、あなたは失う必要があります-時々、「データ構造がどのように見えるかを制御するためにここにいる」という伝統的なゲートキーパーの態度を持つデータモデラーがいます。アジャイル開発に関与している人、特にデータモデラーは、チームの前進を実際に支援するためのファシリテーターとしての役割を果たさなければなりません。そして、それを説明する最良の方法は、最初に変更をモデル化することにより、チームの生産性を非常に迅速に示すことです。繰り返しになりますが、私がコラボレーションについて話しました。

最初にモデルを作成し、DDLを生成して開発者にプッシュできることがいくつかあります。また、制限されているような気分にならないようにしたいと考えています。そのため、作業中の作業がある場合は、開発サンドボックスで作業を続けることができます。これは、開発者が自分のデスクトップまたは他のデータベースで作業を行い、テスト中に変更を加えるためです。そして、彼らと協力して、「わかりました、それで動作します」と言います。それをツールに持ち込み、解決し、次にそれを押し進め、それを展開するために展開できるスクリプトを提供します。データベースをアップグレードして、実際の本番ビューが認可されたものにアップグレードし、今後も前進していきます。そして、あなたはそれを非常に迅速に変えることができます。私は、さまざまな開発チームと繰り返し行ったり、変更を調べたり、比較したり、スクリプトを生成したり、それらを実行したりする日々に満ちていて、4つの開発チームに簡単に追いつくことができました。勢いを達成しました。

デズ・ブランフィールド： それから思い浮かぶことの一つは、あなたが知っているように、私が日常的に持っている会話の多くは、マシンツーマシンの一種であるこの貨物列車に関するものですIoT。現在、企業の現在の環境に大量のデータがあると思われる場合、ユニコーンを少し取って、GoogleとsとUberがペタバイトのデータを持っていることがわかっている場合、従来の企業では、まだ数百テラバイトと大量のデータについて話していました。しかし、私の考えでは、この貨物列車が組織にやって来ており、Robin Bloor博士は以前にIoTについて言及していました。たくさんのウェブトラフィック、ソーシャルトラフィック、モビリティとモバイルデバイスがあり、クラウドには爆発がありますが、スマートインフラストラクチャ、スマートシティがありますそして、爆発したばかりのデータの世界全体があります。

日常的な組織の場合、そこに座ってこの痛みの世界を見ている中規模から大規模の組織は、すぐに計画を立てずに、いくつかの文章で、あなたが置いておくべきことのいくつかを取り上げますこれらの方法論のいくつかを導入することについて、いつ、どこで会話を始める必要があるかについて、彼らに伝えます。座り込んで注意を払うための計画を開始するのにどれくらい早く必要ですか？これはいくつかのツールを配置し、チームを訓練し、この課題を回避するための語彙の会話を取得するのに適切な時期だと言いますか？ストーリーの遅すぎるのは遅すぎますか、それとも早すぎるのですか？あなたが見ているいくつかの組織にとって、それはどのように見えますか？

ロン・フィゼンガ： ほとんどの組織では、まだそれを行っておらず、このような強力なツールを使用してデータモデリングとデータアーキテクチャを調整していない場合、必要な時間は昨日です。今日でも、組織内のデータを見ると、組織内に非常に多くのデータがあり、私たちが見たいくつかの調査に基づいて、そのデータの5％未満を効果的に使用しているのは興味深いからです。組織全体を見るとき。そして、IoTまたはNoSQLでさえ、ビッグデータ（IoTだけでなく一般的なビッグデータであっても）が、組織外から発信される情報をさらに消費し始めているため、その課題はますます大きくなっていますずっと。そして、私たちが取り組むことができる唯一の方法は、そのデータが何であるかを理解するのを助けることです。

そのため、ユースケースは少し異なります。私たちがやっているのは、そのデータを見るとき、それをキャプチャするとき、リバースエンジニアリングする必要がある、データレイクにあるのか、社内のデータベースにあるのか、それらの中にあるものを確認するために、データは、データに意味を定義し、定義を適用して、データが何であるかを理解できるようにします。なぜなら、それが何であるかを理解するまで、それを正しくまたは適切に使用していることを保証できないからです。そのため、そのデータが何であるかを実際に把握する必要があります。そして、それ以外の部分は、この外部データをすべて使用するという観点から、この外部データの使用をサポートするユースケースがあることを確認できるため、実行しないでください。後で必要になる可能性のあるものを引き出して活用しようとするのではなく、必要なものに焦点を当てます。最初に重要なことに集中し、それを進めていくと、外部から他の情報を消費して理解しようとするようになります。

その完璧な例は、私たちがIoTとセンサーについて話していることを知っていますが、同じタイプの問題が実際に長年、IoTの前でさえ多くの組織にありました。パイプライン会社、製造会社、コントロールを使用して多くの自動化を行い、データストリームなどを使用しているプロセスベースの会社など、生産管理システムを持っている人は誰でも把握するためにそれらを飲み込もうとしているデータのこれらのファイアホース、信号を送るために私の生産装置で発生したイベントは何ですか-何が起こったのですか？そして、この膨大なデータストリームの中には、特定の情報やタグのみがあり、それらを選別し、合成し、モデル化し、理解する必要があります。そして、彼らはそれを本当に理解する時が来るまでそれの残りを無視することができ、そしてそれが理にかなっているなら、彼らはそれをもっとスコープに引き込むためにスコープを広げることができます。

デズ・ブランフィールド： 確かにそうです。エリックと呼ばれる紳士からの質問が1つありますが、私たちはそれについてプライベートにチャットしています。私は彼にあなたにそれを求めるために彼に与えられた許可を求めました。これがうまくまとめられたからです。まとめになります。これからは少し時間が経っていますから、エリックに引き渡します。しかし、別のエリックからの質問は、スタートアップの所有者がモデリング用語などの固有の課題に精通しており、理解していると仮定するのは合理的ですか、それとも解釈のために他の人に手渡すべきですか？つまり、言い換えれば、スタートアップは能力と準備ができており、これに焦点を合わせてそれを実現する必要があるのでしょうか？それとも、おそらく彼らは買い物をして専門家を乗せるべきだろうか？

ロン・フィゼンガ： 短い答えは、それは本当に依存していると思います。データベースを本当に理解しているデータアーキテクトまたはモデラーである誰かが社内にいないスタートアップである場合、最も簡単な開始方法は、この分野に精通し、得ることができるコンサルティングのバックグラウンドを持つ人を連れてくることです彼らが行く。あなたが見つけること-実際、私は製品管理のダークサイドに来る前に行った多くのエンゲージメントでこれをしました-私はコンサルタントとして組織に行き、彼らのデータアーキテクチャチームを率いて、そうすることで、彼らは自分自身に焦点を合わせ、こうした種類のことをどのように行うかを人々に訓練して、それを維持し、ミッションを前進させることができます。そして、それが理にかなっている場合は、次のエンゲージメントに進みます。それを行う多くの人々がいますが、彼らは彼らを動かすことができる非常に優れたデータ経験を持っています。

デズ・ブランフィールド： それは重要なポイントであり、私はそれに完全に同意し、ロビン・ブロア博士もそうなると確信しています。特に新興企業では、スタートアップ企業自体の一部として構築しようとしている提案の特定の価値に中小企業であることに焦点を当てており、おそらくすべての専門家である必要はないので、素晴らしいアドバイスが必要です。しかし、素晴らしいプレゼンテーションをありがとうございました。本当に素晴らしい答えと質問。エリック、私たちはあなたに返事をするつもりです。おそらく私たちは時間の経過とともにおそらく10分間行ったことを知っています。

エリック・カバナ： 大丈夫。少なくともいくつかの良い質問があります。私はあなたにそれを投げさせてください。他のいくつかに答えたと思います。しかし、あるアジャイルプロジェクトでは、データモデル作成者が長期的な全体像を把握していないことがあるため、1つで何かを設計し、3つまたは4つで再設計しなければならない場合があります。これは逆効果に思えませんか？どうしてそのようなことを避けることができますか？

ロン・フィゼンガ： 与えられたsですべてを完全に正しくしないのはアジャイルの性質です。そして、それは実際にアジャイルの精神の一部です。それと連携する-与えられたsでコードに取り組んでいるところでプロトタイピングを行い、それを改良します。そして、そのプロセスの一部は、エンドユーザーが見るものを提供し、「うん、近いよ。でも、この少し余分にやらなければならない」と言っていることです。そのため、機能的なデザインだけでなく、コード自体の一部ですが、ユーザーが望むものを提供するために、これらの特定のものの下にデータ構造を変更または追加する必要がある場合が非常に多くあります。そして、それはすべて公正なゲームです。そのため、モデリングツールでその変更を非常に迅速にモデリングおよび作成し、開発者がそれを提供するために作業できるデータベースのDDLを生成できるため、高性能ツールを本当に使用したいのです。さらに迅速に変更します。データ構造を手作業でコーディングしなくても済むようにし、プログラミングやアプリケーションロジックに最も集中できるようにします。

エリック・カバナ： それは完全に理にかなっています。他の何人かの人たちに、これがどのようにツールに結びついているのかということについて、具体的な質問をするだけでした。例に時間を費やし、実際にどのようにこのようなものを展開するかについてのスクリーンショットを見せていることを知っています。この全体のプロセスに関して、組織でそれがどのくらいの頻度で見られるのか、それとも単に物事が一緒になり、より多くの時間がかかる従来のプロセスをどれくらいの頻度で見ますか？あなたの観点から見ると、Sスタイルのアプローチはどの程度普及していますか？

ロン・フィゼンガ： ますます見ていると思います。おそらく、特に過去15年間で、より迅速な配達を受け入れる必要があることを認識している人々の採用が増えていることを知っています。それで、私はますます多くの組織が機敏な時流に飛び乗るのを見ました。必ずしも完全ではありません。彼らはそれが機能することを証明するためにいくつかのパイロットプロジェクトから始めるかもしれませんが、まだ非常に伝統的なものがいくつかあり、彼らはウォーターフォール法に固執しています。さて、良いニュースは、もちろん、これらの組織でもツールがこれらのタイプの方法論で非常にうまく機能することですが、ボードにジャンプする人がツールボックスのツールを持つようにツールに適応性があります彼らの指先。比較とマージのようなもの、リバースエンジニアリング機能のようなものは、既存のデータソースが何であるかを見ることができるので、実際にインクリメンタルDDLスクリプトを非常に迅速に比較して生成できます。そして、彼らがそれを受け入れ始め、生産性を持つことができるようになると、アジャイルを受け入れる傾向がさらに高まります。

エリック・カバナ： まあ、これは素晴らしいものです、皆さん。チャットウィンドウにスライドへのリンクを投稿したので、チェックしてください。それはあなたのためにそこに少しビットです。これらのWebキャストはすべて後で見ることができます。友達や同僚と気軽に共有してください。ロン、今日は本当にありがとうございました。ショーに参加するのはいつでも楽しいです。この分野の真のエキスパートであり、自分のものを知っていることは明らかです。それで、あなたとIDERA、そしてもちろんDezと私たち自身のRobin Bloorに感謝します。

そしてそれで、私たちはあなたに別れを告げるつもりです、皆さん。ご清聴ありがとうございました。 75分間お付き合いいただきありがとうございます。これは非常に良い兆候です。良いショーの皆さん、次回またお話しします。バイバイ。