Эрик Гфессер, главный архитектор практики данных SPR – Интервью

Эрик присоединился к практике данных группы SPR по новым технологиям в качестве главного архитектора в 2018 году.

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

Что изначально привлекло вас к машинному обучению?

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

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

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

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

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

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

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

Мой первый опыт с открытым программным обеспечением произошел, когда я строил продукт здравоохранения, о котором я упоминал ранее, используя инструменты такие как Apache Ant, используемые для построения программного обеспечения, и ранний продукт DevOps под названием Hudson (кодовая база которого позже стала Jenkins). Основной причиной наших решений использовать эти открытые продукты было то, что они либо предоставляли лучшие решения, чем коммерческие альтернативы, либо были инновационными решениями, не предлагаемыми коммерческими сущностями, не говоря уже о том, что коммерческая лицензия некоторых продуктов, которые мы использовали, была чрезмерно ограничительной, что приводило к избыточной бумажной работе, когда дело доходило до необходимости дополнительных лицензий из-за связанных с этим затрат.

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

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

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

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

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

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

Ранее в своей карьере я понял, что архитектурное качество, называемое “пользовательским опытом”, не ограничивается только конечными пользователями, но и самими разработчиками программного обеспечения. Причина этого заключается в том, что код, который пишется, должен быть таким же доступным, как и пользовательские интерфейсы, которые должны быть доступны конечным пользователям. Чтобы продукт стал доступным, необходимо построить доказательства концепции, чтобы продемонстрировать, что разработчики смогут сделать то, чего они хотят, особенно когда речь идет о конкретных технологических выборах, которые они делают. Но доказательства концепции – это только начало, поскольку продукты лучше всего развиваются со временем. На мой взгляд, основа для минимально жизнеспособного продукта должна идеально строиться на прототипах, демонстрирующих некоторую стабильность, чтобы разработчики могли продолжать развивать его.

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

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

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

Кроме того, документация для таких компонентов в основном не доступна публично, что заставляет разработчиков постоянно полагаться на эти фирмы. Когда широко принятые открытые компоненты, такие как Apache Spark, являются центральным фокусом, как в продуктах, таких как Databricks Unified Analytics Platform, многие из этих элементов уже доступны в сообществе, минимизируя части, на которые команды разработчиков должны полагаться на коммерческие сущности для выполнения своей работы.

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

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

Еще одно, в чем вы верите, – это то, что открытое программное обеспечение приводит к “доступу к сильным сообществам разработчиков”. Насколько велики некоторые из этих сообществ и что делает их так эффективными?

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

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

Вы прочитали 100 книг на вашем сайте, можете ли вы порекомендовать три из них нашим читателям?

В последнее время я читаю очень мало книг по программированию, и хотя есть исключения, реальность такова, что они обычно становятся устаревшими очень быстро, и сообщество разработчиков обычно предоставляет лучшие альтернативы через форумы обсуждений и документацию. Многие книг, которые я сейчас читаю, доступны мне бесплатно, либо через технологические новостные рассылки, на которые я подписан, либо через авторов и издателей, которые обращаются ко мне, либо через те, которые Amazon (AMZN ) отправляет мне. Например, Amazon отправил мне предварительный просмотр книги “The Lean Startup” для моего обзора в 2011 году, знакомя меня с концепцией минимально жизнеспособного продукта, и недавно отправил мне копию “Julia for Beginners”.

(1) Одна из книг от O’Reilly, которую я порекомендовал, – “В поисках базы данных Нирваны”. Автор подробно описывает проблемы, с которыми сталкивается движок базы данных для поддержки рабочих нагрузок, охватывающих весь спектр от OLTP с одной стороны до аналитики с другой стороны, с операционными и деловыми интеллектуальными рабочими нагрузками посередине. Эта книга может быть использована в качестве руководства для оценки движка базы данных или комбинации запроса и хранилища, ориентированного на удовлетворение требований рабочей нагрузки, будь то транзакционные, аналитические или смесь этих двух. Кроме того, авторское описание “качания базы данных” в последние годы особенно хорошо сделано.

