Системные интеграторы не любят рассказывать архитектуру решений(не важно, идет ли речь о разработке или поставке коробки). Может потому, что на встречи с заказчиками ходят преимущественно продавцы, а может быть еще по каким-то причинам. Очень редко удается встретить человека с горящими глазами, способного вдохновленно рассказывать о клёвости предлагаемого решения и все чаще это какие-то скучные люди, бормочущие себе под нос: ну, мы это внедрили уже в десяти банках и у вас внедрим или рассуждающие о низких ценах и беспрецедентных скидках или же втирающие фантазии о собственном лидерстве на рынке. Беда в том, что без итерационного уточнения постановки задачи, посредством анализа возможных вариантов реализации, довести заказчика до состояния более-менее внятного понимания чего же он хочет – проблематично. Дальше дилемма. Использовать потенциальных поставщиков на этапе 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-ам (руководителям проектов) предлагаем поконкурировать между собой за успешные команды. Глядишь, меньше всяких дурацких идей будет реализовываться

Казалось бы, если архитекторы информационных систем что-то и умеют делать, то это что-то – документирование структуры базы данных. Питер Чен еще в 1976 году предложил модель «сущность-связь». Но есть, как минимум, две проблемы. Первая заключается в том, что структура данных и сами данные вещи немного разные... https://mxsmirnov.com/2012/05/05/%D0%BA%D0%B0%D0%BA-%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C-%D0%B1%D0%B0%D0%B7%D1%8B-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85/

Не помню у кого подслушал: руководитель проекта – это не менеджер, контролирующий проведение работ по заранее очерченному плану, это даже не человек, отвечающий за управление рисками. Главная забота проектного менеджера – дефициты. Дефицит ресурсов, дефицит времени, дефицит коммуникаций между вовлеченными лицами, дефицит поддержки со стороны руководства, дефицит устойчивости к изменениям, дефицит понимания что и зачем мы делаем…

В июне 2016 Google представил нам новое понятие при взаимодействии с клиентом: микро-моменты. С тех пор различных подходов к описанию таких взаимодействий становится все больше и больше. Customer journey map - для многих уже кажется скучным. Посмотрите перевод статьи Стива МакКарти про сторифрейминг https://uxgu.ru/storyframing/ Возможно пригодится кому-нибудь из бизнес-аналитиков

Эта картинка показывает, что микросервисная и корпоративная архитектура движутся по одному и тому же мосту в противоположных направлениях. Первые справа налево, от монолита к silo, а вторые к n-tier

Большой текст Майка Уокера(Microsoft) от 2007 года о работе корпоративного архитектора (на русском). Неплохое введение в тему EA https://msdn.microsoft.com/ru-ru/library/ee914377.aspx