Mi departamento se especializa en convertir datos de clientes en nuestro esquema de base de datos para que puedan usar nuestro software.

En este momento, tenemos aplicaciones de C # que toman un IDataReader(99% del tiempo que es un SqlDataReader), realizan un poco de limpieza y mapeo, lo insertan en un DataRowobjeto y luego usan a SqlBulkCopypara insertarlo en nuestra base de datos.

A veces (especialmente cuando la base de datos de origen contiene imágenes como varbinaryobjetos), este proceso realmente puede empantanarse con una transferencia SQL desde el servidor a la aplicación para luego girar a la derecha y volver al servidor.

Siento que si reescribimos algunas de las conversiones como paquetes SSIS , podría acelerar mucho las cosas. Sin embargo, el mayor obstáculo con el que me encuentro es cuando mi jefe, al estilo de No inventado aquí , retrocede y dice: "¿Qué pasa si Microsoft deja de admitir SSIS? Tendremos todo este código obsoleto y estaremos jodidos".

Esta no es la primera vez que toco un "¿Qué pasa si eliminan esa característica ...?" respuesta de mi jefe No tengo tiempo para escribir la conversión a la antigua usanza, autodidacta SSIS, y también escribir la nueva forma de demostrar / probar los beneficios (Ninguno de nosotros ha utilizado SSIS, por lo que habría un período en el que tiene que aprender a usarlo).

¿Que debería hacer en esta situación? ¿Dejar de impulsar la nueva tecnología? ¿Esperar hasta que salga del departamento (soy la segunda persona más mayor en el departamento después de él, pero podrían pasar años antes de que renuncie / se retire)? ¿Encuentra una nueva forma de hacer que deje de tener miedo a las herramientas de terceros?

Tomaré una decisión sobre esto desde el punto de vista administrativo, pero tenga en cuenta que soy consciente de que no tengo todos los detalles. Resumiré lo que veo:

1. Desarrollador de nivel medio, lo llamaremos "Scott", recomienda una reescritura de código heredado en SSIS para mejorar el rendimiento del proceso importante ProcessA.
2. ProcessA se está comportando actualmente en un estado funcional sin problemas importantes conocidos.
3. ProcessA está escrito con herramientas patentadas que utilizan conocimientos comunes o potencialmente tribales para mantener.
4. La recomendación de reescribir requerirá nuevas herramientas para soportar.
5. El personal actual no tiene experiencia / conocimiento documentado con las nuevas herramientas.
6. Las nuevas herramientas son reemplazos relativamente recientes de herramientas más antiguas, y el soporte para estas herramientas puede cambiar razonablemente dentro de 4 trimestres comerciales.

Desde esta perspectiva, todo lo que veo es un gran desembolso de dinero por parte de la compañía para mejorar un proceso que no se rompe . Desde un punto de vista técnico, puedo ver la apelación, pero cuando se llega al final, simplemente no tiene sentido comercial hacer este cambio. Si tenía personal disponible con experiencia documentada con SSIS y puntos de referencia para mostrar una mejora masiva en este proceso (tenga en cuenta que la mejora masiva DEBE equivaler a $$$), el resultado podría ser un poco diferente. Sin embargo, tal como está ahora, tendría que estar de acuerdo con la gerencia (en algún lugar acaba de morir un árbol).

Si desea fomentar la adopción de SSIS y potencialmente liderar este refactor, necesita obtener esta experiencia y capacitación con proyectos más pequeños y menos importantes. Proporcione puntos de referencia y soporte para SSIS, y asegúrese de que toda la infraestructura y soporte estén en su lugar antes de que la administración considere siquiera realizar el cambio. Una vez que tenga la herramienta en uso en otro lugar, las personas del equipo con experiencia en su uso, y un factor de "comodidad" empresarial que el soporte no cambiará y desarraiga todo, será más probable que influya en alguien a su punto de vista. Sin eso, estás ladrando el árbol equivocado con ese argumento.

Por estúpido que parezca, a veces la "mejor" forma no es la mejor.

Editar: en respuesta a algunas actualizaciones de la pregunta, publicaré una ligera modificación en mi respuesta.

