Создание Enterprise-архитектуры в НСПК

Привет, Хабр! Меня зовут Игорь Тулинов. Я руковожу центром архитектуры ИТ в Национальной системе платежных карт (АО НСПК) и хочу рассказать о том, как наша компания пришла к решению внедрить процессы управления Enterprise-архитектурой, выделить штат архитекторов предприятия и реализовать архитектурный контроль на ключевых стадиях создания ИТ-ценности.

В ИТ отрасли термин «Архитектура предприятия» (Enterprise Architecture) появился более тридцати лет назад. Со временем возник широкий ряд определений этого понятия, моделей, фреймворков и стандартов его описания. Во множестве ИТ и финтех компаний в том или ином виде реализованы процессы управления корпоративной архитектурой.

Но в какой именно момент в компании появляется Архитектура предприятия? Когда и на основе чего организация приходит к пониманию, что настало время внедрять процессы управления корпоративной архитектурой?

Ведь ИТ-компания не публикует вакансию Корпоративный архитектор в начале своего пути. Возраст предприятия, рост клиентской базы или пользовательских запросов также могут обходиться без привлечения экспертов по модели Захмана или TOGAF. Особенно, если бизнес-модель компании предполагает поставку какой-то одной бизнес-ценности (например, процессинг программы лояльности). Рост числа информационных систем? Возможно. Но тоже не всегда порождает процессы менеджмента Enterprise-архитектуры. Ведь разные системы (или небольшие их группы) могут отвечать за разные, не связанные между собой бизнесы или сервисы компании (если речь не идет об архитектуре экосистем, но это отдельная тема).

К созданию корпоративной архитектуры приводит совокупность этих факторов.

Многие финтех-компании задумываются о внедрении Enterprise-архитектуры, но не инициируют движение в этом направлении. Часто это связано с опасениями, что придется обновлять устоявшиеся технологические и организационные процессы, менять работу подразделений, а также использовать новые подходы и решения. Например, пересмотреть критерии создания новых информационных систем, стараться «переиспользовать» имеющиеся ИТ решения, ограничить свободу в выборе инструментов разработки и поддержки, начать смотреть в сторону Cloud-native решений и переводить часть вычислений и данных в облака, «пилить» монолиты на микросервисы, внедрять data-driven подходы, практики сервис-дизайна, ориентироваться на клиентские пути (Customer Journey), а не отдельные бизнес-сервисы, и многое другое.

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

В бизнес-модели компаний-платформ есть такое понятие — «базовая транзакция». Она означает поставку клиенту какой-то одной атомарной бизнес-ценности (услуги, продукта). Например, вызов такси, просмотр ролика, отправка или чтение сообщений. Задача компании – максимально упростить и ускорить поставку «базовой транзакции». Чем для клиента понятнее, проще и быстрее процесс получения бизнес-ценности, тем она популярней. Во многом за счет этой стратегии в свое время «выстрелили» такие платформенные компании как Uber, Skype, YouTube, Twitter. В момент появления Uber уже были приложения для вызова такси. Но их сложный интерфейс и процесс оформления поездки, длительное ожидание подтверждения заказа и самой машины не позволили выиграть конкурентную борьбу у Uber с его простым и быстрым процессом заказа такси.

Технологическая модель НСПК во многом построена на поставке целого ряда «базовых транзакций».

Первой из них в марте 2015г. стал сервис обработки авторизационных запросов по картам международных платежных систем. Этот сервис обеспечивает Операционный и платежный клиринговый центр (ОПКЦ) АО НСПК. В данном случае обеспечить максимальную скорость поставки бизнес-ценности – передать запрос от POS-терминала эмитенту и вернуть ответ эквайеру – было не задачей рыночного преимущества, а одним из главных требований и условий создания самой компании. Поэтому руководство ИТ приняло в тот момент стратегически выверенное решение – минимизировать количество информационных систем, участвующих в сервисе, не использовать базы данных для обслуживания авторизационных запросов (как лишнюю возможную точку отказа и причину лишних временных затрат) и обеспечить максимально возможную отказоустойчивость и резервирование. В итоге возник ограниченный ряд систем, каждая из которых отвечала за свой сервис – авторизацию операций, клиринг, биллинг, антифрод, арбитраж, сертификацию, мониторинг и другие. Была выстроена сервис-ориентированная архитектура с жестким разделением функционала по слабосвязанным между собой системам. Всем было понятно и очевидно, в чей бэклог нужно «складывать» новую фичу.

