私の部門は、顧客データをデータベーススキーマに変換して、ソフトウェアを使用できるようにすることを専門としています。

IDataReader現時点では、99％の時間がかかるC＃アプリケーションがあり、SqlDataReaderクリーニングとマッピングを実行してDataRowオブジェクトSqlBulkCopyに挿入し、a を使用してデータベースに挿入しています。

場合によっては（特にソースデータベースにvarbinaryオブジェクトとして画像が含まれている場合）、このプロセスはサーバーからアプリへのSQL転送で完全に停止し、その後すぐに向きを変えてサーバーに戻ることができます。

変換の一部をSSISパッケージとして書き直せば、大幅にスピードアップできると思います。しかし、私が直面し続ける最大の石垣は、上司がNot Invented Hereのように押し返し、「MicrosoftがSSISのサポートを終了したらどうなるでしょうか。この廃止されたコードはすべて手に入れられます。」

「もし彼らがその機能を削除したら...」を見つけたのはこれが初めてではありません。上司からの答え。古い方法で変換を記述したり、SSISを自己学習したり、利点を実証/テストする新しい方法を記述したりする時間がありません（SSISを使用したことがないため、使用方法を学習する必要があります）。

この状況ではどうすればよいですか？新しいテクノロジーの推進を停止しますか？彼が部門を去るまで待ってください（私は彼の後の部門で2番目にシニアの人ですが、彼が辞める/退職するまでに何年もかかる可能性があります）？彼がサードパーティのツールを恐れないようにする新しい方法を見つけましたか？

私は管理の観点からこれに亀裂を取りますが、私は詳細のすべてを持っていないことに気づいていることに留意してください。私が見るものを要約します：

1. 中間レベルの開発者は、彼を「Scott」と呼び、重要なプロセスProcessAのパフォーマンスを向上させるために、レガシーコードをSSISに書き直すことを推奨します。
2. 現在、ProcessAは機能状態で動作しており、重大な問題は確認されていません。
3. ProcessAは、一般的なまたは潜在的に部族の知識を使用して維持する独自のツールで記述されています。
4. 書き換えの推奨には、サポートする新しいツールが必要です。
5. 現在のスタッフには、新しいツールに関する文書化された経験/知識はありません。
6. 新しいツールは比較的古いツールの比較的新しいものであり、これらのツールのサポートは4営業四半期以内に合理的に変更される可能性があります。

この観点から見ると、壊れていないプロセスを改善するために会社が多額のお金を費やしているだけです。技術的な見地からは、私はその魅力を見ることができます。しかし、あなたがそれに真剣に取り組むと、この変更を行うことはビジネス上理にかなっていないだけです。このプロセスの大幅な改善を示すために、SSISとベンチマークに関する文書化された経験を持つスタッフがいる場合（大幅な改善は$$$に等しくなければならないことに注意してください）、結果は少し異なる場合があります。しかし、現状では、管理に同意する必要があります（どこかでツリーが枯れたところです）。

SSISの採用を促進し、このリファクタリングにつながる可能性がある場合は、小規模で重要性の低いプロジェクトでこの経験とトレーニングを獲得する必要があります。SSISのベンチマークとサポートを提供し、管理者が変更の実施を検討する前に、すべてのインフラストラクチャとサポートが整っていることを確認します。他の場所でツールを使用し、チームのメンバーがその使用法を経験し、サポートが変更されずにすべてを根絶するビジネスの「快適さ」要因があれば、あなたの視点に誰かを揺さぶる可能性が高くなります。それらがなければ、あなたはその引数で間違ったツリーをbarえています。

ばかげているように、「最良の」方法が最良の方法ではない場合があります。

編集：質問のいくつかの更新に応じて、回答にわずかな変更を投稿します。

プロセスが何らかの苦痛を経験している場合、それを書き換えることは依然として費用のかかるベンチャーになります。既存のコードを微調整するコストがパッケージの書き換えにどの程度かかるかを検討する必要があります。ソフトウェアだけでなく、人間とのインターフェイスプロセスへの影響も考慮してください。経営陣の賛同を得て書き直そうとするとき、それは常にお金に帰着し​​ます。現在の苦痛が現在コストをかけていること、または全体として大きくなることを示すことができなければ、経営陣はまだ利益を見ません。このコストは、必ずしも本質的に金銭的ではありません。スローダウンがダウンタイムの原因となるシステムを危険にさらしたり、侵入ベクトルやその他の「定量化が困難な」症状を引き起こした場合、その問題を金銭的リスクに変換する方法を見つける必要があります。たとえば、侵入ベクトル データの紛失、盗難、破損を引き起こす可能性のある侵入につながる可能性があります。会社は評判を失うか、必要なセキュリティ監査に失敗する可能性があります。重要なのは、問題のマネージャーに、変化の定量化可能なメリットを認識させることです。

