Клуб 4CIO
Архитектура цифрового предприятия

Архитектура цифрового предприятия

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

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

Архитектурирование: мода или насущная необходимость?

Методология трансформации становится насущно востребованной. Но где взять такую методологию?

Ранее, 20-30 лет назад, подобного рода задачи решались в рамках деятельности под названием инжиниринг или организационное развитие. То есть мы этим занимались всегда, правда в существенно меньшем масштабе, реактивно к складывающимся обстоятельствам и не придавая особого значения роли ИТ. Основной акцент уделялся людям, компетенциям, организационным структурам, показателям. Скорость изменений была столь не высокой, что деятельность по их реализации носила вялотекущий функциональный характер. Но в начале XXI века многие бизнесы вступили в фазу комплексных и кардинальных изменений, связанных с глобализацией продаж, разделением труда и кооперацией производств, индивидуализацией продуктов и услуг, ускорением процессов, созданием гибких производственных линий, автоматизацией процессов, повышением роли информации и превращению ее в фактор производства. Это не рядовые изменения! Их сложно совмещать с текущей деятельностью предприятия! Поэтому потребовалась модернизация практик организационного инжиниринга и, как следствие, возникла новая дисциплина, новая терминология и методология, а также их профессиональные носители. Все это объединилось вокруг нового термина – архитектура.

Архитектура – результат деятельности по архитектурированию. Архитектурирование – новый глагол в русском языке, указывающий на деятельность по созданию или изменению архитектуры. Более естественно в русском языке звучит «архитектурный подход к инжинирингу предприятия».

Архитектурный подход объединяет и гармонизирует любые бизнес-инициативы предприятия: смена бизнес-модели, запуск нового канала продаж, внедрение новой ИТ-технологии, роботизация процессов, модернизация инфраструктуры, реализация новой стратегии и т.д.

Понятие архитектуры

Итак, трансформация, как комплексное изменение – это сложный проект, который должен ответить на вопросы, что менять, как менять, зачем менять и какую отдачу это принесёт предприятию. Чтобы понять объект изменения или объект трансформации, его нужно каким-то понятным образом представить (выразить), будь то текущее состояние предприятия, которое предстоит трансформировать, или будущее состояние, или новый бизнес, который предстоит построить.

Представление объекта трансформации может быть выражено через его архитектуру. Здесь под термином «архитектура» подразумевается формальное и комплексное описание (чаще всего – в виде модели) текущего или будущего состояния организации, позволяющее на основании этого описания (модели) сделать различные выводы для заинтересованных лиц из состава руководства.

Данное определение подчеркивает, что результатом архитектурирования является модель, а значит трансформация – это трансформация моделей: текущей модели предприятия в будущую. Это означает, что успех трансформации зависит от качества моделирования! А планировать трансформацию может и должен архитектор. Следующее определение подчеркивает не только сущность необходимого моделирования, но также подразумевает ожидаемые от архитектора компетенции.

Архитектура предприятия (Enterprise Architecture) – это область знаний об организованности (составе, связях и отношениях) отдельных частей предприятия, причем самых разных и абсолютно всех: систем, процессов, людей, инфраструктуры, данных, целей, задач, требований и т.д. Последние 10 лет мы воспринимали организованность только через призму бизнес-процессов или внедрения очередной комплексной системы (CRM, BPMS, ERP). Архитектура смотрит на это шире: цели должны совпадать с ресурсами компании по производству продуктов/услуг, продукты должны адресовать ценности клиента, клиенты взаимодействуют с компанией через предпочтительные для них каналы, каналы поддерживаются процессами, процессы обеспечиваются ИТ-системами, системам нужна инфраструктура, системы сращиваются с АСУ ТП, АСУ ТП изменяет свою природу: монолит разделяется на сеть взаимодействующих IoT-устройств. Всё пронизано целесообразностью и рациональностью, всё пронизано сотнями решений и корректирующих уточнений.

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

Таким образом архитектура (и архитектурирование) имеют несколько очевидных аспектов:

• 

Архитектура – это статическое описание всех аспектов функционирования предприятия.

• 

Архитектура – это метод изменения предприятия.

• 

Архитектура – это методология и дисциплина действий архитекторов.

• 

Архитектура – это принятие бизнес-, ИТ- и технических решений.

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

