Эмм... вроде ж кроме бабла там есть ещё срок, и компетенции плюс инструменты. не?

Ну типа это ж анекдот про 9 женщин рожающих за месяц оттуда.

Коллеги, кто какие инструменты использует для документирования архитектуры ИС с точки зрения инфраструктуры? Стоит задача документирования и поддерживания в актуальном состоянии архитектуры ИС с точки зрения  серверов, их ролей, взаимосвязей

И тут есть два пути:
1. Если мы хотим получить профит от того, что в манифесте - изменения происходят в компании, варианта два:
1.1 революция - сходу всем скрам, например
1.2 эволюция - начинаем с того, что есть и постепенно улучшаемся
2. Если не хотим, то три пути
2.1 ничего не меняем
2.2 берем что-то из манифеста и принимаем, что какой-то профит получим, но ограниченный
2.3 придумываем свой путь  идем по нему

Ну... так в принципе можно про что угодно сказать :)

Был такой случай. Корпоративный курс, как часть курса - исполняемая документация, spec by example, все дела.
Участники прониклись, на практике сломали барьер непонимания, но...в текущей реальности не смогли применить знания потому что:
1. Контракт на количество тестовых сценариев, описанные в документе
2. Их много и они уже не успевали подготовить нужное количество
3. Выполнить из этих сценариев успевали меньше половины
4. Но (3) не важно, так как оплата по количеству. В документе.

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

А это ровно ценность про работающий продукт. Документация считается частью продукта, если брать agile, исполняющаяся документация - прекрасный пример. Но контракт и культура не позволили. Так что если изменения затевать, то быть готовым, что измениться должно не только IT. Тут тебе и бюджетирование и контрактование и еще много вещей, вместе и организующих организацию как систему.

Во многих случаях -- ещё и клиенты, регуляторы,... да и вообще бы людей подтюнинговать))

Поэтому чем выше сидишь, тем больше шансов внедрять всякие приколюхи

>> Так что если изменения затевать, то быть готовым, что измениться должно не только IT. Тут тебе и бюджетирование и контрактование и еще много вещей, вместе и организующих организацию как систему.

Вот это самая большая проблема, почему то “трансфрормация” понимается как “оптимизация ИТ”, а бизнес не трожь, это святое.
Ок, разогнали ИТ, теперь видим как решения застревают на уровне бизнеса, как в черной дыре, совершенно мутной, непрозрачной.

В последнее время вижу слово архитектура везде. Даже  "архитектура бровей" появилась. Можно же просто задуматься об эффективности управления, не трогая понятие "архитектура"

Бизнес тоже меняется, мой опыт говорит ровно об этом (мы работаем и на уровне top management и на уровне команд,комплексно). Бизнес действиьтельно более устойчивая структура, чем software. Но тут парадокс — как раз software делает его менее устойчивым. У всех же на виду, как новые продукты целые индустрии уничтожают и вопрос времени, когда какой-нибудь стартап грохнет очередную индустрию или кластер внутри этой индустрии.

Презентации с конференции o’reilly

https://conferences.oreilly.com/software-architecture/sa-eu/public/schedule/proceedings

Для классической системы хватит лагранжиана. Гамильтониан нужен для (не)стационарного уравнения Шредингера в квантах. Хотя классические задачи им тоже решаются, классическая механика проще через Лагранжа.

Кстати, решением стационарного уравнения Шредингера будет, по идее, набор "стационарных архитектур" (читай, собственных функций), а нестационарного - искомая эволюция архитектурного описания в потенциальном поле внешнего мира.

Вот что делать, если поле непотенциальное - настоящая проблема!

За соответствие актуальной архитектуры целевой отвечает скалярное произведение <as_is | to_be>

Вы тут что-то совсем в космос летите, господа

Я жду регуляризацию Тихонова, а то тут Детсад какой-то, штаны на лямках

Спасибо!

Коллеги, кто и как осуществляет архитектурный надзор в вашей конторе?

надзор, полиция и архитектурная инквизиция...