ものを壊すことはスキルです

私は、「壊れていない場合」という議論を受け入れて、革新に失敗し、最終的に革新を余儀なくされたときに、すべてを変えて反応する場所で働いてきました。単に、物を壊すという経験がないからです。

物事を壊すには、成熟度、スキル、経験が必要です。

常に安全にプレイできる開発チームは、競合他社にとって最も簡単です。失敗し、ミスを犯し、壊れたものだけが、誠実なリスク評価を真に行うことができるチームのみです。

現状維持

確かに、現在のシステムは現在のビジネス要件を満たしています。これらの要件への将来の予期しない変更には当てはまりません。古いことわざにあるように、「幸運は準備されたものを好む」。

この質問は、SQLやパフォーマンスとは関係ありません。「より良い方法はありますか？」という質問をすることです。代替手段を試すことを恐れないでください。

あなたの上司は、現状維持のケースに苦しんでいます。

マヤの

完璧に機能するものはありません。

マヤ人は山腹で食物を育て続けました。すべての栄養素が洗い流され、人々を養う方法がなくなるまで。手遅れになるまで、彼らは同じことを続けた。

問題が発生したときに問題を修正する時間があると仮定すると、それは間違いです。

何をすべきか？

あなたの上司は条件付けのケースに苦しんでいます。現状を受け入れる人は、難しい決定を下す能力を欠いているので、しばしばそうします。挑戦に直面したとき、彼らは彼らが精通しているものに最も近いオプションを選択する傾向があります。

彼への恐怖は大きな動機です。未知または変化する条件への恐怖は、現状とは何かという彼の視点を揺るがします。彼はできるだけ早く条件を正常に戻そうとする傾向があります。

矛盾しない方法でアイデアを提示する必要があります。既に現状にあることでやりたいことの間で共通の基盤を見つけてみてください。彼の変化への恐怖を軽減する議論を提示し、大きな変化を引き起こさないタスクを完了したいという安心感を提供します。

赤ちゃんの一歩を踏み出す

プロジェクトを希望する方向に移動する変更を提供するのが最善ですが、小さな増分プロジェクトを使用します。むしろ、SSISのサポートに関する大きな質問で上司を攻撃します。コードに分離レイヤーを作成して、大きな添付ファイルを持つテーブルを処理するための「代替」メソッドをプラグインできるようにします。その後、すべての前提条件が既にプロジェクトに追加されているSSISを推奨するために進むことができます。これにより、変更を受け入れることで上司が構想するリスクが軽減されます。

時間がかかる

私の経験では、リスクテイカーはプロジェクトを動かし続け、現状維持はレンガの壁のようなものです。永続性は、障壁を打ち破る唯一の選択肢です。お問い合わせには引き続きNoとお答えください。

革新する時が来たとき。あなたは変化に直面しても恐れを知らないので、あなたの上司はすぐにあなたに向きを変えます。現状維持の人が探しているものであり、あなたはあなたの努力に対して報われるでしょう。以前の問い合わせがどれも受け入れられなかったとしても。変化を受け入れない変化に直面した企業にとって、あなたはすぐにかけがえのない資産になります。

変換の一部をSSISパッケージとして書き直せば、大幅にスピードアップできると思います。しかし、私が直面し続ける最大の石垣は、上司がNot Invented Hereのように押し返し、「MicrosoftがSSISのサポートを終了したらどうなるでしょうか。この廃止されたコードはすべて手に入れられます。」

私の意見では、SSISについての懐疑論は有効です。

• 熟練した開発者はブラックボックスが嫌いです。SSISパッケージの内部では多くの魔法が発生します。
• SSISパッケージのソース管理サポートが非常に不足しています。dtsxパッケージが十分にモジュール化されていない場合、SSIS dtsxファイルの差分とマージは悪夢のようです。
  • 対照的に、C＃コンソールアプリケーションは非常に透過的です。いつでもコードに従って、何が問題なのかを把握できます。

また、何か問題が発生した場合は、上司がフックにかかっていることを考慮してください。

• したがって、彼はこの問題について最優先の/唯一の意見を持つ権利があります。

古い方法で変換を記述したり、SSISを自己学習したり、利点を実証/テストする新しい方法を記述したりする時間がありません（SSISを使用したことがないため、使用方法を学習する必要があります）。

