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

Прямо сейчас у нас есть приложения на C #, которые берут IDataReader(99% времени) a SqlDataReader, выполняют некоторую очистку и отображение, вставляют его в DataRowобъект, а затем используют a, SqlBulkCopyчтобы вставить его в нашу базу данных.

Иногда (особенно когда исходная база данных содержит изображения в виде varbinaryобъектов), этот процесс может действительно затормозиться с передачей SQL с сервера в приложение, чтобы просто затем повернуть направо и вернуться на сервер.

Я чувствую, что если бы мы переписали некоторые преобразования как пакеты служб SSIS, это могло бы значительно ускорить процесс. Однако самое большое препятствие, с которым я продолжаю сталкиваться, - это когда мой босс в стиле « Не изобретено здесь» отталкивается и говорит: «Что если Microsoft откажется от поддержки SSIS? У нас будет весь этот устаревший код, и мы облажаемся».

Это не первый раз, когда я нажимаю "Что если они уберут эту функцию ...?" ответ от моего босса. У меня нет времени, чтобы написать преобразование по-старому, самостоятельно обучить себя службам SSIS, а также написать его по-новому, чтобы продемонстрировать / проверить преимущества (никто из нас не использовал службы SSIS, так что был бы период, когда мы надо научиться им пользоваться).

Что мне делать в этой ситуации? Перестать продвигать новую технологию? Подождите, пока он не покинет отдел (я второй по величине человек в отделе после него, но могут пройти годы, прежде чем он уйдет / уйдет)? Найти новый способ заставить его перестать бояться сторонних инструментов?

Я расскажу об этом с управленческой точки зрения, но имейте в виду, что я знаю, что у меня нет всех деталей. Я подведу итог, что я вижу:

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

С этой точки зрения все, что я вижу, - это большие затраты денег со стороны компании на улучшение процесса, который не нарушен . С технической точки зрения я вижу апелляцию, но когда вы к ней подходите, просто не имеет смысла вносить это изменение. Если у вас есть персонал с документированным опытом работы с SSIS и контрольными показателями, чтобы продемонстрировать значительное улучшение этого процесса (имейте в виду, что значительное улучшение ДОЛЖНО приравниваться к $$$), результат может быть немного другим. Однако в нынешнем виде я должен согласиться с руководством (где-то дерево только что умерло).

Если вы хотите способствовать внедрению SSIS и потенциально привести к этому рефакторингу, вам необходимо получить этот опыт и обучение для небольших и менее важных проектов. Предоставьте контрольные показатели и поддержку для служб SSIS, а также убедитесь, что вся инфраструктура и поддержка имеются, прежде чем руководство даже подумает о внесении изменений. Если у вас есть инструмент, которым вы пользуетесь где-то еще, люди в команде знакомы с его использованием, а фактор «комфорта» бизнеса, который поддерживает, не изменит и не искоренит все, вы с большей вероятностью склоните кого-то к своей точке зрения. Без этого вы лаете не на то дерево с этим аргументом.

Как бы глупо это ни звучало, иногда «лучший» путь не самый лучший.

Изменить: В ответ на некоторые обновления к вопросу, я опубликую небольшую модификацию моего ответа.

Если процесс переживает какое-то бедствие, переписать его все равно будет дорогостоящим предприятием. Возможно, вы захотите подумать, сколько будет стоить тонкая настройка существующего кода против переписывания пакета. Рассмотрите влияние не только на программное обеспечение, но и на любые процессы взаимодействия человека. При попытке переписать управленческий взнос, он все равно всегда сводится к деньгам. Если вы не можете доказать, что текущее бедствие сейчас стоит денег или станет большим в совокупности, руководство все равно не увидит выгоды. Эта стоимость не обязательно может иметь финансовый характер. Если замедление ставит под угрозу систему, вызывая время простоя, вводит векторы вторжения или какой-либо другой «трудно поддающийся количественной оценке» симптом, вам может понадобиться найти способ перевести эту проблему в эквивалент денежного риска. Вектор вторжения, например, может привести к вторжению, которое может привести к потере, краже или повреждению данных. Компания может потерять репутацию или не пройти необходимый аудит безопасности. Ключ заключается в том, чтобы заставить рассматриваемого менеджера распознать количественные преимущества изменения.

