3. Если я проигнорирую процессную часть, гаркну на DBA и лидов, что "переходите, тут распоряжение" - то я не передам сути изменения, способа и последовательности. Т.е. заставлю их "выгребать, как умеют".
Это есть способ создания долга. Его префикс (организационный, технический, ...) будет зависеть от места действия.
То, что базово мы смотрим только в технологию порождает иллюзию, что везде только технологический долг - но это не так.

Вводные:
1. Компания взвесила все за и против, обсудила и приняла решение об унификации СУБД - все на Oracle, поддержим экономику США.
2. Есть живые проекты, использующие MySQL.
В какой момент появляется тех. долг?

Давайте так. Решение было принято после обсуждения.

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

Вы сейчас мне или Евгению?

С вами почти не общался. Я больше про общие настроения чата. За месяц тут, примерно такое вижу.

Так точно.  "Людям нужно создавать продукт и решать им проблемы потребителя".
Недавно тут встречал тред про "русские инженеры лучше всех, поэтому их все и нанимают".

Тут чат архитекторов (опять же, что бы пока это слово ни означало), практика чжэнмин для архитектора базовая.

Ну тред про лучше всех, это так издевка. Ошибка выжившего почти, не совсем но почти.

"Чжэнмин", не понял что за практика?

Я вот в соседнем окне пишу микросервис для интеграции продукта с MDM/ERP.
Является ли тех.долгом то, что я сделал набросок автоматической генерации openAPI-спецификации - но до сегодняшнего дня не шел в реализацию?
С точки зрения "prudent design debt"  - нет. Дизайн как раз предусматривает автогенерацию.
С точки зрения "prudent application debt" - да, ведь "должен" - это способ зафиксировать контракт, его важные части, которые пока не имеют срока и приоритета.

С точки зрения  "тех.долг" - нет, конечно.

Спорная практика

Когда между "спор", "спора" и "пора" я могу моментально выбрать значение слово "спорный" - безусловно.
Вот когда не могу - ...

Ух ты, так мы с вами друг друга понимаем :)
https://t.me/c/1304614627/4180

"Но приходится все равно работать в среде, где 100 видов понятий для одних и тех же сущностей. И везде вытаскивают вперед свои, а не общепринятые."

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

но вряд ли, хотя бы 10% архитекторов этого чата позволяют себе мышление неоднородностью времени компании... хотя вся цифровизация с позиции бизнеса, только про изменение времени поставки опыта для пользователя и про изменение времени процесса потребления товара или услуги пользователем. тот факт, что основным способом изменения времени является автоматизация делает "инженеров" заложниками, либо "магистрами игры" со временем.

поэтому "time to market" - ведущая категория цифровизации, но само время и сам рынок - разные "отделы" почти любой компании будут понимать разным образом и кодировать разными словами. тот, кто сможет придумать модель согласования слов и соотнесения образов - станет самым гибким:)

»  кто сможет придумать модель согласования слов и соотнесения образов - станет самым гибким:)
Ага, так и есть. Осталось это сделать :)

сомнительно, что прозрачность на самом деле кому-то нужна, так как за неё придётся выплатить большой образовательный и нравственный долг.

рынку нужен дурак, корпорации "вершок(который сверчок :)) ) знающий свой шесток" - какая уж тут прозрачность...

здрасте уважаемые.

Я щас может наивный или глупый вопрос спрошу...

Подскажите пожалуйста, следующее. есть описание процесса,  что-то типа "для выполнения бизнес-процесса, надо чтоб менеджер тыкнул в том UI кнопку, оно запустить такой то сервис, этот сервис сделает такие-то вызовы тех сервисов, и так далее"

В принципе, я такие вещи описываю в UML sequence diagram.

А как можно такое описать в ArchiMate 3?