Мій відділ спеціалізується на перетворенні даних клієнтів у нашу схему баз даних, щоб вони могли використовувати наше програмне забезпечення.

Зараз у нас є додатки C #, які займають IDataReader(у 99% часу це SqlDataReader), виконують чистку та картування, вставляють її в DataRowоб’єкт, а потім використовують a, SqlBulkCopyщоб вставити його в нашу базу даних.

Іноді (особливо, коли джерельна база даних містить зображення як varbinaryоб’єкти), цей процес може дійсно зірватися при передачі SQL з сервера на додаток, а потім лише повернути праворуч і повернутися на сервер.

Я відчуваю, що якби ми переписали деякі з конверсій як пакети SSIS, це може значно покращити ситуацію. Однак найбільший кам'яний стін, на який я продовжую працювати, - це коли мій начальник, в моді Not Invented Here , відштовхується і каже: "Що робити, якщо Microsoft відмовиться від підтримки SSIS?

Це не перший раз, коли я потрапив на "Що робити, якщо вони видалять цю функцію ..." відповідь від мого начальника. У мене немає часу написати конверсію по-старому, самонавчити себе SSIS, а також написати це новий спосіб продемонструвати / перевірити переваги (ніхто з нас не використовував SSIS, щоб був період, коли ми б доведеться навчитися ним користуватися).

Що мені робити в цій ситуації? Перестати натискати на нову технологію? Почекайте, поки він покине кафедру (я другий найстарший чоловік у відділенні після нього, але це може пройти роки, перш ніж він кине / піде на пенсію)? Знайти новий спосіб змусити його перестати боятися сторонніх інструментів?

Я вирішу це питання з управлінської точки зору, але майте на увазі, що я знаю, що у мене немає всіх деталей. Я підсумую те, що бачу:

1. Розробник середнього рівня, ми будемо називати його "Скотт", рекомендує переписати застарілий код в SSIS, щоб поліпшити продуктивність важливого процесу ProcessA.
2. Наразі ProcessA веде себе у функціонуючому стані, не маючи відомих основних питань.
3. ProcessA пишеться з власницькими інструментами, які використовують загальні або потенційно племінні знання для підтримки.
4. Рекомендація щодо перезапису потребує нових інструментів для підтримки.
5. Нинішній персонал не має документально підтвердженого досвіду / знань з новими інструментами.
6. Нові інструменти є відносно недавніми замінами на старіші інструменти, і підтримка цих інструментів може помітно змінитися протягом 4 ділових кварталів.

