Только что мне от 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

Возможно, кому-то пригодится. В прошлогоднем отчете KPMG CIO Survey 2017, который является крупнейшим глобальным обзором ИТ отрасли (в 2017 в нем приняли участие 4500 ИТ-директоров из 86 стран) говорится, что потребность в архитекторах предприятия показывает наибольший рост, с 26% в 2016 до 34%. Больший спрос (42%) наблюдается сейчас только на аналитиков больших данных: https://home.kpmg.com/xx/en/home/insights/2017/05/harvey-nash-kpmg-cio-survey-2017.html

Вообще-то, я не пересылаю сюда сообщения из других каналов. Ну, только совсем нужные, такие как предыдущее ;-)

draw.io - это онлайн сервис для рисования диаграмм (сделан на JS). Не очень продвинутый, если сравнивать его с библиотеками типа D3.js или Go.js, но достаточно популярный. Беда этого сервиса, как и у многих - это экспорт/импорт данных и автоматическое выравнивание сложных диаграмм. Но они с этим работают. Вот заметку в апреле в свой блог написали: https://about.draw.io/automatically-create-draw-io-diagrams-from-csv-files/

Я написал небольшой текст про комитет по архитектуре в группе @itarchitect и меня настоятельно просят сделать из этого статью. Процесс этот не быстрый, потому сначала поделюсь ссылкой на книжку Паркинсона в библиотеке Машкова https://lib.ru/DPEOPLE/PARKINSON/parklaws.txt в которой, в принципе, написано всё, что следует знать о комитетах. Сам исходный текст сообщения ниже :

Друзья, если у вас появилась возможность запустить в своей организации комитет по архитектуре, то 1) делайте это 2) делайте это быстро, потому как окно возможностей может скоро закрыться 3) напишите одну бумажку: положение об АК, указав кому он репортит, рамки деятельности и полномочия, пару слов о регламенте 4) сделайте этот документ на 2-3 страница иначе запаритесь согласовывать и не успеете (см. п. 2) 5) быстро подпишите её у самого большого начальника 6) наладьте операционную деятельность: подготовка, проведение, протоколы, поручения 7) Ждите ходоков с предложениями по работе АК: 7.а) придет инфраструктура и попросит утверждать стандарты на железки и общесистемное ПО. Помогите им, т.к. решения АК они будут использовать для упрощения процедуры закупок оборудования и лицензий 7.b) придет разработка или сочуствующие и попросят выбрать единую платформу для... Расскажите им про микросервисную архитектуру 7.с) приедет отчетность и начнет втирать про MDM, Data Governance и пр. Посочуствуйте их бедам, но отправьте искать заказчика(это общее правило) 7.d) придет заказчик и скажет: а какого хрена мне отказываются делать доработки системы X ссылаясь на отствутвие её в целевой архитектуре. Дружите с заказчиком. Когда CIO задумает вас уволить, может заказчик заступится 7.е) придет бигбосс и вежливо спросит: можно ли всякие технические вопросы обсуждать на вашем АК, а не выносить их на Правление или бюджетный комитет, а то этот как-то глупо всё это там выглядит. С радостной улыбкой и дурацким выражением лица скажите: Конечно! Именно для этого мы его и создавали

Обнаружил вот такую картинку в блоге ИТ-скептика: https://twitter.com/theitskeptic/status/1001573179284901888 Актуально :-D

Цифровой феодализм - понятие, которое становится всё более распространенным, но означающее не совсем то, что можно было бы подумать в применении к отечественным реалиям.

Цифровой феодализм это про организацию деятельности вокруг платформ. Помните учебник по истории средних веков с картинками замка феодала? Большую часть населения составляют крестьяне, живущие вокруг крепостной стены. Периодически ворота замка открываются и к ним можно принести выращенную собственными руками сельскохозяйственную продукцию, чтоб поменять её на товары ремесленников, скрывающихся за крепостной стеной. Как они там делают эти всякие разные приспособления не понятно, но без создаваемых ими орудий никак нельзя. Весь процесс обмена контролирует феодал, устанавливая жесткие правила и собирая мзду в той или иной форме. Всё принадлежит ему. В принципе, с платформами жить плохо, но без них еще хуже, потому как больше некому предложить свой труд и не у кого получить прожиточный минимум. А если год неурожайный или еще какая-то неприятность случится, то без платформы - вообще беда

В архитектурных моделях иногда возникает гипергрaф — обобщения понятия граф, в котором каждым ребром могут соединяться не две, а любое количество вершин. Я однажды уже писал о карте вариантов использования Use Case Map https://mxsmirnov.com/2016/04/30/use-case-map/ но этой моделью дело явно не ограничится

Со мной поделились крайне любопытным исследованием о том, что думаю архитекторы предприятия о настоящем и будущем своей деятельности

Инженеры любят говорить, что у любой системы есть архитектура. Просто у каких-то систем она не очень: кривая, не продуманная и плохо задокументированная. Архитекторы подозревают в этом тезисе определенное лукавство.

Для них архитектура у системы появляется в присутствии субъекта, наблюдателя(stakeholder). Причем наблюдателя, не просто праздно шатающегося неподалеку от системы, а испытывающего к ней определенный интерес(concern). Об этом написано в IEEE-1471, он же ISO 42010, он же ГОСТ Р 57100. И это важно, потому как в отсутствии субъекта, озадаченного некоторой своей проблемой, не ясно какие аспекты системы являются существенными и заслуживают попадания в наше поле зрения, а какие нет. Не имея этих двух вещей, мы не сможем редуцировать сложность реальной системы до простой, но полезной модели, позволяющей принимать адекватные решения, т.е. сложность системы может быть спроецирована в понятное архитектурное представление(view) только после ответа на вопросы для кого и зачем мы это делаем.

И еще, вы конечно мне не поверите, но архитектура - это как раз о том, как просто судить о сложном, а не запутать всех окончательно