В соответствии со стандартом IEEE архитектура определяется следующим образом:

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

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

Цитата из Стандарта IEEE 42010:2011: Архитектура какой-либо системы представляет собой то, что является существенным относительно рассматриваемой системы в ее окружающей среде. Не существует единственной характеристики того, что является существенным или основным для системы; такая характеристика может принадлежать любому из следующего:

• 

компоненту (классу компонентов) системы;

• 

тому, как компоненты устроены или взаимосвязаны;

• 

принципам организации системы или проекта;

• 

принципам, управляющим развитием системы в её жизненном цикле.

Источник: Стандарт ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011. Краткие заметки по стандарту с учетом выхода в 2022 году новой его версии смотри в Приложении 2.

Как понять и исследовать организованность? Любая система для целей снижения её сложности разбивается на компоненты. Именно через эти компоненты и их связи архитектуры описываются (моделируются) и различаются. Основными видами компонентов являются структурные компоненты, а именно: подразделения, группы, ИТ-системы, базы данных, станки, конвейеры, офисы, склады (и так далее), но также и поведенческие:

• 

действия участников системы, в том числе цели действий, принципы деятельности, ограничения и KPI на деятельность;

• 

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

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

Рис. 1. Взаимосвязи и влияния компонентов архитектуры.

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

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

ИТ-архитектура – это составная часть архитектуры предприятия. Термин «ИТ-архитектура» относится, прежде всего, к программным/ прикладным ИТ-компонентам (а также поддерживающей их инфраструктуре) и в основном отвечает на следующие вопросы: какие функции (сервисы, микросервисы) должны быть у приложений и как они будут распределены между приложениями; какую технологию применять: клиент-сервер, SOA, микросервисы; стоит ли переносить интеграции приложений на шину; на каком оборудовании размещать компоненты приложений, какие компоненты вынести в облако и т.п.

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

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

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

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

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

При рассмотрении вопросов архитектуры выделяют две кардинально разных фазы: анализ архитектуры (для существующих предприятий) и синтез архитектуры (для новых или трансформируемых предприятий). Рассмотрим эти фазы в двух следующих разделах.

Анализ архитектуры = анализ предприятия, как целостной системы

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

Здесь следует обратить внимание на необходимость различать два подхода к ТРАНСФОРМАЦИИ:

Подход №1. Трансформация – это тщательно спланированный перевод предприятия в качественно новое состояние под условным названием «Цифровое предприятие».

Подход №2. Трансформация – это пребывание предприятия в цикле непрерывных изменений и адаптации, что подразумевает постоянную подстройку предприятия под ожидания потребителей, рынка, участников экосистемы.

Подчеркиваем, что в данной главе учебника излагается подход №1 – целостное проектирование заранее продуманной конструкции предприятия. Это может быть как запуск нового бизнеса с нуля, так и скачок в деятельности существующей организации. Подход №2 – это итеративный подход, цель которого состоит в постепенном изменении предприятия с постоянной коррекцией образа будущего. Одним из вариантов подхода №2 является MVP-подход, основанный на минимальных вложениях в MVP и постепенное развитие MVP по ходу его пилотирования.

Прежде всего обратим внимание на различие между реальностью и её моделью. Само предприятие и его компоненты – цели, участники, их деятельность и результаты труда – это реальность. Но решения об этой реальности мы принимаем на основании моделей: языковых, текстовых, графических, имитационных и пр. Архитектура, как и любой другой результат проектной деятельности – это модель³. Модель текущей или будущей реальности. И архитектор работает именно с моделями, создавая их, как реконструкцию настоящего или как замысел будущего. Архитектурные модели имеют свои особенности: они информационные (состоят из информационных элементов) и многослойные. Таким образом, запомним: одному реальному компоненту предприятия соответствует один элемент в модели.

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

Рис. 2. Метамодель типового архитектурного репозитория.

Декомпозиция архитектурной модели на домены и слои

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

• 

Домен «Стратегия».

• 

Домен «Контекст».

• 

Домен или аспект «Мотивация».

• 

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

• 

Домен «Данные». С этим доменом устойчиво связана архитектура данных.

• 

Домен «ИТ-Приложения» и связанные с ним архитектура приложений или интеграционная архитектура.

