Чаще, чем бы того хотелось, встречается ситуация, когда у нас есть работающее приложение, но на него нет внятного описания. Кто-то и что-то об этом приложении знает. Имеются отрывочные описания структуры данных, а, быть может, нескольких последних изменений, но общей картины все равно нет. Рано или поздно всеобщее желание описать такую систему прорастает в организованную активность. Иногда это вызвано желанием полностью переписать приложение или же отдать его развитие и поддержку на аутсорсинг. Бывает, что мы хотим разобраться с причинами имеющихся с приложением проблем. В общем, типичная задачка, для решения которой зовут архитектора.
Эта заметка не для архитектора, которому поручили сделать описание унаследованного приложения (legacy application). Это сообщение предназначено тем, у кого возникла такая потребность. Предыдущие пару месяцев я посвятил общению с крупными системными интеграторами, предлагающими такую услугу. Пожалуй, главное, что я вынес их этих разговоров: называть услугой работы по описанию унаследованных приложений несколько преждевременно. Спрос есть, предложение есть, а услуги нет. Нет устоявшегося набора подходов к решению такого рода задач и конкурентной среды, которая и формирует из предложений услугу. Если не рассмотреть несколько альтернатив, то высока вероятность того, что вам, кроме действительно необходимых работ, впихнут в предложение огромный объем дополнительных услуг, реализующих их инструментов и соответствующих экспертов. А потому, рекомендация номер один:
Сравните несколько предложений. Даже если вы собираетесь сделать такое описание собственными силами, будет полезным понять, каких ресурсов и какого времени это потребует, как будет выглядеть результат и какова стоимость такой активности. Здесь же начинаются и вопросы. Первый в том, что системные интеграторы неплохо умеют делать аудит ИТ-процессов, но намного реже сталкиваются с задачей описания ИТ-приложений. Второй вопрос состоит в том, что вам скорее готовы продать команду, которая определенное время будет что-то делать, и потому большинство оценок выглядит так: три человека будут работать два месяца. Однако, проведя несколько серий переговоров, можно докопаться до существа и выяснить техники, которыми владеют предлагаемые вам эксперты. К сожалению, речь, как правило, идет о восстановлении требований, т.е. вам предлагают аналитиков, которые привыкли видеть задачу только в перспективе требований. Поэтому рекомендация номер два:
Настаивайте на описании системы с нескольких точек зрения. Требования – штука полезная. Но методы работы с требованиями наиболее хороши в период до разработки приложения, когда системы еще не существует, и потому мы мало что о ней знаем. В нашей ситуации приложение уже давно существует и накопило большой объем информации о поддерживаемых процессах и сопутствующих им данных. Имея в руках систему, мы можем получить намного больше, чем требования. В общем, здесь уже необходимы навыки архитектора, возможно, какой-нибудь несложный архитектурный фреймворк, т.е. совокупность моделей, описывающих систему с нескольких точек зрения. Как минимум, с точки зрения пользователя, разработчика и эксплуатирующего систему администратора.
Определите все используемые технологии и подберите соответствующих экспертов. Информационные системы редко ограничиваются использованием какой-то одной технологии. Система управления базами данных соседствует с сервером приложения. За время развития системы в нем появляются различные библиотеки третьих производителей. Рядом с приложением вырастают различные интеграционные решения, системы мониторинга и отчетности и много всего прочего. Поэтому одним экспертом, как правило, не обойтись. Необходимо выявить все используемые технологии и найти людей, которые в них разбираются. Причем разбираются не на уровне прочитанной книжки, а имеют реальный опыт. Могут не только разговаривать об информационной системе, но, как говорится, и руками в неё залезть. Тем более что следующая рекомендация:
Не ограничивайтесь интервью. Используйте накопленные данные. Мы уже говорили, что наличие системы работающей дает нам существенные преимущества. Такие техники, как Data Mining и Process Mining позволяют нам не просто восстановить требования, но и находить в них ошибки и недочеты. Скорее всего, причина проблем с системой и заключается в плохом проектировании процессов и структур данных или неправильном выборе инструментов (в качестве примера см. Побочный эффект управления корпоративным контентом). Список функциональных ролей можно извлечь из заданных в системе профилей доступа. А заодно и определить количественные характеристики таких групп, посмотреть, кто из них заводит больше инцидентов и для чего люди используют приложение на самом деле. Логи ошибок ответят на вопрос «что же мы не учли при проектировании системы», а тексты комментариев – что думают пользователи об умственных способностях проектировщика данных. Вопрос обсуждался в сообщении Как документировать базы данных Главное, не утонуть в деталях. И поэтому, следующая рекомендация:
Планируйте инкрементальный процесс. Контролируйте результаты коротких итераций. Итерационный инкрементальный процесс подходит не только для разработки программ. Все чаще agile применяют и в других видах деятельности. Рискну предположить, что вызвано это тем, что эти методологии сочетают гибкое планирование со строгим контролем. Одно дело, если вы понемногу подкручиваете процент исполнения шестинедельной активности на диаграмме Ганта, и совсем другое – ежедневные stand-up, на которых требуется рассказать, что ты сделал вчера и будешь делать сегодня. Да и объем проделанной работы измеряют, причем не в условных процентах, а вполне конкретных пользовательских историях. В общем, управление процессом описания системы лучше построить подобным образом. Ежедневный контроль, вероятно, будет лишним, но пару раз в неделю собирать статус работ нужно. Хорошо, если уже после первой недели у вас в каком-то виде будут все финальные артефакты, а также список выполненных и предстоящих дел.
Есть еще два момента, которые представляются мне важными, но не были предложены ни одним интегратором.
Настаивайте на структурировании данных. Я, как архитектор, не понимаю, в чем польза от пухлой презентации в PowerPoint или двухсотстраничного отчета. Скорее всего, унаследованная система когда-то обладала документацией. Затем эта документация утратила свою актуальность, и, как следствие, её перестали читать и перестали поддерживать. Получился замкнутый круг. То же самое случится с нашим описанием, причем намного раньше, чем мы того ожидаем. Думаю, многие из вас предпочтут вордовому файлу документацию в wiki (см. Архитектура предприятия в формате Semantic Web) По крайней мере, видно, кто и что пишет и как продвигается процесс. Иначе люди уходят в себя недели на две, а потом возвращаются вместо внятного результата с какой-нибудь ерундой. А времени переделать уже не осталось. В общем, тема более общая – как вы контролируете результаты труда аутсорсеров и собственных сотрудников. Более подробно она обсуждалась в заметке О вреде проектного управления И заключительная рекомендация
Требуйте нахождения источника проблем. Замена старых систем на новые – дело неблагодарное. Если даже вы твердо решили убить унаследованное приложение, некоторое время жить с ним придется. А значит, следует представлять, как заставить его работать все это время. Обычно мы не слишком консервативны, когда есть возможность избавиться от старого приложения. Отрезвление наступает в ходе разработки новой системы. Особенно если требуется полностью восстановить функционал системы-предшественника, проще говоря, добавить к старым ошибкам новые. Большинство проблем с современными приложениями можно сформулировать так: «мы до конца не понимаем, что происходит, и не имеем возможности с этим как следует разобраться». Все, что нам обычно рассказывают в качестве причины проблем, является не фактом, а гипотезой, которую надо проверить. Наличие набора таких гипотез – признак наличия экспертного опыта. Впрочем, я уже начал рассказывать банальные вещи.
С удовольствием выслушают комментарии и добавления. Спасибо всем, кто занят нелегким делом – археологией унаследованных приложений.