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

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

Как развлекаются архитекторы. Концептуальная карта(кликабельна) описания компетенций архитектора решений и ИТ-архитектора. Очевидно, что наши известные теоретики TheOpenGroup и OMG такого нарисовать не сумеют ;-) http://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

Telegram и обход блокировок 🖕

Как и обещала, написала подробную статью о методах обхода блокировок, которые использует Telegram, а также о принципе работы SOCKS5/MTPROTO-прокси.
Статья сугубо техническая, поэтому не всем может быть понятно, но надеюсь, что кому-то будет полезно.
Пожалуйста, распространите её. Я старалась, чтобы навсегда закончить споры и объяснения этих вещей на форумах и в чатах.

Телеграф-то осилите открыть? В любом случае, Instant View всегда работает.

http://telegra.ph/telegram-blocks-wtf-05-26

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

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

Я написал небольшой текст про комитет по архитектуре в группе @itarchitect и меня настоятельно просят сделать из этого статью. Процесс этот не быстрый, потому сначала поделюсь ссылкой на книжку Паркинсона в библиотеке Машкова http://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) только после ответа на вопросы для кого и зачем мы это делаем.

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

Structurizr Express от Саймона Брауна, автора фреймворка для архитектуры ПО с4model, постепенно развивается: https://structurizr.com/express Похоже, что на горизонте пары лет, мы все же получим средства автоматической отрисовки моделей из их описания в стиле GraphViz/PlanUML

Но пока это выглядит как-то так http://www.nomnoml.com/

Сегодня FB напомнил мне фотографию пятилетней давности https://www.facebook.com/554823874556179, которую я сделал в Амстердаме и назвал голландской википедией. Но оказывается, что прообраз броузера: книжное колесо - конструкцию, на которой крепились открытые на нужной странице книжки, чтоб удобнее было перемещаться между несколькими источниками и делать выписки, изобрел еще в 1588 году итальянский инженер Агностино Рамелли

Создал на FB небольшой опрос по впечатлениям от сегодняшенго мастер-класса: "Микросервисы в корпоративном ИТ-ландшафте" https://www.facebook.com/170931133589605/

Слайды вчерашнего мастер-класса

Вот здесь https://ru.atlassian.com/software/jira/portfolio/scaling-agile-with-safe за e-mail дают почитать файл: Scaling agile with Atlassian and SAFe. Вполне такой прагматичный документ, без ореола загадочности вокруг Scaled Agile Framework