В преддверии старта курса "Enterprise Architect" подготовили для вас текстовую версию демоурока, который провел эксперт OTUS - Петр Подымов.

В рамках урока поговорили:

• об обоснованных структурных изменениях в компании в быстро меняющихся условиях;

• о применении архитектурного подхода в вопросах трансформации;

• увидели, что же такое архитектурный подход, для чего он нужен, чем обусловлено его применение.

В будущем Курс «Enterprise Architect» будет построен таким образом, что мы сформулируем бизнес-кейс для трансформации и далее последовательно будем  его решать, чередуя теоретические и практические занятия.

Зачем нужна цифровая трансформация?

Понятно, что цифровая трансформация в различных индустриях продиктована разными причинами и по-разному воплощается.

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

Но, если взять более популярные сейчас модели, группы компаний, которые строят экосистемы, создают платформы, то бизнес в таких компаниях меняется весьма существенно, так как значительно перестраивается сама модель работы и модель взаимодействия.

Почему это происходит?

Имеют место два фактора:  

• Меняются клиенты, меняется рынок. Рынок становится более быстрым. Клиенты становятся более разборчивыми и требовательными.

• Меняются конкуренты. Если раньше банки конкурировали с классическими банками, а ритейлеры с классическими ритейлерами, то сейчас банки начинают конкурировать с финтехом и цифровыми экосистемами. Ритейлеры конкурируют с цифровыми marketplace, которые занимают все большую долю на рынке.

И в совокупности эти факторы требуют совершенно другого от бизнеса.

Если очень коротко сформулировать идею, то в наиболее выгодном положении будет тот, кто займет место между клиентом и его решением. То есть компания, которая как бренд будет сопровождать клиента на всем его пути, и непосредственно решать его задачи end to end (от начала до конца) в той мере, в какой это возможно/необходимо.

Очевидно, что без цифровизации, без трансформации деятельности такое невозможно сделать. Поэтому компании продолжают цифровую трансформацию, чтобы быть более клиентоцентричными, быть более интересными не только для клиентов, но и для партнеров (в целях расширения экосистемы), быть более эффективными.  

Что такое цифровая трансформация, как ее измерить?

Цифровая трансформация достаточно многогранна. Речь не идет о создании цифрового канала продаж, о запуске электронной коммерции – это лишь некоторая часть цифровой трансформации. Любой актуальный продукт, бизнес-продукт, услуга, сейчас должны быть представлены в цифровом мире и над этим тоже нужно поработать. Но это ещё не всё - сама компания должна тоже измениться.

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

 1. Неисчерпаемый перечень.

2. Скорость  внедрения изменений

3. Данные dеitadreavon

4. Про клиента

5. Открытость  

6. Быть  актуальными

Также фундаментом любой архитектуры являются такие параметры:

• Эффективность;

• Безопасность;

• Надежность.

Перечисленные параметры – тот базис, о котором, трансформируя организацию, мы не должны забывать.

Поговорив о сути и направлении цифровой трансформации, следует рассказать о том, как и где принимаются решения?

Важный момент для современного архитектора (в широком смысле - агента изменений), то есть человека, который хотел бы/должен привнести изменения в организацию, то  есть оказать позитивное влияние на развитие своей компании - работа этого человека должна быть:

• с одной стороны, достаточно структурированной и системной;

• с другой стороны, этот человек должен хорошо понимать, куда компания движется, и как его идеи в эту стратегию встраиваются;

• также важна коммуникация.

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

Таким образом, если ты хочешь внести улучшение в компании:

• у тебя есть идея;

• ты знаешь, как эту идею структурировать.

Ты должен:

• Идею описать;

• Хорошо представить идею;

• Обосновать;

• Понимать, каким образом компания примет решение о том, что эта идея будет запущена или не будет.

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

Как устроено принятие решения об изменениях в организации.

