Позволю себе пример из книги Юнга о психологии Бессознательного. В данной работе противопоставляется понимание либидо Фрейда и Адлера, из которых Юнг, применяя диалектику, выводит 2 ортогональные оси: любви и власти.
Затронутый вами вопрос: «инженерия vs психология», на мой взгляд, разрешается схожим образом. Да, это можно назвать мягкими навыками, но только построенными вокруг векторов интересов, а не вокруг эмпатии. Развитие эмоционального интеллекта важная задача (к слову, LLM пытаются с ней рьяно помогать в силу токсичной позитивности), но тут другая задача - выход из конфликта.
Вопрос, к которому я прихожу после синтеза, - вопрос о манипуляциях. В тех случаях, когда собеседник выдаёт плохую коммуникацию за причину, там где повод лежит в области интересов, собственности. Есть немало людей, которые умеют на маниакальном уровне врать, выдавая ложную эмоцию.
Я бы сказал, что это не «инженерия против психологии», а «инженерия + психология против манипуляций», где инженерия - фреймворк, психология от LLM, манипуляция от оппонента.
И да, до эмоций алгоритм не дотягивается - тут я целиком за вами.)
Спасибо за комментарий. Мой ответ будет столь же многослойным
Вы правы, что форма товар/средство производства/средство потребления не нова и описана у классиков. Вопрос, который я пытался поставить - возможно ли, что один и тот же объект выступает во всех трёх ипостасях одновременно для разных экономических агентов, и что это меняет характер присвоения? Автобус не является средством потребления для пассажира в том же смысле, как LLM для пользователя ChatGPT, т.е. вы упускаете метаморфозу средства потребления в средство производства. Автобус ничего не производит - это инструмент водителя. А проектор в кинотеатре как раз воспроизводит фильм. Кинофильм при этом “не затрётся до дыр” на носителе, чего не избежать автобусу.
В литературе есть несколько параллельных попыток, например, algorithmic surplus value, Grammenos.
В Критике политической экономии эта тема не раскрыта ни потому, что её нет, а потому что она была в зачаточном состоянии. Патенты, авторское право, ранние формы авторских отчислений - всё это были «сырые» отношения. Автор знаменитой работы гениально проанализировал формальное и реальное подчинение труда капиталу на материале фабрики XIX века. Но у него не было перед глазами IBM PC, интернета и GitHub’а. Анализ виртуального товара - это не ревизия, а развитие метода исторического материализма на новом, не существовавшем ранее эмпирическом материале. LLM замещает интеллектуальный, творческий труд, который считался «незаменимым» при классиках. И замещает его трудом, обученным на продуктах самого работника. Это не просто «машина». Это имитация живого труда мёртвым трудом. Это репликация способности к творчеству, а не только физической силы.
Классики безусловно сказали очень много. В тоже самое время, как мне кажется, намеренно не отливали себе бронзовых статуй, но сформулировали метод.
Есть вероятность, что эксперт, отвечающий на вопрос уже знаком с ней или аналогом. Поэтому я пока двигался в сторону мета-уроков (промты в репозитории). Надеюсь, получится прийти к мета-шаблонам “смены парадигмы”.
Спасибо. Это, пожалуй, самый важный комментарий из возможных — потому что он вскрывает именно ту границу, на которой мой фреймворк перестаёт быть «инструментом победы» и становится «инструментом диагностики».
Вы описали ситуацию, где:
дисбаланс власти закреплён не только между отделами, но и между сотрудником и его руководителем;
руководитель не защищает, а использует вашу энергию как ресурс для своей репутации;
любые попытки конструктивного диалога будут восприняты не как паритет, а как сигнал «здесь можно ехать».
В такой конфигурации фреймворк не даст вам выиграть конфликт. Но он даст другое: трезвость. Он покажет, что проблема не в вашей «плохой коммуникации», а в структурном перекосе. Что вы не «не смогли договориться», а оказались в игре, где правила писала другая сторона - и она же судит. Это не снимает боли, но снимает самообвинение. А это уже немало. Чем больше итераций (ситуаций), тем лучше ваша карта описывает ландшафт этого самого структурного перекоса - возможно какие-то горы можно обойти.
Зачем я сделал этот фреймворк? для того чтобы видеть все возможные исходы, оценить возможность смены парадигмы, последствия того или иного выбора. Например, как-то готовился к сложному диалогу, и провёл 63 итерации моделирования - от простых до самых циничных. Да, LLM уступает нам в смекалке, а ситуации могут быть очень сложные. Тем ценнее возможность подготовиться - это точно лишит любых сожалений “если бы”.
Возможно, этим мечом не прорубить стену прессинга и систематического использования вашей энергии для чужой карьеры, но и совсем без защиты он не оставит.
Вы говорите: «статья смещает фокус на внешний локус контроля, а это вредно». Но это спор не о фактах, а о том, как правильно смотреть. Исследования локуса контроля показывают корреляцию с личным успехом - но они не показывают, что структуры не существует. Если вы попали в шторм, внутренний локус поможет грести, но не отменит волн. Статья - про волны, про «корпоративную рябь».
Теперь глубже. Почему вообще возник спор о том, как «правильно» смотреть? Потому что за этим стоит убеждение: лестница настоящая. Тот, кто поднялся, склонен верить, что подъём был честным. Это понятно по-человечески, но ваша уверенность - это убеждение, а не анализ. Из того, что вы прошли по лестнице, не следует, что она устроена так, как выглядит. Это может быть ошибкой выжившего.
Ещё глубже. Почему это убеждение так устойчиво? Потому что оно удобно устроено в разделении ролей. Есть ступеньки, с которых лестница видна особенно ясно - потому что она ведёт наверх. И есть ступеньки, с которых виден градиент - потому что лестница для других. Тот, кто на подъёме, естественно принимает свою траекторию за общее правило. Это не злой умысел - это угол обзора с той ступеньки, на которой стоишь.
А в основании - простой факт: везде, где одни задают направление, а другие держат вёсла, воспроизводится интерес в том, чтобы сидящие на вёслах спрашивали с себя, а не с тех, кто у руля. Не потому что кто-то плохой человек - а потому что так устроена лодка. Ваш комментарий - не просто мнение. Это голос, который лодка издаёт, когда говорит о себе самой. И он звучит именно так, как должен звучать, - с искренней верой в лестницу.
Именно об этом статья: не о том, что лестницы нет, а о том, что она не для всех настоящая. И чем выше ступенька, тем труднее это заметить - именно потому, что вам она настоящей оказалась. Более того, в следующих статьях я покажу, почему первые ступеньки уже обваливаются под тяжестью наступающих на пятки LLM.
В чём то да - реклама в том, что использование методологии должно упроститься - скилы/промты и кодовая база. Сначала я хотел использовать для себя эту наработку, но полагаю что аналог (и не обязательно настолько методологически точный) обязательно скоро вышел бы.
Также, фабрика не снимает необходимости составления общеупотребимого языка, взаимодействия с доменными экспертами (хоть LLM многое упрощает в плане эволюционного рефакторинга), но снимает часть боллерплейта, который раньше “растворяли”.
В идеале наверное да (да и видно что я описался). Базово, согласен. На практике, далеко не любая инфраструктура позволяет получить SLA 99%, не любые требования могут быть реализованы так, как кто-то хочет, далеко не любую архитектуру можно реализовывать по "политическим" решениям. НФТ напрямую не определяют архитектуру, а являются вводными для принятия архитектурно-важных решений. Надеюсь, что все мы разделяем архитектуру и дизайн системы, в том смысле, что первое - это решения трудоёмкие к изменению, а второе - это все детали решения.
На мой взгляд, смысл CN - в том что если всё реализовано правильно, надёжность дело наживное до определённого момента. Я упомянул про облако, про его ИТ-услуги, про зоны доступности - на мой взгляд, это говорит о заданном вопросе до определённой степени. Хорошая вводная на эту тему в книге указанной в источнике: Облачные архитектуры: разработка устойчивых и экономичных облачных приложений | Лащевски Том, Арора Камаль, Фарр Эрик, Зонуз Пийум | 978-5-4461-1588-4
Метрики реальных проектов уже мне не показать. Да и нет в этом никакой необходимости - все крупные организации делают это одинаково - стенды нагрузочного тестирования, SLA, расследование инцидентов и т.п. Я бы сказал, что надёжность - это как раз НФТ, а не архитектура. Это требование куда больше зависит от процесса и вашей инфраструктуры. Описанное выше - это про T2M, perfomance, slalability в первую очередь.
Один из примеров описывал продукт в котором пользователи росли кратно. Закрученная пружина маркетинга далеко не сразу, но очень скачкообразно привела миллионы новых клиентов. Насколько слышал от коллег, большинство строят свою надёжность от конкретных цифр, после чего по мере роста аудитории, доступность падает, требуется пересмотр решения. Наш ответ на подобное плавающее НФТ заключался в работе над типовым микросервисом и связке его с облаком, ит-услугами, с целью формирования сценариев масштабирования.
С одной стороны, я подумаю как осветить в будущих статьях тему доступности, развивающих описанное выше. С другой стороны, мне казалось что слова CloudNative и облако говорят сами за себя - SLA, OPEX/CAPEX обычно подразумеваются (возможно это мои домыслы).
Тем самым, простите, но косвенно отсылаю вас к другим материалам на тему надёжности, которые фокусируются на методологии.
В РФ другая практика - TOGAF, карты бизнес возможностей, Корп.Модель данных; иными словами "коты и мыши". На мой взгляд, статья не раскрывает этой подоплёки, а она и содержит в себе суть того зачем нужна роль архитектора и какие формы это может принимать в разных обстоятельствах. Например, если взять банки или телекомы - это огромные департаменты, которые юзают свои фреймворки, и очень часто на практике не стремятся быть ближе к бизнесу, а становятся частью внутреннего сервиса (вопросы к пуговицам есть?). Этим самовоспроизводящимся системам не нужны ни гибкие подходы, ни DDD)) Иными словами, вряд ли есть коллективы больше 200 человек, всеобъемлюще применяющие такие подходы.
Вы же почему-то выкидываете из процесса производства часть, относящуюся к разработке, и считаете производством только производство копий
Напротив, я утверждаю, что производство будет выполнено дважды в двух формах; форма цифрового продукта отрицает в иной форме его воспроизведение для пользователя. Т.е. формально процесс производства продукта (товара/услуги) происходит в момент выполнения кода. А вот прообраз этого кода - это другая форма работы.
как агитацию простых решений, которые не требуют больших затрат.
как пропаганду сегрегации ролей в производственном процессе.
И смею думать, что авторов интересовал в этой теме только хайп. Сама же пропаганда коренится в столкновении интересов менеджера и инженера. В одном месте это формулируется как излишняя сложность технического решения, в другом как низкая квалификация программистов и инженеров, в третьем апеллируют к абсолютам. По факту, менеджер всегда преследует задачу оптимальной утилизации ресурсов. И эта статья сильно подыгрывает подобной позиции.
Вы воспроизвели мой ответ, своими словами. Ещё раз, повторю свою мысль, в доказательство непротиворечивости: форма ПО соответствует материальным условиям развития. В какой-то момент, от вашего продукта может потребоваться рост, с разделением монолита, чтобы соответствовать каким-то метрикам.
Интересная мысль про баланс. ИМХО, лиды/архитекторы/owner'ы именно для соблюдения баланса и нужны, именно в движении противоречивых интересов рождаются, выраствют, умирают все продукты)
Уважаемый собеседник, боюсь вы не правильно поняли мою аналогию. Она не в делимости на части, а в сложности применяемого решения. Внешне для пользователя и то и другое будет схоже. Но для производства смартфонов нужна очень сложная производственная база, цепочки поставок, много версий нужно выпустить. Это уже не говоря о инфраструктуре телекомов.
За такими заявлениями явно есть свои интересы!!!) Отрицать МСА - это как не пользоваться смартфоном, а только городским телефоном проводным. Любые сложные системы/подходы/продукты появляются не на ровном месте, не от гения творца, а в ходе длительного развития. Смысл MSA в том что описанные сложности решаются системно, для всего ландшафта сразу, что даёт "эффект масштаба", позволяет применять эту архитектуру. При этом, конечно, имею место предпосылки к развитию архитектуры на ландшафте. Выбор архитектуры программного обеспечения, как формы его развития, тесно связан с реализуемой функциональностью и окружающими обстоятельствами. По мере количественного роста, с одной стороны, реализованных фичей, и, с другой стороны, количества заинтересованных сторон, в движении этих внутренних и внешних факторов, форма программного обеспечения склонна изменяться, выражаясь в новой архитектуре решения. Задача гибкой архитектуры при этом: предвосхитить возможные изменения, производя наиболее адаптируемый к изменениям продукт, приносить заинтересованным сторонам продукт с наиболее высокими потребительскими качествами. Воспроизведу подобный материализм развития:
Монолитное приложение - это продукт, состоящий из нескольких слоёв или уровней, которые можно выделить логически, иногда физически:
Интерфейс;
Логика приложения;
Слой доступа к данным;
База данных.
Многие продукты и процессы начинаются именно с такой формы. По мере усложнения логики, описания всё большего количества процессов, т.е. при изменении содержания, форма также изменяется. 2. Так или иначе, по мере роста и развития приложения, возникают проблемамы монолитных архитектур:
сложность системы постоянно растет;
поддерживать ее все сложнее и сложнее;
разобраться в ней трудно — особенно если система переходила из поколения в поколение, логика - забывалась, люди уходили и приходили, а комментариев и тестов нет);
много ошибок;
мало тестов — монолит не разобрать и не протестировать, поэтому обычно есть только UI-тесты, поддержка которых обычно занимает много времени;
дорого вносить изменения;
застревание на технологиях
Однако, если приложение приносило пользу стейкхолдерам и развивалось, со временем количество пользователей/операций в системе может значительно вырасти. Появиться необходимость масштабировать систему. 3. Чтобы масштабировать систему, снизить время выхода функциональности, повысить отказоустойчивость и доступность, приходят к микросервисам и облакам.
Т.о. есть предпосылки к появлению микросервисной архитектуры: качественный рост количества фич, правок в них, потребителей.
Профсоюз как низовое движение, отстаивающее интересы коллективов - высшая форма демократии, сознательности рабочих. Вы должны способствовать развитию открытого ПО, поднимать вопрос об отмене собственности на ПО, обговаривать условия труда, но профсоюз ведущий диалог с властью про свой свечной заводик - жёлтый профсоюз.
По поводу экосистемы. Наличие/отсутствие таковой прямо коррелирует с местом страны в мир-системе капиталистической экономики. В условиях тотальной глобализации, крупные компании найдут обходные пути получения железа и софта. А если же экосистема будет реализовываться, то, с одной стороны, спонсировать это будет другой пролетарий, на которого ляжет инфляционная и налоговая нагрузка; с другой стороны, правительство может разыграть в любой момент компрадорскую карту, отказавшись от экосистемы, как уже бывало ни раз за 30 лет.
Вам бы не Мишустиным писать, а писать о том что совсем скоро ждёт всех работников IT, раскрывать методологию органайзинга, агитировать за отстаивание своих рабочих прав.
Извините, но вы так дойдете до того, что заявите про то, что было время, когда строительные архитекторы CJM проектировали.
о CJM
CJM не писали, но практику похожую на EventStorming и сбор общеупотребимого языка ВХУТЕМАС и БАУХАУС проводили, вероятно как и последующие архитекторы. На этом фото часть стенда посвящённая столетию ВХУТЕМАСА, про то как обучали студентов важности общения за заитересованными сторонами.
Если или когда найду кокретный анализ для конкретных объектов (такое было, но не всё легко отыскать), обязательно подкреплю к этому ответу.
Я не пытаюсь свою точку зрения навязать, скорее преуменьшить IT как нечто особенное. Правильно смотреть и на здания и на ПО как основной капитал бизнеса (производства). Если смотреть с этой стороны, то разница совсем уж не велика, т.к. и то и другое используется как технические возможности для обеспечения бизнес-процессов.
Для IT-архитекторов, которые «в танке» и любят сравнивать себя с зодчими:
Архитектурный раздел строительного проекта больше относится к внешней, фасадной части. В нём прорабатываются вопросы эстетики, оформления, отделки помещений и всего прочего, с этим связанного.
Вы здессь сразу сузили определение до рамок строительного проекта - корректно ли это? А кто делал проект Москвы-Сити, например? Сейчас чаще всего так и есть, но было время архитекторы проектировали районы и целые города. Сейчас архитектор - дизайнер потому, что строительство исходит не из рациональности, а из профита.
Связь явно есть, иначе професси бы назывались по-разному. В начале XX века перед архитекторами стояли теже вопросы обеспечения гибкости и лучшего пользовательского опыта. Об этом можно прочитать у Ле Карбюзье в "Дом - машина для жилья". Архитекторы уже тогда понимали, что вот эти фасады, стены - это временное - сегодня ДК, а завтра пятёрочка,
Отчасти я с вами соглашусь. Лично я ещё не встречал тех, у кого был бы неискажённый scrum. Если вы по должности аналитик, а по роли доменный эксперт и владелец продукта, но не менеджер, т.е. вы не форсите побольше задач в спринт, не пытаетесь команду заставить спинт закончить на выходных, то у вас интересный случай) завидую вашим коллегам в таком случае! По рассказам у всех всё правильно, но чаще всего желание получить квартальные/годовые бонусы делает аналитиков немного манагерами)
Позволю себе пример из книги Юнга о психологии Бессознательного. В данной работе противопоставляется понимание либидо Фрейда и Адлера, из которых Юнг, применяя диалектику, выводит 2 ортогональные оси: любви и власти.
Затронутый вами вопрос: «инженерия vs психология», на мой взгляд, разрешается схожим образом. Да, это можно назвать мягкими навыками, но только построенными вокруг векторов интересов, а не вокруг эмпатии. Развитие эмоционального интеллекта важная задача (к слову, LLM пытаются с ней рьяно помогать в силу токсичной позитивности), но тут другая задача - выход из конфликта.
Вопрос, к которому я прихожу после синтеза, - вопрос о манипуляциях. В тех случаях, когда собеседник выдаёт плохую коммуникацию за причину, там где повод лежит в области интересов, собственности. Есть немало людей, которые умеют на маниакальном уровне врать, выдавая ложную эмоцию.
Я бы сказал, что это не «инженерия против психологии», а «инженерия + психология против манипуляций», где инженерия - фреймворк, психология от LLM, манипуляция от оппонента.
И да, до эмоций алгоритм не дотягивается - тут я целиком за вами.)
Спасибо за комментарий. Мой ответ будет столь же многослойным
Вы правы, что форма товар/средство производства/средство потребления не нова и описана у классиков. Вопрос, который я пытался поставить - возможно ли, что один и тот же объект выступает во всех трёх ипостасях одновременно для разных экономических агентов, и что это меняет характер присвоения? Автобус не является средством потребления для пассажира в том же смысле, как LLM для пользователя ChatGPT, т.е. вы упускаете метаморфозу средства потребления в средство производства. Автобус ничего не производит - это инструмент водителя. А проектор в кинотеатре как раз воспроизводит фильм. Кинофильм при этом “не затрётся до дыр” на носителе, чего не избежать автобусу.
В литературе есть несколько параллельных попыток, например, algorithmic surplus value, Grammenos.
В Критике политической экономии эта тема не раскрыта ни потому, что её нет, а потому что она была в зачаточном состоянии. Патенты, авторское право, ранние формы авторских отчислений - всё это были «сырые» отношения. Автор знаменитой работы гениально проанализировал формальное и реальное подчинение труда капиталу на материале фабрики XIX века. Но у него не было перед глазами IBM PC, интернета и GitHub’а. Анализ виртуального товара - это не ревизия, а развитие метода исторического материализма на новом, не существовавшем ранее эмпирическом материале. LLM замещает интеллектуальный, творческий труд, который считался «незаменимым» при классиках. И замещает его трудом, обученным на продуктах самого работника. Это не просто «машина». Это имитация живого труда мёртвым трудом. Это репликация способности к творчеству, а не только физической силы.
Классики безусловно сказали очень много. В тоже самое время, как мне кажется, намеренно не отливали себе бронзовых статуй, но сформулировали метод.
Спасибо за внимание к статье!
Есть вероятность, что эксперт, отвечающий на вопрос уже знаком с ней или аналогом. Поэтому я пока двигался в сторону мета-уроков (промты в репозитории). Надеюсь, получится прийти к мета-шаблонам “смены парадигмы”.
Буду благодарен, если расскажете о результатах!
Спасибо. Это, пожалуй, самый важный комментарий из возможных — потому что он вскрывает именно ту границу, на которой мой фреймворк перестаёт быть «инструментом победы» и становится «инструментом диагностики».
Вы описали ситуацию, где:
дисбаланс власти закреплён не только между отделами, но и между сотрудником и его руководителем;
руководитель не защищает, а использует вашу энергию как ресурс для своей репутации;
любые попытки конструктивного диалога будут восприняты не как паритет, а как сигнал «здесь можно ехать».
В такой конфигурации фреймворк не даст вам выиграть конфликт. Но он даст другое: трезвость. Он покажет, что проблема не в вашей «плохой коммуникации», а в структурном перекосе. Что вы не «не смогли договориться», а оказались в игре, где правила писала другая сторона - и она же судит. Это не снимает боли, но снимает самообвинение. А это уже немало. Чем больше итераций (ситуаций), тем лучше ваша карта описывает ландшафт этого самого структурного перекоса - возможно какие-то горы можно обойти.
Зачем я сделал этот фреймворк? для того чтобы видеть все возможные исходы, оценить возможность смены парадигмы, последствия того или иного выбора. Например, как-то готовился к сложному диалогу, и провёл 63 итерации моделирования - от простых до самых циничных. Да, LLM уступает нам в смекалке, а ситуации могут быть очень сложные. Тем ценнее возможность подготовиться - это точно лишит любых сожалений “если бы”.
Возможно, этим мечом не прорубить стену прессинга и систематического использования вашей энергии для чужой карьеры, но и совсем без защиты он не оставит.
Иван, давайте разбирать по слоям.
Вы говорите: «статья смещает фокус на внешний локус контроля, а это вредно». Но это спор не о фактах, а о том, как правильно смотреть. Исследования локуса контроля показывают корреляцию с личным успехом - но они не показывают, что структуры не существует. Если вы попали в шторм, внутренний локус поможет грести, но не отменит волн. Статья - про волны, про «корпоративную рябь».
Теперь глубже. Почему вообще возник спор о том, как «правильно» смотреть? Потому что за этим стоит убеждение: лестница настоящая. Тот, кто поднялся, склонен верить, что подъём был честным. Это понятно по-человечески, но ваша уверенность - это убеждение, а не анализ. Из того, что вы прошли по лестнице, не следует, что она устроена так, как выглядит. Это может быть ошибкой выжившего.
Ещё глубже. Почему это убеждение так устойчиво? Потому что оно удобно устроено в разделении ролей. Есть ступеньки, с которых лестница видна особенно ясно - потому что она ведёт наверх. И есть ступеньки, с которых виден градиент - потому что лестница для других. Тот, кто на подъёме, естественно принимает свою траекторию за общее правило. Это не злой умысел - это угол обзора с той ступеньки, на которой стоишь.
А в основании - простой факт: везде, где одни задают направление, а другие держат вёсла, воспроизводится интерес в том, чтобы сидящие на вёслах спрашивали с себя, а не с тех, кто у руля. Не потому что кто-то плохой человек - а потому что так устроена лодка. Ваш комментарий - не просто мнение. Это голос, который лодка издаёт, когда говорит о себе самой. И он звучит именно так, как должен звучать, - с искренней верой в лестницу.
Именно об этом статья: не о том, что лестницы нет, а о том, что она не для всех настоящая. И чем выше ступенька, тем труднее это заметить - именно потому, что вам она настоящей оказалась. Более того, в следующих статьях я покажу, почему первые ступеньки уже обваливаются под тяжестью наступающих на пятки LLM.
Спасибо за вашу оценку!
Абсолютно согласен с вами, только дополнив по теме ИИ - на мой взгляд, сейчас не обойтись без небольшой команды “допила”. Но это дело времени.
Добрый день!
В чём то да - реклама в том, что использование методологии должно упроститься - скилы/промты и кодовая база. Сначала я хотел использовать для себя эту наработку, но полагаю что аналог (и не обязательно настолько методологически точный) обязательно скоро вышел бы.
Также, фабрика не снимает необходимости составления общеупотребимого языка, взаимодействия с доменными экспертами (хоть LLM многое упрощает в плане эволюционного рефакторинга), но снимает часть боллерплейта, который раньше “растворяли”.
Спасибо за оценку и ваш совет!
В идеале наверное да (да и видно что я описался). Базово, согласен. На практике, далеко не любая инфраструктура позволяет получить SLA 99%, не любые требования могут быть реализованы так, как кто-то хочет, далеко не любую архитектуру можно реализовывать по "политическим" решениям. НФТ напрямую не определяют архитектуру, а являются вводными для принятия архитектурно-важных решений. Надеюсь, что все мы разделяем архитектуру и дизайн системы, в том смысле, что первое - это решения трудоёмкие к изменению, а второе - это все детали решения.
На мой взгляд, смысл CN - в том что если всё реализовано правильно, надёжность дело наживное до определённого момента. Я упомянул про облако, про его ИТ-услуги, про зоны доступности - на мой взгляд, это говорит о заданном вопросе до определённой степени. Хорошая вводная на эту тему в книге указанной в источнике: Облачные архитектуры: разработка устойчивых и экономичных облачных приложений | Лащевски Том, Арора Камаль, Фарр Эрик, Зонуз Пийум | 978-5-4461-1588-4
Метрики реальных проектов уже мне не показать. Да и нет в этом никакой необходимости - все крупные организации делают это одинаково - стенды нагрузочного тестирования, SLA, расследование инцидентов и т.п. Я бы сказал, что надёжность - это как раз НФТ, а не архитектура. Это требование куда больше зависит от процесса и вашей инфраструктуры. Описанное выше - это про T2M, perfomance, slalability в первую очередь.
Один из примеров описывал продукт в котором пользователи росли кратно. Закрученная пружина маркетинга далеко не сразу, но очень скачкообразно привела миллионы новых клиентов. Насколько слышал от коллег, большинство строят свою надёжность от конкретных цифр, после чего по мере роста аудитории, доступность падает, требуется пересмотр решения. Наш ответ на подобное плавающее НФТ заключался в работе над типовым микросервисом и связке его с облаком, ит-услугами, с целью формирования сценариев масштабирования.
С одной стороны, я подумаю как осветить в будущих статьях тему доступности, развивающих описанное выше. С другой стороны, мне казалось что слова CloudNative и облако говорят сами за себя - SLA, OPEX/CAPEX обычно подразумеваются (возможно это мои домыслы).
Тем самым, простите, но косвенно отсылаю вас к другим материалам на тему надёжности, которые фокусируются на методологии.
В РФ другая практика - TOGAF, карты бизнес возможностей, Корп.Модель данных; иными словами "коты и мыши". На мой взгляд, статья не раскрывает этой подоплёки, а она и содержит в себе суть того зачем нужна роль архитектора и какие формы это может принимать в разных обстоятельствах. Например, если взять банки или телекомы - это огромные департаменты, которые юзают свои фреймворки, и очень часто на практике не стремятся быть ближе к бизнесу, а становятся частью внутреннего сервиса (вопросы к пуговицам есть?). Этим самовоспроизводящимся системам не нужны ни гибкие подходы, ни DDD)) Иными словами, вряд ли есть коллективы больше 200 человек, всеобъемлюще применяющие такие подходы.
Про DDD и архитекторов много референсов, но в крупных компаниях его убивают архитекторы, а небольших нет системной работы над архитектурой.
Напротив, я утверждаю, что производство будет выполнено дважды в двух формах; форма цифрового продукта отрицает в иной форме его воспроизведение для пользователя. Т.е. формально процесс производства продукта (товара/услуги) происходит в момент выполнения кода. А вот прообраз этого кода - это другая форма работы.
Позволю себе больше, определю эту статью
как агитацию простых решений, которые не требуют больших затрат.
как пропаганду сегрегации ролей в производственном процессе.
И смею думать, что авторов интересовал в этой теме только хайп. Сама же пропаганда коренится в столкновении интересов менеджера и инженера. В одном месте это формулируется как излишняя сложность технического решения, в другом как низкая квалификация программистов и инженеров, в третьем апеллируют к абсолютам. По факту, менеджер всегда преследует задачу оптимальной утилизации ресурсов. И эта статья сильно подыгрывает подобной позиции.
Вы воспроизвели мой ответ, своими словами.
Ещё раз, повторю свою мысль, в доказательство непротиворечивости: форма ПО соответствует материальным условиям развития. В какой-то момент, от вашего продукта может потребоваться рост, с разделением монолита, чтобы соответствовать каким-то метрикам.
Интересная мысль про баланс. ИМХО, лиды/архитекторы/owner'ы именно для соблюдения баланса и нужны, именно в движении противоречивых интересов рождаются, выраствют, умирают все продукты)
Уважаемый собеседник, боюсь вы не правильно поняли мою аналогию. Она не в делимости на части, а в сложности применяемого решения. Внешне для пользователя и то и другое будет схоже. Но для производства смартфонов нужна очень сложная производственная база, цепочки поставок, много версий нужно выпустить. Это уже не говоря о инфраструктуре телекомов.
За такими заявлениями явно есть свои интересы!!!)
Отрицать МСА - это как не пользоваться смартфоном, а только городским телефоном проводным.
Любые сложные системы/подходы/продукты появляются не на ровном месте, не от гения творца, а в ходе длительного развития.
Смысл MSA в том что описанные сложности решаются системно, для всего ландшафта сразу, что даёт "эффект масштаба", позволяет применять эту архитектуру. При этом, конечно, имею место предпосылки к развитию архитектуры на ландшафте.
Выбор архитектуры программного обеспечения, как формы его развития, тесно связан с реализуемой функциональностью и окружающими обстоятельствами. По мере количественного роста, с одной стороны, реализованных фичей, и, с другой стороны, количества заинтересованных сторон, в движении этих внутренних и внешних факторов, форма программного обеспечения склонна изменяться, выражаясь в новой архитектуре решения.
Задача гибкой архитектуры при этом: предвосхитить возможные изменения, производя наиболее адаптируемый к изменениям продукт, приносить заинтересованным сторонам продукт с наиболее высокими потребительскими качествами.
Воспроизведу подобный материализм развития:
Монолитное приложение - это продукт, состоящий из нескольких слоёв или уровней, которые можно выделить логически, иногда физически:
Интерфейс;
Логика приложения;
Слой доступа к данным;
База данных.
Многие продукты и процессы начинаются именно с такой формы. По мере усложнения логики, описания всё большего количества процессов, т.е. при изменении содержания, форма также изменяется.
2. Так или иначе, по мере роста и развития приложения, возникают проблемамы монолитных архитектур:
сложность системы постоянно растет;
поддерживать ее все сложнее и сложнее;
разобраться в ней трудно — особенно если система переходила из поколения в поколение, логика - забывалась, люди уходили и приходили, а комментариев и тестов нет);
много ошибок;
мало тестов — монолит не разобрать и не протестировать, поэтому обычно есть только UI-тесты, поддержка которых обычно занимает много времени;
дорого вносить изменения;
застревание на технологиях
Однако, если приложение приносило пользу стейкхолдерам и развивалось, со временем количество пользователей/операций в системе может значительно вырасти. Появиться необходимость масштабировать систему.
3. Чтобы масштабировать систему, снизить время выхода функциональности, повысить отказоустойчивость и доступность, приходят к микросервисам и облакам.
Т.о. есть предпосылки к появлению микросервисной архитектуры: качественный рост количества фич, правок в них, потребителей.
Профсоюз как низовое движение, отстаивающее интересы коллективов - высшая форма демократии, сознательности рабочих. Вы должны способствовать развитию открытого ПО, поднимать вопрос об отмене собственности на ПО, обговаривать условия труда, но профсоюз ведущий диалог с властью про свой свечной заводик - жёлтый профсоюз.
По поводу экосистемы. Наличие/отсутствие таковой прямо коррелирует с местом страны в мир-системе капиталистической экономики. В условиях тотальной глобализации, крупные компании найдут обходные пути получения железа и софта. А если же экосистема будет реализовываться, то, с одной стороны, спонсировать это будет другой пролетарий, на которого ляжет инфляционная и налоговая нагрузка; с другой стороны, правительство может разыграть в любой момент компрадорскую карту, отказавшись от экосистемы, как уже бывало ни раз за 30 лет.
Вам бы не Мишустиным писать, а писать о том что совсем скоро ждёт всех работников IT, раскрывать методологию органайзинга, агитировать за отстаивание своих рабочих прав.
о CJM
Если или когда найду кокретный анализ для конкретных объектов (такое было, но не всё легко отыскать), обязательно подкреплю к этому ответу.
Я не пытаюсь свою точку зрения навязать, скорее преуменьшить IT как нечто особенное. Правильно смотреть и на здания и на ПО как основной капитал бизнеса (производства). Если смотреть с этой стороны, то разница совсем уж не велика, т.к. и то и другое используется как технические возможности для обеспечения бизнес-процессов.
Вы здессь сразу сузили определение до рамок строительного проекта - корректно ли это? А кто делал проект Москвы-Сити, например? Сейчас чаще всего так и есть, но было время архитекторы проектировали районы и целые города. Сейчас архитектор - дизайнер потому, что строительство исходит не из рациональности, а из профита.
Связь явно есть, иначе професси бы назывались по-разному. В начале XX века перед архитекторами стояли теже вопросы обеспечения гибкости и лучшего пользовательского опыта. Об этом можно прочитать у Ле Карбюзье в "Дом - машина для жилья". Архитекторы уже тогда понимали, что вот эти фасады, стены - это временное - сегодня ДК, а завтра пятёрочка,
Отчасти я с вами соглашусь. Лично я ещё не встречал тех, у кого был бы неискажённый scrum. Если вы по должности аналитик, а по роли доменный эксперт и владелец продукта, но не менеджер, т.е. вы не форсите побольше задач в спринт, не пытаетесь команду заставить спинт закончить на выходных, то у вас интересный случай) завидую вашим коллегам в таком случае!
По рассказам у всех всё правильно, но чаще всего желание получить квартальные/годовые бонусы делает аналитиков немного манагерами)