コンポーザブル・アーキテクチャーとモノリシック・アーキテクチャーの比較

:::(Info) (アプリ開発者はソリューション・アーキテクチャについて重要な決定を下す）Tulipでアプリケーションを構築する場合、アプリの構造、データモデル、統合を含むソリューション・アーキテクチャについて決定を下します。意図的であれ偶発的であれ、アーキテクチャの決定は、アプリの採用可能性、拡張性、保守性に大きな影響を与えます。この記事では、コンポーザブルとモノリシックという2つの重要な設計パラダイムを紹介します。Tulipでは、アプリ開発者にコンポーザブル・アーキテクチャの使用を強く推奨しています：

なぜモノリシックよりコンポーザブルが望ましいのか？

モノリシック・ソリューションの特徴は以下の通りです：

• トップダウンのデータモデル
  • プロセスモデルやアクティビティモデルは、テーブル内のデータによって定義され、モノリシックアプリはプロセスモデルやアクティビティモデルを実行するために使用されます。チューリップ・テーブルのデータ・モデルは、複雑なオペレーションを1つのサイズで抽象化したものです。
• プロセス中心
  • モノリシック・アプリは、複雑なオペレーションを機能的に分解し、機能を提供するために構築される。モノリシック・アプリの有限セットは、オペレーションのどこにいても、現場のオペレーターに同じ機能を提供することを目的としている。
  • モノリシック・ソリューションは、一般的にコンフィギュレーション・アプリと実行アプリの2つのアプリで構成され、コンフィギュレーションには、コンポーザブル・アプリそのものではなく、データテーブル内の作業指示とプロセス・ルーティングが含まれます。
• 一元管理可能な設計
  • モノリシック・アプリは、使用するアプリの数と種類を減らすことで、中央チームによるソリューションの保守と管理を容易にするように設計されています。モノリシック・ソリューションは、厳格な階層構造でトップダウンに設計されており、現場のオペレーターは、どの機能が適用可能かを選択することで、アプリに情報を提供する。

Tulipは伝統的なMESではないため、モノリシックなソリューションアプローチには反対し、代わりにコンポーザブルアプローチに従うことを強くお勧めします。Tulipは、モノリシックなアプリ、つまり、1つのアプリで、あらゆる産業、あらゆる様式、あらゆるシナリオ、あらゆるマシン、あらゆるオペレーターに対応するアプリを構築するようには設計されていません。モノリシックなソリューションは、私たちがJAM（Just Another MES）と呼ぶものになります。

モノリシックなソリューションにはどうしても欠点がある

モノリシックなソリューションアプローチは、せいぜい他のMESと「同程度」のソリューションになるのが必然であり、本質的に関連するすべての欠点を抱えることになります。 * モノリシックなソリューションは、導入に数カ月から数年の時間と多大な労力を要します**。**モノリシック・ソリューションは人間中心ではないため、システムがオペレーターにサービスを提供するのではなく、オペレーターがシステムにサービスを提供するという、クランキーなユーザー・エクスペリエンスになりがちです。モノリシック・ソリューションは本質的に複雑で保守が難しく、ソリューションに関する独自の知識を持つ専門チームが必要です。

これは、変更が最小限であり、一般的に知られていることを前提とした、厳格なトップダウンのアプローチである。

モノリシック・ソリューションは、人間が厳格なルールに従わなければならないプロセスを自動化するために構築される。これは、変更がほとんどなく、すべてのバリエーションが既知であることを前提としている。

コンポーザブル・ソリューションの構築は簡単だが、考え方を変える必要がある。

コンポーザブル・ソリューションは、チューリップ・プラットフォームの機能を利用して、現場のオペレーターがデジタルでやり取りできるユニークで具体的な方法を提供し、生産性を高めることを可能にします。物理的な世界と仮想的な世界が相互接続されたデジタル・インタラクティブ・ソリューションをオペレーターに提供します。これは、生産性の向上を達成する上で重要な原則であり、コンポーザブル・ソリューションに固有のものです。

コンポーザビリティとコンポーザブル・ソリューションの特徴

• ソリューションは、特定のショップフロアにとって意味のある最小の論理ブロック（ソリューション・コンポーネント）に分割されます。
  • 例えば、ソリューションは、以下のような要素に基づいて、個別のアプリケーションに分割されます：場所、時間、ペルソナ
• ソリューション コンポーネントは共通のテーブル モデルを共有します。
• ソリューションコンポーネントは、顧客に合わせたベストプラクティスを共有して開発される。
• ソリューションとそのコンポーネントは、別のシチズン開発者によって理解され、サポートされます。
• ソリューションとそのコンポーネントは、必要に応じてパラメータ化されます。

チューリップ・プラットフォームはソフトウェア（SaaS）ですが、チューリップのアプリをソフトウェアと考えるべきではありません。チューリップのアプリは、目的に応じて高度に設定可能なデジタルコンテンツであり、現場のニーズに合わせて継続的に変更・適応されるべきものです。アプリを変更したり強化したりすることは、マスターデータを変更することと同じです！Tulipプラットフォームは、バージョン管理されたライフサイクルプロセスを通じてアプリの変更を管理する方法を提供し、この設定可能性の管理を支援します。アプリはノーコードで構成され、アプリソリューションはアプリで構成されます。ソフトウェアソリューションのように、モノリシックな機能ベースのアプローチを使用してTulipでソリューションを構築することは、ソリューションを迅速に構築し、コンポーザブルシステムの利点を得る能力を決定的に制約します。

コンポーザブル・ソリューションのその他の重要なメリットは以下のとおりです：

• 生産性向上のための現場ワークスペースの拡張
• ビジョン、AI/ML、スマートデバイスなど、シームレスに統合されたデジタル技術の利用
• データ主導の意思決定とCIを可能にする、プロセスと現場業務の計装化／デジタル化。
• テーブルや外部システムからの共有情報を活用した生産実行のガイド。

コンポーザブル・ソリューションは、他のシステムとの統合やコラボレーションを容易に行えるという付加価値を提供する。これは、異なる自律デバイスやシステムが容易に通信し、相互作用するIIoTの中核をなすものです。TulipはIIoTプラットフォームであり、そのノーコード・アプローチを使って他のシステムとの統合を構築する能力をネイティブに提供する。プラットフォームがデータを消費し、他のIIoTに送信することで、ITの知識がない人でも数時間でエンドポイントを達成することができる。これには、アプリが特定のフローを持ち、ローカルの物理世界と接続する、コンポーザブル・アプローチが必要だ。

チューリップ・ソリューション設計における一般的なソリューション・パターン

コンポーザブル・ソリューションのハイレベルな設計は、多くのパターンに従うことができます。以下は、チューリップ・ソリューションの一般的なパターンです。これは排他的なセットではなく、相互に排他的でもないことに注意してください。ある施設でのユースケースに応じて、これらのパターンの多くやその他のパターンが使用されるかもしれません。

従来のモノリシックなシステムの実装と、市民が開発したコンポーザブルなソリューションの実装の比較

企業システムを実装する従来のアプローチは、以下の「古い方法」に見られるように、一般的に長期的でハイリスクな遅延価値のアプローチである。一般的に、このような初期導入には何年もかかると予想され、したがって当然、その後の重要な機能強化にもほぼ同じ時間がかかると予想される。

市民が開発するコンポーザブル・ソリューションの実装 - 小規模に開始し、能力とユースケースを有機的に成長させる

従来のモノリシックなソリューションの実装に時間がかかるのとは対照的に、コンポーザブル・ソリューションの実装は反復的に行うことができるため、価値実現までの時間が非常に早く、継続的な改善を行うアジャイル・モデルを自然にサポートすることができる。

従来のモノリシック・ソリューションで開発されたソリューションの「バージョン2」をデプロイするには、数ヶ月かそれ以上かかるかもしれないが、コンポーザブル・ソリューションでアプリの「バージョン2」をデプロイするのは、数時間、数日、数週間かもしれない。コンポーザブル・ソリューションによって可能になる迅速な反復は、オペレーターによる採用率を向上させます。