Meine Abteilung ist darauf spezialisiert, Kundendaten in unser Datenbankschema zu konvertieren, damit sie unsere Software verwenden können.

Im Moment haben wir C # -Anwendungen, die eine IDataReader(99% der Zeit, in der es sich um eine handelt SqlDataReader), eine Bereinigung und Zuordnung durchführen, sie in ein DataRowObjekt einfügen und dann mit a SqlBulkCopyin unsere Datenbank einfügen.

Manchmal (insbesondere, wenn die Quelldatenbank Bilder als varbinaryObjekte enthält ) kann dieser Prozess mit einer SQL-Übertragung vom Server zur App zum Stillstand kommen, um sich dann nach rechts umzudrehen und zum Server zurückzukehren.

Ich bin der Meinung, dass einige der Konvertierungen, die wir als SSIS-Pakete neu geschrieben haben, die Dinge erheblich beschleunigen könnten. Die größte Steinmauer, auf die ich stoße, ist jedoch, wenn mein Chef in der Art von " Not Invented Here " zurückschiebt und sagt: "Was ist, wenn Microsoft die Unterstützung für SSIS einstellt? Wir werden all diesen veralteten Code haben und fertig sein."

Dies ist nicht das erste Mal, dass ich ein "Was ist, wenn sie diese Funktion entfernen ...?" Antwort von meinem Chef. Ich habe nicht die Zeit, die Konvertierung auf die alte Art und Weise zu schreiben, mir SSIS selbst beizubringen und sie auch neu zu schreiben, um die Vorteile zu demonstrieren / zu testen müssen lernen, wie man es benutzt).

Was soll ich in dieser Situation tun? Hör auf, die neue Technologie voranzutreiben? Warten Sie, bis er die Abteilung verlässt (ich bin der zweithäufigste Senior in der Abteilung nach ihm, aber es könnte Jahre dauern, bis er aus der Abteilung ausscheidet / in den Ruhestand geht)? Finden Sie eine neue Möglichkeit, ihn dazu zu bringen, keine Angst mehr vor Tools von Drittanbietern zu haben?

Ich werde dies von einem Management-Standpunkt aus betrachten, aber denke daran, dass mir bewusst ist, dass ich nicht alle Details habe. Ich werde zusammenfassen, was ich sehe:

1. Entwickler auf mittlerer Ebene, wir nennen ihn "Scott", empfehlen, den alten Code in SSIS umzuschreiben, um die Leistung wichtiger ProcessA-Prozesse zu verbessern.
2. ProcessA verhält sich derzeit in einem funktionsfähigen Zustand, bei dem keine größeren Probleme bekannt sind.
3. ProcessA wurde mit proprietären Tools geschrieben, die allgemeines oder potenziell Stammeswissen verwenden, um es zu pflegen.
4. Für die Umschreibungsempfehlung sind neue Tools zur Unterstützung erforderlich.
5. Derzeitige Mitarbeiter haben keine dokumentierten Erfahrungen / Kenntnisse mit den neuen Tools.
6. Neue Tools sind ein relativ neuer Ersatz für ältere Tools, und die Unterstützung für diese Tools kann sich innerhalb von vier Geschäftsquartalen erheblich ändern.

Aus dieser Perspektive sehe ich nur einen hohen Geldaufwand des Unternehmens, um einen Prozess zu verbessern, der nicht unterbrochen wird . Vom technischen Standpunkt aus kann ich die Anziehungskraft sehen, aber wenn man es genau betrachtet, macht es aus wirtschaftlicher Sicht einfach keinen Sinn, diese Änderung vorzunehmen. Wenn Sie über Mitarbeiter mit dokumentierten Erfahrungen mit SSIS und Benchmarks verfügen, die eine massive Verbesserung dieses Prozesses nachweisen (bedenken Sie, dass eine massive Verbesserung mit $$$ gleichzusetzen ist), ist das Ergebnis möglicherweise ein wenig anders. In der jetzigen Situation müsste ich der Geschäftsführung zustimmen (irgendwo ist gerade ein Baum gestorben).