Si el proceso está experimentando dificultades de algún tipo, reescribirlo seguirá siendo una empresa costosa. Es posible que desee considerar cuál sería el costo de ajustar el código existente en contra de reescribir el paquete. Considere los impactos no solo en el software sino también en cualquier proceso de interfaz humana. Al intentar conseguir que la gerencia acepte una reescritura, siempre se reducirá al dinero. A menos que pueda demostrar que la angustia actual está costando dinero ahora o que se volverá grande en conjunto, la administración aún no verá el beneficio. Este costo puede no ser necesariamente de naturaleza financiera. Si la desaceleración compromete un sistema que causa tiempo de inactividad, introduce vectores de intrusión o algún otro síntoma "difícil de cuantificar", es posible que deba encontrar una manera de traducir ese problema en un equivalente de riesgo monetario. Un vector de intrusión, por ejemplo, puede conducir a una intrusión que podría resultar en datos perdidos, robados o corruptos. La compañía podría perder reputación o puede fallar una auditoría de seguridad necesaria. La clave es lograr que el gerente en cuestión reconozca los beneficios cuantificables del cambio.

Romper cosas es una habilidad

He trabajado en demasiados lugares que adoptaron el argumento de "si no está roto" hasta el punto de que no logran innovar, y cuando finalmente se ven obligados a innovar, reaccionan en exceso cambiando todo . Simplemente porque carecen de la experiencia de romper cosas .

Se necesita madurez, habilidad y experiencia para romper cosas.

Los equipos de desarrollo que siempre juegan a lo seguro son los más fáciles de superar para un competidor. Solo los equipos que han fallado, cometido errores y cosas rotas pueden realizar evaluaciones de riesgo honestas.

Manteniendo el status quo

Si bien es cierto, el sistema actual cumple con los requisitos comerciales actuales. Eso no es cierto para los futuros cambios imprevistos de esos requisitos. Como dice el viejo proverbio "la fortuna prefiere lo preparado".

Esta pregunta no tiene nada que ver con SQL o el rendimiento. Se trata de hacer la pregunta "¿hay una mejor manera?" y no tener miedo de probar una alternativa.

Su jefe sufre un caso de Keeping The Status Quo .

Los mayas

Nada funciona realmente a la perfección.

Los mayas seguían cultivando sus alimentos en la ladera de las montañas. Hasta que todos los nutrientes fueron eliminados, y no tuvieron forma de alimentar a su gente. Siguieron haciendo las cosas de la misma manera hasta que fue demasiado tarde.

Suponiendo que tendrá tiempo para solucionar un problema cuando el problema se presente es un error.

¿Qué hacer?

Su jefe sufre de un caso de condicionamiento. Las personas que aceptan el statu quo a menudo lo hacen porque carecen de la capacidad de tomar decisiones difíciles. Cuando se enfrentan a un desafío, tenderán a elegir la opción más cercana a la que conocen.

El miedo por él es una gran motivación. El miedo a lo desconocido o las condiciones cambiantes sacude su perspectiva de cuál es el status quo. Él tenderá a tratar de devolver las condiciones a la normalidad lo más rápido posible.

Necesita presentar ideas de una manera no conflictiva. Intenta encontrar un terreno común entre lo que te gustaría hacer con lo que ya es el status quo. Presente argumentos que reduzcan su miedo al cambio y ofrezca garantías de que desea completar una tarea que no causará un cambio significativo.

Tomar pasos de bebé

Sería mejor ofrecer cambios que muevan el proyecto en la dirección que desee, pero a través de pequeños proyectos incrementales. En lugar de eso, golpea a tu jefe con la gran pregunta sobre cómo apoyar SSIS. Ofrezca crear una capa de separación en el código que le permita agregar métodos "alternativos" para procesar tablas con archivos adjuntos grandes. Luego puede avanzar para recomendar SSIS con todos los requisitos previos que ya se han agregado al proyecto. Esto reduce el riesgo que su jefe imagina al aceptar el cambio.

Toma tiempo

Mi experiencia ha sido que quienes toman riesgos mantienen un proyecto en movimiento, y los encargados del status quo son como una pared de ladrillos. La persistencia es su única opción para romper sus barreras. Espere seguir escuchando No a sus consultas.

