エンタープライズアプリケーション

今世紀の初頭、私は著書「Patterns of Enterprise Application Architecture」(エンタープライズアプリケーションアーキテクチャのパターン)に取り組んでいました。この本の執筆において直面した問題の一つは、本のタイトル、あるいは私が記述している種類のソフトウェアシステムを何と呼ぶかでした。私は常に、自分のソフトウェア開発経験は特定の種類のソフトウェア、例えば医療記録、外国為替取引、給与計算、リース会計などに焦点を当ててきたことを意識してきました。これらは、プリンター、ゲーム、フライトコントロールソフトウェア、電話交換機内部の組み込みソフトウェアとは大きく異なります。私はこれらの種類のシステムを記述するための名称が必要であり、「エンタープライズアプリケーション」という用語を採用しました。

私がしばしば言わなければならないように、この用語には正式な定義はありません。しかし、エンタープライズアプリケーションには共通するいくつかの特性があります。

エンタープライズアプリケーションは通常、大量の永続データを持ち、通常はなんらかのデータベース管理システムによって管理されています。通常、このデータベースはリレーショナルですが、NoSQLの代替手段も増加しています。このデータは、それを処理するアプリケーションよりも、通常はより長く存続し、より価値のあるものです。

このデータは同時アクセスされ、操作されます。その数は大きく異なります。社内アプリケーションでは数十人のユーザーしかいない場合がありますが、顧客向けのWebアプリケーションでは簡単に数万人のユーザーになる可能性があります。高い並行性のレベルにもかかわらず、多くのエンタープライズアプリケーション開発者は、クリティカルセクション、競合状態、その他の古典的な並行プログラミングの要素についてあまり考えていません。代わりに、彼らはデータベースまたは専用のトランザクション管理ツールによって管理されるトランザクションの上に構築された考え方の上に構築します。

大量のデータがあるため、エンタープライズアプリケーションはそれを処理するために多くのユーザーインターフェース画面を備えています。通常、同じデータは異なるコンテキストで異なる方法で操作されます。ユーザーは、定期的なユーザーから時折のユーザーまで様々であるため、インターフェースは異なるレベルの familiarity に合わせる必要があります。また、容易に見過ごされがちなオフライン（バッチ）処理もかなりの量存在します。

真新しいエンタープライズアプリケーションを構築する場合でも、孤立して行うことはありません。代わりに、他のエンタープライズアプリケーションと統合する必要があります。これらのシステムは、幅広いチームによって構築されています。いくつかは多くの顧客に販売するベンダーからのものですが、その他は組織内だけで構築されたものもあります。これらのアプリケーションは、数十年以上にわたってさまざまな技術で記述されており、その中にはお母さんに尋ねなければならないものもあるでしょう。ファイル交換、共有データベース、メッセージングミドルウェアなど、対処すべき統合メカニズムはたくさんあります。時々、このすべての通信技術を合理化しようという試みがありますが、完全に成功することはなく、さらに複雑さを残します。

異なるアプリケーションが同じデータにアクセスする場合でも、それらの間にはかなりの概念的な不一致があります。顧客は、営業組織にとってとは異なる意味を持つ可能性があり、技術サポートとは異なる意味を持つ可能性があります。同じように聞こえるエンティティは、異なるコンテキストで異なるフィールドを持っていたり、さらに悪いことに、同じ名前なのに異なる意味を持つフィールドを持っていたりします。

そして、いわゆる「ビジネスロジック」があります。オペレーティングシステムを作成する場合、全体を論理的に保ち、簡素化を発見して実装して、ソフトウェアをシンプルで信頼性の高いものにするよう努めます。しかし、ビジネスルールは現状のまま与えられ、変更したい場合は、67回の会議と3人の副社長の退職が必要です。それらは通常、驚くような方法で相互作用する奇妙な条件の場当たり的な配列です。その狂気は正当な理由から生じており、それぞれが営業担当者が特別な一回限りの条件を提供することで特定の取引を成立させることができた事例です。これを1000回行うと、多くのエンタープライズアプリケーションの中心にある複雑なビジネス「非論理」が生まれます。

エンタープライズアプリケーションは、大小さまざまです。多くの場合、議論は大きく複雑なアプリケーションに焦点を当てていますが、迅速に構築する必要がある小さなアプリケーションにも課題があります。大きなシステムは問題が発生すると大きな騒音を出しますが、小さなシステムの累積効果は、企業の健康に驚くほどの影響を与える可能性があります。

物事に名前を付けることは、常に困難です。最小限の単語数を使用する必要があり、読者の心に正しい意味合いを引き起こしたいと考えています。そのため、定義の意味を絶えず思い出させる必要はありません。全体的に、私は自分の選択にかなり満足していましたが、私が本を完成させてから、「エンタープライズ」という言葉は、私の使用法にはあまり合致しない意味合いを持つようになりました。

本以降に明らかになった問題の一つは、「エンタープライズ」という言葉が、現在では通常、大規模で確立された企業を意味するようになったことです。人々は、Facebook、Etsy、またはカスタムTシャツを製造する100人の従業員を持つ企業ではなく、GEやシーメンスを思い浮かべます。しかし、上記の定義によると、小さなスタートアップでさえ、エンタープライズアプリケーションと呼ぶソフトウェアに依存しています。そのため、Ruby on Railsコミュニティが「エンタープライズ」を侮辱として使用することになったとしても、私はRuby on Railsをエンタープライズアプリケーションを構築するためのフレームワークと呼び、BaseCampをエンタープライズアプリケーションの典型的な例と呼びます。（DHHにそう言ったことを言わないでください。そうでないと、私をフードオーナメントにしてしまうでしょう。）

「エンタープライズ」を取り巻くこれらの意味合いから、別の用語が必要かどうかを考えさせられました。「P of EAA」を書いているとき、私の仮タイトルは「情報システムアーキテクチャ」でしたが、「情報システム」には古い技術の望ましくない意味合いがあると私たちは感じました。「データ処理」を使うこともできますが、全体として「エンタープライズアプリケーション」は、私が思いつく他のどの用語よりも優れた用語のようです。