Mi prenderò una brutta piega da un punto di vista manageriale, ma tieni presente che sono consapevole di non avere tutti i dettagli. Riassumo ciò che vedo:

1. Sviluppatore di livello medio, lo chiameremo "Scott", raccomanda una riscrittura del codice legacy in SSIS per migliorare le prestazioni del processo ProcessA importante.
2. ProcessA si sta attualmente comportando in uno stato funzionante senza grossi problemi noti.
3. ProcessA è scritto con strumenti proprietari che utilizzano conoscenze comuni o potenzialmente tribali da mantenere.
4. La raccomandazione di riscrivere richiederà nuovi strumenti da supportare.
5. Lo staff attuale non ha esperienza / conoscenza documentata con i nuovi strumenti.
6. I nuovi strumenti sono sostituzioni relativamente recenti di strumenti precedenti e il supporto per questi strumenti potrebbe cambiare in modo ragionevole entro 4 trimestri.

Da questa prospettiva, tutto quello che vedo è un grande esborso di denaro da parte dell'azienda per migliorare un processo che non è rotto . Da un punto di vista tecnico posso vedere l'appello, ma quando si arriva fino in fondo, non ha senso per fare questo cambiamento. Se disponi di personale con esperienza documentata con SSIS e benchmark per mostrare un notevole miglioramento in questo processo (tieni presente che un notevole miglioramento DEVE equivalere a $$$), il risultato potrebbe essere leggermente diverso. Allo stato attuale, però, dovrei essere d'accordo con la direzione (da qualche parte un albero è appena morto).

Se si desidera promuovere l'adozione di SSIS e potenzialmente portare a questo refactoring, è necessario acquisire questa esperienza e formazione con progetti più piccoli e meno importanti. Fornire benchmark e supporto per SSIS e assicurarsi che tutta l'infrastruttura e il supporto siano presenti prima che la direzione possa anche prendere in considerazione la possibilità di apportare la modifica. Una volta che lo strumento è stato utilizzato altrove, le persone del team hanno sperimentato il suo utilizzo e un fattore di "comfort" aziendale che il supporto non cambierà e sradicherà tutto, sarà più probabile che tu faccia oscillare qualcuno verso il tuo punto di vista. Senza questi, stai abbaiando l'albero sbagliato con quell'argomento.

Per quanto stupido possa sembrare, a volte il modo "migliore" non è il modo migliore.

Modifica: in risposta ad alcuni aggiornamenti della domanda, posterò una leggera modifica alla mia risposta.

Se il processo sta attraversando un periodo di difficoltà, la riscrittura sarà comunque costosa. Si consiglia di considerare quale sarebbe il costo della messa a punto del codice esistente contro la riscrittura del pacchetto. Considera l'impatto non solo sul software, ma su qualsiasi processo di interfacciamento umano. Quando si tenta di ottenere un buy-in di gestione per una riscrittura, verrà comunque sempre giù per i soldi. A meno che tu non possa dimostrare che il disagio attuale sta costando soldi o diventerà grande nel complesso, la direzione non vedrà ancora il vantaggio. Questo costo potrebbe non essere necessariamente di natura finanziaria. Se il rallentamento compromette un sistema che causa tempi di inattività, introduce vettori di intrusione o qualche altro sintomo "difficile da quantificare", potrebbe essere necessario trovare un modo per tradurre tale problema in un equivalente di rischio monetario. Un vettore di intrusione, ad esempio, può portare a un'intrusione che potrebbe causare dati persi, rubati o corrotti. La società potrebbe perdere la reputazione o non riuscire a un controllo di sicurezza necessario. La chiave è ottenere il manager in questione per riconoscere i benefici quantificabili del cambiamento.

Breaking Things Is A Skill

Ho lavorato in troppi posti che hanno abbracciato l'argomento "se non è rotto" al punto che non riescono a innovare, e quando alla fine sono costretti a innovare reagiscono cambiando tutto . Semplicemente perché mancano dell'esperienza di rompere le cose .