Cuando llega el momento de innovar. Su jefe recurrirá a usted rápidamente, porque demuestra valentía ante el cambio. Algo que buscará una persona de status quo, y será recompensado por sus esfuerzos. Incluso si ninguna de sus consultas anteriores ha sido aceptada. Rápidamente se convertirá en un activo insustituible en una empresa que se enfrenta a un cambio que abarca el no cambio.

Siento que si reescribimos algunas de las conversiones como paquetes SSIS, podría acelerar mucho las cosas. Sin embargo, el mayor obstáculo con el que me encuentro es cuando mi jefe, al estilo de No inventado aquí, retrocede y dice: "¿Qué pasa si Microsoft deja de admitir SSIS? Tendremos todo este código obsoleto y estaremos jodidos".

En mi opinión, el escepticismo sobre SSIS es válido.

• Los desarrolladores experimentados odian las cajas negras, y hay mucha magia que ocurre dentro de un paquete SSIS.
• El soporte de control de código fuente para los paquetes SSIS es muy deficiente. Diferenciar y fusionar archivos SSIS dtsx puede ser una pesadilla si sus paquetes dtsx no son lo suficientemente modulares.
  • Por el contrario, las aplicaciones de consola C # son muy transparentes. Siempre puedes seguir el código para descubrir qué está pasando mal.

Además, considere que su jefe está en apuros si algo sale mal.

• Por lo tanto, tiene derecho a tener la opinión principal / única sobre el asunto.

No tengo tiempo para escribir la conversión a la antigua usanza, autodidacta SSIS, y también escribir la nueva forma de demostrar / probar los beneficios (Ninguno de nosotros ha utilizado SSIS, por lo que habría un período en el que tiene que aprender a usarlo).

¿Que debería hacer en esta situación? ¿Dejar de impulsar la nueva tecnología? ¿Esperar hasta que salga del departamento (soy la segunda persona más mayor en el departamento después de él, pero podrían pasar años antes de que renuncie / se retire)? ¿Encuentra una nueva forma de hacer que deje de tener miedo a las herramientas de terceros?

Le recomiendo que aprenda SSIS lo suficientemente bien como para que pueda demostrar sus beneficios.

Y si, después de su autoestudio, encuentra que SSIS ofrece ventajas significativas sobre el enfoque más "tradicional", y aún no puede convencer a su jefe de cambiar de rumbo, le recomiendo que encuentre un trabajo diferente en el que pueda usa SSIS.

La respuesta que casi siempre recibes de la mayoría de los tipos de gerentes es algo como:

"No vale la pena, funciona ahora y costará tiempo cambiar".

Y en general, esto es válido. Sin embargo, este no es siempre un argumento válido, porque el problema central que rodea el síndrome "No inventado aquí" no es si las cosas funcionan o no, sino que la tecnología se está reescribiendo sin sentido , desperdiciando horas de la empresa y restando valor sustancial del producto que se entrega.

Debe determinar si no se ha inventado aquí antes de decidir qué hacer. La tecnología interna puede haber sido escrita por alguna razón .

Señales de que la tecnología se reescribe por una razón:

• La tecnología que está vendiendo también es el producto . Si usted es un proveedor de bases de datos, usar el código MySQL, sin importar cuánto tiempo ahorre, es una idea peligrosa por muchas razones.
• La tecnología interna está bien mantenida y resuelve eficazmente las deficiencias de la solución estándar, al tiempo que proporciona una funcionalidad base comparable.
• La tecnología mejora la productividad de todo el equipo de desarrollo, y los nuevos desarrolladores se venden fácilmente por qué está en uso.
• Hay otros ejemplos en los que la compañía ha adoptado con éxito otras tecnologías externas .
• Su negocio se vería afectado de manera inmediata y grave si la solución OTS fuera descontinuada o rota.
• El negocio es tan grande que tiene los recursos para escribir herramientas de alta calidad a bajo costo (por ejemplo, Google puede escribir una base de datos que cueste menos de una licencia MS SQL de $ 1000 / asiento)

En otras palabras, el equipo comprende los inconvenientes de volver a resolver problemas ya resueltos, pero juiciosamente hizo excepciones donde tenía sentido desde una perspectiva comercial.