Wenn Sie die Einführung von SSIS fördern und möglicherweise zu diesem Umgestalter führen möchten, müssen Sie diese Erfahrung und Schulung bei kleineren, weniger wichtigen Projekten sammeln. Stellen Sie Benchmarks und Support für SSIS bereit und stellen Sie sicher, dass die gesamte Infrastruktur und der Support vorhanden sind, bevor das Management überhaupt eine Änderung in Betracht zieht. Sobald Sie das Tool an einem anderen Ort im Einsatz haben, die Mitarbeiter im Team mit seiner Verwendung vertraut sind und einen geschäftlichen "Komfort" -Faktor haben, bei dem sich durch die Unterstützung nicht alles ändert und entwurzelt, werden Sie mit größerer Wahrscheinlichkeit jemanden zu Ihrem Standpunkt hinlenken. Ohne diese bellt man mit diesem Argument den falschen Baum auf.

So dumm das klingt, manchmal ist der "beste" Weg nicht der beste Weg.

Bearbeiten: Als Antwort auf einige Aktualisierungen der Frage werde ich eine geringfügige Änderung meiner Antwort veröffentlichen.

Wenn der Prozess in Schwierigkeiten gerät, ist das Umschreiben immer noch ein kostspieliges Unterfangen. Möglicherweise möchten Sie überlegen, wie hoch die Kosten für die Feinabstimmung des vorhandenen Codes für das Neuschreiben des Pakets wären. Berücksichtigen Sie die Auswirkungen nicht nur auf die Software, sondern auch auf alle menschlichen Schnittstellenprozesse. Bei dem Versuch, das Management-Buy-in für ein Neuschreiben zu erhalten, kommt es immer auf das Geld an. Solange Sie nicht nachweisen können, dass die aktuelle Notlage jetzt Geld kostet oder insgesamt zu groß wird, wird das Management den Nutzen immer noch nicht erkennen. Diese Kosten müssen nicht unbedingt finanzieller Natur sein. Wenn die Verlangsamung ein System beeinträchtigt, das Ausfallzeiten verursacht, Einbruchsvektoren oder ein anderes "schwer zu quantifizierendes" Symptom einführt, müssen Sie möglicherweise einen Weg finden, um dieses Problem in ein monetäres Risikoäquivalent zu übersetzen. Ein Aufschaltungsvektor, zum Beispiel, Dies kann zu einem Eingriff führen, der zum Verlust, Diebstahl oder zur Beschädigung von Daten führen kann. Das Unternehmen könnte an Ansehen verlieren oder eine erforderliche Sicherheitsüberprüfung nicht bestehen. Der Schlüssel besteht darin, den betreffenden Manager zu veranlassen, den messbaren Nutzen der Änderung zu erkennen.

Dinge zu brechen ist eine Fähigkeit

Ich habe an viel zu vielen Orten gearbeitet, die das Argument "Wenn es nicht kaputt geht" so weit aufgegriffen haben, dass sie nicht mehr innovativ sind, und wenn sie schließlich zur Innovation gezwungen werden, reagieren sie überreagiert, indem sie alles verändern . Einfach, weil ihnen die Erfahrung fehlt, Dinge zu zerbrechen .

Es braucht Reife, Können und Erfahrung, um Dinge zu brechen.

Entwicklungsteams, die immer auf Nummer sicher gehen, sind für einen Konkurrenten am einfachsten zu übertreffen. Nur Teams, die gescheitert sind, Fehler gemacht und Dinge kaputt gemacht haben, sind in der Lage, ehrliche Risikobewertungen vorzunehmen.

Den Status Quo behalten

Das aktuelle System erfüllt zwar die aktuellen Geschäftsanforderungen. Dies gilt nicht für zukünftige unvorhergesehene Änderungen dieser Anforderungen. Wie das alte Sprichwort sagt "das Glück bevorzugt das Vorbereitete".

Diese Frage hat nichts mit SQL oder Leistung zu tun. Es geht darum, die Frage zu stellen: "Gibt es einen besseren Weg?" und keine Angst zu haben, eine Alternative zu versuchen.