З цього погляду все, що я бачу, - це великі витрати грошей з боку компанії на покращення процесу, який не порушується . З технічної точки зору я бачу апеляцію, але коли ви перейдете до неї, просто не має сенсу ділових змін. Якщо б у вас був персонал з документально підтвердженим досвідом роботи з SSIS та орієнтирами, щоб показати масштабне вдосконалення цього процесу (майте на увазі, масове вдосконалення ОБОВ'ЯЗКОВО дорівнює $$$), результат може бути дещо іншим. Як і зараз, я мав би погодитися з керівництвом (десь дерево просто померло).

Якщо ви хочете сприяти впровадженню SSIS і потенційно привести його до цього рефактора, вам потрібно набути цього досвіду та пройти навчання з меншими, менш важливими проектами. Забезпечте орієнтири та підтримку SSIS та переконайтесь, що вся інфраструктура та підтримка є на місці, перш ніж керівництво навіть розглянути можливість внесення змін. Коли у вас з’явиться інструмент, що використовується в інших місцях, люди в команді, які пережили його використання, і фактор «комфорту» для бізнесу, який підтримує, не зміниться і не викорінить все, ви, швидше за все, будете перекидати когось на вашу точку зору. Без цього ви гаворите неправильне дерево цим аргументом.

Як не дурно звучить, іноді "найкращий" спосіб - не найкращий спосіб.

Редагувати: У відповідь на деякі оновлення запитання я опублікую невелику зміну своєї відповіді.

Якщо процес зазнає якихось проблем, переписування його все одно буде дорогим завданням. Ви можете розглянути, яка вартість уточнення існуючого коду буде проти переписування пакета. Розглянемо вплив не тільки на програмне забезпечення, але і на будь-які процеси взаємодії людини. При спробі отримати керування на перезапис менеджменту, воно все одно зводиться до грошей. Якщо ви не зможете довести, що нинішній дистрес коштує грошей зараз або стане загальним у сукупності, керівництво все одно не побачить користі. Ця вартість не обов'язково має фінансовий характер. Якщо гальмування скомпрометує систему, що спричиняє час простою, вводить вторгнення чи інший симптом "важко оцінити", можливо, вам доведеться знайти спосіб перевести цю проблему в еквівалент грошового ризику. Вектор вторгнення, наприклад, може призвести до вторгнення, яке може призвести до втрати, викраденого або пошкодження даних. Компанія може втратити репутацію або може провалити необхідний аудит безпеки. Головне - змусити відповідного менеджера визнати кількісно вигідні зміни від змін.

Розбивати речі - це вміння

Я працював у занадто багатьох місцях, які сприйняли аргумент "якщо це не порушено" до того, що вони не вдається внести інновації, і коли вони, нарешті, змушені внести інновації, вони надреагують, змінивши все . Просто тому, що їм бракує досвіду ламати речі .

Щоб зламати речі, потрібна зрілість, вміння та досвід.

Команди розробників, які завжди грають у безпеку, найлегше перемагають конкурента. Тільки команди, які зазнали невдач, помилок та зламаних речей, здатні по-справжньому робити чесні оцінки ризиків.

Збереження статусу квоти

Хоча це правда, поточна система відповідає сучасним вимогам бізнесу. Це неправда для майбутніх непередбачених змін цих вимог. Як говорить стара прислів'я, «фортуна віддає перевагу підготовленому».

Це питання не має нічого спільного з SQL або продуктивністю. Йдеться про те, щоб задати питання "чи є кращий спосіб?" і не боячись спробувати альтернативу.

Ваш начальник страждає від випадку збереження статусу квоти .

Майя

Ніщо справді не працює ідеально.

Майя продовжували вирощувати їжу на узбережжі гір. Поки всі поживні речовини не були вимиті, і їм не було можливості годувати людей. Вони продовжували робити так само, поки не пізно.

Якщо припустити, що ви встигнете вирішити проблему, коли проблема виявиться, це помилка.

Що робити?

Ваш начальник страждає від випадків кондиціонування. Люди, які приймають статус-кво, часто роблять це, оскільки їм не вистачає можливості приймати важкі рішення. Зіткнувшись із викликом, вони схильні обирати варіант, найближчий до того, з чим вони знайомі.

Страх за нього - велика мотивація. Страх перед невідомим або мінливими умовами хитає його погляд на те, що таке статус-кво. Він прагне спробувати якнайшвидше повернути умови до нормальних умов.

Потрібно представити ідеї безконфліктно. Спробуйте знайти спільну позицію між тим, що ви хотіли б зробити, з тим, що вже є статус-кво. Представіть аргументи, які зменшують його страх перед змінами, і запропонуйте запевнити, що ви хочете виконати завдання, яке не спричинить суттєвих змін.

Зробіть дитячі кроки

Найкраще було б запропонувати зміни, які рухають проект у потрібному напрямку, але через невеликі додаткові проекти. Замість цього вдарив свого начальника з великим питанням щодо підтримки SSIS. Запропонуйте створити роздільний шар у коді, який би дозволив вам підключати «альтернативні» методи для обробки таблиць з великими вкладеннями. Потім ви можете прогресувати, щоб рекомендувати SSIS з усіма передумовами, які вже були додані до проекту. Це зменшує ризик, який передбачає ваш начальник, приймаючи зміни.

Це потребує часу

Мій досвід полягав у тому, що ті, хто приймає ризик, продовжують проект рухатися, а зберігачі статусу - як цегляна стіна. Наполегливість - ваш єдиний варіант, щоб зруйнувати їхні бар'єри. Очікувати , щоб почути Немає на ваші запити.

Коли настає час нововведень. Ваш начальник швидко звернеться до вас, тому що ви демонструєте безстрашність перед обличчям змін. Щось буде шукати людина-статус-кво, і ви будете винагороджені за свої зусилля. Навіть якщо жоден ваш попередній запит не був прийнятий. Ви швидко станете незамінним активом у компанії, яка зіткнулася зі змінами, які охоплюють не зміни.

Я відчуваю, що якби ми переписали деякі з конверсій як пакети SSIS, це може значно покращити ситуацію. Однак найбільший кам'яний стін, на який я продовжую працювати, - це коли мій начальник, в моді Not Invented Here, відштовхується і каже: "Що робити, якщо Microsoft відмовиться від підтримки SSIS? У нас буде весь цей застарілий код, і ми будемо накручені".

На мою думку, скептицизм щодо SSIS справедливий.

• Досвідчені розробники ненавидять чорні скриньки, і все, що відбувається всередині пакету SSIS, є багато магії.
• Підтримка контролю джерел для пакетів SSIS дуже бракує. Розходження та об'єднання файлів SSTS dtsx може бути кошмаром, якщо пакети dtsx недостатньо модульні.
  • На відміну від цього, консольні програми C # дуже прозорі. Ви завжди можете слідувати коду, щоб зрозуміти, що відбувається не так.

Також врахуйте, що ваш начальник на гачку, якщо щось піде не так.

• Таким чином, він має право мати головну / єдину думку з цього приводу.

У мене немає часу написати конверсію по-старому, самонавчити себе SSIS, а також написати це новий спосіб продемонструвати / перевірити переваги (ніхто з нас не використовував SSIS, щоб був період, коли ми б доведеться навчитися ним користуватися).

Що мені робити в цій ситуації? Перестати натискати на нову технологію? Почекайте, поки він покине кафедру (я другий найстарший чоловік у відділенні після нього, але це може пройти роки, перш ніж він кине / піде на пенсію)? Знайти новий спосіб змусити його перестати боятися сторонніх інструментів?

Я рекомендую вам вивчити SSIS досить добре, щоб ви могли продемонструвати його переваги.

І якщо після самостійного навчання ви виявите, що SSIS пропонує значні переваги перед «традиційним» підходом, і ви все ще не можете переконати свого начальника змінити курс, то я рекомендую вам знайти іншу роботу, в якій зможете використовувати SSIS.

Відповідь, яку ви майже завжди отримуєте від більшості типів менеджера, є чимось на зразок:

"Це не варто. Це працює зараз, і це коштуватиме часу, щоб змінити".

І взагалі це справедливо. Однак це не завжди є вагомим аргументом, оскільки основна проблема, пов’язана з синдромом "Не придумано тут", полягає не в тому, чи спрацьовують справи, чи не працює, а в тому, що технологія безглуздо переписується , витрачає робочі години компанії та шкодить значній цінності від товару, що постачається.

Вам потрібно визначити, чи не придумано Тут насправді відбувається, перш ніж вирішити, що робити. Внутрішня техніка, можливо, була написана не просто так .

Ознаки того, що Технологія переписана з причини:

• Технологія, яку ви продаєте, також є продуктом . Якщо ви продавець баз даних, використання коду MySQL, незалежно від того, скільки часу це заощадить, небезпечна ідея з багатьох причин.
• Внутрішня технологія є доглянутою та ефективно вирішує недоліки позашляхового рішення, в той же час надаючи порівнянну базову функціональність.
• Технологія підвищує продуктивність роботи всієї команди розробників, і нові розробники легко продаються, чому вона використовується.
• Є й інші приклади, коли компанія успішно застосувала інші зовнішні технології .
• На ваш бізнес буде негайно і серйозно вплинути, якщо рішення ОТС було припинено або порушено.
• Бізнес настільки великий, що у нього є ресурси для написання високоякісних інструментів з низькою вартістю (наприклад, Google може мати можливість створити базу даних, що коштує менше ніж 1000 доларів США / ліцензія MS SQL)

Іншими словами, команда розуміє недоліки повторного вирішення вже вирішених проблем, але розумно робила винятки, коли це мало сенс з точки зору бізнесу.

Ознаки "Тут не винаходили":

• Схоже, все є внутрішнім , і для всього є виправдання: "е-е, це було занадто повільно", "е-е, це Microsoft, ми ненавидимо Microsoft", "е, це виглядає дійсно важко у використанні" тощо.
• У випадках, коли використовується зовнішня техніка, ви чуєте "так, добре, це смердить, і ми плануємо в кінцевому підсумку писати свою ".
• Власники цих компонентів не мають інших завдань, над якими вони можуть працювати.
• Ви бачите більшість нових розробників із широко прийнятим набором навичок, але для їх утилізації до внутрішнього інструментарію потрібно чимало часу.
• Після ретельного аналізу стає зрозумілим, що перехід від рішення OTS до користувальницького чи іншого рішення OTS у розділі "що робити, якщо його припинено!" сценарій матиме мінімальний вплив на бізнес . Наприклад, якщо вони String.Join()були вилучені з .NET Framework, повторна реалізація до користувацького StringJoin()методу була б тривіальною.

Іншими словами, NIH - це схема невдало бути об'єктивною та реалістичною у випадках, коли зовнішній технологій використовується замість власного коду.

Коли техніка переписується з якоїсь причини, висловлюючи ваші побоювання, слід оцінювати та оцінювати начальство. Коли технологія впроваджувалася, це повинно бути обережним рішенням, а перегляд рішення періодично є корисним для бізнесу. Все змінюється з часом, і у вас може бути дійсна точка. Якщо ви можете надати номери про витрачений раніше час, прогнозовані витрати на перемикання та іншу інформацію, ви могли б (теоретично) зробити справу для перемикання.

Зрозумійте, що, враховуючи ваш досвід, вони можуть не погоджуватися з вашими номерами, але незалежно, вони повинні принаймні вас почути. Може зайняти час, щоб завоювати повагу.

Якщо розмову неможливо навіть виховувати, навіть якщо ви ввічливі, це може бути просто "Тут не придумано". У такому випадку, швидше за все, це особистісні чи політичні питання, які ви, ймовірно, не можете легко виправити. Робота в середовищі, яке сильно загрожує постійним винаходом, є токсичним для розробників та бізнесу. Біжи.

(Побічна примітка: У більшості компаній завжди є елемент NIH, але це на допустимому рівні, і поки вони регулярно переглядають свій кодекс і практику. У перспективі ми всі до певної міри винні, але це ніколи не стає проблемою.)

Ну, все про аналіз витрат / вигод.

Що ви отримуєте, переписавши його в SSIS? Швидкість? Це важливо? Якщо це процес, який виконується в графічному інтерфейсі і витрачає час на всіх, то так, це, мабуть, хороша ідея пришвидшити його, оскільки витрачені гроші, змінюючи його, будуть повернуті більш щасливим клієнтом або внутрішнім працівником, який виконує свою роботу замість того, щоб чекає програмного забезпечення. Але якщо його нічна партія розпочнеться о 12 ранку, і вона закінчиться о 1 ранку замість 6 ранку ... немає великого сенсу. Так, це 6 разів швидше, але різниці ніхто не відчує.

І у вашого начальника є хороший момент. Microsoft, як правило, відмовляється від деяких своїх технологій. VB6, Linq-S-SQL, ASP classic, COM + ... Це ризик для будь-якого програмного забезпечення, що не працює з відкритим кодом (і програмного забезпечення з відкритим кодом, яке було б занадто великим для підтримки вашої організації у разі відсутності оновлення). Якщо він є головним у вашій заявці, ви повинні мати жорсткий контроль над нею.

Програмне забезпечення - це додавання вартості клієнту, а технічні вдосконалення, які не приносять великої користі при введенні ризику, насправді не виконують цієї ролі.

Розробіть POC (Доказ концепції), а потім демонструйте його своєму начальнику. POC повинен допомогти вам визначити будь-яку реальну користь із запропонованої вами технології. Тоді ви та ваш начальник можете поговорити про технологію та розробити плюси та мінуси її впровадження.

Можливо, вам доведеться витратити трохи додаткового часу поза звичайним робочим часом, щоб розробити POC.

Як побічна примітка з точки зору SSIS, я використав її та розробив пакети SSIS. Ми фактично замінили власний процес завантаження за допомогою пакетів SSIS. Ми зробили це лише тому, що фактичні клієнти скаржилися на час завантаження. Час завантаження значно зменшився за допомогою SSIS, і всі стали щасливішими.

SSIS - це, як правило, робочий процес перетягування з дуже маленьким програмуванням. Щоб дізнатись, як працює чорний ящик, потрібен певний час, тому вам знадобиться взяти це до уваги, якщо ваша команда почне його використовувати.

Гарні відповіді. Якщо він не зламався, не виправляйте. Я хотів би лише додати

• Хоча занепокоєння щодо виконання дійсно може бути правдивим, це слово "може" є червоним прапором. Спершу я поставив би діагноз ефективності, тому мав би підтвердження того, що було проблемою продуктивності, перш ніж залучити будь-які ресурси для її вирішення.

• Розглядаючи останнє "рішення" від Microsoft, слід враховувати, що багато людей були спалені тим, що MS колись промовляло, але згодом застаріло і потім не підтримувалося. Якщо ви хочете, щоб програмне забезпечення працювало 10 або 20 років без великих перекодувань, вам слід бути дуже обережними. Наша компанія так сильно постраждала.

Обороти будуть розглядатись для вашого начальника. SSIS потрапляє на арену DBA порівняно з програмістом, який має цей набір навичок. Якщо ваша програма не використовує SSIS за межі початкової конверсії, я не впевнений, що має сенс вивчити її та отримати нових програмістів на C # до швидкості, тому що, як і ваша команда, більшість не має з цим досвіду.

Ви можете вказати своєму начальнику, що SSIS насправді є більш старим технологічним рівнем, ніж .NET Framework, якщо ви повернетесь до його коренів як "рамки трансформації даних" SQL 7.0.

Якщо у вашого начальника може бути сенс, це те, що SSIS є лише частиною стандартної та корпоративної версій сервера Microsoft Sql; це досить великий куточок змін для ваших клієнтів, щоб виправити помилки, коли ваша програма, за сценарієм малого бізнесу, цілком може відмінно працювати з Sql Express (або MySQL, з цього приводу, який працює з ADO.NET, але не може використовувати інтеграцію SSIS).

Тепер дозвольте мені бути абсолютно зрозумілим; IMO, NIH майже ніколи не є хорошою справою для дому розробки програмного забезпечення. Це позбавляє вас від безлічі дуже потужних інструментів та послуг. Це також лицемірно на обличчі; Ваша компанія написала Visual Studio? Як щодо .NET Framework? Сервер Sql? Windows? Ні. Ви будуєте своє програмне забезпечення на основі тих інструментів і платформ, які у вас вже є (і так роблять ваші клієнти). Тому, якщо ви бачите інструмент, який набуває загального визнання, і який може бути корисним для здійснення вашої основної діяльності, ви приймаєте його, і ви навчитеся жити з тим ризиком, що вам доведеться продовжувати свою реалізацію, щоб бути в курсі останніх версії цих інструментів або навіть замінити їх. Надіюсь, ваш начальник вперше розробив програмне забезпечення для роботи в Windows 95/98 або після цього (якщо не довго)до цього, як 3.0 / 3.1). Якщо так, він бачив, що півтора десятка версій ОС робочих станцій Windows приходять і виходять, і йому довелося оновити своє програмне забезпечення для роботи на новіших платформах, і він зіткнувся з ще однією з XP, офіційно EOLed. Хоча він може скаржитися, це просто вартість ведення бізнесу.

