Мы же под "software architecturing" понимаем одно?

Скрам слишком мелок для архитектуры, он только покрывает малую часть процесса и ЖЦ разработки.

Конечно. Просто там в скобочках указано)

Понятия не имею. Но не бывает архитектуры без процессов и наоборот )

Месяц назад я согласился с Эберхардом Рехтиным. Пока беру за reference.

Ну и вот тут хорошо показывается, что "Not engineer's role to decide what makes a Church a Church"
Тот, кто создаёт feeling of space (sic. воображает и умеет выражать людям и в проект-схему-команду-компанию)  + требования заказчика

Э, это к чему, я глупый, не понимаю

Давай я прямо Эберхарда процитирую

#Откликнуться(↑)

Это из семинара "SYSTEMS ARCHITECTING AND SOFTWARE INTEGRATION" Eberhardt Rechtin'а, который проходил примерно в 2001 году.


Проникаюсь уважением к Эберхарду как к отцу термина "software architecturing":
1) он обозначил , что Art - это восприятие, представления, визуальные отображения
2) "модели - это не реальность", "карта - не территория"
3) имел смелость внести понятие "феномен" в инженерный текст.

Ну да. А при чем тут социальные и организационные процессы?

Было время, когда я склонялся к такой модели:
код = f(дизайн)
дизайн = f(архитектура)
архитектура = f(требования)
требования = f(процесс)
процесс = f(культура, бизнес-модель)
бизнес-модель = f(рынок, окружение, …)

А потом все сломалось 🙂
В Complex Adaptive Systems, во первых, связи в обе стороны, а во вторых (об этом, кстати, будет доклад на архдейз) — вполне реальный кейс когда
(новая) бизнес-модель = f(архитектура)

Так, ты согласен с базовой посылкой здорового консалтера о том что "IT лишь реализует орг.дизайн определённым образом - так что, конечно, можно менять реализующие системы - но оптимальный результат достигается теми, кто умеет соотносить change
1) в среде (рынке)
2) в профильной отрасли (типе рынка)
3) в консорциумах-производственных объединениях
4) в Предприятии (Ent)
5) в совокупности отделов
.....
х) в системах, которые являются средствами поддержки управленческих и операционных решений"

» (новая) бизнес-модель = f(архитектура)
О, я как раз про это. Заинтересовал :)

Раньше было "(новая) идеология = f(архитектуры)"

Вот этот доклад: https://archdays.ru/#speaker-181_227
Не смотря на то, как он называется, там история такая:
Вначале была одна бизнес модель и под нее была архитектура
Затем архитектура менялась и открывала возможности для развития новых бизнес-моделей
Какое-то время поддерживалась определенная бизнес-модель, архитектура развивалась, видоизменялась и в какой-то момент открывала возможность для появления еще новых бизнес-моделей. Чистая органика 🙂
Если не сможешь прийти, будет запись.

В западных микросервисных кругах, к слову, архитектура = оргструктура. Что тоже интересно. Потому что тогда архитектор проектирует не информационные системы, а организацию в целом.

Я тут понял, что за семь лет в Таллине я сросся с такой постановкой отношения к архитектору.
И причиной непонимания в околоархтектурных разговорах является моя полная нерефлексивность, что может быть по-другому...
Удивлен, благодарю за мысль!

Ну да. Нельзя проектировать архитектуру отдельно от оргструктуры и бизнес-процессов.
Но этого много где не понимают.

Это определения подходит скорее к Enterprise архитектуре. А вот уже на основе Enterprise архитектуры, которая включает в себя бизнес-процессы в привязке к оргструктуре, мы уже можем делать набор сервисов или микросервисов, которые автоматизируют описанные ранее процессы организации.

То есть прямого перехода оргструктура -> микросервисная архитектура быть не может. Нужно промежуточное звено и вопрос только в том формализуем мы это в документах или все в голове держит архитектор.