Meu departamento é especializado na conversão de dados de clientes em nosso esquema de banco de dados para que eles possam usar nosso software.

No momento, temos aplicativos C # que demoram um IDataReader(99% do tempo SqlDataReader), executam alguma limpeza e mapeamento, inserem-no em um DataRowobjeto e, em seguida, usam a SqlBulkCopypara inseri-lo em nosso banco de dados.

Às vezes (especialmente quando o banco de dados de origem contém imagens como varbinaryobjetos), esse processo pode realmente atrapalhar com uma transferência SQL do servidor para o aplicativo, para então virar e voltar ao servidor.

Sinto que, se reescrevemos algumas das conversões como pacotes SSIS, isso poderia acelerar bastante as coisas. No entanto, o maior obstáculo em que eu continuo encontrando é quando meu chefe, na moda Não inventou aqui , recua e diz: "E se a Microsoft abandonar o suporte ao SSIS? Teremos todo esse código obsoleto e seremos ferrados".

Esta não é a primeira vez que clico em "E se eles removerem esse recurso ...?" resposta do meu chefe. Não tenho tempo para escrever a conversão da maneira antiga, autodidata do SSIS e também escrever a nova maneira de demonstrar / testar os benefícios (Nenhum de nós usou o SSIS, portanto haveria um período em que tem que aprender a usá-lo).

O que devo fazer nesta situação? Pare de empurrar a nova tecnologia? Espere até ele sair do departamento (eu sou a segunda pessoa mais Sr. no departamento depois dele, mas pode levar anos até que ele desista / se aposente)? Encontrou uma nova maneira de fazê-lo parar de ter medo de ferramentas de terceiros?

Vou dar uma olhada nisso do ponto de vista gerencial, mas lembre-se de que não tenho todos os detalhes. Vou resumir o que vejo:

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

Nesta perspectiva, tudo o que vejo é um grande desembolso 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ê se dedica a isso, simplesmente não faz sentido nos negócios fazer essa alteração. Se você tivesse uma equipe com experiência documentada com o SSIS e benchmarks para mostrar melhorias maciças nesse processo (lembre-se de que as melhorias maciças DEVEM ser equivalentes a $$$), o resultado pode ser um pouco diferente. Como está agora, porém, eu teria que concordar com o gerenciamento (em algum lugar em que uma árvore acabou de morrer).

Se você deseja promover a adoção do SSIS e potencialmente levar a esse refator, precisará adquirir essa experiência e treinamento com projetos menores e menos importantes. Forneça referências e suporte para o SSIS e verifique se toda a infraestrutura e suporte estão em vigor antes que o gerenciamento considere fazer a alteração. Depois que você tiver a ferramenta em uso em outro lugar, as pessoas da equipe tiverem experiência com esse uso e um fator de "conforto" dos negócios que o suporte não mudará e arrancará tudo, você terá mais chances de influenciar alguém do seu ponto de vista. Sem eles, você está latindo na árvore errada com esse argumento.

Por mais estúpido que pareça, às vezes o "melhor" caminho não é o melhor.

Editar: em resposta a algumas atualizações da pergunta, publicarei uma pequena modificação na minha resposta.

Se o processo estiver passando por algum tipo de sofrimento, reescrevê-lo ainda será um empreendimento caro. Você pode considerar o custo do ajuste fino do código existente contra a reescrita do pacote. Considere os impactos não apenas no software, mas também em qualquer processo de interface humana. Ao tentar obter a adesão da gerência a uma reescrita, ainda assim o custo será sempre baixo. A menos que você possa mostrar que a aflição atual está custando dinheiro agora ou se tornará grande no conjunto, a gerência ainda não verá o benefício. Esse custo pode não ser necessariamente de natureza financeira. Se a desaceleração comprometer um sistema que causa tempo de inatividade, introduzir vetores de intrusão ou algum outro sintoma "difícil de quantificar", talvez seja necessário encontrar uma maneira de converter esse problema em um risco monetário equivalente. Um vetor de intrusão, por exemplo, pode levar a uma invasão que pode resultar em dados perdidos, roubados ou corrompidos. A empresa pode perder a 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

