Заработало?!

Карта сбоев Telegram на 9:00 по московскому времени. Примерно с 11:30 работа мессенджера начала восстанавливаться.

Следить за ситуацией можно здесь: downdetector.com/status/telegram/map/

Перевод статьи со сложным названием Events, Flows and Long-Running Services: A Modern Approach to Workflow Automation https://habr.com/post/346630/ которую, на мой взгляд, лучше было бы назвать легковесные конечные автоматы, т.к. речь идет о месте BPMS в современных(микросервисных, управляемых событиями) корпоративных ИТ-ландшафтах

Впрочем, история Java Business Integration подсказывает, что такая архитектура приводит к развитию множества самых разнообразных service engine. Как вам, например, микросервис, внутри которого сидит сотрудник и обрабатывает запросы? Подробнее, см. https://mxsmirnov.com/2015/07/04/private-paas-architecture/

Понимаю, что слишком часто публикую ссылки на объемные тексты, написанные латинскими буквами https://medium.com/capital-one-developers/toward-a-functional-programming-analogy-for-microservices-ba6f49b94ad

Главная проблема customer experience современного банкинга в попытке натянуть опыт взаимодействия с пользователями[корпоративных информационных систем] на клиентов. Кнопок и экранов в мобильных банковских приложениях уже стало больше, чем в интернет-банке, а пунктов меню в личных кабинетах в веб, больше чем во фронт-офисах и АБСках. И всё это никому не нужно! [Новый]функционал нужен банку, а не клиентам, он, типа, деньги помогает зарабатывать. А клиентам функционал не нужен, им нужны данные. Желательно, более-менее структурированные, желательно отвечающие [микро]моменту. Функции должны идти следом за данными. Если у меня на счете нет денег, то нафига мне знать, что я смог бы с ними сделать в случае, если бы они у меня были? В конце прошлого года два больших банка обновили свои мобильные приложения. Один добавил в него чат, другой – ленту событий. Угадайте, что пользуется спросом. Приложение – это не про функционал. Приложение – этой контейнер для данных и функционала, который напишет за вас следующее поколение разработчиков

... и в продолжение темы: https://mxsmirnov.com/2018/05/02/rest-cx/

Simon Brown переписал FAQ для своей C4 model https://c4model.com/#faq

Все уже поделились переводом законов Акина и я поделюсь https://habr.com/post/354936/

Почему все ИТ-системы разные. В рассуждения о типовых ИТ-решениях спекуляции витиевато переплетены с фрагментами здравого смысла. Но из практики известно, что даже самые типовые функции в разных организациях будут автоматизированы совсем непохожими приложениями. И при слиянии организаций попытка объединения двух таких приложений в одно станет непростым испытанием. А на вопрос: почему это так сложно, вам будут рассказывать что-то о проблемах в архитектуре. Вопрос в архитектуре чего.
Информационные системы всегда разрабатывают под архитектуру внешней, более общей системы. Это может быть совокупность процессов организации, экосистема поставщиков и партнеров (и регуляторов), текущая клиентская база со своей структурой и предпочтениями. Приложения, особенно заказные, получаются разными из-за своей зависимости от контекста. От того, что аналитики с пиететом и трепетом называют требованиями. Но, по сути своей, требования лишь проецируют нам архитектуру более объемлющей системы, c её оргструктурой, ролями, операциями, соглашениями и договоренностями (с)Капитан очевидность

С чем-то я бы поспорил, а с чем-то и согласился бы https://medium.com/@nvashanin/the-path-to-becoming-a-software-architect-de53f1cb310a

Интервью на InfoQ c новой попыткой разрушить понятие приложение(информационная система) в корпоративных ИТ. Приурочено к появлению книжки соучредителя и президента компании Semantic Arts Дэйва МакКомба. Естественно, речь о подходе, ориентированном на данные, семантических моделях и графовых базах данных:
- Практически все корпоративные информационные системы в настоящее время стоят намного больше, чем они должны стоить
- Большую часть избыточной стоимости можно объяснить сложностью
- Когда у вас есть сотни или тысячи сложных приложений, вы полностью застряли в том, что мы называем зацикленность на приложениях (Application Centric Quagmire)
- Более крупные фирмы тратят большую часть своего ИТ-бюджета на интеграцию (без достижения чего-либо большего, чем одноразовые программные интерфейсы)
- Исправление состоит в том, чтобы стать действительно ориентированным на данные, где интегрированная базовая модель предшествует добавлению функциональности
https://www.infoq.com/articles/book-review-software-wasteland

