Tomaré en serio esto desde un punto de vista gerencial, 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 reescribir el código heredado en SSIS para mejorar el rendimiento del importante proceso ProcessA.
2. ProcessA se está comportando actualmente en un estado de funcionamiento sin problemas importantes conocidos.
3. ProcessA está escrito con herramientas propietarias que usan conocimientos comunes o potencialmente tribales para mantener.
4. La recomendación de reescritura requerirá nuevas herramientas para ser compatible.
5. El personal actual no tiene experiencia / conocimiento documentado con las nuevas herramientas.
6. Las nuevas herramientas son reemplazos relativamente recientes a las 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 empresa para mejorar un proceso que no está roto . Desde un punto de vista técnico, puedo ver la apelación, pero cuando llegas a eso, simplemente no tiene sentido comercial hacer este cambio. Si tuviera personal disponible con experiencia documentada con SSIS y puntos de referencia para mostrar una mejora masiva en este proceso (tenga en cuenta, la mejora masiva DEBE ser equivalente a $$$), el resultado podría ser un poco diferente. Sin embargo, tal como está ahora, tendría que estar de acuerdo con la administración (en algún lugar donde un árbol acaba de morir).

Si desea fomentar la adopción de SSIS y potencialmente llevar a 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 el soporte estén en su lugar antes de que la administración incluso considere realizar el cambio. Una vez que tenga la herramienta en uso en otro lugar, las personas del equipo experimentaron con su uso, y un factor de "comodidad" de negocios que el soporte no cambiará y desarraigará todo, será más probable que convenza a alguien desde su punto de vista. Sin esos, estás ladrando el árbol equivocado con ese argumento.

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

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

Si el proceso está experimentando problemas 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 volver a escribir el paquete. Considere los impactos no solo al software sino a cualquier proceso de interfaz humana. Cuando se trata de obtener la aprobación de la administración para una reescritura, siempre se reducirá al dinero. A menos que pueda demostrar que la angustia actual está costando dinero ahora o que aumentará en conjunto, la administración todavía no verá el beneficio. Este costo puede no ser necesariamente de naturaleza financiera. Si la ralentización compromete un sistema que causa un 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 riesgo equivalente monetario. Un vector de intrusión, por ejemplo, puede llevar a una intrusión que podría resultar en datos perdidos, robados o corruptos. La compañía podría perder reputación o 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 abrazaron el argumento "si no está roto" hasta el punto de que no logran innovar, y cuando finalmente se ven obligados a innovar, reaccionan de forma exagerada 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 de manera segura son los más fáciles de superar para un competidor. Solo los equipos que han fallado, cometido errores y cosas rotas son capaces de hacer evaluaciones de riesgo honestas.

Mantener 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 en esos requisitos. Como el antiguo proverbio dice "la fortuna prefiere a los preparados".

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 Mantener el status quo .

Los mayas

Realmente nada funciona perfectamente.

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

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

¿Quéhacer?

Tujefesufredeuncasodecondicionamiento.Laspersonasqueaceptanelstatusquoamenudolohacenporquecarecendelacapacidaddetomardecisionesdifíciles.Cuandoseenfrentanaundesafío,tenderánaelegirlaopciónmáscercanaalaqueestánfamiliarizados.

Elmiedoporélesunagranmotivación.Elmiedoalodesconocidoolascondicionescambiantessacudesuperspectivadeloqueeselstatusquo.Tendrálatendenciadeintentarquelascondicionesvuelvanalanormalidadlomásrápidoposible.

Esnecesariopresentarideasdemaneranoconflictiva.Intenteencontrarpuntosencomúnentreloquelegustaríahacerconloqueyaeselstatusquo.Presenteargumentosquereduzcansutemoralcambioyofrezcagarantíasdequedeseacompletarunatareaquenocausaráuncambiosignificativo.

Dapasosdebebé

Seríamejorofrecercambiosquemuevanelproyectoenladirecciónquedesee,peroatravésdepequeñosproyectosincrementales.Envezdeeso,golpeeasujefeconlagranpreguntasobreelsoportedeSSIS.Ofrezcacrearunacapadeseparaciónenelcódigoquelepermitaagregarmé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 prevé al aceptar el cambio.

Lleva tiempo

Mi experiencia ha sido que los tomadores de riesgos mantienen un proyecto en movimiento, y los mantenedores de status quo son como un muro de ladrillos. La persistencia es su única opción para derribar sus barreras. Espere seguir escuchando No a sus consultas.