Já trabalhei em muitos lugares que adotaram o argumento "se não está quebrado" a ponto de não conseguirem inovar 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 de serem superadas por um concorrente. Somente equipes que falharam, cometeram erros e quebraram coisas são capazes de realmente fazer avaliações honestas de riscos.

Mantendo o Status Quo

Embora seja verdade, o sistema atual atende aos requisitos comerciais atuais. Isso não é verdade para as futuras mudanças imprevistas nesses requisitos. Como diz o velho provérbio, "a sorte prefere o preparado".

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

Seu chefe sofre de um caso de Como manter o status quo .

Os Maias

Nada está realmente funcionando perfeitamente.

Os maias continuavam cultivando sua comida nas encostas das montanhas. Até que todos os nutrientes foram lavados e eles não tinham como alimentar seu povo. Eles continuaram fazendo as coisas da mesma maneira até que fosse tarde demais.

Supondo que você tenha tempo para corrigir um problema quando o problema se apresentar é um erro.

O que fazer?

Seu chefe sofre de um caso de condicionamento. As pessoas que aceitam o status quo frequentemente o fazem, porque não têm a capacidade de tomar decisões difíceis. Quando confrontados com um desafio, eles tendem a escolher a opção mais próxima do que estão familiarizados.

O medo por ele é uma grande motivação. O medo das condições desconhecidas ou mutáveis ​​abala sua perspectiva do que é o status quo. Ele tenderá a tentar retornar as condições ao normal o mais rápido possível.

Você precisa apresentar idéias de uma maneira não conflitante. Tente encontrar um ponto em comum entre o que você gostaria de fazer e o que já é o status quo. Apresente argumentos que reduzam o medo de mudar e ofereça garantias de que você deseja concluir uma tarefa que não causará mudanças significativas.

Dê passos de bebê

Seria melhor oferecer alterações que movessem o projeto na direção desejada, mas através de pequenos projetos incrementais. Em vez disso, acerte seu chefe com a grande pergunta sobre o suporte ao SSIS. Ofereça-se para criar uma camada de separação no código que permita o plug-in de métodos "alternativos" para processar tabelas com anexos grandes. Em seguida, você pode avançar para recomendar o SSIS com todos os pré-requisitos já adicionados ao projeto. Isso reduz o risco que seu chefe imagina ao aceitar a alteração.

Leva tempo

Minha experiência foi que os que tomam riscos mantêm um projeto em andamento e os que mantêm 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 às suas perguntas.

Quando chegar a hora de inovar. Seu chefe se voltará para você rapidamente, porque você demonstra destemor diante da mudança. Algo que uma pessoa com status quo estará procurando e você será recompensado por seus esforços. Mesmo que nenhuma das suas consultas anteriores tenha sido aceita. Você se tornará rapidamente um ativo insubstituível em uma empresa que enfrenta mudanças que adotam mudanças sem mudanças.

Sinto que, se reescrevemos algumas das conversões como pacotes SSIS, isso poderia acelerar bastante as coisas. No entanto, o maior obstáculo em que eu continuo encontrando é quando meu chefe, na moda Não inventou aqui, recua e diz: "E se a Microsoft abandonar o suporte ao SSIS? Teremos todo esse código obsoleto e seremos ferrados".

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

• Desenvolvedores experientes odeiam caixas-pretas, e há muita mágica que acontece dentro de um pacote SSIS.
• O suporte ao controle de origem para pacotes SSIS está extremamente ausente. Difundir e mesclar arquivos dtsx do SSIS pode ser um pesadelo se os 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 / única opinião sobre o assunto.

Não tenho tempo para escrever a conversão da maneira antiga, autodidata do SSIS e também escrever a nova maneira de demonstrar / testar os benefícios (Nenhum de nós usou o SSIS, portanto haveria um período em que tem que aprender a usá-lo).