Ihr Chef leidet unter dem Fall, dass er den Status Quo beibehält .

Die Mayas

Nichts funktioniert wirklich perfekt.

Die Mayas bauten ihr Essen am Rande der Berge an. Bis alle Nährstoffe weggespült waren und sie keine Möglichkeit hatten, ihre Leute zu ernähren. Sie machten so weiter, bis es zu spät war.

Angenommen, Sie haben Zeit, um ein Problem zu beheben, wenn das Problem auftritt, ist ein Fehler.

Was ist zu tun?

Ihr Chef leidet unter einer Konditionierung. Menschen, die den Status Quo akzeptieren, tun dies häufig, weil sie nicht in der Lage sind, schwierige Entscheidungen zu treffen. Wenn sie sich einer Herausforderung gegenübersehen, werden sie dazu neigen, die Option zu wählen, die dem am nächsten kommt, mit dem sie vertraut sind.

Angst um ihn ist eine große Motivation. Die Angst vor unbekannten oder sich ändernden Bedingungen erschüttert seine Sicht auf den Status quo. Er wird versuchen, die Bedingungen so schnell wie möglich wieder herzustellen.

Sie müssen Ihre Ideen konfliktfrei präsentieren. Versuchen Sie, Gemeinsamkeiten zu finden zwischen dem, was Sie mit dem, was bereits der Status Quo ist, tun möchten. Präsentieren Sie Argumente, die seine Angst vor Veränderungen mindern, und versichern Sie, dass Sie eine Aufgabe erledigen möchten, die keine wesentlichen Änderungen hervorruft.

Machen Sie kleine Schritte

Es ist am besten, Änderungen anzubieten, die das Projekt in die gewünschte Richtung bewegen, jedoch über kleine inkrementelle Projekte. Schlagen Sie lieber Ihren Chef mit der großen Frage nach der Unterstützung von SSIS an. Bieten Sie an, eine Trennebene im Code zu erstellen, mit der Sie "alternative" Methoden für die Verarbeitung von Tabellen mit großen Anhängen einbinden können. Anschließend können Sie fortfahren, um SSIS zu empfehlen, wobei alle Voraussetzungen bereits zum Projekt hinzugefügt wurden. Dies verringert das Risiko, das Ihr Chef sich vorstellt, indem er die Änderung akzeptiert.

Es braucht Zeit

Ich habe die Erfahrung gemacht, dass Risikoträger ein Projekt in Bewegung halten und Status Quo-Bewahrer wie eine Mauer sind. Beharrlichkeit ist Ihre einzige Option, um ihre Barrieren abzubauen. Erwarten Sie, auf Ihre Anfragen mit Nein zu antworten.

Wenn die Zeit für Innovationen kommt. Ihr Chef wird sich schnell an Sie wenden, weil Sie angesichts von Veränderungen Furchtlosigkeit zeigen. Etwas, das ein Status-Quo-Mensch sucht, und Sie werden für Ihre Bemühungen belohnt. Auch wenn keine Ihrer vorherigen Anfragen angenommen wurde. Sie werden schnell zu einem unersetzlichen Vermögenswert in einem Unternehmen, das sich einer Veränderung gegenübersieht, die nichts anderes beinhaltet.

Ich denke, wenn wir einige der Konvertierungen als SSIS-Pakete neu schreiben, könnte dies die Dinge erheblich beschleunigen. Die größte Steinmauer, auf die ich stoße, ist jedoch, wenn mein Chef in der Art von "Not Invented Here" zurückschiebt und sagt: "Was ist, wenn Microsoft die Unterstützung für SSIS einstellt? Wir werden all diesen veralteten Code haben und fertig sein."

Meiner Meinung nach ist die Skepsis gegenüber SSIS berechtigt.

