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

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

Во-первых, началась глубокая специализация внутри ИТ. Универсальные специалисты, которые могли и код написать, и данные достать, и сервер администрировать, стали редкостью. Их место заняли узкопрофильные специалисты — «фронтендеры», «бэкендеры», «администраторы Oracle». Каждый отвечал лишь за свой участок — целостное представление о информационной системе стало распадаться.

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

В-третьих, значительно усложнились требования информационной безопасности. Сегодня доступ в «боевую» систему строго ограничен и жестко регламентирован.

Все это привело к тому, что бизнес перестал получать ответ на свой простой вопрос, хотя объем собираемых данных вырос на порядки. Причем бизнес не понимает, почему раньше (годами!) можно было быстро получить отчет «здесь и сейчас», а теперь нужно ждать неделями — ведь в его представлении ничего не изменилось, данные по-прежнему где-то «лежат», значит, кто-то должен уметь их «достать». Однако механизмов доступа либо больше нет, либо они настолько усложнились, что теряют оперативность.

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

Ключевая проблема сегодня — это парадокс избытка данных и недостатка понимания. Бизнес обращается к ИТ с простым запросом, например, «построить в BI-системе воронку продаж». Однако дальше начинается ступор. ИТ-специалисты отвечают: «Это же ваши данные, а не наши. Где именно они хранятся? Как их интерпретировать? Что значит вот эта колонка в таблице? Почему данные разбросаны по разным системам и базам?» Возникает системный конфликт — не из-за злонамеренности сторон, а из-за потери единого контекста.

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

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

А потом еще появилось поветрие «Давайте просто сделаем нормальное, понятное для бизнеса хранилище данных». Появилась вера в упорядочивание: «Если все аккуратно переложить в хранилище данных, то все наладится. Сделаем такое хранилище, опишем слои, дадим бизнесу витрины, стандартизируем метаданные, и все снова станет просто».

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

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

Мало того, к старым проблемам добавились новые. Раньше существовала одна база данных, она одновременно была и оперативной, и аналитической. Все данные поступали туда напрямую, и там же можно было запрашивать нужные показатели, фактически это был единый центр правды. Конечно, не все было идеально, но все находилось в одной точке. С внедрением хранилища произошел сдвиг — архитекторы «по фэншую» разделили данные по уровням. Появились «сырые» данные, которым доверять еще нельзя — мало ли, оператор ошибся или ввел параметр с опечаткой. Дальше — слой очищенных данных. Это уже вторая копия тех же данных. И, наконец, витрины — третий слой. Все это стало плодиться. Из 100 Мбайт исходных данных можно наделать терабайты витрин, однако найти нужную — это уже отдельный квест, пройти который почти невозможно даже с хорошей системой тегов. Более того, теперь внутренними регламентами зачастую запрещено формировать отчеты по «сырым» данным, потому что им официально нельзя доверять. Но и с витринами беда — их становится слишком много. И если бизнесу нужен ответ на простой вопрос «Какая у нас средневзвешенная ставка по кредитным договорам?», то задача превращается в головоломку: найдите среди тысячи витрин ту, где она уже рассчитана, причем именно способом, который имел в виду бизнес. А если такой витрины нет — создайте 1001! Но создать новую витрину это вопрос не часа или даже дня, а иногда путь длиною в неделю и более, причем не помогут и инструменты self-service. И запрос повисает в воздухе.

И в этот момент, когда конфликты между бизнесом и ИТ стали системными, когда компании потратили миллиарды на хранилища, процессы и регламенты, а ответа на ключевые вопросы так и не получили, появилась фигура директора по данным (Chief Data Officer, CDO).

CDO — временная заплатка или новая надежда?

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

Возникает абсурдная ситуация — продолжает существовать CIO, но появляется CDO с похожим названием, но другим функционалом. То есть данные уже не входят в зону ответственности CIO?

