ビジネス駆動型データアーキテクチャの構築

2024

Techopediaスタッフ、2016年9月28日

まとめ：ホストRebecca Jozwiakは、OSTHUSのEric Little、First San Francisco PartnersのMalcolm Chisholm、およびIDERAのRon Huizengaとデータアーキテクチャソリューションについて説明します。

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

Rebecca Jozwiak：ご列席の皆様 、こんにちは。2016年のHot Technologiesへようこそ。今日は、間違いなくホットなトピックである「ビジネス駆動型データアーキテクチャの構築」について議論しています。私の名前はレベッカジョズウィアックです。今日のウェブキャストのホストになります。ハッシュタグ#HotTech16でツイートしているので、すでにTwitterを使用している場合は、気軽に参加してください。ご質問がある場合は、画面の右下にある[Q&A]ペインに送信してください。回答が確実に届きます。そうでない場合は、お客様に確実にお届けします。

ですから、今日は本当に魅力的なラインナップがあります。今日私たちと一緒にたくさんのヘビーヒッターがいます。 OSTHUSのデータサイエンス担当副社長、エリックリトルがいます。 First San Francisco Partnersの革新的な最高責任者であるMalcolm Chisholm氏は非常にクールなタイトルです。また、IDERAのシニアプロダクトマネージャーであるRon Huizengaがいます。そして、ご存知のように、IDERAは非常に充実したデータ管理およびモデリングソリューションのスイートです。そして今日、彼は彼のソリューションがどのように機能するかについてのデモを提供するつもりです。しかし、その前に、エリックリトル、私はあなたにボールを渡すつもりです。

エリックリトル：わかりました、ありがとう。そこで、ここでいくつかのトピックを取り上げて、ロンの話に少し触れ、これらのトピックのいくつか、Q&Aの舞台を設定することを望んでいます。

ですから、IDERAの仕事に興味を持ったのは、最近の複雑な環境が本当に多くのビジネス価値を推進していることを彼らが正しく指摘していると思うことです。複雑な環境とは、複雑なデータ環境を意味します。そして、技術は本当に急速に動いており、今日のビジネス環境に追いつくのは難しいです。そのため、テクノロジースペースで働く人々は、「ビッグデータをどのように使用すればよいのでしょうか？セマンティクスを組み込むにはどうすればよいですか？この新しいデータを古いデータにリンクするにはどうすればいいのでしょうか？」などのように、最近では多くの人がよく知っているこれらの4つのvのビッグデータに私たちを導いています。時々-私は8〜9個も見ましたが、通常、人々がビッグデータのようなことについて話すとき、またはビッグデータについて話しているときは、通常、企業規模のようなものを見ています。そして人々は、大丈夫、あなたのデータの量について考えます、それは通常焦点です-それはあなたが持っている量です。データの速度は、データを移動できる速さ、クエリまたは回答を取得する速さなどに関係しています。個人的には、その左側は多くの異なるアプローチによって比較的迅速に解決され処理されているものだと思います。しかし右側には、改善のための多くの機能と、本当に前面に出ている多くの新しいテクノロジーがあります。そして、それは本当に3番目の列であるデータの多様性に関係しています。

つまり、今日のほとんどの企業は、構造化データ、半構造化データ、非構造化データに注目しています。画像データはホットトピックになり始めているため、コンピュータービジョンの使用、ピクセルの確認、テキストのスクレイピング、NLP、エンティティ抽出、統計モデルまたはセマンティックからのグラフ情報が得られますモデル、テーブルなどに存在するリレーショナルデータがあります。そのため、すべてのデータとこれらのさまざまな種類のデータをまとめることは大きな課題であり、ガートナーや業界のトレンドに追随している他の人々にこれを見ることができます。

そして、ビッグデータで人々が話す最後のことは、しばしばこのボラシティの概念です。これは、実際にはデータの不確実性、あいまいさです。あなたはあなたのデータが何であるかをどれだけよく知っていますか、そこにあるものをどれだけよく理解しますか、そしてあなたは知っていますか？統計を使用する機能と、知っている可能性のある情報に関する何らかのタイプの情報を使用する機能、またはコンテキストを使用する機能は、価値がある場合があります。そのため、データをどれだけ持っているか、データを移動または取得するのに必要な速さ、企業内にある可能性のあるすべてのタイプのデータ、およびどこにいるのかについて、このようにデータを見ることができます。それが何であるか、それがどのような品質であるかなどです。これには、データを効果的に管理するために、多くの個人間で大規模な調整が必要になります。したがって、データのモデリングは、今日の世界でますます重要になっています。したがって、優れたデータモデルは、エンタープライズアプリケーションで多くの成功を収めています。

私たちが言っていたように、さまざまなソースからのデータソースがあります。これには、多くの異なる種類の統合が本当に必要です。そのため、たとえば、さまざまな種類のデータソースでクエリを実行し、情報を取得できるようにするために、すべてをまとめておくと非常に便利です。しかし、それを行うには、優れたマッピング戦略が必要です。そのため、これらの種類のデータをマッピングし、それらのマッピングを維持することは非常に難しい場合があります。そして、あなたはこの問題を抱えていますが、レガシーデータをこれらすべての新しいデータソースにリンクするにはどうすればよいですか？だから、私はグラフを持っていると仮定し、すべてのリレーショナルデータを取得してグラフに入れますか？通常、それは良い考えではありません。では、人々は現在進行中のこれらの種類のデータモデルをすべて管理できるのでしょうか。分析は、これらのさまざまな種類のデータソースと組み合わせの多くで実際に実行する必要があります。したがって、これから出てくる答え、人々が本当に良いビジネス上の意思決定をするために必要な答えは重要です。

ですから、これは単にテクノロジーのためにテクノロジーを構築することではなく、実際に何をしようとしているのか、それで何ができるのか、どのような分析を実行できるのか、そしてすでに私がしているように能力ですこのことをまとめ、統合することは本当に重要です。そして、これらのタイプの分析の1つは、統合された検索やクエリのようなもので実行されます。それは本当に必須になりつつあります。通常、クエリは複数の種類のソースにスレッド化され、信頼できる情報を取得する必要があります。

多くの場合、特に人々がセマンティックテクノロジーなどの重要なものを検討する重要な要素の1つです。これは、IDERAアプローチでRonが少し語ることを期待しているものです。その生データから、データ層自体からあなたのデータのモデル層？そのため、データレイヤーには、データベース、ドキュメントデータ、スプレッドシートデータ、画像データがあります。製薬業界などの分野にいる場合、膨大な量の科学データを入手できます。それに加えて、人々は通常、そのデータをすばやく統合できるモデルを構築する方法を探します。実際にデータを探しているときは、すべてのデータをモデルレイヤーに引き上げようとはしていませんモデルレイヤーで見ているのは、物事、一般的な語彙、一般的な種類のエンティティと関係、そしてそれが存在するデータに実際に到達する能力の素晴らしい論理表現を提供することです。ですから、それが何であるかを言う必要があり、それがどこにあるかを言う必要があり、それを取得して戻す方法を言わなければなりません。

そのため、これはセマンティックテクノロジを前進させるのに非常に成功したアプローチであり、私は多くの分野で仕事をしています。それで、私がロンに提起したかった質問、およびQ&Aセクションで役立つと思う質問は、これがIDERAプラットフォームによってどのように達成されるかを見ることです。モデル層は実際にデータ層から分離されていますか？より統合されていますか？それはどのように機能し、彼らのアプローチから得られる結果と利点の一部は何ですか？したがって、参照データも本当に重要になりつつあります。そのため、このような種類のデータモデルを使用する場合、フェデレートしてアイテム全体を検索できるようにする場合は、適切な参照データが必要です。しかし、問題は参照データの維持が本当に難しいことです。そのため、多くの場合、標準自体を命名すること自体が難しい課題です。 1つのグループが何かXを呼び出し、1つのグループが何かYを呼び出しますが、このタイプの情報を探しているときにXとYをどのように見つけるかという問題がありますか？データの一部のみを提供するのではなく、関連するすべてのものを提供する必要があります。条件が変更されると同時に、ソフトウェアは非推奨になります。など、その参照データをどのように維持し、維持するのですか？

