機能的なソフトウェアアーキテクチャ

機能ソフトウェア アーキテクチャ( FSA )は、エンタープライズ機能、相互作用、および対応するITニーズを識別するアーキテクチャ モデルです。これらの機能は、さまざまなドメインの専門家が、協調的な情報駆動型エンタープライズの一部として IT システムを開発するための参照として使用できます。このようにして、ソフトウェア エンジニアとエンタープライズ アーキテクトの両方が、情報駆動型の統合された組織環境を作成できます。

統合ソフトウェア システムを開発および実装する必要がある場合、通常は複数のタスクと対応する責任を分割できます。

1. 戦略的管理およびビジネス コンサルタントは、より効率的/効果的なビジネス プロセスに関連して目標を設定します。
2. エンタープライズ エンジニアは、より効率的なビジネス プロセスの設計と、特定の情報システムに対する要求をエンタープライズ アーキテクチャの形式で考案します。
3. ソフトウェア エンジニアは、特定のアーキテクチャ記述言語(ADL)を使用してシステムのコンポーネントと構造的特徴を記述する情報システムの設計を作成します。
4. コンピュータ プログラマーはさまざまなモジュールをコーディングし、実際にシステムを実装します。

説明した作業区分は実際にははるかに複雑で、より多くの関係者が関与しますが、組織がビジネス目標を達成できるようにするソフトウェア システムの作成にさまざまな背景を持つ人々が関与することを概説しています。このシステム開発プロセスでは、さまざまな関係者によって作成された多種多様な資料が複数の関係者間で交換され、理解される必要があります。

特にソフトウェア エンジニアリングの分野では、多くのツール (A4 Tool、CAME、ARIS )、言語(ACME、Rapide、UML )、手法 ( DSDM、RUP、ISPL ) が開発され、広く使用されています。また、ソフトウェア エンジニア (ステップ 3) とコンピュータ プログラマー (ステップ 4) 間の移行は、たとえばオブジェクト指向開発によってすでに高度に形式化されています。

戦略目標の設定 (ステップ 1) とそれに伴うビジネス チャンスおよび弱点の探索は、100 年以上にわたって広く議論され、調査されてきたテーマです。ビジネス プロセス リエンジニアリング、製品ソフトウェア市場分析、要件分析などの概念は、このコンテキストで広く知られ、広く使用されています。これらの戦略的な入力は、適切なエンタープライズ デザインの開発 (ステップ 2) に使用する必要があり、その後、ソフトウェアの設計と実装にそれぞれ使用できます。

最近の研究では、これらのエンタープライズ アーキテクチャは、いくつかの異なる方法と技術によって開発できることが示されています。これらの方法と技術について詳しく説明する前に、エンタープライズ アーキテクチャの定義を示します。

エンタープライズ アーキテクチャは、ミッション、ミッションの実行に必要な情報、ミッションの実行に必要なテクノロジ、および変化するミッションのニーズに応じて新しいテクノロジを実装するための移行プロセスを定義する戦略的な情報資産ベースです。

この定義では、ビジネス プロセスの改善と必要な情報システムの開発のための豊富な戦略的情報源としてアーキテクチャを使用することを強調しています。これらの制度的青写真は、効果的に定義、維持、実装されれば、組織のビジネス オペレーションと、オペレーションをサポートする基盤となる IT 間の相互依存性と相互関係を最適化するのに役立ちます。

このエントリの冒頭で機能ソフトウェア アーキテクチャの定義を読んだ後、機能ソフトウェア アーキテクチャは、統合情報システムの開発のための豊富なリファレンスとして使用できるエンタープライズ アーキテクチャの一種であることがわかります。これを機能ソフトウェア アーキテクチャと名付けると、実務家はこれを技術アーキテクチャの戦略的入力として使用するようになります。したがって、機能ソフトウェア アーキテクチャとADLのタイプとの間の正式なマッピングが必要です。このようにして、エンタープライズ アーキテクチャをソフトウェア アーキテクチャの戦略的入力として正式に使用および再利用できます。