Функция CDO изначально несла в себе искусственность. Вся концепция централизованного управления данными возникла не по внутренней логике развития бизнеса, а как вынужденный ответ на системные сбои во взаимодействии между бизнесом и ИТ. Поэтому, когда мы смотрим на эту роль в исторической перспективе, то видно, что CDO скорее переходная мера, промежуточный этап. Да, она может немного смягчить боль, взять на себя часть проблем. Но системно ничего не меняет — это не путь к выходу из кризиса, а временная заплатка.

Хотим мы этого или нет, но все равно должен вернуться тот самый айтишник, который знает, где хранится пресловутая процентная ставка, и у которого есть конкретное понимание, что лежит в таблицах и почему. Если в организации не осталось ни одного человека, который может ответить на эти базовые вопросы, то ни CDO, ни какая-либо витрина, ни система Data Governance не смогут навести порядок. Более того, системы управления данными сами по себе создают дополнительный уровень сложности — их тоже нужно настраивать, администрировать и поддерживать. Это еще одна надстройка над и без того раздутой архитектурой.

Методологии против хаоса: agile, Data Governance, колдовство

Объективно мы столкнулись с увеличением объемов данных. Это была первая проблема. Сначала мы перешли от простых DBF-файлов 1990-х годов к более сложным базам данных, что дало передышку — системы стали работать быстрее, а возросший объем данных можно было обрабатывать за счет более мощного железа. Это была золотая эра СУБД Oracle — в каждом банке было несколько лицензированных СУБД и регулярно обновляемое оборудование. Все ехало за счет технологии. Были те же таблицы, такие же «селекты», просто на «стероидах». По сути, это как если бы мы раньше копали яму лопатой, а потом взяли экскаватор.

Проблема началась позже, когда объемы перестали влезать уже и в Oracle. Все, что раньше решалось этим «экскаватором» — мощностью СУБД, железа и памяти, — больше не справляется. Возникает не просто вопрос объема данных, а вопрос структуры. Появляется сложность, а если с ней не работать, то появляется хаос.

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

Технология не работает. Почему? Потому что хаос начал проявляться как новое качество, по принципу «количество переходит в качество», только качество получилось с негативным оттенком. Причем речь даже не о классическом «хаосе», а скорее о той самой сложности, с которой ИТ-департамент просто не умеет работать. Это не баг, это фундаментальное ограничение.

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

Сегодня уже невозможно вернуться в мир с одним главным архитектором, который видит всю картину целиком и может по памяти сказать, где найти нужные данные. Этот этап объективно пройден. Конечно, попытки решить эту проблему были. Выходили статьи, поднимались флаги, собирались конференции, на этой волне возникали стартапы в поисках технологических либо методологических прорывов. Возник обширный рынок «объяснителей»: тренеров, коучей, инфоцыган, которые приходили и говорили: «Ваша проблема — в неправильном мышлении. Перестаньте использовать нормализацию и строгие типы в СУБД, переходите на гибкие и масштабируемые технологии NoSQL. И тогда все наладится».

Все это — попытки преодолеть ту самую сложность через ментальную революцию. Вспомним Манифест гибкой разработки (Agile Manifesto) — сотни форумов, тысячи подписчиков, а затем обучения, аудит соответствия стандартам, agile-евангелисты в каждой компании. Мощное движение. И все ради того, чтобы как-то справиться со сложностью.

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

А вот тут мир ИТ снова оказывается перед выбором — бороться со сложностью либо методологией, либо технологией. Ну или, в отчаянии, чем-то третьим — шаманством, колдовством, верой в каких-то гуру. Но в основе все те же два лагеря: один говорит — надо просто по-умному организовать процесс (и предлагает методологию), другой — давайте просто напишем новую технологию, чтобы все само заработало. Кто победит, неважно, пока есть надежда, что кто-то вообще победит.

