Ерік Гфессер, головний архітектор практики даних компанії SPR – Інтерв’ю серія

Ерік приєднався до практики даних групи компанії SPR, що займається новими технологіями, на посаду головного архітектора у 2018 році.

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

Що спочатку привернуло вашу увагу до машинного навчання?

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

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

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

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

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

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

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

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

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

Ви використовували відкритий джерельний код для будівництва прототипів, моделей та мінімально життєздатних продуктів. Чи можете ви розповісти про свій досвід з деякими цими продуктами?

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

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

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

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

Раніше в моєй кар’єрі я зрозумів, що архітектурна якість, яка називається “зручністю використання”, не обмежується лише кінцевими користувачами, а також розробниками програмного забезпечення. Причина цього полягає в тому, що код, який пишеться, повинен бути таким же зручним для використання, як і інтерфейси користувача, які повинні бути зручними для кінцевих користувачів. Щоб продукт став зручним для використання, потрібно будувати прототипи, які демонструють, що розробники будуть能够 робити те, що вони планують зробити, особливо коли це пов’язано з конкретними технологічними виборами, які вони роблять. Але прототипи – це лише початок, оскільки продукти найкраще еволюціонують з часом. На мою думку, основа для мінімально життєздатного продукту повинна бути побудована на прототипах, які демонструють певну стабільність, щоб розробники могли продовжувати еволюціонувати його.

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

Багато комерційних продуктів даних використовують ключові відкриті джерельні коди під капотом та дозволяють розробникам використовувати популярні мови програмування, такі як Python. Фірми, які будують ці продукти, знають, що відкриті джерельні коди, які вони обрали для включення, дають їм стартовий avantaj, оскільки ці коди вже широко використовуються спільнотою.

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

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

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

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

Ще щось, у що ви вірите щодо відкритого джерельного коду, полягає в тому, що це веде до “доступу до сильних спільнот розробників”. Наскільки великими можуть бути деякі з цих спільнот і що робить їх так ефективними?

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

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

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

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

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

(2) Хоча багато чого змінилося в сфері даних за останні кілька років, оскільки продовжуються появлятися нові продукти аналітики даних, “Дисруптивна аналітика” представляє доступний, короткий історичний огляд останніх 50 років інновацій в аналітиці, якого я не бачив деінде, і обговорює два типи дисрупції: дисрупцію інновацій всередині ланцюга цінності аналітики та галузеву дисрупцію інноваціями в аналітиці. З точки зору стартапів та практиків аналітики успіх забезпечується дисрупцією їхніх галузей, оскільки використання аналітики для диференціації продукту є способом створення дисруптивної бізнес-моделі або створення нових ринків. З точки зору інвестування в технологію аналітики для своїх організацій, підхід “чекай і дивись” може мати сенс, оскільки технології, які піддаються дисрупції, є ризикованими інвестиціями через скорочені терміни корисності.

(3) Одна з найкращих бізнес-книг з технологій, яку я прочитав, – “Ліміт стратегії”, написана співзасновником Research Board (придбаної Gartner), міжнародного дослідницького центру, який досліджує розвиток у сфері обчислень та того, як корпорації повинні адаптуватися. Автор представляє дуже детальні нотатки з багатьох своїх розмов з бізнес-лідерами, надаючи проникливу аналітику на протяженні всього тексту про свої досвіди будівництва (разом з дружиною) групи клієнтів, великих фірм, які потребували поєднання своїх стратегій з快速но розширюваним світом обчислень. Як я прокоментував у своїй рецензії, те, що відрізняє цю книгу від інших подібних зусиль, – це дві, здавалося б, протилежні характеристики: галузева широта та інтимність, яка доступна лише через особисту взаємодію.

Ви є головним архітектором практики даних компанії SPR. Чи можете ви описати, що робить SPR?

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

Які деякі з ваших обов’язків у SPR?

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

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

Який цікавий проєкт ви зараз працюєте над ним з SPR?

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

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

Чи є щось інше, про що ви хотіли б розповісти щодо відкритого джерельного коду, SPR або іншого проєкту, над яким ви працюєте?

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

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

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

Це було цікаве інтерв’ю, яке торкнулося багатьох предметів, я відчуваю, що я багато чого навчився про відкритий джерельний код. Читачі, які бажають дізнатися більше, можуть відвідати корпоративний веб-сайт компанії SPR або веб-сайт Еріка Гфессера.