Архитектура ИТ-решений
15.9K subscribers
330 photos
2 videos
34 files
1.21K links
Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений).

Регистрация в перечне РКН: https://knd.gov.ru/license?id=6735f4cd97de7d1d1953c457&registryType=bloggersPermission
Download Telegram
Пропустил историю о том, как Нил Форд и Марк Ричардс занялись [пере]осмыслением темы Architecture as code. В феврале они провели подкаст в котором упомянули, что пишут новую книгу с тем же названием, а в конце июня собираются провести двухдневный курс Architecture as Code

В подкасте речь шла о разработке некоторого легковесного Architecture Description Language и комментариям почему это не model-driven architecture и как такой ADL поможет в разработке полезных фитнес-функций. Темы курса вроде бы несколько шире, но думаю речь пойдет примерно о том же. Возможно, термин architecture mesh из подкаста тоже всплывет.

Я не услышал чего-то действительно интересного, прорывного в разговоре этих знаменитых авторов. Но, быть может, им удастся вдохновить на изобретение чего-то подобного кого-либо из своих многочисленных читателей и слушателей
👍207
Когда речь заходит о записях архитектурных решений (architecture decision records, ADR) часто возникает вопрос: где посмотреть реальный пример? Вот чтоб в проекте более-менее долго фиксировались решения, уточнялись, пересматривались и т.п.
... и тут все обычно начинают мяться, вспоминают про NDA

Из открытых проектов я бы предложил посмотреть как это ведется в NATS, см. NATS Architecture And Design Если у кого-то есть еще примеры, то непременно поделитесь, плз.
👍4215
Все знают, что я люблю делиться стостраничными презентациями Алана Максуиней – автора первой толстой книжки о Solution Architecture. В июне он порадовал нас новым слайдсетом Application Of The Function- Behaviour-Structure (FBS) Design Framework To IT Architecture Designs на мой взгляд, и на этот раз есть на что посмотреть и над чем подумать
👍23🔥52
Поделюсь недавней заметкой Дика Доуделла Rethinking Technical Debt, основная идея которой в том, что техдолг является скорее системной проблемой, а не просто изъяном, возникающем при неправильной доработке кода. И решаем мы эту проблему неверными способами
Forget the metaphor for a second. Technical debt isn’t just a design compromise or a lack of refactoring time. It’s a structural imbalance that arises when systems evolve without coherent patterns.

Причины дисбаланса по мнению автора:
- чрезмерное увлечение «лучшими практиками». Agile церемонии, TDD, микросервисы, CQRS, dependency injection etc. не заменяют архитектуру. Нельзя исправить ошибки декомпозиции: правильное определение границ между компонентами и взаимодействий, улучшая то, что находится внутри компонент
- иерархические вызовы вместо разработки bindable (связываемые, подключаемые) компонент
- … и отсутствие "модерации сообщений" (отдельный текст Дика The Magic of Message Moderation)
- шараханье от единственного монолита к хаосу случайных микросервисов вместо развертывания, называемого автором service nodes. Я бы назвал это осмысленным развертыванием
...

Ну а заканчивает автор замечанием, что это не фантазия или мечта, а реализуемая его командой реальность и что The architecture resists debt by design

Подытожу: идея переосмыслить источники технического долга мне точно нравится
👍2310🤔9🔥5
Please open Telegram to view this post
VIEW IN TELEGRAM
8🤔4👍2💯1
Архитектура ИТ-решений
Предварительные итоги опроса (1204 голоса) с исправленной ошибкой :)
👍225🔥1
Forwarded from Another Tech Product
#архитектура

Выложили видосы по архитектуре с прошлых конференций

Роман Цирульников - Основы архитектуры систем

Максим Смирнов - Как показать ценность проектирования ИТ-решений

Кирилл Ветчинкин - Как DDD и Event Storming помогает декомпозиции на сервисы

