我的部门专门致力于将客户数据转换为我们的数据库架构，以便他们可以使用我们的软件。

现在，我们有一些C＃应用程序IDataReader（占99％的时间SqlDataReader），执行一些清理和映射，将其插入到DataRow对象中，然后使用将SqlBulkCopy其插入到我们的数据库中。

有时（尤其是当源数据库包含图像作为varbinary对象时），此过程实际上可能陷入从服务器到应用程序的SQL传输，然后又转过来再返回到服务器。

我觉得，如果我们将某些转换重写为SSIS软件包，则可以大大加快转换速度。但是，我遇到的最大障碍是当我的老板以“在这里没有发明”的方式退缩并说：“如果Microsoft放弃对SSIS的支持，那该怎么办？我们将拥有所有这些过时的代码，并且将被搞砸。”

这不是我第一次点击“如果他们删除了该功能...？” 我老板的回答。我没有时间以旧的方式编写转换，自我学习SSIS，也没有以新的方式编写它来演示/测试收益（我们都没有人使用过SSIS，所以会有一段时间必须学习如何使用它）。

在这种情况下我该怎么办？停止推广新技术？等到他离开部门后（我是继他之后部门中第二高的人，但是离职/退休可能还需要几年时间）？寻找一种新方法让他停止害怕第三方工具？

从管理的角度来看，我会尽力而为，但是请记住，我知道我没有所有细节。我将总结一下我所看到的：

1. 我们将中级开发人员称为“ Scott”，建议将遗留代码重写为SSIS，以提高重要流程ProcessA的性能。
2. ProcessA当前处于运作状态，没有已知的重大问题。
3. ProcessA是使用专有工具编写的，需要使用常见或潜在的部落知识来维护。
4. 建议重写将需要新的工具来支持。
5. 现有员工没有使用新工具的书面经验/知识。
6. 新工具是旧工具的相对较新的替代品，并且对这些工具的支持可能会在4个业务季度内发生合理变化。

从这个角度来看，我所看到的只是该公司在改善不中断流程方面的大量资金。从技术角度看，我可以看到这种吸引力，但是当您坚持到底时，进行此更改就没有商业意义。如果您有在SSIS和基准方面有记录的经验的人员来显示对该过程的巨大改进（请记住，大规模改进必须等同于$$$），那么结果可能会有所不同。但是，就目前情况而言，我必须同意管理层的意见（某个地方树刚刚死了）。

如果您想促进SSIS的采用并可能导致这种重构，则需要通过较小的，不太重要的项目获得此经验和培训。提供SSIS的基准和支持，并确保所有基础结构和支持均已就绪，然后管理层甚至可以考虑进行更改。一旦您在其他地方使用了该工具，团队中的人员就对它的使用有了经验，并且支持的业务“舒适”因素不会改变并使所有事情连根拔起，您将更有可能左右某人。没有这些，您将使用该参数来搞错错误的树。

听起来很愚蠢，但有时“最佳”方法并不是最佳方法。

编辑：为了对问题进行一些更新，我将对我的答案进行一些修改。

如果该过程遇到某种麻烦，将其重写仍然是一项代价高昂的冒险。您可能要考虑对现有代码进行微调的成本与重写程序包的成本相比。不仅要考虑对软件的影响，还要考虑对任何人机交互过程的影响。当试图让管理层接受重写时，它仍然总归结为金钱。除非您能证明当前的困境现在正在花钱，否则总的来说，管理层将看不到收益。该成本可能不一定是财务性质的。如果速度下降损害了导致停机的系统，引入了入侵向量或其他“难以量化”的症状，则您可能需要找到一种将问题转化为货币风险等值的方法。例如，入侵向量 可能会导致入侵，从而可能导致数据丢失，被盗或损坏。该公司可能会失去声誉或可能无法通过必要的安全审核。关键是让有问题的经理认识到变更的可量化收益。

破事是一种技能

我在很多地方都使用过“如果没有破损”这一论点，以至于他们无法创新，而当他们最终被迫进行创新时，他们会通过改变一切做出过度反应。仅仅是因为他们缺乏打破事物的经验。

打破事物需要成熟，技巧和经验。

始终保持安全的开发团队是竞争对手最容易超越的。只有失败，犯错和破损的团队才能真正进行诚实的风险评估。

保持现状

确实，当前的系统可以满足当前的业务需求。对于将来对这些要求的意外更改，情况并非如此。就像古老的谚语所说的那样，“财富更倾向于有准备的人”。

这个问题与SQL或性能无关。这是关于问“有没有更好的方法？”的问题 并且不害怕尝试其他选择。

您的老板遭受“ 保持现状”的困扰。

玛雅人的

没有什么能真正完美地工作。