O que devo fazer nesta situação? Pare de empurrar a nova tecnologia? Espere até ele sair do departamento (eu sou a segunda pessoa mais Sr. no departamento depois dele, mas pode levar anos até que ele desista / se aposente)? Encontrou uma nova maneira de fazê-lo parar de ter medo de ferramentas de terceiros?

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

E se, após seu auto-estudo, você achar que o SSIS oferece vantagens significativas em relação à abordagem mais "tradicional" e ainda não conseguir convencer seu chefe a mudar de rumo, recomendo que encontre um trabalho diferente no qual possa use SSIS.

A resposta que você quase sempre faz da maioria dos tipos de gerente é algo como:

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

E, em geral, isso é válido. No entanto, esse nem sempre é um argumento válido, porque o principal problema em torno da síndrome "Não foi inventado aqui" não é se as coisas funcionam ou não, mas essa tecnologia está sendo reescrita sem sentido , desperdiçando horas da empresa e prejudicando um valor substancial do produto que está sendo entregue.

Você precisa determinar se Não está inventado aqui realmente está ocorrendo antes de decidir o que fazer. A tecnologia interna pode ter sido escrita por uma razão .

Sinais de que a tecnologia foi reescrita por um motivo:

• A tecnologia que você está vendendo também é o produto . Se você é um fornecedor de banco de dados, usando o código MySQL, não importa quanto tempo economize, é uma ideia perigosa por vários motivos.
• A tecnologia interna é bem mantida e soluciona efetivamente as deficiências da solução pronta para uso, além de fornecer funcionalidade básica comparável.
• A tecnologia melhora a produtividade de toda a equipe de desenvolvimento, e novos desenvolvedores são facilmente vendidos por que estão em uso.
• Existem outros exemplos em que a empresa adotou com sucesso outras tecnologias externas .
• Sua empresa seria imediatamente e seriamente afetada se a solução OTS fosse descontinuada ou interrompida.
• A empresa é tão grande que possui recursos para gravar ferramentas de alta qualidade a baixo custo (por exemplo, o Google pode escrever um banco de dados que custa menos de uma licença MS SQL de US $ 1000 / assento)

Em outras palavras, a equipe entende as desvantagens de resolver problemas já resolvidos, mas criteriosamente fez exceções onde fazia sentido da perspectiva dos negócios.

Sinais de "não inventado aqui":

• Parece que tudo é interno e há desculpas para tudo: "foi muito lento", "é a Microsoft, odiamos a Microsoft", "parece muito difícil de usar" etc.
• Nos 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 empregos nos quais possam trabalhar.
• Você vê a maioria dos novos desenvolvedores chegando com um conjunto de habilidades amplamente aceito, mas leva um tempo considerável para eles se adaptarem às ferramentas internas
• Após uma análise cuidadosa, torna-se aparente que alternar da solução OTS para uma solução personalizada ou outra solução OTS no "e se for descontinuado!" cenário teria um impacto mínimo nos negócios . Por exemplo, se String.Join()fossem removidos do .NET Framework, a reimplementação em um StringJoin()método personalizado seria trivial.

Em outras palavras, o NIH é o padrão de deixar de 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, as preocupações devem ser elogiadas e apreciadas pelos seus superiores. Deveria ter sido uma decisão cuidadosa quando a tecnologia foi implementada, e revisar a decisão ocasionalmente é bom para os negócios. As coisas mudam com o tempo e você pode ter um ponto válido. Se você pode fornecer números sobre o tempo perdido 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, devem pelo menos ouvi-lo. Pode levar tempo para ganhar respeito.

Se a conversa não puder ser iniciada, mesmo se você estiver sendo educado, pode ser apenas "Não inventado aqui". Nesse caso, é mais provável que seja uma questão política ou de personalidade que você provavelmente não consiga resolver facilmente. Trabalhar em um ambiente fortemente atolado pela reinvenção constante é tóxico para os desenvolvedores e os negócios. Corre.

(Observação: na maioria das empresas, sempre há um elemento do NIH, mas é em um nível tolerável, e desde que eles revisem regularmente seu código e práticas. A longo prazo, todos somos culpados até certo ponto, mas isso nunca se torna um problema.)

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

