Рубрика: Software architecture

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

Архитектор ИТ-решения (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. В одном из будущих потоков курса по ИТ-архитектуре я рассчитываю провести подобную сессию, надеясь, что наша историю получится ничуть не хуже, чем у коллег (В какой-то мере я уже воспользовался этой идеей в курсе Практики архитектуры предприятия, нарисовав портреты потенциальных слушателей курса).

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