Ломать вещи - это умение

Я работал во многих местах, где принимали аргумент «если он не сломан», так что им не удается вводить новшества, и когда они, наконец, вынуждены вводить новшества, они чрезмерно реагируют, изменяя все . Просто потому, что им не хватает опыта ломать вещи .

Требуется зрелость, навыки и опыт, чтобы сломать вещи.

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

Сохраняя статус-кво

Хотя это правда, текущая система соответствует текущим требованиям бизнеса. Это не относится к будущим непредвиденным изменениям этих требований. Как гласит старая пословица, «удача предпочитает приготовленное».

Этот вопрос не имеет ничего общего с SQL или производительностью. Речь идет о том, чтобы задать вопрос "есть ли лучший способ?" и не боясь попробовать альтернативу.

Ваш босс страдает от случая сохранения статус-кво .

Майя

Ничто действительно не работает идеально.

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

Предполагая, что у вас будет время, чтобы решить проблему, когда проблема возникает, это ошибка.

Что делать?

Ваш босс страдает от случая кондиционирования. Люди, которые принимают статус-кво, часто делают это, потому что им не хватает способности принимать сложные решения. Столкнувшись с проблемой, они склонны выбирать вариант, наиболее близкий к тому, с которым они знакомы.

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

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

Примите Детские Шаги

Было бы лучше предложить изменения, которые перемещают проект в нужном вам направлении, но с помощью небольших дополнительных проектов. Вместо этого задайте боссу большой вопрос о поддержке SSIS. Предложите создать разделительный слой в коде, который позволит вам подключить «альтернативные» методы для обработки таблиц с большими вложениями. Затем можно перейти к рекомендации SSIS со всеми предпосылками, уже добавленными в проект. Это снижает риск, который видит ваш начальник, принимая изменения.

Это требует времени

Мой опыт показывает, что риск-менеджеры поддерживают проект, а хранители статус-кво похожи на кирпичную стену. Упорство - ваш единственный способ разрушить их барьеры. Ожидайте, что вы продолжите слышать " Нет" на ваши запросы.

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

Я чувствую, что если бы мы переписали некоторые преобразования как пакеты служб SSIS, это могло бы значительно ускорить процесс. Однако самое большое препятствие, с которым я продолжаю сталкиваться, - это когда мой босс в стиле «Не изобретено здесь» отталкивается и говорит: «Что если Microsoft откажется от поддержки SSIS? У нас будет весь этот устаревший код, и мы облажаемся».

На мой взгляд, скептицизм по поводу SSIS действителен.

• Опытные разработчики ненавидят черные ящики, и внутри пакета служб SSIS происходит много волшебства.
• Поддержка контроля версий для пакетов служб SSIS крайне отсутствует. Расхождение и слияние файлов dtsx служб SSIS может стать кошмаром, если ваши пакеты dtsx недостаточно модульны.
  • Консольные приложения C #, напротив, очень прозрачны. Вы всегда можете следовать коду, чтобы выяснить, что происходит не так.

Кроме того, учтите, что ваш босс на крючке, если что-то пойдет не так.

• Следовательно, он имеет право иметь первостепенное / единственное мнение по этому вопросу.

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

Что мне делать в этой ситуации? Перестать продвигать новую технологию? Подождите, пока он не покинет отдел (я второй по величине человек в отделе после него, но могут пройти годы, прежде чем он уйдет / уйдет)? Найти новый способ заставить его перестать бояться сторонних инструментов?

Я рекомендую вам изучить SSIS достаточно хорошо , так что вы можете продемонстрировать свои преимущества.

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

Ответ, который вы почти всегда получаете от большинства типов менеджеров, выглядит примерно так:

«Это того не стоит, это работает сейчас, и это будет стоить времени, чтобы измениться».

