先週、私はTwitterで#ENOVIAEverywhereをフォローしていて、ゼロファイル(ファイルレス、データドリブン)環境について言及されたいくつかのコメントに非常に興味をそそられました。 このトピックだけに焦点を当てたパネルもありました。 私がフォローしている人のツイートの一部を次に示します。
データ駆動型アーキテクチャは、CAD /CAMソリューションを含む最新のソフトウェアの未来になると私は本当に信じているものです。 ファイルは素晴らしく、私たちに非常によく役立っていますが、今日と明日の環境では、不必要な複雑さが増します。 ファイルの使用は、私たちが非常に基本的に私たちの仕事を整理するだけでなく、それを共有するのに役立つ消耗パッケージに私たちの仕事を分類することを可能にするパッケージに情報をキャプチャできる方法でした。 しかし、今日のはるかに包括的なアプリケーションでは、すべてをはるかに多く加えることができるので、ファイルの有用性が低下し、場合によってはタスクが複雑になります。
現在の現実
プロジェクトの規模が大きくなってきている – 今日のプロジェクトは大きくなるだけでなく、コンポーネントごとにより多くの情報をモデル化し、キャプチャしています。 これにより、管理しやすいチャンクで消費する必要がある、より多くの関係、関連付け、およびデータが発生します。 特定のタスクに関連しない可能性のある追加情報(私がノイズと呼ぶもの)を提供する時代はとっくに過ぎています。 ファイルは、アクションを実行するために必要な情報の包括的なコンテキストを提供しません。
より協調的で分散した環境 – 今日のプロジェクトでは、コロケーションされていないチームと連携する必要性が高くなっています。 また、プロジェクト内のすべての関係者と共同作業を行う必要もあります。 これは、組織内または外部の場合があります。 ファイルは、他のチーム メンバーと共有して共同作業するための優れた方法を提供しません。
より多くのコンカレントエンジニアリング– これは上記の2つの点に関連しています。しかし、それ自体は、それ自身のメリットに言及するに値する。 コンカレントエンジニアリングには多くのレベルがあり、すべてのプロジェクトでタイムラインを絞り込み、各フェーズをさらに重ね合らせようとします。 これは、ますます増加する並行エンジニアリングをサポートするために、より優れたソリューションとプロセスが必要なことを意味します。 ファイルは、1 人のユーザーが 1 つのファイルで作業できるようにすることで、同時実行エンジニアリングを実際に妨げます。 通常、ファイルには、この単一ユーザーが変更するコンポーネントよりも多くのコンポーネントが含まれます。 したがって、編集されていないファイルの一部に変更が必要な場合、現在のユーザーは他のユーザーによる同時作業をブロックしています。
製品データモデルは、より多くの関係を持っています – 今日のソフトウェアアプリケーションの多くは、パラメトリック方式や関連付けに依存して、モデル全体の変化を伝播する改善を行っています。 これらの関係は、その複雑さを増す可能性があるオーサリングツールから来るかもしれないし、しないかもしれません。 ファイルには、ファイル内のコンポーネントのすべての情報のコンテナであるという前提と矛盾するため、ファイルに必ずしも含まれているわけではありません。
情報を見つけるのは難しいです – これは大きな問題であり、私たちの非常に貴重な時間の多くを吸い上げる。 この課題を解決するためのソリューションの種類は多く(PLM/PDM/など)が多く存在します。ただし、ファイルから情報を抽出し、ユーザーが情報をより多く利用できるようにすることが利点です。 データに十分な構造と分類を提供するために使用されるファイル。 しかし、今日生成されるファイルの量では、ファイルだけでは十分ではなくなり、ファイル管理に焦点を当てたソリューションが数多く存在します。
私のクリスタルボールが私に言っていること
免責事項:私はそれが常に正しいとは限らないので、私のクリスタルボールはいくつかのバグを持っていると思います。
短期的には、純粋にファイルレス環境は見 当たりません 。 しかし、ファイルゼロのソリューションが見え始めるでしょう。 ファイルは私たちの生活の重要な部分であり続けますが、コンテンツを保存する主なソースとしてファイルから離れて大幅な移行があります。 今、これは我々がファイルを使用しないことを意味するものではありません、それは我々が抽象化された中間パラダイムでファイルを使用することを意味します。
私がこれが当てはまると思う理由は、現在、ファイルに焦点を当てたプロセスとツールが多すぎるからだ。 この場合、ユーザーが同じような環境で作業を行えるようにするために、いくつかの段階的な手順が必要になりますが、基になるテクノロジをユーザーから抽象化します。 したがって、ユーザーは同じ古いファイルを使用していると思うかもしれませんが、実際にはファイルは製品モデルの内容の表現に過ぎず、製品データモデルのデータから 100% 再作成することができます。
私のクリスタルボールは、ファイルの定義を変更することなく、ファイルに関する問題を解決することに焦点を当てたソリューションの将来に本当にあいまいです。 上記の予測が正しければ、これらのファイル中心の解決策は、もはやファイルなしでは存在しない問題を解決しています。 彼らはこの新しいトレンドで進化する可能性があります。
閉会の挨拶
ファイルレスソリューションや情報中心アーキテクチャについて、今後もこれからも多くのことを聞いていきます。 クラウドへのプッシュは、 クラウド ソリューション内のファイルを処理する頻度としてもこれを駆動します。非常にまれに。 その理由は、私たち、ユーザーは、本当にファイルを気にしないので、我々は情報へのアクセスを得ることを気にします。
ファイルは、近い将来、当社の環境の一部として継続されますが、次の方向に傾きます。
- 現在の技術を用いたモデルの可視化
- 他の製品との統合とインターフェース
- 現在のワークフロー、プロセス、ツールの中断を削減
ファイルレスソリューションを使用しても、ソフトウェアプロバイダは、現在の環境におけるユーザーの現在のツールとスキルをより重要に活用する戦略を作成する機会があります。 ソフトウェア プロバイダーは、基盤となるテクノロジを抽象化する方法を検討する必要があるため、戦略の変更はエンド ユーザーに大きな影響を与えるべきではありません。
誰かがEnoviaコミュニティで ゼロファイルパネルの議論 に関連する情報を持っている場合、私はそれについて聞いてみたいと思います。