В прошлом году у меня появился новый учебный курс «Практики Архитектуры Предприятия». Формальное описание и программу курса можно посмотреть на сайте 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.
Второе. Попадание приложения в ту или иную часть списка определяется его возможностями и ограничениями. Причем ограничения сосредоточены как бы внутри приложения. Определяются они размером технического долга (technical debt), устареванием технологий, практиками доработки и развертывания приложения и рядом прочих ограничений, которые принято называть архитектурными.
Следующий момент: возможности. Возможности приложения чаще лежат вовне и зависят от того какие business capability и как именно эти приложения поддерживают. Зачастую приложение сочетает большой набор ограничений с еще большим спектром возможностей. Бывает и наоборот: замечательное приложение до поры до времени мирно существует вдалеке от цепочек создания ценности, но случается проект трансформации.
Проект agile и/или digital трансформации – это четвертая характеристика курса. Мы намеренно рассматриваем наиболее сложный контекст уточнения текущий и выработки целевой архитектуры (а заодно и дорожной карты путешествия из состояния A в направлении состояния B). С большой вероятностью это будет внезапно случившийся проект трансформации. Чтоб разобраться с текущим набором приложений и договориться об изменениях у вас будет несколько недель. И делать всё придется довольно шустро, завидуя длительности двухнедельных спринтов у разработчиков. Затем окно возможностей закроется, ключевые решения будут приняты и следующие 2-3 года пройдут в границах этих решений.
И еще одна характеристика курса. Практики архитектуры предприятия это только начало, т.к. сказать первый сезон или первая ступень. Уже в этом году я планирую запустить продолжение «Практики архитектуры предприятия. Цифровые услуги», базирующееся, в частности, на стандарте The Open Group Digital Practitioner Body of Knowledge™(DPBoK™ Standard). Эта история о том, как нарисовать широкоформатную картинку надвигающегося цифрового будущего организации, включающего омниканальность, API для развития партнерской экосистемы и взаимодействия с регуляторами, поддержку клиентов, продуктовую и клиентскую аналитику. Разговор о том, почему не стоит игнорировать cloud-native архитектуры и во что обойдется модернизация унаследованных приложений.