Интервью на 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, ни тем более о выборе пути, учитывающем текущие ресурсы и локальные ограничения, ни о динамической генерации процесса в ходе его исполнения и т.п. и т.д.

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

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

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

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

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

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

Реляционная модель данных Эдгара Кодда не сразу завоевала популярность. Опубликованный в 69-70 годах подход в течении нескольких лет подвергался обсуждению и критике и только к середине 70-х стал де-факто стандартом для организации баз данных. Однако в 1979 году Кодд опубликовал еще одну работу с говорящим заголовком Extending the Database Relational Model to Capture More Meaning в которой рассуждает, в частности, о том, что модель «сущность-связь» является слишком верхнеуровневой абстракцией, что не позволяет сохранить семантику предметной области. В разделе 5 он выделяет несколько более конкретных типов сущностей, таких как: основные сущности(kernel), характеризующие и ассоциативные. (Перевод работы см. https://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/

Слайды Stefan Tilkov c конференции MicroXchg Berlin 2018 https://speakerdeck.com/stilkov/microservices-patterns-and-antipatterns-1

Только что мне от Neo4j пришла голосовалка за создание единого языка запросов к графовым базам данных GQL. Поддержал

It seems like the time is right to create one standard property graph query language. Fusing the best of Cypher, PGQL and G-CORE into a more comprehensive query language built specifically for graph solutions https://gql.today/

Кстати, визуализация данных из графовых БД в виде молекулярных структур (Force-directed graph drawing) кажется мне довольно неряшливой. Ребра между экземплярами и абстракциями не должны быть одинаковыми, да и отношения агрегации и композиции - слишком частный случай ассоциации. Ну а про наследование я вообще молчу. Одним словом, понятней надо визуализировать, доходчивей, для людей...

Забавные размышления о трех стилях документирования API: описательном, в виде захватывающих историй(storytelling) и предписывающем. При случае, надо будет сделать пример с картинками https://caseysoftware.com/blog/three-styles-api-documentation (Keith Casey это автор учебного курса Designing RESTful APIs)

Для того, чтоб умело рисовать архитектурные картинки, не плохо бы иметь базовое представление о теории графов и связных областях математики. Краткое введение о том, что там происходило раньше и делается сейчас см. здесь https://youtu.be/SdXeKJJAwBY

Небольшой каталог Text2UML инструментов, включая несколько штук на JS, запускаемых в браузере, таких как Nomnoml https://modeling-languages.com/text-uml-tools-complete-list/

Картинки от Spotify полезно рассматривать не потому, что они описывают какую-то правильную организацию команд гибкой разработки, а в качестве гипотезы будущего устройства организаций. Трайбы – это компании, скводы – отделы, чаптеры и гильдии – профессиональные сообщества. И чем дальше все это развивается, тем меньше зависимость человека от трайба, задача которого – обеспечивать фронт работ и платить за выполнение этих работ деньги. Но ассоциировать себя эксперт должен не с трайбом, а с гильдией. Именно она должна обеспечивать ему пресловутое непрерывное обучение и карьерный рост. А трайбы(кланы) это больше про политику и непрерывные изменения [оргструктуры]

TheOpenGroup опубликовал комиксы(Reference Cards) к новой версии 9.2 TOGAF https://publications.opengroup.org/n180 Ни одной новой картинки не обнаружено, да и стили старых сохранены :-( Пора делать ребрендинг! ;-)

Давным-давно была придумана и даже стандартизирована User Requirements Notation (URN), включающая в себя карту вариантов использования Use Case Map (UCM). Кому интересно см. здесь https://jucmnav.softwareengineering.ca/foswiki/UCM/WebHome Там даже есть большая книжка про UCM

Обзор Алексея Скобелева (Markswebb) об использовании банковских карт в России. И вот такой взгляд на топологию карты нашей страны https://www.facebook.com/1711312482290840/

Как развлекаются архитекторы. Концептуальная карта(кликабельна) описания компетенций архитектора решений и ИТ-архитектора. Очевидно, что наши известные теоретики TheOpenGroup и OMG такого нарисовать не сумеют ;-) https://criticaltechnology.blogspot.ru/2013/02/the-solution-architect.html