Обзор подготовлен
Андрей Сыкулев:
Через 3-4 года развития приложения количество «костылей» превышает все разумные пределы
Андрей Сыкулев, директор по развитию бизнеса компании «Синимекс», уверен, что в будущем прикладные системы должны базироваться на компонентном подходе. Отказ от монолитных решений позволит банкам «на лету» развивать функциональность систем, сокращать сроки и стоимость доработок, а также продлить срок жизни систем. Правда, пока последователи единичны - стоимость подобных проектов достаточно серьезна.
CNews: Каковы, по вашим наблюдениям, характерные черты информатизации банковского сектора в этом году?
Андрей Сыкулев: Самое главное, что в этом году восстановился весь спектр докризисных проектов по всем направлениям: начиная от внедрения новых АБС и заканчивая внедрением и развитием хранилищ данных. Каких-то лидирующих направлений информатизации нет. Развитие ИТ идет ровным фронтом.
Если говорить о финансовых показателях нашей компании, сравнивая итоги 2010 года и планируемые результаты за этот год, то пересегментации выручки также не произошло. Как и раньше, основными нашими проектами остаются работы, связанные с интеграцией приложений, построением инфраструктуры. Правда, появилась едва заметная тенденция - немножко увеличивается доля проектов по автоматизации бизнес-процессов. Но эту особенность вряд ли можно проецировать на рынок, это индивидуальная особенность «Синимекса».
CNews: Какие тенденции вы бы назвали главными на рынке системной интеграции в отечественном банковском секторе?
Андрей Сыкулев: Вопрос не в бровь, а в глаз. Главные тенденции надо искать в отчетах аналитических агентств. Мы же видим, что у всех банков свои проблемы, у нас нет двух одинаковых клиентов, их невозможно как-то выделить, сгруппировать. Интеграционные проекты в 99% случаев — это проекты ведомые, в том смысле, что сначала возникает конкретная бизнес-задача. То есть первичный поставщик – это поставщик бизнес-системы, будь то интернет-банкинг, АБС, хранилище данных, а мы являемся как бы вторичным поставщиком. Поэтому функциональные тенденции в интеграции выделять нет особого смысла. С точки зрения архитектуры, сейчас на рынке явно прослеживается тенденция отхода от универсальных многофункциональных систем к интеграции узкоспециализированных решений, наверное, это продиктовано теми же предпосылками, что и компонентный подход – компактные системы проще развивать и дешевле сопровождать.
CNews: Можно ли проследить тенденции в области интеграции именно в зависимости от приложений, которые вам приходится интегрировать?
Андрей Сыкулев: Это возможно. В последний год большинство наших проектов связано с внедрением CRM, либо дистанционных каналов обслуживания, либо заменой АБС. Удивительно, но это не редкость. В наше сложное время довольно многие банки продолжают проекты по замене АБС.
CNews: Какие из своих ИТ-проектов этого года вы считаете самыми интересными?
Андрей Сыкулев: Это как раз проект по автоматизации бизнес-процесса. Наша задача - построить компонентную систему . Внедряется приложение, которое будет состоять из отдельных слабосвязанных частей. Благодаря этому «части» можно будет менять, что называется, «на лету», то есть без остановки самого приложения.
Как сейчас происходит замена какого-либо компонента? В выходные или ночью останавливается все приложение, «накатывается» новая версия, и программа перезапускается. Наша задача – научиться создавать такие решения, части которых можно было бы менять на ходу, без остановки всей системы. Еще лучше, если можно будет использовать готовые компоненты других производителей.
CNews: Кто будет менять модули: специалисты вашей компании, сотрудники ИТ-департамента банка или бизнес-пользователи?
Андрей Сыкулев: Разговоры о том, что в руки бизнеса можно и нужно отдать изменения и доработки, так или иначе связанные с программированием, еще очень долго будут разговорами. В данном случае актуализировать приложение будут предварительно обученные ИТ-специалисты банка. В принципе услуги по доработке компонентно-ориентированного приложения может предоставлять и сотрудник поставщика.
CNews: Как компонентный подход соотносится с принципами сервис-ориентированной архитектуры, переход на которую декларируется банками как конкурентное преимущество?
Андрей Сыкулев: Сервис-ориентированная архитектура (СОА) – это достаточно высокоуровневый подход к проектированию, который в той или иной степени присутствует в любой современной АБС. Когда мы говорим про компоненты, то имеем ввиду более конкретные вещи. Например, приложение может быть внешне, с точки зрения других систем, построено по сервис-ориентированной архитектуре. Из приложения «торчат наружу» несколько десятков сервисов. Другие системы могут эти сервисы использовать, и в этом смысле получается вполне себе сервис-ориентированная архитектура. Но само приложение может внутри себя оставаться «монолитом», когда изменение в одном его модуле влечет необходимость доработки других, и как следствие, — необходимость периодических технологических остановок всего приложения.
Компонентный подход предполагает, что приложение и внутри себя построено из динамически связываемых частей, что позволяет обновлять компоненты независимо друг от друга, а приложению — работать непрерывно, обслуживая клиентов. В нашем проекте приложение предназначено для обслуживания физических лиц. В этом случае требование непрерывности для банка очень актуально, ведь «физики» пользуются банковскими услугами круглосуточно и без выходных.
CNews: Многие банки заявляют, что в 2010 года значительно нарастили клиентскую базу или кредитный портфель - например в 1,5 раза. Заметили ли вы подтверждения этому в требованиях к производительности внедряемых систем, в стоимости проектов?
Андрей Сыкулев: ИТ-интеграторы, ориентированные на банковский сектор, вместе с клиентами восстанавливаются после кризиса. Не берусь оценить, достигли ли сейчас банки по объемам докризисных уровней. Но дело в том, что приложения, которые были разработаны до кризиса, характеризуются высокой производительностью, поэтому сейчас, даже при заявленной высокой динамике банковского сектора, программы справляются с растущими объемами данных. У многих финансовых организаций «запаса прочности» ИТ-инфраструктуры хватит еще на несколько лет.
CNews: Сегодня на отечественном рынке представлено 15-20 современных автоматизированных банковских систем. По вашим словам, сервис-ориентированный подход в той или иной степени присутствует в каждой из них. Можно ли оценить эту степень?
Андрей Сыкулев: На мой взгляд, разработчики бэк-офисных систем идут тремя путями. Первый: системы, разработанные лет 10 назад еще во времена объектно-ориентированных или клиент-серверных технологий, до изобретения СОА, имеют «стандартные» программные интерфейсы — API. Чтобы встроить такую систему в СОА, для нее делается «обвязка» — сервисная оболочка, после чего сервисы этой системы, хоть и старенькой, становятся доступны внешнему миру – другим приложениям.
Второй способ: компания-разработчик АБС выпускает на рынок новую версию системы, декларируя компонентный подход. На самом деле, новая версия все же строится на основе предыдущей, и компоненты глубоко технически зависимы между собой и не являются слабо связанными. Отдельно от «ядра» системы эти компоненты существовать не смогут. Тем не менее, поставщики предлагают банку выбрать из этих компонентов нужное и собрать некое приложение на заказ. Получаются взаимодействующие между собой компоненты с общими интерфейсами, это уже близко к СОА.
Третий вариант: бэкофис собирается из компонентов от разных производителей, например «главная книга», «расчетный центр» и т.д., части между собой интегрируются. Это уже больше похоже на СОА. Но среди сотен проектов это единицы.
CNews: Такая малочисленность как-то связана со стоимостью работ?
Андрей Сыкулев: По моим оценкам, основанным на косвенных данных, склеивать несколько «бэков» от разных производителей в разы дороже покупки единой АБС.
CNews: Почему тогда вы считаете, что за компонентным подходом будущее?
Андрей Сыкулев: Как интеграторы мы видим, что стоимость сопровождения программного обеспечения опасно растет. Доли затрат, которые тратятся на разработку нового ПО и сопровождение старого, постепенно меняются в сторону увеличения последней. То есть в процентном отношении все меньше средств тратится на разработку новых решений. Это не очень хорошая тенденция, которая ведет к технологическому застою.
Например, сначала банк оценивал заемщика по набору определенных показателей, через год департамент риск-менеджмента решил добавить регион проживания. А в приложении такого поля нет, есть задача его добавления , соответственно, требуется расширить модель данных, внести изменения в слой, который работает с данными, встроить это поле в бизнес-логику приложения, вывести новое поле на экраны и в печатные формы. Если приложение монолитное, то нельзя предсказать, на какие части повлияет доработка, и банк «попадает» на большие проблемы. Во-первых, затруднено распараллеливание работ, потому что с одной единицей кода может работать один человек. Во-вторых, поскольку изменение затрагивает все приложение насквозь, придется перетестировать всю систему. Без тестирования невозможно предугадать, на что повлияет сквозное изменение и кто «накосячил». В итоге «удовольствие» получается очень дорогим.
Мы видим, почему и как происходит замена приложений. Всегда есть давление сроков, и когда требуется добавить новую функциональность, как правило, нет времени разбираться, как и что в приложении устроено. Костыль поставили где-то сбоку, заработало – слава богу. По мере развития приложения количество «костылей» превышает все разумные пределы, и лет через 5 невозможно уже разобраться, что внутри, кто и что написал. Нужно делать дорогостоящий рефакторинг. Проще выкинуть систему и установить новую.
Не хотелось бы, чтобы то же самое через 2-4 года случилось с приложениями, которые мы сейчас разрабатываем. Поэтому ищем пути, как продлить жизнь наших изделий, снизить стоимость их обслуживания, и считаем, что это все-таки компонентная модель, когда приложение строится из слабо зависимых компонентов, которые могут развиваться по отдельности и, что главное – разными поставщиками. Если вернуться к примеру, то изменения будут вноситься только в блок оценки заемщика и еще 3-4 компонента, которые эти изменения затронут. При этом остальные компоненты тоже могут параллельно по-своему меняться. Такой подход означает сокращение расходов, сроков на доработку, сохраняет читаемый, «чистый» код. Технически это возможно, основная сложность лежит в области правильного функционального проектирования. Но решение этой проблемы пока близко к искусству.
CNews: Какие задачи по информатизации банков требуют максимально сложной интеграции?
Андрей Сыкулев: Самые простые интеграционные проекты – решение чисто технологических задач, например какие-то данные надо передать из одной системы в другую, будь то интеграция приложений, построение инфраструктурных систем. Технологическая интеграция занимает от месяца до полугода. Например, мы сделали «Личный кабинет» для одного из пенсионных фондов. Технологическую задачку решили «под ключ» буквально за два месяца. Это фантастические сроки для современных ИТ.
Сложности возникают, когда появляется человек. Если нужно интегрировать процесс, результатом которого будет пользоваться человек, это сложнее. Появляются требования к пользовательскому интерфейсу, распределению обязанностей и ответственности между участниками, требования часто противоречивы и их приходится долго согласовывать. Порой такой проект вызывает смех сквозь слезы, когда на согласование бизнес-требований тратятся годы и, в итоге, согласованный документ появляется на свет изначально устаревшим, потому что за время согласования условия ведения бизнеса уже изменились. Мы последовательно отстаиваем итерационный подход к разработке. Если продукт нельзя установить «в бой» за полгода, то надо сокращать начальные требования. Последующие релизы с расширением функциональности должны выходить 1 раз в 2-3 месяца.
CNews: Если вернуться к такому направлению деятельности «Синимекса», как внедрение бизнес-приложений, на что именно делаете ставку?
Андрей Сыкулев: Мы готовы локализовывать и внедрять точечные западные решения, которых нет на отечественном рынке, так называемые best of breed, которые закрывают узкую задачу, такие как, например, система обслуживания VIP-клиентов, внедрение и интеграция специфических устройств, таких как автоматизированные кассиры и др. Разработчики этих систем не присутствуют в России, у них нет локальной экспертизы. А наш опыт позволяет найти общий язык с западными партнерами. Крупным интеграторам такие заказы, как правило, неинтересны, потому что одноразовое или мелкосерийное внедрение вряд ли заинтересует большую «фабрику» по производству софта. Интерес к услуге постепенно растет, в этом году у нас уже 3 таких проекта.
CNews: Как ваши клиенты относятся к облачным технологиям, которые обещают значительную экономию затрат?
Андрей Сыкулев: К облакам я сам отношусь настороженно. Если брать знаменитый Gartner’овский жизненный цикл, то облака сейчас на взлете. Так было с СОА лет 5-6 назад. Я бы подождал, когда мы заберемся на горку и станем съезжать, тогда и поговорим. В отношении к публичным облачным технологиям российские банки ничем не отличаются от зарубежных коллег, все очень осторожны. Есть ряд некритичных задач, которые можно передать в публичное облако, но в остальном… Даже просто в соответствии с законом №152-ФЗ невозможно передать партнеру персональные данные клиентов. С частными облаками, с одной стороны, все более оптимистично, с другой стороны, не всегда понятно, в чем, собственно, облачность. Часто в облачную маркетинговую струю попадают обыкновенные сервисы, предоставляемые одной компанией-поставщиком другим компаниям. Хотя, конечно, хочется верить, что со временем в «облаках» появятся такие услуги как единый интернет-банк для клиента нескольких банков, доставка от клиента к клиенту юридически-значимых электронных документов, ну и, разумеется, все более разнообразные способы безналичных платежей и расчетов…
CNews: Каковы ваши планы дальнейшего развития?
Андрей Сыкулев: Планов-то много. Как уже упоминал выше, осваиваем технологии построения компонентных систем, основанные на отраслевых стандартах. Расширяем спектр интеграционных решений в сторону сверхбыстрого обмена сообщениями (это нужно, в частности, при биржевой торговле). Разрабатываем решения по гибкой тарификации банковских услуг на основе систем управления бизнес-правилами. Есть много идей по разработке мобильных приложений для бизнеса. Но, как и многие наши коллеги по ИТ-цеху, ощущаем острейший кадровый голод. Специалистов, которые нам нужны, на рынке просто нет. Это всеобщая проблема. Приходится воспитывать самим, но пока вчерашний студент становится самостоятельным специалистом, проходит полтора-два года. Ну, если совсем бриллиантовый молодой человек, то полгода.
В системе подготовки инженеров со времен Советского Союза ничего не изменилось. Мой сын учится на третьем курсе МФТИ, его учат те же самые преподаватели, которые учили меня, по тем же самым программам. Добавилась пара-тройка курсов, но основные дисциплины не изменились. Я не сомневаюсь в качестве физтеховского образования, оно по-прежнему очень высокое. Но, на мой взгляд, современные дисциплины должны появляться в значительных объемах уже на младших курсах, и у студентов должно быть гораздо больше выбора, что изучать: «дифуры» или прикладное программирование, «вычматы» или проектирование современных ИТ-систем. Конечно, квантовая теория поля развивает мозги и воображение будущих программистов, но хотелось бы, чтобы наша высшая школа научилась развивать и то, и другое с помощью более актуальных для бизнеса дисциплин.
CNews: Спасибо.
