Архитектура ИС. Страница 12
4563
@it_arch
Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений, микросервисы).
-
Архитектура ИС
Не важно, какой именно формат архитектурных решений использовать – MADR с картинки над сообщением или какой-то другой. Практически любой шаблон ADR представляет собой ещё и чек-лист для самопроверки: какую задачу мы решаем, рассмотрели ли альтернативные варианты, видим ли негативные последствия решения или зациклились только на позитивных и т.д. Кстати, еще одна ссылка к вебинару - обзор истории ADR от Olaf Zimmermann (ZIO) ozimmer.ch/practic…ing.html 
-
Архитектура ИС
Закон Конвея. Перевод статьи «How Do Committees Invent?» Так как статья – не художественное произведение, да еще и написана в далеком 1968 году, ее перевод может (да, наверное, и должен) восприниматься как весьма косноязычный и местами непонятный, но так уж излагали мысли ученые в 68-м. Посчитал, что для научной статьи адаптивный перевод может привести к потере смыслов (хотя и понимаю, что на русском языке смысл может исказиться). Всячески рекомендую оригинал (ссылка в конце статьи), а переводом пользоваться только в том случае, если недостаточно знаний английского. http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/ Несколько цитат: 👉«никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново» «Каждый раз, когда осуществляется делегирование и сужается чья-то область исследования, также сужается и класс вариантов решений по проектированию, которые могут быть эффективно реализованы.» «Как только определены сферы деятельности, возникает проблема координации. Координация между рабочими группами, хотя и снижает продуктивность отдельных сотрудников в небольшой группе, обеспечивает единственную возможность того, что отдельные рабочие группы смогут объединить свои усилия в единую систему.» «осознание первоначальными проектировщиками того, что система будет большой, вместе с определенным давлением в организации делает непреодолимым искушение назначить для разработки дизайна слишком много людей» «Менеджер должен отдать в субподряд важную и сложную задачу по проектированию. Он выбирает между двумя подрядчиками: небольшой новой организацией, которая предлагает интуитивно привлекательный подход за гораздо меньшие, чем заложено в бюджете, деньги, и давно зарекомендовавшей себя, но традиционной организацией, которая требует более «реалистичную» плату. Он знает, что, если яркая молодая организация не сможет добиться достаточных результатов, его обвинят в неумелом управлении, а если потерпит неудачу проверенная организация, это будет доказательством того, что проблема действительно сложна. В чем тут сложность? Большая ее часть относится к рассуждениям об измерении ресурсов, вытекающим из традиционной теории бухгалтерского учета. Согласно этой теории, единицей ресурса является доллар, и все ресурсы должны измеряться с использованием единиц измерения, конвертируемых в доллары. Если ресурсом является человеческий труд, единицей измерения является количество часов, отработанных каждым человеком, умноженное на его почасовую ставку, суммированные для всей рабочей силы. Одним из заблуждений, лежащих в основе этого расчета, является свойство линейности, согласно которому два человека, работающие в течение года, или сто человек, работающие в течение недели (при одинаковых почасовых ставках на человека), являются ресурсами равной ценности. Если предположить, что два человека и сто человек не могут работать в одной и той же организационной структуре (это интуитивно очевидно и будет обсуждаться ниже), наш гомоморфизм говорит, что они не будут проектировать подобные системы; поэтому ценность их усилий может быть даже несопоставимой. По опыту мы знаем, что два человека, если они правильно подобраны и имеют нужный опыт, дадут нам лучшую систему. Предположения, которые могут быть достаточными для чистки картошки и возведения кирпичных стен, не годятся для проектирования систем.» «Даже в умеренно небольшой организации возникает необходимость ограничить общение, чтобы люди могли выполнить какую-то «работу».» «Необходима философия управления дизайном систем, которая не основывается на предположении, что простое добавление рабочей силы повышает производительность.» – Закон Конвея именно об этом, хоть и звучит как «организация, проектирующая систему (в принятом здесь широком смысле), производит дизайн, являющийся копией коммуникационных структур этой организации» -
Архитектура ИС
12 определений Cloud-Native приложений ozimmer.ch/index/2…sis.html -
Реклама
-
Архитектура ИС
Я редко стал заходить на InfoQ Когда-то это был интересный ресурс, но всё рано или поздно заканчивается. Но вот сегодня я туда заглянул и тут же обнаружил вот это: www.infoq.com/article…ven-fail Думаю, что еще лет десять одни люди будут писать разные глупости и умности, предостерегая других людей от микросервисов. Время начинать изучать это в качестве культурного феномена -
Архитектура ИС
Добавил много ссылок, связанных с записями архитектурных решений (architecture decision record), к видео вебинара, прошедшего в сентябре 2019 года https://youtu.be/9vtf33NIJrE -
Архитектура ИС
Вот мы и перешагнули еще одну скромную отметку в 7000 подписчиков. Спасибо всем, кто помогает каналу и тем кто просто его читает! Приглашайте подписаться коллег и друзей и сами оставайтесь на связи! 
-
Архитектура ИС
Вчера заглянул на гартнеровский вебинар (слайды здесь). Удивился, что Gartner проводит вебинары на русском, да еще такие толковые. И дело даже не в том, что компонуемость (это один из трендов 2022 года) оказалась, в первую очередь, бизнес/ИТ характеристикой организации. Компонуемость эту самую оказывается можно прокачивать благодаря улучшению перечисленных в презентации практик. Важнее, что потребность в ней возникает из-за разрушения монополии ИТ-отдела на производство ИТ-решений. Вот это вот мега-тренд! Я касался его в вебинаре Что ждет архитектора решений? В двух словах: все мы находимся в процессе замены функциональных и технологических силосов продуктовыми. Это главная история. И это главное следствие цифровой трансформации. Ну и слайд №20 (см. рисунок) просто великолепен 
-
Архитектура ИС
Продолжая рассматривать описания архитектур с O'Reilly Architectural Kata, обнаружил и с интересом полистал презентацию Нила Форда с kickoff вторых кат прошлого года. tekiegirl.github.io/Archang…-off.pdf (Описание победителей этих кат здесь: https://tekiegirl.github.io/Archangels/) -
Архитектура ИС
Сейчас я понимаю, что вчера не следовало задавать этот вопрос :) Тем не менее, за ответы большое спасибо! -
Архитектура ИС
По-моему, канал стал слишком серьезным. Так что сегодня пятничный пост - должен ли архитектор читать код? 
-
Архитектура ИС
Ilograph – одна из немногих компаний, которая может позволить себе писать в блоге такие вот философские рассуждения о моделировании Why Do We Create System Architecture Diagrams Anyway? Да еще ссылаться в них на работы по нейрофизиологии Почему? Ну, просто у них есть движок, позволяющий не только в виде псевдокода описывать модель системы, но и потом нарезать её на набор представлений (там это называется перспективы), а еще «зумить» отображение выделяя последовательности вызовов (транзитивные отношения) и т.д. В общем, с таким инструментом можно чуть-чуть и поумничать -
Архитектура ИС
Нашел в своем блоге заметку Интеграция новых приложений в корпоративный ИТ-ландшафт о том, зачем нужна архитектура ИТ-решений (Solution Architecture), на какие пять вопросов она отвечает. Посмотрел на дату - январь 2012, десять лет прошло! А вопросы все актуальны по-прежнему -
Архитектура ИС
Полгода назад у Фаулера появился цикл статей под общей темой Patterns of Legacy Displacement Кроме основного текста martinfowler.com/article…lacement это еще набор небольших заметок, возникающих по мере необходимости. В январе 2022 появились следующие три: - Legacy Mimic - Critical Aggregator - Divert the Flow Работа с унаследованными приложениями – одна из ключевых компетенций корпоративного ИТ-архитектора. А закономерный (как мы узнали из серии статей :) провал программы модернизации таких приложений – основной профессиональный риск. Я далек от мысли, что авторы цикла (James Lewis и др.) уже обнаружили универсальное лекарство от legacy, но направление мне представляется вполне верным -
Архитектура ИС
Наш канал не участвует в рекламных ротациях и не рассылает вам длинные списки ссылок на разные невнятные каналы. Куда честнее просто иногда взять и поделиться ссылкой на дружественный канал. Сегодня, например, на https://t.me/ba_and_sa Business | System analyst Канал для бизнес/системных аналитиков, как для начинающих, так и для бывалых. Выкладываем статьи (также зарубежные), видео, новости, юмор)) Сотрудничество: @the_real_bird Канал для ИТ-аналитиков: @analysis_it Чаты: @saba_hunter
-
Архитектура ИС
Предупреждение! Сегодня вечер активности ботов. Из разных архитектурных групп (преимущественно из "Работа для ИТ-архитекторов") боты атакуют подписчиков личными сообщениями. Будьте осторожны! Блокируйте запросы от подозрительных аккаунтов. Сообщайте о вражеских происках. Не поддавайтесь на провокации 
-
Реклама
-
Архитектура ИС
The Future history of data engineering [1] активно цитируемый сейчас текст от Matt Arderne в котором он описывает развитие текущих платформ по инженерии данных и их будущее. Рассуждения интересные, практические и автор пишет про новое понятие и роль Data Platform Engineer (DPE). Это инженер данных который знает как устроены платформы для работы с данными и знает как правильно их применять для конкретых, как правило сложных, случаях. Ссылки: [1] https://groupby1.substack.com/p/data-engineering #data #readings #dataenginering -
Архитектура ИС
Поделюсь и я ссылкой на этот интересный текст с осмыслением текущей позиции инженерии и инженера данных 
-
Архитектура ИС
Очень большой текст Principles of technical documentation www.innoq.com/en/arti…entation, возвращающий нас во времена хороших требований из легендарного IEEE-830. Тем не менее, этот текст достоин прочтения, как пример проработанного текста с одной стороны и нелишнего повторения банальностей, типа: Automation won’t improve your content - с другой