Señales de "No inventado aquí":

• Parece que todo es interno , y hay excusas para todo: "uh, fue demasiado lento", "uh, es Microsoft, odiamos a Microsoft", "uh, parece muy difícil de usar", etc.
• Para los casos en los que se está utilizando tecnología externa, escuchas "sí, apesta y planeamos escribir el nuestro eventualmente ".
• Los propietarios de esos componentes no tienen otros trabajos en los que sean capaces de trabajar.
• Verá que la mayoría de los nuevos desarrolladores llegan con un conjunto de habilidades ampliamente aceptado, pero les lleva un tiempo considerable avanzar a las herramientas internas.
• Después de un análisis cuidadoso, se hace evidente que cambiar de la solución OTS a una solución OTS personalizada u otra en el "¡y si se descontinúa!" escenario tendría un impacto comercial mínimo . Por ejemplo, si String.Join()se eliminaran de .NET Framework, la reimplementación a un StringJoin()método personalizado sería trivial.

En otras palabras, NIH es el patrón de no ser objetivo y realista en los casos en que se utiliza tecnología externa en lugar del propio código.

Cuando la tecnología se reescribe por una razón, sus superiores deben elogiar y apreciar sus inquietudes. Debería haber sido una decisión cuidadosa cuando se implementó la tecnología, y revisar la decisión ocasionalmente es bueno para el negocio. Las cosas cambian con el tiempo y es posible que tenga un punto válido. Si puede proporcionar números sobre el tiempo perdido en el pasado, los costos proyectados para cambiar y otra información, podría (en teoría) presentar un caso para el cambio.

Ten en cuenta que, dada tu experiencia, es posible que no estén de acuerdo con tus números, pero de todos modos, al menos deberían escucharte. Puede tomar tiempo ganar respeto.

Si la conversación no puede ser mencionada, incluso si eres cortés, podría ser "No inventado aquí". En cuyo caso, lo más probable es que sea un problema político o de personalidad que probablemente no pueda solucionar fácilmente. Trabajar en un entorno que está fuertemente empantanado por la reinvención constante es tóxico para los desarrolladores y el negocio. Correr.

(Nota al margen: en la mayoría de las empresas, siempre hay un elemento de NIH, pero está en un nivel tolerable, y siempre que revisen regularmente su código y prácticas. A largo plazo, todos somos culpables de ello en cierta medida, pero nunca se convierte en un problema).

Bueno, todo se trata del análisis de costo / beneficio.

¿Qué gana reescribiéndolo en SSIS? ¿Velocidad? ¿Importa? Si se trata de un proceso que se ejecuta en una GUI y le hace perder el tiempo a todos, entonces sí, probablemente sea una buena idea acelerarlo, porque el dinero gastado en cambiarlo será recuperado por un cliente más feliz o un empleado interno que haga su trabajo en lugar de esperando el software Pero si es un lote nocturno que comienza a las 12 a.m. y terminará a la 1 a.m. en lugar de a las 6 a.m. ... no tiene mucho sentido. Sí, es 6 veces más rápido, pero nadie sentirá la diferencia.

Y tu jefe tiene un buen punto. Microsoft tiende a abandonar algunas de sus tecnologías. VB6, Linq-to-SQL, ASP classic, COM + ... Esto es un riesgo con cualquier software de código abierto (y software de código abierto que sería demasiado grande para que su organización lo mantenga en caso de falta de actualización). Si es fundamental para su aplicación, debe tener un control estricto sobre ella.

El software se trata de agregar valor al cliente, y la mejora técnica que no produce muchos beneficios al tiempo que introduce riesgos no cumple realmente ese papel.

Desarrolle un POC (Prueba de concepto) y luego demuéstrelo a su superior. El POC debería ayudarlo a determinar cualquier beneficio real con la tecnología que está proponiendo. Luego, usted y su superior pueden hablar sobre la tecnología y desarrollar ventajas y desventajas para implementarla.

Probablemente tendrá que pasar un tiempo extra fuera del tiempo de trabajo normal para desarrollar el POC.

