前回の 投稿 では、NIST主催のモデル・ベース・エンタープライズ・サミットへの最近の旅行についてお話ししました。 私は私の質問の多く答えたいくつかの議論をしました。しかし、議論はさらに多くを生み出しました。 ある会話は、標準とそれがMBEの重要な側面であった方法についての方向性に私たちを取りました。 これは私が標準の将来について考えさせられ、私はあなたと私の考えのいくつかを共有したいと思います。
私は標準が好きか嫌いかは言えません。 しかし、私は、エンドアプリケーションやプラットフォームが反対側にあるかどうかにかかわらず、シームレスに情報を交換するという考え方が本当に好きです。
私が覚えている限り、事実上すべての業界で情報交換が話題になっています。 標準の本体(IGES、STEP など)または事実上のベンダー(DWG、PCFなど)によって定義されるさまざまな標準フォーマットを使用することは、情報を交換する方法の1つでした。 しかし、私たちは皆、多くの理由で標準を使用することにいくつかの制限に遭遇したと思います。
私が現在標準で見ている主な問題は、彼らが非常に速く反復しないことです。 技術的に彼らがはるかに速く繰り返すことができない理由はありませんが、「台所に多くの料理人がいる」ので、今日のペースの速い環境で必要なものよりも時間がかかるようです。
プラットフォーム化は、標準の将来にどのような影響を与えるか
私が受け取ったすべての会話と情報は、標準を中心に展開し、私は標準の将来について考えさせられました。 多くのソフトウェアベンダーがプラットフォームを作成する方向が、標準の未来を大きく形作ることができると思います。
プラットフォーム化の推進とは何ですか?
私たちはついに、ベンダーがクライアントが単一の組織が提供する製品のみを使用することを期待する方法はないと認めているところです。 この考え方の変化は、多くのソフトウェアプロバイダがプラットフォームを作成している理由の原動力の1つです。 また、プラットフォームテクノロジを基盤として構築されたソリューションを提供するサードパーティ企業 のより良いエコシステムを構築するなど、プラットフォームを作成する理由や利点も数多くあります。
プラットフォームのオープン性アーキテクチャ
ソフトウェア ソリューション プロバイダーがプラットフォームを成功させるには、少なくともある程度開いている必要があります。 このオープンプラットフォームは、他の企業(競争を含む)がエンドユーザーにツールや製品を提供するためにプラットフォームを拡張することを可能にします。 クラウド ソリューションでは、この例は数多くありますが、オンプレミス ソリューションでも同様に普及しています。
これらのプラットフォームの開放性は、要件や標準の必要性を大きく変える可能性があると思います。
プラットフォーム化の前に、私たちが使用していたシステムは閉鎖されていたため、誰もがこれらのシステムから情報を引き出すのは非常に困難でした。 これには、3rd パーティプロバイダーとクローズドプラットフォームの競争が、情報交換のための何らかの標準を使用する必要がありました。 これらの標準ファイルは、クローズドソースシステムから生成され、次に、宛先システムへの入力として使用されます。
プラットフォーム化により、送信先システムは他のシステム (競合システムの場合もある) から自動的に情報を取得でき、ファイルは必要ありません。 ワークフローレシピに従う必要はありません ([エクスポート標準ファイル]-[転送ファイル]->[標準ファイルのインポート] )。 ユーザーの介入なしに競合他社からシームレスに情報を引き出すことができるため、ソリューション プロバイダーにとって、これがどのように大きなメリットとなるか想像できます。 これは、複雑さとレシピワークフローの任意のタイプの使用を減らします。
では、この効果は標準にどのように影響するのでしょうか。 まあ、私はそれが2つの可能な方法で行うと思います:
1. オープンプラットフォームが提供するAPIを使用してネイティブ情報にアクセスする
オープンプラットフォームを簡単に拡張するには、データの読み取りと書き込みを行うためのAPIを提供する必要が生じるでしょう。 これにより、競合他社のシステムまたはサードパーティ製 ソフトウェア会社がこの API を利用してデータを読み取り、ソース プラットフォームから宛先のネイティブ形式に情報を変換することができます。 これは、2 つのネイティブ形式間で情報が交換されるため、標準を使用する必要がないことを意味します。
この方法の欠点は、デスティネーション システムが拡張するシステムごとに情報を交換するために異なるツールを必要とすることです。 ほとんどのソリューションプロバイダーは主な競争に焦点を当てていますが、戦略的に拡張を決定しなかったシステムはどうなりますか? さて、私はこれが3rd パーティーベンダーが足を踏み入れる場所だと思います。 このシームレスな統合に対する需要が十分にある場合、誰かがそれを活用することができます。 プラットフォームの開放性は、誰もが閉鎖されたシステムに比べて非常に少ない労力でシステムを拡張することを可能にします。
2. API を通じて情報を交換するための標準を使用する
上記と同じ方法を使用しますが、データを変換元ネイティブ形式から変換先のネイティブ形式に変換する代わりに、中間ステップを追加できます。 これは、最初にデータを標準に変換する方法で構成されます。 この中間ステップはエンドユーザーから抽象化されます。 この戦略は、複数のシステムを拡張するために必要な労力と開発の量を減らすので、ソリューションを提供していた組織に利益をもたらすでしょう。
この戦略の欠点は、標準を使用すると、常に必要なすべての情報を取得しないことです。 これは、現在の標準とまったく同じ問題です。 追加の情報は、宛先システムに書き込む前に組み合わせる必要がある標準ファイルを補完するために引き出す必要があります。
ここでの問題は、このように標準を使用している場合、業界が標準に必要なものを変えるのでしょうか? おそらくそうではありませんが、これは私が自分自身とあなた自身に尋ねている質問です。
閉会のコメント
私は標準の将来について確信していません。 しかし、私はすべての業界が情報をより効率的に移動する戦略を見つけることを知っています。 システム間での情報の使用は、私が覚えて以来問題となっており、ここ数年で情報交換に重点を置いているため、エンドユーザーとの重要性は増し続けるでしょう。
プラットフォーム化はすでに始まっており、多くの企業が全体的な戦略でこれを述べています。 この方針の変更により、ソフトウェア ソリューション プロバイダとそのサードパーティ パートナーが他のシステムとの情報交換をどのように処理するかを再定義できます。
プラットフォーム化は、エンド ユーザーからソリューション プロバイダに 2 つの異なるシステム間で情報を転送する作業と要件を取り除く可能性があります。 この責任の転換は間違いなく物事を揺るがすでしょう。