Vou dar uma olhada nisso do ponto de vista gerencial, mas tenha em mente que estou ciente de que não tenho todos os detalhes. Vou resumir o que vejo:

1. O desenvolvedor de nível médio, nós o chamamos de "Scott", recomenda uma reescrita do código legado no SSIS para melhorar o desempenho do processo importante ProcessA.
2. O ProcessA está atualmente se comportando em um estado funcional sem problemas importantes conhecidos.
3. O ProcessA é escrito com ferramentas proprietárias usando conhecimento comum ou potencialmente tribal para manter.
4. A recomendação para reescrever exigirá novas ferramentas para suporte.
5. A equipe atual não tem experiência / conhecimento documentado com as novas ferramentas.
6. Novas ferramentas são substituições relativamente recentes para ferramentas mais antigas, e o suporte para essas ferramentas pode mudar razoavelmente dentro de quatro áreas comerciais.

Dessa perspectiva, tudo o que vejo é um grande gasto de dinheiro por parte da empresa para melhorar um processo que não está quebrado . Do ponto de vista técnico, posso ver o apelo, mas, quando você chega até ele, não faz sentido comercial fazer essa mudança. Se você tivesse uma equipe à mão com experiência documentada com o SSIS e benchmarks para mostrar melhorias maciças nesse processo (lembre-se, a melhoria massiva DEVE ser igual a $$$), o resultado pode ser um pouco diferente. No momento, porém, eu teria que concordar com o gerenciamento (em algum lugar uma árvore acabou de morrer).

Se você quiser promover a adoção do SSIS e possivelmente liderar esse refatorador, precisará obter essa experiência e treinamento com projetos menores e menos importantes. Forneça benchmarks e suporte para o SSIS, e certifique-se de que toda a infraestrutura e suporte estejam em vigor antes que o gerenciamento considere a possibilidade de fazer a mudança. Uma vez que você tenha a ferramenta em uso em outro lugar, as pessoas da equipe experimentaram seu uso, e um fator de "conforto" de negócios que suporte não irá mudar e desenraizar tudo, você estará mais propenso a influenciar alguém ao seu ponto de vista. Sem eles, você está latindo na árvore errada com esse argumento.

Tão estúpido quanto parece, às vezes o "melhor" caminho não é o melhor caminho.

Edit: Em resposta a algumas atualizações da questão, postarei uma pequena modificação na minha resposta.

Se o processo estiver sofrendo algum tipo de problema, reescrevê-lo ainda será um empreendimento caro. Você pode querer considerar qual seria o custo de ajustar o código existente contra a regravação do pacote. Considere os impactos não apenas no software, mas em qualquer processo de interface humana. Ao tentar obter o buy-in gerencial para uma reescrita, ele sempre será reduzido ao dinheiro. A menos que você possa mostrar que a angústia atual está custando dinheiro agora ou se tornará grande no agregado, a administração ainda não verá o benefício. Esse custo pode não ser necessariamente financeiro por natureza. Se a lentidão comprometer um sistema que causa paralisação, introduzir vetores de intrusão ou algum outro sintoma "difícil de quantificar", talvez seja necessário encontrar uma maneira de traduzir esse problema em um equivalente de risco monetário. Um vetor de intrusão, por exemplo, pode levar a uma intrusão que pode resultar em dados perdidos, roubados ou corrompidos. A empresa pode perder reputação ou pode falhar em uma auditoria de segurança necessária. A chave é fazer com que o gerente em questão reconheça os benefícios quantificáveis da mudança.

Quebrar as coisas é uma habilidade

Eu trabalhei em muitos lugares que abraçaram o argumento "se não está quebrado" ao ponto de não inovarem, e quando finalmente são forçados a inovar, reagem mudando tudo . Simplesmente porque eles não têm a experiência de quebrar coisas .

É preciso maturidade, habilidade e experiência para quebrar as coisas.

As equipes de desenvolvimento que sempre jogam com segurança são as mais fáceis para um concorrente superar. Apenas as equipes que falharam, cometeram erros e quebraram as coisas são capazes de realmente fazer avaliações de risco honestas.

Mantendo o status quo

Embora seja verdade, o sistema atual atende aos requisitos de negócios atuais. Isso não é verdade para as futuras mudanças imprevistas desses requisitos. Como diz o velho provérbio, "a fortuna prefere o preparado".

Esta questão não tem nada a ver com SQL ou desempenho. É sobre fazer a pergunta "há uma maneira melhor?" e não ter medo de tentar uma alternativa.

Seu chefe sofre de um caso de Manter o status quo .

Os maias

Nada está funcionando perfeitamente.