この状況ではどうすればよいですか？新しいテクノロジーの推進を停止しますか？彼が部門を去るまで待ってください（私は彼の後の部門で2番目にシニアの人ですが、彼が辞める/退職するまでに何年もかかる可能性があります）？彼がサードパーティのツールを恐れないようにする新しい方法を見つけましたか？

SSISの利点を実証できるように、SSISを十分に学習することをお勧めします。

そして、自習後、SSISがより「伝統的な」アプローチよりも大きな利点を提供し、上司にコースを変更するよう説得できない場合、別の仕事を見つけることをお勧めしますSSISを使用します。

ほとんどのマネージャータイプからほとんど常に行っている応答は次のようなものです：

「それは価値がありません、今は動作し、変更するには時間がかかります。」

そして一般的に、これは有効です。 しかし、これは必ずしも有効な議論ではありません。「ここで発明されていない」症候群を取り巻く中心的な問題は、物事が機能するか機能しないかではなく、その技術は無意味に書き直され、会社の時間を浪費し、実質的な価値を損なっているためです提供されている製品から。

何をすべきかを決める前に、ここで未発明が実際に起こっているかどうかを判断する必要があります。内部技術は理由で書かれたかもしれません。

技術が理由で書き直されていることの兆候：

• あなたが販売している技術も製品です。あなたがデータベースベンダーである場合、MySQLコードを使用すると、いくら時間を節約しても、多くの理由で危険なアイデアです。
• 内部技術は十分に維持されており、市販のソリューションの欠点に効果的に対処しながら、同等の基本機能を提供しています。
• この技術は開発チーム全体の生産性を向上させ、新しい開発者はそれが使用されている理由について簡単に販売されます。
• 会社が他の外部技術をうまく採用した他の例があります。
• OTSソリューションが中止または破損した場合、ビジネスはすぐに深刻な影響を受けます。
• ビジネスが非常に大きいため、低コストで高品質のツールを作成するためのリソースがあります（たとえば、Googleは、シートあたり$ 1000のMS SQLライセンスよりも低いデータベースを作成できる場合があります）

言い換えれば、チームはすでに解決された問題を解決することの欠点を理解しているが、ビジネスの観点から意味のある例外を慎重に行った。

「ここでは発明されていません」の兆候：

• すべてが内部にあるようで、すべての言い訳があります：「ええ、遅すぎました」、「ええ、マイクロソフトです、マイクロソフトが嫌いです」、「ええ、使いにくいです」など。
• 外部の技術が使用されている場合は、「うん、それは悪臭がするので、最終的には独自のものを書くつもりだ」と聞くでしょう。
• これらのコンポーネントの所有者には、作業可能な他のジョブがありません。
• ほとんどの新しい開発者は広く受け入れられているスキルセットを使用していますが、内部ツールに到達するにはかなりの時間がかかります
• 慎重に分析した結果、OTSソリューションからカスタムまたは他のOTSソリューションへの切り替えが「中止された場合はどうすればよいか」で明らかになります。このシナリオでは、ビジネスへの影響は最小限になります。たとえばString.Join()、.NET Frameworkから削除された場合、カスタムStringJoin()メソッドへの再実装は簡単になります。

言い換えると、NIHは、自分のコードの代わりに外部の技術が使用されている場合に客観的かつ現実的であることに失敗するパターンです。

技術が何らかの理由で書き直された場合、懸念を表明することは、上司から称賛され評価されるべきです。技術が実装されたとき、それは慎重な決定であったはずであり、決定をレビューすることはビジネスにとって良いことです。物事は時間の経過とともに変化するため、有効なポイントがあるかもしれません。過去に無駄になった時間、切り替えにかかる予測コスト、およびその他の情報に関する数値を提供できる場合、（理論的には）切り替えを主張できます。

あなたの経験を考えると、彼らはあなたの数字に同意しないかもしれませんが、それにもかかわらず、彼らは少なくともあなたの声を聞くべきです。尊敬を得るには時間がかかるかもしれません。

たとえ会話が上手くいかない場合、たとえあなたが礼儀正しいとしても、それは単に「ここでは発明されていない」かもしれません。その場合、おそらく簡単に修正できないのは人格や政治的な問題です。絶え間ない再発明によってひどく行き詰まった環境で働くことは、開発者とビジネスにとって有害で​​す。走る

（補足：ほとんどの企業では、NIHの要素は常に存在しますが、許容できるレベルであり、コードとプラクティスを定期的にレビューしている限り、ある程度は有罪ですが、問題になることはありません。）