O que você ganha reescrevendo-o no SSIS? Rapidez? Isso importa? Se for um processo executado em uma GUI e desperdiçar o tempo de todos, é provável que seja uma boa idéia acelerá-la, porque o dinheiro gasto para mudá-la será recuperado por clientes mais satisfeitos ou por funcionários internos que fazem seu trabalho em vez de aguardando o software. Mas se é um lote noturno que começa às 12h e termina às 1h em vez das 6h ... não faz muito sentido. Sim, é 6 vezes mais rápido, mas ninguém sentirá a diferença.

E seu chefe tem um bom argumento. A Microsoft costuma abandonar algumas de suas tecnologias. VB6, Linq-to-SQL, ASP classic, COM + ... Esse é um risco com qualquer software de código não aberto (e software de código aberto que seria muito grande para a sua organização manter em caso de falta de atualização). Se for central para o seu aplicativo, você deve ter um controle rígido sobre ele.

O software tem tudo a ver com agregar valor ao cliente, e o aprimoramento técnico que não gera muitos benefícios ao mesmo tempo em que introduz riscos não cumpre esse papel.

Desenvolva um POC (Proof of Concept) e depois demonstre-o ao 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 tempo normal de trabalho para desenvolver o POC.

Como uma observação lateral do ponto de vista do SSIS, eu o usei e desenvolvi pacotes SSIS. Na verdade, substituímos um processo de carregamento proprietário usando pacotes SSIS. Só fizemos isso porque os clientes reais se queixaram dos tempos de carregamento. O tempo de carregamento diminuiu 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; portanto, você precisará levar isso em consideração se sua equipe começar a usá-la.

Boas respostas. Se não estiver quebrado, não conserte. Eu só adicionaria

• Embora as preocupações com o desempenho possam realmente ser verdadeiras, essa palavra "pode" é uma bandeira vermelha. Eu faria o diagnóstico de desempenho primeiro, para ter provas de qual era o problema de desempenho, antes de comprometer qualquer recurso para resolvê-lo.

• Ao considerar a mais recente "solução" da Microsoft, deve-se considerar que muitas pessoas foram queimadas pelo que a MS estava divulgando, mas que posteriormente foi reprovada e, em seguida, descomprometida. Se você deseja que o software funcione por 10 ou 20 anos sem grandes recodificações, tenha muito cuidado com isso. Nossa empresa foi gravemente ferida dessa maneira.

A rotatividade será uma consideração para o seu chefe. O SSIS está entrando na arena do DBA em comparação com um programador com esse conjunto de habilidades. Se o seu aplicativo não usa o SSIS além da conversão inicial, não tenho certeza se faz sentido aprendê-lo e acelerar novos programadores de C # porque, como sua equipe, a maioria não tem experiência com ele.

Você pode indicar ao seu chefe que o SSIS é, de fato, 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.

O ponto em que seu chefe pode ter razão é que o SSIS é apenas uma parte das versões Standard e Enterprise do Microsoft Sql Server; é uma grande parte da mudança para seus clientes pagarem, quando seu aplicativo, em um cenário de pequenas empresas, pode estar perfeitamente bem com o Sql Express (ou MySQL, que funciona com o ADO.NET, mas não pode use a integração SSIS).

Agora, deixe-me ser perfeitamente claro; OMI, NIH quase nunca é uma coisa boa para uma casa de desenvolvimento de software. Ele impede você de muitas ferramentas e serviços muito poderosos. Também é hipócrita em seu rosto; sua empresa escreveu o Visual Studio? E o .NET Framework? Servidor SQL? Janelas? Não. Você constrói seu software sobre as ferramentas e plataformas que já possui (e seus clientes também). Portanto, se você encontrar uma ferramenta que está obtendo aceitação geral e que pode ser útil no desempenho do seu negócio principal, você a adota e aprende a viver com o risco de ter que manter sua implementação para acompanhar as atualizações mais recentes. versões dessas ferramentas, ou mesmo substituí-las. Aposto que seu chefe desenvolveu o software para rodar no Windows 95/98 ou nos próximos anos (se não muito tempo)antes disso, como 3.0 / 3.1). Nesse caso, ele viu meia dúzia de versões dos sistemas operacionais Windows chegar e sair, e teve que atualizar seu software para rodar nas plataformas mais novas, e ele está enfrentando outra com o XP oficialmente EOLed. Embora ele possa reclamar, esse é simplesmente o custo de fazer negócios.

