Unified software development process
Перелистываю фундаментальную книжку «троих друзей» (Jacobson, Booch, Rumbaugh) об унифицированном процессе разработки ПО 1999 года выпуска (перевод на русский в 2002) и с сожалением осознаю, что наиболее ценные идеи RUP и UML не нашли своего воплощения в корпоративной среде. Сплошь и рядом игнорируются три основные свойства унифицированного процесса:
- управляемый вариантами использования;
- ориентированный на архитектуру;
- итеративный и инкрементный.
Процесс развития корпоративной информационной управляется deadline-ами (К кому-то на Новый год приходит Дед Мороз, а к кому-то – дед лайн). В лучшем случае, под такую интерацию подкладываются требования в виде списка фич. Причем, элементы такого списка могут описывать структуры данных, элементы поведения, нефункциональные требования и вообще все что угодно. Что означает доступность сервиса 99,9% редко кого волнует. А ведь большинство современных сервисов включают множество вариантов использования: подключение(подписка), предоставление, настройка, разрешение проблем и пр. Какой из этих сценариев должен успешно завершаться в 999 случаях из тысячи и что такое успешное завершение – решительно не понятно. Далее, в отличие от требований, варианты использования четко описывают, для какой группы пользователей предоставляет требуемый функционал и, что даже более важно, зачем он им предоставляется. В требованиях никогда такого не было. Обычная формулировка требования: у объекта X должно быть свойство Y. На вопросы, кто и в какой момент задает значение этого свойства, кто и когда использует это значение, кому разрешено данное значение переопределить, требования не дают ответов. Унифицированный процесс предлагает построить все активности вокруг сценариев: определение состава проекта(итерации), проектирование, разработку и тестирование, развертывание компонент, планирование capacity и т.д.
Сделать это правда, можно только с использованием архитектуры. Основная идея ИТ архитектуры заключается в том, что для получения качественного решения следует рассматривать продукт с нескольких точек зрения. Недостаточно определить структуры данных и операции. Декомпозиция решения на модули позволяет четко определить зоны ответственности различных команд. Описание взаимодействий – собирает отдельные модули в единую работающую систему. Варианты использования привязывают цели пользователей к взаимодействиям между системами и компонентами, что позволяет планировать характеристики продукта (емкость, доступность, время отклика). Планирование развертывания, с одной стороны, дает возможность независимо от процесса разработки готовить инфраструктуру, а с другой стороны помогает не запутаться при согласовании настроек различных сред и приложений.
И все эти активности происходят в ходе всего проекта, т.е. решение разрабатывается инкрементально, от простого к сложному. Как известно, сложную систему невозможно заставить работать(«включить»). Её можно «вырастить» из простой работающей системы. Точно так же с первого раза невозможно сделать хорошую архитектуру, хорошую документацию, хорошие тесты. И именно поэтому в процессе нужна социальная составляющая. Люди должны общаться, ругаться, договариваться, причем делать все это не «на пальцах» а при помощи моделей и прототипов системы. Весь agile, пришедший вслед за унифицированным процессом построен на этом. Не ИТ разрабатывает систему для бизнес-заказчика, а заказчик разрабатывает себе систему при помощи ИТ. Иначе получится как всегда.
На протяжении последних десяти лет ИТ архитектура и управление ИТ-сервисами(ITSM) следуют параллельными курсами. Не то чтоб они не пересекаются, пересекаются они на каждом шагу, я бы даже сказал, не пересекаются, а скорее сталкиваются, высекают друг из друга искры и снова расходятся на безопасное расстояние. При этом оба обозначенных направления изначально не являлись целостными и крайне друг в друге нуждаются. Проблема ИТ архитектуры заключается в её статичности. Архитектурные модели, вырванные из процессов ИТ, не актуализируются и довольно быстро устаревают. Архитекторам, зачастую приходится заниматься тем, что Гради Буч назвал software archeology, раскопками утраченных знаний о том, что представляет собой ИТ система и как она работает. В свою очередь, ИТ процессам очень не хватает четкой классификации объектов и отношений между ними. Определяемые ITIL понятия ИТ-сервис и конфигурационная единица(КЕ) не особо конкретны. Любое существительное можно назвать КЕ, однако сколь либо стандартизированных классификаторов КЕ не существует и организациям их приходится придумывать самостоятельно. С ИТ-сервисом ситуация не лучше. Про него по большому счету известно то, что он предоставляется и то, что он обладает(или должен обладать) соглашением об уровне сервиса (SLA). Попробуем «подружить» архитектуру информационных систем и управление ИТ-сервисами 
Почему-то архитекторам свойственно напускать много сиреневого тумана на свою деятельность: и определения что такое архитектура единого нет; и книжки про архитектуру все почему-то довольно толстые. Даже великий Буч, как мне кажется, больше написал о том, чем не является архитектура, а не о том, чем же она является. Мне хочется сделать простой и по возможности краткий обзор того, что же такое архитектура. Может начальникам как-нибудь расскажу. Обзор будет субъективный, потому сразу прошу – тапками в меня не кидайтесь.
