Через тернии к Омни. Эпизод 1. Вместо предисловия

Привет, коллеги! Творческий центр Департамента ИТ-архитектуры ВТБ, при сдержанной поддержке Технологического блока банка, под настороженно-дружелюбными взглядами неравнодушных представителей ИТ-производства, и с трудно угадываемым молчаливым одобрением служб эксплуатации, неожиданно представляет: первый в России (а значит и в мире) архитектурный сериал «Через тернии к Омни».

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

Итак мы начинаем. Эпизод I.

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

Я, в порыве мимолетной филантропии, предложу посмотреть понятийный аппарат, который мы будем использовать по всему материалу в самом начале нашего сериала и если он сразу вызывает неприятие, подумайте: стоит ли мучиться и читать далее? С наиболее смелыми продолжаем.

Понятие архитектуры

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

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

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

Требования первичны

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

Что такое требования и какие они бывают

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

• Что должна уметь делать система — это функциональные требования;

• И как (под какой нагрузкой, с какой надежностью, с каким временем отклика) она должна это делать — нефункциональные требования. Например, мне нужно выкопать канал для воды: если это канавка на даче — это лопата; если нужен канал между Волгой и Доном — это экскаватор. У экскаватора и лопаты разная архитектура.

От требований к задачам архитектуры

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

ИТ-архитектура должна обеспечить решение двух фундаментальных задач:

• непрерывность бизнеса. Техническими словами это надежность и производительность в заданных условиях организации. Современным уровнем надежности являются надежность 99,99%, то есть, 9 часов простоя в год, время отклика 0,3 сек, под нагрузкой 40 000 запросов в секунду;

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

Сервисный подход

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

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

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

Вместо вывода

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