取り除く： ホストRebecca Jozwiakは、OSTHUSのEric Little、First San Francisco PartnersのMalcolm Chisholm、およびIDERAのRon Huizengaとデータアーキテクチャソリューションについて説明します。
あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。
レベッカ・ジョズウィアック： ご列席の皆様、こんにちは。2016年のHot Technologiesへようこそ。今日は、間違いなくホットなトピックである「ビジネス駆動型データアーキテクチャの構築」について議論しています。私の名前はRebecca Jozwiakです。今日のウェブキャストのホストになります。ハッシュタグ＃HotTech16でツイートしていますので、すでに参加している場合は、気軽に参加してください。ご質問がある場合は、画面の右下にある[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の関係セットを使用して、参照の問題があります。専門用語は業界によって異なるため、この種のデータ管理のための包括的なソリューションを考え出す場合、あるプロジェクトから別のアプリケーションへの移植はどれほど簡単ですか？それは別の挑戦になる可能性があります。
自動化は重要であり、挑戦でもあります。参照データを手動で処理するのは高価です。手動でマッピングを維持するのは費用がかかります。また、主題の専門家が日々の仕事をやめてデータ辞書を修正し、定義を再更新するなどの作業を行わなければならないのは費用がかかります。複製可能な語彙は本当に多くの価値を示しています。したがって、これらはしばしば組織の外部にある語彙です。たとえば、原油で仕事をしている場合、医薬品、銀行業界、金融、これらの多くの分野で同じように、オープンソースのスペースから借りることができる特定の種類の語彙があります。人々は、人々が使用するために、再利用可能な、一般的な、複製可能な語彙をそこに置いています。
そして、再び、IDERAツールを見て、ある種の標準を使用するという観点から、彼らがこれをどのように扱っているのか興味があります。セマンティクスの世界では、SKOSモデルのように、少なくとも関係よりも広い/狭い関係の標準を提供するものがよく見られます。これらのことはERモデルでは困難な場合がありますが、不可能ではなく、これらのタイプのシステムで処理できる機械とそのリンク。
最後に、業界で見かけるいくつかのセマンティックエンジンと比較したいと思いました。Ronにちょっと尋ねて、おそらくIDERAのシステムがどのようにセマンティックテクノロジーと連携して使用されているかを話してもらいました。トリプルストア、グラフデータベースと統合できますか？外部ソースを使用することは、セマンティックの世界ではこうした種類のものをSPARQLエンドポイントを使用して頻繁に借用できるため、どれほど簡単ですか？ RDFまたはOWLモデルをモデルに直接インポートすることができます-それらを参照してください-たとえば、遺伝子オントロジーまたはタンパク質オントロジーは、独自のガバナンス構造を持つ独自の空間のどこかに住むことができます。自分のモデルにそれを必要とするので、その一部。そして、IDERAがこの問題にどのように取り組んでいるのか知りたいです。内部ですべてを維持する必要がありますか、または他の種類の標準化されたモデルを使用してそれらを取り込む方法がありますか？ここで最後に言及したことは、用語集とメタデータリポジトリを構築するのに実際にどれだけの手作業が必要かということです。
ですから、Ronがこれらの種類のデモを実際に見せてくれることを知っています。しかし、顧客とのコンサルティングでよく見られる問題は、人々が独自の定義やメタデータを書いていると、多くのエラーが発生することです。そのため、つづりの間違い、太った指のエラーが発生します。それは1つのことです。また、ウィキペディアまたは定義に必要な品質とは限らないソースから何かを取得する可能性のある人々を取得します。または、定義は1人の観点からのみであるため、完全ではなく、明確ではありませんガバナンスプロセスの仕組み。もちろん、ガバナンスは、参照データについて話しているときや、これが誰かのマスターデータにどのように適合するか、彼らがメタデータをどのように使用するかについて話しているときは常に、非常に大きな問題です。など。
ですから、これらのトピックのいくつかを公開したかっただけです。これらは、さまざまな種類のコンサルティング契約やさまざまなスペースのビジネス空間で見られるアイテムであり、これらのトピックのいくつかを指摘するために、RonがIDERAで私たちに何を見せてくれるのか本当に興味があります。本当にありがとうございます。
レベッカ・ジョズウィアック： エリック、ありがとうございました。自分の定義やメタデータを書いていると多くのエラーが発生する可能性があるというコメントを本当に気に入っています。ジャーナリズムの世界には「多くの目がほとんど間違いを犯さない」というマントラがあることは知っていますが、実際の用途に当てはまると、クッキージャーの手が多すぎると、壊れたクッキーがたくさん残る傾向があります。
エリックリトル： ええ、そして細菌。
レベッカ・ジョズウィアック： うん。それで先に進み、マルコムチザムに渡します。マルコム、床はあなたのものです。
マルコムチザム： ありがとう、レベッカ。エリックが話していることについて少し見ていきたいと思います。また、「ビジネス駆動型データアーキテクチャに向けて」で、Ronが応答することを気にするかもしれないいくつかの所見に追加したいと思います。 」–ビジネス主導であることは何を意味し、なぜそれが重要なのですか？それとも単なる誇大広告の形式ですか？私はそうは思いません。
1964年頃など、メインフレームコンピューターが実際に企業で利用できるようになってから、今日まで何が起こっているのかを見ると、多くの変更があったことがわかります。そして、これらの変更は、プロセス中心からデータ中心への移行であると要約します。そして、それが今日のビジネス主導のデータアーキテクチャを非常に重要かつ関連性の高いものにしているのです。そして、それは単なる流行語ではなく、絶対に現実的なものだと思います。
しかし、歴史を掘り下げてみると、もう少し感謝することができます。そのため、時間を遡って1960年代に戻り、その後しばらくの間、メインフレームが支配的でした。その後、これらはPCに取って代わられました。PCが登場すると、実際にユーザーに反抗していました。彼らのニーズを満たしていないと思われる集中ITに対する反抗は、十分に機敏ではありませんでした。 PCがリンクされると、すぐに分散コンピューティングが発生しました。そして、インターネットが発生し始め、企業の境界があいまいになりました。これまではなかったデータ交換の観点から、外部とのやり取りが可能になりました。そして今、私たちはクラウドとビッグデータの時代に突入しました。クラウドは本当にインフラストラクチャを共有しているプラットフォームであるため、ビッグデータセンターを運営する必要のあるITをそのまま残しています。クラウドの容量を利用できるようになり、エリックが持っているビッグデータに付随して、雄弁に議論しました。そして全体として、私たちが見るように、技術の変化が起こったとき、それはよりデータ中心になりました、私たちはデータをもっと気にします。インターネットと同様に、データの交換方法。ビッグデータの場合、データ自体の4つ以上のv。
同時に、そしておそらくより重要なことには、ビジネスのユースケースが変化しました。コンピューターが最初に導入されたとき、コンピューターは本や記録などの自動化に使用されていました。そして、元帳などを含む手動プロセスであるものはすべて、本質的に社内でプログラムされました。 80年代には、運用パッケージが利用可能になりました。独自の給与計算を書く必要はもうありませんでした。その結果、多くのIT部門で当時の大幅なダウンサイジングまたは再構築が行われました。しかしその後、データウェアハウスのようなものを備えたビジネスインテリジェンスが登場しました。そのほとんどは90年代のことです。ドットコムのビジネスモデルが続きますが、これはもちろん大きな熱狂でした。次に、MDM。 MDMを使用すると、自動化について考えていないことがわかります。データとしてのデータのキュレーションに焦点を合わせているだけです。次に、データから取得できる値を表す分析。そして、アナリティクス内では、データを中心とするコアビジネスモデルを持つ大成功企業を見ることができます。 Googleはその一部になりますが、ウォルマートもそうだと主張できます。
そして今、ビジネスは本当にデータについて考えています。データから価値を得る方法データがどのようにビジネス、戦略を推進できるか、そして私たちはデータの黄金時代です。それでは、データがアプリケーションのバックエンドから出てくる単なる排気ではなく、ビジネスモデルの中心であると見なされなくなった場合、データアーキテクチャに関してはどうなりますか？さて、それを達成する上で私たちが抱えている問題の一部は、ITがシステム開発ライフサイクルに過去に停滞していることです。これは、ITの初期のプロセス自動化フェーズに迅速に対処しなければならず、プロジェクトも同様です。 ITにとって–これは少し似顔絵ですが、私が言いたいのは、ビジネス主導型のデータアーキテクチャを得るための障壁の一部は、ITの文化を批判的に受け入れていないからです。過ぎ去った時代に由来します。
すべてがプロジェクトです。要件を詳しく教えてください。うまくいかない場合は、要件を教えてくれなかったからです。私たちは自動化されていない手動プロセスやビジネスプロセスの技術的な変換から始めているわけではないため、今日ではデータではうまくいきません。価値を引き出すために。しかし、データ中心のプロジェクトを後援している人は誰もそのデータを本当に理解していません。データの発見、ソースデータの分析が必要です。そして、それはシステム開発とは実際には一致しません-ウォーターフォール、SDLCライフサイクル-私が維持するアジャイルはその一種のより良いバージョンです。
そして、注目されているのはデータではなくテクノロジーと機能です。たとえば、テストフェーズでテストを行うと、通常、機能が動作しますか（ETLなど）、データはテストしません。入ってくるソースデータについての仮定をテストしていません。もしそうなら、おそらくより良い形になり、データウェアハウスプロジェクトを行って上流の変更に苦しみ、ETLを無効にする誰かとして、私はそれを感謝します。そして実際、私たちが見たいのは、継続的な生産データ品質監視の準備段階としてのテストです。そこで、プロセス中心の時代に条件付けられているため、ビジネス主導のデータアーキテクチャを実現するのが難しいという多くの態度をここに持っています。データ中心性への移行が必要です。そしてこれは完全な移行ではありません、あなたは知っています、そこにはやるべき多くのプロセス作業がありますが、必要なときにデータ中心の用語で本当に考えているわけではありませんそれをする義務がありました。
今、ビジネスはデータの価値を認識し、データのロックを解除したいのですが、どのようにそれを行うのでしょうか？では、どのように移行を行うのでしょうか？まあ、我々はデータを開発プロセスの中心に置いています。そして、私たちは情報要件でビジネスをリードさせました。そして、プロジェクトの開始時に既存のソースデータを理解している人はいないことを理解しています。データ構造とデータ自体はそれぞれITと運用を通じてそこに到達したと主張することができるので、それを知っておく必要がありますが、実際にはそうではありません。これはデータ中心の開発です。したがって、データ中心の世界でデータモデリングをどこでどのように行うかを考える際には、データの検出とデータのプロファイリングを行う際に、ユーザーの情報要件を改善するという観点から、フィードバックループを作成する必要があります、ソースデータ分析を予測し、データについて徐々に確実性を高めるようになります。そして今、私はMDMハブやデータウェアハウスのような従来のプロジェクトについて話しています。必ずしもビッグデータプロジェクトではありませんが、これはまだかなり近いものです。したがって、それらのフィードバックループには、データモデラーが含まれます。データモデルを徐々に進めて、ユーザーと対話することで、ソースデータから理解できるように、可能性、利用可能な情報に基づいて情報要件を調整します。データモデルが存在しない、または完全に終了した状態では、データモデルはもうそうではありません。徐々に焦点を当てています。
同様に、より下流では、データが想定しているパラメーターの範囲内にあることを確認するためのデータ品質テストのルールを作成する品質保証があります。入って、エリックは参照データの変更について言及していました。ある種の管理されていない変更の下流の被害者になりたくないので、品質保証ルールをポストプロダクションの継続的なデータ品質監視に組み込むことができます。したがって、データ中心になるかどうかを確認できます。データ中心の開発方法は、機能ベースのSDLCおよびアジャイルとはまったく異なります。そして、ビジネスビューにも注意を払う必要があります。エリックが言っていたことを繰り返しますが、データベースのデータストーリーを定義するデータモデルがありますが、同時に、従来は行われていなかったデータのビジネスモデルである概念モデルが必要です。過去。データモデルはそれをすべて実行できると思うこともありますが、概念ビュー、セマンティクス、データを調べ、ストレージモデルをビジネスに変換する抽象化レイヤーを介してレンダリングする必要があります見る。そして、再び、エリックがセマンティクスの観点から話していたすべてのことは、それを行うために重要になります。そのため、実際には追加のモデリングタスクがあります。私がやったように、データモデラーとしてのランクに出てきた場合、それはまた興味深いことだと思います。
そして最後に、より大きなアーキテクチャもこの新しい現実を反映しなければならないと言いたいと思います。たとえば、従来の顧客MDMは一種です。顧客データをハブに入れて、バックオフィスアプリケーションのデータ品質という点で理解できるようにします。ビジネス戦略の観点からは、あくびのようなものです。しかし、今日では、静的データだけでなく、顧客のトランザクションアプリケーションとの双方向インターフェースを実際に備えた、追加の顧客プロファイルデータを持つ顧客MDMハブを検討しています。はい、彼らはまだバックオフィスをサポートしていますが、今では私たちは顧客のこれらの行動についても知っています。これは構築するのにより高価です。これは構築がより複雑です。しかし、従来の顧客MDMではなく、ビジネス主導型です。あなたは実装するのが簡単なシンプルなデザインに対してビジネスへのオリエンテーションをトレードオフしていますが、ビジネスのために、これは彼らが見たいものです。私たちは本当に新しい時代にあり、ビジネスを推進するデータアーキテクチャに対応しなければならないレベルがいくつかあると思います。物事を行うのは非常にエキサイティングな時間だと思います。
よろしくお願いします、レベッカ。
レベッカ・ジョズウィアック： Malcolmに感謝します。データモデルについてあなたが言ったことがビジネスビューに役立たなければならないことを本当に楽しみました。なぜなら、あなたが言っていることとは違って、ITが長い間手綱を握っていて、それはもはやそうではなく、その文化シフトする必要があります。そして、あなたと100％同意してくれた犬がバックグラウンドにいたと確信しています。そして、それでボールをロンに渡します。私はあなたのデモを見ることを本当に楽しみにしています。ロン、床はあなたのものです。
ロン・フィゼンガ： エリックとマルコムが指摘したように、これは非常に広くて深いトピックであり、私たちが何をするのかについて、私たちはそこに飛び込む前に、いくつかのスライドを見てから少しデモを見ていきます「今日話しているのは、ビジネスドリブンアーキテクチャから考慮して検討する必要がある非常に多くの側面と非常に多くのものがあるため、その表面を削っているだけです。そして、私たちのアプローチは、モデルをコミュニケーションベースとしてだけでなく、他のシステムを有効にするためのレイヤーとして使用できるため、実際にモデルに基づいてモデルから真の価値を引き出すことです。サービス指向のアーキテクチャを使用している場合でも、他のことをしている場合でも、モデルは、その周りのすべてのメタデータとビジネスにあるデータとともに、実際に起こっていることの生命線になります。
しかし、私が話したいのは、マルコムがソリューションの進化方法とそのタイプの歴史のいくつかに触れていたからです。サウンドデータアーキテクチャを持つことがいかに重要であるかを実際に示す1つの方法は、製品管理の役割に就く前に相談していたときによく遭遇するユースケースです。彼らがビジネスの変革を行っているのか、それとも既存のシステムやその種類のものを単に置き換えているのかなど、組織が自分のデータをいかによく理解していないかがすぐに明らかになりました。このような特定のユースケースを採用する場合、あなたがコンサルタントになるか、組織を始めたばかりか、またはあなたの組織は異なる企業を買収することで長年にわたって築かれてきたものであるかどうか、すぐに非常に複雑な環境になり、多数の新しいテクノロジー、レガシーテクノロジー、ERPソリューション、その他すべてを備えています。
モデリングアプローチで実際にできることの1つは、このすべてをどのように理解するのかという質問に答えることです。本当に情報をつなぎ合わせることができるので、ビジネスは私たちが持っている情報を適切に活用できます。そして、それらの環境で私たちがそこにいるのは何ですか？モデルを使用して必要な情報を引き出し、その情報をよりよく理解するにはどうすればよいですか？そして、リレーショナルデータモデルなど、さまざまなものすべてに対する従来のタイプのメタデータがあり、定義やデータディクショナリなど、データタイプやそのタイプのものを見ることに慣れています。しかし、さらに多くの意味を与えるためにキャプチャしたい追加のメタデータはどうでしょうか？たとえば、どのエンティティが実際に参照データオブジェクトになる候補であり、マスターデータ管理オブジェクトとそれらの種類のものであり、それらを結び付ける必要があります。また、情報は組織をどのように流れますか？データは、プロセスの観点から消費される方法だけでなく、当社のビジネスを通じた情報の旅の観点からのデータ系統と、さまざまなシステムまたはデータストアを経由する方法からも流れます。 Iソリューションまたはこれらの種類の物を構築するとき、実際に手元のタスクの正しい情報を消費しています。
そして、非常に重要なのは、これらのすべての利害関係者、特にビジネスの利害関係者がどのようにコラボレーションできるようにするかということです。ビジネスは、一日の終わりに、データを所有します。それらは、エリックが話していた語彙と事物の定義を提供するので、それらすべてを結びつける場所が必要です。そして、その方法は、データモデリングとデータリポジトリアーキテクチャを使用することです。
いくつかのことに触れます。 ER / Studio Enterprise Team Editionについてお話します。主に、データモデリングを行うデータアーキテクチャ製品とその種類について説明しますが、このスイートには他にも多くのコンポーネントがありますので、簡単に触れます。ビジネスアーキテクトの1つのスニペットが表示されます。ここでは、概念モデルを実行できますが、ビジネスプロセスモデルを実行し、それらのプロセスモデルを結び付けて、データモデルにある実際のデータをリンクできます。それは本当に私たちがそのネクタイをまとめるのに役立ちます。ソフトウェアアーキテクトは、UMLモデリングやこれらのタイプのような追加の構成を実行して、私たちが話している他のシステムやプロセスのいくつかにサポートロジックを提供することができます。しかし、非常に重要なこととして、下に移動するとリポジトリとチームサーバーがあります。それについては、同じことの2つの半分として説明します。リポジトリは、ビジネス用語集と用語に関して、モデル化されたすべてのメタデータとすべてのビジネスメタデータを格納する場所です。そして、このリポジトリベースの環境があるので、同じ環境でこれらすべての異なるものをつなぎ合わせてから、実際に技術者だけでなくビジネスマンにも利用できるようにすることができます。そして、それが私たちが本当にコラボレーションを促進し始める方法です。
そして、最後に簡単に説明しますが、これらの環境に足を踏み入れると、そこにあるのはデータベースだけではありません。多数のデータベース、データストア、多くのレガシーアーティファクトが必要になります。たぶん、人々はVisioまたは他の図を使用して、いくつかのことを考え出しました。たぶん彼らは他のモデリングツールとそのタイプのものを持っているでしょう。したがって、MetaWizardでできることは、その情報の一部を実際に抽出し、モデルに取り込み、最新の状態にし、それを使用し、消費し、現在の方法で再び使用することです。現在では、作業モデルのアクティブな部分になっていますが、これは非常に重要です。
私が言ったように、組織に足を踏み入れると、多くの異なるシステムが存在し、ERPソリューションが多く、部門別ソリューションが一致していません。多くの組織は外部で制御および管理されるSaaSソリューションも使用しているため、それらのホストおよびホストのデータベースおよびそれらの種類を制御しませんが、そのデータがどのように見えるかを知る必要があります。もちろん、その周りのメタデータ。また、Malcolmが話し合ったプロジェクトベースのアプローチのために削除されていない多くの古いレガシーシステムもあります。近年、組織がどのようにプロジェクトをスピンアップし、システムやソリューションを置き換えるかは驚くべきことですが、多くの場合、廃止されたソリューションを廃止するのに十分なプロジェクト予算が残っていないので、今は邪魔になっています。そして、私たちは私たちの環境で実際に何を取り除くことができるのか、また今後何が役立つのかを考えなければなりません。そして、それは貧しい廃止措置戦略に結びついています。それは同じことの一部であり小包です。
また、多くの組織がこれらすべての異なるソリューションから構築されているため、多くの場所で多くのデータが移動する多くのポイントツーポイントインターフェイスが見られます。それを合理化し、前に簡単に述べたデータ系統を把握して、正しい情報を提供するために、サービス指向アーキテクチャ、エンタープライズサービスバス、およびそれらの種類の利用など、よりまとまった戦略を立てられるようにする必要がありますビジネス全体で正しく使用するパブリッシュアンドサブスクライブ型のモデルに。そして、もちろん、データウェアハウス、従来のETLを使用したデータマート、または新しいデータレイクの一部を使用しているかどうかにかかわらず、何らかの分析を行う必要があります。すべて同じことです。すべてのデータ、ビッグデータ、リレーショナルデータベースの従来のデータのすべてを管理し、モデル全体で何を扱っているかを把握できるように、すべてのデータをまとめる必要があります。
繰り返しますが、私たちがやろうとしている複雑さは、私たちができるようにしたい多くのステップがあることです。まず第一に、あなたは中に入ると、あなたはその情報の風景がどのように見えるかのブルースを持っていないかもしれません。 ER / Studio Data Architectのようなデータモデリングツールでは、まず、そこにあるデータソースを指して、それらを取り込み、実際にそれらをつなぎ合わせてより代表的なものにするという点で、多くのリバースエンジニアリングを行います。ビジネス全体を表すモデル。重要なのは、これらのモデルをビジネスラインに沿って分解して、ビジネスマンとビジネスアナリストや作業しているその他の利害関係者がより小さなチャンクでそれらを関連付けることができるようにすることです。その上。
命名基準は非常に重要であり、ここではいくつかの異なる方法でそれについて話しています。モデル内の名前の付け方に関する命名基準。論理モデルでは、モデルに適切な命名規則と適切なデータディクショナリが用意されているため、非常に簡単ですが、それから、持ち込むこれらの物理モデルの多くに異なる命名規則があります。リバースエンジニア、非常に頻繁に短縮名と私が話をするそのようなタイプを参照してください。そして、それらをビジネスにとって意味のある意味のある英語の名前に変換して、環境内にあるこれらすべてのデータが何であるかを理解できるようにする必要があります。そして、ユニバーサルマッピングは、それらをつなぎ合わせる方法です。
それに加えて、さらにドキュメントを作成して定義します。ここで、添付ファイルと呼ばれるものを使用してデータをさらに分類し、スライドをいくつか紹介します。そして、ループを閉じて、ビジネス用語を結び付け、それらを異なるモデル成果物にリンクできるビジネス意味を適用したいので、特定のビジネス用語について話しているとき、それがどこにあるかがわかります組織全体のデータに実装されています。そして最後に、私たちはこれらすべてを、多くのコラボレーションとパブリッシング機能を備えたリポジトリベースにする必要があるという事実について話しました。リバースエンジニアリングについては、すぐに説明します。私はすでにあなたにそれの非常に簡単なハイライトを与えました。私たちがそこにもたらすことができるもののいくつかを示すために、実際のデモでそれを示します。
そして、このタイプのシナリオで作成するさまざまなモデルタイプと図のいくつかについてお話したいと思います。明らかに、多くの場合に概念モデルを実行します。あまり時間をかけるつもりはありません。論理モデル、物理モデル、作成できる特殊なモデルについて本当に話したいです。そして、これらをすべて同じモデリングプラットフォームで作成して、それらをつなぎ合わせることができるようにすることが重要です。これには、ディメンションモデルと、新しいデータソースの一部を利用するモデルも含まれます。これは、次に紹介するNoSQLなどです。そして、データ系統モデルはどのように見えますか？そして、そのデータをビジネスプロセスモデルにどのようにつなぎ合わせるのかを次に説明します。
ここでは、非常にすばやく簡単に概要を説明するために、ここでモデリング環境に切り替えます。そして、あなたは今、私の画面を見ることができるはずです。まず、従来のタイプのデータモデルについてのみ説明します。そして、モデルを取り込むときに整理する方法は、モデルを分解できるようにすることです。左側にあるのは、この特定のモデルファイルに論理モデルと物理モデルがあることです。次に、ビジネスの分解に沿って分類できるので、フォルダーが表示されます。水色のモデルは論理モデルで、緑のモデルは物理モデルです。また、ドリルダウンすることもできます。したがって、ER / Studio内で、ビジネスの分解がある場合は、好きなだけ多くのレベルの深さまたはサブモデルに移動でき、低レベルで行った変更は高レベルで自動的に反映されますレベル。したがって、非常に迅速に非常に強力なモデリング環境になります。
この情報をまとめるために開始することが非常に重要であることも指摘しておきたいのは、1つの論理モデルに対応する複数の物理モデルを作成できることです。多くの場合、論理モデルを持っているかもしれませんが、異なるプラットフォームやそのタイプの物理モデルを持っているかもしれません。 1つはそのSQL Serverインスタンス、もう1つはOracleインスタンスかもしれません。同じモデリング環境でこれらすべてを結び付けることができます。繰り返しになりますが、ここで得たのは実際のデータウェアハウスモデルです。このモデルは、同じモデリング環境に置くことも、リポジトリに保存して、さまざまなものにリンクすることもできます。
私が本当にあなたにこれを見せたかったのは、私たちが入るモデルの他のいくつかと他のバリアントです。したがって、このような従来のデータモデルに入ると、列とメタデータとそのタイプの典型的なエンティティを見ることに慣れていますが、これらの新しいNoSQLテクノロジーのいくつかを処理し始めると、その視点は非常に急速に変化します、または一部の人々はまだそれらをビッグデータテクノロジーと呼んでいます。
それでは、環境にもHiveがあるとしましょう。 Hive環境からリバースエンジニアリングを行い、まったく同じモデリングツールを使用してHiveからフォワードエンジニアリングとリバースエンジニアリングを行うことができる場合、少し異なることがわかります。私たちはまだすべてのデータを構成要素と見なしていますが、TDLは異なります。 SQLの表示に慣れている人は、Hive QLになります。これは非常にSQLに似ていますが、さまざまなスクリプト言語での作業を開始できるのと同じツールではありません。したがって、この環境でモデリングし、Hive環境に生成することができますが、同じように重要なことは、私が説明したシナリオでは、すべてをリバースエンジニアリングして意味を理解し、一緒にステッチを開始することもできます。
少し違う別のものを見てみましょう。 MongoDBは、ネイティブでサポートする別のプラットフォームです。そして、ドキュメントストアがあるJSONタイプの環境に入ると、JSONは別の動物であり、その中にリレーショナルモデルに対応しない構成要素があります。 JSONへの問い合わせを開始すると、すぐに埋め込みオブジェクトやオブジェクトの埋め込み配列などの概念を扱うようになり、これらの概念は従来のリレーショナル表記法には存在しません。ここで行ったのは、実際に表記とカタログを同じ環境で処理できるように拡張したことです。
ここの左側を見ると、エンティティやテーブルのようなものを見る代わりに、それらをオブジェクトと呼んでいます。そして、異なる表記法が表示されます。ここでも典型的な種類の参照表記が表示されますが、この特定の図に示しているこれらの青いエンティティは、実際には埋め込みオブジェクトです。そして、異なるカーディナリティを示します。ダイヤモンドのカーディナリティとは、一方のオブジェクトであることを意味しますが、一方のカーディナリティとは、パブリッシャー内でその関係に従う場合、アドレスオブジェクトが埋め込まれていることを意味します。 JSONを調べると、利用者に埋め込まれているオブジェクトの構造とまったく同じであることがわかりましたが、実際にはオブジェクトの配列として埋め込まれています。コネクタ自体だけでなく、実際のエンティティを見ると、後援者の下に住所が表示され、オブジェクトの配列として分類されていることがわかります。あなたはそれをどのように持ち込むことができるかについて非常に説明的な視点を得ることができます。
繰り返しになりますが、ほんの数秒でこれまで見てきたのは、マルチレベルの従来のリレーショナルモデルです。Hiveでも同じことができ、MongoDBや他のビッグデータソースでも同じことができます。まあ。私たちにもできること、そしてこれを非常に迅速に紹介するつもりです。他の異なる分野から物を持ち込むという事実について話しました。データベースからモデルをインポートするか、リバースエンジニアリングすることを想定しますが、外部メタデータからモデルを取り込みます。私たちが持ち込み始めることができるさまざまな種類のすべての非常に迅速な視点を提供するだけです。
ご覧のとおり、モデリング環境にメタデータを実際に取り込むことができるものは無数にあります。 Amazon Redshift、Cassandra、その他の多くのビッグデータプラットフォームなどから始めて、これらの多くがリストされていることを確認できます。これはアルファベット順です。多くのビッグデータソースとそのタイプのものが見られます。また、そのメタデータを実際にもたらすことができる多くの伝統的または古いモデリング環境を見ています。ここを1つずつ見ていくと、それらすべてに時間を費やすつもりはありませんが、モデリングプラットフォームとデータプラットフォームに関して、さまざまなものを取り入れることができます。そして、ここで理解することが非常に重要なことは、データ系統について話し始めるときにできる別の部分です.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でそれらを引き出すために協力したいと考えています。より効率的で自動化されたデータモデリングを可能にします。ビッグデータ、従来のリレーショナルデータ、ドキュメントストアなど、あらゆる種類のデータです。繰り返しますが、さまざまなプラットフォームや他のツールに対応できる強力なフォワードおよびリバースエンジニアリング機能を備えているため、これを達成しました。そして、関係するすべての利害関係者と組織全体で共有および通信することがすべてです。そこで、命名基準を通じて意味を適用します。その後、ビジネス用語集を通じて定義を適用します。そして、データ品質拡張、マスターデータ管理の分類、またはそのデータに適用する他の種類の分類などのメタデータ拡張を使用して、他のすべてのガバナンス機能の分類をさらに行うことができます。そして、特にモデラーと開発者の間のさまざまな利害関係者の聴衆とのビジネスデータオブジェクトとのコミュニケーションをさらに要約し、さらに強化することができます。
繰り返しになりますが、これについて非常に重要なのは、その背後にあるのは、非常に堅牢な変更管理機能を備えた統合リポジトリです。かなり複雑になるため、今日はそれを示す時間はありませんでしたが、リポジトリには非常に堅牢な変更管理機能と監査証跡があります。名前付きリリースを行うことも、名前付きバージョンを行うこともできます。また、変更管理を行うユーザー向けの機能もあります。これをタスクに結び付けることができます。開発者がコードの変更を作業中のタスクやユーザーストーリーにも関連付けるのと同じように、現在、タスクを配置してモデルの変更をタスクに関連付けることができます。
繰り返しますが、これは非常に簡単な概要でした。将来的にこれらのトピックのいくつかを分割することで、より深い会話に参加できるように、あなたの食欲を刺激するのに十分であることを願っています。お時間をいただき、ありがとうございます、レベッカ。
レベッカ・ジョズウィアック： おかげで、ロン、それは素晴らしかったし、聴衆からかなりの数の質問がありますが、私たちのアナリストにあなたが言わなければならないことに歯を沈める機会を与えたいです。エリック、私は先に進むつもりです。おそらく、このスライドまたは別のスライドに対処したい場合は、まず先に進んでみませんか？または他の質問。
エリックリトル： 承知しました。申し訳ありませんが、レベッカの質問は何でしたか？あなたは私に何か具体的な質問をしたいですか…？
レベッカ・ジョズウィアック： 最初にRonに質問がありました。すぐに彼にそれらのいずれか、またはそれらのいくつかをあなたのスライドから、またはあなたが興味を持ちたいと思わせる他の何かに対処するように頼みたいなら？ IDERAのモデリング機能について。
エリックリトル： ええ、それで、ロン、どうですか、あなたが見せていた図は、データベース構築で通常使用するような一般的な種類のエンティティ関係図のように見えますよね？
ロン・フィゼンガ： ええ、一般的に言えば、もちろんドキュメントストア用の拡張タイプと、そのタイプのものもあります。実際には、純粋なリレーショナル表記法とは異なりますが、実際には他の店舗にも表記法を追加しました。
エリックリトル： グラフベースのタイプのモデリングを使用できる方法はありますか？たとえば、統合する方法はありますか？たとえば、トップクアドラント、TopBraidコンポーザーツール、またはProtégéで何かをしたと仮定しますFIBOの金融関係者のように、彼らはセマンティクス、RDFスタッフで多くの作業を行っています。このタイプのエンティティ関係グラフタイプモデリングをこのツールに取り込み、それを利用する方法はありますか。
ロン・フィゼンガ： 実際に、グラフをどのように処理できるかを検討しています。現在、グラフデータベースとそのようなものを明示的に処理しているわけではありませんが、メタデータを拡張するためにそれを行う方法を検討しています。つまり、少なくともXMLを何らかの形で表現して、それを出発点として取り込むことができれば、XMLとそのタイプのものを今すぐ取り込むことができます。しかし、私たちはそれをよりエレガントな方法で探しています。
また、リバースエンジニアリングブリッジのリストも示しましたので、特定のプラットフォーム用にそれらのブリッジの拡張機能を常に探しています。それが理にかなっている場合、これらの新しい構成要素とそこにあるさまざまなプラットフォームの多くを受け入れ始めることは、継続的かつ継続的な努力です。しかし、私たちは間違いなくその最前線にいると言えます。たとえば、MongoDBなどで示したものは、自社の製品で実際にネイティブに行う最初のデータモデリングベンダーです。
エリックリトル： わかったそのため、私があなたに持っていたもう1つの質問は、ガバナンスと維持の観点からでした。例を使用したとき、「従業員」である人の例を示したときのように、給料」と「計画」があります。たとえば、さまざまな種類の人々を管理する方法があります。たとえば、大規模なアーキテクチャを持っているとします。そうすると、大企業と人々はこのツールで物事をまとめ始めます。あなたはここに「従業員」という言葉を持っているグループと、「労働者」という言葉を持っているグループを持っています。 「賃金」
これらの種類の違いをどのように調整し、管理し、管理していますか？グラフの世界でそれをどのように行うか知っているので、同義語リストを使用するか、1つの概念があり、いくつかの属性があると言うか、SKOSモデルでは優先ラベルがあり、私は持っていると言うことができます使用できる多数の代替ラベル。どうやってやるの？
ロン・フィゼンガ： 私たちはいくつかの異なる方法でそれを行います。まず最初に用語について話しましょう。もちろん、私たちがしていることの1つは、定義された用語または認可された用語を持ちたいことです。また、ビジネス用語集の類義語へのリンクも許可しているので、ここで私の用語を言うことができますが、それらの類義語を定義することもできます。
興味深いのは、もちろん、そこに出てきたこれらのさまざまなシステムすべてでこの広大なデータランドスケープを調べ始めると、そこに出て、対応するテーブルとそれらのタイプを変更することはできませんそれはあなたが購入したパッケージであるかもしれないので、その命名標準に対応します。そのため、データベースや何かの変更を制御することはできません。
ここでできることは、用語集の定義を関連付けることができることに加えて、私が話し合った普遍的なマッピング、何をすべきか、そしてある種の推奨されるアプローチを通して、何をレイアウトする包括的な論理モデルを持つことですこれらの異なるビジネスコンセプトはあなたが話していることです。ビジネス用語集の用語をそれらに結び付けると、素晴らしいのは、論理エンティティをそのまま表すこのコンストラクトを取得したことです。その後、その論理エンティティからその論理エンティティのすべての実装へのリンクを開始できます。さまざまなシステム。
次に、必要な場所で、このシステムで「人」が「従業員」と呼ばれることがわかります。ここでの「給与」は、この他のシステムでは「賃金」と呼ばれます。それらが表示されるため、それらを互いにリンクしているため、それらのさまざまな症状がすべて表示されます。
エリックリトル： わかりました、ええ、得ました。その意味で、それはオブジェクト指向のアプローチのようなものだと言っても安全ですか？
ロン・フィゼンガ： 幾分。あなたが言うことができるよりも少し集中的です。つまり、手動でリンクして、すべてを調べて実行するというアプローチを取ることができます。話す機会がなかったことが1つあります-繰り返しますが、多くの機能があるため、Data Architectツール自体に完全な自動化インターフェイスもあります。そして、マクロ機能。これは実際にはツールのプログラミング言語です。ですから、実際にマクロを書くようなことをして、それを外に出して、物事を調べて、あなたのためのリンクを作成することができます。情報のインポートとエクスポートに使用し、モデル自体に基づいてイベントの変更や属性、イベントの追加に使用したり、バッチで実行して実際に外に出て質問したり、実際に異なるコンストラクトに移入したりできます型。そのため、人々が利用できる完全な自動化インターフェースがあります。そして、それらのユニバーサルマッピングを利用することは、そのための非常に強力な方法です。
レベッカ・ジョズウィアック： さて、ロンに感謝し、エリックに感謝します。これらは素晴らしい質問でした。 1時間を少し過ぎてしまっていることはわかっていますが、マルコムにロンの質問を投げかける機会を与えたいと思います。マルコム？
マルコムチザム： ありがとう、レベッカ。それで、ロン、それは非常に面白いです、私はここに多くの能力があると思います。私が非常に興味を持っている分野の1つは、たとえば開発プロジェクトがある場合、これらの機能を使用し、ビジネスアナリスト、データプロファイラー、データ品質アナリストとより連携して作業するデータモデラーをどのように見ているかです、プロジェクトの実際の情報要件に最終的に責任を負うことになるビジネススポンサーと。データモデラーは、私たちが検討している機能により、プロジェクトをより効果的かつ効率的にする方法を本当に知っていますか？
ロン・フィゼンガ： 最初にやらなければならないことの1つは、データモデラーとしてのことだと思います。一部のモデラーを選択するつもりはありませんが、とにかく私は、データモデラーがまさにゲートキーパーのような役割です。どのように機能するかを定義し、すべてが正しいことを確認する警備員です。
今、その側面があります。サウンドデータアーキテクチャとその他すべてを定義していることを確認する必要があります。しかし、より重要なことは、データモデラーとして、そして私がコンサルティングを行っていたときにこれを明らかにしたことは、ファシリテーターにならなければならないということです。
データベースを事前に設計し、生成し、データベースを構築することはもうありません。あなたができることは、これらすべての異なる利害関係者グループと連携できることです。リバースエンジニアリング、情報のインポート、他の人々は、用語集であれ文書であれ、そのようなものすべてに協力します。そして、これをリポジトリに取り込み、リポジトリ内の概念をリンクし、それらの人々と連携するファシリテーターになります。
実際には、タスクの定義やディスカッションスレッド、またはチームサーバーにあるものを定義する場合でも、人々が実際にコラボレーションし、質問をし、最終的な最終製品に到達できるのは、共同作業型の環境です。データアーキテクチャと組織の必要性。そのような答えはありましたか？
マルコムチザム： ええ、私は同意します。ファシリテーションスキルは、データモデル作成者にとって非常に望ましいものだと思います。私たちは常にそれを見るとは限らないことに同意しますが、それは必要だと思いますし、あなたのデータモデリングを行うあなたの隅に滞在する傾向があることをお勧めしますが、あなたは本当に他の利害関係者グループと協力してそこにいなければなりませんまたは、あなたが扱っているデータ環境を理解していないだけで、結果としてモデルが苦しんでいると思います。しかし、それは私の意見です。
ロン・フィゼンガ： また、スライドの最初の方で、タイムリーな方法でソリューションを提供していなかったために、ビジネスがITからどのように離れたのかについての歴史について何かを述べたので興味深いです。
プロダクトマネージャーになる前のその後のコンサルティング業務で、それ以前の2年間に行ったほとんどのプロジェクトがビジネススポンサーであり、実際にそれを推進していたのはデータアーキテクトであったことは非常に興味深いモデラーはITの一部ではありませんでした。私たちはビジネスにスポンサーされたグループの一員であり、他のプロジェクトチームと協力して進行役として働いていました。
マルコムチザム： とても興味深い点だと思います私は、ビジネスが求めている、または多分、私がしていることではなく、プロセスのように考えているビジネス世界の変化を見始めていると思いますが、彼らはまた、データとは何かについて考え始めています私が仕事をしていること、データのニーズは何か、データとして扱っているデータは何か、その視点をサポートするIDERA製品と機能をどこまで手に入れることができるか、そしてビジネスのニーズは、それはまだ少し初期のようなものですが。
ロン・フィゼンガ： 私はあなたに同意します、そして、私たちはそれがますますそのようになるのを見ていると思います。目覚めがありましたが、データの重要性の観点から先ほど触れました。 ITやデータベースの進化の早い段階でデータの重要性を認識し、その後、あなたが言うように、このプロセス管理サイクル全体にやってきました。プロセスは非常に重要です。誤解しないでください。それが起こったとき、データの種類はフォーカスを失います。
そして今、組織はデータが本当に焦点であることを認識しています。データは、ビジネスで行っているすべてのことを表しているので、正確なデータを確保し、意思決定に必要な正しい情報を見つけられるようにする必要があります。なぜなら、すべてが定義されたプロセスから来るわけではないからです。情報の一部は他のものの副産物であり、それを見つけ、それが何を意味するのかを理解し、最終的にそこに表示されるデータを最終的にビジネスをより良くするために使用できる知識に変換できるようにする必要があります。
マルコムチザム： そうです、今私が苦労しているもう1つの分野は、データライフサイクルと呼ばれるものです。つまり、企業を通過するデータサプライチェーンの種類を見ると、データ取得またはデータキャプチャは、データエントリである場合もありますが、同じように、あるデータベンダーから企業の外部からデータを取得しています。
次に、データキャプチャからデータのメンテナンスに進みます。そこでデータを標準化し、必要な場所に発送することを考えています。そして、データの使用、データが存在する実際のポイント、データから価値を引き出します。
昔は、これはすべて個別のスタイルで行われていましたが、今日では、たとえば、分析環境であり、それを超えて、アーカイブではなく、もはやデータを保存するストアであるかもしれませんそれが必要で、最後にパージの種類のプロセスです。このデータライフサイクル全体の管理に適合するデータモデリングをどう思いますか？
ロン・フィゼンガ： それは非常に良い質問であり、今日ここで詳細を掘り下げる時間がなかったのは、私たちが実際に話し始めているのはデータ系統です。したがって、実際にできることは、ツールにデータ系統機能があり、私が言うように、ETLツールから実際にその一部を抽出できますが、系統を描画するだけでマップすることもできます。これらのデータモデルまたはデータベースのいずれかをキャプチャしてモデルに持ち込んだ場合、データ系統図の構造を参照できます。
私たちができることは、あなたが言うように、ソースからターゲットへのデータフローを描き、そのデータが異なるシステムをどのように通過するか、そしてあなたが見つけようとしているもののライフサイクル全体を通して、従業員を連れて行きましょう'データ-それは私が何年も前にやったプロジェクトに基づいて私のお気に入りの一つです。私は、30の異なるシステムに従業員データがある組織で働いていました。私たちがそこでやったこと-そしてRebeccaがデータ系統スライドをポップアップしました-これはここではかなり単純なデータ系統スライドですが、私たちができることはすべてのデータ構造を取り込み、ダイアグラムでそれらを参照し、実際にフロー間の関係を調べ始めることができ、フロー内でこれらの異なるデータエンティティはどのようにリンクされますか？そして、それを超えることもできます。これは、ここに表示されるデータフローまたは系統図の一部です。それを超えたい場合は、このスイートのビジネスアーキテクトの部分もあり、同じことが当てはまります。
データモデリング環境でキャプチャしたデータ構造はすべて、ビジネスモデリングツールで参照できるため、ビジネスモデル図やビジネスプロセス図でも、必要に応じて個々のデータストアを参照できます。データモデリング環境、およびビジネスプロセスモデルのフォルダーでそれらを使用しているときに、それらのCRUDを指定することもできます。その情報をどのように消費または生成するかについても、その後、生成を開始できます。影響および分析レポートや図表などがあります。
私たちが目指していること、そして私たちはすでに多くの機能を持っていますが、私たちが探しているゴールポストのようなものの1つは、私たちがツールを進化させ続けているので、エンドツーエンドの組織データ系統とデータのライフサイクル全体をマッピングできるようになりました。
マルコムチザム： はい。レベッカ、もう1つ許可されますか？
レベッカ・ジョズウィアック： マルコム、もう一回許可します。
マルコムチザム： どうもありがとうございます。データガバナンスとデータモデリングについて考える場合、これら2つのグループを効果的に連携させ、相互に理解させるにはどうすればよいでしょうか？
エリックリトル： おもしろいことですが、それは本当に組織に依存していると思います。以前のコンセプトに戻ると、イニシアチブがビジネス主導であった組織では、私たちはすぐに結びつきました。たとえば、データアーキテクチャチームを率いていましたが、ビジネスユーザーと密接に結びついており、実際にデータガバナンスプログラムの立ち上げを支援していました。繰り返しになりますが、よりコンサルティング的なアプローチですが、実際にはビジネス上の機能です。
そのために本当に必要なのは、ビジネスを本当に理解し、ビジネスユーザーに関連し、その周りのガバナンスプロセスの立ち上げを支援できるデータモデラーとアーキテクトが必要だということです。ビジネスはそれを望んでいますが、一般的に言えば、これらのタイプのプログラムを際立たせるのに役立つ技術知識があります。本当にコラボレーションである必要がありますが、ビジネス所有である必要があります。
マルコムチザム： いいですねありがとうございました。
エリックリトル博士： はい。
レベッカ・ジョズウィアック： さて、どうもありがとう。観客の皆さん、私たちはあなたの質問に答えられなかったのではないかと思いますが、私たちが今日出会った適切なゲストに確実に転送されるようにします。本日はエリック、マルコム、ロンにご招待いただき、誠にありがとうございます。これは素晴らしいものでした。また、今日のIDERA Webキャストを楽しんだ場合、IDERAも参加したい場合、来週の水曜日にホットテクノロジーに参加し、インデックス作成とOracleの課題について議論します。
みなさん、どうもありがとうございました。次回もお会いしましょう。バイバイ。