Архитектура ИТ-решений
13.8K subscribers
283 photos
29 files
1.09K links
Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений, микросервисы).

Этот канал не продается, а я не сдаю квартиры/машины/яхты. Будьте, пожалуйста, осторожны!
Download Telegram
Архитектура ИТ-решений
Спасибо за большое количество отзывов на такую маленькую заметку. Было бы ошибкой с моей стороны попробовать ответить на все комментарии сразу, т.к. они очень разные. Постараюсь сделать это постепенно. Начну, пожалуй, со сложности https://tttttt.me/c/1304614627/18955…
И еще одно замечание. В упомянутой статье https://www.osp.ru/os/2005/07-08/185761 Натис вводит следующее определение
Сложность (IT Complexity) — это мера нашей неспособности понимать, использовать, «ремонтировать» и наращивать свою ИТ-среду. Любое решение, помогающее воспринимать, диагностировать и обслуживать эту среду как единое целое, упрощает ее. А любые факторы, препятствующие этому, ее усложняют
Т.е., по-сути такое определение делает IT complexity субъективной мерой, т.е. зависящей от того, кто именно разбирается с данной конкретной архитектурой. Субъект может знать об определенных паттернах или не знать, понимать или не понимать замысел спроектировавшего решения архитектора и это влияет на воспринимаемую сложность. В общем, как только мы вводим в нашу модель субъекта, про комбинаторную сложность можно забыть. Слишком близка стала ИТ-архитектура к гуманитарным дисциплинам, чтоб мерять её объективными мерами длин и весов
А тем временем, я продолжаю проводить обучение по ИТ-архитектуре. Ближайший курс Микросервисная архитектура начнется 11 апреля
Появившаяся в прошлом году серия руководств Patterns of Legacy Displacement продолжает расширяться. Новая статья Transitional Architecture появилась как раз вовремя. Я готовлю небольшое выступление на тему Модернизация унаследованных приложений, а тут позавчера выходит такое подспорье про перехватчики событий и прочие связанные вещи
Помните, в начале нулевых появилось множество гибких методологий разработки: XP Кента Бека, семейство Crystal Коберна, ICONIX и т.д. А потом они все отошли на второй план и на какое-то время остался один SCRUM, т.е. подход, который в наименьшей степени можно назвать методологией разработки. Скорее, это мета-методология. Она не отвечает на вопрос Что делать? давая вместо этого ответ на вопрос Как? (см. Scrum guide). По сути, рекомендация звучит так: изобретите свой собственный процесс. Но этот ваш процесс должен быть эмпирическим, прозрачным, адаптируемым и т.д. Т.е. задан только самый общий минимум техник и инструментов.

Думаю, что только так сформулированный подход имел шансы закрепиться. Другие просто не прижились, т.к. слишком много вопросов можно к ним сформулировать. Собственно, на текущий момент резервы развития этой темы исчерпаны. (Абстрагироваться еще на более высокий уровень невозможно. Там уже стратосфера. Потому развиваться некуда) ...
... Но вопросы что делать, как вырабатывать и принимать решения, остались. На них никто не ответил! ИТ-архитектура как-то пытается заполнить этот разрыв. Поэтому и шаблоны архитектурных решений ADR содержат наборы альтернатив и описание мотиваций выбора, как это принято у solution architects, и DDD так востребован и истории про топологии команд из той же серии…

Но в общем и целом современный архитектурный подход не прояснен и внятно не описан. И пока кто-то не сформулирует новый подход к архитектуре(вероятно, мета-подход, как это уже случилось для процесса разработки c появлением SCRUM-а), ничего в ней не изменится
Архитектура ИТ-решений
Я редко стал заходить на InfoQ Когда-то это был интересный ресурс, но всё рано или поздно заканчивается. Но вот сегодня я туда заглянул и тут же обнаружил вот это: https://www.infoq.com/articles/microservices-seven-fail/ Думаю, что еще лет десять одни люди…
🥁InfoQ продолжает традицию вставлять слово микросервисы во все свои публикации. В этот раз абсолютно не к месту.

В общем-то, вполне неплохая заметка о Technology Capability Plan (TCP) https://www.infoq.com/articles/managing-technical-debt-microservices/ естественно, не имеет к микросервисам никакого отношения.