玛雅人在山边继续种植食物。直到所有营养被冲走，他们才无法养活自己的人民。他们一直以同样的方式做事，直到为时已晚。

假设您有时间解决问题，这是一个错误。

该怎么办？

你的老板患上了调节病。接受现状的人经常这样做，因为他们缺乏做出困难决定的能力。面对挑战时，他们倾向于选择最接近他们熟悉的选项。

对他的恐惧是一个很大的动机。对未知或不断变化的条件的恐惧动摇了他对现状的看法。他将倾向于尝试使病情尽快恢复正常。

您需要以一种无冲突的方式提出想法。尝试找到您想要做的事情与已经存在的现状之间的共同点。提出减少他对变更的恐惧的论据，并向您保证要完成不会造成重大改变的任务。

迈出婴儿的脚步

最好通过小型增量项目来提供使项目朝您想要的方向移动的更改。然后，向您的老板询问有关支持SSIS的大问题。提供在代码中创建一个分离层的功能，该层允许您插入“替代”方法来处理具有大附件的表。然后，您可以继续向SSIS推荐所有已具备的先决条件的项目。通过接受更改，这可以减少老板设想的风险。

这需要时间

我的经验是，风险承担者使项目保持运转，而现状保持者就像一堵砖墙。坚持是打破障碍的唯一选择。希望不断听到没有您的垂询。

是时候进行创新了。您的老板会迅速求助于您，因为您面对变化时会表现出无所畏惧。一个正在寻找现状的人，您的努力将会得到回报。即使您以前的查询都没有被接受。在面临无变化的变革的公司中，您将迅速成为不可替代的资产。

我觉得，如果我们将某些转换重写为SSIS软件包，则可以大大加快转换速度。但是，我遇到的最大障碍是当我的老板以“在这里没有发明”的方式退缩并说：“如果Microsoft放弃对SSIS的支持，那该怎么办？我们将拥有所有这些过时的代码，并且将被搞砸。”

我认为，对SSIS的怀疑是正确的。

• 经验丰富的开发人员讨厌黑匣子，并且SSIS包内部发生了很多魔术。
• 严重缺乏对SSIS包的源代码控制支持。如果您的dtsx软件包没有足够的模块化，则与SSIS dtsx文件进行区分和合并可能是一场噩梦。
  • 相比之下，C＃控制台应用程序非常透明。您始终可以按照代码来找出问题所在。

另外，如果出现任何问题，请考虑老板已陷入困境。

• 因此，他有权对此事拥有最高/唯一的意见。

我没有时间以旧的方式编写转换，自我学习SSIS，也没有以新的方式编写它来演示/测试收益（我们都没有人使用过SSIS，所以会有一段时间必须学习如何使用它）。

在这种情况下我该怎么办？停止推广新技术？等到他离开部门后（我是继他之后部门中第二高的人，但是离职/退休可能还需要几年时间）？寻找一种新方法让他停止害怕第三方工具？

我建议您充分学习SSIS，以便可以证明其优势。

并且，如果您在自学之后发现SSIS相对于“传统”方法而言具有显着的优势，而您仍然不能说服老板改变方向，那么我建议您找到一份可以从事的工作。使用SSIS。

您几乎总是会从大多数经理类型得到的响应是这样的：

“这不值得，现在就可以使用，而且要花时间进行更改。”

通常，这是有效的。 但是，这并不总是正确的论据，因为围绕“未在这里发明”综合症的核心问题不是事情是否有效，而是技术被无意义地重写，浪费了公司的时间并降低了实质性的价值。从所交付的产品中。

您需要确定“未发明这里”是否确实在发生，然后再决定要做什么。内部技术可能是出于某种原因编写的。

表示技术被重写的原因如下：

• 您所销售的技术也是产品。如果您是数据库供应商，那么使用MySQL代码，无论它将节省多少时间，出于多种原因都是一个危险的主意。
• 内部技术维护良好，可以有效解决现成解决方案的缺点，同时仍提供可比的基本功能。
• 该技术提高了整个开发团队的生产力，并且可以很容易地就其使用原因向新开发人员出售。
• 公司还有其他成功采用其他外部技术的例子。
• 您的企业将被立即和严重影响，如果OTS解决方案被中止或破裂。
• 这项业务如此庞大，以至于它有足够的资源以低成本编写高质量的工具（例如，Google能够编写成本低于$ 1000 /座的MS SQL许可证的数据库）

换句话说，团队理解重新解决已经解决的问题的弊端，但是从业务角度来看，明智地做出了例外处理。

“此处未发明”的迹象：