そして再び、特に分類法や語彙、データディクショナリなどを使用するセマンティックテクノロジーは、これを行うための標準的な空間方法を提供しました。これは非常に堅牢で、特定の種類の標準を利用しますが、データベースコミュニティはこれを実現しましたさまざまな方法で、長い時間も。ここでのキーの1つは、エンティティ関連モデルの使用方法、グラフモデルの使用方法、またはここで参照データを処理する標準的な間隔の方法を実際に提供する何らかのタイプのアプローチの使用方法について考えることです。そしてもちろん、参照データを取得したら、マッピング戦略はさまざまな名前とエンティティを管理する必要があります。そのため、主題の専門家は多くの場合、独自の用語を使用します。

だから、これの挑戦は常に、どのように誰かに情報を提供するが、彼らがそれについて話す方法に関連性を持たせるのですか？したがって、あるグループは何かを見るための1つの方法を持っているかもしれません。たとえば、あなたは薬に取り組んでいる化学者かもしれませんし、同じ薬に取り組んでいる構造生物学者かもしれませんし、同じタイプのエンティティに対して異なる名前を持っているかもしれませんそれはあなたの分野に関係しています。パーソナライズされた用語をまとめる方法を考え出す必要があります。他のアプローチは、人々に自分の用語を落として他の誰かの言葉を使うように強制する必要があるためです。ここでのもう1つのポイントは、多数の同義語の処理が困難になることです。そのため、多くの人のデータには、同じものを参照できる多くの異なる単語があります。多対1の関係セットを使用して、参照の問題があります。専門用語は業界ごとに異なるため、この種のデータ管理のための包括的なソリューションを考え出す場合、あるプロジェクトから別のアプリケーションへの移植性はどれほど簡単ですか？それは別の挑戦になる可能性があります。

自動化は重要であり、挑戦でもあります。参照データを手動で処理するのは高価です。手動でマッピングを維持するのは費用がかかり、主題の専門家が日々の仕事をやめ、データ辞書を修正し、定義を再更新するなどの作業を継続的に行う必要があります。複製可能な語彙は本当に多くの価値を示しています。したがって、これらはしばしば組織の外部にある語彙です。たとえば、原油で仕事をしている場合、医薬品と同じように、銀行業界と同じように、オープンソースのスペースから借りることができる特定の種類の語彙があります。人々は、再利用可能な、一般的な、複製可能な語彙を人々が使用するためにそこに置いています。

そして、再び、IDERAツールを見て、ある種の標準の使用に関して、彼らがこれをどのように扱っているのか興味があります。セマンティクスの世界では、SKOSモデルのように、少なくとも関係よりも広い/狭い関係の標準を提供するものがよく見られます。これらのことはERモデルでは困難な場合がありますが、不可能ではなく、これらのタイプのシステムで処理できる機械とそのリンク。

ですから、最後に、業界で見かけるセマンティックエンジンと比較したいと思いました。そして、Ronにちょっと尋ねて、おそらくIDERAのシステムがどのようにセマンティックテクノロジーと連携して使用されているのかを話してもらいました。トリプルストア、グラフデータベースと統合できますか？外部ソースを使用することは、セマンティックの世界ではこうした種類のものをSPARQLエンドポイントを使用して頻繁に借用できるため、どれほど簡単ですか？ RDFまたはOWLモデルをモデルに直接インポートすることができます-それらを参照してください-たとえば、遺伝子オントロジーまたはタンパク質オントロジーは、独自のガバナンス構造を持つ独自の空間のどこかに住むことができます。自分のモデルにそれを必要とするので、その一部。そして、IDERAがこの問題にどのように取り組んでいるかを知りたいです。内部ですべてを維持する必要がありますか、または他の種類の標準化されたモデルを使用してそれらを取り込む方法がありますか？ここで最後に言及したことは、用語集とメタデータリポジトリを構築するのに実際にどれだけの手作業が必要かということです。

ですから、Ronがこの種の事柄に関するいくつかのデモを見せてくれることを知っています。しかし、顧客とのコンサルティングでよく見られる問題は、人々が独自の定義やメタデータを書いていると、多くのエラーが発生することです。そのため、つづりの間違いや太った指のエラーが発生します。また、ウィキペディアまたは定義に必要な品質とは限らないソースから何かを取得する可能性のある人々を取得します。または、定義は1人の観点からのみであるため、完全ではなく、明確ではありませんガバナンスプロセスの仕組み。もちろん、ガバナンスは、参照データについて話しているときや、これが誰かのマスターデータにどのように適合するか、彼らがメタデータをどのように使用するかについて話しているときは常に、非常に大きな問題です。など。

ですから、これらのトピックのいくつかを公開したかっただけです。これらは、さまざまな種類のコンサルティング契約やさまざまなスペースのビジネス空間で見られるアイテムであり、これらのトピックのいくつかを指摘するために、RonがIDERAで私たちに何を見せてくれるのか本当に興味があります。本当にありがとうございます。

Rebecca Jozwiak：ありがとう、エリック、そして私はあなたのコメントが本当に好きです。人々が自分の定義やメタデータを書いていると多くのエラーが発生する可能性があるからです。ジャーナリズムの世界では、「多くの目がほとんど間違いを犯さない」というマントラがあることを知っていますが、実際の用途に当てはまると、クッキージャーの手が多すぎると、壊れたクッキーがたくさん残る傾向がありますよね？

エリックリトル：ええ、そして細菌。

Rebecca Jozwiak：ええ。それで私は先に進み、マルコム・チザムにそれを渡すつもりです。マルコム、床はあなたのものです。

Malcolm Chisholm：ありがとう、レベッカ。エリックが話していることについて少し見ていきたいと思います。また、「ビジネス駆動型データアーキテクチャに向けて」で、Ronが応答することを気にするかもしれないいくつかの所見に追加したいと思います。」–ビジネス主導であることは何を意味し、なぜそれが重要なのですか？それとも単なる誇大広告の形式ですか？私はそうは思いません。

メインフレームコンピューターが企業（たとえば1964年頃）で実際に利用できるようになってから、今日までの状況を見ると、多くの変更があったことがわかります。そして、これらの変更は、プロセス中心からデータ中心への移行であると要約します。そして、それが今日のビジネス主導のデータアーキテクチャを非常に重要かつ関連性の高いものにしているのです。そして、それは単なる流行語ではなく、絶対に現実的なものだと思います。

しかし、歴史を掘り下げてみると、もう少し感謝することができます。そのため、時間を遡って1960年代に戻り、その後しばらくの間、メインフレームが支配的でした。その後、これらはPCに取って代わり、PCが登場したときに実際にユーザーに反乱を起こしました。彼らのニーズを満たしていないと考えられた集中型ITに対する反乱は、十分に機敏ではありませんでした。 PCがリンクされると、すぐに分散コンピューティングが発生しました。そして、インターネットが発生し始め、企業の境界があいまいになりました。これまではなかったデータ交換の観点から、外部とのやり取りが可能になりました。そして今、私たちはクラウドとビッグデータの時代に突入しました。クラウドは本当にインフラストラクチャを共有しているプラットフォームであるため、ビッグデータセンターを運営する必要のあるITをそのまま残しています。クラウドの容量を利用できるようになり、エリックが持っているビッグデータに付随して、雄弁に議論しました。そして全体として、私たちが見るように、技術の変化が起こったとき、それはよりデータ中心になりました、私たちはデータをもっと気にします。インターネットと同様に、データの交換方法。ビッグデータでは、データ自体の4つ以上のv。

同時に、そしておそらくより重要なことには、ビジネスのユースケースが変化しました。コンピューターが最初に導入されたとき、コンピューターは本や記録などの自動化に使用されていました。そして、元帳などを含む手動プロセスであるものはすべて、本質的に社内でプログラムされました。 80年代には、運用パッケージが利用可能になりました。独自の給与計算を書く必要はもうありませんでした。その結果、多くのIT部門で当時の大幅なダウンサイジングまたは再構築が行われました。しかしその後、データウェアハウスのようなものを備えたビジネスインテリジェンスが登場しました。そのほとんどは90年代のことです。ドットコムのビジネスモデルが続きますが、これはもちろん大きな熱狂でした。次に、MDM。 MDMを使用すると、自動化について考えていないことがわかります。データとしてデータをキュレートすることに焦点を合わせているだけです。次に、データから取得できる値を表す分析。そして、アナリティクス内では、データを中心とするコアビジネスモデルを持つ大成功企業を見ることができます。グーグル、ツイッター、フェイスブックもその一部ですが、ウォルマートもそうだと主張できます。

