Архитектура в ИТ-проектах. Результаты опроса

Реализация бизнес-процессов при помощи чек-листовПришло время вкратце подвести результаты опроса, который я сделал в начале ноября (В конце сообщения будет еще один опрос). Прежде всего, я выражаю огромную благодарность тем, что принял участие. Для меня важен и сам факт вашего участия и непосредственно ответы. За это время поступило 115 ответов. Каждый участник мог выбрать несколько вариантов ответов, но не более трех. При этом разрешалось предлагать свои варианты, чем многие и воспользовались. Вопрос звучал так «Почему ИТ-проекты не ориентированы на использование архитектуры». Проще говоря, почему в ИТ-проектах архитектура отсутствует. Вроде бы вещь небесполезная. У нас в компании все проектные менеджеры желают, чтоб им в проекте разработали архитектуру (не все знают, зачем она им, но все хотят) 

Самым популярным стал вариант ответа: Её нет. Архитектуру проекта никто не разработал.  На первый взгляд, ответ кажется банальным, но по нему было высказано и наибольшее количество комментариев, в которых анализировались причины отсутствия архитектуры. От простого варианта – не хочется тратить время и ресурсы на архитектуру, до замечания о том, что архитектура приводит к необходимости делать выбор, принимать решение, брать на себя ответственность, т.е. делать то, что делать хочется не всегда.

Следующий по популярности вариант ответа: Каждый участник проекта представляет архитектуру по-своему. Т.е. архитектура как бы есть, но у каждого она своя. Вспоминаем самое первое определение архитектуры информационных систем, данное Яном Шарпом в 1969 году:

Обычно, мы рассматриваем только функциональные требования к программному обеспечению: мы рассуждаем лишь о том, что программа должна делать. Но кто-то должен задуматься о большем. Выстроить проект – форму, в рамках которой будут творить программисты или инженеры. Ничто другое не сможет компенсировать недостатки проекта.

Контроль, управление, обучение и другие вещи, о которых мы говорим, очень важны, но специалисты по реализации должны понимать замысел архитектора

Очевидно, что когда каждый участник проекта представляет только свой замысел, то это не архитектура. Коммуникативная функция архитектуры при таком варианте развития событий не срабатывает. Что мы все вместе строим не понятно. Зато будет понятно кто виноват в том, что результат разительно отличается от наших ожиданий – все кроме нас!

И на третье место неожиданно поднялся вариант ответа: Архитектура не отвечает изменившимся требованиям. Самое красивое определение, которое появилось на одном из моих тренингов по архитектуре информационных систем, звучит так: «архитектура – это то, что не меняется при изменении требований». В нем есть определенная правда и определенное лукавство. Архитектура, понимаемая как форма, замысел, концепция, действительно, не должна меняться. Архитектура как проект или план меняется постоянно. Данный вариант ответа описывает ситуацию когда архитектура в проекте, как бы есть, но она уже давно не актуально и потому какого-либо влияния на проект не оказывает.

Еще раз говорю спасибо всем, кто принял участие в предыдущем опросе и перехожу к следующему. На этот раз я хочу попросить вас высказать свое мнение о том, как должна выглядеть проектная архитектура, что она обязательно должна себя включать и какими свойствами обладать. Есть много вариантов ответа на этот вопрос. От традиционного —The “4+1” View Model of Software Architecture прописанного во всех стандартах, до С4 Саймона Брауна (см. Архитектура в формате C4. Sketches and NoUML). Предлагаю следующие варианты ответа

[polldaddy poll=7661396]

