Архитектура цифрового предприятия - стр. 3
•
действия участников системы, в том числе цели действий, принципы деятельности, ограничения и KPI на деятельность;
•
функции участников системы (людей, отделов, смежных бизнесов), которые должны совершать строго определенные действия в определенных последовательностях (конвейеры действий или процессы).
Структурные и поведенческие компоненты – это еще не весь арсенал архитектора. В поле анализа и дизайна входят компоненты самой различной природы: цели, каналы взаимодействия, заинтересованные и влияющие лица, их интересы, требования, решения, принципы, драйверы – все, что может быть выделено как отдельный рассматриваемый фрагмент физической, виртуальной или ментальной реальности, имеющий влияние на успех или надежное функционирование предприятия (см. для примера Рис. 1).
Рис. 1. Взаимосвязи и влияния компонентов архитектуры.
В первую очередь архитектура увязывает конструктивно-функциональные решения с назначением или свойствами конструкции. Но она – не только про внутренне устройство. Архитектура идет дальше и исследует устойчивые умозаключения о контексте, в котором пребывает рассматриваемая система (предприятие), а также как из этого контекста было решено породить именно данный состав целей, назначений, систем, интеграций, процессов, данных и т.п.
Архитектура тех предприятий, предметом переработки или «материалом» которых является информация, включает в себя описание и набор решений по информации: что считать информацией, как информационные единицы связаны друг с другом, какие методы обработки информации следует применять, в какой последовательности и при каких условиях. Именно информация лежит в основе того, что мы называем цифрой.
ИТ-архитектура – это составная часть архитектуры предприятия. Термин «ИТ-архитектура» относится, прежде всего, к программным/ прикладным ИТ-компонентам (а также поддерживающей их инфраструктуре) и в основном отвечает на следующие вопросы: какие функции (сервисы, микросервисы) должны быть у приложений и как они будут распределены между приложениями; какую технологию применять: клиент-сервер, SOA, микросервисы; стоит ли переносить интеграции приложений на шину; на каком оборудовании размещать компоненты приложений, какие компоненты вынести в облако и т.п.
Важно понимать, что при всем желании и удобстве трактовать архитектуру (организованность), как статическое свойство предприятия (существующего или будущего), нельзя не признать, что процесс настройки и тюнинга работы всей организации исполняется постоянно, как у каждого отдельного отдела, так и у всего предприятия в целом, и даже у холдинга, объединяющего несколько различных предприятий. В этом смысле архитектуру можно и нужно рассматривать не только как стационарное состояние организованности, но и как набор транзитных состояний для перехода в будущее, что и представляет собой сущность трансформации.
Как следует из опыта, организованность не является одноактным действием, а требует целенаправленного и постоянного усилия. В связи с этим приведем еще одно определение архитектуры, взятое из акта Клингера-Коэна2:
Архитектура предприятия – это управленческая инженерная дисциплина, представляющая исчерпывающий обзор предприятия, включая стратегическое планирование, организационное планирование, управление взаимодействиями, улучшение бизнес-процессов, управление информацией, знаниями и операциями.