Como nota al margen desde el punto de vista de SSIS, lo he usado y he desarrollado paquetes de SSIS. De hecho, reemplazamos un proceso de carga patentado usando paquetes SSIS. Solo hicimos esto porque los clientes reales se quejaron de los tiempos de carga. Los tiempos de carga disminuyeron significativamente con SSIS y todos se sintieron más felices.

SSIS es básicamente un flujo de trabajo de arrastrar y soltar con muy poca programación involucrada. Lleva algún tiempo aprender cómo funciona el recuadro negro, por lo que deberá tenerlo en cuenta si su equipo comienza a usarlo.

Buenas respuestas Si no está roto, no lo arregles. Solo agregaría

• Si bien las preocupaciones sobre el rendimiento podrían ser ciertas, esa palabra "podría" es una señal de alerta. Primero haría un diagnóstico de rendimiento, para tener una prueba de cuál era el problema de rendimiento, antes de comprometer recursos para abordarlo.

• Cuando se considera la última "solución" de Microsoft, uno debe considerar que mucha gente se ha quemado por lo que una vez MS promocionó pero luego desaprobó y luego dejó de admitir. Si desea que el software se ejecute durante 10 o 20 años sin recodificación importante, debe tener mucho cuidado con eso. Nuestra compañía ha sido gravemente herida de esa manera.

La rotación de personal será una consideración para su jefe. SSIS está entrando en la arena de DBA en comparación con un programador que tiene ese conjunto de habilidades. Si su aplicación no usa SSIS más allá de la conversión inicial, no estoy seguro de que tenga sentido aprenderla y poner a los nuevos programadores de C # a la velocidad porque, como su equipo, la mayoría no tiene experiencia con ella.

Podría señalarle a su jefe que SSIS es, de hecho, una capa de tecnología más antigua que .NET Framework, si vuelve a sus raíces como el "Marco de transformación de datos" de SQL 7.0.

Donde su jefe podría tener un punto es en el hecho de que SSIS es solo una parte de las versiones Standard y Enterprise de Microsoft Sql Server; ese es un cambio bastante grande para que sus clientes aprovechen, cuando su aplicación, en un escenario de pequeña empresa, puede estar perfectamente bien con Sql Express (o MySQL, para el caso, que funciona con ADO.NET pero no puede usar la integración SSIS).

Ahora, déjame ser perfectamente claro; En mi opinión, NIH casi nunca es algo bueno para una empresa de desarrollo de software. Te bloquea de muchas herramientas y servicios muy potentes. También es hipócrita en su cara; ¿su empresa escribió Visual Studio? ¿Qué tal el .NET Framework? ¿Servidor SQL? Windows? No. Usted construye su software sobre las herramientas y plataformas que ya tiene (y sus clientes también). Por lo tanto, si ve una herramienta que está ganando aceptación general, y que podría ser útil para realizar su negocio principal, la adopta y aprende a vivir con el riesgo de tener que mantener su implementación para mantenerse al día con las últimas novedades. versiones de esas herramientas, o incluso reemplazarlas. Apuesto a que su jefe primero desarrolló el software para ejecutarse en Windows 95/98 o por ahí (si no muchoantes de eso, como 3.0 / 3.1). Si es así, ha visto media docena de versiones de sistemas operativos de estaciones de trabajo de Windows ir y venir, y tuvo que actualizar su software para que se ejecute en las plataformas más nuevas, y se enfrenta a otra con XP oficialmente EOLed. Si bien puede quejarse, ese es simplemente el costo de hacer negocios.

Sin embargo, una actitud de los NIH no se deriva necesariamente de una negativa a aceptar una, o incluso una serie, de tecnologías que pueden considerarse útiles. Esos rechazos podrían basarse en análisis de costo-beneficio perfectamente válidos. Trabajo para una empresa de videovigilancia y monitoreo de alarmas, y tomamos decisiones para respaldar o no respaldar varias nuevas tecnologías o productos a diario. Por lo general, la decisión de aceptar una nueva tecnología, y el dolor de combinarla con nuestro montón de software de visualización de alarmas y visor compatible, se basa principalmente en lo que vale para nuestros clientes. Recientemente terminé un gran proyecto de integración con un nuevo tipo de DVR, simplemente porque uno de nuestros mayores clientes existentes dijo que estaban actualizando a ese DVR desde otro producto DVR de gran renombre pero tecnológicamente rezagado, y lo harían con o sin nuestra ayuda. Por otro lado, rechazamos regularmente nuevos fabricantes, incluso los principales nombres familiares, simplemente porque nuestros clientes no lo usan y no vemos ningún valor en comenzar a ofrecerlo, incluso si nos pierde algunos clientes potenciales que lo tienen y no lo hacen ' No quiero pagar por nuestra versión de lo mismo.

