Автор: Максим Смирнов

Коротко об обучении ИТ-архитекторов

Сейчас в образовании популярна новая тема: обучение через большие идеи или дидактика «больших идей». Не знаю, как скоро этот подход проникнет в среднее образование, но для своих курсов по ИТ-архитектуре я нашел его, как говорится методом проб и ошибок. Ну, например, архитектуру ИТ-решений (solution architecture) и микросервисы можно изучать отдельно. Хотя изучать просто ИТ-архитектуру немного скучно. А изучать микросервисную архитектуру, особенно после большого и долгого хайпа, довольно сложно. Все, вроде бы, и так всё уже об этом знают. Ну, может быть, в общих чертах и недостаточно глубоко. Хотя буквально в каждой группе, первая же из девяти характеристик микросервисной архитектуры по Льюису-Фаулеру оказывает сюрпризом хотя бы для одного из слушателей. А вот изучать и то и другое одновременно полезно и с точки зрения поддержания интереса, и для приобретения конкретных компетентностей. Читать далее Коротко об обучении ИТ-архитекторов

Как понять, что вы разговариваете с настоящим ИТ-архитектором

Архитекторами называют не только людей, занимающихся проектированием ИТ-решений, но и просто хороших специалистов, разбирающихся в определенной области. Многим присваивают титул архитектора по совокупности заслуг. Многие эксперты, занимающиеся самыми различными видами деятельности, в душе считают себя немножко ИТ-архитекторами.

Как нам разобраться кто из них настоящий ИТ-архитектор, суждениям которого можно доверять, а чьи рекомендации стоит перепроверить? Я бы не стал делить ИТ-архитекторов на настоящих и фейковых. Внимание к архитектуре системы, решения или организации в целом – это уже хорошо. Тем не менее, полезным будет иметь некоторую шкалу, характеризующую уровень доверия к предложенным тем или иным экспертом архитектурным решениям(architecture decision). Примерно так же, как в свое время Леонард Ричардсон предложил использовать модель уровней зрелости для проверки соответствия API архитектурному стилю REST. Читать далее Как понять, что вы разговариваете с настоящим ИТ-архитектором

Микросервисы. Закат хайпа?

Всё больше число людей предрекает коррекцию интереса к микросервисной архитектуре. Некоторые даже говорят о надвигающемся возврате к монолитам или чему-то похожему на монолит, но с границами нового типа между модулями. Возможно, в design time такие границы и существуют, но как только приложение запускается на выполнение карета превращается в тыкву граница эта остается исключительно в голове разработчика. В конечном счете, разный функционал либо реализуется в рамках одного процесса либо декомпозируется на несколько процессов. А как иначе? Второй вариант неминуемо приводит к необходимости решения задачи межпроцессного взаимодействия.

Но, действительно, тема микросервисов столь долго держалась на первых полосах блогов и в расписаниях айтишных мероприятия, что многие от неё порядком подустали. Я не думаю, что микросервисы, т.е. независимо развертываемые компоненты систем, куда-то исчезнут. Скорее их будет становиться все больше и больше. Но восприятие их, возможно, изменится. Слишком разные по своему характеру и назначению компоненты сегодня записывают в микросервисы. Приверженцы связанных с микросервисами архитектурных паттернов уже не первый год стараются дистанцироваться от этого чересчур туманного, а зачастую и неверно истолковываемого термина. Вряд ли это желание ослабнет. То, что мы называем этим общим термином сегодня, рассыплется на несколько разных понятий. Перечислю основные из них: Читать далее Микросервисы. Закат хайпа?

Архитектор ИТ-решений

Архитектор ИТ-решения (Solution architect) отвечает за проектирование одного или нескольких приложений или сервисов в организации, обычно являясь участником команды проекта или услуги. Он должен иметь сбалансированное сочетание технических и деловых навыков и часто будет работать под методическим руководством архитектора предприятия (Enterprise architect)…

Не стану полностью переводить более чем внятное описание позиции Архитектора ИТ-решений с страницы What does a solution architect do? сайта СareerExplorer. Но всегда готов обсудить этот профиль деятельности и ответить на ваши вопросы.

Тень цифрового будущего 2.0