Никита Ерилин - Где тонко, там порвётся: считаем нагрузку и подстилаем соломку
👍36🥱62👎1
25 комментариев к предыдущим постам сообщали об использовании Archimate или удивлялись его отсутствию в опросе. Я думаю, что Archimate это вообще отдельная и разноплановая тема и её не надо смешивать c диаграммами. К тому же, TheOpenGroup как-то очень своеобразно развивает этот стандарт. С одной стороны, регулярно добавляет в него новые уровни и аспекты (хотя и Archimate версии 1.0 уже был перегружен идеями, и к 3-м версиям он вовсе не стал проще). С другой стороны, давая советы по усеченному использованию языка, например, для отрисовки представлений TOGAF.

В общем, может нам zoom пора провести на тему Archimate 2025? Давайте сделаем блицы: 5 минут на выступление + 5 на вопросы и комментарии. Я помодерирую. Кто готов выступить и уложиться в регламент – записывайтесь в комментарии к этому сообщению

Дата/время: 7 августа 19:00 MSK
👍55🔥11🤔52🤨1
Кстати, в конце июля появилось
... описание того, что должно стать следующей версией спецификации, а именно: ArchiMate® NEXT Specification, Snapshot 1 По ссылке список ожидаемых изменений и сам snapshot
🔥12👍41
Архитектура ИТ-решений
25 комментариев к предыдущим постам сообщали об использовании Archimate или удивлялись его отсутствию в опросе. Я думаю, что Archimate это вообще отдельная и разноплановая тема и её не надо смешивать c диаграммами. К тому же, TheOpenGroup как-то очень своеобразно…
С составом спикеров разговора об Archimate мы определились. Это:
- Artem Varkulevich
- ‎⁨Roman Tsirulnikov⁩
- ‎⁨Kirill Keker⁩
- ‎⁨Mikhail Zaborov⁩
- Alexander Chertilin, и я
- Maxim Smirnov⁩
а вот на темы разговора еще можно повлиять.

В комментариях к этому сообщению вы можете обозначить интересующие вас темы и задать вопросы спикерам

и, конечно, присоединяйтесь к зуму
📆 7 августа в 19:00 MSK
(ссылка будет в этом канале накануне)
🔥25👍146🎉1
Разбираясь с тем, как менялась концепция доменов в Archimate, нашел еще одну точку входа в эту нотацию. Это опубликованное в сообществе языка на сайте TheOpenGroup руководство: ArchiMate 101: A Practical Introduction Мне оно не показалось каким-то выдающимся, но кому-то может будет полезно
Идея этой книги возникла из отзывов преподавателей, которые были разочарованы тем, что новые ученики не могли на практике применить полученные знания, в то время как в других (более неформальных) ситуациях можно было быстро объяснить, как использовать небольшую часть ArchiMate® и освоить её за несколько часов
👍13🔥6
Когда-то я хотел сам поделиться этой печальной историей, но подумал, что она будет не вполне в формате канала. Однако Павел великолепно, кратко и емко, описал всё в одном сообщении и теперь я просто не могу его не репостнуть
Можно ли представить, что ИТ система отправляет сотни людей в тюрьму?

Увы можно. Я в своей книге говорю, что сейчас ошибки в проектах обычно не измеряются жизнями. Но есть и неприятные исключения.

Проект Fujitsu North Star. Автоматизация почты Великобритании

Разберем по Пентабазису:

🔻ЗАЧЕМ
Проблема:
Замена бумажного учета на Единую электронную систему учета (Epos) – Horizon от Fujitsu.
Для кого: Post Office как организация, государственные институты и тысячи управляющих почтовыми отделениями. (ПА: Тут интересно - Это не наемные сотрудники, а контрактные управленцы, часто — микропредприниматели, которые арендуют или владеют локальными отделениями Post Office и работают по франчайзингу. Они несут финансовую ответственность за любую недостачу)

🔻ЧТО
Автоматизация учета и обслуживания клиентов - финансовые транзакции, кассовые операции, учёт товаров, учёта пенсий, пособий и переводов, инвентаризацию и централизованный сбор данных

🔻КАК
▪️Инициация и контрактование (1994–1996)
▪️Разработка и пилотирование (1996–1999)
▪️Массовое внедрение (1999–2001)
▪️Обновление системы — Horizon Online (2010)

🔻КТО
▪️Заказчик – Post Office Ltd (бывшая часть Royal Mail Group)
▪️Подрядчик (Разработчик) – Fujitsu/ICL
▪️Пользователи (Ключевые операторы системы) – Субпостмастеры — управляющие почтовыми отделениями