Ci vuole maturità, abilità ed esperienza per rompere le cose.

I team di sviluppo che giocano sempre al sicuro sono i più facili da superare per un concorrente. Solo le squadre che hanno fallito, commesso errori e le cose rotte sono in grado di fare veramente valutazioni del rischio oneste.

Mantenimento dello status quo

Anche se è vero, il sistema attuale soddisfa i requisiti aziendali attuali. Questo non è vero per le future modifiche impreviste a tali requisiti. Come dice il vecchio proverbio "la fortuna preferisce i preparati".

Questa domanda non ha nulla a che fare con SQL o prestazioni. Si tratta di porre la domanda "c'è un modo migliore?" e non aver paura di provare un'alternativa.

Il tuo capo soffre di un caso di Mantenimento dello status quo .

The Mayan's

Niente funziona veramente perfettamente.

I Maya continuarono a coltivare il loro cibo dalla parte delle montagne. Fino a quando tutte le sostanze nutritive erano state lavate via e non avevano modo di nutrire la loro gente. Continuavano a fare le cose nello stesso modo fino a quando non era troppo tardi.

Supponendo che avrai il tempo di risolvere un problema quando il problema si presenta è un errore.

Checosafare?

Iltuocaposoffrediuncasodicondizionamento.Lepersonecheaccettanolostatusquospessolofanno,perchénonhannolacapacitàdiprenderedecisionidifficili.Difronteaunasfidatenderannoasceglierel'opzionepiùvicinaaciòchehannofamiliarità.

Lapauraperluièunagrandemotivazione.Lapauradell'ignotoolemutevolicondizioniscuotonolasuaprospettivadiciòcheèlostatusquo.Tenderàacercarediriportarelecondizioniallanormalitàilpiùrapidamentepossibile.

Devipresentareleideeinmodononconflittuale.Cercaditrovareunterrenocomunetraciòchevorrestifareconciòcheègiàlostatusquo.Presentaargomenticheriduconolasuapauradelcambiamentoeoffrirassicurazionisulfattochedesidericompletareun'attivitàchenoncauseràcambiamentisignificativi.

Prendipiccolipassi

Sarebbemegliooffriremodifichechespostinoilprogettonelladirezionedesiderata,maattraversopiccoliprogettiincrementali.Piuttosto,colpisciiltuocapoconlagrandedomandasulsupportodiSSIS.Offridicreareunlivellodiseparazionenelcodicecheticonsentadicollegareimetodi"alternativi" per l'elaborazione di tabelle con allegati di grandi dimensioni. È quindi possibile passare a raccomandare SSIS con tutti i prerequisiti già aggiunti al progetto. Questo riduce il rischio che il tuo capo prevede accettando il cambiamento.

Ci vuole tempo

La mia esperienza è stata che chi è a rischio mantiene un progetto in movimento, e chi si occupa dello status quo è come un muro di mattoni. La persistenza è la tua unica opzione per abbattere le barriere. Aspettati di continuare a sentire No alle tue richieste.

Quando arriva il momento di innovare. Il tuo capo ti rivolgerà rapidamente a te, perché dimostrerai l'impavidità di fronte al cambiamento. Qualcosa che una persona di status quo cercherà, e sarai ricompensato per i tuoi sforzi. Anche se nessuna delle tue precedenti richieste è stata accettata. Diventerai rapidamente un patrimonio insostituibile in un'azienda che si trova di fronte a un cambiamento che abbraccia il non-cambiamento.

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."

Secondo me, lo scetticismo su SSIS è valido.

• Gli sviluppatori esperti odiano le scatole nere e c'è molta magia che accade all'interno di un pacchetto SSIS.
• Il supporto del controllo del codice sorgente per i pacchetti SSIS è gravemente carente. Diffondere e unire i file dtsx di SSIS può essere un incubo se i pacchetti dtsx non sono sufficientemente modulari.
  • Al contrario, le applicazioni della console C # sono molto trasparenti. Puoi sempre seguire il codice per capire cosa non va.

