企業資源計画(ERP)

learn menu
By Joannes Vermorel, March 2020

ERP(企業資源計画)は、企業の日常業務をサポートし、現金、原材料、進行中の作業、最終製品、顧客注文、発注、給与などのリソースを追跡する企業ソフトウェアの一種を指します。 ERPには、会計、調達、流通、財務、販売などの主要な業務機能を対象とした多くのモジュールが含まれており、これらのモジュール内で(トランザクションの)情報の流れを容易にするための緊密な統合を提供しています。 ERPはリレーショナルデータベースの上に構築され、通常非常に広範な設計を特徴としています。多数のエンティティ(製品、顧客、請求書など)、多数の画面、高度な設定可能性があります。

enterprise-resource-planning

起源と動機

70年代になると、従来の紙の記録と比較して、電子記録には複数の利点があることが徐々に明らかになってきました。電子記録は、紙の記録よりも安価で、高速で、信頼性が高くなっていました。 ERPsよりも前に登場した2つの発明が、電子記録の活用を可能にしました:バーコードリーダー(1950年代)とリレーショナルデータベース(1970年代)。バーコードリーダーは、商品の流れを管理するための優れた方法を提供し、生産性を向上させながら事務的なエラーを減らしました。しかし、バーコードリーダーは多くの状況でデータの取得を劇的に改善した一方で、電子記録の保存、整理、処理は20年間ほどの間、ある種の未解決の問題でした。リレーショナルデータベースは、70年代後半にこの問題に対するソフトウェア業界の対応策であり、50年後の現在でもビジネスデータ管理において主流の実践となっています。

ただし、80年代初頭に一般的に販売された裸のリレーショナルデータベースシステムは、実装に非常に高価であることが判明しました。なぜなら、すべての企業がデータベース内のすべての要素をどのように表現するかを再発明していたからです:製品、顧客、請求書、支払いなど。そのため、80年代には、「事前設定済み」のリレーショナルシステムを販売するソフトウェア会社が次々と現れました。これらの製品は後にERPと総称されるようになりましたが、この用語は誤りです。ERPは、計画ではなく、むしろ企業資源管理であるべきでした。実際、計画は最大でもERPsの二次的な関心事です。以下で詳しく説明するように、予測分析は基本的なERPの設計とは相容れません。

歴史的に、ERPsは、以前は広範な事務作業を必要とした一連の操作を効率化しました。たとえば、サプライヤーに発注書を発行するには、サプライヤー名と住所を記入する必要がありました。注文行には有効な製品参照のみを含める必要がありました。次に、商品の受け取り時には、受け取った数量が元の発注書に記載されている数量と一致する必要があり、配送が適合と見なされた場合、適切な金額、サプライヤーの支払条件に一致する日付、正しくサプライヤーの銀行口座番号を含むテンプレートに対して支払い命令が生成される必要がありました。これらすべてはERPに存在し、整合性チェックは自動的に簡単に行うことができます。

ERP市場は90年代後半に急速な成長を遂げ、その成長は主にコンピューティングハードウェア(プロセッサ、メモリ、ストレージ)の進歩によって推進されました。これにより、あらゆる規模の企業がハードウェアにアクセスできるようになりました。

90年代には、ビジネスが主に商品の流れを中心としていた場合、ERPsはほとんどの大企業のソフトウェアコアとなりました。対照的に、主にサービスに重点を置いた企業は、顧客関係管理(CRM)ソフトウェアをコアとして採用しました。 ERPsとCRMsは、リレーショナルデータベースの上に共通の設計を採用しているため、多くの属性を共有しています。 ERPsは、ほとんどの機能においてトランザクション中心の視点を採用していますが、CRMsは顧客中心の視点を採用しています。

ERPsの設計

ERPsは多様であり、市場には多くのベンダーが存在し、数十年にわたって多くのバージョンのERP製品を提供してきましたが、その中核はほとんどの実装で非常に類似した設計ラインに従っています。 ERPsは、リレーショナルデータベースの上に実装された「事前設定済み」のソフトウェアレイヤーとして登場しました。したがって、ERPの設計プロセスには、次の項目のカタログ化が含まれます:

  • エンティティ、つまり、ERPが表現する必要があるすべての概念やオブジェクト、例えば製品、支払い、在庫、サプライヤなど。各エンティティは、基礎となるリレーショナルデータベースの1つまたは複数のテーブルを含む場合があります。ほとんどのERPsは数百のエンティティを定義し、最も複雑なERPsでは数千のエンティティを定義します。
  • ユーザーインターフェースは、エンティティのデータを表示および編集するためのものです。これらのインターフェースは、エンティティを扱う際にエンドユーザーが期待する最も基本的な操作であるCRUD設計(作成/読み取り/更新/削除)によって支配されます。
  • ビジネスロジックは、よく定義されたルールに基づいて自動化された動作を提供し、多くの事務作業を不要にします。例えば、顧客の注文を顧客の請求書に変換するなど、自動化できる作業です。

