Несколько комментариев к упомянутой вчера статье из SEI Insights https://mxsmirnov.com/2018/11/14/data-governance/

О том, как сделать свой Technology Radar в стиле радаров ThoughtWorks:
https://github.com/thoughtworks/build-your-own-radar

Поделитесь, пожалуйста, с коллегами бизнес- системными аналитиками и ИТ-менеджерами. В феврале хотим сделать мастерскую для НЕархитекторов: https://mxsmirnov.com/2018/11/19/black-friday/

60-страничное введение в Service Mesh с рассказом о том, что это такое и зачем оно нужно, перечисление основных решений и сравнением их c API Gateways, парой слов про Evolutionary Architectures и совсем короткой главой про sidecars https://www.nginx.com/resources/library/the-enterprise-path-to-service-mesh-architectures/

В Gartner написали бумагу Building an Agile Application Architecture with... https://www.gartner.com/en/conferences/emea/applications-uk/why-attend/gartner-insights/rn-agile-application-architecture

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

CNCF добавила третий проект к списку Graduated. Вслед за Kubernetes и Prometheus из инкубатора вылупился Service Proxy Envoy https://www.cncf.io/announcement/2018/11/28/cncf-announces-envoy-graduation/ Честно говоря, я его совсем не смотрел, хотя в списке возможностей на сегодняшний день: балансировщик, outlier detection, circuit breaking, терминация TLS, работа с MongoDB, Redis, ну и много чего еще

Еще немного из цикла "мнение": рассуждения о том, почему RPA может замедлить вашу цифровую трансформацию от Camunda https://blog.camunda.com/post/2018/11/rpa-can-delay-your-digital-transformation/

Историю этой картинки чуть позже расскажу в своём блоге https://mxsmirnov.com

Не знаю, что полезней: слушать выступления на мероприятиях или разбирать demo, предварительно описанные докладчиками https://www.infoq.com/articles/istio-service-mesh-tutorial Наверное, и то и другое. Мне больше нравится сначала что-нибудь почитать, а потом и авторов послушать

Информационные технологии приносят работы больше, чем забирают. Вот вам пример, когда идея взять аналитика-стажера на 50K и научить его некому сокровенному знанию побеждает идею разработки сервиса валидации данных https://habr.com/company/hflabs/blog/431376/

Как-то пропустил я очередной холивар про микросервисы https://habr.com/company/raiffeisenbank/blog/427953/ Надо хабр не раз в месяц почитывать, а чаще. Хотя ...

Теперь рассказывать о развертывании Kafka в k8s кластере модно вот так: https://youtu.be/P_DEreC4ECw

Как-то пропустил этот проект https://www.minio.io/ Кто-нибудь разбирался? Расскажете? Ведь вдруг так случится, что скоро надо будет все контентные хранилища переделывать (Привет любителям, электронного документооборота, в частности)

Запись вчерашнего вебинара: https://youtu.be/AQrqeJmrxnE

Похоже, медицина только приступает к хождению по хорошо известным граблям автоматизации:

выберите себе модель вашего Цифрового регионального контура здравоохранения на ближайшие 6 лет с учетом предыдущего опыта:
…
б) или монолитную систему одного разработчика - если вы идеалист
https://zen.yandex.ru/media/id/5bd2e38afd73ab00ad0e5a0e/i-shinoi-edinoi-i-mis-ne-odnoi-5c0813743b426800aabb5d92

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

Не знаю чем народ недоволен. Мне это выступление понравилось https://habr.com/company/flant/blog/431500/

Большинство подходов к моделированию бизнес-процессов, показывают, что может произойти в процессе. В ряде случаев больше подойдут примеры того, что происходит на самом деле. Перефразируя Peter Hruschka: «Три хороших примера лучше, чем плохая абстракция» https://www.domainstorytelling.org/ Слайды(немного на немецком) https://speakerdeck.com/hofstef/knowledge-crunching-mit-domain-storytelling

Вопрос-ответ. (Что-то типа новой рубрики на канале c хэштегом #FAQ ). Вчера на вебинаре меня спросили: Как убедить заказчика, что этап анализа и проектирования необходим, за него ему надо платить.

Мой вариант ответа: поставьте себя на место заказчика. Много лет ему рассказывали, что он [тупой] не может сформулировать требования на понятном разработчику языке, а разработчик не понимает язык человеческий. Конечно же, заказчик обиделся: если программисту нужно какое-то там ТЗ, то пусть он и платит… и за ТЗ и за общесистемный софт и за все остальное.

Я вижу три варианта решения: 1) Перестать торговать душами, а предлагать команду целиком. 2) Объяснять заказчику в чем состоит ценность. Например, грамотная постановка задачи позволит ему заказать софт не у вас, а там, где дешевле (шутка, но это не единственная ценность) 3) Перестать мечтать о работе на конвейере (в pipeline-е CI/CD в нашем случае). Маржа, как известно, из производства уходит в сферу услуг, идите за ней. Помогайте заказчику осознать, что и зачем он хочет, а не как это сделать

Это правда! Три месяца назад в ВШБИ ВШЭ мы провели круглый стол по ИТ-архитектуре. Подробности здесь: https://habr.com/post/432386/ Большое спасибо всем участникам и отдельный респект Кристине за обзор этого мероприятия