Cuando llegue el momento de innovar. Tu jefe se dirigirá a ti rápidamente, porque demuestras valentía ante el cambio. Algo que una persona de status quo estará buscando, y usted será recompensado por sus esfuerzos. Incluso si ninguna de sus preguntas anteriores ha sido aceptada. Rápidamente se convertirá en un activo irremplazable 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 muro de piedra más grande con el que me encuentro es cuando mi jefe, al estilo de No inventó aquí, se echa atrás y dice: "¿Qué pasa si Microsoft deja de ser compatible con SSIS? Tendremos todo este código obsoleto y seremos atornillados".

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

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

También, considera que tu jefe está en el gancho si algo sale mal.

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

  

No tengo tiempo para escribir la conversión de la manera antigua, autoaprendizaje de SSIS y también para escribir la nueva forma de demostrar / probar los beneficios (ninguno de nosotros ha usado SSIS, por lo que habría un período donde tendríamos que aprender a usarlo).

     

¿Qué debo hacer en esta situación? ¿Dejar de impulsar la nueva tecnología? Espere a que salga del departamento (soy la segunda persona más senior 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 temerle 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, SSIS ofrece ventajas significativas sobre el enfoque más "tradicional" y aún no puede convencer a su jefe de que cambie de rumbo, entonces le recomiendo que encuentre un trabajo diferente en que puede utilizar 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 cambiarlo".

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

Debe determinar si Not Invented Here se está llevando a cabo antes de decidir qué hacer. La tecnología interna puede haber sido escrita por una razón .

Indica que la tecnología se reescribió por un motivo:

• La tecnología que estás 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 aborda de manera efectiva las deficiencias de la solución estándar, a la vez que proporciona una funcionalidad básica 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 sería inmediatamente y seriamente afectado si la solución OTS se interrumpiera o se rompiera.
• El negocio es tan grande que tiene los recursos para escribir herramientas de alta calidad a un bajo costo (por ejemplo, Google puede escribir una base de datos que cuesta menos de una licencia MS SQL de $ 1000 por asiento )

En otras palabras, el equipo entiende los inconvenientes de la resolución de problemas ya resueltos, pero hizo juiciosamente las excepciones donde tenía sentido desde una perspectiva empresarial.

Señales de "No se han 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 que se está utilizando tecnología externa, se escucha "sí, bueno, apesta y planeamos escribir nuestro propio eventualmente ".
• Los propietarios de esos componentes no tienen otros trabajos en los que pueden trabajar.
• La mayoría de los nuevos desarrolladores vienen con un conjunto de habilidades ampliamente aceptado, pero les lleva un tiempo considerable llegar a las herramientas internas
• Después de un análisis cuidadoso, se vuelve actual que el cambio de la solución OTS a una solución personalizada u otra solución OTS en el "¡qué pasa si se suspende!" El escenario tendría un impacto comercial mínimo . Por ejemplo, si se eliminara String.Join() de .NET Framework, la implementación de un método personalizado de StringJoin() 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 se reescribe la tecnología 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) justificar el cambio.

Comprende que dada su experiencia, es posible que no estén de acuerdo con sus números, pero independientemente de eso, al menos deberían escucharlo. Puede tomar tiempo ganar respeto.

Si la conversación ni siquiera puede ser mencionada, incluso si estás siendo cortés, podría ser simplemente "No se ha inventado aquí". En ese caso, es muy probable que sea una personalidad o Problema político que probablemente no puedas solucionar fácilmente. Trabajar en un entorno que está fuertemente atascado por la constante reinvención es tóxico para los desarrolladores y el negocio. Ejecutar.

(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 sus prácticas. A largo plazo, todos somos culpables de ello a un grado, pero nunca se convierte en un problema.)

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

¿Qué gana al reescribirlo en SSIS? ¿Velocidad? ¿Importa? Si es un proceso que se ejecuta en una GUI y desperdicia el tiempo de todos, entonces sí, probablemente sea una buena idea acelerarlo, porque el dinero gastado en cambiarlo será devuelto por un cliente más feliz o un empleado interno que hace su trabajo en lugar de esperando el software. Pero si es un lote nocturno que comienza a las 12 am y terminará a la 1 am en lugar de a las 6 am ... 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 no abierto (y el software de código abierto que sería demasiado grande para su organización en caso de falta de actualización). Si es fundamental para su aplicación, debe tener un control estricto sobre él.

El software tiene que ver con agregar valor al cliente, y las mejoras técnicas que no brindan mucho beneficio al tiempo que introduce riesgos realmente no cumplen ese rol.

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

Es probable que tenga que pasar algún tiempo adicional fuera del tiempo normal de trabajo para desarrollar el POC.

Como una nota lateral desde el punto de vista de SSIS, lo he usado y he desarrollado paquetes de SSIS. En realidad, reemplazamos un proceso de carga patentado utilizando 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 alegraron.