• Erfahrene Entwickler hassen Black Boxes, und in einem SSIS-Paket steckt viel Magie.
• Die Unterstützung der Quellcodeverwaltung für SSIS-Pakete fehlt dringend. Das Vergleichen und Zusammenführen von SSIS-DTSX-Dateien kann ein Albtraum sein, wenn Ihre DTSX-Pakete nicht modular genug sind.
  • Im Gegensatz dazu sind C # -Konsolenanwendungen sehr transparent. Sie können immer dem Code folgen, um herauszufinden, was falsch läuft.

Denken Sie auch daran, dass Ihr Chef am Haken liegt, wenn etwas schief geht.

• Daher hat er das Recht, die übergeordnete / einzige Meinung zu dieser Angelegenheit zu haben.

Ich habe nicht die Zeit, die Konvertierung auf die alte Art und Weise zu schreiben, mir SSIS selbst beizubringen und sie auch neu zu schreiben, um die Vorteile zu demonstrieren / zu testen müssen lernen, wie man es benutzt).

Was soll ich in dieser Situation tun? Hör auf, die neue Technologie voranzutreiben? Warten Sie, bis er die Abteilung verlässt (ich bin der zweithäufigste Senior in der Abteilung nach ihm, aber es könnte Jahre dauern, bis er aus der Abteilung ausscheidet / in den Ruhestand geht)? Finden Sie eine neue Möglichkeit, ihn dazu zu bringen, keine Angst mehr vor Tools von Drittanbietern zu haben?

Ich empfehle , dass Sie SSIS gut genug lernen , so dass Sie können ihre Vorteile zeigen.

Und wenn Sie nach Ihrem Selbststudium feststellen, dass SSIS erhebliche Vorteile gegenüber dem eher "traditionellen" Ansatz bietet und Sie Ihren Chef immer noch nicht davon überzeugen können, den Kurs zu ändern, dann empfehle ich Ihnen, einen anderen Job zu finden, in dem Sie es können Verwenden Sie SSIS.

Die Antwort, die Sie fast immer von den meisten Managertypen erhalten, lautet etwa:

"Es ist es nicht wert, es funktioniert jetzt und es wird Zeit kosten, es zu ändern."

Und im Allgemeinen gilt dies. Dies ist jedoch nicht immer ein stichhaltiges Argument, da das Kernproblem beim "Not Invented Here" -Syndrom nicht darin besteht, ob die Dinge funktionieren oder nicht, sondern dass diese Technologie sinnlos umgeschrieben wird , Arbeitsstunden verschwendet und den Wert erheblich beeinträchtigt vom gelieferten Produkt.

Sie müssen feststellen, ob Not Invented Here tatsächlich stattfindet, bevor Sie entscheiden, was zu tun ist. Die interne Technologie wurde möglicherweise aus einem bestimmten Grund geschrieben .

Anzeichen dafür, dass die Technologie aus einem bestimmten Grund umgeschrieben wurde:

• Die Technologie, die Sie verkaufen, ist auch das Produkt . Wenn Sie ein Datenbankanbieter sind, ist die Verwendung von MySQL-Code aus vielen Gründen eine gefährliche Idee, unabhängig davon, wie viel Zeit Sie einsparen.
• Die interne Technologie ist gut gewartet und behebt effektiv die Mängel der Standardlösung, bietet aber dennoch eine vergleichbare Basisfunktionalität.
• Die Technologie verbessert die Produktivität des gesamten Entwicklungsteams, und neue Entwickler können leicht erkennen, warum sie verwendet wird.
• Es gibt andere Beispiele, bei denen das Unternehmen andere externe Technologien erfolgreich übernommen hat .
• Ihr Geschäft würde sofort und ernsthaft beeinträchtigt, wenn die OTS-Lösung eingestellt oder beschädigt würde.
• Das Unternehmen ist so umfangreich, dass es über die Ressourcen verfügt, um hochwertige Tools zu geringen Kosten zu erstellen (beispielsweise kann Google möglicherweise eine Datenbank erstellen, die weniger als 1000 US-Dollar pro Lizenz für MS SQL kostet).

Mit anderen Worten, das Team versteht die Nachteile der Lösung bereits gelöster Probleme, machte jedoch vernünftigerweise Ausnahmen, wenn dies aus geschäftlicher Sicht sinnvoll war.

