Для вакансий ИТ-архитекторов стало характерно отсутствие больших идей. Даже хайпы стали упоминаться реже. Сохранились одни трансформации. Трансформации из априори плохого настоящего в  сторону всё равно какого будущего. Почему так? Может с ИТ-директорами что-то случилось?

Не знаю, доберется ли до корпоративного мейнстрима идея поставки программного обеспечения в виде sidecars контейнеров, но контуры этой темы проступают всё более и более чётко: минимальные накладные расходы на межпроцессное взаимодействие в сочетании с независимостью от используемых технологий https://thenewstack.io/operators-and-sidecars-are-the-new-model-for-software-delivery/

Хотя может, я просто всегда любил sidecar-ы. В конце 1999 года даже короткую заметку в Компьютерре напечатал https://old.computerra.ru/196057/

Недавно случился подкаст, на который Gene Kim пригласил Michael Nygard, известного, в частности, знаменитой книжкой Release It! К аудиозаписи этого полуторачасового разговора добавили расшифровку(транскрипт).

В общем, слушайте и читайте здесь: https://itrevolution.com/idealcast-episode-8/
PS: картинка, как это часто уже случается в моём канале, неправильная :-)

20 августа, 20:00 MSK
Веб-ресурсы – новая интеграционная среда?

Нет никакого изъяна в очередях и брокерах сообщений. Нам по-прежнему нужны машины состояний и обработчики бизнес-правил. Почему же корпоративные сервисные шины ESB, ставшие столь популярными в нулевых годах, к концу второго десятилетия XXI века считаются явным анахронизмом. Что в них не так?
А может быть проблема не в сервисной шине, а некоторых других понятиях...

Приглашаю обсудить эту тему, в ближайший четверг, в zoom: https://us02web.zoom.us/j/89019160706?pwd=dXF2ZFVFUWh2NDUwbTlaMFM3M09Xdz09  Идентификатор конференции: 890 1916 0706 Код доступа: 513901

Можем ли мы простыми словами рассказать неайтишнику о том, что у нас происходит? Объяснить некоторые базовые концепции, приложив их к текущему состоянию дел. Раньше, очевидно, могли. И получаса хватит, чтоб растолковать практически кому-угодно что такое реляционные базы данных и даже порисовать с ним таблички, рассказать об устройстве хранилища данных или, например, корпоративной сервисной шины.

Сегодня, боюсь, что нет. Мы, конечно, можем попробовать, но вряд ли уложимся в полчаса и то, выйдет у нас слишком поверхностно (Расскажите про CQRS за пять минут).  Впрочем, слушать нас скорее всего никто не станет. Обстоятельные истории об устройстве технологий уступили место бестолковым журнальным заголовкам. А в реальной работе понимание достигается за счет плотных регулярных коммуникаций. Показать мы можем намного больше чем объяснить. Потому и без agile никуда.

В общем, снова архитекторы виноваты, как ни крути! Ну, а кто еще должен простыми словами объяснять людям сложные вещи?

Доктор Курпатов рассказывает понятным для людей языком что такое  архитектура предприятия и основные концепции ISO 42010 https://youtu.be/qOD3ceZxdYM?t=2278 :-D

Чем радует меня закат микросервисного хайпа, особенно в корпоративном контексте, так это предложением вернуться назад, типа к монолиту. Прям рисуется картина маслом, как мы берем ERP, CRM, системы дистанционного обслуживания и всё прочее и собираем в один большой процесс и развертываем его в сотнях экземпляров на всех серверах компании.

Не было у вас никакого монолита. Вернее, их было много с разными технологическими стеками, разными структурами данных и непосредственно данными, разными фрагментами функционала, перевязанного в сквозные бизнес-процессы интеграционными средами. В общем кусочно-лоскутная автоматизация во всей красе. Мы к ней возвращаться будем?
- Нет, не будем – отвечают ревизионисты микросервсиной архитектуры – мы новые системы станем писать не в виде набора сервисов, а как единый процесс.

Ну, правильно! Предыдущие тридцать лет все так и делали. Начиналось обычно словами: сейчас мы все перепишем и будет одно новое и хорошее. Заканчивалось появлением еще одного булыжника в дополнение к существующему ИТ-ландшафту. Со своей технологией, со своими данными, как-то криво и косо синтегрированного со всем остальным

