Комментарии 6
Реальность все-таки куда шире, от проектов попадающих под действительно жесткий regulatory compliance, до проектов в которых важнее всего доказать жизнеспособность идеи. И от разовых проектов на три месяца, когда с заказчиком больше никогда не увидишься — до проектов в которых с заказчиком надо жить по 20 лет потом. И на одном краю всего спектра все описанное будет выглядеть недостаточным “детским садом” и “деревенской самодеятельностью”, а на другом превратиться в неподъемное бюрократическое бремя и скорее убьет потенциально успешный проект. Мне в этом плане “не повезло”, я работаю не в нише, как консультант я сталкиваюсь с самыми разными проектами — от системы безопасности АЭС до стартапа пытающегося вытащить совершенно безумную на первый взгляд идею.
Ну и да, не всегда и не везде sales и executives настолько не способны или найти заказчика понимающего как на самом деле делаются проекты или объяснить ему как это делается. Поэтому нахождение с состоянии “никто кроме меня этого не понимает” — совершенно не обязательное. Опять-таки когда меня просят посмотреть процессы — такие моменты это первый “красный флаг” того, что что-то идет сильно не так. Вон в ПыМыБОК аж специально дисциплины под это специально ввели — управление коммуникациями и управление ожиданиями. Мне конечно проще, я в позиции когда я могу на это напрямую влиять, но таки иногда и от Agile есть польза в таких случаях. Когда мы начинаем задавать себе честные вопросы “на фига мы делаем работу которая на самом деле не приносит пользы” — очень быстро выясняется что или мы, или те самые злобные другие действуем не по злому умыслу, а просто из-за недостатка прозрачности.
Не лезу с советами, но мне просто кажется две маленьких вещи:
— Четкое определение круга проектов и ситуаций к которым относятся все утверждения
— И оценка “по чем нам это обошлось” не только для критикуемых решений, но и для своих (потому что бесплатного сыра не бывает, мы всегда чем-то жертвуем, и часто самый интересный анализ лежит не в плоскости “что мы получили”, а в плоскости “чем мы за это заплатили/что мы потеряли”)
сделают просто хороший цикл статей — вот прям таким, что хоть в учебник вставляй. Мне почему-то кажется что он того стоит.
Спасибо за развёрнутый коментарий!
Весь цикл (если он когда-нибудь будет) описывает процесс, а не результат. Я делюсь своим опытом (шаг2: продуктовая корпорация с энтерпрайз заказами, долгий срок разработки и обслуживания) большее по стадиям развития решения — они на 80% стандартные в энерпрайз. Сама же архитектура и реализация уже сильно относятся к конкретной задаче и серебряных пуль нет. Категорично писать — "делайте серверлесс на graphQL", на мой взгляд, признак непрофессионализма. А вот "подумайте нужно ли вам облако" — подход верный во всех случаях. Как вы сами и отметили — за всё нужно платить.
В плане не всегда архитектор единственный специалист, конечно, вы правы. Но принцип Питера приводит любые корпорации к состоянию, что те, кто понимают, не влияют на процесс — не принимают решения. АЭС прислушивается к вашим словам, потому что они уже прошли весь путь внутреннего пищеварения, раз обратились к стороннему консультанту.
Сама должность архитектора достаточна абсурдна — отвечаешь за процесс, которым не управляешь.
p.s. С точки зрения архитектора мне нравится позиция которая им в RUP отводилась, я стараюсь что-то такое и ораганизовывать моим архитекторам. Что бы у архитектора отвественность была только дать набор проверенных типовых решения для типовых задач, но вот отвественность выбора наиболее подходящего из типовых решений для проекта лежит все-таки на команде. Ну с возможностью «вызвать дух» архитектора если сами затупили. Тогда это происходит чуть позже, чем «ну-ка скажи нам путь на 10 лет вперед», и возможностей дать внятный ответ больше.
p.p.s. Комментариев и лайков, кстати, почти нет. Верный признак дельной статьи. :-)
"Так что в отличии от строительства, вы начинаете разработку с наброска, а детальную архитектуру получите лишь в конце."
Полагаю, что "детальная архитектура" - противоречит самому понятию "архитектура": понятие "архитектура" противоречит детализации, а является неким агрегатором, укрупнением, формирующим верхнеуровневый взгляд (причем "одного стандарта" , т.е. одного архитектурного подхода). Лучше тогда для "детализации" применять слова модель, структура и т.п.
Кстати, почему нигде нет полного примера "Архитектура предприятия"? Реального примера, пусть и простого предприятия.
Архитектура, по моему мнению - это как раз цельная картина, наполненная деталями. Полный и конечный результат. Модели и структуры - это лишь часть архитектуры. Элементы. И жизненный путь проходит от верхнеуровневых элементов к деталям в тот самый агрегатор.
Насчёт примеров: реального ничего выложить нельзя - NDA. Какого то типового проекта тоже нет, так как именно в предприятиях свои нюансы. Большая часть разработки - унификация и интегрирование. Так что всё зависит от того что уже есть и с чем хотят расстаться. После отпусков закончу цикл и может соберу какой то пример под все этапы.
Архитектура архитектуры. Шаг 5: один за всех и все на одного