そして今、ビジネスは本当にデータについて考えています。データから価値を得る方法データがどのようにビジネス、戦略を推進できるか、そして私たちはデータの黄金時代です。それでは、データがアプリケーションのバックエンドから出てくる単なる排気ではなく、ビジネスモデルの中心であると見なされなくなった場合、データアーキテクチャに関して何が起きているのでしょうか？さて、それを達成する上で私たちが抱えている問題の一部は、ITがシステム開発ライフサイクルに過去に停滞していることです。これは、ITの初期のプロセス自動化フェーズに迅速に対処しなければならず、プロジェクトも同様です。 ITにとって–これは少し似顔絵ですが、私が言いたいのは、ビジネス主導型のデータアーキテクチャを得るための障壁の一部は、ITの文化を批判的に受け入れていないからです。過ぎ去った時代に由来します。

すべてがプロジェクトです。要件を詳しく教えてください。うまくいかない場合は、要件を教えてくれなかったからです。私たちは自動化されていない手動プロセスやビジネスプロセスの技術的な変換から始めているわけではないため、今日ではデータではうまくいきません。価値を引き出すために。しかし、データ中心のプロジェクトを後援している人は誰もそのデータを本当に理解していません。データの発見、ソースデータの分析が必要です。そして、それはシステム開発とは実際には一致しません-ウォーターフォール、SDLCライフサイクル-私が維持するアジャイルは、それの一種のより良いバージョンです。

そして、注目されているのはデータではなくテクノロジーと機能です。たとえば、テストフェーズでテストを実行する場合、通常、機能は動作しますか、ETLの場合、データはテストしていません。入ってくるソースデータについての仮定をテストしていません。もしそうなら、おそらくより良い形になり、データウェアハウスプロジェクトを行い、上流の変更に苦しみ、ETLを破壊する誰かとして、私はそれを感謝します。そして実際、私たちが見たいのは、継続的な生産データ品質監視の準備段階としてのテストです。そのため、プロセス中心の時代に条件付けられているため、ビジネス駆動型のデータアーキテクチャを実現するのが難しいという多くの態度があります。データ中心性への移行が必要です。そしてこれは完全な移行ではありません、あなたは知っています、そこにはやるべき多くのプロセス作業がありますが、必要なときにデータ中心の用語で本当に考えているわけではありませんそれをする義務がありました。

今、ビジネスはデータの価値を認識し、データのロックを解除したいのですが、どのようにそれを行うのでしょうか？では、どのように移行を行うのでしょうか？まあ、我々はデータを開発プロセスの中心に置いています。そして、私たちは情報要件でビジネスをリードさせました。そして、プロジェクトの開始時に既存のソースデータを理解している人はいないことを理解しています。データ構造とデータ自体はそれぞれITと運用を通じてそこに到達したと主張できるので、それを知っておく必要がありますが、実際にはそうではありません。これはデータ中心の開発です。そのため、データ中心の世界でデータモデリングをどこでどのように行うかを考える際に、データの検出とデータのプロファイリングを行う際に、情報要件を改善するという観点からユーザーにフィードバックループを持たなければなりません、ソースデータ分析を予測します。データが徐々に確実になるにつれて、そして今、私はMDMハブやデータウェアハウスのようなより伝統的なプロジェクトについて話しています。必ずしもビッグデータプロジェクトではありませんが、これはまだかなり近いものです。したがって、それらのフィードバックループには、データモデラーが含まれます。データモデルを徐々に進めて、ユーザーと対話することで、ソースデータから理解できるように、可能性、利用可能な情報に基づいて情報要件を調整します。データモデルが存在しない、または完全に終了した状態では、データモデルはもうそうではありません。徐々に焦点を当てています。

同様に、その下流には品質保証があり、データが想定しているパラメータ内にあることを確認するためのデータ品質テストのルールを作成します。入って、エリックは参照データの変更について言及していました。あなたは、そうであるように、その分野のある種の管理されていない変更の下流の犠牲者になりたくないので、品質保証ルールは、ポストプロダクション、継続的なデータ品質監視に入ることができます。したがって、データ中心になるかどうかを確認できます。データ中心の開発方法は、機能ベースのSDLCおよびアジャイルとはまったく異なります。そして、ビジネスビューにも注意を払う必要があります。データベースのデータストーリーの青写真を定義するデータモデルがありますが、それと同時に、従来は行われていなかったデータのビジネスビューが必要です。過去。データモデルはそれをすべて実行できると思うこともありますが、概念ビュー、セマンティクス、データを調べ、ストレージモデルをビジネスに変換する抽象化レイヤーを介してレンダリングする必要があります見る。そして、再び、エリックがセマンティクスの観点から話していたすべてのことは、それを行うために重要になります。そのため、実際には追加のモデリングタスクがあります。私がやったように、データモデラーとしてのランクに出てきた場合、それは興味深いことだと思います。

そして最後に、より大きなアーキテクチャもこの新しい現実を反映しなければならないと言いたいと思います。たとえば、従来の顧客MDMは、大丈夫です。顧客データをハブに入れて、バックオフィスアプリケーションの実際のデータ品質の観点から理解できるようにします。ビジネス戦略の観点からは、あくびのようなものです。しかし、今日では、静的データだけでなく、顧客のトランザクションアプリケーションとの双方向インターフェースを実際に備えた、追加の顧客プロファイルデータを持つ顧客MDMハブを検討しています。はい、彼らはまだバックオフィスをサポートしていますが、今では私たちは顧客のこれらの行動についても知っています。これは構築するのにより高価です。これは構築がより複雑です。しかし、従来の顧客MDMではない方法でビジネス主導です。あなたは実装するのが簡単なシンプルなデザインに対してビジネスへのオリエンテーションをトレードオフしていますが、ビジネスのために、これは彼らが見たいものです。私たちは本当に新しい時代にあり、ビジネスを推進するデータアーキテクチャに対応しなければならないレベルがいくつかあると思います。そして、物事を行うのは非常にエキサイティングな時期だと思います。

よろしくお願いします、レベッカ。

Rebecca Jozwiak：ありがとう、Malcolm。データモデルについてあなたが言ったことをビジネスビューに取り入れなければならないことを本当に楽しみました。なぜなら、あなたが言っていたこととは違って、ITが長い間手綱を握っていたからです。文化を変える必要があること。そして、私はあなたと100％同意した犬がバックグラウンドにいたと確信しています。そして、それでボールをロンに渡します。私はあなたのデモを見ることを本当に楽しみにしています。ロン、床はあなたのものです。

Ron Huizenga：ありがとうございます。その前に、いくつかのスライドを見てから少しデモを見ていきます。EricとMalcolmが指摘したように、これは非常に広範で深いトピックです。今日私たちが話していることは、その表面を削っているだけです。なぜなら、非常に多くの側面と非常に多くのことがビジネス駆動型アーキテクチャから考慮して検討する必要があるからです。そして、私たちのアプローチは、モデルをコミュニケーションベースとしてだけでなく、他のシステムを有効にするためのレイヤーとして使用できるため、実際にモデルに基づいてモデルから真の価値を引き出すことです。サービス指向アーキテクチャを実行している場合でも、他のことを実行している場合でも、モデルは、その周りのすべてのメタデータとビジネス内にあるデータとともに、実際に起こっていることの生命線になります。

しかし、私が話したいのは、マルコムがソリューションの進化方法とそのタイプの歴史のいくつかに触れていたからです。サウンドデータアーキテクチャを持つことがいかに重要であるかを実際に示す1つの方法は、製品管理の役割に就く前に相談していたときによく遭遇するユースケースです。彼らがビジネスの変革を行っているのか、それとも既存のシステムやその種類のものを単に置き換えているのかなど、組織が自分のデータをいかによく理解していないかがすぐに明らかになりました。このような特定のユースケースを採用する場合、あなたがコンサルタントになるか、組織を始めたばかりか、またはあなたの組織は異なる企業を買収することで長年にわたって築かれてきたものであるかどうか、すぐに非常に複雑な環境になり、多数の新しいテクノロジー、レガシーテクノロジー、ERPソリューション、その他すべてを備えています。