ビジネスは非常に多様で複雑なため、進化するビジネスプラクティスをカバーするために、新しいまたは洗練されたエンティティ、ユーザーインターフェース、ビジネスロジックが必要とされることは絶え間ない努力です。これはERPベンダーにとって大きな継続的な取り組みを表しています。そして、この課題は、非常に多様な垂直市場に対応しようとする際に生じるすべての曖昧さによって複雑さが増します。同じ用語「支払い」でも、垂直市場によっては非常に異なる現実とプロセスを反映しています。ソフトウェアでは、複雑さは非線形のコストを持つ傾向があります。つまり、製品の機能を2倍サポートすることは、元のコストの2倍以上のコストがかかります。

その結果、ERPベンダーは、ソフトウェアの投資を競争力を持たせるために一連の戦略を採用しています。

テクノロジー

複雑さに対処するために、ERPベンダーが利用する最初の戦略は、複雑さに対処するためのコストを低減することを目的とした技術の開発です。

特に、多くのERPベンダーは、基礎となるクエリ言語(現在では通常SQLのバリエーション)を補完する目的で設計されたDSL(ドメイン固有プログラミング)言語を開発しました。よく設計されたDSLを通じて、特定の会社の特異性をカバーするためにERPを拡張する(つまり、新しいエンティティ、インターフェース、ロジック)は、汎用プログラミング言語を使用して同じ努力を行う場合に比べて少ないリソースで行うことができます。

2000年代以降、オープンソースのERPベンダーは、90年代後半に利用可能になったオープンソースのリレーショナルデータベースを活用して登場しましたが、通常はDSLの代わりにプラグイン戦略を採用しました。この戦略では、ERPは、ERP自体と同じ汎用プログラミング言語で書かれた、各クライアント会社に合わせたカスタムコードの導入によって拡張されるように設計されています。この戦略は、ERPベンダーにとって実行が軽く(DSLを設計する必要がない)、ERPのオープンソースの性質と一致しています。

提供

機能の実装およびサポートコストは、機能の総数とともに増加するため、ほとんどのERPベンダーはモジュールベースの価格戦略を採用しています。機能は「モジュール」にまとめられ、会社内の異なる機能領域に焦点を当てています:在庫管理、財務、給与など。ERPはモジュール単位で販売され、クライアント企業が最も重要なモジュールを選択し、他のモジュールを後で投資することができます。

モジュールベースの価格戦略は、ERPベンダーにとって将来の販売の主要なターゲットとなる既存の顧客基盤を持つ自然なアップセル戦略も提供します。最初のモジュールセットで最初にカバーされていなかったビジネス領域には、新しい専用モジュールが追加され、それらはクライアント企業に販売することができます。

このモジュールベースの価格戦略は、支払い意欲が最も高い機能領域についてERPベンダーに直接フィードバックを提供するため、複雑さに対処するための効果的なメカニズムです。そのため、ベンダーはソフトウェアエンジニアリングの取り組みを正しく優先するのに役立ちます。

エコシステム

ERPに追加される各追加機能は、ソフトウェアエンジニアリングの取り組みを正しく優先したERPベンダーにとって、収益が減少する傾向があります1。実際、この機能が以前に追加されていなかった場合、それは最初から十分に関心を引かなかったためです。そのため、組織自体(ERPベンダーも含む)は、量的供給チェーンマニフェストに従っています:ソフトウェア製品に追加のソフトウェアエンジニアを追加することは、改善のスループットにおいて線形の利益をもたらさないことで広く知られています。