Микросервис от приложения отличают два важных преимущества: у него есть API и у него нет GUI. Помните как раньше пользователи ходили и орали:
- Сделайте нам единое окно! Мы не хотим работать в десятках систем!... А еще мы хотим быстрый поиск по данным из всех систем и чтоб ничего никогда не тормозило!

Хайп твоего счастья заканчивается, дорогой  пользователь!
Вспоминай старые навыки: запускаем в начале рабочего дня все нужные приложения и копи-пастим данные между ними через клипборд и ждем ...

Начав читать транскрипт этого выступления https://www.infoq.com/presentations/microservices-monolith-antipatterns/ я решил, что оно относится к разделу "сатира и юмор". Однако ни после истории с потребностью в webhooks, ни после злоключений с shared libraries в транскрипте не было отметок о смехе в зале. Пришлось включить запись. С изумлением я обнаружил, что по ходу выступления вообще никто не смеется... Может это считается неполиткорректным, не знаю. Почему-то мне кажется, что девушка собиралась сделать веселую презентацию, но вошла в другой образ и веселыми получились лишь смайлики на последнем слайде

Раз уж я переименовал этот канал в "Архитектура ИТ-решений", то позволю себе иногда публиковать некоторые определения. Сегодня термин solution (решение) из руководства бизнес-аналитиков BABOK Guide v3
Solution:

A specific way of satisfying one or more needs in a context.

A solution satisfies a need by resolving a problem faced by stakeholders or enabling stakeholders to take advantage of an opportunity

Поделюсь приглашением на вебинар

3 сентября в 18:00 мы проведем вебинар «Единые фронтальные решения и обратные потоки». Спикер — Павел Абдюшев, директор по развитию продуктов HFLabs. В HFLabs Павел участвовал в шести проектах по интеграции ЕФР и CDI. Еще в трех налаживал обратные потоки.

О чем пойдет речь:
— возможно ли построить ЕФР без CDI;
— откуда берутся дубли после внедрения ЕФР;
— ЕФР или CDI. Какую систему выбрать в качестве мастера клиентских данных;
— нужен ли обратный поток данных о клиентах во все учетные системы;
— как синхронизировать данные без обратных потоков;
— можно и нужно ли добиваться дедупликации клиентов во всех исходных системах.

Вебинар будет интересен специалистам из банков, страховых, телекомов, ритейла. Ждем архитекторов, руководителей проектов и подразделений, CIO, CDO, ответственных за Big Data.

Руководители бизнес-подразделений тоже найдут для себя полезное: Павел покажет, что картинки с презентаций о ЕФР очень сложно воплотить в жизнь.

Вебинар продлится час.

Регистрация: forms.gle/xSCms1C5R4M1Er6FA

Давайте продолжим с определениями:
Solution Architecture

A description of a discrete and focused business operation or activity and how IS/IT supports that operation.

Note: A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks
[ TOGAF 9.2: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_69 ]

А вот вам состав описания архитектуры решения из прошлогодней книжки
Alan McSweeney, Introduction to Solution Architecture

Собрал в один плейлист вебинары, проведенные на канале IT Expert https://www.youtube.com/playlist?list=PLDwZgqHLFBe5B4Dt3dFszxo-p3xMalN8e

#youtube

Коллеги из компании ЦРММ приглашают всех интересующихся дистанционным обучением, принять участие в вебинаре «Как TinCan API меняет обучение».
15 сентября в 19:00 разработчики EdTech-продуктов в прямом эфире поделятся опытом внедрения TinCan API. Расскажут, как с его помощью настроить процесс получения BigData об обучении. На конкретных примерах покажут, как данные помогают принимать эффективные бизнес-решения.

❗️Участие БЕСПЛАТНО.
Регистрируйтесь по ссылке: https://clck.ru/QibzA

Что такое TinCan API? Это стандарт передачи данных в дистанционном обучении, который пришел на замену SCORM. Благодаря новому стандарту возможно получать всестороннюю информацию о том, как проходило онлайн-обучение.

Я всё ждал, а не перерисует ли кто-нибудь знаменитую картинку Джона Захмана 1987 года в приемлемом разрешении

Вдогонку. Фрагмент видео https://youtu.be/oUhOPcHginY
#youtube

The OpenAPI Specification (OAS) - стандарт описания REST API в виде YAML-файла.

Но YAML можно использовать и для описания  микросервисов в Microservice Design Canvas. Прототип такого решения см. https://solusoftsl.github.io/microservices-design-canvas-editor/