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

Обсуждение вчерашней статьи на хабре, в комментариях к оригинальному сообщению и в группе https://tttttt.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 приложений. Однако, архитекторы предприятия в большей степени склонны сравнивать себя с градостроителями, чем с архитекторами зданий. ... Впрочем, закон Конвея никогда и не прекращал работать а 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/ Наиболее популярным ответом оказался вариант: "Чтоб навести порядок" . Но смотрите какая штука. Все проекты организации можно разделить на две группы: инвестиции и поддержку. Поддержку обычно стараются сократить, для чего и озвучивается потребность в "наведении порядка". В общем, не видать корпоративным приложениям ресурсов и инвестиций без смещения акцента с текущих задач на перспективные и расширения спектра бизнес-заказчиков

Обзор выступления Stefan Tilkov об антипаттернах микросервисной архитектуры на microXchg 2018 в Берлине (ссылка на видео полного ыступления внутри). Главный, связанный с микросервисами паттерн - Evolutionary Architecture: разделение крупных доменов на "islands of change"; разработка для замены, а не повторного использования, уменьшение зависимостей, а не повторное использование. Антипаттерны: распределенный монолит, иллюзия низкой связности, микроплатформа, сервис- сущность, распределенный DDD https://www.infoq.com/news/2018/03/microservices-anti-patterns

Business Objects: Re-Engineering for Re-Use

Хотите толстую заумную книжку про данные(на английском, естественно)? Загрузил выше. Последний раз она переиздавалась в 2000 году, так что надеюсь, что ничьих прав я не нарушаю

An Association for All IT Architects (IASA) поддержала традицию рисования большой кликабельной картинки для в духе SAFe https://www.iasaglobal.org/itabok3_0/

Классификация архитекторов https://mxsmirnov.com/2014/02/23/antipatterns/