Архитектура в ИТ-проектах. Результаты опроса: 3 комментария

  1. Уууух 🙂 Мне есть что сказать по этому поводу!

    Буквально пару недель назад задумывался над тем, как экономично и эффективно развивать ИС внутри организации.
    С одной стороны ты упираешься в необходимость описывать процессы.
    С другой стороны нужно добиться того чтобы они выполнялись так как написаны. Иначе грош цена этим описаниям.
    В третьих тебе нужно максимально стандартизировать разработки. Чтобы они были хорошо интегрируемы между собой и с теми описаниями что ты делаешь.

    И тут есть ряд идей, которые мной уже были проверены и их реальность подтверждаю:
    1. Конечно же wiki и веб-страницы. Только они позволяют достаточно быстро вносить изменения и удобно читать/искать информацию.
    2. ООП = ACM. Аллен Кей сказал, если вам нужна хорошая система, бесполезно думать о функциях отдельных компонентов, а нужно думать о том как этим компоненты будут взаимодействовать друг с другом, без необходимости залазить в их внутреннее устройство.
    3. Среда с описанием и среда с исполнением – должны быть максимально тесно связаны друг с другом и работать по похожим принципам. Так было 100 лет назад, когда регламенты и формы имели единый механизм в основе – бумагу. Сейчас все идет к тому же – только вместо бумажных страниц – веб-страницы.

    А теперь конкретика:
    1. У нас все процессы, отделения и компоненты описаны в формате вики с гиперссылками друг на друга. Это дико удобно. Один раз попробуешь и уже отказаться от этого не получится 🙂
    2. Наша система состоит примерно из 100 модулей. Примерно 80% из них написаны кем то кого мы даже не знаем. Они сами как то обновляются и нас это не волнует. Потому что интерфейсы у них остаются как правило те же. Заданные единым ядром. Ядро обновляется само по себе, а каждый компонент в системе обновляется его автором. Мы следим только за своими компонентами. Как только мы выпустили новую версию компонента – пользователи могут его обновить на своих продуктах. Мне не доводилось видеть чего либо более поразительного в других платформах. Только в WordPress.
    3. Процессы, операции, записи, пользователи – все это веб-страницы, которые связаны между собой. Сотрудник читает регламент по процессу и тут же может перейти в список кейсов ранее выполненных по этому процессу. Человек исполняет задачу, видит не понятный пункт в чек листе и тут же может перейти на инструкцию по этому пункту и тому как правильно его выполнить.

    Тут нет 100% решения. Есть лишь ряд условий, выполнив которые, мы можем с вероятностью в 80% быть уверенными что систему не разорвет под гнетом разношерстных требований.

    И конечно же, есть засада: Архитектура у каждого своя и ее можно решить только одним ломиком: Должен быть архитектор, который сможет пролоббировать решение, которое не даст быстрого результата, но обеспечит выигрышь в перспективе.
    На самом деле такие же засады бывают в экономике предприятий. Когда правильное решение даст ухудшение ситуации в ближайшем горизонте планирования и даст эффект долгосрочном периоде. Такие штуки классно описаны в книге Цель 2 – Э. Голдратт. В архитектуре тоже самое. Мне однажды удалось продавить архитектуру ACM, которая не дала быстрого результата, но затем в течении года данная система дала охват процессов и результативность многократно превышающее рядом стоящую систему, без архитектуры, которая разрывалась под гнетом разнонаправленных хотелок.

    Вот как то так 🙂

    1. Анатолий, а wiki какой используете? Мне все хочется упражнения учебного курса по архитектуре предложить участникам делать прямо в wiki, но MediaWiki с семантическими расширениями выглядит для этого тяжеловатым.

      1. Да, мне когда то также пришлось делать выбор. И перебрал кучу ВИКИ движков. Затем нашел статью о том как человек рекомендовал с аргументами вместо ВИКИ использовать Google Sites. Он меня убедил 🙂 И далее ряд задач удалось реализова на базе Google Sites. До тех пор пока не уперся в его закрытость и ограниченность, в сложности с распределением доступа.
        И вот тогда уже познакомившись с WP понял что они очень похожи, только у WP нет рамок для развития и гибче механика распределения доступа. С тех пор мы все базы знаний и все наши процессы, задачи и переписку ведем в WP 🙂 Как показала моя практика, людям много понятней формат сайтов, чем формат вики. Возможности перекрестных гиперссылок сильны и там и там, но вот формат блога как то понятней. Для примера возьмем ХабраХабр, Лайфхакер.ру – почему эти популярные движки используют этот формат? Потому что для большинства пользователей это наиболее понятный и простой формат. ВиКи формат в чистом виде понятен только гикам и технарям, коих малый процент от общего числа.
        Больше информации по нашим рассуждениям можно найти тут http://casepress.org/?portfolio=kompleksnaya-model-opisaniya-protsessov и тут http://casepress.org/?portfolio=baza-znanij

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *