Как в воду глядел: 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

Возможно, кому-то пригодится. В прошлогоднем отчете 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.е) придет бигбосс и вежливо спросит: можно ли всякие технические вопросы обсуждать на вашем АК, а не выносить их на Правление или бюджетный комитет, а то этот как-то глупо всё это там выглядит. С радостной улыбкой и дурацким выражением лица скажите: Конечно! Именно для этого мы его и создавали