Однак ставлення до НІГ не обов'язково випливає з відмови прийняти одну чи навіть низку технологій, які можуть розглядатися як корисні. Ці відмови можуть базуватися на ідеально справедливих аналізах витрат та вигод. Я працюю в компанії з відеоспостереження та спостереження тривоги, і ми приймаємо рішення підтримувати чи не підтримувати різні нові технології чи продукти щодня. Зазвичай рішення прийняти нову технологію, а також біль, що її застосовують разом із наявним набором підтримуваного програмного забезпечення для перегляду та контролю тривоги, ґрунтується насамперед на тому, що це варто нашим клієнтам. Нещодавно я закінчив великий інтеграційний проект із новим типом відеореєстратора, просто тому, що один із наших найбільших клієнтів сказав, що вони переходять на цей DVR з іншого великого імені, але технологічно відстаючий DVR-продукт, і вони зробили б це з нашою допомогою чи без нас. З іншого боку, ми регулярно відмовляємо від нових виробників, навіть основних імен домогосподарств, просто тому, що наші клієнти не користуються цим, і ми не бачимо ніякої цінності починати пропонувати його, навіть якщо він втрачає у нас кількох потенційних клієнтів, які мають його і не хочуть ' не хочу платити за нашу версію того ж самого.

У мене немає часу написати конверсію по-старому, самонавчити себе SSIS, а також написати це новий спосіб продемонструвати / перевірити переваги (ніхто з нас не використовував SSIS, щоб був період, коли ми б доведеться навчитися ним користуватися).

