Корпоративные бизнес -приложения нельзя считать образцом для подражания. Сложный пользовательский интерфейс, перегруженный формами ввода, запутанными меню и иерархическими списками, многошаговыми операции, ни на одном этапе которых нельзя ошибиться, наличие большого числа ограничений и долгие сроки внесения изменений — всё это резко контрастирует с сервисами, предоставляемыми нам в сети интернет, социальными сетями, мобильными приложениями.

Но особенно удручает корпоративных пользователей низкий уровень доступности бизнес-приложений: https://mxsmirnov.com/2018/02/10/msa-osp/

Читаем Роба Ингланда: Стюарт Ранс открыл грязную тайну ITIL процессов: на самом деле процессами они не являются:
"Многие из деятельностей ITSM, которые люди называют процессами, фактически ими не являются. Они не имеют простой последовательности четко определенных действий. У них плохо определенны виды деятельности, нет четкого триггера для начала их выполнения, имеется широкий спектр разнообразных и слабо определенных входов и выходов, которые также определены лишь частично https://www.itskeptic.org/content/itil-processes-arent-processes

Статья полезная: https://medium.com/@sgevlich/сторителлинг-глазами-технаря-b19ae9366a8e Примерно так мы и делаем на тренинге презентацию архитектуры ИТ-решения

Немного философских рассуждений относительно https://www.sei.cmu.edu/architecture/tools/evaluate/atam.cfm Так случилось, что мало кто явно называет целью проектирования поиск компромиссного решения, возникающего под давлением противоречивых требований, ограничений, неопределенности будущего и непонимания настоящего положения дел. На вопрос: «Хорошая ли у вас архитектура?» ответ, скорее всего будет: «Да просто отличная! Самая современная и замечательная из всех возможных архитектур».
Так не бывает! Как не бывает полных, непротиворечивых, однозначно трактуемых требований, стопроцентно предопределенного будущего, неограниченных ресурсов, совершенных технологических решений и идеального планирования. Можно лишь сильнее зажмуриться, чтоб образ целевого решения показался более расплывчатым, превратился в большое цветовое пятно, на фоне которого варианты реализации решения станут неразличимы. И тогда можно выбрать любой вариант архитектуры, т.к. он наверняка будет более-менее совпадать с расплывчатой цель. Если же сфокусировать взгляд в будущее, конкретизировать постановку задачи, очертить её более четко, то станет абсолютно очевидно, что ни один из вариантов реализации решения с постановкой не совпадает. Вот тогда уже можно выбирать между красивым решением, находящемся на значительном расстоянии от постановки задачи или более кривым вариантом в непосредственно близости. А что бы выбрали вы?

Исключительно чтоб потроллить товарищей подписался на несколько айтишных каналов. Достойных материалов пока не обнаружил, а потроллить кого-нибудь хочется. Потому в качестве такого объекта выбираю конференцию AnalystDays 8 https://analystdays.ru/ru/talks/55425 Я вот что-то не понимаю: англоязычных докладов от незнакомых мне людей пока несколько больше, чем докладов на русском языке. Неделю назад, на замечательной "Точке сборке" в Питере кто-то мне говорил, что это всё временно и скоро будет много-много отличных местных докладов. Похоже обманули 😱

Системные интеграторы не любят рассказывать архитектуру решений(не важно, идет ли речь о разработке или поставке коробки). Может потому, что на встречи с заказчиками ходят преимущественно продавцы, а может быть еще по каким-то причинам. Очень редко удается встретить человека с горящими глазами, способного вдохновленно рассказывать о клёвости предлагаемого решения и все чаще это какие-то скучные люди, бормочущие себе под нос: ну, мы это внедрили уже в десяти банках и у вас внедрим или рассуждающие о низких ценах и беспрецедентных скидках или же втирающие фантазии о собственном лидерстве на рынке. Беда в том, что без итерационного уточнения постановки задачи, посредством анализа возможных вариантов реализации, довести заказчика до состояния более-менее внятного понимания чего же он хочет – проблематично. Дальше дилемма. Использовать потенциальных поставщиков на этапе RFI/RFP для конкретизации постановки задачи или же делать это своими ресурсами. Первый вариант нравится мне больше, но системные интеграторы так не любят, да и не умеют, рассказывать архитектуру решений…

Что-то я так и не понял, что они там в ЦФТ сделали на микросервисах и главное зачем https://habrahabr.ru/company/jugru/blog/349954/ А ведь так хочется верить во что-то хорошое: мир, в котором не будет ни РБО, ни ИБСО, ни фактуры... Зря мечтаю?