(2) Хотя многое изменилось в области данных за последние несколько лет, поскольку продолжают появляться новые продукты аналитики, “Disruptive Analytics” представляет собой доступную, краткую историю последних 50 лет инноваций в аналитике, которую я не видел в другом месте, и обсуждает два типа нарушений: инновации в цепочке создания ценности аналитики и отраслевые нарушения инновациями в аналитике. С точки зрения стартапов и практиков аналитики успех обусловлен нарушением их отраслей, поскольку использование аналитики для дифференциации продукта является способом создания нарушительного бизнес-модели или создания новых рынков. С точки зрения инвестиций в технологии аналитики для своих организаций, подход “жди и увиди” может иметь смысл, поскольку технологии, подверженные нарушению, являются рискованными инвестициями из-за сокращенных сроков полезного использования.

(3) Одна из лучших технологических бизнес-книг, которые я прочитал, – “Ограничения стратегии”, написанная сооснователем Research Board (приобретенной Gartner), международной исследовательской группой, которая изучает разработки в мире вычислений и то, как корпорации должны адаптироваться. Автор представляет очень подробные заметки из многих своих разговоров с бизнес-лидерами, предоставляя проницательный анализ на протяжении всей книги о его опыте построения (вместе с женой) группы клиентов, крупных фирм, которым нужно согласовать свои стратегии с взрывным миром вычислений. Как я прокомментировал в своем обзоре, то, что отличает эту книгу от других связанных усилий, – это два, казалось бы, противоположных характеристик: отраслевая широта и интимность, доступная только через лицо к лицу взаимодействие.

Вы являетесь главным архитектором практики данных SPR. Можете ли вы описать, что делает SPR?

SPR – это цифровая технологическая консалтинговая компания, базирующаяся в районе Чикаго, которая доставляет технологические проекты для широкого спектра клиентов, от предприятий Fortune 1000 до местных стартапов. Мы строим цифровые trải nghiệm с использованием широкого спектра технологических возможностей, от настройки программного обеспечения до пользовательского опыта, данных и облачной инфраструктуры, а также DevOps-коучинг, тестирование программного обеспечения и управление проектами.

Что из ваших обязанностей в SPR?

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

На протяжении большей части своей карьеры я специализировался на открытом программном обеспечении с использованием Java, выполняя все больше работы с данными на пути. Кроме этих двух специализаций, я также занимаюсь “практической” или “прагматической” корпоративной архитектурой, которая означает выполнение архитектурных задач в контексте того, что будет построено, и фактическое строительство, а не просто разговор о нем или рисование диаграмм о нем, понимая, конечно, что эти другие задачи также важны.

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

Что интересного проекта вы сейчас работаете над с SPR?

Только что я опубликовал первую статью в многочастной серии деловых исследований о платформе данных, которую моя команда и я реализовали в AWS с нуля в прошлом году для ЦIO чикагской глобальной консалтинговой фирмы. Эта платформа состоит из конвейеров данных, озера данных, канонических моделей данных, визуализаций и моделей машинного обучения, которые будут использоваться корпоративными отделами, практиками и конечными клиентами клиента. Хотя основная платформа должна была быть построена корпоративной ИТ-организацией, возглавляемой ЦIO, целью было то, что эта платформа будет использоваться другими организациями вне корпоративной ИТ для централизации активов данных и анализа данных по всей компании с использованием общей архитектуры, строя на ней, чтобы удовлетворить потребности каждого случая использования.

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

Есть ли что-то еще, что вы хотели бы поделиться об открытом программном обеспечении, SPR или другим проектом, над которым вы работаете?

Другой проект (читайте о нем здесь и здесь), который я недавно возглавил, включал успешную реализацию Databricks Unified Analytics Platform и миграцию выполнения моделей машинного обучения на него с Azure HDInsight, Hadoop-распределения, для директора инженерии данных крупного страховщика.

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

Чтобы решить эти ключевые вызовы, в качестве следующего шага после нашей реализации я сделал рекомендации по автоматизации, конфигурации и версионированию, разделению проблем с данными, документации и необходимому выравниванию между их командами данных, платформы и моделирования. Наша работа убедила изначально очень скептического главного ученого, что Databricks – это правильный путь, с заявленной целью после нашего ухода мигрировать их оставшиеся модели в Databricks как можно скорее.

Это было fascинiruyuschее интервью, затронувшее многие темы, я чувствую, что я многое узнал об открытом программном обеспечении. Читатели, которые могут захотеть узнать больше, могут посетить корпоративный веб-сайт SPR или веб-сайт Эрика Гфессера.