Inoltre, considera che il tuo capo è agganciato se qualcosa va storto.

• Pertanto, ha il diritto di avere l'opinione prevalente / unica in merito.

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?

Ti consiglio di imparare il SSIS abbastanza bene in modo che possa dimostrare i suoi benefici.

E se, dopo il tuo studio individuale, scopri che SSIS offre vantaggi significativi rispetto all'approccio più "tradizionale" e non riesci ancora a convincere il tuo capo a cambiare rotta, allora ti consiglio di trovare un lavoro diverso in che puoi usare SSIS.

La risposta che passi quasi sempre dalla maggior parte dei tipi di manager è qualcosa come:

"Non ne vale la pena, funziona ora e ti costerà del tempo per cambiare."

E in generale, questo è valido. Tuttavia, questo non è sempre un argomento valido, perché il problema principale che circonda la sindrome di "Non inventato qui" non è se le cose funzionano o non funzionano, ma che la tecnologia viene inutilmente scritto , sprecando ore di lavoro e sottraendo valore sostanziale al prodotto consegnato.

Devi determinare se Not Invented Here è effettivamente in atto prima di decidere cosa fare. Il tecnico interno potrebbe essere stato scritto per un motivo .

Segnala che la Tech è riscritta per un motivo:

• La tecnologia che stai vendendo è anche il prodotto . Se sei un fornitore di database, l'utilizzo del codice MySQL, indipendentemente dal tempo di salvataggio, è un'idea pericolosa per molte ragioni.
• La tecnologia interna è ben mantenuta e risolve efficacemente le carenze della soluzione off-the-shelf, pur fornendo funzionalità di base comparabili.
• La tecnologia migliora la produttività dell'intero team di sviluppo e i nuovi sviluppatori sono facilmente vendibili sul perché è in uso.
• Esistono altri esempi in cui l'azienda ha adottato con successo altre tecnologie esterne .
• La tua azienda sarebbe immediatamente e seriamente influenzata se la soluzione OTS fosse interrotta o interrotta.
• Il business è così grande che ha le risorse per scrivere strumenti di alta qualità a basso costo (ad esempio, Google potrebbe essere in grado di scrivere un database che costa meno di $ 1000 / post licenza MS SQL )

In altre parole, il team comprende gli svantaggi di risolvere i problemi già risolti, ma fa delle eccezioni in modo giudizioso laddove aveva senso dal punto di vista aziendale.

Segni di "Non inventato qui":

• Sembra tutto è interno e ci sono scuse per tutto: "uh, era troppo lento", "uh, è Microsoft, odiamo Microsoft", "uh, sembra davvero difficile da usare ", ecc.
• Per i casi in cui viene utilizzata la tecnologia esterna, senti "sì, beh, puzza e pensiamo di scrivere da soli alla fine ".
• I proprietari di quei componenti non hanno altri lavori su cui sono in grado di lavorare.
• Vedi la maggior parte dei nuovi sviluppatori che entrano in possesso di un set di abilità ampiamente accettato, ma per loro impiega molto tempo per implementare gli strumenti interni
• Dopo un'attenta analisi, diventa apparente che il passaggio dalla soluzione OTS a una soluzione personalizzata o altra soluzione OTS in il "cosa succede se è interrotto!" lo scenario avrebbe un impatto aziendale minimo . Ad esempio, se String.Join() è stato rimosso da .NET Framework, la nuova implementazione in un metodo StringJoin() personalizzato sarebbe banale.

In altre parole, il NIH è il modello di non riuscire a rimanere obiettivi e realistici nei casi in cui viene utilizzata tecnologia esterna anziché il proprio codice.

