「スーパー」サイトに対して、またそれに対してどのような考慮が必要ですか？

私の会社は、すべてのティア1（つまり、トップエンドの本番）アプリケーションとサイトを1つの包括的なコードベースに統合することを検討しています。

理論は、それらの権限、デザイン、および全体的な機能を均質化し、集中管理できるというものです。

各アプリケーションの基盤となるデータ構造は非常に異なり、ビジネスルールは複雑で、各アプリケーションに固有であり、既存のアプリケーションの全体的なコードベースは非常にバラバラで無視されているため、このアプローチに終わりはありません。

編集：

現在の環境は、最初に書かれて以来ほとんど愛されていない3つのASP.Net 1.1サイト（主に社内の経験豊富な開発者がいないため）と、以前はASP.Net 1.1サイトでもあった1つのMVC2アプリケーションで構成されています。昨年アップグレードされました。C＃のみで書き込みます。

同社はかなり小規模で、約50人のスタッフがいます。3人は実際の開発者です。管理（IT管理であっても）には、ITプロジェクトのプロジェクト管理（したがって、専門用語やビジネスへの影響に関するある程度の知識）以外のITの背景や経験はありません。

アプリケーションは主に、同社が販売する製品をサポートするオンラインサービスです。同社はソフトウェアを直接販売していません。

したがって、この状況全体をかなり具体的で答えられる質問で言い表す：現在の条件（つまり、古いコードベース、複雑なビジネスシステムおよびルール）を前提として、すべてのシステムを1つの包括的なソリューションにまとめようとすることに対する、または反対する説得力のある理由は何ですか？ ）？

悪いアイデア

この反応は、次の仮定に基づいています。

1. 均質化されているかなり異なるアプリケーションがたくさんあります
2. さまざまなアプリケーションに取り組んでいる多くのチームがあります
3. アプリケーションを積極的に管理する、尊敬され権威のあるソフトウェアアーキテクトはいない

先に進むとどうなりますか

ほとんどの場合、単一の設計アプローチの下ですべてを統合する最初の統合された取り組みが行われます。これは、すべてを同じように機能させるために必要な多大な労力を示し、機能しないものとして缶詰になる可能性があります。

必要な場合は、構成データ（セキュリティアクセス、ロギングレベルなど）を含むある種の集中化されたリポジトリが必要になります。この時点で、誰かが明白なことを指摘して言う

「ねえ、なぜこの外部化された構成アプローチを古いアプリケーションに改造しないのですか？それははるかに速くなるのですか？」

そしてしばらくすると、他の誰かがパイプをします

「そして、とにかくリファクタリングしているので、各アプリケーションドメインに設計標準を適用するだけではどうでしょう。Web処理は次のようになり、ビジネスルール処理はこのようになり、データベースアクセスはこのようになります。」

ようやくまで

「ああ、ここには多くの一般的なコードがあるので、簡単に共有できるライブラリをいくつかまとめてみませんか。おそらく、たとえば毎晩、一定の間隔で実行するある種の統合ビルドが必要になるでしょう。」

その時点で、誰もが巨大なモノリスが構築されなかったことに安堵のため息をつく。

私の会社ではこれに取り組んでいます。私はそれが可能であり、明らかな利点があると思います（あなたはそれらについて言及しました）が、これはおそらく最低5〜7年のプロジェクトであり、基本的にすべてを書き直す必要があります。もしあなたがそのようなものでサインオフを得ることができるなら、私はそれのために行くと言うでしょう。そうでない場合は、悪夢のような死の行進の準備をします。

グーグルはそれをするので、それは確かに可能です。

そのリンクBTWは、Google社員がコードベース、継続的インテグレーション、テストなどを管理する方法についての興味深いプレゼンテーションです。

しかし、Googleが行ったように、ツールへの同様の強いコミットメントがなければ、あなたは傷ついた世界に陥る可能性があります。