Така проблема, чи не так? Ви просите інших людей ризикувати своєю продуктивністю на вашу ідею, і ви не готові виходити на кінцівку, щоб показати їм, що вона того варта. Технічне керівництво вимагає або ризикувати своєю репутацією, або вільний час, щоб показати, що ваші ідеї варто мати.

Постарайтеся побачити речі з точки зору вашого начальника. Це здається, що функціонал, який ви намагаєтеся замінити, є основним для того, що робить ваше програмне забезпечення (див. Його "накручений" коментар). Хороший менеджер знає, що ви передаєте основний бізнес на власну небезпеку. Він справедливо переживає, як робити ферму на те, що може зникнути в майбутньому. Коли основні функції задіяні, не придумано Тут насправді хороша річ.

Якщо швидкість - це особливість, вам доведеться знайти інший спосіб прискорити роботу. В іншому випадку, якщо швидкість має значення для вас більше, ніж для ваших клієнтів, я кажу, киньте її і забудьте про це.

Хоча є заслуга "не виправити те, що не порушено", я не погоджуюся з прийнятою відповіддю.

Прийнята відповідь виходить з точки зору того, що проблема не порушена. З точки зору керівництва середнього рівня, це правда. Якби аналіз витрат був зроблений на час, який витрачали розробники на створення та підтримку рішення ETL в C # порівняно з придбанням нестандартного рішення, це показало б, що для рішення C # потрібно створити 3 - 4 рази більше часу і підтримувати і коштувати в 10 разів більше (я шукав посилання на номери, але не зміг його знайти).

