Получи случайную криптовалюту за регистрацию!

Архитектура ИТ-решений

Логотип телеграм канала @it_arch — Архитектура ИТ-решений А
Логотип телеграм канала @it_arch — Архитектура ИТ-решений
Адрес канала: @it_arch
Категории: Технологии
Язык: Русский
Количество подписчиков: 11.24K
Описание канала:

Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений, микросервисы).
-
Блог: https://mxsmirnov.com

Рейтинги и Отзывы

3.00

3 отзыва

Оценить канал it_arch и оставить отзыв — могут только зарегестрированные пользователи. Все отзывы проходят модерацию.

5 звезд

1

4 звезд

0

3 звезд

1

2 звезд

0

1 звезд

1


Последние сообщения 8

2022-03-21 15:45:12 Спасибо за большое количество отзывов на такую маленькую заметку. Было бы ошибкой с моей стороны попробовать ответить на все комментарии сразу, т.к. они очень разные. Постараюсь сделать это постепенно. Начну, пожалуй, со сложности https://t.me/c/1304614627/18955

Во-первых, поделюсь ссылкой на перевод старого, но всё еще актуального текста Ефима Натиса Покорение сложности ИТ Удивительно, но ссылки на этот легендарный текст в этом канале до сих пор не было.
Во-вторых, уже от себя замечу, что разные виды сложности можно и нужно различать. Есть сложность реальная, проистекающая из большой вариативности объектов, отношений и вариантов развития событий. Есть сложность невынужденная, связанная с выбором не самого подходящего варианта реализации. А еще бывает сложность мифологическая. Примером такой сложности является популярная в своё время история о том, что интеграция точка-точка проигрывает интеграции через серверную шину. Вообще, любые комбинаторные предположения должны нас насторожить. В реальности интегрировать все системы со всеми никто и не собирался. Это просто не требуется. Сейчас похожий сюжет используют в страшилках про сложность взаимодействия между микросервисами в топологии каждый с каждым. Зачем бы это понадобилось сказать сложно, но выглядит вполне пугающе
4.4K views12:45
Открыть/Комментировать
2022-03-21 06:52:27
В далеком 1987-м Джон Захман предложил любую модель системы причислять к одному из трех фундаментальных типов: описание данных, описание функций или описание физической структуры системы.

Cловом архитектура обычно обозначают модели третьего типа. А вот решение о выделении фрагмента системы в отдельный модуль завязано на элементах моделей первых двух. Модуль включает в себя либо некоторый набор данных, либо некоторый набор функций.
Не так уж всё и сложно, правда?
4.4K viewsedited  03:52
Открыть/Комментировать
2022-03-18 08:45:15 Обнаружил, что в январе 2022 The Open Group выпустило руководство о том, как делать микросервисы по TOGAF ADM. https://publications.opengroup.org/togaf-library/g21i Вот прям по тупо по процессу, со всеми фазами: бизнес-архитектура, архитектура данных и т.д. На 50 страниц руководство.

Сначала мне показалось это бредом, но потом я решил еще немного почитать и подумать. Вдруг есть в этом тот или иной смысл?
7.8K views05:45
Открыть/Комментировать
2022-02-21 06:47:05
Добавил много ссылок, связанных с записями архитектурных решений (architecture decision record), к видео вебинара, прошедшего в сентябре 2019 года

2.1K views03:47
Открыть/Комментировать
2022-02-18 08:12:29 Закон Конвея. Перевод статьи «How Do Committees Invent?»

Так как статья – не художественное произведение, да еще и написана в далеком 1968 году, ее перевод может (да, наверное, и должен) восприниматься как весьма косноязычный и местами непонятный, но так уж излагали мысли ученые в 68-м. Посчитал, что для научной статьи адаптивный перевод может привести к потере смыслов (хотя и понимаю, что на русском языке смысл может исказиться). Всячески рекомендую оригинал (ссылка в конце статьи), а переводом пользоваться только в том случае, если недостаточно знаний английского.

http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/

Несколько цитат:

«никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново»

«Каждый раз, когда осуществляется делегирование и сужается чья-то область исследования, также сужается и класс вариантов решений по проектированию, которые могут быть эффективно реализованы.»