🔻ЧЕМ
Контракт порядка 2 млрд.£ (около 2,5 млрд.долларов)

🔻УСЛОВИЯ
▪️Жесткий график и политическое давление. Horizon был частью правительственной инициативы по модернизации инфраструктуры. Было требование быстрой цифровизации
▪️Фиксированный контракт. Контракт с ICL/Fujitsu был заключён по модели с фиксированной стоимостью и сроками, ограничивавшими гибкость в переработке системы.
▪️Культурный разрыв между центром и исполнителями. Центр (Post Office, Fujitsu) принимал решения в ИТ-терминах, а исполнители (субпостмастеры) работали с реальными людьми и деньгами. Они не понимали друг-друга.

К 2013 году система Horizon была внедрена более чем в 11,500 отделениях почты Великобритании. Через систему ежедневно проходило около 6 млн транзакций. Благодаря работе системы удалось выявить сотни случаев мошенничества!


Казалось бы УСПЕХ!
И что же пошло не так?

Увы за фасадом успеха была трагедия, вышедшая на национальный масштаб!
Оказалось, что большая часть случай мошенничества мошенничеством не являлась. А являлась ошибками системы. Десять лет это отрицалось. При этом людей увольняли, сажали. 900+ субпостмастеров обвинены, более 230 — в уголовном порядке. Было как минимум 13 случаев самоубийства.


«Мы не работали на компанию. Мы были этой компанией в глазах общества. А она отвернулась от нас в момент, когда мы больше всего в ней нуждались» — пострадавший субпостмастер.


В конце-концов пришлось признать очевидное. Что что переросло в крупнейшее в истории Британии судебное и репутационное поражение для Post Office. Уже выплачено более £1 млрд, через суд оправдано уже 555 человек. И дела еще идут...

Вобщем шикарная история как не надо делать проекты. По итогам даже сериал сняли. В прошлом году вышел - «Mr Bates vs the Post Office» («Мистер Бейтс против почты»). Статьи с подробностями можно почитать здесь и здесь.


🦉Практические выводы для Ваших проектов:

❗️ Никогда слепо не доверяйте ИТ системе. Horizon считалась «непогрешимой», и это стало ключевой ошибкой.

❗️ Риски - это не формальные списки, а способ мышления. Мне очень много раз помогал простой вопрос "Из-за чего мой проект признают провальным?". Швейцарский сыр Вам в помощь..

❗️ Слушайте пользователей. Они часто невнятные, скандальные, не могут объяснить что не так. И вообще "Любая система работает идеально, пока туда не запустили пользователей" (c). - но они ближе всего к системе. И они поднимают красные флажки.

❗️ Внедрение ≠ успех. Формально Horizon была успешно внедрена, но последствия были разрушительны. После того как внедрили надо хорошенько "погонять" систему. Стоит убедиться, что все работает правильным образом. Это называется "опытная эксплуатация" и не надо на нее жалеть времени! Это тема ПРИЖИВЛЕНИЯ - я много об этом пишу в книге - это критично!!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3921🔥12😢2
Is "Software Architect" a Fake Role? - вероятно, самый длинный текст из встречавшихся мне попыток ответа на вопрос кто такой архитектор ПО и чем он собственно занимается. Настоящий лонгрид, с пометкой 32 min read (в конце есть summary).

Я далеко не совсем согласен, но читается текст легко. Любителям поразмышлять, располагающим некоторым свободным временем, однозначно рекомендую
🔥12👍84🥱4
Вышел новый айфон...
Автор c4model Саймон Браун написал пару дней назад в своем твиттере x
Farewell "blue and grey boxes" ... the new example diagrams are now live on the C4 model website -> https://c4model.com


На сайте https://c4model.com и правда обновились все диаграммы. Посмотрите кому интересно. Скоро такие же появятся везде
👍27🔥173
Пятничное. В последнюю пятницу уходящего лета неплохая шутка десятилетней давности:
There are only two hard problems in distributed systems:
2. Exactly-once delivery
1. Guaranteed order of messages
2. Exactly-once delivery

Подробности см. здесь
🔥42💯13👍71👏1