モデリングアプローチで実際にできることの1つは、このすべてをどのように理解するのかという質問に答えることです。本当に情報をつなぎ合わせることができるので、ビジネスは私たちが持っている情報を適切に活用できます。そして、それらの環境で私たちがそこにいるのは何ですか？モデルを使用して必要な情報を引き出し、その情報をよりよく理解するにはどうすればよいですか？そして、リレーショナルデータモデルなど、さまざまなものすべてに対する従来のタイプのメタデータがあり、定義やデータディクショナリなど、データタイプやそのタイプのようなものを見ることに慣れています。しかし、さらに多くの意味を与えるためにキャプチャしたい追加のメタデータはどうでしょうか？たとえば、どのエンティティが実際に参照データオブジェクトになる候補であり、マスターデータ管理オブジェクトとそれらの種類のものであり、それらを結び付ける必要があります。また、情報は組織をどのように流れますか？データは、プロセスの観点から消費される方法だけでなく、当社のビジネスを通じた情報の旅の観点からのデータ系統と、さまざまなシステムまたはデータストアを経由する方法からも流れます。 Iソリューションまたはこれらの種類の物を構築するとき、実際に手元のタスクの正しい情報を消費しています。

そして、非常に重要なのは、これらのすべての利害関係者、特にビジネスの利害関係者がどのようにコラボレーションできるようにするかということです。ビジネスは、一日の終わりに、データを所有します。それらは、エリックが話していた語彙と事物の定義を提供するので、それらすべてを結びつける場所が必要です。そして、その方法は、データモデリングとデータリポジトリアーキテクチャを使用することです。

いくつかのことに触れます。 ER / Studio Enterprise Team Editionについてお話します。主に、データモデリング製品とそのタイプのことを行うデータアーキテクチャ製品についてお話しますが、このスイートには他にも多くのコンポーネントがありますので、簡単に触れます。ビジネスアーキテクトの1つのスニペットが表示されます。ここでは、概念モデルを実行できますが、ビジネスプロセスモデルを実行し、それらのプロセスモデルを結び付けて、データモデルにある実際のデータをリンクすることもできます。それは本当に私たちがそのネクタイをまとめるのに役立ちます。 Software Architectを使用すると、UMLモデリングなどの追加の構成要素を実行して、これから説明する他のシステムやプロセスの一部にサポートロジックを提供できます。しかし、非常に重要なことに、下に移動するとリポジトリとチームサーバーがあります。これについては、同じことの2つの半分として説明します。リポジトリは、ビジネス用語集と用語に関して、モデル化されたすべてのメタデータとすべてのビジネスメタデータを格納する場所です。そして、このリポジトリベースの環境があるので、同じ環境でこれらすべての異なるものをつなぎ合わせ、実際に技術者だけでなくビジネスマンにも利用できるようにすることができます。そして、それが私たちが本当にコラボレーションを推進し始めた方法です。

そして、最後に簡単に説明するのは、これらの環境に足を踏み入れたときに、そこにあるのはデータベースだけではないということです。多数のデータベース、データストアが必要になります。また、レガシーアーティファクトも多くなります。たぶん、人々はVisioまたは他の図を使用して、いくつかのことを計画しました。たぶん、彼らは他のモデリングツールとそのタイプのものを持っていた。したがって、MetaWizardでできることは、その情報の一部を実際に抽出し、モデルに取り込み、最新の状態にし、それを使用し、消費できるようにすることです。現在では、作業モデルのアクティブな部分になっていますが、これは非常に重要です。

私が言ったように、組織に足を踏み入れると、多くの異なるシステムが存在し、ERPソリューションが多く、部門別ソリューションが一致していません。多くの組織は外部で制御および管理されるSaaSソリューションも使用しているため、それらのホストおよびホストのデータベースおよびそれらの種類を制御しませんが、そのデータがどのように見えるかを知る必要があります。もちろん、その周りのメタデータ。また、Malcolmが話していたプロジェクトベースのアプローチのために削除されていない多くの古いレガシーシステムもあります。近年、組織がどのようにプロジェクトをスピンアップし、システムまたはソリューションを置き換えるかは驚くべきことですが、多くの場合、廃止されたソリューションを廃止するのに十分なプロジェクト予算が残されていないため、今は邪魔になっています。そして、私たちの環境で実際に何を取り除くことができるか、また今後何が役立つかを理解する必要があります。そして、それは貧しい廃止措置戦略に結びついています。それは同じことの一部であり小包です。

また、多くの組織がこれらすべての異なるソリューションから構築されているため、多くの場所で多くのデータが移動する多くのポイントツーポイントインターフェイスが見られます。それを合理化し、前に簡単に述べたデータ系統を把握して、正しい情報を提供するために、サービス指向アーキテクチャ、エンタープライズサービスバス、およびそれらのタイプの利用など、よりまとまった戦略を立てられるようにする必要があります。ビジネス全体で正しく使用するパブリッシュアンドサブスクライブ型のモデルに。そして、もちろん、データウェアハウス、従来のETLを使用したデータマート、または新しいデータレイクの一部を使用しているかどうかにかかわらず、何らかの分析を行う必要があります。すべて同じことです。すべてのデータ、ビッグデータ、リレーショナルデータベースの従来のデータ、すべてのデータをまとめて管理し、モデル全体で何を扱っているかを把握する必要があります。

繰り返しますが、私たちがやろうとしている複雑さは、私たちができるようにしたい多くのステップがあることです。まず第一に、あなたは中に入って、その情報の風景がどのように見えるかの青写真を持っていないかもしれません。 ER / Studio Data Architectのようなデータモデリングツールでは、まず、そこにあるデータソースを指して、それらを取り込み、実際にそれらをつなぎ合わせてより代表的なものにするという点で、多くのリバースエンジニアリングを行います。ビジネス全体を表すモデル。重要なことは、ビジネスモデルもビジネスラインに沿って分解できるようにして、ビジネススタッフとビジネスアナリストやその他の利害関係者が関係することができる小さなチャンクでモデルに関連付けることができるようにすることです。その上。

命名基準は非常に重要であり、ここではいくつかの異なる方法でそれについて話しています。モデル内の名前の付け方に関する命名基準。論理モデルでは、モデルに適切な命名規則と適切なデータディクショナリが用意されているため、非常に簡単ですが、持ち込んでいるこれらの物理モデルの多くに異なる命名規則があります。リバースエンジニア、非常に頻繁に短縮名と私が話をするそのようなタイプを参照してください。そして、それらをビジネスにとって意味のある意味のある英語の名前に変換して、環境内にあるこれらすべてのデータが何であるかを理解できるようにする必要があります。そして、ユニバーサルマッピングは、それらをつなぎ合わせる方法です。

それに加えて、さらにドキュメントを作成して定義します。ここで、添付ファイルと呼ばれるものでデータをさらに分類することができます。ここで、スライドをいくつか紹介します。そして、ループを閉じて、ビジネス用語を結び付け、それらを異なるモデル成果物にリンクできるビジネス意味を適用したいので、特定のビジネス用語について話しているとき、それがどこにあるかを知っています組織全体のデータに実装されています。そして最後に、私たちはこれらすべてが、多くのコラボレーションとパブリッシング機能を備えたリポジトリベースである必要があるという事実について話しました。リバースエンジニアリングについては、かなり迅速に説明します。私はすでにあなたにそれの非常に簡単なハイライトを与えました。私たちがそこにもたらすことができるもののいくつかを示すために、実際のデモでそれを示します。

そして、このタイプのシナリオで作成するさまざまなモデルタイプと図のいくつかについてお話したいと思います。明らかに、多くのインスタンスで概念モデルを実行します。私はそれに多くの時間を費やすつもりはありません。論理モデル、物理モデル、作成できる特殊なモデルについて本当に話したいです。そして、これらをすべて同じモデリングプラットフォームで作成して、それらをつなぎ合わせることができるようにすることが重要です。これには、ディメンションモデルと、新しいデータソースの一部（これから説明するNoSQLなど）を利用するモデルも含まれます。そして、データ系統モデルはどのように見えますか？そして、そのデータをビジネスプロセスモデルにどのようにつなぎ合わせるのかを次に説明します。

ここでは、高度で迅速な概要を示すために、ここでモデリング環境に切り替えます。そして、あなたは今、私の画面を見ることができるはずです。まず、従来のタイプのデータモデルについてのみ説明します。そして、モデルを取り込むときに整理する方法は、モデルを分解できるようにすることです。左側にあるのは、この特定のモデルファイルに論理モデルと物理モデルがあることです。次は、ビジネスの分解に沿って分解できるため、フォルダが表示される理由です。水色のモデルは論理モデルで、緑のモデルは物理モデルです。また、ドリルダウンすることもできます。したがって、ER / Studio内で、ビジネスの分解がある場合は、好きなだけ多くのレベルの深さまたはサブモデルに移動でき、低レベルで行った変更は高レベルで自動的に反映されますレベル。したがって、非常に迅速に非常に強力なモデリング環境になります。