И вообще, это действительно. Однако это не всегда верный аргумент, потому что основная проблема, связанная с синдромом «Не изобретено здесь», не в том, работают ли вещи или не работают, а в том, что технология бессмысленно переписывается , тратит часы компании и умаляет значительную ценность. от поставляемого товара.

Прежде чем решить, что делать, вам нужно выяснить, действительно ли имеет место «Не изобретено». Внутренняя технология, возможно, была написана по причине .

Признаки того, что технология переписана по причине:

• Технология, которую вы продаете, также является продуктом . Если вы являетесь поставщиком базы данных, то использование кода MySQL, независимо от того, сколько времени он сэкономит, является опасной идеей по многим причинам.
• Внутренние технологии хорошо поддерживаются и эффективно устраняют недостатки готового решения, в то же время обеспечивая сопоставимую базовую функциональность.
• Эта технология повышает производительность всей команды разработчиков, и новые разработчики легко продаются по причине ее использования.
• Есть и другие примеры, когда компания успешно внедрила другие внешние технологии .
• Ваш бизнес будет немедленно и серьезно затронут, если решение OTS будет прекращено или сломано.
• Бизнес настолько велик, что у него есть ресурсы для написания высококачественных инструментов по низкой цене (например, Google может написать базу данных, которая стоит меньше, чем лицензия MS SQL на 1000 долларов США / место)

Другими словами, команда понимает недостатки повторного решения уже решенных проблем, но делает разумные исключения, если это имеет смысл с точки зрения бизнеса.

Признаки «Не изобретено здесь»:

• Кажется, что все внутреннее , и есть оправдания для всего: «ну, это было слишком медленно», «это Microsoft, мы ненавидим Microsoft», «это выглядит очень сложно в использовании» и т. Д.
• В тех случаях, когда используются внешние технологии, вы слышите: «Да, ну, воняет, и мы планируем написать свою собственную ».
• Владельцы этих компонентов не имеют других рабочих мест, на которые они способны работать.
• Вы видите, что большинство новых разработчиков приходят с широко принятым набором навыков, но им требуется немало времени, чтобы освоить внутренний инструментарий
• После тщательного анализа становится очевидным, что переход от решения OTS к заказному или другому решению OTS в режиме «что, если он будет прекращен!» сценарий будет иметь минимальное влияние на бизнес . Например, если String.Join()удалить из .NET Framework, повторная реализация в пользовательский StringJoin()метод будет тривиальной.

Другими словами, NIH - это образец неспособности оставаться объективным и реалистичным в тех случаях, когда вместо собственного кода используется внешняя технология.

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

Поймите, что, учитывая ваш опыт, они могут не согласиться с вашими номерами, но, тем не менее, они должны по крайней мере выслушать вас. Это может занять время, чтобы завоевать уважение.

Если разговор даже не может быть начат, даже если вы вежливы, это может быть просто «Не изобретено здесь». В этом случае, скорее всего, это личная или политическая проблема, которую вы, вероятно, не сможете легко решить. Работа в среде, которая сильно увязла в результате постоянного переосмысления, ядовита для разработчиков и бизнеса. Запустить.

(Примечание: в большинстве компаний всегда присутствует элемент NIH, но он находится на приемлемом уровне, и при условии, что они регулярно пересматривают свой код и практику. В долгосрочной перспективе мы все до некоторой степени виноваты в этом, но это никогда не становится проблемой.)

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

Что вы получаете, переписав его в SSIS? Скорость? Это имеет значение? Если это процесс, который выполняется в графическом интерфейсе и тратит впустую все время, то да, возможно, это хорошая идея, чтобы ускорить его, потому что деньги, потраченные на его изменение, будут возвращены более счастливым клиентом или внутренним сотрудником, выполняющим свою работу вместо в ожидании программного обеспечения. Но если это ночная партия, которая начинается в 12:00 и заканчивается в 1:00 вместо 6:00 ... особого смысла нет. Да, это в 6 раз быстрее, но никто не почувствует разницу.