На ArchDays’19 я рассказывал, что специфика работы с техдолгом в современных распределенных системах состоит в том, что вы можете выбросить отдельный микросервис вместе с накопленным в нем техдолгом. Если угодно, списать технический долг. И вы не можете этого сделать в больших сильносвязанных системах. Но можете перехватить команду или запрос и передать его/её обработку в отдельный сервис
Pace layered подход, сформулированный когда-то в Gartner (см., например https://mxsmirnov.com/pace-layer/), это не только о том, когда надо, а когда не надо собирать требования, например

Предлагаю посмотреть на эту классификацию как на набор из трех фундаментальных ценностей, которые ИТ может принести:
1. Дать вам чужую технологию и операционную модель (system of records)
2. Поддержать ваши уникальные операции (system of differentiation)
3. Выявить потребность (system of innovation) Именно третья ценность является наиболее актуальной. Её мало кто понимает. Другие (инженерные) технологии так не умеют. Для них важно заранее знать что именно мы хотим сделать (вариант 2). А вот ИТ умеет работать в ситуации, когда владелец ресурсов совершенно не представляет чего хотеть, как с пользой задействовать доставшийся ему ресурс
Вот эта картинка (Hanschke, Strategic IT Management...) иллюстрирует основной вызов, стоящий сейчас перед бизнес-архитектором. Заключается он в необходимости разработки метамодели деятельности организации. Две идеи с картинки:

1. В информационной архитектуре не существует никаких уровней или доменов. (Бизнес-объект расположен между прикладным уровнем и уровнем бизнеса). Система информационных понятий едина (по вертикали). Одни и те же концепции пронизывают все слои: прикладной, бизнесовый, технологический (помните ubiquitous language).

2. В разных бизнес-доменах при организации деятельности используются разные концепции. У кого-то это продукты, у кого-то бизнес-процессы, а у третьих что-то совсем иное. Нет никакой единой модели деятельности организации, основанной, например, на бизнес-процессах. В каких-то функциональных областях процессы заходят, а в других – нет. Предметную область для каждого бизнес юнита надо проектировать и это снова про Domain Driven Design
Недели три я перечитываю снова и снова Why Software Is Eating the World 2011 года и другие рассуждения на эту тему от Marc Andreessen.

Читаю и никак не могу уловить тот тайный ингредиент, делающий software столь востребованным и уникальным продуктом. Таким, что нужен все большему и большему количеству заказчиков и во всё больших и больших объемах. Рассуждения о том, что процессора стали слишком производительными и чересчур дешевыми выглядят неубедительно. История про мобильные приложения если и была актуальна, то во времена написания статьи, т.е. десяток лет назад, а софт и его разработчики нужны всем не меньше прежнего. Почему?
Раздел Techniques 26-го технологического радара (29 марта 2022) оказался интересней, чем того можно было бы ожидать. Обычно, я сначала смотрю на новые или поменявшие своё место темы (кстати, на картинке такие обведены полным кругом или же его четвертинкой). В области Trail таких немало, я бы отметил:

- Documentation quadrants Очень полезно ознакомиться вот здесь
- Rethinking remote standups Все и так уже сделали
- Server-driven UI Речь про мобильные приложения. Если кто успел так сделать и больше не нуждается в публикации каждой версии в магазине приложений, то он молодец
- Tactical forking Тоже полезно почитать здесь
- Transitional architecture Обсуждали выше, в связи с Patterns of Legacy Displacement

В общем, только definition of production readiness (DPR) как-то мне не откликнулся. Может я просто недостаточно погружен в Google SRE
Вчерашнее обсуждение распределенной, а теперь и опенсорсной, YDB в нашей группе несколько схлынуло. Смотреть надо, но думаю там будет все более-менее нормально. Однако, вопрос: а не потеряют ли актуальность все эти CQRS-ы и Event Sourcing-и? - после таких новостей остается
Поделюсь слайдом из одной недавней презентации на давно уже обозначенную тему
Forwarded from Maxim Smirnov
В момент выхода версии 9.2 TOGAF развивающая его The Open Group анонсировал свое намерение превратить TOGAF в открытую расширяемую библиотеку. В 10-ой версии это практически реализовалось. PDF-ы скачать можно, но их довольно много и работать с ними не очень удобно
Архитектура ИТ-решений
Собственно, короткая заметка о выходе TOGAF10 у меня в блоге https://mxsmirnov.com/2022/04/28/togaf-10/
Некоторые шутники уже меня спрашивают:
- Потребуется ли миграция архитектурных репозиториев на новую версию TOGAF-10 с предыдущих версий

Шутка, безусловно, веселая, но как в любой шутке в ней есть доля чего-то большего. Во-первых, некоторые изменения и в метамодели, и в содержании стандарта в целом всё же есть. Насколько существенные - это уже другой вопрос Таблички с изменениями можно посмотреть в Appendix A An Introduction to the TOGAF® Standard, 10th Edition. Во-вторых, The Open Group, как мне представляется, действует вполне осознанно, пытаясь сохранить свои лидирующие позиции центра компетенций по архитектуре предприятия. Посмотрев какой отклик получил O-AA, а до этого и DPBOK, сейчас они возвращают наше внимание к TOGAF. И если кого-то и что-то не устраивало и не устраивает в основном стандарте, то ответы и уточнения теперь придется искать всё равно в TOGAF, но уже в TOGAF Series Guides или в TOGAF Library, куда попал, например, стандарт IT4IT и пр.
Поступают первые обзоры 10-ой версии TOGAF. Хочу обратить ваше внимание на заметку What Makes TOGAF 10 a Valuable Contribution, которую написал Markus Freimuth Согласен с его идеями о назревшей необходимости актуализировать ADM. Этого пока не случилось, но в TOGAF Series Guides появились руководства, предлагающие альтернативу традиционному тяжеловесному процессу
Многие знакомые мне ИТ-архитекторы стараются дистанцироваться от темы low-code/no-code. Попыток серьезно об этом поговорить немного, да и они заглушаются хором отраслевых консультантов и поставщиков loconoco решений. Именно поэтому стоит обратить внимание на январскую заметку The Quest for Low-Code: 9 paths, some of which actually work от Gregor Hohpe. В ней есть над чем поразмышлять и даже о чем поспорить