Любое  изменение –  это выделение бюджета.
Любое  выделение бюджета – это инвестиции.

 Бюджет  может выделяться:

• Напрямую, комитетом, в виде какой-то суммы;

• Косвенно, когда есть команда работающая над каким-то направлением и она принимает решение об инвестициях. Куда направить свое время.

Важно понимать, какая «фича» более актуальна, более приоритетна, с учетом текущих ограничений, текущих планов.

Если подняться на уровень организации в целом, мы увидим, что люди, отвечающие за бюджет, за выделение денежных средств мыслят терминами инвестора, а не обывателя.

Процесс, формирующий общий портфель изменений

Инвестиционная  культура. Находится наверху процесса, формирующего общий портфель изменений. Определяет подход организации к вложению денежных средств. Например, трансформировать себя – это один из атрибутов культуры.

Инвестиционная стратегия. Склонность к риску. Насколько мы готовы экспериментировать. Насколько консервативны при отборе решений, в которые мы вкладываем деньги.

Инвестиционный процесс. Жизненный цикл, последовательность шагов, как эти инвестиционные решения принимаются. Это уровень спонсора любой инициативы.

Исполнение портфеля. Управление результативностью портфеля. Качество  проектной деятельности. Метрики, попадание в сроки.

Архитектура предприятия. Дисциплина, которая позволяет структурировать активности, инициативы, изменения, которые нужны компании, чтобы достичь стратегических целей.

Те, кто занимается изменениями, кто придет на новый курс, находится в треугольнике: 

1. Захватываем  архитектуру предприятия - это  наша основа.

2. Заглядываем и видим  портфель изменений.

3. Смотрим  на результативность портфеля  с точки зрения обратной связи. (сдвигаются /не сдвигаются сроки, что меняется).

4. Участвуем  в инвестиционном процессе.

TOGAF – достаточно старый стандарт, которому больше 20 лет. Пережил несколько реинкарнаций, без существенных изменений.

The Open Agile Architecture – новый стандарт. Как  заниматься архитектурой в agile среде.

Почему именно ADM (Architecture Development Method)?

Стандарт Тogaf, достаточно громоздкий. Мало кто им пользовался, как методическими указаниями. Однако, помимо того, что он содержит ряд здравых базовых мыслей, связанных с декомпозицией, в нем есть жизненный цикл архитектуры предприятия, цикл разработки архитектуры. Если мы пойдем в agile без понимания этой логической последовательности действий, то можем потерять саму архитектуру.

Поэтому, в нашем курсе мы фокусируемся на последовательной проработке бизнес-кейса и это вовсе не означает, что мы не гибкие. В реальной жизни с этим бизнес-кейсом будем работать гибко, с изменением требований. Но логика действий и преемственность этапов должна соблюдаться как фундамент.

АDM

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

Мы не будем заострять своё внимание на предварительной фазе и сразу перейдем к жизненному циклу:

A. Видение архитектуры. Исходя из того куда движется компания, понимание того, где мы находимся и куда мы хотим прийти, какой наша организация должна стать.
B. Бизнес-архитектура. Более структурированный анализ. Как должен быть устроен наш бизнес. Как  должна эволюционировать наша бизнес-модель, и операционной модель.
C. Архитектура информационных систем.
D. Техническая архитектура. Как это реализуется технологически.
E. Возможности и решения. Какие технические решения нам нужны, чтобы реализовать функции в тех приложениях, которые мы у себя заложили, или которые решили развивать.
F. Планирование миграции. Планируем переход из состояния А, в состояние Б. 
G. Управление реализацией. Как некая дорожная карта изменений компании последовательно/параллельно. Важно следить за отклонениями реализации от видения, архитектуры движения, которые мы нарисовали ранее.
H. Управление изменениями архитектуры. Любое событие, которое возникает в реальном мире, может повлиять на наше понимание организации, понимание того, куда эта организация должна двигаться.

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

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

Последовательность действий

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