この情報をまとめるために開始することが非常に重要であることも指摘したいのは、1つの論理モデルに対応する複数の物理モデルを作成できることです。多くの場合、論理モデルを持っているかもしれませんが、異なるプラットフォームやそのタイプの物理モデルを持っているかもしれません。たぶん、それのSQL Serverインスタンスかもしれませんし、たぶん別のOracleインスタンスかもしれません。同じモデリング環境でこれらすべてを結び付けることができます。繰り返しになりますが、ここで得たのは、同じモデリング環境にある実際のデータウェアハウスモデルであるか、リポジトリに格納してさまざまなものにリンクすることができます。

私が本当にあなたにこれを見せたかったのは、私たちが入るモデルの他のいくつかと他のバリアントです。したがって、このような従来のデータモデルに入ると、列とメタデータとそのタイプの典型的なエンティティを見ることに慣れていますが、これらの新しいNoSQLテクノロジーのいくつかを処理し始めると、その視点は非常に急速に変化します、または一部の人々はまだそれらをビッグデータテクノロジーと呼んでいます。

それでは、環境にもHiveがあるとしましょう。 Hive環境からリバースエンジニアリングを行い、まったく同じモデリングツールを使用してHiveからフォワードエンジニアリングとリバースエンジニアリングを行うことができる場合、少し異なることがわかります。私たちはまだすべてのデータを構成要素と見なしていますが、TDLは異なります。 SQLの表示に慣れている人は、Hive QLになります。HiveQLは非常にSQLに似ていますが、同じツールを使用すれば、異なるスクリプト言語で作業を開始できます。したがって、この環境でモデリングし、Hive環境に生成することができますが、同じように重要なことは、私が説明したシナリオでは、すべてをリバースエンジニアリングして意味を理解し、一緒にステッチを開始することもできます。

少し違う別のものを見てみましょう。 MongoDBは、ネイティブでサポートする別のプラットフォームです。また、ドキュメントストアがあるJSONタイプの環境に入ると、JSONは別の動物であり、その中にリレーショナルモデルに対応しない構成要素があります。 JSONへの問い合わせを開始すると、埋め込みオブジェクトやオブジェクトの埋め込み配列などの概念にすぐに対処し始め、それらの概念は従来のリレーショナル表記法には存在しません。ここで行ったことは、実際に表記とカタログを拡張して、同じ環境でそれを処理できるようにしたことです。

ここの左側を見ると、エンティティやテーブルのようなものを見る代わりに、それらをオブジェクトと呼んでいます。そして、異なる表記法が表示されます。参照表記の典型的なタイプはここでも見られますが、この特定の図に示しているこれらの青いエンティティは、実際には埋め込みオブジェクトです。そして、異なるカーディナリティを示します。ダイヤモンドのカーディナリティとは、それが一方のオブジェクトであることを意味しますが、一方のカーディナリティとは、パブリッシャー内に、その関係に従う場合、埋め込みアドレスオブジェクトがあることを意味します。 JSONを調べると、利用者に埋め込まれているオブジェクトの構造とまったく同じであることがわかりましたが、実際にはオブジェクトの配列として埋め込まれています。コネクタ自体だけでなく、実際のエンティティを見ると、オブジェクトの配列として分類されている後援者の下にアドレスが表示されていることがわかります。あなたはそれをどのように持ち込むことができるかについて非常に説明的な視点を得ることができます。

繰り返しになりますが、ほんの数秒でこれまで見てきたのは、マルチレベルの従来のリレーショナルモデルです。Hiveでも同じことができ、MongoDBや他のビッグデータソースでも同じことができます。上手。私たちにもできること、そしてこれを非常に迅速に紹介するつもりです。他のさまざまな分野から物を持ち込むという事実について話しました。データベースからモデルをインポートするか、リバースエンジニアリングするかを想定しますが、外部メタデータからモデルを取り込みます。私たちが持ち込み始めることができるさまざまな種類のすべての非常に迅速な視点を提供するだけです。

ご覧のとおり、モデリング環境にメタデータを実際に取り込むことができるものは無数にあります。 Amazon Redshift、Cassandra、その他の多くのビッグデータプラットフォームなどから始めて、これらの多くがリストされていることを確認できます。これはアルファベット順です。たくさんのビッグデータソースとそのタイプのものを見ています。また、実際にそのメタデータをもたらすことができる多くの伝統的または古いモデリング環境を見ています。ここで説明しますが、それらのすべてに時間を費やすつもりはありませんが、モデリングプラットフォームとデータプラットフォームに関して、さまざまなものを取り入れることができます。そして、ここで理解することが非常に重要なことは、データ系統について話し始めるときにできる別の部分です.Enterprise Team Editionでは、TalendまたはSQL Server Information Servicesマッピングのようなものであっても、ETLソースを調べることもできます実際にそれを取り込み、データ系統図も開始し、それらの変換で何が起こっているのかを描きます。これらのさまざまなブリッジのうち、実際にはEnterprise Team Edition製品の一部である130以上のブリッジがあるため、すべてのアーティファクトを1つのモデリング環境に非常に迅速にまとめることができます。

最後に重要なことですが、データウェアハウジングや任意のタイプの分析を行っている場合、他のタイプのコンストラクトが必要であるという事実を見失うことはありません。ファクトテーブルがあり、ディメンションとこれらのタイプの事柄があるディメンションモデルのようなことを実行できるようにする必要があります。私がお見せしたいことの1つは、メタデータの拡張機能を使用して、ディメンションの種類やその他すべてを分類できるようにすることです。たとえば、ここでディメンションデータタブを見ると、たとえばこれらのいずれかで、表示されているモデルパターンに基づいて実際に自動的に検出し、ディメンションと見なすかどうかの出発点を提供しますファクトテーブル。しかし、それを超えてできることは、ディメンション内で、データウェアハウジングタイプの環境でデータを分類するために使用できるさまざまなタイプのディメンションもあります。非常に強力な機能なので、これを完全に統合します。

スライドに戻る前に、今すぐデモ環境にいるので、これにジャンプして、他のいくつかのことを紹介します。最近ER / Studio Data Architectに追加したことの1つは、状況に遭遇したことです。これは、プロジェクトで作業しているときの非常に一般的なユースケースです。モデル作成者は、テーブルとエンティティ、およびそのタイプの観点から考える傾向があります。これは非常に単純なデータモデルですが、開発者やビジネスアナリストやビジネスユーザーでさえも、それらを異なるオブジェクトやビジネスコンセプトと考えるかもしれないいくつかの基本的な概念を表しています。これまでこれらを分類することは非常に困難でしたが、2016リリースでER / Studio Enterprise Team Editionで実際に行ったことは、ビジネスデータオブジェクトと呼ばれる概念を持っていることです。それにより、エンティティまたはテーブルのグループを真のビジネスオブジェクトにカプセル化できるようになります。

たとえば、この新しいビューでここにあるのは、Purchase OrderヘッダーとOrder Lineがまとめられ、オブジェクトとしてカプセル化されているため、データを永続化するときの作業単位と考えます、それらをまとめて、さまざまな視聴者に関連付けることが非常に簡単になりました。モデリング環境全体で再利用可能です。これらは真のオブジェクトであり、単なる描画構造ではありませんが、モデリングの観点から実際に通信しているときに選択的に折りたたみまたは展開できるため、特定の利害関係者との対話の要約ビューを作成できるという追加の利点もあります。もちろん、より多くの技術的な視聴者のためにここで見ているように、より詳細なビューを保持することもできます。本当に良いコミュニケーション手段を提供してくれます。今私たちが見ているのは、複数の異なるモデルタイプを組み合わせ、ビジネスデータオブジェクトの概念でそれらを強化していることです。そして、これらのタイプのものに実際にもっと意味を適用する方法と、それらをつなぎ合わせる方法についてお話します全体的な環境。

ここに戻って自分のWebExを見つけようとしているので、そうすることができます。そして、ホットテックのスライドに戻ります。モデルのデモンストレーション自体で既にこれらのスライドを見ているので、ここでいくつかのスライドを早送りします。命名標準について非常に早く話したいです。さまざまな命名基準を適用および実施したいと考えています。私たちがやりたいのは、レポジトリに名前付け標準テンプレートを実際に保存して、基本的に単語やフレーズ、さらには略語を通してその意味を構築し、それらを意味のある英語の単語に結びつける機能を持っていることです。ビジネス用語、それぞれの略語を使用します。順序、ケースを指定し、プレフィックスとサフィックスを追加できます。これの典型的な使用例は、通常、人々が論理モデルを構築し、その後、実際に略語やその他すべてを使用している可能性のある物理モデルを作成する場合です。