«Как только определены сферы деятельности, возникает проблема координации.  Координация между рабочими группами, хотя и снижает продуктивность отдельных сотрудников в небольшой группе, обеспечивает единственную возможность того, что отдельные рабочие группы смогут объединить свои усилия в единую систему.»

«осознание первоначальными проектировщиками того, что система будет большой, вместе с определенным давлением в организации делает непреодолимым искушение назначить для разработки дизайна слишком много людей»

«Менеджер должен отдать в субподряд важную и сложную задачу по проектированию. Он выбирает между двумя подрядчиками: небольшой новой организацией, которая предлагает интуитивно привлекательный подход за гораздо меньшие, чем заложено в бюджете, деньги, и давно зарекомендовавшей себя, но традиционной организацией, которая требует более «реалистичную» плату. Он знает, что, если яркая молодая организация не сможет добиться достаточных результатов, его обвинят в неумелом управлении, а если потерпит неудачу проверенная организация, это будет доказательством того, что проблема действительно сложна.

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

Одним из заблуждений, лежащих в основе этого расчета, является свойство линейности, согласно которому два человека, работающие в течение года, или сто человек, работающие в течение недели (при одинаковых почасовых ставках на человека), являются ресурсами равной ценности. Если предположить, что два человека и сто человек не могут работать в одной и той же организационной структуре (это интуитивно очевидно и будет обсуждаться ниже), наш гомоморфизм говорит, что они не будут проектировать подобные системы; поэтому ценность их усилий может быть даже несопоставимой. По опыту мы знаем, что два человека, если они правильно подобраны и имеют нужный опыт, дадут нам лучшую систему. Предположения, которые могут быть достаточными для чистки картошки и возведения кирпичных стен, не годятся для проектирования систем.»

«Даже в умеренно небольшой организации возникает необходимость ограничить общение, чтобы люди могли выполнить какую-то «работу».»

«Необходима философия управления дизайном систем, которая не основывается на предположении, что простое добавление рабочей силы повышает производительность.» – Закон Конвея именно об этом, хоть и звучит как «организация, проектирующая систему (в принятом здесь широком смысле), производит дизайн, являющийся копией коммуникационных структур этой организации»
2.5K views05:12
Открыть/Комментировать
2022-02-16 07:37:02 Запись здесь:

1.2K views04:37
Открыть/Комментировать
2022-02-15 19:28:27 Я редко стал заходить на InfoQ Когда-то это был интересный ресурс, но всё рано или поздно заканчивается. Но вот сегодня я туда заглянул и тут же обнаружил вот это: https://www.infoq.com/articles/microservices-seven-fail/ Думаю, что еще лет десять одни люди будут писать разные глупости и умности, предостерегая других людей от микросервисов. Время начинать изучать это в качестве культурного феномена
2.0K views16:28
Открыть/Комментировать
2022-02-12 09:37:19 Добавил много ссылок, связанных с записями архитектурных решений (architecture decision record), к видео вебинара, прошедшего в сентябре 2019 года

3.4K views06:37
Открыть/Комментировать
2022-02-10 15:11:34
Вот мы и перешагнули еще одну скромную отметку в 7000 подписчиков. Спасибо всем, кто помогает каналу и тем кто просто его читает!

Приглашайте подписаться коллег и друзей и сами оставайтесь на связи!
3.5K views12:11
Открыть/Комментировать
2022-02-09 07:46:53
Вчера заглянул на гартнеровский вебинар (слайды здесь). Удивился, что Gartner проводит вебинары на русском, да еще такие толковые. И дело даже не в том, что компонуемость (это один из трендов 2022 года) оказалась, в первую очередь, бизнес/ИТ характеристикой организации. Компонуемость эту самую оказывается можно прокачивать благодаря улучшению перечисленных в презентации практик.

Важнее, что потребность в ней возникает из-за разрушения монополии ИТ-отдела на производство ИТ-решений. Вот это вот мега-тренд! Я касался его в вебинаре Что ждет архитектора решений? В двух словах: все мы находимся в процессе замены функциональных и технологических силосов продуктовыми. Это главная история. И это главное следствие цифровой трансформации.

Ну и слайд №20 (см. рисунок) просто великолепен
1.8K viewsedited  04:46
Открыть/Комментировать