Анализ бизнес-архитектуры

Первый шаг – это разработка бизнес-архитектуры в какой-то области. Бизнес-архитектура – это не только ландшафт бизнес-процесса.

Существует определенный подход, который рассматривает бизнес-архитектуру, как отдельную дисциплину. В  классической западной школе существует гильдия бизнес-архитектуры. Она существуют по сей день.

Гильдия бизнес-архитектуры на базовом уровне показывает бизнес-архитектуру, как 2 концентрических круга.

• В центре, в ядре бизнес-архитектуры находится – Сapability. Возможности, бизнес-компетенция организации, что организация умеет делать, как некий объект.

• Value Streams – потоки ценности. Фундаментальные вещи, о том как организация доставляет ценность? Как организация работает? В чем ее бизнес состоит?

• Information – то как элементы бизнес-архитектуры связаны с архитектурой информационной.

• Organization – привязка всего к организационной структуре.

• Vision, strategy, and tactics – мотивация компании. Видение стратегии, куда компания движется.

• Stakeholder – лица, принимающие решения.

• Policies, Rules, Regulations – политики.

• Products & Services – продукты и услуги, то есть то, что на витрине перед клиентом.

• Initiatives & Projects – инициативы и проекты, то есть объекты изменений.

• Metrics & Measures – показатели. То, как мы это мерим.

Начать лучше всего с capability (компетенции).
Под компетенциями понимается совокупность:

• навыков и знаний;

• методологий и подходов;

• технологических инструментов.

Компетенция –  это возможность организации делать что-то.

ПРИМЕР:

Есть артефакт capability map. Его нужно создавать, если мы рассматриваем организацию в целом. Если мы решаем задачу более прикладную  в данный момент, мы также можем применить этот подход, но у нас нет еще готовой карты возможности. Поэтому, мы можем пойти последовательно.

 

Здесь мы видим, что на одной картинке объединены четыре сущности.

Поток ценностей. Это подготовка и запуск маркетинговых кампаний. В этой сравнительно узкой, но важной области, есть свой поток ценностей, своя этапность. Начиная с оценки, заканчивая исполнением. Оценка, подготовка, исполнение.

Далее, изображен верхнеуровневый процесс, где каждый квадратик – это и этап процесса, но это и компетенция, которая нужна компании для того, чтобы его реализовать.

Для того чтобы реализовать этот процесс, нужно:

• уметь реализовать функционал регистрации согласования компании;

• должна быть реализована настройка;

• должно быть моделирование;

• анализ хода компаний;

• обработка коммуникации в каналах коммуникаций.

Для того, чтобы запустить компанию, нам нужно прокачать все эти компетенции, посмотреть в какой степени они сейчас, насколько они приоритетны для выполнения данной конкретной задачи, насколько они требуют прокачки.

Здесь задействовано достаточно много систем.
Одновременно и поток ценностей, и процессный взгляд, и компетенции компании и приложение.

С  помощью таких достаточно простых иллюстраций, можно понять, что нужно делать, получить базу для выявления узких мест. 

Информационная архитектура

Информационная архитектура - это архитектура информаций, то, как семантически информация в нашей организации устроена. По сути модель данных, но концептуальная.

 Для чего она нужна?

• Чтобы понимать, какие данные у нас в организации есть, как они используются, как они структурированы.

• Прикладное значение - выделение контекстов.

Для дальнейшей работы достаточно важно понимать, кто за что отвечает. Разделить контексты, зоны ответственности.
Разделение контекстов помогает разделять и приложения и уже делать более чёткое проектирование в дальнейшем.

На этом уровне, пока мы не выделяем контексты, пока мы описали всю информацию, важно понимать:

• какие объекты есть;

• кто за них отвечает;

• как эти объекты появляются и потребляются в рамках потока ценностей.

 

Что мы видим на рисунке?

Контекст продаж:

• клиент;

• продукт;