Zeichen von "hier nicht erfunden":

• Anscheinend ist alles intern und es gibt Ausreden für alles: "Äh, es war zu langsam", "Äh, es ist Microsoft, wir hassen Microsoft", "Äh, es sieht wirklich schwer zu bedienen aus" usw.
• In Fällen, in denen externe Technologie verwendet wird, hört man "Ja, es stinkt und wir planen, irgendwann unsere eigene zu schreiben ".
• Die Eigentümer dieser Komponenten haben keine anderen Jobs, an denen sie arbeiten können.
• Sie sehen, dass die meisten neuen Entwickler über eine allgemein anerkannte Qualifikation verfügen, es dauert jedoch einige Zeit, bis sie sich auf die internen Tools vorbereitet haben
• Nach sorgfältiger Analyse wird deutlich, dass der Wechsel von der OTS-Lösung zu einer benutzerdefinierten oder einer anderen OTS-Lösung im Abschnitt "Was ist, wenn sie nicht mehr angeboten wird? " Das Szenario hätte nur minimale Auswirkungen auf das Geschäft . Wenn Sie beispielsweise String.Join()aus .NET Framework entfernen, ist die Neuimplementierung in eine benutzerdefinierte StringJoin()Methode trivial.

Mit anderen Worten, NIH ist das Muster, dass es nicht objektiv und realistisch bleibt, wenn externe Technologien anstelle des eigenen Codes verwendet werden.

Wenn Technik aus einem bestimmten Grund umgeschrieben wird, sollten Ihre Vorgesetzten Ihre Bedenken loben und würdigen. Es sollte eine sorgfältige Entscheidung gewesen sein, als die Technologie implementiert wurde, und die Entscheidung gelegentlich zu überprüfen, ist gut für das Geschäft. Die Dinge ändern sich mit der Zeit und Sie haben möglicherweise einen gültigen Punkt. Wenn Sie Zahlen über in der Vergangenheit verschwendete Zeit, prognostizierte Kosten für den Wechsel und andere Informationen angeben können, können Sie (theoretisch) einen Wechsel begründen.

Verstehe, dass sie aufgrund deiner Erfahrung möglicherweise nicht mit deinen Zahlen übereinstimmen, aber egal, sie sollten dich zumindest anhören. Es kann einige Zeit dauern, um Respekt zu erlangen.

Wenn die Konversation nicht einmal zur Sprache gebracht werden kann, selbst wenn Sie höflich sind, könnte es sein, dass sie "hier nicht erfunden" ist. In diesem Fall handelt es sich höchstwahrscheinlich um ein persönliches oder politisches Problem, das Sie wahrscheinlich nicht einfach beheben können. Das Arbeiten in einer Umgebung, die durch ständige Neuerfindungen stark in Mitleidenschaft gezogen wird, ist für die Entwickler und das Unternehmen giftig. Lauf.

(Randbemerkung: In den meisten Unternehmen gibt es immer ein Element von NIH, aber es ist auf einem tolerierbaren Niveau, und solange sie ihren Kodex und ihre Praktiken regelmäßig überprüfen. Langfristig sind wir alle bis zu einem gewissen Grad daran schuld, aber es wird nie ein Problem.)

Nun, es geht nur um die Kosten-Nutzen-Analyse.

Was bringt es Ihnen, wenn Sie es in SSIS umschreiben? Geschwindigkeit? Ist das wichtig? Wenn es sich um einen Prozess handelt, der in einer grafischen Benutzeroberfläche ausgeführt wird und alle Zeit verschwendet, ist es wahrscheinlich eine gute Idee, ihn zu beschleunigen, da das ausgegebene Geld für das Ändern von Änderungen von zufriedenen Kunden oder internen Mitarbeitern zurückgewonnen wird, die ihre Arbeit erledigen, anstatt Warten auf die Software. Aber wenn es eine Nachtreihe ist, die um 12 Uhr beginnt und um 1 Uhr morgens statt um 6 Uhr morgens endet ... gibt es nicht viel Sinn. Ja, es ist 6 Mal schneller, aber niemand wird den Unterschied spüren.

