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

Этот канал не продается, а я не сдаю квартиры/машины/яхты. Будьте, пожалуйста, осторожны!
Download Telegram
Нашел свой довольно старый текст https://mxsmirnov.com/2014/03/20/why-ea/ и подумал, что вместо него следовало бы создать для архитекторов предприятия страничку ответов на часто задаваемые руководителями и заказчиками вопросы. Может кто видел такую штуку именно для EA?
Очень простое объяснение одного из паттернов микросервисной архитектуры https://medium.com/@volodymyrfrolov/pluggable-microservices-734457c3a3b3 Я уже говорил, что микросервисы бывают разными и изложенная в статье архитектура - лишь одна из нескольких. Но, задумываясь о микросервисах, я бы в первую очередь думал о "распределенных плагинах"
Вау! Оказывается Cloud native computing foundation с июня 2020 делает тематические технологические радары, наподобие ThoughtWorks. Сегодня появился уже второй https://www.cncf.io/blog/2020/09/11/cncf-end-user-technology-radar-observability-september-2020/

Подробнее: https://radar.cncf.io/
В CQRS Documents by Greg Young https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf я всегда проскакивал мимо идеи о том, что анемичная модель предметной области, во-первых, это своеобразный способ обеспечения гибкости: когда ИТ-системы предоставляют россыпь объектов, которые можно как угодно модифицировать, а рабочий процесс реализован в головах пользователей и его изменение не требует доработок софта. А во-вторых - показатель бедности (Возникающие в таких системах ошибки, видимо, не столь критичны; как тактично говорит автор, эти системы имеют низкую ценность с точки зрения бизнеса)

В противоположность этому CQRS добавляет в предметную область глаголы (частные случаи команд), которые становятся полноценными элементами модели, а не только сигнатурами методов, о существовании которых никто кроме разработчиков и не подозревал
В отличии от историков, архитекторы предприятия часто перерисовывают модели будущего. Есть даже традиция разработки нескольких целевых архитектур: для горизонта планирования год, три года и совсем отдаленного будущего, например. Для структурирования унаследованных приложений и данных было бы полезным наличие нескольких горизонтов прошлого. Например, до некоторого момента времени организация структурирует своих клиентов в соответствии с предоставленными им услугами. Затем, когда услуг становится слишком много, появляется понятие кампании – ограниченного по времени предложения пакета услуг, перевязанного праздничной ленточкой. Потом приходит пора когортного анализа, целевых предложений и других подобных вещей… Всё это разные представления клиентов, разные сценарии услуг, а часто и разные информационные системы. Обобщить это в единую концептуальную модель практически нереально.

Архитектуре предприятия помогло бы мульти-концептуальное проектирование, если бы такое существовало
Разбор AWS-овских картинок от Ilograph https://blog.ilograph.com/posts/fixing-aws-architecture-diagrams-vod/ Конечно, это в первую очередь реклама собственного инструмента, но придирки к картинкам Амазона и предложения по их улучшению вполне обоснованные
Для новых подписчиков и тех, кто почему-то не знал, хочу напомнить про связанные с каналом группы:
Архитектура ИТ-решений и
Работа для ИТ-архитекторов

А заметки, опубликованные здесь, можно обсудить в специальной группе этого канала
Forwarded from Ilya
Все кто хочет поучаствовать - добавляйтесь в группу
https://tttttt.me/joinchat/CSEd5Rvy_6VeCyuZlnkGpA
Следует ли расценивать появление в iOS 14 такой штуки как App Clips (в русской версии блиц-приложения) как дальнейшее проникновении идей Грега Янга о Task based UI и CQRS?
Не сумел ответить для себя на вопрос: почему в Large Scale Scrum акцент сделан на системной динамике https://less.works/ru/less/principles/systems-thinking Ведь это не единственный из способов имитационного моделирования. Есть еще, как минимум, дискретно-событийное и агентное моделирование, но о них вообще ни слова.

Намеренно ли умалчиваются альтернативы или же авторы просто ограничились чтением книжки Питера Сенге - не ясно
Оставить ли кнопку "Прокомментировать" в сообщениях канала "Архитектура ИТ-решений" или избавиться от неё, как думаете?
The Open Group выпустила стандарт Open Agile Architecture https://www.opengroup.org/open-group-publishes-open-agile-architecture Он довольно сильно отличается от вышедшей в прошлом году предварительной версии O-AAF, хотя и базируется на ней, включает основные темы и много чего еще. Стандарт, как и прочие документы Open Group, доступен у них на сайте https://pubs.opengroup.org/architecture/o-aa-standard/
Кому лень читать - одна из немногочисленных картинок O-AA Building Blocks. Вообще, с картинками в стандарте всё плохо, впрочем как всегда. Ну, ничего, со временем нарисуем
Forwarded from Экспресс 42
Отчет о состоянии DevOps в России 2020

Компания Экспресс 42, совместно с конференциями Олега Бунина (Онтико), провели первое исследование состояния DevOps в России. Мы давно вынашивали эту идею, так как понимали, что исследования других компаний не дают ответов на вопросы, как DevOps развивается у нас в России. 

В течении августа 2020 мы опросили 889 специалистов и руководителей из разных регионов, отраслей и компаний.  В результате получили срез по текущему состоянию инженерных практик и инструментов, проверили гипотезы, как DevOps влияет на производительность и показатели компаний, сравнили результаты с предыдущими исследованиями, выявили тренды развития.

В отчете за 2020 год вы узнаете про следующие темы:

1. Использование ключевых DevOps метрик;
2. Сравнение ключевых метрик с показателями эффективности компаний;
3. Планы компаний на следующий год;
4. Популярные DevOps инструменты;
5. Применение DevOps практик:
1. Платформа как сервис;
2. Инфраструктура как код;
3. Непрерывная поставка и интеграция;
6. Как внедрять и развивать DevOps практики и инструменты;
7. Как связаны Agile и DevOps.
 

Скачайте отчет о состоянии DevOps в России 2020 прямо сейчас!
Набрел в ФБ на еще одну дискуссию о том, нужен ли корпоративный архитектор и, в случае положительного ответа, зачем он нужен. И в который раз наивно удивился тому, что в таких разговорах речь всегда идет о каких-то очень абстрактных предприятиях. Даже отраслевая принадлежность не дает ответа на вопрос: впишется ли в текущее устройство конкретной компании функция корпоративной архитектуры, есть ли зазор между реализациями других capabilities для архитектуры предприятия, есть ли потребности, не закрываемые имеющими функциональными подразделениями. Можно чётко обрисовать место архитектуры на business capabilities map: между операциями и стратегией, чуть в стороне от ИТ и неподалеку от основных заказчиков. А вот наличие потребности и возможности в том, чтоб занять это место, да еще и в данный конкретный момент времени – свойство каждого частного случая