Методологии появляются одна за другой. Классический пример — Agile, все как будто согласились, что это ответ на вызовы. И понеслось. Agile начали внедрять везде: в банках, газетах, заводах и пр. Не важно, что процессы разные, главное — соответствовать духу времени. Сожгли бюджеты, обучились, внедрили. Что в итоге? Ничего не сломалось — уже хорошо. А польза? Какая-то польза есть. Но появились и новые проблемы. А затем идем дальше — новая методология, новая надежда.

От деления истинная сложность не исчезает

Что касается баз данных, то реляционные СУБД доказали свою зрелость и жизнеспособность. В свое время СУБД Oracle вытеснили старые DBF, которые остались в эпохе Windows 3.11 и MS-DOS. Это был технологический прорыв, ответ на рост объемов данных. Но со временем и эти СУБД вместе с решениями на ее основе перестали справляться не столько с объемами, сколько со сложностью. Данные стали слишком разнородными и уже не помещались в классическую реляционную модель. Раньше банк мог жить на одной базе с 50 таблицами и это все помещалось в голове одного архитектора, а сейчас в базе — 500 таблиц, а дальше будет тысяча. Архитектор уже не справляется в одиночку. Появляется трое, четверо, пятеро, каждый отвечает за свою часть, все завязано на согласованиях. Любая архитектурная правка превращается в баталию. И все вязнет, причем не из-за объема — миллиарды строк обрабатывались и раньше, а из-за сложности структуры. Один архитектор не способен охватить ее целиком, а без этого — нет целостности.

И вот в какой-то момент бизнес смотрит на это все и говорит: «Ребята, ну а почему вы не можете просто пойти и создать еще одну таблицу, как раньше? Что изменилось-то?»

Поветрие NoSQL в каком-то смысле появилось как протест против архитекторов, против реляционных баз, против всех этих «приседаний», которые нужны, чтобы просто сохранить данные: «Давайте просто складывать все как есть, а потом разберемся». Параллельно возник еще один вызов — даже СУБД Oracle стала буксовать на больших объемах. Конечно, потом разработчики подтянулись, адаптировали технологию, но позже, чем было надо.

А NoSQL в итоге так и не взлетел, как ожидалось, а стал нишевым решением — в реальных «боевых» системах так и остались реляционные базы: Oracle, SAP, PostgreSQL и другие, которые продолжают развиваться. Новый NoSQL не смог заменить старый добрый SQL, хотя экстремальный хайп именно это обещал.

А почему нельзя было бы уйти в специализацию? Как, например, в машиностроении. Приезжаешь на швейцарский завод, спрашиваешь: «Где у вас главный конструктор?» «А у нас одного нет — есть по электрике, по гидравлике, по механике, по динамике, и каждый отвечает за свое». Почему бы не сделать так же? Пусть каждый архитектор отвечает за свою часть. Не 500 таблиц на одного, а 80 — на конкретный участок.

Собственно, так и делается — классическое решение проблемы сложности в разделении на части, маленькие, понятные и управляемые. И потом кто-то все это собирает. Но тут есть нюанс — истинная сложность от деления не исчезает. В физическом мире можно собрать станок из готовых узлов: болты, микросхемы, масло и прочие — все по стандарту. Сложно, но возможно. А в ИТ сложность другая. И даже если каждый кусок работает идеально, все вместе может не работать вовсе. Просто не склеивается. Проблема в том, что, когда все это начинают собирать, сложность возвращается. Опять нужен кто-то, кто может удержать в голове всю картину, целиком. Даже если архитектор будет работать не с 500 таблицами, а с 10 «снежинками», это все равно уже будет на новом уровне абстракции.

Современный архитектор, по-хорошему, должен уметь клеить не «снежинки», а десятки хранилищ данных: стриминговая Kafka, пара конфигураций СУБД Oracle, SAP. И все это надо собрать в одну систему. Однако ИТ-отрасль пока с этим справляется плохо. Именно на этом уровне сложности и появляются реальные пробуксовки — из-за разной скорости потоков, разной степени готовности данных и разной логики.