В дальнейшем НСПК стала «обрастать» новыми бизнес-сервисами. Уже в декабре 2015 г. прошла первая операция по карте «Мир», в летом 2017 г. был начислен первый кэшбэк в рамках программы лояльности, в начале 2019 г. стартовали переводы в рамках Системы быстрых платежей (СБП), а в марте того же года заработал сервис мобильных платежей Mir Pay.

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

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

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

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

Развитие ИТ ландшафта НСПК я бы сравнил с жизненным циклом аэропорта. Сначала появился терминал A, который обеспечивал множество внутренних рейсов между НСПК и банками-эквайерами и эмитентами. Затем возник терминал B, отвечающий за рейсы «авиакомпании Мир». Кстати, уже не только внутренние, но и международные рейсы (СНГ, Турция и др.), плюс программа лояльности. Далее – терминал C (СБП), управляющий службой недорогой и быстрой доставки «грузов» (денег) между эмитентами. Полным ходом идет развитие терминала D (Mir Pay), обслуживающего пассажиров, которые путешествуют налегке – только со смартфоном.
Под каждый бизнес-домен НСПК (ОПКЦ, «Мир», СБП, Mir Pay) создавался свой набор приложений, набирались команды разработки. Если ресурсов команды не хватало на реализацию нового функционала, то для обеспечения короткого time-to-market оперативно формировалась новая команда, а необходимый функционал выделялся в новую систему.

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

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

Вследствие этого в компании возникло понимание, что необходим единый центр систематизации процесса создания ИТ-решений.

Так мы пришли к Enterprise-архитектуре.

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

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

Полагаю, что Enterprise-архитектура – это связующее звено между бизнесом и ИТ.

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

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

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

Архитектура предприятия в классическом виде включает четыре основных слоя:

1. Бизнес-архитектура
2. Архитектура данных
3. Архитектура приложений
4. Технологическая архитектура

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

Поэтому первыми задачами центра Enterprise-архитектуры мы увидели:

• Систематизацию и описание архитектурного ландшафта компании;
• Формирование единого технологического стека;
• Формирование базовых требований информационной безопасности к новым решениям и системам;
• Описание базовых требований со стороны поддержки и мониторинга решений;
• Описание и внедрение архитектурного стандарта и архитектурного процесса.

Расскажу немного подробней об архитектурном процессе. Мы разделили архитектуру на два уровня – Корпоративную (Enterprise) и Архитектуру решений (Solution architecture).

Enterprise-архитекторы отвечают за формирование и контроль общих правил, стандартов и подходов к проектированию решений. Определяют концепцию реализации функционала – какую систему доработать, какие потоки данных создать или расширить, как обеспечить базовые требования безопасности и сопровождения. По итогам проработки вопроса Enterprise создает архитектурные артефакты – карту бизнес-процесса и клиентского пути (Service BluePrint), а также концептуальную архитектуру с верхнеуровневым описанием доработок. С этими артефактами начинает проработку бизнес-инициативы Solution-архитектор.

Кстати, замечу здесь, что мы немного дополнили стандартный скоуп компетенций Enterprise-архитектора задачами сервис-дизайна. Проектирование архитектуры должно начинаться с описания процесса (со «стрелочек»). Поэтому в проектировании сервиса и карты клиентского пути Enterprise-архитекторы принимают активное участие.

Из составов команд разработки выделили Solution-архитекторов. В большинстве своем это разработчики или аналитики. Solution-архитекторы декомпозируют задачу от Enterprise-коллег – детально описывают интеграционные сценарии, формируют интеграционную и компонентную схемы решения, создают карту развертывания. На основе этих документов аналитик создает техническое задание, спецификации и передает в разработку.

Артефакты, созданные Enterprise- и Solution-архитекторами, проходят согласование с представителями управлений безопасности, инфраструктуры и сопровождения.

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

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

Следующей задачей видится создание процесса управления Информационной архитектурой (Архитектурой данных). Для этого также есть масса оснований. Но, учитывая сложность и многогранность вопроса, полагаю, что это тема для отдельного поста.