美しいことは、リバースエンジニアリングした物理データベースの一部にそれらの命名基準が何であるかを伝えることができれば、同じように強力であり、逆にさらに強力であるということです。単語、および英語のフレーズにそれらを後方にもたらす。実際に、データがどのように見えるかについて適切な名前を導き出すことができます。私が言うように、典型的なユースケースは、論理ストアから物理ストアへと進み、データストアとそのタイプのものをマップすることです。右側のスクリーンショットを見ると、ソース名に省略名が含まれていることがわかります。命名標準テンプレートを適用すると、実際にはより多くのフルネームがあります。また、使用する命名標準テンプレートに応じて、必要に応じてスペースなどを入れることができます。見た目は自由に変えられますが、モデルに取り入れたいと思っています。何が呼ばれているのかを知っている場合にのみ、実際に定義を付け始めることができます。なぜなら、それが何であるかを知らない限り、どのように意味を適用できるのでしょうか？

良いことは、あらゆる種類のことをしているときに実際にこれを呼び出すことができるということです。リバースエンジニアリングについて話しましたが、リバースエンジニアリングを行っているときに、実際に同時に命名標準テンプレートを呼び出すことができます。ウィザードの一連のステップで、できることは、慣習がわかっていれば、物理データベースをリバースエンジニアリングでき、それをモデリング環境の物理モデルとして戻すことができるということです。また、これらの命名規則を適用します。そのため、環境内の対応する論理モデルで、英語のような名前の表現が何であるかがわかります。また、それをXMLスキーマ生成と組み合わせて、モデルを取得し、SOAフレームワークまたはそのタイプのことを行うかどうかを略語でプッシュすることもできるため、異なる命名規則をプッシュすることもできます。モデル自体に実際に保存したこと。これにより、非常に強力な機能が多数提供されます。

繰り返しますが、ここにテンプレートがあった場合の外観の例を示します。これは実際に、命名標準の規則で、「従業員」にEMP、「給与」にSAL、「計画」にPLNがあることを示しています。また、モデルを構築して物を入れるときに、それらをインタラクティブに実行するように適用することもできます。この略語を使用していて、エンティティ名に「従業員給料プラン」と入力すると、命名標準テンプレートで動作しますここで定義しましたが、エンティティを作成しているときにEMP_SAL_PLNを与え、対応する物理名をすぐに与えました。

繰り返しますが、私たちがデザインやフォワードエンジニアリングを行う場合にも非常に適しています。私たちには非常にユニークなコンセプトがあり、ここからこれらの環境を実際に統合し始めます。そして、それはユニバーサルマッピングと呼ばれます。これらのすべてのモデルを環境に持ち込み、できることを実行したら、これらの命名規則を適用し、簡単に見つけられると仮定して、ERでユニバーサルマッピングと呼ばれる構造を使用できます/スタジオ。モデル間でエンティティをリンクできます。私たちが「顧客」を見ればどこでも-私たちはおそらく多くの異なるシステムと多くの異なるデータベースで「顧客」を持っているでしょう-私はそれらをすべて一緒にリンクし始めることができます。他のモデルで顧客の症状がどこにあるかを見ることができます。そして、それを表すモデルレイヤーがあるので、それをデータソースに結び付けて、それらがどのデータベースに存在するかについての使用された問い合わせにも引き渡すことができます。これにより、これらすべてを非常に密接に結び付けることができます。

ビジネスデータオブジェクトを紹介しました。また、添付ファイルと呼ばれるメタデータ拡張機能についても非常に簡単に説明します。それにより、モデルオブジェクトの追加のメタデータを作成できるようになります。多くの場合、これらのタイプのプロパティを設定して、データガバナンスとデータ品質の観点からさまざまなことを実行し、マスターデータ管理とデータ保持ポリシーを支援します。基本的な考え方は、これらの分類を作成し、テーブルレベル、列レベル、それらの種類のものを必要な場所に添付できることです。もちろん、最も一般的なユースケースは、エンティティがテーブルであり、マスターデータオブジェクト、参照テーブル、トランザクションテーブルとは何かを定義できるということです。データ品質の観点から、ビジネスにとって重要度の観点から分類を行うことができるため、データクレンジングの取り組みとそのようなことを優先できます。

しばしば見落とされがちなのは、組織内のさまざまな種類のデータの保持ポリシーとは何ですか？これらをセットアップし、モデリング環境ともちろんリポジトリのさまざまなタイプの情報アーティファクトに実際に添付できます。美しさは、これらの添付ファイルがデータディクショナリにあるため、環境でエンタープライズデータディクショナリを使用しているときに、複数のモデルに添付できることです。定義する必要があるのは一度だけで、環境内のさまざまなモデルで繰り返し利用できます。これは簡単なスクリーンショットであり、添付ファイルを作成する時期、添付するすべてのピースを実際に指定できることを示しています。そして、この例は実際には値のリストであるため、値が入っている場合は、値のリストから選択することができ、選択するもののモデリング環境で多くの制御ができ、デフォルトを設定することさえできます値は、値が選択されない場合です。そこで多くの力があります。彼らはデータ辞書に住んでいます。

この画面のさらに下に表示したいものに加えて、添付ファイルが上部に表示され、その下にデータセキュリティ情報が表示されます。実際に、環境内のさまざまな情報にもデータセキュリティポリシーを適用できます。さまざまなコンプライアンスマッピング、データセキュリティ分類については、すぐに生成して使用を開始できる多くのボックスが出荷されていますが、独自のコンプライアンスマッピングと標準も定義できます。 HIPAAや他のイニシアチブを行っているかどうか。そして、この非常に豊富なメタデータのセットを環境で実際に構築し始めることができます。

そして、用語集と用語–これはビジネスの意味が結び付けられている場所です。用語集と用語は、用語集を追い出すための出発点として組織が使用することが多いデータ辞書があります。多くの場合、非常に技術的です。したがって、必要に応じて用語集を作成するための出発点としてそれらを使用できますが、ビジネスにこれらを所有してもらいたいのです。チームサーバー環境で行ったことは、人々がビジネス定義を作成できるようにし、モデリング環境でも対応するさまざまなモデルアーティファクトにリンクできることです。また、以前に説明したポイント、つまり、入力する人が多いほど、ヒューマンエラーの可能性が高くなることも認識しています。用語集構造で行うことは、用語集の階層をサポートすることです。そのため、組織内で異なる用語集タイプまたは異なるタイプのものを使用できますが、同様に重要なのは、これらのソースの一部をすでに持っている場合です定義された用語とすべてを使用して、CSVインポートを実際に実行して、これらをモデリング環境に取り込み、チームサーバーまたは用語集にも取り込み、そこからリンクを開始できます。そして、何かが変更されるたびに、定義やその他すべての点で、前の画像と後の画像が何であるかについての完全な監査証跡があり、非常に近い将来に見られるものは承認ワークフローでもあります誰がそれを担当するか、委員会や個人による承認、およびそのようなことを実際に管理して、今後のガバナンスプロセスをさらに強固なものにすることができます。

これは、チームサーバー用語集にこれらの用語集の用語がある場合にも役立ちます。これは、ここで取り上げたモデル自体のエンティティを編集する例です。リンクされた用語があるかもしれませんが、ここでエンティティにあるもののメモまたは説明に表示される用語集にある単語がある場合、それは自動的に明るいハイパーリンクの色で表示され、それらの上にマウスを置くと、ビジネス用語集の定義も実際に見ることができます。情報自体を使用しているときに、用語集の用語がすべて揃っているため、さらに豊富な情報が提供されます。それは本当に経験を豊かにし、私たちが取り組んでいるすべてのものに意味を適用するのに役立ちます。