Und Ihr Chef hat einen guten Punkt. Microsoft neigt dazu, einige seiner Technologien aufzugeben. VB6, Linq-to-SQL, ASP-Klassiker, COM + ... Dies ist ein Risiko bei nicht-Open-Source-Software (und Open-Source-Software, die für Ihr Unternehmen zu groß wäre, um sie bei fehlendem Update zu warten). Wenn es für Ihre Anwendung von zentraler Bedeutung ist, sollten Sie eine strenge Kontrolle darüber haben.

Bei Software geht es darum, dem Kunden einen Mehrwert zu verschaffen, und technische Verbesserungen, die nicht viel Nutzen bringen und gleichzeitig Risiken mit sich bringen, erfüllen diese Rolle nicht wirklich.

Entwickeln Sie einen POC (Proof of Concept) und stellen Sie ihn Ihrem Vorgesetzten vor. Der POC soll Ihnen dabei helfen, den tatsächlichen Nutzen der von Ihnen vorgeschlagenen Technologie zu ermitteln. Dann können Sie und Ihr Vorgesetzter über die Technologie sprechen und Vor- und Nachteile entwickeln, um sie umzusetzen.

Wahrscheinlich müssen Sie etwas mehr Zeit außerhalb der normalen Arbeitszeit aufwenden, um den POC zu entwickeln.

Als Randnotiz aus Sicht von SSIS habe ich es verwendet und SSIS-Pakete entwickelt. Wir haben tatsächlich einen proprietären Ladeprozess durch SSIS-Pakete ersetzt. Dies haben wir nur gemacht, weil sich die tatsächlichen Kunden über die Ladezeiten beschwert haben. Die Ladezeiten konnten mit SSIS erheblich verkürzt werden und alle waren zufriedener.

SSIS ist im Grunde ein Drag & Drop-Workflow mit sehr wenig Programmieraufwand. Es dauert einige Zeit, bis Sie erfahren, wie die Black Box funktioniert. Sie müssen dies berücksichtigen, wenn Ihr Team sie verwendet.

Gute Antworten. Wenn es nicht kaputt ist, reparieren Sie es nicht. Ich würde nur hinzufügen

• Während die Leistungsbedenken tatsächlich wahr sein könnten, ist dieses Wort "könnte" eine rote Fahne. Ich würde zuerst eine Leistungsdiagnose durchführen, um den Beweis für das Leistungsproblem zu erhalten, bevor Ressourcen für die Behebung des Problems bereitgestellt werden.

• Wenn man die neueste "Lösung" von Microsoft in Betracht zieht, sollte man bedenken, dass viele Menschen von dem, was MS einst ankündigte, verbrannt wurden, aber anschließend veraltet und dann nicht mehr unterstützt wurden. Wenn Sie möchten, dass Software 10 oder 20 Jahre lang ohne größere Neucodierung ausgeführt wird, sollten Sie diesbezüglich sehr vorsichtig sein. Unsere Firma wurde auf diese Weise schwer verletzt.

Der Umsatz wird eine Überlegung für Ihren Chef sein. SSIS betritt die DBA-Arena im Vergleich zu einem Programmierer mit diesen Fähigkeiten. Wenn Ihre Anwendung SSIS nicht über die anfängliche Konvertierung hinaus verwendet, ist es nicht sinnvoll, dies zu lernen und neue C # -Programmierer auf den neuesten Stand zu bringen, da die meisten wie Ihr Team keine Erfahrung damit haben.

Sie können Ihrem Chef klar machen, dass SSIS in der Tat eine ältere Technologieebene als .NET Framework ist, wenn Sie als "Data Transformation Framework" von SQL 7.0 zu seinen Wurzeln zurückkehren.

Wo Ihr Chef einen Punkt haben könnte, ist die Tatsache, dass SSIS nur ein Teil der Standard- und Enterprise-Versionen von Microsoft SQL Server ist. Das ist eine ziemlich große Veränderung für Ihre Kunden, wenn Ihre Anwendung in einem kleinen Geschäftsszenario mit Sql Express (oder MySQL, was mit ADO.NET funktioniert, aber nicht funktioniert) durchaus in Ordnung sein kann SSIS-Integration verwenden).