ここで重要な質問はなぜですか？なぜ上級管理職はこれをしたいのですか？彼らはどのような節約、レバレッジ、またはその他の利点を得たいと考えていますか？

それらの目標を達成するためにそれらの問題に十分に対処できれば、問題となる単一のコードベースを回避しながら、同じ効果的な結果を得ることができます。

同様のプロセスを経てきました。しばらく前からある製品がありました。昨年、最初の製品と95％同一の別の製品を導入しました。5％の場合は微妙ですが大きな違いがあり、それらの違いは別のチームによって開発および保守されます。

私たちが最初に新製品の開発を始めたとき、古いチームは新製品を理解していなかったため、その5％で私たちに悪影響を及ぼした変更を続けていました。そのため、コードの5％を完全に分岐させたため、最初のリリースを予定どおりに完了することができました。

その後、より多くのメンテナンス作業が始まり、ほぼ同じコードでほぼ同じ変更を頻繁に行っていることがわかりました。古いチームはまた、新製品をよりよく理解しているので、分岐したものを徐々に再統合し、違いを表現するためのより効率的なアーキテクチャの方法を見つけています。

したがって、データ構造が異なり、全体的なコードベースが異なると言う場合、私が尋ねる質問は、それらがそのようにする必要があるのか​​、それとも瞬間の便宜のためにそれらがどのように進化したのかということです。明らかに、異なるビジネスルールと要件を考慮する必要がありますが、重要なのは、それらの違いをできるだけ小さなモジュールに分離することです。異なるコードベースに対してわずかに異なる方法で複数の顧客にまったく同じ機能を実装していることがよくある場合は、統合が実際に役立つ可能性があります。その場合、経営陣はおそらくこれを提案しないでしょう。

多くのアプリケーションを同じコードベースに統合することはほとんど不可能です。これはかなりの労力を要し、古い、無視されたプログラムの場合、これは当初の予想よりもはるかに多くの作業になる可能性があるためです。

とはいえ、すべてのアプリケーションを同じコードリポジトリに配置しても問題はありません。アプリケーションごとに個別の領域があります。これにより、たとえば、コードベース全体のオンラインドキュメントを1つの一貫したビューで生成することができます。

これを決定する人は、なぜそれをしたいのか、そしてそこに到達するために費やしたい仕事の量を考えるべきです。

企業の開発を非常に非効率的で費用のかかるものにする単一のものがあれば、すべてを行う単一のシステムを作成することが可能であるという幻想です。システムのすべての詳細を理解し、1週間の会議を必要とせずにすべての決定を下すことができる単一の製品所有者がいた場合、それはうまくいくかもしれませんが、それが起こるのを見たことがありません。

一般的には、インターネット向けの開発のように扱うほうがよいでしょう。実際に自分のコード以外では何も制御できないことを認めて、自分のアプリを作成するだけです。OAuthと、ユーザー設定用の単純なAPIと共有CSSを使用することで、ほぼすべての一貫性を実現できます。

これはSOAの本来の目的と非常に似ていますが、これを呼び出すと、すべてを実行しようとする、大規模でかろうじて機能する別のタイプのシステムになってしまいます。

私の最初の考えは、これがリリースの合計PITAになるということです。

管理と承認のすべてのレイヤーを回避する場合にのみ、管理可能な機能のチャンクに分割する方がはるかに賢明です。

一般的なものをコンポーネント/サービスに分割し、その方法で標準化することは、IMHOをはるかに簡単にします。

Deliveranceなどの統合テクノロジーを使用して、すべてのWebアプリケーションに同様のテーマを設定することで、これに異なるアプローチをとることができます。基本的に、各アプリケーションはまだ個別です。DeliveranceはXSLTルールを使用して、出力を設計した静的HTMLテンプレートにシューホーンします。これにより、比較的単純な静的HTML / CSSテーマを最小限のアプリケーションでアプリケーションスイート全体に適用できます。