Os maias continuavam cultivando a comida do lado das montanhas. Até que todos os nutrientes fossem lavados e não tivessem como alimentar seu povo. Eles continuaram fazendo as coisas da mesma maneira até que fosse tarde demais.

Supondo que você tenha tempo para resolver um problema quando o problema se apresenta é um erro.

Oquefazer?

Seuchefesofredeumcasodecondicionamento.Aspessoasqueaceitamostatusquogeralmenteofazemporquenãotêmacapacidadedetomardecisõesdifíceis.Quandoenfrentamumdesafio,tendemaescolheraopçãomaispróximadoqueestãofamiliarizados.

Omedoporeleéumagrandemotivação.Omedododesconhecidooudascondiçõesmutáveisabalasuaperspectivadoqueéostatusquo.Eletenderáatentardevolverascondiçõesaonormalomaisrápidopossível.

Vocêprecisaapresentarideiasdemaneiranãoconflitante.Tenteencontrarumabasecomumentreoquevocêgostariadefazercomoquejáéostatusquo.Apresenteargumentosquereduzamseumedodemudançaeofereçagarantiasdequevocêdesejaconcluirumatarefaquenãocausarámudançassignificativas.

Tomepassosdebebê

Seriamelhoroferecermudançasquemovamoprojetonadireçãodesejada,maspormeiodepequenosprojetosincrementais.Emvezdisso,acerteseuchefecomagrandeperguntasobreosuporteaoSSIS.Ofereça-separacriarumacamadadeseparaçãonocódigoquepermitaquevocêfaçaoplug-indemétodos"alternativos" para processar tabelas com anexos grandes. Você pode então avançar para recomendar o SSIS com todos os pré-requisitos já adicionados ao projeto. Isso reduz o risco que seu chefe prevê, aceitando a mudança.

Leva tempo

Minha experiência tem sido que os tomadores de risco mantêm um projeto em movimento, e os detentores do status quo são como uma parede de tijolos. A persistência é sua única opção para derrubar suas barreiras. Espere continuar ouvindo Não para suas dúvidas.

Quando chega a hora de inovar. Seu chefe se voltará para você rapidamente, porque você demonstra destemeriedade diante da mudança. Algo que uma pessoa do status quo estará procurando, e você será recompensado por seus esforços. Mesmo que nenhuma de suas perguntas anteriores tenha sido aceita. Você rapidamente se tornará um ativo insubstituível em uma empresa que enfrenta mudanças que não envolvem mudanças.

I feel that if we re-wrote some of the conversions as SSIS packages it could speed things up a lot. However the biggest stonewall I keep running into is when my boss, in Not Invented Here fashion, pushes back and says "What if Microsoft drops support for SSIS? We will have all this obsolete code and we will be screwed."

Na minha opinião, o ceticismo sobre o SSIS é válido.

• Os desenvolvedores experientes odeiam caixas pretas e há muita mágica que acontece dentro de um pacote do SSIS.
• O suporte ao controle de origem para pacotes do SSIS é extremamente insuficiente. Difundir e mesclar arquivos SSIS dtsx pode ser um pesadelo se seus pacotes dtsx não forem suficientemente modulares.
  • Por outro lado, os aplicativos de console C # são muito transparentes. Você sempre pode seguir o código para descobrir o que está errado.

Além disso, considere que seu chefe está no gancho, se algo der errado.

• Portanto, ele tem o direito de ter a única e única opinião sobre o assunto.

I don't have the time to write the conversion the old way, self-teach myself SSIS, and also write it the new way to demonstrate/test the benefits (None of us have used SSIS so there would be a period where we would have to learn how to use it).

What should I do in this situation? Stop pushing the new technology? Wait till he leaves the department (I am the 2nd most Sr. person in the department after him, but it could be years before he quits/retires)? Find a new way of getting him to stop being afraid of 3rd party tools?

Eu recomendo que você aprenda o SSIS bem o suficiente para que você possa demonstrar seus benefícios.

E se, após o seu estudo autodidático, você descobrir que o SSIS oferece vantagens significativas em relação à abordagem mais "tradicional" e ainda não conseguir convencer seu chefe a mudar de curso, recomendo que você encontre um trabalho diferente em que você pode usar o SSIS.

A resposta que você está quase sempre indo da maioria dos tipos de gerenciadores é algo como:

"Não vale a pena, funciona agora e vai custar tempo para mudar."

E, em geral, isso é válido. No entanto, nem sempre é um argumento válido, porque a questão central em torno da síndrome "Não inventada aqui" não é se as coisas funcionam ou não funcionam, mas que a tecnologia está sendo desnecessária escrito , desperdiçando horas da empresa e diminuindo o valor substancial do produto que está sendo entregue.

