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


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


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


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


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


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


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


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

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


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


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


В дальнейшем НСПК стала «обрастать» новыми бизнес-сервисами. Уже в декабре 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-архитектуры и архитектурный процесс. В нашем случае оптимально было начать с уровня прикладной архитектуры (слой приложений).


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

Мир Plat.form (Национальная система платежных карт)
Компания

Комментарии 10

    0
    Нам потребовались специалисты, которые «видят» ИТ-ландшафт компании системно, на более-менее высоком уровне абстракции.

    Где вы их нашли?
    Сколько они стоят?

      0

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


      Часть людей переходят из крупных ИТ-компаний. Это специалисты, имеющие хороший опыт работы корпоративными архитекторами.


      Уровень дохода в нашей организации озвучивать не могу в виду формальных ограничений. Но он соответствует среднему значению относительно крупных ИТ-компаний.

        0
        А какое среднее значение у относительно крупных компаний? На это ведь у вас формальных ограничений нет? :)
    0
    Из составов команд разработки выделили Solution-архитекторов. В большинстве своем это разработчики или аналитики. Solution-архитекторы декомпозируют задачу от Enterprise-коллег

    У вас, получается, аналитики стоят уже после архитекторов, а не общаются с бизнесом «на первой линии»? Или всё же есть какие-нибудь Enterprise-аналитики для управления требованиями верхнего уровня?
      0
      Насколько я понял из текста, верхнеуровневые требования — вотчина enterprise архитекторов, которые ими сами и управляют, накладывая на существующий ландшафт, либо формируя новые части ландшафта для удовлетворения бизнес-требований.
        0

        Да, тоже верно.

        0

        Схема такая. Во-первых, Enterprise-архитекторы берут на себя большой объём работы в части бизнес-аналитики. В статье описано укрупнённо. На самом деле в рамках проработки Enterprise-архитектуры есть три этапа — сервис-дизайн, проектирование архитектуры бизнес-сервиса и проектирование концептуальной архитектуры решения. Вот первый и второй этапы это в основном бизнес-аналитика — в нашем случае это карта клиентского пути (CJM), uses-cases, Service BluePrint, sequence-диаграммы бизнес-процессов, детальные функциональные требования (UX в общем). А на этапе проработки Solution-архитектуры свой скоуп задач решает уже системный аналитик. Он декомпозирует архитектуру бизнес-сервиса. Описывает сценарии интеграционных взаимодействий, например.


        Во-вторых, работа всегда носит совместный характер. И системные аналитики и разработчики при необходимости привлекаются для консультаций на этапе Enterprise архитектуры. Нет «конвейера» с четко разграниченными зонами участия специалистов. Этапность здесь скорее — про хронологию создания архитектурных артефактов (документов, схем). Сначала Enterprise-артефакты, затем Solution.

        0
        Поэтому первыми задачами центра Enterprise-архитектуры мы увидели:… «Формирование единого технологического стека;» — удалось решить задачу? На чём остановились в итоге?
          0

          Добрый день! В организационном плане это тодна из сложных задач. С одной стороны мы должны создавать новые решения на том, что сможем далее развивать, переключая или подключая разработчиков из других команд. То, в чем есть широкие компетенции (напр., Java, Kotlin, MySQL, Kafka и др.). С другой стороны мы должны осваивать новые версии средств разработки или технологические решения. То есть «бетонировать» техстек на века было бы неправильно. Поэтому определяем сейчас основной набор технологий, плюс реализуем менеджмент процесса расширения техстека (изучение, тестирование, пилотирование и утверждение новых решений).

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое