Erik Gfesser, Головний Архітектор практики даних SPR – Серія інтерв’ю

Ерік приєднався до практики даних Групи нової технології SPR у якості Головного Архітектора у 2018 році.

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

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

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

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

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

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

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

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

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

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

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

Ви використали відкрите джерело для будівництва PoC, прототипів та 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) Хоча багато чого змінилося в сфері даних за останні кілька років, оскільки продовжують з’являтися нові продукти аналітики даних, “Дисруптивна аналітика” представляє підхідний, короткий історичний огляд останніх 50 років інновацій в аналітиці, якого я не бачив ніде інде, та обговорює два типи порушення: інновації всередині ланцюга вартості аналітики та порушення галузей інноваціями в аналітиці. З точки зору стартапів та практиків аналітики успіх забезпечується порушенням їх галузей, оскільки використання аналітики для диференціації продукту є способом створення дисруптивного бізнес-моделі або створення нових ринків. З точки зору інвестування в технологію аналітики для своїх організацій, підхід “чекай і дивись” може мати сенс, оскільки технології, які ризикують бути порушеними, є ризикованими інвестиціями через скорочені терміни корисного використання.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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