SSIS es básicamente un flujo de trabajo de arrastrar y soltar con muy poca programación involucrada. Tomarse un tiempo para aprender cómo funciona la caja negra, por lo que tendrá que tomar eso en consideración si su equipo comienza a usarla.

Buenas respuestas. Si no está roto, no lo arregles. Sólo añadiría

• Si bien las preocupaciones de rendimiento pueden ser ciertas, esa palabra "podría" es una bandera roja. Primero haría un diagnóstico de rendimiento, así que tendría una prueba de cuál era el problema de rendimiento, antes de asignar cualquier recurso para resolverlo.

• Al considerar la última "solución" de Microsoft, se debe considerar que muchas personas se han quemado por lo que MS alguna vez promocionó, pero luego se desaprobó y luego dejó de ser compatible. 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.

Turnover será una consideración para su jefe. SSIS está entrando a 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 aprenderlo y poner a los nuevos programadores de C # al día, porque al igual que su equipo, la mayoría no tiene experiencia con él.

Podría indicar a su jefe que SSIS es, de hecho, una capa tecnológica 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 puede tener un punto es en el hecho de que SSIS es solo una parte de las versiones Standard y Enterprise de Microsoft Sql Server; esa es una parte bastante grande de cambio para que sus clientes se acumulen, cuando su aplicación, en un escenario de pequeña empresa, bien puede estar perfectamente bien con Sql Express (o MySQL, para el caso, que funciona con ADO.NET pero no puede utilizar la integración de 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 una gran cantidad de herramientas y servicios muy poderosos. También es hipócrita en su cara; ¿Tu 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 también lo hacen sus clientes). 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 que tendrá que mantener su implementación para mantenerse al día con lo último. Versiones de esas herramientas, o incluso reemplazarlas. Apuesto a que su jefe primero desarrolló el software para ejecutarse en Windows 95/98 o más o menos (si no es largo antes de eso, como 3.0 / 3.1). Si es así, ha visto media docena de versiones de sistemas operativos de estaciones de trabajo con Windows que van y vienen, 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 un número, de tecnologías que pueden considerarse útiles. Esos rechazos podrían basarse en análisis de costo-beneficios perfectamente válidos. Trabajo para una compañía de vigilancia por video y monitoreo de alarmas, y tomamos decisiones para respaldar o no admitir varias tecnologías o productos nuevos diariamente. Por lo general, la decisión de aceptar una nueva tecnología y el dolor de unirla con nuestro montón de software de gestión de alarmas y espectadores compatibles se basa principalmente en lo que vale para nuestros clientes. Hace poco terminé un gran proyecto de integración con un nuevo tipo de DVR, simplemente porque uno de nuestros mayores clientes existentes dijo que se estaba actualizando a ese DVR de otro producto de DVR de gran renombre pero con retraso tecnológico, y lo harían con o sin nuestro ayuda. Por otro lado, rechazamos regularmente a los nuevos fabricantes, incluso a los nombres más importantes, simplemente porque nuestros clientes no lo usan y no vemos ningún valor en comenzar a ofrecerlo, incluso si nos pierde a algunos clientes potenciales que lo tienen y no lo tienen. No quiero pagar por nuestra versión de lo mismo.

  

No tengo tiempo para escribir la conversión de la manera antigua, autoaprendizaje de SSIS y también para escribir la nueva forma de demostrar / probar los beneficios (ninguno de nosotros ha usado SSIS, por lo que habría un período donde tendríamos que aprender a usarlo).

Ese es el tipo de problema, ¿no es así? Estás pidiendo a otras personas que arriesguen su productividad con tu idea, y no estás dispuesto a arriesgarte para demostrar 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 intenta reemplazar es fundamental para lo que hace su software (consulte su comentario "atornillado"). Un buen gerente sabe que usted externaliza su negocio principal a su propio riesgo. Está, con razón, preocupado por apostar a la granja en algún tipo de tecnología que podría desaparecer en el futuro. Cuando las funciones básicas están involucradas, Not Invented Here es realmente una buena cosa.

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

Si bien existe el mérito de "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 una gerencia de nivel medio, esto es cierto. Si se hiciera un análisis de costos sobre el tiempo dedicado 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 empresa, 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 de borde, 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 una carga de basura. Está tan lejos del trabajo creativo como se puede conseguir.

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

A largo plazo, la compra de una herramienta, como Informatica o el uso de SSIS, le ahorrará a la empresa potencialmente millones en el 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 origen 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 fuente señalados por la respuesta de Jim, no lo sabía.

Problema lateral: Por lo tanto, para acelerar, sugiero reducir el tamaño de las transacciones para los bultos de su imagen. Digamos, cada 800 en lugar de 5000 rocords. Puede reducir el tamaño de la E / S necesaria para admitir esa transacción.