したがって、ほとんどのERPベンダーは、ERPを特定の企業で運用可能にするために必要な最後の開発作業を、一般にインテグレーターとして知られる第三者企業に委任するエコシステム戦略を採用しています。これらのインテグレーターは、クライアント企業に対して「生の」ERPでは提供されないすべての機能の実装と展開に対して料金を請求します。歴史的には、2000年代まで、企業が初めてERPを採用したとき、インテグレーターの仕事は通常、ERPの追加機能の導入に焦点を当てていました。しかし、現在では、ほとんどのERPプロジェクトはアップグレードです。レガシーERPが既に存在しているため、インテグレーターの主な付加価値は、古いERPから新しいERPへのスムーズな移行を確保することです。実際の作業では、システム間でのデータとプロセスの移行が含まれます。

ERP自体を主に対象とするビジネス戦略を持つERPベンダーとは異なり、インテグレーターは通常、人日単価のいくつかのバリエーションを採用しています。彼らは作業量に基づいて請求し、作業の知的財産(IP)は通常、契約によってクライアント企業自体に帰属します。

多様なインテグレーターエコシステムを地理的および垂直に開発することは、ERP開発に関連する固有の複雑さを緩和する効果的な方法です。ほとんどの大規模ERPベンダーは、大規模なインテグレーターネットワークを開発しています。

ERPの限界

ERPは、基礎となる関係データベースシステムの制約のほとんどを受け継いでいます2。その後、前のセクションで説明した複雑さ緩和戦略からさらなる制約が生じます。これらの制約は特に興味深いものです。なぜなら、それらは設計上の制約であり、したがって、新しいERPバージョンでこれらの制約を解決することはほとんどないか、それらのソフトウェア製品をまだERPとして参照することはあまり意味がなくなるほどERPを変質させることになるでしょう。

粗い読み取りまたは書き込みに不適

ERPで使用される関係データベースは、ACID(原子性、一貫性、分離性、耐久性)の特性を提供し、主に小規模な読み取りおよび書き込み操作を含むワークロードに適した設計で、低いレイテンシで実行する必要があります。通常、数秒の一部で、読み取りと書き込みのボリュームがほぼバランスされています。関係データベースの詳細な分析は、本記事の範囲を超えていますが、ERPの意図されたワークロードに関するこの観察は、ERPの理解されていない制約の多くを単独で説明しています。

データベースの設計に基づいているため、ERPはデータ量が大きい場合には分析、統計、レポート作成には適していません。ビジネスの運用が続いている間にERPで大量のデータにアクセスすることは常に問題です。データの読み取りや書き込みが多すぎるためにシステムが遅くなるためです。実際には、バーコードの処理などの日常的な操作も遅くなります。最悪の場合、会社全体が停滞します。したがって、ERPのすべての操作(読み取りまたは書き込み)は、理想的には「些細な」ものである必要があります。非些細なデータの量は、過去40年間で劇的に増加しましたが、より良く、安価なコンピュータハードウェアとともに、企業は自社のERPに注ぎ込むデータ量を大幅に拡大しました。その結果、現在のERPシステムは、20年前と比べてほとんど速くなっていないことが一般的です。

たとえば、ERPはSKUの在庫レベルを表示したり、ユニットがピックアップまたはロードされたときにその値を更新するのに適していますが、ERPは通常、過去3年間のSKUの在庫変動の統合された日次タイムラインを表示するのには適していません。ビジネスインテリジェンス(BI)セグメントのソフトウェア製品全体が、ERPの分析上の制約(およびCRMも同様)に対する業界全体の対応策として90年代に登場しました。ERPとは異なり、BIツールはインメモリハイパーキューブ(通常はOLAP(オンライン分析処理)と呼ばれる)を中心に設計されています。ACIDの特性を放棄することで、OLAPシステムは関係データベースよりもハードウェア効率がはるかに向上し、日ごと、店舗ごと、カテゴリごとの売上などの集計統計を提供します。

興味深いことに、90年代以降、BIセグメントがこの状況の証拠であったにもかかわらず、ほとんどのERPベンダーは自社製品のこの設計上の制約に完全に気付いていないようです。たとえば、ほとんどのERPベンダーは、設計上、単なるレポート機能よりもさらに関係データベースと相反する需要予測機能に進出しました。予測には、企業の取引データの全履歴へのアクセスが必要です。販売、返品、在庫レベル、割引など。計算は通常、夜間にバッチ処理されることを意図していますが、関係データベースでは、このタイプの計算を実行しようとすると、大きな偶発的なオーバーヘッドが発生します。その結果、現在のERPシステムには、数年または数十年前に廃れた「レガシー」の予測機能3がほとんど備わっています。