В Back2ITSM разворачивается дискуссия об использовании матрицы Захмана https://www.facebook.com/groups/back2itsm/permalink/1683650655021988/

Буквально на днях в каком-то тексте прочитал очень внятную историю о том, что большинство бизнес-процессов представляют собой тупую кальку из видов деятельности докомпьютерной эпохи, когда все было построено на формах(примерно таких, как в банковской отчетности). Одни люди их заполняли, другие консолидировали в новые формы, что-то по ходу вычисляя, третьи анализировали, ну и т.д. Такая форма организации провоцировала представление деятельности, как совокупность потоков работ. Собственно, отсюда и текущий взгляд на то, как должны выглядеть бизнес-процессы и отсюда же все драконовские ограничения восприятия операционной деятельности. Никто даже и не задумывается над совместной работой с взаимосвязанными ресурсами, как например в WWW, ни тем более о выборе пути, учитывающем текущие ресурсы и локальные ограничения, ни о динамической генерации процесса в ходе его исполнения и т.п. и т.д.

Осталось только вспомнить где же я это все прочитал

Нашел: http://tdan.com/the-data-centric-revolution-data-centric-vs-application-centric/ Сейчас, в связи темой цифровой экономики, будет очень много разговоров о том, что надо бы как-то автоматизировать обработку потоков данных, перегородить бумажные реки плотинами бизнес-приложений, мелиорировать бюрократические болота свежим потоком бумажных и экранных форм. Всё это полная ерунда. "Подрыв" будет заключаться в преодолении мышления, воспринимающего деятельность в виде потоков работ над структурированными данными

А тем временем в Техасе, на своей главной ежегодной конференции SATURN 2018, архитекторы ПО обсуждают совсем невероятные вещи: https://pbs.twimg.com/media/Dc2rJx0V0AAiybL.jpg

Как в воду глядел: https://t.me/itSMFRussia/139

В продолжение темы любителей форм и потоков данных: IT Service Management - типичный пример того, как к администраторам информационных систем пришли свидетели "передового опыта" и заставили их заполнять множество форм, боормоча при этом непонятные аббревиатуры: RFC, CMDB, CAB и пр. Чуть раньше эти люди посещали врачей, а в наше время плотно взялись за учителей и преподавателей ВУЗов 😱

НаучПоп для архитектора данных.

Реляционная модель данных Эдгара Кодда не сразу завоевала популярность. Опубликованный в 69-70 годах подход в течении нескольких лет подвергался обсуждению и критике и только к середине 70-х стал де-факто стандартом для организации баз данных. Однако в 1979 году Кодд опубликовал еще одну работу с говорящим заголовком Extending the Database Relational Model to Capture More Meaning в которой рассуждает, в частности, о том, что модель «сущность-связь» является слишком верхнеуровневой абстракцией, что не позволяет сохранить семантику предметной области. В разделе 5 он выделяет несколько более конкретных типов сущностей, таких как: основные сущности(kernel), характеризующие и ассоциативные. (Перевод работы см. http://citforum.ru/database/classics/codd_2/) Большинству архитекторов и аналитиков эта работа Кодда практически неизвестна. Cтолкнуться с ней довелось разве что архитекторам корпоративных хранилищ данных, которым предстояло придумывать модели, способные обобщить данные из множества БД с различной структурой, например такие как Data Vault

Решил просто поделиться картинкой https://mxsmirnov.com/2018/05/11/euler/

Аналитики Gartner придумали новое слово на букву "Х": hybrid integration platform (HIP). Ну, вроде бы текущие интеграционные среды они не очень правильные, инструментов в них не хватает, да и процессы развития в них сильно забюрократизированы. Захочет, например, HR-директор какой-нибудь SaaS подключить, или кто-то другой в компании с IoT поиграться и потребуются им те или иные данные - а нельзя! Вот Gartner говорит, что это не совсем правильно и скоро в половине компаний заведется этот самый HIP в стиле iPaaS, c открытыми для простых сотрудников APIs и прочими наворотами https://www.gartner.com/smarterwithgartner/use-a-hybrid-integration-approach-to-empower-digital-transformation/