まあ、それはすべて費用/便益分析についてです。

SSISに書き換えることで何が得られますか？速度？それは重要ですか？GUIで実行され、すべての時間を浪費するプロセスの場合、それを変更するために費やしたお金は、より幸せな顧客または社内の従業員が仕事をすることで取り戻されるため、スピードアップすることをお勧めしますソフトウェアを待っています。しかし、夜のバッチが午前12時に始まり、午前6時ではなく午前1時に終了する場合は、あまり意味がありません。ええ、その6倍速くなりますが、誰も違いを感じません。

そして、あなたの上司には良い点があります。マイクロソフトは、一部のテクノロジを放棄する傾向があります。VB6、Linq-to-SQL、ASPクラシック、COM + ...これは、非オープンソースソフトウェア（および、更新が不足した場合に組織が維持するには大きすぎるオープンソースソフトウェア）のリスクです。アプリケーションの中心である場合は、厳密に制御する必要があります。

ソフトウェアとは、顧客に価値を付加することであり、リスクをもたらしながら多くの利益をもたらさない技術的改善は、実際にはその役割を果たしません。

POC（概念実証）を開発し、それを上司にデモします。POCは、提案しているテクノロジーの実際のメリットを判断するのに役立ちます。その後、あなたと上司はテクノロジーについて話し、それを実装するための賛否両論を開発できます。

POCを開発するには、通常の作業時間以外に余分な時間を費やす必要があります。

SSISの観点からの補足として、私はそれを使用し、SSISパッケージを開発しました。実際に、SSISパッケージを使用して独自のロードプロセスを置き換えました。実際の顧客がロード時間について不平を言ったので、私たちはこれをしました。ロード時間はSSISによって大幅に短縮され、誰もが幸せになりました。

SSISは基本的に、ほとんどプログラミングを必要としないドラッグアンドドロップワークフローです。ブラックボックスがどのように機能するかを学習するには時間がかかります。そのため、チームが使用を開始する場合は考慮に入れる必要があります。

良い答え。壊れていない場合は、修正しないでください。追加するだけです

• パフォーマンスの問題は実際には当てはまるかもしれませんが、その「可能性がある」という言葉は危険です。最初にパフォーマンス診断を行うので、リソースに対処する前に、パフォーマンスの問題が何であるかを証明します。

• マイクロソフトの最新の「解決策」を検討する際には、MSがかつて非難し、その後廃止され、サポートされなくなったことで多くの人々が火傷を負ったことを考慮する必要があります。大幅な再コーディングをせずにソフトウェアを10年または20年実行したい場合は、非常に注意する必要があります。当社はそのようにひどく傷ついています。

離職はあなたの上司の考慮事項になります。SSISは、そのスキルセットを持っているプログラマと比較して、DBAアリーナに参入しています。あなたのアプリケーションが最初の変換を超えてSSISを使用しない場合、あなたのチームのように、ほとんどの人がそれを経験していないので、それを学び、新しいC＃プログラマーをスピードアップすることは理にかなっています。

SQL 7.0の「データ変換フレームワーク」としてルーツに戻ると、SSISは実際には.NET Frameworkよりも古いテクノロジーレイヤーであると上司に指摘できます。

上司がポイントを持っているのは、SSISがMicrosoft Sql ServerのStandardおよびEnterpriseバージョンの一部にすぎないという事実です。クライアントが小さなビジネスシナリオでアプリケーションがSql Express（または、MySQL、ADO.NETで動作するが、できません）で完全にうまくいく場合、それはクライアントがポニーアップするかなり大きな変更ですSSIS統合を使用します）。

さて、完全に明確にしておきましょう。IMO、NIHはソフトウェア開発会社にとってほとんど良いことではありません。非常に強力なツールやサービスの多くからあなたを締め出します。また、その面では偽善的です。会社はVisual Studioを作成しましたか？.NET Frameworkはどうですか？SQLサーバー？Windows？いいえ。既存のツールとプラットフォーム上でソフトウェアを構築します（クライアントも同様です）。したがって、一般に受け入れられており、コアビジネスの実行に役立つ可能性のあるツールを見つけた場合は、それを採用し、最新の状態を維持するために実装を維持する必要があるというリスクに耐えることを学びます。これらのツールのバージョン、またはそれらを置き換えます。上司が最初にWindows 95/98またはその周辺で実行するソフトウェアを開発したに違いない（長くない場合）その前、3.0 / 3.1など）。そうだとすれば、彼はWindowsワークステーションOSの6つのバージョンが出入りするのを見て、新しいプラットフォームで実行するためにソフトウェアを更新しなければならず、XPが正式にEOLされた別のものに直面しています。彼は文句を言うかもしれませんが、それは単にビジネスを行うためのコストです。