新しいまたは独自のパラダイムに不適

ERPベンダーが使用するエンティティカタログ戦略は、複雑性管理の観点から線形的にスケーリングしません。上記で説明したより優れたツールは、エンティティの数に対して線形的な救済をもたらすだけであり、複雑性のコストは超線形的に増加します。その結果、新しいまたは独自のパラダイムは、通常、コストと遅延の両方がかかり、ERPを完全にスキップする方が良い選択肢になることがよくあります。これらの状況はさまざまですが、以下にいくつかをリストアップします。しかし、すべての状況は、ERPの開発プロセスの後半に現れたために統合が困難なパラダイムに帰結します4

ゼロの運用停止時間を実現することは困難です。なぜなら、上記で指摘したように、大規模な読み取りまたは書き込みはERPのシステムの遅延のリスクを引き起こすからです。したがって、これらの操作は通常、夜間のバッチとして実行されます。しかし、この設計は、ERPsの歴史の比較的遅い段階で現れた電子商取引の要件とは相容れません。その結果、ほとんどのERPベンダーは、電子商取引モジュールを別々に分離し、しばしば別のデータベースシステムを利用しています。これにより、ERPをバックエンドとする電子商取引モジュールは、サードパーティのアプリと同様に展開が困難で高価になる傾向があります。

リマニュファクチャリングのような複雑な循環フロー(つまり、修理)に従う垂直市場に対処することは、主流のERPが一般的にFMCGや流通で見られるような前向きのフローに重点を置いているため困難です。リマニュファクチャリングの目的に必要なほとんどの関連エンティティ(つまり、製品、在庫、注文)はすでにERPに存在しますが、それらの設計は通常、リマニュファクチャリングの要件とはまったく矛盾しています。これらの垂直市場で主流のERPのエンティティを再利用しようとするよりも、それらのエンティティを完全に再実装する方が簡単です。

人間の知覚以下(つまり、50ms以下)の低遅延を保証することは困難です。なぜなら、ERPやその関係データベースは、そのような要件を考慮して設計されていないからです。しかし、ロボット倉庫などの高度に自動化されたシステムを導入するには、ソフトウェアによるオーケストレーションがシステムのボトルネックになるのを避けるために、このような遅延が必要です。したがって、実際には、「リアルタイム」(4)処理に関連するほとんどの領域は、ERPの外部に専用のシステムを持っています。

興味深いことに、主流のERPでは適切に対応していないニッチな垂直市場をターゲットにした専門のERPが存在します。ただし、これらの代替開発パスは、通常、主流の要件とは矛盾しています。

ERP移行のリスク

一見すると逆説的ですが、ERPをアップグレードすることは、初めてデプロイするよりもはるかに困難です。アップグレードは通常、数年にわたるプロセスとして知られています。同じベンダーを使用した場合でも、ERPのバージョンアップグレードは通常、数か月にわたる作業となります。逸話的には、このような困難は、大企業が数億ドルまたはユーロを超える予算オーバーとなったERPのアップグレードの取り組みを発表するときに、しばしばニュースになります。このような状況では、ERPベンダー、インテグレータ、または企業自体が非難されます。しかし、これらの問題は、上記でリストアップされた市場の力によって設計されたERPs自体に固有のものであることを多くの人が認識していないようです。

複雑性のコストは線形的にではなく、超線形的にスケーリングしません。会社が初めてERPを採用する場合、各モジュールを段階的に採用するという贅沢があります。したがって、各イテレーションで関与するエンティティ/インターフェース/ロジックの数は比較的少なく、ERPを会社のニーズに適したものにするために徐々にカスタマイズできます。

しかし、会社が別のERPに移行する必要がある場合、同時にすべてのモジュールを移行する問題に直面します。実際、ERPは、設計上および経済的な要因5により、一部のデータベースを基に構築されたソフトウェアのモノリスです。したがって、新しいERPを展開する際には、元のERPに使用された段階的な採用パスを再現することはできません。したがって、前払いの実装コストは非常に高くなり、デプロイ後の状態は修正に数年かかる半壊状態になる傾向があります。