• территория;

• человек;

• продавец и тд.

 Контекст поддержки:

• клиент;

• продукт;

• ticket  (инцидент);

• дефект;

• связь его с версией продукта.

В рамках этих контекстов начинаем прикладное проектирование.

Архитектура приложений

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

Важнее разделить контексты внутри организации на логические подразделения (домены), дать  им определенную свободу. Понимать, как эти домены взаимодействуют между собой. Внутри каждого домена будут взаимодействия в своих приложениях.

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

Для того, чтобы модульность работала хорошо, нужна открытость.

Должно быть понятно, как области взаимодействуют между собой, по каким правилам, через  какие интерфейсы. И ниже внутри областей также удобно применять этот подход, когда отдельные  микро-сервисы взаимодействуют между собой по определенным интерфейсам, развиваясь каждый, независимо друг от друга.

Рациональность – зачем повторять одну и ту же функцию в разных местах? Лучше получать синергитический эффект от реализации однотипных функций с помощью одного инструмента.

Руководствуясь этими базовыми принципами не так сложно построить архитектуру приложения.

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

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

Следующая фаза

На изображении мы видим выбор между готовой платформой из коробки, и открытой системой.

Мы идем по такой цепочке:

Мы прошли всю цепочку, приведённую выше, поняли какие сценарии хотим автоматизировать, для чего мы выбираем решение, какие функции оно будет выполнять (где, в каких областях бизнеса). Выбирали мы под решение конкретных бизнес-задач.

И только после этого мы выбрали и наш выбор обоснован - понятно на что мы тратим деньги, понятно почему. 

Потом, переходя из плоскости предприятия в плоскость решений, выбрав решение, смотрим, как его правильно спроектировать/построить. 

Как строятся современные системы

Выделяем отдельно презентационный слой.

• делаем определенный универсальный интерфейс.

Выделяем слой бизнес-логики, в который постепенно наращиваем функционально:

• процессный движок;

• движок бизнес-правил;

• движок отработки кейсов.

 Интеграционный слой, который работает с внешними приложениями.

 Инфраструктурный слой:

• Мониторинг;

• Хранение;

• Безопасность;

• Развёртывание.

Общие принципы закладываем универсальные стандарты, которыми руководствуемся.

В реальной жизни мы запускаем  эти функции. Каждый  слой  взаимодействует с другими через внутренние api. Также есть внешний api, через который идёт взаимодействие  с окружающей системой.

План миграции

Наша картина была бы не полной, если мы не составили план.

План, который показывает, каким образом то решение, которое было принято выше, мы будем внедрять и развивать: 

• Какой у нас общий прогноз на дальнейшее развитие этого решения?

• Какие компетенции постепенно нам нужно будет добавить в команду?

• По каким этапам у нас будет идти развитие?

• Как мы будем сочетать развитие бизнес-возможности и развитие платформы, которые потом можно будет переиспользовать для других бизнес-направлений?

После того, как это всё представили и выстроили, мы можем считать, что мы провели архитектурные исследования: вместе с топ-менеджерами приняли решение о том, что такому-то продукту быть, и продукт должен двигаться в этом направлении. Обладать такими-то характеристиками и взаимодействовать с другими продуктами по определенным правилам.

Это архитектурный подход. Подход, логически следующий из togaf. Этим подходом можно пользоваться достаточно широко при запуске любого продукта.

На уровне предприятия, когда мы говорим об архитектуре компании в целом, мы помогаем запуску такого рода инициатив, подходов и процессов тем, что по сути формируем площадку для этого запуска, посредством того, что мы создаем карты компетенции всей компании.

Это база, которая помогает каждый раз запускать проще и легче ценные для бизнеса идеи.

Основная ценность – в запуске таких идей. Некая основа (карта), которая помогает делать всё остальное.

Материал подготовлен в преддверии старта курса "Enterprise Architect"

• Узнать подробнее о курсе