Пришло время вкратце подвести результаты опроса, который я сделал в начале ноября (В конце сообщения будет еще один опрос). Прежде всего, я выражаю огромную благодарность тем, что принял участие. Для меня важен и сам факт вашего участия и непосредственно ответы. За это время поступило 115 ответов. Каждый участник мог выбрать несколько вариантов ответов, но не более трех. При этом разрешалось предлагать свои варианты, чем многие и воспользовались. Вопрос звучал так «Почему ИТ-проекты не ориентированы на использование архитектуры». Проще говоря, почему в ИТ-проектах архитектура отсутствует. Вроде бы вещь небесполезная. У нас в компании все проектные менеджеры желают, чтоб им в проекте разработали архитектуру (не все знают, зачем она им, но все хотят)
Самым популярным стал вариант ответа: Её нет. Архитектуру проекта никто не разработал. На первый взгляд, ответ кажется банальным, но по нему было высказано и наибольшее количество комментариев, в которых анализировались причины отсутствия архитектуры. От простого варианта – не хочется тратить время и ресурсы на архитектуру, до замечания о том, что архитектура приводит к необходимости делать выбор, принимать решение, брать на себя ответственность, т.е. делать то, что делать хочется не всегда.
Следующий по популярности вариант ответа: Каждый участник проекта представляет архитектуру по-своему. Т.е. архитектура как бы есть, но у каждого она своя. Вспоминаем самое первое определение архитектуры информационных систем, данное Яном Шарпом в 1969 году:
Обычно, мы рассматриваем только функциональные требования к программному обеспечению: мы рассуждаем лишь о том, что программа должна делать. Но кто-то должен задуматься о большем. Выстроить проект – форму, в рамках которой будут творить программисты или инженеры. Ничто другое не сможет компенсировать недостатки проекта.
Контроль, управление, обучение и другие вещи, о которых мы говорим, очень важны, но специалисты по реализации должны понимать замысел архитектора
Очевидно, что когда каждый участник проекта представляет только свой замысел, то это не архитектура. Коммуникативная функция архитектуры при таком варианте развития событий не срабатывает. Что мы все вместе строим не понятно. Зато будет понятно кто виноват в том, что результат разительно отличается от наших ожиданий – все кроме нас!
И на третье место неожиданно поднялся вариант ответа: Архитектура не отвечает изменившимся требованиям. Самое красивое определение, которое появилось на одном из моих тренингов по архитектуре информационных систем, звучит так: «архитектура – это то, что не меняется при изменении требований». В нем есть определенная правда и определенное лукавство. Архитектура, понимаемая как форма, замысел, концепция, действительно, не должна меняться. Архитектура как проект или план меняется постоянно. Данный вариант ответа описывает ситуацию когда архитектура в проекте, как бы есть, но она уже давно не актуально и потому какого-либо влияния на проект не оказывает.
Еще раз говорю спасибо всем, кто принял участие в предыдущем опросе и перехожу к следующему. На этот раз я хочу попросить вас высказать свое мнение о том, как должна выглядеть проектная архитектура, что она обязательно должна себя включать и какими свойствами обладать. Есть много вариантов ответа на этот вопрос. От традиционного —The “4+1” View Model of Software Architecture прописанного во всех стандартах, до С4 Саймона Брауна (см. Архитектура в формате C4. Sketches and NoUML). Предлагаю следующие варианты ответа
[polldaddy poll=7661396]