estimation - 構築するか購入して統合するか - どのように決定しますか?

Question

構築するか購入するかについて多くの質問や議論を見てきましたが、ほとんどの場合、単純にどちらか一方を実行できるという単純なアプローチに固執しています。ほとんどの場合、購入して統合するか、自分で構築する必要があります。いずれにせよ、あなたはいくつかの仕事のために入っています。

次の 30 ～ 60 日間で、私はいくつかの管理プロジェクトを実施して、全員が髪を引きちぎり、殺し合いをしないようにする必要があります。その最大のものは、チケット システム (電子メール、サポート リクエスト、セルフ サービスなど) です。

オプションが不足することはありませんが、最終的には、使用すると決めたものを購入し、すべてのクライアントとそのユーザーを追加して、時間の経過とともに同期を維持する必要があります. また、シングル サインオンを提供し、設計作業を行って、すべてをゼロから構築したように見せる必要があります。

構築すれば、限られた（しかし焦点を絞った）機能セットではありますが、統合の問題点をスキップできます。

このような決定を下す際に、通常何を分析しますか? 非常に特定の仕事をうまくこなす 4 ～ 5 台のシステムと、すべてをこなす 1 つのモノリシック システムのどちらがよいでしょうか?

Answer 1

すべてを行うモノリシック システムは、非常に多くのエンタープライズ アプリケーションの存在理由です。しかし、私が見つけたのは、多額のお金を払いたくない場合は、統合の問題が発生するということです.

「最良の」ソリューションは非常に主観的なものであり、どのような答えも間違っているのと同じくらい正しいですが、もし私が王様だったら、おそらく確立されたオープン ソース ソリューションを使い、必要なアイテムを Web サービスでラップするでしょう。お互いに話すこと。私が王だったら。

分岐点として、購入を気にする必要のないRT (その他) のような無料のチケット システムがあります。

Answer 2

次の場合は、1 つのシステムが適しています。

• 1 つのデータ リポジトリ (つまり、データベース)
  各システムを相互にリンクし、相互参照する簡単な方法。中間のインポーター/エクスポーター/シンクロを構築する必要はありません

• 単一のログインを許可します。これは、ビジネスにおいて、適切な情報を見つける場所を全員が確実に把握できるようにするのに非常に役立ちます。さらに「バグ追跡のサイトは何だったのか...」 ほとんどの場合、すべての人がすべてのツールを使用するわけではなく、アクセス方法や使用方法さえも忘れてしまいます。

• すべてが同じルック アンド フィールです
  トレーニングを節約できます

• 維持費が安くなります。更新することはすべて同じです。管理者は、別のシステムを聞くことに特化する必要はありません。

しかし...明らかに、あなたは購入したものにこだわっています. 可能であれば、独自のアドインを構築できるシステムを入手して、ビジネス モデルに合わせてください。

Answer 3

明らかに「場合による」。私の一般的なルールは、内部の場合は購入し、必要に応じて統合することです。私たちの会社のシステム管理者は、問題があり、開発者に負担をかける巨大なプロジェクトではない場合、組織外の誰かにサポートラインを持っています.

それが私が出荷する製品の一部である場合は、それをビルドするか、必要に応じてオープン ソース ライブラリからソースの一部を取得します。他人のブラック ボックス コードがあなたの製品を壊してしまうことほど悪いことはありません。出荷製品の依存関係が少ないほど、私見です。

あなたが言及したようなサポート製品の購入に傾倒します. 優れたものは、共有認証システム、ユーザー向けのテーマ設定、そしておそらくカスタマー サービス チームが望んでいる/必要としていることにまだ気づいていない大量の機能への優れた統合ポイントを提供します。

しかし、何を分析するか。このような「管理」プロジェクトに関して、私にとって最大のものは機会費用です。私のチームは、会社の収益を大幅に増やしたり、顧客を増やしたりするために、他に何に取り組むことができるでしょうか? もちろん、これらのプロジェクトは収益にいくらかプラスの影響を与えますが、新製品や改良された製品などと比較すると何もありません。開発者/PM/テスターは、メンテナンスを含めて、この管理プロジェクトにどれくらいの時間を費やしますか? 購入した場合、統合ポイントは頻繁に変更されませんが、構築した場合、顧客 (社内の人々) は常に新しい機能を要求し、残りの在職期間中、このプロジェクトを維持する立場になります。

