В этой заметке не описываются какие-либо новые идеи, и она посвящена очень практической теме – проблеме эволюции бизнес-процессов. Заметку старался писать в "рабоче-крестьянской" манере, без каких-либо умствований с примененем термина model-driven development и иже с ним (хотя речь, по существу, идет именно об этом). Я знаю, что эту заметку почитает куча моих коллег по малому шоу бизнесу.
Сегодняшние бизнес-системы обычно являются крупными программными системами, поддерживающими производственные и управленческие процессы соответствующих организаций. Функциональные требования определяют природу бизнес-процессов (например, в терминах их целей), а нефункциональные требования накаладывают ограничения на то, как эти процессы должны поддерживаться (в терминах эксплуатационной надежности, производительности, безопасности, удобства обслуживания и технологической платформы). Выявление изменений требований, их трансляция в изменения системы, применение изменений и развертывание измененной системы в совокупности называются эволюцией системы.
Бизнес-системы подвергаются непрерывной модификации из-за изменений среды, в которой они функционируют. Проблемы эволюции систем пытаются решать исследовательские сообщества и программной инженерии, и инженерии баз данных. Однако, как ни странно, представители этих сообществ проводят очень мало исследований в области пересечения своих дисциплин.В большинстве случаев бизнес-система образуется из программной системы и системы данных, которые должны эволюцинировать совместно. Программная система структурируется как набор программ, реализующих бизнес-логику, что достигается на основе интенсивного взаимодействия с системой данных, содержащей бизнес-объекты (заказчики, счета, поставки), которые формируют точный образ бизнеса.
В идеальном мире функциональные изменения транслируются в изменения спецификаций – в частности, проектных моделей и концептуальной схемы базы данных. Мы удаляем объекты схемы, добавляем новые объекты и модифицируем некоторые существующие объекты. Эти операции распространяются на физическую схему, в которой соответствующим образом удаляются, создаются и модифицируются таблицы, столбцы и ключи. Среди разнообразных сценариев миграции наиболее простым и популярным является физический метод. Он состоит в систематическом преобразовании каждой физической конструкции исходной схемы в наиболее близкую по типу физическую конструкцию целевой модели данных. К сожалению, этот быстрый и недорогой метод слишком часто приводит к плохим результатам. Целевая реляционная схема является неполной, поскольку не включает, помимо прочего, внешних ключей и полей более низкого уровня. Кроме того, она ненормализована и избыточна, не наглядна, не документирована, а поэтому ее трудно использовать и практически невозможно поддерживать и модифицировать. В добавок к этому, неприемлемыми могут оказаться показатели производительности.
Как функциональная, так и нефункциональная эволюция систем опирается на доступность актуальных концептуальных схем баз данных. Однако на практике такие схемы могут быть неполными, ненадежными, устаревшими или просто отсутствующими. В таких случаях концептуальную схему необходимо воссоздать, по крайней мере, частично. Следующий шаг состоит в извлечении из этой схемы семантики – т.е. в воссоздании концептуальной схемы базы данных. Обратная инженерия баз данных – это сложный процесс, который невозможно полностью автоматизировать, но он обеспечивает разработчиков полной и актуальной документацией старой базы данных, являющейся необходимой потребностью любого процесса эволюции.
Системы, насыщенные данными, демонстрируют интересное свойство симметрии из-за наличия интенсивного взаимодействия базы данных и программного обеспечения, работающего с ее содержимым. При отсутствии какой-либо полезной документации для понимания логики программы необходимо понимать схему базы данных, и наоборот, понимание того, что делает с данными программа, существенно помогает понять свойства базы данных. Все более популярное промежуточное программное обеспечение объектно-реляционного отображения (object-relational mapping, ORM) позволяет программистам использовать внешнюю объектно-ориентированную схему базы данных, что снижает уровень воздействия проблемы потери соответствия (impedance mismatch) между моделями программирования и базы данных. Однако в действительности эта технология только ухудшает ситуацию, поскольку теперь физическая и внешняя схемы могут эволюционировать асинхронно, с разной скоростью, и отвечают за это независимые группы. В результате наличия недисциплинированных процессов эволюции между компонентами системы могут постепенно образоваться серьезные несоответствия.
В этом бизнес плане я обозначил несколько существенных трудностей, которые необходимо преодолеть, чтобы справиться с проблемой инволюции будущего нашего бизнеса, насыщенного данными. Преодоление этих трудностей принципиально важно для достижения соответствия предписанным стандартам качества русскоязычных айну.