Lassen Sie mich jetzt ganz klar sein; IMO, NIH ist fast nie eine gute Sache für ein Softwareentwicklungshaus. Es sperrt Sie aus vielen sehr leistungsfähigen Werkzeugen und Diensten. Es ist auch scheinheilig im Gesicht; Hat Ihre Firma Visual Studio geschrieben? Wie wäre es mit dem .NET Framework? SQL Server? Windows? Nein. Sie bauen Ihre Software auf den Tools und Plattformen auf, die Sie bereits haben (und Ihre Kunden auch). Wenn Sie also feststellen, dass ein Tool allgemeine Akzeptanz findet und für die Ausführung Ihres Kerngeschäfts nützlich sein kann, übernehmen Sie es und lernen, mit dem Risiko umzugehen, dass Sie Ihre Implementierung warten müssen, um mit den neuesten Entwicklungen Schritt zu halten Versionen dieser Tools oder ersetzen Sie sie sogar. Ich wette, Ihr Chef hat die Software zuerst so entwickelt, dass sie unter Windows 95/98 oder so läuft (wenn auch nicht langedavor wie 3.0 / 3.1). In diesem Fall sah er ein halbes Dutzend Versionen von Windows-Workstation-Betriebssystemen kommen und gingen und musste seine Software aktualisieren, um auf den neueren Plattformen ausgeführt zu werden, und er hat eine andere mit XP, das offiziell EOLed ist. Während er sich beschweren kann, ist das einfach die Kosten für das Geschäft.

Eine Haltung von NIH folgt jedoch nicht notwendigerweise aus der Weigerung, eine oder sogar eine Reihe von Technologien zu akzeptieren, die als hilfreich angesehen werden können. Diese Ablehnungen könnten auf einwandfrei gültigen Kosten-Nutzen-Analysen beruhen. Ich arbeite für ein Videoüberwachungs- und Alarmüberwachungsunternehmen und wir treffen täglich die Entscheidung, verschiedene neue Technologien oder Produkte zu unterstützen oder nicht zu unterstützen. Normalerweise hängt die Entscheidung, eine neue Technologie zu akzeptieren, und die Schwierigkeit, sie zusammen mit unserer vorhandenen Menge unterstützter Viewer- und Alarmverwaltungssoftware zu verwenden, in erster Linie davon ab, was sie für unsere Kunden wert ist. Ich habe kürzlich ein großes Integrationsprojekt mit einem neuen DVR-Typ abgeschlossen, weil einer unserer größten bestehenden Kunden angab, von einem anderen bekannten, aber technologisch nacheilenden DVR-Produkt auf diesen DVR umzurüsten. und sie würden es mit oder ohne unsere Hilfe tun. Auf der anderen Seite lehnen wir regelmäßig neue Hersteller ab, auch große bekannte Namen, einfach weil unsere Kunden es nicht verwenden und wir keinen Wert darin sehen, es anzubieten, selbst wenn es uns ein paar potenzielle Kunden verliert, die es haben und es nicht anbieten. ' Ich möchte nicht für unsere Version derselben Sache bezahlen.

Ich habe nicht die Zeit, die Konvertierung auf die alte Art und Weise zu schreiben, mir SSIS selbst beizubringen und sie auch neu zu schreiben, um die Vorteile zu demonstrieren / zu testen müssen lernen, wie man es benutzt).

Das ist ein Problem, oder? Sie fordern andere Menschen auf, ihre Produktivität in Bezug auf Ihre Idee zu riskieren, und Sie sind nicht bereit, sich auf die Probe zu stellen, um ihnen zu zeigen, dass es sich lohnt. Technische Führung erfordert, entweder Ihren Ruf oder Ihre Freizeit zu riskieren, um zu beweisen, dass Ihre Ideen es wert sind, dass Sie sie haben.

