Андрей Трушкин - Архитектура цифрового мира

Рассмотрим примеры эволюционного и революционного развития архитектуры и выделим их основные характеристики. В качестве наглядного примера рассмотрения возьмем такую ключевую тенденцию развития архитектуры, как распределенность.

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

Если взять за отправную точку рассмотрения уже упоминавшийся столь значимый для ИТ 2001-й год, можно отметить, что на тот момент ИТ-решения для большинства направлений человеческой деятельности имели «монолитный» характер, представляли собой целостную единицу развертывания (либо весьма ограниченный набор таких единиц). Создание и развитие таких решений велось обширной командой развития, включавшей представителей разных направлений деятельности.

Возьмем в качестве наглядного примера финансовую сферу. Основой финансовой сферы являлась (и является) учетная платформа (в России традиционное название – автоматизированная банковская система, АБС). Эта система (при исходном проектировании) выполняла следующие функции:

• Учет финансовых/хозяйственных операций;

• Ведение счетов;

• Ведение плана счетов;

• Бухгалтерский документооборот;

• Валютный учет;

• Многофилиальный учет;

• Налоговый учет;

• Формирование учетной документации для проведения проверок;

• Формирование оперативной и аналитической бухгалтерской отчетности (операционный день и т. п.).

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

• Ведение данных клиентов;

• Управление бизнес-процессами;

• Автоматизированные рабочие места сотрудников, ведущих обслуживание клиентов;

• Продуктовые операции (не только учетного характера, но и, например, продуктовые конвейеры);

• И т. д.

При этом учетная платформа представляла собой «закрытое» (vendor-lock) программное обеспечение, основанное на «закрытом» же технологическом стеке, предоставляемом независимыми поставщиками, требовавшая значительных инфраструктурных мощностей для обеспечения корректного функционирования.

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

Пример указанного функционала монолитной системы в формате учетной платформы приведен на Рисунке 6.

На Рисунке 6 представлено разделение учетной платформы на следующие составные блоки:

• Целевой функционал, который направлен на автоматизацию собственно учетной функции;

• Вмененный функционал, который не связан непосредственно с целями учета;

• Автоматизированные рабочие места, к которым можно отнести целевые (АРМ бухгалтерии) и вмененные (АРМ специалиста по обслуживанию клиентов).

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

Рисунок 6. Пример монолитной системы в формате учетной платформы

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