Рядом с методологией проектирования, разработки и сопровождения информационных систем есть довольно большой пласт интересных идей, которые никогда не достигнут мэйнстрима. Не достигнут не потому, что они сырые или же бестолковые, а потому что сфера их актуальности не велика. Такие идеи могут существовать в голове одного человека или ограниченной группы лиц. Иногда превращаться в корпоративный стандарт, реже становиться отраслевой спецификацией. Как правило, речь идет об организации данных. Иногда процессов и сценариев их изменения и развития. Ну вот сел человек и придумал как следует хранить информацию об узлах связи и каналах передачи данных. Получилась хорошая(или не очень) объектная модель. Другой человек обобщил и нарисовал в своей голове универсальные сценарии оказания партнерских услуг. Третий придумал удобную номенклатуру дел и т.д. Потом они обсудили эти модели с коллегами и те их горячо поддержали. Кто-то искренне, а кто-то из вежливости и стремления соблюдать субординацию. Далее идут отраслевые конференции, статьи в специализированных журналах и пр. Ну а потом наступает самый интересный этап – воплощения этих идей в бизнес-процессах и приложениях.
Вот здесь вот, в точке встречи идеи с реальностью, начинает разворачиваться настоящий экзистенциальный конфликт. И если реальность, как правило, проявляет к нам благосклонность, то информационные системы и люди их разрабатывающие ведут себя совершенно иначе. Во-первых, архитектор информационной системы может вас просто не понять. Во-вторых, у архитекторов и разработчиков есть собственная модель идеального мира, осознанная или подсознательная. Множество шаблонов проектирования(паттернов), оставшихся от предыдущих проектов, прочитанных в институте учебников или выданных гуглом в период импринтной уязвимости сознания разработчика. В-третьих, инструменты разработки, действительно, накладывают весьма заметный отпечаток на разрабатываемую систему. Заложенные в их основу абстракции не получится проигнорировать. Можно, конечно, попробовать поизобретать велосипед и, если вам повезет, то увидеть и опробовать опытный образец, но я предлагаю другой, причем более простой, вариант.
Вам не надо разрабатывать информационную систему. Намного целесообразней ограничиться разработкой структуры системы управления знаниями. Той самой штуки, на которой вы построите бизнес-процессы и взаимодействия. Идея абсолютно банальная (см. ссылки на сообщения в конце этой заметки), но пересказывать её почему-то приходится снова и снова. Вам не надо структурировать “правильным образом” данные в информационной системе. Оставьте вопросы реализации экспертам по проектированию баз данных. Обычно они знают что делают. Сместите акцент на структурирование документацию по системе – функциональные требования, техническое задание, инструкции по организации работ и руководство пользователя. Создайте свой слой абстракции, разделите интерфейс и реализацию (прошу прощения за жаргон). Порежьте двухсотстраничную документацию на короткие вики-статьи. Классифицируйте их, наделите атрибутами и отношениями. Придумайте и запустите процесс актуализации знаний. Назначьте ответственных и настройте оповещения. Свяжите описание процессов с отчетностью о текущих операциях.
По сути, я предлагаю использовать техники построения архитектуры информационных систем к организации знаний. Когда одни и те же сущности предметной области затрагиваются в нескольких параллельно развивающихся проектах без этого не обойтись. Ваши описания объектов и операций должны быть reusable.
Обычно, слово reusable переводят как повторное использование, но есть нюанс. В архитектуре информационных систем оно так же означает одновременное использование некоторого сервиса несколькими внешними системами. Причем такое, когда сервис не дорабатывается специально под каждую из таких систем.
Вы не сможете этого добиться от описания какой-либо бизнес-сущности если запихнете его внутрь своего документа. На него будет неудобно ссылаться и практически невозможно править. Другие авторы в других документах создадут совершенно другие описания тех же самых вещей.
В принципе, всем этим и должна бы была заняться Архитектура Предприятия(Enterprise Architecture), но она надолго задержалась на слишком высоком уровне абстракции и дойдет до решения обозначенной задачи, вероятно, еще не скоро. Впрочем, с архитектурой корпоративных знаний мы и без TOGAF-а с Archimate-ом вполне можем справиться.
- Архитектура предприятия в формате Semantic Web
- Open Graph: Третье поколение глобальной сети
- Почему архитектура нуждается в социальном ПО
Иллюстрация к записи: Kristin Baker, Winter, 2011