А вдруг вы захотите проголосовать в небольшом опросе относительно границ информационной(автоматизированной) системы? https://www.facebook.com/345075415992373/

В чате про микросервисы опять обсуждаем как правильно релизиться. О книжке, с изолжением нового подхода о защите production среды от разрушающих изменений я писал здесь https://mxsmirnov.com/2015/08/09/cloud-native-application-architectures/ Скачайте её с сайта o'reilly (бесплатно, за регистрацию) там все написано

Начинаю отвечать на вопросы прошедшего сегодня вебинара (запись выложу чуть позже). Сначала о ссылках. Картинка TOGAF ADM Kanban взята отсюда https://erwin.com/blog/avoiding-analysis-paralysis-just-enough-enterprise-architecture/ В приницпе, заметки Zak Cole из блога ErWin все достатоно интересны, но нуждаются, на мой взгляд, в обсуждении в некотором хотя бы небольшом комьюнити

Запись вебинара про Ardoq https://youtu.be/4dZ1vNbSFVY

И моя заметка про Enterprise Evolver и другие подходы к описанию EA https://mxsmirnov.com/2016/01/02/digital-enterprise-architecture/

Ссылка на прошедший 2-го марта вебинар. https://youtu.be/_HMz88uH9pc Опять слишком много тем я постарался запихнуть в один час вместо того, чтоб подробней обсудить каждую. Впрочем, формат вебинара не очень способствует обсуждению. Надо экспериментировать с диалогами докладчика и оппонента. Наверняка это будет интересней

Кто был на прошлогоднем SECR в Питере? Вдохновила ли вас речь Ivar Jacobson? https://www.ivarjacobson.com/publications/presentations/kill-all-methods-free-practices

В криптопузыре начали случаться интересные вещи: "Мы не нашли ни одного проекта, который сейчас работает над созданием полностью децентрализованной и синхронизированной цепи, способной быстро обрабатывать необходимый для мира объем данных, поэтому сделали проект #MetaHash." https://metahash.org/

Пожалуй, самая цитируемая статья о том, кто такой архитектор ИТ-решений. Как им стать, что делать в этой роли, в чем её преимущества и печали https://www.developer.com/mgmt/article.php/3504496/Anatomy-of-a-Software-Development-Role-Solution-Architect.htm

Интернет-гиганты, я думаю, рано или поздно все же доберутся до банков. Интересно, а что это за люди не имеющие банковского счета(или по каким-то причинам не использующие свой счет в локальном банке), уж не мы ли с вами? https://www.technologyreview.com/the-download/610420/amazon-wants-to-start-offering-bank-accounts/

Раньше как-то не приходилось сталкиваться с этим ресурсом CA про API https://www.apiacademy.co/ Есть несколько интересных маркетинговых брошюр типа вот такой https://www.ca.com/content/dam/ca/us/files/ebook/api-strategy-and-architecture-a-coordinated-approach.pdf

Да они в своем гугле просто охренели. Решение о повышении сотрудника принимает не раздолбай-начальник, а регулярно работающий комитет, который рассматривает так называемые промо-пакеты. Сотруднику, которого включают в новый проект освобождают от старого. Что еще способны придумать эти коварные имериалисты империи добра? https://habrahabr.ru/post/350374/ Нет. Я бы тоже ушел в инди-хакеры. Впрочем, неделю назад я именно так и сделал. Вероятно, покидать большие корпорации нас заставляет что-то другое

Обсуждение вчерашней статьи на хабре, в комментариях к оригинальному сообщению и в группе https://t.iss.one/itarchitect вылилось, как того и следовало ожидать, в поиск виноватых. Google, плохой, менеджеры плохие, KPI – это плохо, автор сам виноват и т.д. Никто не подумал о том, а можно ли в такой ситуации что-то поменять, т.е. вопрос «что делать?» практически не обсуждался. Думаю, что поменять можно и сам факт появления этого сообщения был некоторой попыткой автора что-то сделать. Попыткой, безусловно, наивно и детской, из серии: «назло бабушке отморожу уши» - я думаю. Несколько моих тезисов: 1. Организациям нужен механизм обновления. Им жизненно необходимо реализовывать механизмы селекции, улучшающего отбора. 2. Традиционный менеджмент с HR, KPI-ями и прочими реквизитами – архаичное зло. 3. Не обязательно оценивать численно именно людей. Можно делать это с проектами, продуктами, конкретными бизнес-процессами, командами. Думаю, оценивать целиком команду – самый перспективный вариант. Победителей повышаем, проигравших расформировываем, а product owner-ам (руководителям проектов) предлагаем поконкурировать между собой за успешные команды. Глядишь, меньше всяких дурацких идей будет реализовываться