No tengo tiempo para escribir la conversión a la antigua usanza, autodidacta SSIS, y también escribir la nueva forma de demostrar / probar los beneficios (Ninguno de nosotros ha utilizado SSIS, por lo que habría un período en el que tiene que aprender a usarlo).

Ese es el tipo de problema, ¿no? Estás pidiendo a otras personas que arriesguen su productividad con tu idea, y no estás dispuesto a arriesgarte para demostrarles que vale la pena. El liderazgo técnico requiere arriesgar su reputación o su tiempo libre para demostrar que vale la pena tener sus ideas.

Intenta ver las cosas desde la perspectiva de tu jefe. Parece que la funcionalidad que está tratando de reemplazar es esencial para lo que hace su software (vea su comentario "atornillado"). Un buen gerente sabe que usted externaliza su negocio principal bajo su propio riesgo. Está justamente preocupado por apostar a la granja por alguna pieza de tecnología que podría desaparecer en el futuro. Cuando las funciones principales están involucradas, no inventado aquí es realmente algo bueno.

Si la velocidad es una característica, tendrá que encontrar otra forma de acelerar las cosas. De lo contrario, si la velocidad es más importante para usted que para sus clientes, le digo que lo deje y se olvide.

Si bien hay mérito para "no arreglar lo que no está roto", no estoy de acuerdo con la respuesta aceptada.

La respuesta aceptada proviene de la perspectiva de que el problema no está roto. Desde la perspectiva de la gerencia de nivel medio, esto es cierto. Si se hiciera un análisis de costos sobre el tiempo empleado por los desarrolladores para crear y mantener una solución ETL en C # en comparación con la compra de una solución lista para usar, mostraría que la solución C # tarda de 3 a 4 veces más en crearse y mantener y costar hasta 10 veces más (busqué la referencia en los números, pero no pude encontrarla).

A menos que sea la competencia central de la compañía, hay muy pocas razones para escribir y mantener las transformaciones de datos en C #. La solución local será lenta, habrá errores (es decir, datos corruptos), habrá casos extremos, habrá poca reutilización entre las clases de ETL y será frágil. Honestamente, ¿qué desarrollador quiere pasar sus días escribiendo y manteniendo ETL en C #? Lo he hecho. Es un montón de basura. Está tan lejos del trabajo creativo como uno puede llegar.

Use una herramienta como Informatica, una empresa cuyo negocio es ETL. Han estado trabajando en este problema por más de 15 años. Lo tienen resuelto. Sus herramientas son arrastrar y soltar, la reutilización está integrada, al igual que el rendimiento. La mayoría de las personas (es decir, los desarrolladores tampoco) pueden crear ETL con las herramientas de Informatica. No estoy tratando de vender Informatica, use ninguna herramienta. Simplemente no reinventes la rueda.

A la larga, la compra de una herramienta, como Informatica o el uso de SSIS, le ahorrará potencialmente a la compañía millones a largo plazo. Y lo mejor de todo es que no tendrá que mantener el ETL ni ser responsable de él cuando se rompa.

He intentado SSIS para hacer tareas simples antes.

Puede ser muy molesto, ya que incluso las tareas simples dan lugar a diagramas de complejidad de nivel bajo a medio (no, no hay otra forma de "codificarlo" excepto los diagramas). Y los problemas de control de la fuente señalados por la respuesta de Jim no lo sabía.

Problema secundario: por lo tanto, para acelerar, sugiero reducir el tamaño de las transacciones para los lotes de imágenes. Digamos, cada 800 en lugar de 5000 rocords. Puede reducir el tamaño de la E / S necesaria para admitir esa transacción.