Você precisa determinar se o Inventado Aqui está realmente ocorrendo antes de decidir o que fazer. O técnico interno pode ter sido escrito por um motivo .

Sinais de que a tecnologia é reescrita por um motivo:

• A tecnologia que você está vendendo é também o produto . Se você é um fornecedor de banco de dados, usar o código do MySQL, não importa quanto tempo economize, é uma ideia perigosa por vários motivos.
• A tecnologia interna é bem mantida e aborda efetivamente as deficiências da solução pronta para uso, ao mesmo tempo em que fornece funcionalidade básica comparável.
• A tecnologia melhora a produtividade de toda a equipe de desenvolvimento, e novos desenvolvedores são facilmente vendidos sobre o motivo pelo qual ela está em uso.
• Existem outros exemplos em que a empresa conseguiu adotar outras tecnologias externas .
• Seu negócio seria imediatamente e seriamente afetado se a solução OTS fosse descontinuada ou quebrada.
• O negócio é tão grande que tem recursos para escrever ferramentas de alta qualidade a baixo custo (por exemplo, o Google pode criar um banco de dados que custa menos de US $ 1.000 / licença MS SQL )

Em outras palavras, a equipe entende as desvantagens de resolver problemas já resolvidos, mas fez exceções criteriosamente onde fazia sentido do ponto de vista comercial.

Sinais de "não inventados aqui":

• Parece que tudo é interno , e há desculpas para tudo: "uh, foi muito lento", "uh, é a Microsoft, odiamos a Microsoft", "uh, parece realmente difícil de usar ", etc.
• Para os casos em que a tecnologia externa está sendo usada, você ouve "sim, bem, fede e planejamos escrever nossa própria, eventualmente ".
• Os proprietários desses componentes não têm outros trabalhos em que são capazes de trabalhar.
• Você vê a maioria dos novos desenvolvedores entrando com um conjunto de habilidades amplamente aceito, mas leva um tempo considerável para que eles avancem para o conjunto de ferramentas internas
• Após uma análise cuidadosa, torna-se aparente que a mudança da solução OTS para uma solução personalizada ou outra solução OTS em o "e se for descontinuado!" cenário teria um impacto comercial mínimo . Por exemplo, se String.Join() fosse removido do .NET Framework, a reimplementação para um método StringJoin() personalizado seria trivial.

Em outras palavras, o NIH é o padrão de não ser objetivo e realista nos casos em que a tecnologia externa está sendo usada em vez do próprio código.

Quando a tecnologia é reescrita por um motivo, apresentar suas preocupações deve ser elogiado e apreciado por seus superiores. Deveria ter sido uma decisão cuidadosa quando a tecnologia foi implementada, e rever a decisão ocasionalmente é bom para o negócio. As coisas mudam com o tempo e você pode ter um ponto válido. Se você puder fornecer números sobre o tempo desperdiçado no passado, os custos projetados para alternar e outras informações, você pode (em teoria) defender a mudança.

Entenda que, dada a sua experiência, eles podem não concordar com seus números, mas, independentemente disso, eles devem pelo menos ouvi-lo. Pode levar algum tempo para ganhar respeito.

Se a conversa não puder ser atualizada, mesmo que você esteja sendo educado, talvez seja "Não inventada aqui". Nesse caso, é mais provável que seja uma personalidade ou problema político que você provavelmente não pode corrigir facilmente. Trabalhar em um ambiente que é strongmente atolado pela constante reinvenção é tóxico para os desenvolvedores e os negócios. Executar.

(Nota: Na maioria das empresas, há sempre um elemento do NIH, mas está em um nível tolerável, e desde que eles revisem regularmente seus códigos e práticas. No longo prazo, somos todos culpados por isso a um grau, mas nunca se torna um problema.)

Bem, é tudo sobre a análise de custo / benefício.

O que você ganha ao reescrevê-lo no SSIS? Rapidez? Isso importa? Se é um processo que é executado em uma GUI e desperdiça tempo a todos, então, provavelmente é uma boa idéia acelerar, porque o dinheiro gasto na alteração será ganho pelo cliente mais feliz ou pelo funcionário interno fazendo seu trabalho em vez de esperando pelo software. Mas se é um lote noturno que começa às 12h e termina às 1h em vez das 6h ... não há muito sentido. Sim, é 6 vezes mais rápido, mas ninguém vai sentir a diferença.