И у твоего босса есть хорошая точка зрения. Microsoft, как правило, отказывается от некоторых своих технологий. VB6, Linq-to-SQL, ASP classic, COM + ... Это риск для любого программного обеспечения с открытым исходным кодом (и программного обеспечения с открытым исходным кодом, которое будет слишком большим для вашей организации в случае отсутствия обновления). Если это главное в вашем приложении, вы должны иметь жесткий контроль над ним.

Программное обеспечение - это добавленная стоимость для клиента, а технические усовершенствования, которые не приносят большой пользы при введении риска, на самом деле не выполняют эту роль.

Разработайте POC (Proof of Concept) и продемонстрируйте его своему начальнику. POC должен помочь вам определить реальную выгоду от предлагаемой вами технологии. Тогда вы и ваш начальник можете поговорить о технологии и разработать плюсы и минусы для ее реализации.

Вам, вероятно, придется потратить дополнительное время вне обычного рабочего времени, чтобы разработать POC.

В качестве дополнительного примечания с точки зрения SSIS, я использовал его и разработал пакеты SSIS. Мы фактически заменили проприетарный процесс загрузки с использованием пакетов служб SSIS. Мы сделали это только потому, что реальные клиенты жаловались на время загрузки. Время загрузки значительно сократилось с SSIS, и все стали счастливее.

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

Хорошие ответы. Если это не сломано, не исправляйте это. Я бы только добавил

• Хотя проблемы производительности могут быть правдой, это слово может означать красный флаг. Сначала я бы проверил диагностику производительности, поэтому у меня было бы доказательство того, что такое проблема с производительностью, прежде чем выделять какие-либо ресурсы для ее устранения.

• Рассматривая последнее «решение» от Microsoft, следует учитывать, что множество людей были сожжены тем, что когда-то рекламировали MS, но впоследствии устарели, а затем перестали поддерживать. Если вы хотите, чтобы программное обеспечение работало в течение 10 или 20 лет без серьезной перекодировки, вы должны быть очень осторожны с этим. Наша компания так сильно пострадала.

Оборот будет рассматриваться как ваш босс. SSIS выходит на арену DBA по сравнению с программистом с таким набором навыков. Если ваше приложение не использует SSIS после первоначального преобразования, я не уверен, что имеет смысл изучить его и получить новых программистов на C #, потому что, как и ваша команда, большинство из них не имеют никакого опыта в этом.

Вы можете указать своему боссу, что SSIS, по сути, является более старым технологическим уровнем, чем .NET Framework, если вы вернетесь к его корням как «Data Transformation Framework» SQL 7.0.

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

Теперь позвольте мне быть совершенно ясно; ИМО, NIH почти никогда не подходит для дома разработчиков программного обеспечения. Это блокирует вас от множества очень мощных инструментов и сервисов. Это также лицемерно на его лице; Ваша компания написала Visual Studio? Как насчет .NET Framework? Sql Server? Окна? Нет. Вы строите свое программное обеспечение на основе инструментов и платформ, которые у вас уже есть (как и ваши клиенты). Поэтому, если вы видите инструмент, который получает всеобщее признание и который может быть полезен для ведения вашего основного бизнеса, вы принимаете его, и вы учитесь жить с риском, что вам придется поддерживать реализацию, чтобы идти в ногу с последними новостями. версии этих инструментов, или даже заменить их. Бьюсь об заклад, ваш начальник впервые разработал программное обеспечение для запуска на Windows 95/98 или около того (если не долгодо этого вроде 3.0 / 3.1). Если так, то он видел, как приходят и уходят полдюжины версий операционных систем Windows, и ему пришлось обновить свое программное обеспечение, чтобы оно работало на более новых платформах, и он столкнулся с еще одной версией XP с официально EOLed. Хотя он может жаловаться, это просто расходы на ведение бизнеса.