• 似乎所有内容都是内部的，所有内容都有借口：“嗯，它太慢了”，“嗯，这是Microsoft，我们讨厌Microsoft”，“嗯，它看起来真的很难使用”，等等。
• 对于使用外部技术的情况，您会听到“是的，它很臭，我们计划最终编写自己的技术 ”。
• 这些组件的所有者没有他们可以从事的其他工作。
• 您会看到大多数新开发人员都具备广泛接受的技能，但是他们花大量时间才能升级到内部工具
• 经过仔细的分析，很明显，在“如果停止的话！”中，从OTS解决方案切换到定制或其他OTS解决方案！这种情况对商业的影响最小。例如，如果String.Join()将其从.NET Framework中删除，则重新实现自定义StringJoin()方法将变得很简单。

换句话说，NIH是在使用外部技术而非自己的代码的情况下无法保持客观和现实的模式。

当技术由于某种原因而被重写时，上司应该赞扬和赞赏您提出的问题。实施该技术时应该是一个谨慎的决定，并且偶尔回顾该决定对企业来说是有好处的。事情确实会随着时间而改变，您可能有一个正确的观点。如果您可以提供有关过去浪费的时间，预计的转换成本以及其他信息的数字，那么（理论上）您可以提出转换的理由。

请了解，根据您的经验，他们可能不同意您的电话号码，但是无论如何，他们至少应该听到您的声音。获得尊重可能需要一些时间。

如果即使您彬彬有礼，甚至无法进行对话，则可能只是“此处未发明”。在这种情况下，很可能是您无法轻易解决的人格或政治问题。在持续不断的重新发明严重困扰的环境中工作对开发人员和企业都是有害的。跑。

（旁注：在大多数公司中，NIH总是有一个要素，但它是在可以容忍的水平上，只要他们定期审查其守则和实践即可。永远不会成为问题。）

好吧，这全是关于成本/收益分析的。

通过将其重写为SSIS，您可以获得什么？速度？有关系吗？如果它的过程在GUI中执行并浪费了每个人的时间，那么是的，加快它的速度可能是个好主意，因为花在更改它上的钱将由更满意的客户或内部员工来代替他们的工作来获得等待软件。但是，如果它的夜间批次从12am开始，并且将在1am而不是6am结束...那没有什么意义。是的，它的速度快了6倍，但没有人会感到与众不同。

而且你的老板确实有一个好处。Microsoft确实倾向于放弃某些技术。VB6，Linq-to-SQL，ASP经典，COM + ...这对于任何非开放源代码软件（以及对于缺乏更新而无法维护的开放源代码软件）来说都是一种风险。如果它对您的应用程序至关重要，则应该对其进行严格控制。

软件就是要为客户增加价值，而在带来风险的同时却不能带来太大收益的技术改进并不能真正发挥作用。

开发一个POC（概念验证），然后将其演示给您的上级。POC应该可以帮助您确定所提议技术的任何真正好处。然后，您和您的上级可以讨论该技术，并开发实现该技术的利弊。

您可能需要在正常工作时间之外花费一些额外的时间来开发POC。

作为SSIS观点的补充说明，我已经使用它并开发了SSIS软件包。实际上，我们使用SSIS软件包替换了专有的加载过程。我们这样做是因为实际客户抱怨加载时间。使用SSIS，加载时间显着减少，每个人都变得更加快乐。

SSIS基本上是一个拖放式工作流程，几乎不需要编程。学习黑匣子的工作方式确实需要花费一些时间，因此，如果您的团队开始使用黑匣子，则需要考虑这一点。

好答案。如果没有损坏，请不要修复。我只会添加

• 尽管性能问题可能确实是正确的，但“可能”一词却是一个危险信号。我将首先进行性能诊断，因此在投入任何资源来解决该问题之前，我将获得性能问题的证明。

• 在考虑Microsoft的最新“解决方案”时，应该考虑到，许多人曾经被MS曾经吹捧过的东西烧死了，但是后来弃用了，然后又被取消了支持。如果您希望软件在不进行大量重新编码的情况下运行10或20年，则应非常谨慎。这样对我们公司造成了严重伤害。

营业额将是您老板的考虑因素。与具有该技能的程序员相比，SSIS正在进入DBA领域。如果您的应用程序在初始转换后没有使用SSIS，我不确定是否有必要学习它并让新的C＃程序员快速入门，因为像您的团队一样，大多数人都没有使用它的经验。

您可以向您的老板指出，如果您将SSIS的根源追溯到SQL 7.0的“数据转换框架”，那么它实际上是比.NET Framework更旧的技术层。

您的老板可能会指出的事实是SSIS只是Microsoft Sql Server的标准版和企业版的一部分；对于您的客户来说，这是一个相当大的改变，当您的应用程序在小型企业场景中，使用Sql Express（或MySQL）就可以很好地解决（就此而言，它可以与ADO.NET一起使用，但不能使用SSIS集成）。