No entanto, uma atitude do NIH não decorre necessariamente de uma recusa em aceitar uma, ou mesmo várias, tecnologias que podem ser vistas como úteis. Essas recusas podem ser baseadas 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 o suporte diário de várias novas tecnologias ou produtos. Geralmente, a decisão de aceitar uma nova tecnologia e a dor de combiná-la com nosso monte de softwares de gerenciamento de visualizador e alarme suportados, são baseadas principalmente no que vale a pena para nossos clientes. Concluí recentemente um grande projeto de integração com um novo tipo de DVR, simplesmente porque um dos nossos maiores clientes existentes disse que estava atualizando para esse DVR a partir de outro produto DVR de grande nome, mas tecnologicamente deficiente, e eles fariam isso com ou sem a nossa ajuda. Por outro lado, regularmente rejeitamos novos fabricantes, 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 nos perca alguns clientes em potencial que o possuem e não o fazem ' Não quero pagar por nossa versão da mesma coisa.

Não tenho tempo para escrever a conversão da maneira antiga, autodidata do SSIS e também escrever a nova maneira de demonstrar / testar os benefícios (Nenhum de nós usou o SSIS, portanto haveria um período em que tem que aprender a usá-lo).

Esse é o tipo de problema, não é? Você está pedindo que outras pessoas arrisquem sua produtividade com a sua ideia e não está disposto a se esforçar para mostrar que vale a pena. A liderança técnica exige que você arrisque sua reputação ou tenha tempo livre para mostrar que vale a pena ter suas idéias.

Tente ver as coisas da perspectiva do seu chefe. Parece que a funcionalidade que você está tentando substituir é essencial para o que o seu software faz (consulte o comentário "ferrado"). Um bom gerente sabe que você terceiriza seu negócio principal por sua própria conta e risco. Ele está justamente preocupado em apostar na fazenda em algum tipo de tecnologia que possa desaparecer no futuro. Quando as funções principais estão envolvidas, não é inventado aqui é realmente uma coisa boa.

Se a velocidade é um recurso, 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, digo: abandone e esqueça.

Embora haja mérito de “não consertar 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 com a compra de uma solução pronta para uso, mostraria que a solução C # leva de 3 a 4 vezes mais para criar e manter e custar até 10 vezes mais (procurei a referência nos números, mas não a encontrei).

A menos que seja a principal competência da empresa, há muito pouco motivo para gravar e manter transformações de dados em C #. A solução doméstica será lenta, haverá erros (ou seja, dados corrompidos), haverá casos extremos, haverá pouca reutilização entre as classes ETL e será frágil. Honestamente, qual desenvolvedor deseja passar seus dias escrevendo e mantendo ETL em C #? Eu fiz isso. É um monte de porcaria. É o mais longe possível do trabalho criativo.

Use uma ferramenta como a Informatica, uma empresa cuja empresa é ETL. Eles estão trabalhando nesse problema há mais de 15 anos. Eles o resolveram. Suas ferramentas são arrastar e soltar, a reutilização é incorporada, assim como o desempenho. Quase todo mundo (ou seja, os desenvolvedores também não têm) pode criar ETL com as ferramentas da Informatica. Não estou tentando vender a Informatica, use qualquer ferramenta. Só não reinvente a roda.

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

Eu tentei o SSIS para executar tarefas simples antes.

Pode ser muito chato, pois 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 "codificá-lo", exceto os diagramas). E os problemas de controle de origem apontados pela resposta de Jim não estavam cientes.

Problema secundário: para acelerar, sugiro reduzir o tamanho das transações dos seus volumes de imagem. Digamos, a cada 800 em vez de 5000 rocords. Pode reduzir o tamanho da E / S necessária para suportar essa transação.