Versuchen Sie, die Dinge aus Sicht Ihres Chefs zu sehen. Es hört sich so an, als ob die Funktionalität, die Sie ersetzen möchten, der Kern dessen ist, was Ihre Software tut (vgl. Seinen "verdrehten" Kommentar). Ein guter Manager weiß, dass Sie Ihr Kerngeschäft auf eigene Gefahr auslagern. Er ist zu Recht besorgt, die Farm auf ein technisches Teil zu setzen, das in Zukunft verschwinden könnte. Wenn es um Kernfunktionen geht, ist Not Invented Here eigentlich eine gute Sache.

Wenn Geschwindigkeit eine Funktion ist, müssen Sie einen anderen Weg finden, um die Dinge zu beschleunigen. Ansonsten, wenn Geschwindigkeit für Sie wichtiger ist als für Ihre Kunden, sage ich, lassen Sie es fallen und vergessen Sie es.

Obwohl es ein Verdienst ist, "nicht zu reparieren, was nicht kaputt ist", bin ich mit der akzeptierten Antwort nicht einverstanden.

Die akzeptierte Antwort kommt aus der Perspektive, dass das Problem nicht gebrochen ist. Aus Sicht des Managements auf mittlerer Ebene ist dies richtig. Wenn eine Kostenanalyse über den Zeitaufwand der Entwickler für die Erstellung und Wartung einer ETL-Lösung in C # im Vergleich zum Kauf einer gebrauchsfertigen Lösung durchgeführt würde, würde sich herausstellen, dass die Erstellung der C # -Lösung drei- bis viermal länger dauert und zu pflegen und so viel wie 10-mal mehr kosten (Ich suchte nach der Referenz auf den Zahlen, aber ich konnte es nicht finden).

Sofern es sich nicht um die Kernkompetenz des Unternehmens handelt, gibt es kaum einen Grund, Datentransformationen in C # zu schreiben und zu verwalten. Die hausgemachte Lösung wird langsam sein, es wird Fehler geben (dh korrupte Daten), es wird Randfälle geben, es wird wenig Wiederverwendung zwischen ETL-Klassen geben und es wird zerbrechlich sein. Ehrlich gesagt, welcher Entwickler möchte seine / ihre Tage damit verbringen, ETL in C # zu schreiben und zu pflegen? Ich habe es getan. Es ist eine Menge Mist. Es ist ungefähr so ​​weit weg von kreativer Arbeit, wie es nur geht.

Verwenden Sie ein Tool wie Informatica, ein Unternehmen, dessen Geschäft ETL ist. Sie haben dieses Problem seit über 15 Jahren bearbeitet. Sie haben es gelöst. Ihre Werkzeuge sind Drag & Drop, die Wiederverwendbarkeit ist ebenso integriert wie die Leistung. Die meisten Benutzer (dh Entwickler haben keine) können ETL mit Informatica-Tools erstellen. Ich versuche nicht, Informatica zu verkaufen, sondern benutze ein Tool. Erfinde das Rad einfach nicht neu.

Auf lange Sicht spart der Kauf eines Tools wie Informatica oder die Verwendung von SSIS dem Unternehmen möglicherweise Millionen auf lange Sicht. Und das Beste ist, dass Sie die ETL nicht warten müssen oder dafür verantwortlich sind, wenn sie kaputt geht.

Ich habe zuvor versucht, mit SSIS einfache Aufgaben zu erledigen.

Es kann sehr ärgerlich sein, da selbst einfache Aufgaben Diagramme mit geringer bis mittlerer Komplexität hervorbringen (nein, es gibt keine andere Möglichkeit, es zu "codieren", als die Diagramme). Und die Probleme mit der Quellcodeverwaltung, auf die Jims Antwort hinwies, waren mir nicht bewusst.

Nebenproblem: Aus Gründen der Beschleunigung schlage ich vor, die Größe der Transaktionen für Ihre Image-Bulks zu reduzieren. Sprich alle 800 statt 5000 Rocords. Dies kann die Größe der E / A verringern, die zur Unterstützung dieser Transaktion erforderlich ist.