E seu chefe tem um bom argumento. A Microsoft tende a abandonar algumas de suas tecnologias. VB6, Linq-to-SQL, ASP clássico, COM + ... Este é um risco com qualquer software de código aberto (e software de código aberto que seria grande demais para a sua organização manter em caso de falta de atualização). Se é central para sua aplicação, você deve ter um controle rígido sobre isso.

O software tem tudo a ver com agregar valor ao cliente, e melhorias técnicas que não geram muito benefício, ao mesmo tempo que introduzem riscos, não cumprem realmente esse papel.

Desenvolva um POC (Prova de Conceito) e depois demonstre para o seu superior. O POC deve ajudá-lo a determinar qualquer benefício real com a tecnologia que você está propondo. Então você e seu superior podem falar sobre a tecnologia e desenvolver prós e contras para implementá-la.

Você provavelmente terá que gastar algum tempo extra fora do horário normal de trabalho para desenvolver o POC.

Como uma nota secundária do ponto de vista do SSIS, usei-o e desenvolvi pacotes do SSIS. Na verdade, substituímos um processo de carregamento proprietário usando pacotes do SSIS. Nós só fizemos isso porque os clientes reais reclamaram dos tempos de carregamento. Os tempos de carregamento diminuíram significativamente com o SSIS e todos ficaram mais felizes.

O SSIS é basicamente um fluxo de trabalho de arrastar e soltar com muito pouca programação envolvida. Leva algum tempo para aprender como a caixa preta funciona, então você precisará levar isso em consideração se sua equipe começar a usá-la.

Boas respostas. Se não está quebrado, não conserte. Eu adicionaria apenas

• Embora as preocupações com desempenho possam ser verdadeiras, a palavra "might" é um sinal vermelho. Eu faria o diagnóstico de desempenho primeiro, então eu teria uma prova de qual era o problema de desempenho, antes de comprometer quaisquer recursos para resolvê-lo.

• Ao considerar a mais recente "solução" da Microsoft, deve-se considerar que muitas pessoas foram queimadas pelo que a MS já divulgou, mas depois foram reprovadas e, em seguida, desprovidas de suporte. Se você quiser que o software seja executado por 10 ou 20 anos sem grandes recodificações, você deve ser muito cauteloso com isso. Nossa empresa foi gravemente ferida dessa maneira.

O volume de negócios será considerado pelo seu chefe. O SSIS está entrando na arena do DBA comparado a um programador que possui esse conjunto de habilidades. Se seu aplicativo não usa o SSIS além da conversão inicial, não tenho certeza se faz sentido aprendê-lo e obter novos programadores de C # atualizados porque, como sua equipe, a maioria não tem nenhuma experiência com ele.

Você poderia indicar ao seu chefe que o SSIS é, na verdade, uma camada de tecnologia mais antiga que o .NET Framework, se você voltar às suas raízes como o "Data Transformation Framework" do SQL 7.0.

Onde seu chefe pode ter um ponto no fato de que o SSIS é apenas uma parte das versões Standard e Enterprise do Microsoft Sql Server; isso é um grande pedaço de mudança para seus clientes desembolsarem, quando seu aplicativo, em um cenário de pequena empresa, pode estar perfeitamente bem com o Sql Express (ou o MySQL, que funciona com o ADO.NET, mas não pode usar a integração SSIS).

Agora, deixe-me ser perfeitamente claro; IMO, NIH quase nunca é uma coisa boa para uma casa de desenvolvimento de software. Ele bloqueia muitas ferramentas e serviços muito poderosos. Também é hipócrita em sua face; sua empresa escreveu o Visual Studio? Como sobre o .NET Framework? Servidor SQL? Janelas? Não. Você constrói seu software em cima das ferramentas e plataformas que você já tem (e seus clientes também). Portanto, se você vir uma ferramenta que está ganhando aceitação geral e isso pode ser útil para realizar seu negócio principal, você a adota e aprende a viver com o risco de ter que manter sua implementação para acompanhar as últimas versões dessas ferramentas, ou até mesmo substituí-las. Aposto que seu chefe primeiro desenvolveu o software para rodar no Windows 95/98 ou por aí (se não longo antes disso, como 3.0 / 3.1). Em caso afirmativo, ele viu meia dúzia de versões dos sistemas operacionais da estação de trabalho Windows e teve que atualizar seu software para rodar nas plataformas mais novas, e está enfrentando outra com o XP oficialmente EOLed. Embora ele possa reclamar, isso é simplesmente o custo de fazer negócios.