Answer 4

あなたは重要な問題を特定しました - 購入するとき、あなたはまだやるべきことがあり、それは潜在的にたくさんあります. とは言っても、私の全体的な傾向は毎回購入に向かっています。コードを書くのは難しく、コードをデバッグするのははるかに困難です。購入するときは、コード/アプリケーションを購入するだけでなく、それが機能するという事実を購入しています.後者は利益の90％です.

ただし、ニーズは非常に一般的であるため、オープンソースを使用してみませんか. これには 2 つの顕著な利点があります。

1) ソースにアクセスできるので、自由に変更できます。つまり、既存のシステムにシングル サインを追加する必要はありません。既存のインフラストラクチャを使用するようにログイン モジュールを調整します。したがって、同期、時間の節約、クリーンなアプローチなどを維持する必要はありません。多くのオープン ソースは、とにかく環境固有の側面をコンポーネント化 (?) することで現実世界を認識しています。多くの場合、DB/ID に依存しません。

2) 賢明な選択をすれば、すでにシステムを理解しており、すぐにサポートしてくれる最高の技術スタッフのバンドが用意されます。唯一の問題は、彼らがあなたのために働いていないことです (まだ!)。

私のアドバイスは、あなたの簡単なターゲットの 1 つを選ぶことです。チケット システムはそのようなもので、オープン ソースの世界であなたのニーズのほとんど/すべてを満たすものを分析してください。必要な変更について評価し、 Rent A Coderでリクエストを送信します。座って結果を待ちます。うまくいけば素晴らしいものです。あなたは少し時間を失いましたが、多くの経験を積みました。

オープンソースは Linux/Unix と同じではありません - .Net の優れた機能もたくさんあります。

Answer 5

買う？見知らぬ人、あなたが話しているこの買い物は何ですか？

真剣に、私は長い間、自分のプロジェクト用にソフトウェアを購入する必要がありませんでした。私の開発ツールはすべて無料で、サードパーティのライブラリもすべて無料です (GPL ではありません)。私のOSも無料です。テスト目的で Windows を購入する必要がありますが、ほとんどの作業ではクロスプラットフォームのツールを使用しています。

無料のツールやライブラリからすぐに入手できないコードを必要とするものはすべて、ゼロから作成するか (すべてのアルゴリズムは Web 上で無料で入手できます)、追加してきた (私はとても年をとっているので巨大な) スニペット ライブラリを使用します。ソースコードを何年も

ほとんどの場合、購入する (「入手する」) 方が、構築するよりも迅速です。これは、実績がほとんどないサプライヤーからの最新の奇抜なものを避けることで軽減できます.

Answer 6

要件が「標準的」であればあるほど、購入に適しています (別の言い方をすれば、一からやり直す必要はありません)。逆に、要件が固有であればあるほど、構築を検討する可能性が高くなります。

購入するときでさえ、いくつかのカスタマイズがある傾向があることをあなたは非常に正しく指摘しています. カスタマイズすると、アップグレード/パッチ適用のたびにコストがかかることに注意してください。要件が、購入する可能性のあるツールのいずれかでサポートされているビジネス モデルに近い場合は、ビジネス プロセスをベンダーの標準に再調整することを真剣に検討することをお勧めします。これが不可能な場合は、正しいツールを購入しているかどうかを尋ねてください。

誰かがコストの理由でそれを構築することを提案した場合は、叫んで実行することをお勧めします。私の経験では、購入のコストはよく知られており、構築のコストは十分に隠されています。アプリの存続期間中 (ビジネス アプリの場合は平均 7 年) コーディングを続けるかどうかを決定することになりますが、購入するかビルドするかを決定する際には、初期開発コストのみを考慮する可能性があることを忘れないでください。

私は単一のモノリシック データベースを強く好みますが、これが機能しない場合があります。さらに重要なのは、「唯一の真実の情報源」を持つことです。同様のデータを保持するデータベースが複数ある場合は、特定のデータの信頼できるソースとして 1 つを選択し、他のすべてのデータをそのソースと一致させるプロセスを用意します。これは自動であることが望ましい。