Однако отношение NIH не обязательно следует из отказа принять одну или даже несколько технологий, которые могут рассматриваться как полезные. Эти отказы могут быть основаны на совершенно обоснованном анализе затрат и выгод. Я работаю в компании, занимающейся видеонаблюдением и мониторингом тревоги, и мы принимаем решения поддерживать или не поддерживать различные новые технологии или продукты на ежедневной основе. Обычно решение о принятии новой технологии и о том, как ее мучить вместе с существующей кучей поддерживаемых программ для просмотра и управления тревогами, основывается, прежде всего, на том, что стоит нашим клиентам. Недавно я закончил большой интеграционный проект с новым типом видеорегистратора, просто потому, что один из наших крупнейших существующих клиентов сказал, что они переходят на этот видеорегистратор с другого известного, но технологически отстающего продукта видеорегистратора, и они будут делать это с нашей помощью или без нее. С другой стороны, мы регулярно отвергаем новых производителей, даже имена крупных домашних хозяйств, просто потому, что наши клиенты не используют его, и мы не видим смысла начинать предлагать его, даже если это лишает нас нескольких потенциальных клиентов, которые его имеют и не не хочу платить за нашу версию того же самого.

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

Это проблема, не так ли? Вы просите других людей рисковать своей продуктивностью по вашей идее, и вы не готовы выходить на конечности, чтобы показать им, что это того стоит. Техническое лидерство требует либо риска для своей репутации, либо свободного времени, чтобы показать, что ваши идеи стоят того, чтобы их иметь.

Постарайтесь увидеть вещи с точки зрения вашего босса. Похоже, что функциональность, которую вы пытаетесь заменить, является ядром того, что делает ваше программное обеспечение (см. Его «прикрученный» комментарий). Хороший менеджер знает, что вы делаете свой основной бизнес на свой страх и риск. Он справедливо беспокоится о том, чтобы поставить на ферму какую-то технологию, которая может исчезнуть в будущем. Когда задействованы основные функции, Not Invented Here на самом деле хорошая вещь.

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

Хотя есть смысл «не чинить то, что не сломано», я не согласен с принятым ответом.

Принятый ответ исходит из того, что проблема не сломана. С точки зрения менеджмента среднего звена это правда. Если бы анализ затрат был проведен на время, потраченное разработчиками на создание и поддержку решения ETL в C #, по сравнению с покупкой готового решения, это показало бы, что решение C # занимает в 3-4 раза больше времени на создание и поддерживать и стоить в 10 раз больше (я искал ссылку на цифры, но не смог ее найти).

Если это не основная сфера деятельности компании, есть очень мало причин для написания и поддержки преобразований данных в C #. Домашнее решение будет медленным, будут ошибки (то есть поврежденные данные), будут крайние случаи, будет мало повторного использования между классами ETL, и оно будет хрупким. Честно говоря, какой разработчик хочет провести свои дни за написанием и поддержкой ETL на C #? Я сделал это. Это груз дерьма. Это как можно дальше от творчества.

Используйте такой инструмент, как Informatica, компания, чей бизнес ETL. Они работают над этой проблемой более 15 лет. У них это решено. Их инструменты - перетаскивание, встроенное многократное использование, как и производительность. Большинство людей (то есть, разработчиков нет) могут создавать ETL с помощью инструментов Informatica. Я не пытаюсь продать Informatica, используйте любой инструмент. Только не изобретай колесо.

В долгосрочной перспективе покупка такого инструмента, как Informatica или использование SSIS, позволит компании сэкономить миллионы в течение длительного времени. И лучше всего вам не нужно будет поддерживать ETL или нести ответственность за него, когда он сломается.

Я пытался SSIS делать простые задачи раньше.

Это может быть очень раздражающим, так как даже простые задачи порождают диаграммы сложности от низкого до среднего уровня (нет, нет другого способа «кодировать» его, кроме диаграмм). И проблемы с контролем версий, на которые указывал ответ Джима, я не знал.

Побочная проблема: Итак, для ускорения, я предлагаю уменьшить размер транзакций для ваших изображений. Скажем, каждые 800 вместо 5000 рокордов. Это может уменьшить размер ввода-вывода, необходимый для поддержки этой транзакции.