• 

Домен ИТ-технологий и технологическая архитектура

⁴

.

• 

Домен производства и соответственно производственная архитектура.

Приведенные домены (мы будем использовать именно слово «домен», как наиболее употребительное в литературе) можно найти в методических рекомендациях таких известных фреймворков, как TOGAF, Захман, NAF (NATO Architecture Framework), а также в руководстве по языку, наиболее распространенному среди корпоративных архитекторов, – Archimate. Каждый домен состоит из одного и более слоёв архитектуры. Состав слоёв может быть разным – все зависит от того, какая задача решается в текущий момент (см. выше о существенности в определение архитектуры из Стандарта IEEE 42010:2011) и какой аспект моделирования превалирует над другими. Хорошие примеры слоёв даёт TOGAF, где аллегория слоя получила весьма практическое воплощение в виде архитектурного каталога.

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

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

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

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

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

Излагаемые ниже слои архитектуры основаны на концептах Архимейт версии 3 и выше. Совокупность таких концептов образует DSL архитектурной дисциплины (Domain Specific Language). По-русски мы называем такие языки «птичьими языками», то есть язык профессионального сообщества в определенной области знаний. Цель такого языка – обеспечить общение профессионалов. Поэтому ничего удивительного в том, что многим такой язык будет не понятен, а его освоение требует усилий и даже сертификации.

Домен №1. Мотивация и стратегия

Данный домен систематизирует (выделяет/находит, каталогизирует, связывает) элементы, которые фиксируют внешний периметр компании и его трансформацию в целеполагание компании. Здесь каталогизируются цели, ограничения и KPI, которыми ежедневно будут руководствоваться все подразделения предприятия. Домен «Мотивация и стратегия» – это граница рассматриваемой системы (то есть предприятия). Обычно в этом домене описывается также всё, что имеем отношение к контексту предприятия. Рассмотрение системы вне контекста ее функционирования считается в системной инженерии бессмысленным занятием.

Следующие каталоги архитектурных элементов образуют данный домен:

• 

глоссарий предприятия

;

• 

каталог лиц и сторон, заинтересованных в предприятии;

• 

каталог драйверов бизнеса (постоянно действующих факторов внешней среды, как например, импортозамещение, цифровизация);

• 

каталог требований и ограничений (требования регуляторов, законов, стандарты отрасли, требования самого бизнеса к развитию или трансформации);

• 

каталог целей бизнеса, каталог KPI;

• 

каталог ресурсов предприятия, каталог способностей (

capability

) предприятия;

• 

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

• 

ключевые проекты, программы или инициативы;

• 

каталог рисков.

Это не полный перечень каталогов в домене «Мотивация и стратегия». Полный перечень см. в методичке Open Group® по Archimate® по таким доменам, как «Стратегия», «Имплементация» и по аспекту «Мотивация». У Захмана данный домен обозначен как Executive Perspective.

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

Домен №2. Деятельность

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

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

Каталоги «процессов», «информации» и «подразделений» являются ключевыми каталогами элементов данного домена, так как фактически своими элементами и связями они устанавливают операционную модель предприятия.

Таким образом бизнес-модель и операционная модель являются подмножеством полной архитектурной модели предприятия.

Следующие каталоги архитектурных элементов составляются для данного домена:

• 

каталог продуктов (в том числе типов продуктов) и/или услуг, как вариант – каталог государственных услуг;

• 

каталог подразделений и каталог функций подразделений (орг.структура);

• 

каталог процессов

;

• 

каталог информационных единиц (совокупность информационных единиц и их связей образуют концептуальную объектную модель данных);

• 

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Примечания

1

Слово «аспект» здесь было бы лучше заменить русским словом «ипостась», которое, к сожалению, не прижилось в светском и инженерном дискурсе.

Вернуться

2

Основано на материалах по Реформе управления ИТ (Information Technology Management Reform Act), принятых конгрессом США в 1996 году и известных также как Акт Клингера-Коэна (Clinger-Cohen Act, CCA). Материалы акта пополняются и обновляются с 1996 и по настоящее время.

Вернуться

3

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

Вернуться

4

Здесь, чаще всего, имеется в виду «ИТ-инфраструктура, поддерживающая работу информационных технологий».

Вернуться