技術的には、これらのアップグレードは常に実装が困難です。古いシステムと新しいシステムの間のエンティティ/インターフェース/ロジックのインポートは、1対1の関係ではありません。エンティティの意味は時間とともに変化します。たとえば、ERPのベンダーは、元々は顧客の注文用に意図された「注文」テーブルから始めるかもしれません。しかし、その後、ベンダーは元々計画されていなかった顧客の返品の管理という新しい要件に対応する必要があります。次のバージョンのERPでは、「注文」テーブルを顧客の返品用に再利用しますが、これらの行には負の注文数量があります。このささいな変更が、古いERPバージョンから新しいバージョンへの移行を非常に複雑にします。

ただし、新しいERPにアップグレードするか、同じERPの後のバージョンにアップグレードすることは、会社の唯一の選択肢ではありません。実際、移行のリスクを軽減するために複数の代替手段が利用可能です。当然、ERPベンダーや統合業者のエコシステム全体は、彼らの経済モデルの生存のために逆を推進することに強い経済的な利益を持っています。

モノリスを超えて

ERPは、すべての内部コンポーネントが緊密に結合されているソフトウェアモノリスとして登場しました。これは、すべてのモジュールをプラグアンドプレイで展開するために必要なものです。さらに、2010年代まで、分散システム(つまり、数台の中央マシンではなく、複数のマシンで動作するソフトウェア)の構築は、大幅に困難で高コストでした6。したがって、大部分が数十年前のERPベンダーであるため、彼らはモノリスとして製品を構築する以外の選択肢を持っていませんでした。

しかし、クラウドコンピューティングが主流になるにつれて、ツールやライブラリ(頻繁にオープンソース)がより人気があり、よりアクセスしやすくなりました。その結果、分散アプリケーションの設計に関連するコストとオーバーヘッドは、過去10年間で着実に減少しています。ソフトウェア業界は、歴史的にERP(またはERPのようなソフトウェア)によってのみ提供されていた付加価値をどのように提供できるかを広範に再評価し始めました。

エンタープライズソフトウェアの現代的なアプローチは、一つのことをうまく行うように設計された一連の小さなアプリを通じてモノリスを分解することです7。アプリを結びつけるためのAPI(アプリケーションプログラミングインターフェース)は、さまざまなアプリケーションランドスケープへのカスタム統合を容易にするために特に設計されています。ほとんどのAPIは、そのようなカスタム統合に関連する開発コストを大幅に低下させる人気のあるオープンソースのAPIツールを活用するように設計されています。

これらのアプリは、組み込みのERPモジュールよりも前払いの統合コストが高い場合があります。しかし、これらのアプリは、アプリケーションランドスケープのさらなる進化を大幅にリスクを回避する利点があります。会社は、一度に1つのアプリをアップグレードまたは置き換えるオプションを得ることができます。これは実行がはるかに容易であり、リスクも少なく、さらに安価です。最後に、SaaS(サービスとしてのソフトウェア)アプリは通常、小規模な増分変更の継続的な提供を選択します。このパターンは、ITチームに継続的な(しかし限定的な)作業量を生成しますが、SaaSの変更プロセスは、年次または2年ごとのアップグレードと比較して、より有機的で、安価で、リスクが少ないです。

リレーショナルデータベースを超えて

80年代以来、リレーショナルデータベースはERPのデファクトバックボーンでした。しかし、2010年代以降、魅力的な代替手段が現れました。最も注目すべきものはおそらくイベントソーシング(ES)とコマンドクエリ責任分離(CQRS)の組み合わせです。このアプローチは、優れたスケーラビリティとレイテンシを提供し、さまざまな状況でより具体的なビジネス意図を狭く捉えることができるようにします。

イベントソーシングの要点は、システム内のすべての変更を不変のイベントとして扱うことです。不変性の観点は、会計の実践に触発されています。会計士は、元帳の問題を修正するために行を消去するのではなく、代わりに元帳に別の修正行を追加します。データストレージがこの戦略を実現するために十分に安価であると仮定すれば、イベントの完全な履歴を保持することは、多くの利点をもたらします。追跡性、監査可能性、セキュリティの向上などです。さらに、不変性の観点から、イベント駆動型システムはスケーリングが容易になります。データは変更を扱う必要がないまま、広範にコピーおよび複製できます。

CQRSデザインは、ほとんどのシステムで読み取り書き込みのボリュームが非常に不均衡であることを認識しています。多くの場合、(データの)読み取りのボリュームは書き込みのボリュームを数桁上回ります。しかし、リレーショナルデータベースは(多少)対称的な読み取りと書き込みのボリュームに向けられています。CQRSは、読み取りと書き込みの責任を明示的に分離し、通常は2つの異なるサブシステムで行います。この設計は、レイテンシ、スケーラビリティ、ハードウェアの効率性など、さまざまな利点ももたらします。

