Сегодня снова про функциональные карты. В апреле этого года, в заметке О заполнении шаблона описания архитектуры решения я затрагивал тему архитектуры в ИТ-проектах. А совсем недавно рассказал вымышленную историю об использовании функциональных карт. Все эти вещи появляются из-за того, что мы сейчас заново пересобираем нашу архитектурную практику. Укладываем фрагменты традиционных и только появившихся техник в новую, совершенно уникальную мозаику. И, безусловно, мне хочется поделиться какими-то находками, разочарованиями и постепенно проявляющимися результатами этих практик
В начале весны процесс разработки архитектуры в ИТ-проектах мы представляли себе в виде пяти (4+1) основных архитектурных представлений. Примерно как на этой картинке
Прикладная, технологическая и интеграционная архитектура особых сложностей из себя не представляют. Достаточно думать об информационных системах, как о совокупности взаимодействующих по сетевым протоколам процессов. Конечно, каждый процесс выполняется в определенном окружении, определяющим характер его поведения, но по сути ничего сложного. А вот верхние два представления, функциональная архитектура и описание предметной области, являют собой благодатную почву для произрастания пустых фантазий, многочасовых совещаний, пухлых отчетов о научно-исследовательской деятельности и, с большой вероятностью, приводят процесс в состояние аналитического паралича. Так вот, функциональные карты помогают нам либо разобраться с десятками страниц требований либо запутаться окончательно.
Поначалу этот инструмент выглядит крайне примитивным. Мы тупо выписываем каждую функцию в отдельном прямоугольнике и отображаем их на одной странице. Затем начинаем передвигать прямоугольники по странице, группировать их тем или иным способом, добавлять недостающие или удалять повторяющиеся. (Конечно, для создания большего антуража мы можем выписывать функции на стикеры и расклеивать их на доске.) В какой-то момент этой незатейливой деятельности включается магия. Фигурки начинают сами группироваться в области деятельности, функции конкретных систем или модулей, распределяться по сложности и приоритетности.
После того, как функциональная карта более-менее стабилизируется её можно использовать как основу для всех остальных моделей. Некоторую логическую сетку, в которую мы будем вписывать бизнес-процессы, приложения, источники данных, стадии и работ и прочие ассоциированные понятия. Т.е. отображенные функции (или capability) используются как набор ассоциирующих классов между любыми другими объектами. Это очень похоже на понятие сервис в телекоме или ITSM. Что такое сервис? Вот есть клиенты, которым предоставляется некоторое оборудование, резервируются определенные емкости, оказываются услуги по подключению и поддержке. Типовой комплекс таких услуг и ресурсов называется продуктом. Клиент покупает, использует и оплачивает продукт, т.е. комплекс всех этих услуг и ресурсов. Однако конкретные железки, порты, емкости и даже уровень сервиса могут меняться. Неизменна только объединяющая их ассоциирующая сущность и называемая сервисом. Думаю, что разработчики стандарта корпоративной архитектуры Archimate думали примерно так же, когда объединяли в своей метамодели все сущности через сервисы. Получилось как-то сложновато, не особо прозрачно, потому не будем об этом лишний раз вспоминать. Остановимся на понятии: функциональная карта.
Впрочем, есть и в функциональных картах одна корневая беда. Вкратце, я бы сформулировал её так: функциональная карта – не территория. Но об этом как-нибудь в следующий раз.
См. также:
Эскизы архитектурных решений: 3 комментария