2010-11-18 7 views
1

私は中規模の会社を買収しようとしている中規模の会社のために技術を運用しています。私たちの技術はすべてLAMP(Linux/Apache/MySQL/PHP)です。取得している会社はすべてMicrosoftスタック(IIS/MSSQL/ASP.NET)です。スタッフの開発者の誰も現在.NETをやっておらず、Microsoftサーバーインフラストラクチャをサポートしていません。私はその状況にどう対応するかを決めるのに苦労しています...IIS/ASP.NETサイトをLAMPに移植しますか?

私たちはすべてのMSをLAMPに移植しますか?私のチームの個人的な未経験者を含む様々な理由で、オーバーヘッドをスラッシュしようとしているときのライセンスのコストなど)

2つのテクノロジを別々のチームと並行して実行し、それぞれをサポートし、ミドルウェアを作成してお互いに話すことができますか?

これらのいずれの選択も最適ではありません。このような状況に直面したことがある人はいますか?どのように進めましたか?高いトラフィック量とかなり広範なバックエンドシステムの両方で、大規模なインフラストラクチャについて話していることに留意してください。どんなアイデアも歓迎されます。

+1

奇妙なことに、ダウンシフトの代わりにLAMPを.NETに移植する最も明白な解決策について誰も言及しなかったのはなぜですか? –

+0

"LAMPは現在完璧かもしれませんが、将来のニーズを満たすために.netに移行するための議論があるかもしれません。そして、再びそうではないかもしれませんが、評価される必要があります。 :) –

+0

@ vgv8:OPは彼らが.Netにすべてを移動することに興味がないことを示した。検討中の唯一のものは、2つの技術スタックを維持すること、またはすべてをLAMPに移すことでした。 – NotMe

答えて

2

買収の一環として、貴社は買収のITサポートチームを務めていますか?

結局のところ、バックオフィスのスタッフを統合することで「効率化」が実現する可能性がありますが、ライトをオンにするために両チームが自分のシステムをサポートするという強力な議論があります。

次に、オーバーラップを分析する必要があります。同様のことをしている各スタックのシステムで終わるのでしょうか。その場合は、優先プラットフォームに統合し、他のプラットフォームを削除します。また、(現在のスキルとは無関係に)今後のビジネスニーズを最大限に生かす必要があります。 LAMPは現在完璧かもしれませんが、将来のニーズを満たすために.netに移行する議論があるかもしれません。それでは、やはりそうではないかもしれませんが、評価する必要があります。

データを共有する2組のシステムがビジネス上必要ですか?もしそうなら、どのレベルで?共有機能をカプセル化して他のシステムで利用できるようにする(Web)サービスを作成することは、(SOAを効果的に活用する)1つの方法です。あるいは、バックエンドを最初に共有し、.NETデータベースにMySQLデータベースやその他のデータベースと通信する必要があります。

+0

ほとんどの場合、エンジニアは最小限になり、残りはすでに販売者の親会社に吸収されています。ビジネスは密接に関連しているため、機能性の重複が非常に多い可能性があります。データはサイト間のいくつかの側面で共有され、統合されている必要があります。 –

1

これは非常に複雑な質問です。

2つのアプリケーションが同じような機能を提供する場合は、保持したいアプリケーションの機能がすべて同じになるまで、両方のアプリケーションを同時に実行します。その後、私は顧客を切り替えて、最終的にそれを投げ捨てます。顧客が受け入れやすい場合は、今すぐ切り替えます。

根本的に異なるアプリであれば、今後も両方を維持する可能性が最も高いでしょう。これらが大規模なアプリケーションであることを考えると、書き換えは苦痛を伴うことになり、失敗する可能性が高くなります。家にさまざまな技術を積み重ねるアイデアに慣れるのが最善です。

両方のアプリを維持することで、顧客基盤に関する限り、取得をできるだけ静かに保つことができます。既にアプリを使用しているクライアントは、使用しているアプリがもはやサポートされなくなると感じる場合、通常は馬を変更するだけです。その時点で、他のシステムがどれほど優れているかにかかわらず、一部のユーザーが離れることを保証することができます。

買収によってマーケティングが変更される場合(たとえば、他の会社のロゴの変更など)は、両方を維持することを再度提案します。クライアントはそれほど緊張しているだろう。

これはすべて、技術的な問題よりもビジネス上の問題であり、最初に他の会社を買収した理由と、既存のクライアントにどのように提示するのかという点にあります。同社が技術や顧客基盤のために買収された場合は、それをそのままにしておくことが良い考えです。

私はこれを数回しました。唯一の違いは、PHPから.Netへの別のルートに進んでいたことです。

1つのケースでは、アプリは比較的小さいものの、ユーザーの巨大な基盤を持っていました。私たちはいくつかのURL書き換えルールを使用してしまったので、ユーザーベースはそれらの下でアプリケーションが変更されたことさえ知りませんでした。それはWebサービスの集まりでした。

別のケースでは、アプリが大きく、大きなユーザーベースを持ち、非常にパブリックなスキンを持っていました。ここでも、Googleのプレースメントとブックマークを保存するために、URLの書き換えを大いに活用しました。私たちが持っていた最大の問題は、元のサイトでの開発が、私たちが交換品を組み立てている間中止められなかったことでした。これは、すべての機能が両方のチームを通過しなければならないという点で、多くの課題を提示しました。結局のところ、プロジェクトは予想よりも約3倍長くかかっていましたが、私たちは高度に熟練した人々を抱えていたため、最終的には成功しました。

4

私は以前これをやったことがないので、塩の粒で私の意見を取ってください。しかし、私は既存のアプリケーションを書き直さないことを提案します。つまり、ボタンをクリックしたときに「こんにちは」と伝える1ページのアプリケーションであれば、それをPHPで書き換えます。しかし、お金を稼ぐビジネスアプリケーションはそれほど単純ではありません。あなたは何年も前から、他の会社に何年もかけて開発したものを書き直すことになります。言い換えれば、PHPで書き直している間も、引き継いだアプリケーションをサポートし維持する必要があります。

あなたのチームにスマートな開発者がいて容量があれば、ASP .NETを学ぶことができます。しかし、あなたのチームがそれを学び、引き継いでいるアプリケーションの重量(保守とサポート)を負担するのを助けるために、いくつかのASP .NETリソースを雇うことが最善の方法かもしれません。チームは連携して、2つのアプリケーション間の統合ポイントを見つけることができます。

統合ポイントを書くか、ビジネスアプリケーション全体を一から書き込むかによって、統合ポイントを書くチャンスがあります。

関連する問題