Это замечательно: https://youtu.be/4ht22ReBjno

Похоже, что эта история не устаревает: https://mxsmirnov.com/2015/06/02/paas/ :-)

Должен ли High Level Design (верхнеровневую архитектуру проекта, подробнее см. https://mxsmirnov.com/high-level-it-design/) разрабатывать исключительно ИТ-архитектор

Иногда HLD может разрабатывать и аналитик – 21
👍👍👍👍👍👍👍 70%

Да. Это только его задача – 8
👍👍👍 27%

Никто ничего подобного не пишет – 1
▫️ 3%

Обычно, разрабатывает аналитик
▫️ 0%

Решение предлагает разработчик
▫️ 0%

👥 30 people voted so far. Poll closed.

Примите, пожалуйста, участие в опросе. Еще раз продублирую ссылку на описание того что такое HLD https://mxsmirnov.com/high-level-it-design/

Самая популярная страница в блоге за прошлый год https://mxsmirnov.com/2017/02/01/landscape-map/ и одновременно учебный курс, который так и не сумел найти своего слушателя

Еще раз хочу обратить внимание на учебный курс https://idratherbewriting.com/learnapidoc/ Не смотря на то, что OpenAPI specification (swagger) вынесен в отдельный раздел, весь остальной материал заслуживает не меньшего внимания

Утащил слайд у Сэма Ньюмана - автора книжки про микросервисы

Собираем переводы свежих популярных статей про микросервисы. "Смерть микросервисного безумия в 2018 году" https://habrahabr.ru/company/flant/blog/347518/ наверняка все уже видели (довольно типичный взгляд разработчика)

А вот и перевод еще одной обсуждаемой статьи: https://habrahabr.ru/company/infopulse/blog/347428/

И еще одна ссылка, показавшаяся мне интересной. Полезно было бы провести аналогичное исследование по топ50-топ100 отечественных компаний https://www.infoq.com/articles/trends-culture-methods-jan2018

А еще, картинки про техники из BABOK Guide для аналитиков https://mxsmirnov.com/2015/05/02/babok-guide-v3-techniques-map/

Если кому-нибудь вдруг станет скучно, то вот короткая заметка про IoC https://mxsmirnov.com/2013/06/23/framework/

Буду отвечать по частям. Первый эффект, наблюдаемый для ERP систем, как впрочем и для других трехбуквенных слов, типа CRM, ECM - это эффект "пакетного" предложения. Примерно такой же, как в пакетах оператора связи, включающего в себя 100 минут, 200 смс и пару гигабайт трафика. Что из этого пакета, действительно, нужно, а что нет, понятно далеко не всегда. Но мы покупаем пакет, даже не смотря на то, что никто нам ничего не наплел про лучшие практики и исключительно выверенный для данного пакета баланс минут и смс, подходящий для современного городского жителя. Более того, мы не думаем уже отдельно о голосе и передаче данных, а думаем о пакете в целом. Тaк же и с ERP. Что такое финансовый учет, главная книга, поставщики и клиенты более или менее понятно. Понятны такие виды деятельности, как материальный учет, бюджетирование, управление поставщиками, проекты, кадровый учет. Но мы рассуждаем не обэтих предметных областях, а об ERP в целом и такие "мелочи", как например возможность вынести payroll на аутсорсинг выпадают из нашего поля зрения. С другой стороны, стоит нам задуматься о серьезной поддержки той или инйо потребности, ну например управлении цепочками поставок, как выясняется отсутстувие этого функционала в стандартной трехбуквенной системе. И мы идем к финансовому директору и начинаем канючить о необходимости покупки новой трехбуквенной хрени, называемой SCM. Теперь пару слов процессах. Какие там процессы лежат в этой самой ERP? Структуры данных, да, видел. Взятые из этой, не новой уже книжки https://www.amazon.com/Data-Model-Patterns-David-Hay/dp/0932633749 Управление жизненным циклом этих объектов, тоже есть. Но назвать это полноценными бизнес-процессами я бы не решился. Собственно с гибкостью процессов у ERP и обнаруживается проблема: настроить их можно как угодно, но только один раз. В этом у ERP есть определенное сходство с бетоном, который до своего застывания может быть залит в совершенно любую форму ...

Если вы раньше читали международный стандарт описания архитектур ANSI/IEEE 1471-2000 или его возрождение в виде ISO/IEC/IEEE 42010:2011, то надеюсь согласитесь со мной, что документы эти сложно назвать понятными. Поэтому перевод на русский язык должен был сделать описание описания архитектуры непонятным вдвойне. Но перевод стандарта не только блестяще справился с этой задачей, но и в определенной степени превзошел открывающиеся возможности. Теперь, что такое описание архитектуры и как его делать стало окончательно непонятным https://mxsmirnov.com/2017/06/10/gost-r-57100/

Наверное, это преждевременная статья. Но архитекторы, они же всегда смотрят немного за горизонт https://www.infoq.com/articles/kubernetes-effect

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

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

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

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