К середине десятых годов над нашим миром нависла Тень цифрового будущего. Все уже знали, что скоро наступит время беспилотных автомобилей, умных холодильников и микроволновок из интернета домашних вещей и прочих диковин нового индустриального уклада. Мало кто с ними сталкивался вживую, но никто не сомневался, что они есть. Я даже написал небольшую заметку в конце 2016 года ИТ стратегия в переходный период, в которой посетовал, что тень цифрового будущего над нами нависла, а само оно все никак не приходит. Почему-то не утешали слова Уильяма Гибсона: «Будущее уже наступило. Просто оно еще неравномерно распределено».

Сегодня, медленно, но неотвратимо приходит время разобраться с целями и задачами текущего кризиса года 2020. И кажется: где ты теперь, новая индустриальная революция, ау-ау!  — но не все так просто.

Читать далее Тень цифрового будущего 2.0

Рационализация портфеля приложений

В прошлом году у меня появился новый учебный курс «Практики Архитектуры Предприятия». Формальное описание и программу курса можно посмотреть на сайте https://www.itexpert.ru/eap/, а здесь я хочу дать ему менее формальную характеристику и расставить основные акценты. Уложиться в три предложения я не смог и в итоге получилось пять основных вещей, которые я должен отметить

Во-первых, это курс о рационализации портфеля корпоративных приложений. Под рационализацией или оптимизацией часто понимают сокращение затрат или полный отказ от дальнейшего развития приложения. Это не совсем так. Если разработка целевой архитектуры для вашего приложения привела к подобным последствиям, то вы просто попали не в ту часть списка. Для других приложений результатом рационализации является либо привлечение дополнительных ресурсов и инвестиций, либо, как минимум, толерантное к нему отношение. Знаменитый гартнеровский TIME анализ – это аббревиатура: Tolerate, Invest, Migrate and Eliminate (см., например, Application Portfolio Triage: TIME for APM, Jim Duggan, August 2009). Впрочем, есть и более современные источники, например, вышедший в 2019-м Application rationalization playbook американского Federal Chief Information Officers (CIO) Council. Читать далее Рационализация портфеля приложений

Карта предметной области

Еще одна серия постов из Telegram-канала «Архитектура ИС»

На этот раз о том, почему техника Domain Storytelling (далее DS) сорвав низко висящее яблоко, не съела его, а всего лишь понадкусывала. Читать далее Карта предметной области

Архитектор Предприятия AS IS и TO BE

Если я ничего не напутал, то дело обстояло так. В ходе конференции “Agile Architecture”, проведенной в июле этого года The Open Group в Денвере(Колорадо), состоялся воркшоп по дизайн-мышлению (design thinking) на котором и была придумана приведенная ниже история вымышленных персонажей Лоретты, Арчи1 и Арчи2. Участвовавший в воркшопе Теренс Блевинс (Terence Blevins) — Director of The Open Group Governing Board записал её и опубликовал в блоге THE FUTURE ENTERPRISE ARCHITECT, а Шервин Микер(Sherwin Meeker), тоже участник The Open Group и главный консультант по управлению в IBM – немного отредактировал.

Меня зацепил предложенный формат обсуждения роли архитектора предприятия, но сам текст оставил ощущение некоторой недосказанности. Не полагаясь на свой английский, я попросил перевести эту статью. Чувство недосказанности, однако, полностью не улетучилось. Перечитав исходный текст еще раз, я вдруг вспомнил сессии по разработке ценностного предложения и используемый в них value proposition canvas. В одном из будущих потоков курса по ИТ-архитектуре я рассчитываю провести подобную сессию, надеясь, что наша историю получится ничуть не хуже, чем у коллег (В какой-то мере я уже воспользовался этой идеей в курсе Практики архитектуры предприятия, нарисовав портреты потенциальных слушателей курса).

Чтоб выполненный по моей просьбе перевод не пропал зря выкладываю его в первом комментарии ниже. Вдруг кому-нибудь пригодится (Конечно, в нем многое следовало бы подправить, но у меня на это сейчас абсолютно нет времени. Тем более, я рассчитываю, что слушатели моего курса, создадут как-нибудь не менее интересную историю)