Но это уже не просто интеграция — это архитектура новой природы.

Роль новой формации

И тут появляется роль вроде CDO, потому что кто-то должен отвечать за архитектуру новой природы. И считается, что этот человек владеет какой-то методологией или подходами, вроде Data Governance, Big Data, теоремы CAP и инструментарием — Data Governance и Data Management.

Как правило, начинают с ПО — не получается. Идут к методологам, а те говорят: «Вы неправильно приседаете. Мы научим как надо». То есть внедряют правила, процедуры, регламенты. А если опять не получается — значит, вы не следуете правилам, вот и вся проблема.

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

Не означает ли это, что мы уже в другой точке? Все эти усложнения, появление специального слоя типа Data Governance — отлично, но в реальности до рабочей модели их так никто и не довел. Это скорее теория, давайте создадим промежуточный уровень, который поможет управлять. Но Data Governance не дал новый уровень абстракции, а просто помогает не забыть архитектору, что значат эти 500 таблиц. Удобнее, но не проще.

Сейчас быстрые пожирают больших. NoSQL, новые СУБД типа ClickHouse, другие прорывные технологии — каждая дала локальный выигрыш. Те, кто успели внедрить, те, кто были достаточно гибкими, получили профит. Например, один банк все еще в конце месяца пытается понять, сработала ли его рекламная кампания по кэшбэку, а другой уже на второй день ее отключает, потому что видит убытки. Но все это решалось не с помощью Data Governance. Это решалось в стиле 1990 -х — бизнес пришел, сказал «надо». ИТ-департамент ответил, что так на Oracle не сделаешь. Тогда CDO взял и внедрил условный 'ClickHouse'. Потому что понимал — нельзя ждать конца месяца, чтобы узнать, что миллиард улетел в трубу.

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

Ответа нет, но есть надежда и временное решение

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

И вот на этом фоне появляется новое направление, пока мутное и сырое, — искусственный интеллект. Агентские ИИ-системы, которые встраиваются в хаос данных. Идея в том, что ни архитекторы, ни дата-инженеры в СУБД больше не ходят. Туда запускают ИИ, который сам разбирается с этой сложностью и наводит там порядок, работая с этим хаосом лучше человека. Люди просто сдались перед сложностью, а теперь уповают на ИИ.

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

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

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

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

С данными этого пока не произошло. Но непременно должно произойти.

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

Искусственные нейронные сети, большие языковые модели — это первая попытка построить новый уровень абстракции, позволяющий общаться с данными на естественном языке. И, возможно, появится и надстройка над SQL, язык, который будет оперировать не таблицами, а чем-то более крупным: схемами, модулями, объектами. Точно так же, как транзисторы были «запакованы» в более крупные логические элементы, таблицы однажды могут быть запакованы в более высокоуровневые структуры. И, наверное, тогда мы потеряем возможность «достать конкретную строчку», но зато научимся оперировать огромными объемами данных с новой легкостью и получим наконец ответ на вопрос о средневзвешенной процентной ставке по кредитным договорам.

Почему этого еще не произошло? Возможно, просто пока еще недостаточно больно. Или боль гасится упомянутым «аспирином» — процедурами, регламентами и прочими методологическими анальгетиками. Но технологического скачка пока нет.

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

***

Существующих подходов при работе с данными уже не хватает. Да, сообщество предлагает новые решения, но они не устраняют саму проблему — сложность и разрозненность данных. Никто не знает, как правильно. Но есть шанс заложить фундамент совершенно нового подхода к работе с данными.

Александр Тютюнник (atutunnik@ luxms.ru) — директор по развитию бизнеса, Дмитрий Дорофеев (ddorofeev@luxms.ru) — главный конструктор, компания Luxms BI (Санкт-Петербург).