Quando la tecnologia viene riscritta per una ragione, sollevare le tue preoccupazioni dovrebbe essere lodata e apprezzata dai tuoi superiori. Doveva essere una decisione attenta quando la tecnologia è stata implementata, e rivedere la decisione di tanto in tanto è un bene per il business. Le cose cambiano nel tempo e potresti avere un punto valido. Se è possibile fornire numeri sul tempo perduto in passato, i costi previsti per il passaggio e altre informazioni, si potrebbe (in teoria) fare il caso di cambiare.

Capisci che, data la tua esperienza, potrebbero non essere d'accordo con i tuoi numeri, ma a prescindere, dovrebbero almeno sentirti. Potrebbe essere necessario del tempo per ottenere rispetto.

Se la conversazione non può essere sollevata, anche se sei educato, potrebbe semplicemente essere "Non inventato qui". In questo caso, è molto probabile che sia una personalità o problema politico che probabilmente non è possibile risolvere facilmente. Lavorare in un ambiente che è pesantemente impantanato da una costante reinvenzione è tossico per gli sviluppatori e il business. Esegui.

(Nota a margine: nella maggior parte delle aziende c'è sempre un elemento di NIH, ma è a un livello tollerabile e fintanto che rivedono regolarmente il loro codice e le loro pratiche. A lungo termine siamo tutti colpevoli grado, ma non diventa mai un problema.)

Bene, tutto riguarda l'analisi costi / benefici.

Che cosa ottieni rielaborando su SSIS? Velocità? Importa? Se è un processo che viene eseguito in una GUI e fa perdere tempo a tutti, allora sì, è probabilmente una buona idea accelerarlo, perché i soldi spesi per cambiarlo saranno recuperati da un cliente più felice o da un dipendente interno che fa il proprio lavoro invece di in attesa del software. Ma se è un lotto notturno che inizia alle 12 e termina alle 1 del mattino anziché alle 6 del mattino ... non ha molto senso. Sì, è 6 volte più veloce ma nessuno sentirà la differenza.

E il tuo capo ha un buon punto. Microsoft tende ad abbandonare alcune delle loro tecnologie. VB6, Linq-to-SQL, ASP classic, COM + ... Questo è un rischio con qualsiasi software non open source (e software open source che sarebbe troppo grande per la tua organizzazione da mantenere in caso di mancanza di aggiornamento). Se è centrale nella tua applicazione, dovresti avere un controllo stretto su di esso.

Il software è interamente basato sull'aggiunta di valore al cliente e miglioramenti tecnici che non offrono molti vantaggi mentre introducono il rischio non soddisfano realmente tale ruolo.

Sviluppa un POC (Proof of Concept) e quindi dimostralo al tuo superiore. Il POC dovrebbe aiutarti a determinare qualsiasi reale vantaggio con la tecnologia che stai proponendo. Quindi tu e il tuo superiore potete parlare della tecnologia e sviluppare vantaggi e svantaggi per implementarla.

Probabilmente dovrai dedicare un po 'di tempo extra al normale orario di lavoro per sviluppare il POC.

Come nota a margine da un punto di vista SSIS, l'ho usato e ho sviluppato pacchetti SSIS. Abbiamo effettivamente sostituito un processo di caricamento proprietario utilizzando i pacchetti SSIS. Lo abbiamo fatto solo perché i clienti effettivi si sono lamentati dei tempi di caricamento. I tempi di caricamento sono diminuiti in modo significativo con SSIS e tutti sono diventati più felici.

SSIS è fondamentalmente un trascinamento del flusso di lavoro con pochissima programmazione coinvolta. Ci vuole un po 'di tempo per imparare come funziona la scatola nera, quindi dovrai tenerne conto se il tuo team inizia ad usarlo.

Buone risposte. Se non è rotto, non aggiustarlo. Vorrei solo aggiungere

• Anche se i problemi di rendimento potrebbero effettivamente essere veri, quella parola "potrebbe" è una bandiera rossa. Prima farei la diagnosi delle prestazioni, quindi dovrei avere una prova di quale fosse il problema delle prestazioni, prima di impegnare qualsiasi risorsa per affrontarlo.

• Se si considera l'ultima "soluzione" di Microsoft, si dovrebbe considerare che molte persone sono state bruciate da ciò che la SM aveva una volta reclamizzato, ma successivamente deprecate e poi de-supportate. Se vuoi che il software funzioni per 10 o 20 anni senza ricodifica, dovresti essere molto cauto. La nostra compagnia è stata gravemente ferita in quel modo.

Il fatturato sarà una considerazione per il tuo capo. SSIS sta entrando nell'arena DBA rispetto a un programmatore con quel set di abilità. Se la tua applicazione non utilizza SSIS oltre la conversione iniziale, non sono sicuro che abbia senso apprenderlo e far sì che i nuovi programmatori C # diventino più veloci, perché come la tua squadra, la maggior parte non ne ha esperienza.

Potresti indicare al tuo capo che SSIS è, in effetti, un vecchio strato tecnologico rispetto a .NET Framework, se torni alle sue radici come "Data Transformation Framework" di SQL 7.0.

Dove il tuo capo potrebbe avere un punto è nel fatto che SSIS è solo una parte delle versioni Standard ed Enterprise di Microsoft Sql Server; questa è una grossa fetta di cambiamento per i tuoi clienti di pony su, quando la tua applicazione, in uno scenario di piccola impresa, potrebbe benissimo essere perfettamente soddisfacente con Sql Express (o MySQL, del resto, che funziona con ADO.NET ma non può utilizzare l'integrazione SSIS).

Ora, lasciami essere perfettamente chiaro; IMO, il NIH non è quasi mai una buona cosa per una casa di sviluppo software. Ti blocca da molti strumenti e servizi molto potenti. È anche ipocrita sul suo volto; la tua azienda ha scritto Visual Studio? Che ne dici di .NET Framework? Server SQL? Finestre? No. Costruisci il tuo software sopra gli strumenti e le piattaforme che hai già (e così anche i tuoi clienti). Pertanto, se vedi uno strumento che sta ottenendo un'accettazione generale e che potrebbe essere utile per svolgere il tuo core business, lo adotti e impari a vivere con il rischio che dovrai mantenere la tua implementazione per stare al passo con le ultime versioni di tali strumenti o addirittura sostituirli. Scommetto che il tuo capo ha prima sviluppato il software per funzionare su Windows 95/98 o giù di lì (se non lungo prima di quello, come 3.0 / 3.1). Se è così, ha visto andare e venire una mezza dozzina di versioni di sistemi operativi per workstation Windows e ha dovuto aggiornare il suo software per l'esecuzione sulle piattaforme più recenti, e ne sta affrontando un altro con XP ufficialmente EOLed. Mentre lui può lamentarsi, questo è semplicemente il costo di fare affari.

Tuttavia, un atteggiamento NIH non deriva necessariamente dal rifiuto di accettare uno, o anche un numero, di tecnologie che possono essere considerate utili. Tali rifiuti potrebbero basarsi su analisi costi-benefici perfettamente valide. Lavoro per una società di videosorveglianza e monitoraggio degli allarmi e prendiamo decisioni per supportare o non supportare varie nuove tecnologie o prodotti su base giornaliera. Di solito, la decisione di accettare una nuova tecnologia e il dolore di integrarla con il nostro attuale mucchio di visualizzatori supportati e software di gestione degli allarmi si basa principalmente su ciò che vale per i nostri clienti. Di recente ho terminato un grande progetto di integrazione con un nuovo tipo di DVR, semplicemente perché uno dei nostri più grandi clienti esistenti ha affermato che stavano passando a quel DVR da un altro grande nome, ma tecnologicamente in ritardo, e lo avrebbero fatto con o senza il nostro Aiuto. D'altra parte, rifiutiamo regolarmente nuovi produttori, anche importanti nomi di famiglia, semplicemente perché i nostri clienti non li usano e non vediamo alcun valore nel cominciare a offrirli, anche se ci perde alcuni potenziali clienti che ce l'hanno e don ' t voglio pagare la nostra versione della stessa cosa.

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).

Questo è il tipo di problema, no? Stai chiedendo ad altre persone di rischiare la loro produttività sulla tua idea, e non sei disposto ad uscire con gli arti per dimostrare loro che ne vale la pena. La leadership tecnica richiede di rischiare la tua reputazione o il tuo tempo libero per dimostrare che vale la pena avere le tue idee.

Cerca di vedere le cose dal punto di vista del tuo capo. Sembra che la funzionalità che stai cercando di sostituire sia fondamentale per ciò che fa il tuo software (vedi il suo commento "avvitato"). Un buon manager sa che esternalizzi il tuo core business a tuo rischio e pericolo. È giustamente preoccupato di scommettere la fattoria su un pezzo di tecnologia che potrebbe scomparire in futuro. Quando sono coinvolte le funzioni principali, Not Invented Here è in realtà una buona cosa.

Se la velocità è una caratteristica, dovrai trovare un altro modo per accelerare le cose. Altrimenti, se la velocità è più importante per te che per i tuoi clienti, io dico di lasciar perdere e di dimenticartene.

Anche se c'è il merito di "non aggiustare ciò che non è rotto" non sono d'accordo con la risposta accettata.

La risposta accettata viene dalla prospettiva che il problema non è rotto. Dal punto di vista del management di medio livello questo è vero. Se si dovesse fare un'analisi dei costi sul tempo speso dagli sviluppatori per creare e mantenere una soluzione ETL in C # rispetto all'acquisto di una soluzione pronta all'uso, mostrerebbe che la soluzione C # impiega da 3 a 4 volte di più per creare e mantenere e costare fino a 10 volte di più (ho cercato il riferimento sui numeri, ma non ho potuto trovarlo).

A meno che non si tratti della competenza principale dell'azienda, vi sono ben poche ragioni per scrivere e mantenere le trasformazioni di dati in C #. La soluzione di homegrown sarà lenta, ci saranno errori (cioè dati corrotti), ci saranno casi limite, ci sarà poco riutilizzo tra le classi ETL, e sarà fragile. Onestamente, quale sviluppatore vuole passare le sue giornate scrivendo e mantenendo ETL in C #? L'ho fatto. È un mucchio di merda. È più lontano dal lavoro creativo che si può ottenere.

Utilizza uno strumento come Informatica, una società la cui attività è ETL. Stanno lavorando a questo problema da oltre 15 anni. Hanno risolto. I loro strumenti sono drag and drop, la riusabilità è integrata, così come le prestazioni. La maggior parte di chiunque (anche gli sviluppatori non ne hanno) possono creare ETL con gli strumenti di Informatica. Non sto cercando di vendere Informatica, utilizzare qualsiasi strumento. Basta non reinventare la ruota.

A lungo termine l'acquisto di uno strumento, come Informatica o l'utilizzo di SSIS, salverà la società potenzialmente milioni nel lungo raggio. E soprattutto non dovrai mantenere l'ETL o esserne responsabile quando si rompe.

Ho provato SSIS a svolgere compiti semplici prima.

Può essere molto fastidioso, dal momento che anche semplici attività danno vita a diagrammi di complessità di livello medio-basso (no, non c'è altro modo di "codificarlo" tranne i diagrammi). E i problemi di controllo del codice sorgente indicati dalla risposta di Jim non ne ero a conoscenza.

Problema laterale: Pertanto, per accelerare, suggerisco di ridurre le dimensioni delle transazioni per i bulks delle immagini. Dì, ogni 800 invece di 5000 rocords. Può ridurre la dimensione dell'I / O necessario per supportare quella transazione.