それで、再び、それは非常に速いフライバイでした。明らかに、さまざまな部分を掘り下げていくためにこれに数日を費やすことができますが、これは表面上の非常に速いフライバイです。私たちが本当にやろうとしているのは、これらの複雑なデータ環境がどのように見えるかを理解することです。これらすべてのデータアーティファクトの可視性を向上させ、ER / Studioでそれらを引き出すために協力したいと考えています。より効率的で自動化されたデータモデリングを可能にします。そして、ビッグデータ、従来のリレーショナルデータ、ドキュメントストアなど、私たちが話しているすべての種類のデータです。繰り返しますが、さまざまなプラットフォームや他のツールに対応できる強力なフォワードおよびリバースエンジニアリング機能を備えているため、これを達成しました。そして、関係するすべての利害関係者と組織全体で共有および通信することがすべてです。ここで、命名基準を通じて意味を適用します。その後、ビジネス用語集を通じて定義を適用します。そして、データ品質拡張、マスターデータ管理の分類、またはそのデータに適用する他の種類の分類などのメタデータ拡張を使用して、他のすべてのガバナンス機能の分類をさらに行うことができます。そして、特にモデラーと開発者の間のさまざまな利害関係者の聴衆とのビジネスデータオブジェクトとのコミュニケーションをさらに要約し、さらに強化することができます。

繰り返しますが、これについて非常に重要なことは、その背後にあるのは、非常に堅牢な変更管理機能を備えた統合リポジトリです。かなり複雑になるため、今日はそれを示す時間はありませんでしたが、リポジトリには非常に堅牢な変更管理機能と監査証跡があります。名前付きリリースを行うことも、名前付きバージョンを行うこともできます。また、変更管理を行うユーザー向けの機能もあります。これをタスクに結び付けることができます。開発者がコードの変更を作業中のタスクやユーザーストーリーにも関連付けるのと同じように、今日、タスクを配置してモデルの変更をタスクに関連付けることができます。

繰り返しますが、これは非常に簡単な概要でした。将来的にこれらのトピックのいくつかを分割することで、より深い会話に参加できるように、あなたの食欲を刺激するのに十分であることを願っています。お時間をいただき、ありがとうございます、レベッカ。

Rebecca Jozwiak：ありがとう、Ron、それは素晴らしかったし、聴衆からかなりの数の質問がありますが、アナリストに彼らの歯をあなたが言わなければならないことに集中させる機会を与えたいです。エリック、私は先に進むつもりです。おそらく、このスライドまたは別のスライドに対処したい場合は、まず先に進んでみませんか？または他の質問。

エリックリトル：もちろん。申し訳ありませんが、レベッカの質問は何でしたか？あなたは私に何か具体的な質問をしたいですか…？

Rebecca Jozwiak：最初にRonに質問がありました。すぐに彼にそれらのいずれか、またはそれらのいくつかをあなたのスライドから、またはあなたが興味を持ちたいと思わせる他の何かに対処するように頼みたいなら？ IDERAのモデリング機能について。

エリック・リトル：ええ、それで、ロン、どうですか、あなたが示していた図は、データベース構築で通常使用するような一般的な種類のエンティティ関係図のように見えますよね？

Ron Huizenga：ええ、一般的に言えば、もちろん、ドキュメントストア用の拡張タイプとそのタイプのものもあります。実際には、単なる純粋なリレーショナル表記法とは異なりますが、実際には他のストアにも追加表記法を追加しました。

エリック・リトル：グラフベースのモデリングを使用できる方法はありますか？たとえば、統合する方法はありますか？たとえば、トップクアドラント、TopBraidコンポーザーツール、または何かをしたとしましょうProtégéで、またはFIBOの金融関係者のように、彼らはセマンティクス、RDFの分野で多くの作業を行っています。このタイプのエンティティ関係グラフタイプモデリングをこのツールに取り込み、利用する方法はありますかそれ？

Ron Huizenga：実際にグラフを処理する方法を検討しています。現在、グラフデータベースとそのタイプのことを明示的に扱っているわけではありませんが、メタデータを拡張するためにそれを行う方法を検討しています。つまり、少なくともXMLを何らかの形で表現して、それを出発点として取り込むことができれば、XMLとそのタイプのものを今すぐ取り込むことができます。しかし、私たちはそれをよりエレガントな方法で探しています。

また、リバースエンジニアリングブリッジのリストも紹介しました。そのため、特定のプラットフォーム用にそれらのブリッジの拡張機能を常に探しています。それが理にかなっている場合、これらの新しい構成要素とそこにあるさまざまなプラットフォームの多くを受け入れ始めることは、継続的かつ継続的な努力です。しかし、私たちは間違いなくその最前線にいると言えます。たとえば、MongoDBなどで示したものは、自社の製品で実際にネイティブに行う最初のデータモデリングベンダーです。

エリックリトル：わかりました。そのため、私があなたに持っていたもう1つの質問は、ガバナンスと維持の観点からでした。例を使用したとき、「従業員」である人の例を示したときのように、給料」と「計画」があります。たとえば、さまざまな種類の人々を管理する方法があります。たとえば、大規模なアーキテクチャを持っているとします。そうすると、大企業と人々はこのツールで物事をまとめ始めます。あなたはここに「従業員」という言葉を持っているグループと、「労働者」という言葉を持っているグループを持っています。「賃金」

これらの種類の違いをどのように調整し、管理し、管理していますか？グラフの世界でそれをどのように行うか知っているので、同義語リストを使用するか、1つの概念があり、いくつかの属性があると言うか、SKOSモデルでは優先ラベルがあり、私は持っていると言うことができます使用できる多数の代替ラベル。どうやってやるの？

Ron Huizenga：いくつかの異なる方法でそれを行います。最初に用語について説明しましょう。もちろん、私たちがしていることの1つは、定義された用語または認可された用語を持ちたいことです。また、ビジネス用語集の同義語へのリンクも許可しているので、ここで私の用語を言うことができますが、それらのすべての同義語を定義することもできます。

興味深いのは、もちろん、そこに出てきたこれらのさまざまなシステムすべてでこの広大なデータランドスケープを調べ始めると、そこに出て、対応するテーブルとそれらのタイプを変更することはできませんそれはあなたが購入したパッケージであるかもしれないので、その命名標準に対応します。そのため、データベースや何かの変更を制御することはできません。

ここでできることは、用語集の定義を関連付けることができることに加えて、私が話し合った普遍的なマッピング、何をすべきか、そしてある種の推奨されるアプローチを通して、何をレイアウトする包括的な論理モデルを持つことですこれらの異なるビジネスコンセプトはあなたが話していることです。ビジネス用語集の用語をそれらに結び付けると、素晴らしいのは、論理エンティティをそのまま表すこのコンストラクトを取得したことです。その後、その論理エンティティからその論理エンティティのすべての実装へのリンクを開始できます。さまざまなシステム。

次に、必要な場所で、このシステムで「人」が「従業員」と呼ばれることがわかります。ここでの「給与」は、この他のシステムでは「賃金」と呼ばれます。あなたはそれを見るでしょうから、あなたはそれらを一緒にリンクしたので、それらのすべての異なる症状を見るでしょう。

エリックリトル：わかりました、ええ、わかりました。その意味で、それはオブジェクト指向のアプローチの一部のようなものだと言っても安全ですか？

ロン・フィゼンガ：やや。それはあなたが言うことができるよりも少し集中的です。つまり、手動でリンクして、すべてを調べて実行するというアプローチを取ることができます。話をする機会がなかったのは、やはり多くの機能があるためです。DataArchitectツール自体に完全な自動化インターフェイスもあります。そして、マクロ機能。これは実際にはツールのプログラミング言語です。ですから、実際にマクロを書くようなことをして、それを外に出して、物事を調べて、あなたのためのリンクを作成することができます。情報のインポートとエクスポートに使用し、モデル自体に基づいてイベントの変更や属性、イベントの追加に使用したり、バッチで実行して実際に外に出て質問したり、実際に異なるコンストラクトに移入したりできますモデル。したがって、人々が同様に利用できる完全な自動化インターフェースがあります。そして、それらのユニバーサルマッピングを利用することは、そのための非常に強力な方法です。

Rebecca Jozwiak：わかりました、ロン、ありがとう、エリック。これらは素晴らしい質問でした。私たちは1時間を少し過ぎて実行していることを知っていますが、マルコムにRonのやり方に疑問を投げかける機会を与えたいと思います。マルコム？

Malcolm Chisholm：ありがとう、レベッカ。だから、ロン、それは非常に面白いです、私はここに多くの能力があると思います。私が非常に興味を持っている分野の1つは、たとえば開発プロジェクトがある場合、これらの機能を使用し、ビジネスアナリスト、データプロファイラー、データ品質アナリストとより連携して作業するデータモデラーをどのように見ているかです、プロジェクトの実際の情報要件に最終的に責任を負うことになるビジネススポンサーと。データモデラーは、私たちが見ている機能により、プロジェクトをより効果的かつ効率的にする方法を本当に知っていますか？