Якщо це не основна компетенція компанії, є дуже мало причин писати та підтримувати перетворення даних у C #. Рішення в домашніх умовах буде повільним, будуть помилки (тобто пошкоджені дані), будуть крайні випадки, буде мало використання повторно між класами ETL, і це буде неміцним. Чесно кажучи, що розробник хоче витратити свої дні на написання та підтримку ETL в C #? Я це зробив. Це безлад. Це приблизно як далеко від творчої роботи, як можна дістатися.

Використовуйте такий інструмент, як Informatica - компанія, бізнесом якої є ETL. Вони працюють над цією проблемою понад 15 років. Вони це вирішили. Їх інструменти - перетягування, вбудована повторна використання, як і продуктивність. Більшість людей (тобто розробників не надто) можуть створити ETL за допомогою інструментів Informatica. Я не намагаюся продавати Informatica, використовую будь-який інструмент. Тільки не вигадуйте колесо заново.

У довгостроковій перспективі придбання інструменту, такого як Informatica або використання SSIS, заощадить компанії потенційно мільйони протягом довгої віддачі. І найкраще вам не доведеться підтримувати ETL або нести за нього відповідальність, коли він порушується.

Я раніше намагався SSIS робити прості завдання.

Це може бути дуже прикро, оскільки навіть прості завдання народжують діаграми складності низького та середнього рівня (ні, іншого способу "кодувати", крім діаграм, немає. І проблеми з управлінням джерелами, що вказували на відповідь Джима, я не знав.

Побічна проблема: Отже, щоб пришвидшити, я пропоную зменшити розмір транзакцій для вашої кількості зображень. Скажімо, кожні 800 замість 5000 рокордів. Це може зменшити розмір вводу-виводу, необхідного для підтримки цієї транзакції.