企業の境界が拡大するにつれて、必要なビジネス、人、IT システムの活動の共通の「全体像」を作成し、関係者全員で共有することがますます重要になります。^[1]機能的なソフトウェア アーキテクチャは、組織をビジネス機能とそれに対応する IT ニーズに細分化することでこれを実現します。このようにして、エンタープライズ エンジニアは、ソフトウェア エンジニアがこれらの IT システムの開発に使用できる豊富な図式的なリファレンスを提供します。

機能的なソフトウェア アーキテクチャの開発は、さまざまな方法と技術を組み合わせて行うことができます。さまざまな方法と技術を組み合わせて使用​​することで、エンタープライズ エンジニアとソフトウェア エンジニアの間の「ギャップ」を埋めることが主な目的となります。ただし、この目的は、方法を組み合わせて、両者が開発して使用する明確で豊富な機能的なソフトウェア アーキテクチャが実現された場合にのみ達成できます。

プロセス リエンジニアリングを通じて内部および外部のビジネス プロセスを最適化することは、外部からのプレッシャーが高まっている時代に企業が持つことができる主な目標の 1 つです。ビジネス プロセスには、特定の入力と出力を伴う価値創造活動が含まれます。これらの入力と出力は相互に関連し、プロセスの結果 (製品またはサービス) に共同で貢献します。プロセス リエンジニアリングは、組織をどのように変更するかについてさまざまな視点をカバーします。組織のプロセスを最適化するために、戦略的で付加価値のあるプロセス、システム、ポリシー、組織構造を再設計することに関係しています。^[2]

エンタープライズ エンジニアリングの正式な方法論の領域では、組織に再利用可能なビジネス プロセス ソリューションを提供するために、方法とテクニックが設計、テストされ、広く使用されています。

• コンピュータ統合製造オープンシステムアーキテクチャ（CIMOSA）方法論^[3]
• 統合定義（IDEF）方法論^[4]
• ペトリネット^[5]
• 統一モデリング言語（UML）または統一エンタープライズモデリング言語（UEML）^{[6] [7]}
• エンタープライズ機能図 (EFD)

これらの方法論/技術および手法はすべて、多かれ少なかれ企業とその基礎となるプロセスのモデリングに適しています。では、効果的かつ効率的な (再) 設計プロセスに必要な情報技術システムのさらなる開発には、どれが適しているのでしょうか。さらに重要なのは、情報およびソフトウェア エンジニアが効率化を実現する IT システムの開発で不明確な結果を使用できない、または使用しないのに、時間のかかる企業方法論を使用するのはなぜでしょうか。これらの質問に答える前に、上記の方法について簡単に説明します。

CIMOSA は、企業要件のビジネス、人、IT の側面をコード化するためのテンプレートと相互接続されたモデリング構造を提供します。これは、情報ビュー、機能ビュー、リソース ビュー、組織ビューなど、複数の観点から行われます。これらの構造は、詳細な IT システムの設計と実装を構造化し、促進するためにも使用できます。

さまざまなビューに分割されているため、企業やソフトウェア エンジニアにとってわかりやすいリファレンスとなります。さまざまな企業機能 (アクティビティ、プロセス、操作) と対応するリソースの情報ニーズを示します。これにより、特定のアクティビティとプロセスでどの IT システムが情報ニーズを満たすかを簡単に判断できます。

IDEFは構造化モデリング技術で、最初は製造システムのモデリング用に開発されました。1981 年には米国空軍ですでに使用されていました。当初は、特定の観点から企業をモデリングするための 4 つの異なる表記法がありました。これらは、機能、データ、動的、およびプロセス分析用のそれぞれIDEF0、IDEF1、IDEF2、およびIDEF3でした。過去数十年にわたり、表記法を統合するためのいくつかのツールと技術が段階的に開発されてきました。

IDEF は、ビジネス プロセスが、対応する情報の入力、出力、アクターを含むさまざまな分解されたビジネス機能を通じてどのように流れるかを明確に示します。CIMOSA と同様に、IDEF もさまざまなエンタープライズ ビューを使用します。さらに、IDEF は、システムをさらに開発するために UML ダイアグラムに簡単に変換できます。これらの肯定的な特性により、IDEF は機能的なソフトウェア アーキテクチャの開発に強力な方法となります。

