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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каковы некоторые из ваших обязанностей в SPR?

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

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

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

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

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

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

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

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

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

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

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