しかし、ESとCQRSは、すでに大手の消費者向けテック企業や量的取引(金融)で人気がありますが、メインストリームのエンタープライズソフトウェアでの採用は最近になって始まったばかりです。その結果、リレーショナルデータベースの領域に比べて、ES+CQRSのツールはまだ初期段階です。それにもかかわらず、このアプローチはハードウェアコストを大幅に削減するだけでなく、ERPの実装において頻繁に問題となるレイテンシを圧縮する方法を提供します。

Lokadのアプローチ

ERPsは分析目的には適していないため(したがって、BI(ビジネスインテリジェンス)ツールの必要性がある)、予測分析が関与する場合、その実績は芳しくありません。事実証拠として、機械学習/ データサイエンスの革命は、ERPでは起こりませんでした。そのような要件に直面すると、チームは必ずスプレッドシートや特別なスクリプトに頼ることになります。

Lokad自体は、供給チェーンの予測最適化に特化したアプリとして、ERPを補完することを目的として登場しました。在庫/購買/生産/アソートメント/価格設定などの平凡な意思決定をサポートするために設計された、確率的予測の機能など、当社の主要な機能のほとんどは、ERPシステム内で実装するのは実用的ではありません。

ノート


  1. この見解はやや単純化されています。実際には、過去数十年間、ソフトウェアエンジニアリングは計算リソースとともに大きく進歩してきました。その結果、80年代に開発するのが非常に高価だった機能が、数十年後には大幅に安価になる可能性があります。ERPベンダーは、この現象を考慮に入れて開発の取り組みを再評価しています。 ↩︎

  2. 歴史的には、70年代の最初のERP、あるいはERPという用語が後になって登場するまでのERPに似たソフトウェアは、原始的なフラットファイルデータベースに依存していました。関係データベースは、実質的にすべての面でフラットファイルデータベースに優れた代替手段として登場しました。したがって、初期のERPベンダーは、関係データベースに向けて設計をアップグレードしました。ただし、全体データベースのバッチデータ処理に関しては、同じコンピュータハードウェアへの投資が同じであれば、フラットファイルデータベースの方が実質的に優れていました。これは、関係データベースの列指向フレーバーが2010年代に人気を博するまでのことです。 ↩︎

  3. 多くのERPベンダーが予測機能を構築し提供しようと試みましたが、データベースベンダーもまた、自社のシステムに予測機能を構築し提供しようと試みました。私の知る限りでは、これらのデータベースのネイティブな「予測」機能は広く普及しており、ほとんど使用されていない(またはExcelスプレッドシートで手動で補完されている)ため、ベンダーによって後方互換性のために保持されています。 ↩︎

  4. リアルタイム処理は、比較的主観的な用語です。技術的には、光自体の速度が分散システムで達成できる遅延に厳しい制限を設けています。ERPを持つ目的は、地理的に分散したサプライヤー、工場、倉庫などを調整することです。 ↩︎

  5. モジュールごとの価格設定戦略の全体的なセールスポイントは、新しいモジュールをクライアント企業にとって(ほぼ)プラグアンドプレイの体験にすることです。ただし、採用の容易さに対するデザイン上の代償として、モジュール間の強い結合、つまりモノリシックな設計があります。どのモジュールに触れても、他の多くのモジュールに影響を与えます。 ↩︎

  6. 分散コンピュータシステムは数十年前から存在しています。ただし、クラウドコンピューティングが2010年ごろに主流になるまで、ほぼすべてのエンタープライズソフトウェアはクライアントサーバーアーキテクチャを中心に構築されており、すべてのプロセスとデータをフロントエンド、バックエンド、データベースの数台のマシンに集約していました。一方、クラウドコンピューティングは信頼性とパフォーマンスのために複数のマシンで構成されます。 ↩︎

  7. これはもともとUnixの設計哲学でした。2010年以降の専門のエンタープライズアプリは、Unixツールほど狭く焦点を絞ったものではありません。ただし、これらのアプリは既にERPよりも1〜2桁複雑性が低いです。また、このアプローチは、アプリ自体を内部的にエンジニアリングする方法とは異なるものです。 ↩︎