No entanto, uma atitude do NIH não decorre necessariamente da recusa em aceitar um, ou mesmo um número, de tecnologias que possam ser consideradas úteis. Essas recusas podem basear-se em análises de custo-benefício perfeitamente válidas. Eu trabalho para uma empresa de vigilância por vídeo e monitoramento de alarmes, e tomamos decisões para apoiar ou não várias novas tecnologias ou produtos diariamente. Normalmente, a decisão de aceitar uma nova tecnologia, e a dificuldade de evitá-la junto com o nosso monte de softwares suportados de visualização e gerenciamento de alarmes, baseia-se principalmente no que vale para nossos clientes. Eu terminei recentemente um grande projeto de integração com um novo tipo de DVR, simplesmente porque um dos nossos maiores clientes existentes disse que eles estavam atualizando para esse DVR de outro produto de DVR de grande nome, mas tecnologicamente atrasado, e fariam isso com ou sem o nosso Socorro. Por outro lado, rejeitamos regularmente novos fabricantes, até mesmo os principais nomes familiares, simplesmente porque nossos clientes não o usam e não vemos valor em começar a oferecê-lo, mesmo que isso nos perca alguns clientes em potencial que o possuem e não o fazem. Não quero pagar pela nossa versão da mesma coisa.

I don't have the time to write the conversion the old way, self-teach myself SSIS, and also write it the new way to demonstrate/test the benefits (None of us have used SSIS so there would be a period where we would have to learn how to use it).

Esse é o tipo de problema, não é? Você está pedindo a outras pessoas para arriscar sua produtividade em sua idéia, e você não está disposto a sair em um membro para mostrar que vale a pena. A liderança técnica exige que você arrisque sua reputação ou seu tempo livre para mostrar que suas ideias valem a pena.

Tente ver as coisas do ponto de vista do seu chefe. Parece que a funcionalidade que você está tentando substituir é fundamental para o que seu software faz (cf. seu comentário "parafusado"). Um bom gerente sabe que você terceiriza seu negócio principal por sua própria conta e risco. Ele está corretamente preocupado em apostar a fazenda em algum pedaço de tecnologia que pode desaparecer no futuro. Quando as funções principais estão envolvidas, o Not Invented Here é realmente uma coisa boa.

Se a velocidade é uma característica, você terá que encontrar outra maneira de acelerar as coisas. Caso contrário, se a velocidade é mais importante para você do que para seus clientes, eu digo desistir e esquecer isso.

Embora haja mérito para "não corrigir o que não está quebrado", discordo da resposta aceita.

A resposta aceita vem da perspectiva de que o problema não está quebrado. Do ponto de vista da gerência de nível médio, isso é verdade. Se uma análise de custo fosse feita no tempo gasto pelos desenvolvedores para criar e manter uma solução ETL em C # em comparação à compra de uma solução pronta para uso, ela mostraria que a solução C # leva de 3 a 4 vezes mais tempo para criar e manter e custar até 10 vezes mais (procurei a referência nos números, mas não consegui encontrá-la).

A menos que seja a principal competência da empresa, há muito poucas razões para escrever e manter transformações de dados em C #. A solução caseira será lenta, haverá erros (ou seja, dados corrompidos), haverá casos de borda, haverá pouca reutilização entre as classes de ETL e será frágil. Honestamente, o desenvolvedor quer passar seus dias escrevendo e mantendo o ETL em C #? Eu fiz isso. É uma porcaria de porcaria. É tão longe do trabalho criativo quanto possível.

Use uma ferramenta como a Informatica, uma empresa cujo negócio é ETL. Eles trabalham com esse problema há mais de 15 anos. Eles resolvem isso. Suas ferramentas são arrastar e soltar, a reutilização é embutida, assim como o desempenho. A maioria das pessoas (ou seja, os desenvolvedores também não) podem criar o ETL com o ferramental da Informatica. Não estou tentando vender a Informatica, use qualquer ferramenta. Apenas não reinvente a roda.

A longo prazo, comprar uma ferramenta, como a Informatica ou o uso do SSIS, economizará potencialmente para a empresa milhões no longo prazo. E o melhor de tudo é que você não terá que manter o ETL ou ser responsável por ele quando quebrar.

Eu tentei o SSIS para fazer tarefas simples antes.

Pode ser muito chato, uma vez que mesmo tarefas simples dão origem a diagramas de complexidade de baixo a médio nível (não, não há outra maneira de "codificar", exceto os diagramas). E os problemas de controle de origem apontados pela resposta de Jim eu não sabia.

Problema secundário: Então, para acelerar, sugiro reduzir o tamanho das transações para suas imagens em massa. Diga, a cada 800 em vez de 5000 rocords. Pode reduzir o tamanho da E / S necessária para suportar essa transação.