ペトリネットは製造システムをモデル化するためのツールとして知られています。^[8]ペトリネットは表現力に優れ、並行システムのモデル化に適した形式を提供します。最も有利な特性は、状態のシンプルな表現、並行システムの遷移、遷移の持続時間をモデル化する機能です。

したがって、ペトリ ネットは、対応する状態と遷移、または内部のアクティビティと出力を持つ特定のビジネス プロセスをモデル化するために使用できます。さらに、ペトリ ネットは、さまざまなソフトウェア システムとこれらのシステム間の遷移をモデル化するために使用できます。このように、プログラマーはペトリ ネットを図式的なコーディング リファレンスとして使用します。

近年、ペトリネットがビジネスプロセス統合の発展に貢献できることがいくつかの試みで示されています。その1つがModel Blue方法論です。これはIBM中国研究所によって開発され、統合プラットフォームを構築するための新しいアプローチとしてモデル駆動型ビジネス統合の重要性を概説しています。^[9] Model Blueビジネスビューと同等のペトリネット間のマッピングも示されており、彼らの研究がビジネスとITのギャップを埋めていることを示しています。しかし、彼らはペトリネットの代わりに、変換エンジンを介してビジネスビューから派生できる独自のModel Blue ITビューを使用しています。

UML は、ソフトウェア システムおよびアプリケーションの開発に広く受け入れられているモデリング言語です。オブジェクト指向コミュニティも、UML をエンタープライズ モデリングの目的で使用しようとしています。彼らは、複雑なエンタープライズ システムを作成するためのエンタープライズ オブジェクトまたはビジネス オブジェクトの使用を重視しています。これらのオブジェクトのコレクションとそれらの間の対応する相互作用は、複雑なビジネス システムまたはプロセスを表すことができます。ペトリ ネットがオブジェクトの相互作用と状態に焦点を当てているのに対し、UML はビジネス オブジェクト自体に重点を置いています。これらは「エンタープライズ ビルディング ブロック」と呼ばれることもあり、リソース、プロセス、目標、ルール、およびメタモデルが含まれます。^[10]このように UML は統合ソフトウェア システムをモデル化するために使用できますが、ビジネスの現実はソフトウェア モデリング言語でモデル化できると主張されてきました。これに対して、オブジェクト指向コミュニティは UML のビジネス拡張機能を作成し、言語を適応させます。UEML は UML から派生したもので、ビジネス モデリング言語として提案されています。このビジネス変革が正しいことなのかどうかという疑問が残ります。以前、UML を他の「純粋な」ビジネス メソッドと組み合わせると、より良い代替手段になる可能性があると言われました。

EFD は、エンタープライズ機能とそれに対応する相互作用を表現するために使用されるモデリング手法です。これらの表現では、「機能モジュール」とトリガーを使用して、さまざまなビジネス プロセスをモデル化できます。開始ビジネス プロセスは、さまざまな機能にさまざまな入力を提供します。すべての機能とサブ機能を通過するプロセスは、複数の出力を作成します。エンタープライズ機能図は、ビジネス プロセスとそれに対応する機能、入力、出力、トリガーを非常に使いやすく詳細に表現します。このように、EFD は、ビジネス プロセスを機能とトリガーの組み合わせとして階層的に表現する IDEF0 図と多くの類似点があります。違いは、EFD ではビジネス機能が組織の階層的な観点に配置され、組織内の特定のプロセスの下流が概説されることです。一方、IDEF0 図では、矢印を使用して特定のビジネス機能の責任を示します。また、IDEF0 では、すべての (サブ) 機能の入力と出力が明確に表現されます。

EFD は、UML のようなソフトウェア モデリング言語のビジネス フロントエンドとして使用できる可能性があります。モデリング ツールとしての IDEF と大きな類似点があることから、それが可能であることがわかります。ただし、EFD 手法を改善して UML への正式なマッピングを行えるようにするには、さらに研究が必要です。^{[1] の}IDEF と UML の相補的使用に関する研究は、IDEF がビジネス フロントエンドとして受け入れられるきっかけとなりました。EFD と UML についても同様の研究を行う必要があります。