Кто был на прошлогоднем 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 http://www.apiacademy.co/ Есть несколько интересных маркетинговых брошюр типа вот такой http://www.ca.com/content/dam/ca/us/files/ebook/api-strategy-and-architecture-a-coordinated-approach.pdf

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

Обсуждение вчерашней статьи на хабре, в комментариях к оригинальному сообщению и в группе https://t.me/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 - для многих уже кажется скучным. Посмотрите перевод статьи Стива МакКарти про сторифрейминг http://uxgu.ru/storyframing/ Возможно пригодится кому-нибудь из бизнес-аналитиков

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

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

Появилось новое слово на букву i В применении к бизнес-требованиям пока никто этого слова не произносил, но вот пожалуйста: Intelligent Business Requirements http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/4923/Intelligent-Business-Requirements.aspx Примечательно даже не то, что этот разговор начался на modern-analyst, а то что это попало в одну из лент международного института бизнес-анализа IIBA. Думаю, что BABOK неминуемо ждет 4-ая версия(либо безнадежное  устаревание), потому как в текущей версии тема отношения к требованиям, как к требующим подтверждения цифрами гипотезам не звучала. Пока промелькнуло выражение Digital BA

А я ведь здесь еще не делился своим веселым рассказом из жизни бизнес-аналитиков? https://mxsmirnov.com/2015/07/27/fmap/

Всё же это скорее вопросы, чем ответы, а слово "платформа" всё равно каждый будет понимать по своему. Тем не менее многие организации (и не обоснованно)  уже не первый год считают, что для решения проблемы собственного ИТ им нужно частное облако as a service https://martinfowler.com/articles/talk-about-platforms.html

Книжка [настоящего] архитектора Стюарта Брэнда "How Buildings Learn: What Happens After They’re Built", в которой была приведена в качестве паттерна многослойная архитектура зданий, позволяющая переклеивать обои не разрушая стен и менять электропроводку без перекладывания фундамента, дала мощную метафору N-tier приложений. Однако, архитекторы предприятия в большей степени склонны сравнивать себя с градостроителями, чем с архитекторами зданий. Ну так вот вам интервенция из области социологии https://youtu.be/kPrFXnnVwM4 Впрочем, закон Конвея никогда и не прекращал работать а EA, на мой взгляд, пусть не быстро, но неминуемо будет дрейфовать из области инженерных дисциплин в направление социальных наук

Как-то писал о том, что абстрагирование, придумывание покрывающих широкий класс задач моделей, необходимо и для SOA и для MDM и просто для интеграции приложений. Знаменитая Бруксовская "концептуальная целостность" - это перевод английского conceptual integrity. Нельзя интегрироваться не согласовав предварительно модели данных, событий и справочников https://mxsmirnov.com/2011/08/15/master-data-management-eda-esb-soa-%D1%81%D0%BE%D0%B1%D0%B8%D1%80%D0%B0%D0%B5%D0%BC-%D0%B2%D1%81%D0%B5-%D0%B2%D0%BC%D0%B5%D1%81%D1%82%D0%B5/

Накануне вебинара по ИТ-архитектуре предприятия я провел небольшой опрос, чтоб выяснить: "Зачем организациям целевая ИТ-архитектура" https://www.facebook.com/events/341054666394448/permalink/344506792715902/ Наиболее популярным ответом оказался вариант: "Чтоб навести порядок" . Но смотрите какая штука. Все проекты организации можно разделить на две группы: инвестиции и поддержку. Поддержку обычно стараются сократить, для чего и озвучивается потребность в "наведении порядка". В общем, не видать корпоративным приложениям ресурсов и инвестиций без смещения акцента с текущих задач на перспективные и расширения спектра бизнес-заказчиков