Ron Huizenga：まず最初にやらなければならないことの1つは、データモデラーとしてのことだと思います。データモデラーは、実際にはゲートキーパーのような役割です。それがどのように機能するかを定義し、すべてが正しいことを確認するガードです。

現在、その側面があります。サウンドデータアーキテクチャとその他すべてを定義していることを確認する必要があります。しかし、より重要なことは、データモデラーとして、そして私がコンサルティングを行っていたときにこれを明らかにしたことは、ファシリテーターにならなければならないということです。

データベースを事前に設計し、生成し、データベースを構築することはもうありません。あなたができることは、これらすべての異なる利害関係者グループと連携できること、リバースエンジニアリング、情報のインポート、他の人々は、用語集であれ文書であれ、そのようなものすべてに協力します。そして、これをリポジトリーに取り込み、リポジトリー内の概念をリンクし、それらの人々と連携するファシリテーターになります。

実際には、タスクの定義やディスカッションスレッド、またはチームサーバーにあるそのようなタイプであっても、人々が実際にコラボレーションし、質問し、最終的な最終製品に到達できるのは、共同作業型の環境です。データアーキテクチャと組織の必要性。そのような答えはありましたか？

Malcolm Chisholm：ええ、私は同意します。ファシリテーションスキルは、データモデル作成者にとって非常に望ましいものだと思います。私たちは常にそれを見るとは限らないことに同意しますが、私はそれが必要だと思いますし、データモデリングを行うためにあなたの隅にとどまる傾向があることをお勧めしますが、本当に他の利害関係者グループと協力する必要がありますまたは、あなたが扱っているデータ環境を理解していないだけで、結果としてモデルが苦しんでいると思います。しかし、それは私の意見です。

Ron Huizenga：スライドで、ビジネスがITからタイムリーに提供されていなかったためにビジネスがITからどのように離れたのかについての歴史について何かお話ししたので、興味深いです。

プロダクトマネージャーになる前のその後のコンサルティング業務で、それ以前の2年間に行ったほとんどのプロジェクトがビジネススポンサーであり、実際にそれを推進していたのはデータアーキテクトであったことは非常に興味深いモデラーはITの一部ではありませんでした。私たちはビジネスにスポンサーされたグループの一員であり、他のプロジェクトチームと協力して進行役として働いていました。

Malcolm Chisholm：それはとても興味深い点だと思います。私は、ビジネスが求めている、または多分、私がしていることではなく、プロセスのように考えているビジネス世界の変化を見始めていると思いますが、彼らはまた、データとは何かについて考え始めています私が仕事をしていること、データのニーズは何か、データとして扱っているデータは何か、その視点をサポートするIDERA製品と機能をどこまで手に入れることができるか、そしてビジネスのニーズは、それはまだ少し初期のようなものですが。

Ron Huizenga：私はあなたに同意します、そして、私たちはそれがますますそのようになるのを見ていると思います。目覚めがありましたが、データの重要性の観点から先ほど触れました。 ITやデータベースの進化の早い段階でデータの重要性を認識し、その後、あなたが言うように、このプロセス管理サイクル全体にやってきました。プロセスは非常に重要です。誤解しないでください。それが起こったとき、データの種類はフォーカスを失います。

そして今、組織はデータが本当に焦点であることを認識しています。データは、ビジネスで行っているすべてのことを表しているので、正確なデータを確保し、意思決定に必要な正しい情報を見つけることができるようにする必要があります。なぜなら、すべてが定義されたプロセスから来るわけではないからです。情報の一部は他のものの副産物であり、それを見つけ、それが何を意味するのかを理解し、最終的にそこに表示されるデータを最終的にビジネスをより良くするために使用できる知識に変換できるようにする必要があります。

Malcolm Chisholm：そうですね、今私が苦労しているもう1つの分野は、データライフサイクルと呼ぶものです。つまり、企業を通過するデータサプライチェーンの種類を見ると、データ取得またはデータキャプチャ（これはデータエントリである可能性がありますが、同様にそうである可能性があります）は、データベンダーから企業の外部からデータを取得しています。

そして、データキャプチャからデータメンテナンスに進み、このデータを標準化し、必要な場所に出荷することを考えています。そして、データの使用、データが存在する実際のポイント、データから価値を引き出します。

昔は、これはすべて個別のスタイルで行われていましたが、今日では、たとえば、分析環境であり、それを超えて、アーカイブではなく、もはやデータを保存するストアであるかもしれませんそれが必要で、最後にパージの種類のプロセスです。このデータライフサイクル全体の管理に適合するデータモデリングをどう思いますか？

Ron Huizenga：それはとても良い質問です。今日ここで詳細を掘り下げる時間がなかったのは、データの系統です。したがって、実際にできることは、ツールにデータ系統機能があり、私が言うように、ETLツールから実際にその一部を抽出できますが、系統を描画するだけでマップすることもできます。これらのデータモデルまたはデータベースをキャプチャしてモデルに持ち込んだ場合、データ系統図の構造を参照できます。

私たちができることは、あなたが言うように、ソースからターゲットへのデータフローを描き、そのデータが異なるシステムをどのように通過するか、そしてあなたが見つけようとしているもののライフサイクル全体を通して、従業員を連れて行きましょう'データ-それは私が何年も前にやったプロジェクトに基づいて私のお気に入りの一つです。私は、30の異なるシステムに従業員データがある組織で働いていました。私たちがそこでやったこと-そしてRebeccaがデータ系統スライドをポップアップしました-これはここではかなり単純なデータ系統スライドですが、私たちができることはすべてのデータ構造を取り込み、ダイアグラムでそれらを参照し、実際にフロー間の関係を調べ始めることができ、フロー内でこれらの異なるデータエンティティはどのようにリンクされますか？そして、それを超えることもできます。これは、ここに表示されるデータフローまたは系統図の一部です。それを超えたい場合は、このスイートのビジネスアーキテクト部分もあり、同じことが当てはまります。

データモデリング環境でキャプチャしたデータ構造はすべて、ビジネスモデリングツールで参照できるため、ビジネスモデル図やビジネスプロセス図でも、必要に応じて個々のデータストアを参照できます。データモデリング環境、およびビジネスプロセスモデルのフォルダーでそれらを使用しているときに、それらのCRUDを指定することもできます。その情報をどのように消費または生成するかについても、その後、生成を開始できます。影響および分析レポートや図表などがあります。

私たちが目指していること、そして私たちはすでに多くの機能を持っていますが、私たちが探しているゴールポストのようなものの1つは、私たちがツールを進化させ続けているので、エンドツーエンドの組織データ系統とデータのライフサイクル全体をマッピングできるようになりました。

マルコムチザム：わかりました。レベッカ、もう1つ許可されますか？

Rebecca Jozwiak：マルコム、もう1つ許可します。

Malcolm Chisholm：ありがとうございます。データガバナンスとデータモデリングについて考える場合、これら2つのグループを効果的に連携させ、相互に理解させるにはどうすればよいでしょうか？

エリックリトル：それは興味深いです。組織に本当に依存していると思います。イニシアチブがビジネス主導であった組織では、私たちはすぐに結ばれました。たとえば、データアーキテクチャをリードしていました。チームですが、ビジネスユーザーと密接に結びついており、実際にデータガバナンスプログラムの立ち上げを支援していました。繰り返しますが、より多くのコンサルティング的アプローチですが、それは本当にビジネス上の機能です。

そのために本当に必要なのは、ビジネスを本当に理解し、ビジネスユーザーに関連し、その周りのガバナンスプロセスの立ち上げを支援できるデータモデラーとアーキテクトが必要だということです。ビジネスはそれを望んでいますが、一般的に言えば、これらの種類のプログラムを際立たせるのに役立つ技術知識があります。本当にコラボレーションである必要がありますが、ビジネス所有である必要があります。

Malcolm Chisholm：わかりました、それは素晴らしい。ありがとうございました。

エリックリトル博士：わかりました。

Rebecca Jozwiak：わかりました、ありがとう。観客の皆さん、私たちはあなたの質問に答えなかったのではないかと思いますが、私たちが今日ラインにいた適切なゲストに転送されることを確認します。本日はエリック、マルコム、ロンにご招待いただき、誠にありがとうございます。これは素晴らしいものでした。また、今日のIDERAウェブキャストを楽しんでいるなら、参加したいならIDERAも来週のHot Technologiesに参加し、インデックス作成とOracleの課題について話し合うので、もう1つの興味深いトピックです。

みなさん、どうもありがとうございました。次回もお会いしましょう。バイバイ。