现在，让我说清楚。IMO，NIH对软件开发公司来说几乎从来不是一件好事。它使您无法使用许多非常强大的工具和服务。它的表面也是虚伪的。贵公司是否编写了Visual Studio？.NET Framework怎么样？SQL服务器？视窗？不。您可以在已经拥有的工具和平台上构建软件（客户也可以如此）。因此，如果您看到一种获得普遍认可的工具，并且该工具可能对您的核心业务有用，那么您就可以采用它，并且您将学会承受这样的风险，即必须维护自己的实施以跟上最新的发展。这些工具的版本，甚至取代它们。我敢打赌，您的老板首先开发了可在Windows 95/98或更高版本（如果时间不长）上运行的软件在此之前，例如3.0 / 3.1）。如果是这样，他已经看到了六种版本的Windows工作站操作系统问世，并且不得不更新他的软件以在较新的平台上运行，并且他还面临着另一种XP正式EOLed。尽管他可能会抱怨，但这仅仅是做生意的成本。

但是，NIH的态度并不一定是因为拒绝接受一种甚至多种可能被认为有用的技术。那些拒绝可以基于完全有效的成本效益分析。我在一家视频监视和警报监视公司工作，我们每天都会做出决定是否支持各种新技术或产品的决定。通常，接受一项新技术的决定以及将其与我们现有的受支持的查看器和警报管理软件组合在一起的痛苦，主要是基于对我们的客户而言有价值的。我最近完成了与新型DVR的大型集成项目，这仅仅是因为我们最大的现有客户之一表示他们正在从另一种知名但技术落后的DVR产品升级到该DVR，无论有没有我们的帮助，他们都会这样做。另一方面，我们经常拒绝新的制造商，甚至拒绝主要的家喻户晓的品牌，这仅仅是因为我们的客户不使用它，并且即使它失去了一些拥有它而又没有的潜在客户，我们也开始提供它没有任何价值。不想为我们的相同版本付费。

我没有时间以旧的方式编写转换，自我学习SSIS，也没有以新的方式编写它来演示/测试收益（我们都没有人使用过SSIS，所以会有一段时间必须学习如何使用它）。

那是个问题，不是吗？您要让其他人冒着他们的主意冒险的风险，并且您不愿意费力地向他们展示这是值得的。技术领导力需要冒着名声或空闲时间来证明自己的想法值得拥有的风险。

尝试从老板的角度看待事情。听起来您要替换的功能是软件功能的核心（请参见他的“拧紧”评论）。一个好的经理知道您将自己的核心业务外包给自己，后果自负。他担心将农场押在某些将来可能会消失的技术上，这是理所当然的。当涉及到核心功能时，“在这里不发明”实际上是一件好事。

如果速度是一项功能，那么您将不得不寻找另一种加快速度的方法。否则，如果速度对您而言比对您的客户而言更重要，那么我就说放弃它，而忘了它。

尽管有“不解决未解决的问题”的优点，但我不同意已接受的答案。

可接受的答案来自问题未解决的观点。从中层管理人员的角度来看，这是正确的。如果要对开发人员用C＃创建和维护ETL解决方案所花费的时间进行成本分析，而不是购买现成的解决方案，则表明C＃解决方案创建时间要长3-4倍并维持和花费多达10倍的成本（我在数字上寻找参考，但找不到）。

除非这是公司的核心竞争力，否则几乎没有理由用C＃编写和维护数据转换。本地解决方案将很慢，会出现错误（即数据损坏），会出现边缘情况，在ETL类之间几乎没有重用，并且会很脆弱。老实说，什么开发人员想用他/她的一天来编写和维护C＃中的ETL？我做完了 这真是胡扯。它离创造性工作的极限远。

使用Informatica这样的工具，该公司的业务是ETL。他们解决这个问题已有15年以上。他们解决了。他们的工具是拖放式的，可重用性是内置的，性能也是如此。大多数人（即开发人员也没有）可以使用Informatica工具创建ETL。我不打算出售Informatica，请使用任何工具。只是不要重新发明轮子。

从长远来看，购买Informatica之类的工具或使用SSIS从长远来看将为公司节省数百万美元。而且，最重要的是，当ETL中断时，您将不必维护或对其负责。

我曾经尝试过SSIS做简单的任务。

这可能非常烦人，因为即使是简单的任务也会产生低到中级的复杂性图表（不，除了图表之外，没有其他方法可以对其进行“编码”）。我不知道，吉姆的答案指出了源代码控制问题。

附带问题：因此，为了加快速度，我建议减小图像批量的事务大小。说，每800而不是5000 rocord。它可以减少支持该事务所需的I / O大小。