Корпоративная архитектура:
соединяем технологии и бизнес

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

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

Архитектура — это фундаментальный способ организации системы. Она описывает ключевые элементы и взаимосвязи между ними, задает принципы и стандарты их работы. Согласно популярному фреймворку The Open Group Architecture Framework (TOGAF) корпоративная архитектура состоит из пяти основных слоев, увязанных в единую систему, — это бизнес-процессы, данные, приложения, механизмы интеграции и технологии.

Бизнес-архитектура

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

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

Информационная архитектура

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

Уровни информационной архитектуры

Уровни информационной архитектуры

Совокупность всех данных составляет информационную архитектуру предприятия. Важный инструмент — корпоративная модель данных. Она задает единый язык общения, стандарты и инструменты описания данных, а также правила их хранения, то есть систематизирует требования на всех уровнях информационной архитектуры.

Архитектура приложений

Третий слой корпоративной архитектуры объединяет все автоматизированные системы (АС, иначе говоря, приложения) компании. Их цель — «упаковать» бизнес-процесс или функцию в программные прикладные решения так, чтобы конкретному пользователю было удобно выполнять свои задачи. Например, отделу продаж наверняка знакома CRM-система Salesforce, бухгалтерии — программа автоматизации учета «1С: Предприятие», а вам как клиенту — приложение «СберБанк Онлайн».

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

Уровни архитектуры приложений

Уровни архитектуры приложений

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

Благодаря развитию технических компонентов, баз данных и сетей появился иной подход к проектированию приложений — на базе микросервисов. Это программы, каждая из которых выполняет одну конкретную функцию, работает только со своими данными и взаимодействует с другими микросервисами по сети. Их легко менять, комбинировать и адаптировать под бизнес-задачи, более того, этим могут заниматься разные команды разработчиков независимо друг от друга. Например, после того как интернет-магазин Adidas перешел на микросервисную архитектуру, время загрузки сайта сократилось вдвое. Обновления стали делать 3—4 раза в день, а раньше это происходило раз в полтора месяца. Быстрый и надежный интернет-магазин — конкурентное преимущество ретейлера.

Интеграционная архитектура

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

Один из наиболее популярных сегодня интеграционных стандартов — так называемый Application Programming Interface (API). Он помогает приложениям связываться между собой: принимает запрос одной системы, интерпретирует его, доставляет другой системе, принимает результат и возвращает обратно. По сути, API представляет собой контракт, который фиксирует ответственность одной стороны и ожидания другой. Система, интегрированная с помощью API, как бы говорит: «Ко мне можно обращаться так и так, я обязуюсь делать то и это». Примеры встречаются повсеместно — это встроенные виджеты с прогнозом погоды и картами или банковская система оплаты в интернет-магазине, которая запрашивает у вас код из СМС.

Известные экосистемы AppStore и Google Play предоставляют разработчикам широкий набор инструментов и готовых компонентов (в том числе на основе API) для создания, публикации, тестирования и контроля интеграции приложений. За счет этого компании добиваются стандартизации приложений. Вдобавок это облегчает процесс адаптации уже созданных приложений к новым устройствам или версиям операционной системы. Для разработчиков тоже сплошные плюсы: многие процессы автоматизированы, на создание продукта нужно меньше времени.

Когда происходит интеграция приложений по сети, возможны два варианта взаимодействия:

  • cинхронный (запрос-ответ) — одна система вызывает другую и ожидает ответ;
  • асинхронный (по событиям) — одна система отправляет другой запрос и продолжает работать, не дожидаясь ответа.

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

У event-driven архитектур есть свои недостатки — их сложно разрабатывать и сопровождать. Но за ними будущее. В рамках бизнес-экосистемы количество событий может измеряться миллионами в секунду: входы клиента в экосистему, достижение лимитов, изменение геолокации, покупки и так далее. Требуется архитектура, которая позволит обмениваться ими в режиме реального времени и понимать контекст клиента в каждый момент времени.

Техническая архитектура

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

Когда компании пользуются инфраструктурой и центрами обработки данных Amazon, Microsoft и других провайдеров, — это так называемые публичные облака (скорее всего, вы тоже так делаете, если у вас есть «Яндекс.Диск» или Dropbox). Ряд компаний в стремлении диверсифицировать риски и снизить стоимость прибегают к услугам сразу нескольких поставщиков публичных облаков — этот подход называется мультиоблачным (multicloud). Но из соображений безопасности компании могут предпочесть публичным сервисам частные облачные системы на собственных мощностях. Возможен и гибридный вариант: когда несколько облачных инфраструктур комбинируют в одну. В рамках банковского бизнеса Сбер использует свое частное облако SberInfra, а дочерняя компания SberCloud выступает как облачный провайдер услуг для компаний экосистемы, корпоративных клиентов и государства.

IT-индустрия непрерывно развивается, и требования к качеству корпоративной архитектуры растут. По мере того как компания развивает свои IT-компетенции, устаревшие (legacy) системы постепенно сменяются более гибкими платформенными решениями, состоящими из пересобираемых компонентов, а те, в свою очередь, — cloud-native приложениями, которые в полной мере используют возможности облачной инфраструктуры. Если на этом этапе компания способна превратить свои системы в востребованные внешним рынком сервисы, то можно говорить о высоком уровне ее технологической зрелости.