Мы живем в эпоху огромных технологических перемен. Нашу жизнь буквально за несколько лет изменили интернет, беспроводные технологии, мобильные устройства, облачные вычисления. Это меняет то, как компании выстраивают архитектуру IT-систем, поддерживающих их бизнес. Это меняет роль IT-руководителя в компании и новую степень проникновения технологий в каждый аспект деятельности компании.
Это принципиально меняет ландшафт всей IT-индустрии. Это требует изменений на стороне IT-поставщиков, системных интеграторов. Как технологический прогресс влиял на IT-потребности бизнеса и бизнес-модели?
Если проанализировать развитие корпоративных IT в течение десятилетий, то можно увидеть, как происходила эволюция запросов бизнеса к IT, как менялись предъявляемые к ним требования и как решения давали возможность решать все новые и новые задачи.
И главный двигатель этого развития — все более тесная интеграция различных бизнес-процессов и различных систем с помощью все более совершенных технологий.
Как это происходило?
Системы автоматизации стали широко использоваться в бизнесе в 80-е годы.
На этом этапе речь еще не шла об интеграции систем — отдельно друг от друга, в основном на самописных системах, автоматизировались отдельные не связанные между собой бизнес-операции, такие как расчет зарплаты, составление балансов, расчет производственных показателей и т.д. Это было время отдельных, не связанных между собой приложений.
В 90-е годы на управление предприятием стали смотреть более интегрировано.
Руководители компаний поняли, что нужно видеть не только качество отдельных бизнес-операций, но зависимости между ними. В моду вошел термин «бизнес-процесс», и выражения «оптимизация бизнес-процессов», «выявление «узких мест» и другие.
IT ответили на это попыткой интеграции отдельных приложений между собой, чтобы охватить автоматизацией целый бизнес-процесс.
Стандартных интерфейсов и протоколов обмена информацией тогда еще не существовало. Поэтому в основном эта интеграция заключалась в написании специальных программ-коннекторов. С углублением интеграции количество этих самописных коннекторов росло, сложность систем и стоимость поддержки также возрастали.
Как альтернатива возрастающей сложности интеграции был предложен подход с внедрением единых интегрированных систем (приложений) — таких, как SAP R/3. Этот период, безусловно, время взлета SAP и концепции ERP. Компании, столкнувшись с возрастающей сложностью интеграции разрозненных решений, в отсутствии каких-то единых стандартов, были готовы платить SAP. Главным достоинством таких решений была внутренняя интегрированность.
Все изменилось в 2000-е. Стали появляться универсальные протоколы обмена данными и интеграционные сервера, такие как IBM WebSphere или Microsoft BizTalk. Вычислительные мощности, доступные компаниям, стали позволять интегрировать между собой практически любые приложения. Возник новый тренд — интеграция приложений.
Тогда же появились первые механизмы для интеграции данных.
Во-первых, появились технологии подключения к источникам, выгрузки, нормализации данных — ETL и системы интеграции реестров, технологии MDM. Во-вторых, появились технологии аналитической обработки данных, OLAP, которые позволяли собирать информацию из различных баз данных и быстро обрабатывать ее.
Для удобства эти данные стали хранить в единой системе. Возник такой инструмент как корпоративное хранилище данных. Различные аналитические приложения могли брать данные из него и сохранять в нем же результаты анализа. Прежде всего, таким образом решалась достаточно узкая задача подготовки аналитической отчетности.
Но постепенно эти системы стали брать на себя все больше функций. Постепенно отмерли интеграционные шины — задачи интеграции стали решаться непосредственно на уровне КХД.
Слой аналитических приложений также значительно расширился — это была и типовая аналитическая отчетность, и прогнозный анализ, и другие аналитические сервисы.
С ростом объемов и разновидностей данных все больше задач ложилось и на слой технологической интеграции данных — ETL, MDM. Сегодня это еще и интеграция неструктурированных данных — голос, видео, телеметрия, данные социальных сетей и т.д.
Таким образом, в результате этой эволюции огромное корпоративное хранилище данных — мы называем его экзахранилищем — становится центральным компонентом корпоративной IT-архитектуры.
Прикладные бизнес-приложения остаются, но они строятся поверх данных экзахранилища и являются фактически пользователями сервисов экзахранилища.
Картинка, если изобразить на ней схематично структуру корпоративных IT, становится трехмерной. Есть слой IT-инфраструктуры, «железа». Слой экзахранилища — универсальной виртуализированной среды хранения и обработки интегрированной корпоративной информации, в которой решаются универсальные IT-задачи. Это совместно используемый ресурс для всех IT-приложений, используемых в организации.
И над этим хранилищем построены приложения, решающие специфические бизнес-задачи, и погруженные в эту среду данных, пользующиеся ее вычислительными ресурсами, универсальными сервисами и сохраненной там информацией.
Можно называть такой подход построения IT «датацентричной корпоративной IT-архитектурой».
На самом деле это не просто новая IT-архитектура, это отражение новой парадигмы ведения бизнеса — интеграция между собой внутренних и внешних информационных потоков, управление в реальном бизнесе, предиктивные решения в интересах бизнеса.
Не нужно забывать, что на это наложилось новое явление, которое мы называем «большие данные» — новая IT-архитектура должна позволять хранить и обрабатывать эти сверхбольшие объемы, работать с неструктурированными данными.
Это предъявляет новые требования к качеству всей IT-инфраструктуры.
С появлением IT-архитектуры, в центре которой находятся потоки бизнес-данных, возникла новая бизнес-задача, которой раньше в принципе не существовало. Это обеспечение организационного процесса управления корпоративными данными (Data Governance).
Решение этой задачи подразумевает создание специальной организационной единицы, которая занимается управлением данными как активом организации. Это большой сложный вопрос: каким образом методологически управлять жизненным циклом данных, каким образом поддерживать корпоративную модель данных. Без такой модели, без понимания, какие данные есть в организации, как ими управлять и как они могут быть использованы бизнесом, данные не представляют никакой ценности.
В большинстве компаний этот вопрос пока никак не решается, хотя в западных компаниях есть примеры отношения к данным как к важнейшему корпоративному активу.
Пора чуть ближе взглянуть на функциональную архитектуру экзахранилища. Потому что внешне выглядящая довольно просто, эта структура внутри очень сложна. Решение множества из задач, возложенных на каждый слой, базируется, как правило, на различных специализированных системах, которые должны быть сквозным образом интегрированы между собой.
При этом вся архитектура существует не сама по себе, а в пространстве других, новых измерений, таких как мобильность, облака, внешние программные сервисы, гибридные решения и т.д.
Если внимательнее всмотреться на «строительные блоки», из которых выстраивается экзахранилище в крупной организации, то мы увидим, что это десятки и сотни различных продуктов и решений.
Мы живем в эпоху крайне фрагментированного продуктового ландшафта — уже далеко в прошлом те времена, когда корпорации опирались только на два-три больших бренда. Раньше, если говорили про обработку данных, брали Microsoft, Oracle, иногда db2. Сегодня количество продуктов, которые специализируются на интеграции данных, измеряется сотнями — достаточно взглянуть на аналитические отчеты по рынку Gartner или IDC.
Эти платформы и продукты не так легко складываются вместе в единую картину. Решения зачастую сочетают в себе свойства и функции из различных функциональных слоев.
Кроме того, интеграция продуктов и платформ происходит не «в чистом поле», а в определенном сложившемся унаследованном корпоративном ландшафте, от которого нельзя одномоментно отказаться. Переход к новой экза-архитектуре должен происходить без прерывания обслуживания текущей IT-структуры. Это эволюционный процесс.
В результате получается довольно сложная задача на пересечении различных экспертиз.
Нужно уложить все эти нестандартные куски-компоненты в достаточно правильную картинку, грамотно подобрать продукты, интегрировать все между собой, сделать так, чтобы все задачи бизнеса были закрыты тем или иным продуктом.
Нужно продумать, каким образом эволюционно происходит постепенный переход к новой архитектуре и как она вписывается в существующий унаследованный ландшафт.
Всё это профессиональная зона применения знаний для специалистов в области интеграции систем и данных. Такие услуги будут востребованы в ближайшем будущем.
Для таких проектов внутри компаний должен вырасти внутренний заказчик.
Для решения новой бизнес-задачи постепенно возникает новый корпоративный лидер — CDO, Сhief Data Officer. Задача CDO, как уже говорилось, — построить модель данных, организовать ее поддержку и обеспечить взаимодействие всех руководителей C-level по вопросам корпоративных данных.
Задача CIO и CDO не в том, чтобы построить универсальную архитектуру, которая могла бы уже сегодня решить все задачи функциональных заказчиков на ближайшие 10 лет. Предсказать ничего не возможно. Главные характеристики дата-архитектуры будущего — это гибкость и адаптивность.
Поэтому задача IT-руководителя — создать такую IT-архитектуру компании, которая бы позволила очень быстро и с понятным эффектом развертывать новые сервисы поверх единого корпоративного экзахранилища. Он должен иметь возможность максимально быстро реагировать на возникновение новых потребностей у бизнес-заказчика. Вызов CIO — построить инфраструктуру высокой готовности, высокой гибкости, с учетом всех новых платформ и необходимости адаптации к будущим изменениям.
Вызов CDO — найти способ сделать цифровые данные организации активом, приносящим доход. Это сложная задача, это удается пока далеко не всем.
Но те, кому удастся это сделать — преуспеют, а кто нет — те, безусловно, потеряют.
Сокращенный текст выступления опубликован в газете «Ведомости»