ただし、NIHの態度は、役立つと見なされる可能性のある1つまたは複数のテクノロジーを受け入れることを拒否した結果とは限りません。これらの拒否は、完全に有効な費用便益分析に基づいている可能性があります。私はビデオ監視およびアラーム監視会社に勤務しており、さまざまな新技術や製品を毎日サポートするかどうかを決定しています。通常、新しい技術を受け入れるかどうかの決定、およびサポートされているビューアおよびアラーム管理ソフトウェアの既存のヒープと一緒にそれを束縛することの苦痛は、主に顧客にとっての価値に基づいています。私は最近、新しいタイプのDVRとの大きな統合プロジェクトを終了しました。これは、既存の最大の顧客の1人が、他の有名で技術的に遅れのあるDVR製品からDVRにアップグレードすると言ったからです。そして彼らは私たちの助けを借りて、または助けなしでそれをするでしょう。一方、私たちは顧客がそれを使用しておらず、提供し始めたとしても価値がないと考えているため、大手メーカーの名前であっても、新しいメーカーを定期的に拒否しています。同じバージョンの私たちのバージョンに支払いたい。

古い方法で変換を記述したり、SSISを自己学習したり、利点を実証/テストする新しい方法を記述したりする時間がありません（SSISを使用したことがないため、使用方法を学習する必要があります）。

それは一種の問題ですね。あなたは他の人々にあなたのアイデアの生産性を危険にさらすように頼んでおり、あなたは彼らにそれが価値があることを示すために手足に出て行く気がありません。技術的リーダーシップをとるには、評判を落とすか、自由時間を使ってアイデアに価値があることを示す必要があります。

上司の視点から物事を見てみてください。あなたが置き換えようとしている機能は、あなたのソフトウェアがすることの中核であるように思えます（彼の「ねじれた」コメントを参照）。優れた管理者は、コアビジネスを自分の責任で外注することを知っています。彼は、将来消滅するかもしれない技術に農場を賭けることを当然心配している。コア機能が関与する場合、ここでは実際には発明されていませんが良いことです。

速度が機能である場合、物事を高速化する別の方法を見つける必要があります。それ以外の場合、クライアントよりも速度の方が重要な場合は、速度を落として忘れてください。

「壊れていないものを修正しない」というメリットはありますが、受け入れられている答えには同意しません。

受け入れられた答えは、問題が壊れていないという観点から来ています。中間レベルの経営者の観点から、これは事実です。開発者がC＃でETLソリューションを作成および保守するために費やした時間について、すぐに使用できるソリューションを購入する場合と比較してコスト分析を行うと、C＃ソリューションの作成には3〜4倍の時間がかかります10倍も維持し、コストがかかります（数値の参照を探しましたが、見つかりませんでした）。

会社のコアコンピテンシーでなければ、C＃でデータ変換を記述して維持する理由はほとんどありません。独自のソリューションは遅く、間違い（データの破損）、エッジケース、ETLクラス間の再利用がほとんどなく、脆弱です。正直なところ、C＃でETLの作成と保守に何日を費やしたいのですか？やった それはがらくたの負荷です。創造的な仕事とはかけ離れています。

ETLをビジネスとするInformaticaなどのツールを使用します。彼らは15年以上にわたってこの問題に取り組んできました。彼らはそれを解決しました。ツールはドラッグアンドドロップで、再利用性は組み込みであり、パフォーマンスも同様です。ほとんどの人（開発者もいない）は、Informaticaツールを使用してETLを作成できます。Informaticaを販売するつもりはありません。ツールを使用してください。車輪を再発明しないでください。

長期的には、Informaticaなどのツールを購入したり、SSISを使用したりすることで、長期的に何百万もの会社を節約できます。そして何よりも、ETLを維持したり、壊れたときにETLに責任を負ったりする必要はありません。

以前、SSISで簡単なタスクを実行しようとしました。

単純なタスクでも低から中レベルの複雑さのダイアグラムが生成されるため、非常に迷惑な場合があります（いいえ、ダイアグラム以外にそれを「コーディング」する方法はありません）。そして、私が知らなかったジムの答えによって指摘されたソース管理の問題。

副次的な問題：そのため、高速化のために、画像バルクのトランザクションのサイズを小さくすることをお勧めします。たとえば、5000個のロコードではなく800個ごとにします。そのトランザクションをサポートするために必要なI / Oのサイズを減らすことができます。