Стратегия и архитектура организации
“
Гаррис спросил, бывал ли я когда-нибудь в Хэмптон-Кортском лабиринте. Сам он, по его словам, заходил туда один раз, чтобы показать кому-то, как лучше пройти. Он изучал лабиринт по плану, который казался до глупости простым, так что жалко было даже платить два пенса за вход. Гаррис полагал, что этот план был издан в насмешку, так как он ничуть не был похож на подлинный лабиринт и только сбивал с толку.
Скорость изменений и возрастание неопределенности требуют новых
стратегических подходов к развитию организации и ее деятельности.
Внутренним устройством организаций, которое обеспечивает их адаптивность, сегодня занимается такое междисциплинарное
направление, как архитектура организации. Тщательная проработка
архитектуры позволяет обеспечить практическую реализацию
стратегии, чтобы она не осталась только «на бумаге».
стратегических подходов к развитию организации и ее деятельности.
Внутренним устройством организаций, которое обеспечивает их адаптивность, сегодня занимается такое междисциплинарное
направление, как архитектура организации. Тщательная проработка
архитектуры позволяет обеспечить практическую реализацию
стратегии, чтобы она не осталась только «на бумаге».
Автор:
П. М. Потеев, В. Г. Рудь
П. М. Потеев, В. Г. Рудь
5.1 Что такое архитектура организации
5.1.1 Архитектура: слои и домены
Время чтения — 21 минут
Архитектура организации (Enterprise Architecture) — это область знаний об организованности (составе, связях и отношениях) отдельных элементов предприятия: систем, процессов, людей, инфраструктуры, данных, целей, задач, требований и т. д. Архитектура — это проектирование, а его результат — набор схем, задающих структуру организации, поведение элементов структуры и их взаимосвязи: информационные, организационные, технологические
Рисунок 5.1
Архитектура организации
- структурные элементы — например, подразделения, группы, ИТ-системы, базы данных, станки, конвейеры, офисы, склады;
- поведенческие элементы — действия и функции участников системы (людей, отделов, смежных бизнесов), которые должны совершать свою деятельность в определенных последовательностях в виде процессов;
- пассивные элементы в виде документов, объектов данных, цифровых двойников реальности;
- элементы мотивации и целеполагания: цели действий, принципы деятельности, правовые нормы, драйверы рынка и интересы отдельных стейкхолдеров.
Архитектура предприятия как дисциплина все больше и больше переплетается с такой областью менеджмента, как теория организации: архитекторы все больше вторгаются на территорию менеджеров, привнося в управление инженерные методы проектирования и контроля. За менеджерами бесспорно остаются лидерство, управление культурой, фокусировка, целеполагание и собственно контроль.
Типизированные блоки архитектуры называют компонентами, или слоями архитектуры . На рисунке 5.2 приведены базовые компоненты архитектуры согласно методологии TOGAF (The Open Group Architecture Framework). Де-факто фреймворк TOGAF стал стандартом описания архитектуры предприятия и может использоваться любой организацией, разрабатывающей собственную архитектуру.
Для удобства описания авторы раздела называют компоненты архитектуры слоями. Хотя это не полностью равнозначные понятия, с точки зрения введения в архитектурный подход разница между ними несущественна. Подробнее см. Рудь В. Слои корпоративной архитектуры / Блог «Архитектура Digital».
TOGAF (The Open Group Architecture Framework) — методология описания архитектуры ИТ и предприятия, в том числе метод ее трансформации, разработанные консорциумом Open Group. Основной акцент в методологии делается на представлении в виде компонентов всех технологий и аспектов жизнедеятельности предприятия. Подробнее см. TOGAF // The Open Group.
Термин framework можно перевести как «рамочная модель» или «каркас»; это логическая структура для классификации и организации информации о сложном явлении или системе.
ArchiMate — еще один технический стандарт от консорциума Open Group, который поддерживается различными вендорами и консалтинговыми фирмами. ArchiMate Standards // The Open Group.
Подробнее о слоях и доменах см. Рудь В. Слои корпоративной архитектуры / Блог «Архитектура Digital».
Process Classification Framework // APQC.
В ассоциации TM Forum разработан ряд стандартов и рекомендаций. См. TM Forum.
Рисунок 5.2
Базовые компоненты (слои) архитектуры в методологии TOGAF
Язык моделирования архитектуры предприятия ArchiMate расширяет базовый состав компонентов для целей моделирования всех архитектурных нюансов организации и сопряжения архитектурных моделей с ранее утвердившимися подходами.
ArchiMate — это тщательно выверенный архитектурный язык, имеющий целью формальное описание различных аспектов сложных социотехнических систем, включая организации и группы организаций, холдинги, министерства и их подведомственные организации, логистические цепочки и экосистемы.
В дальнейшем изложении и примерах используется расширенный состав компонентов (слоев) архитектуры, заимствованный из ArchiMate.Архитектурная практика использует более 60 слоев — своего рода строительных блоков, с помощью которых можно описать текущее или будущее состояние организации . К каждому слою относится набор элементов, например:
- Слой «Драйверы». Может включать такие элементы, как «Импортозамещение», «Цифровизация», «Противодействие эпидемии COVID-19».
- Слой «Системы». Его образуют такие элементы, как «СRM», «ЭДО», «Exchange», «Кадры», «Склад», «Портал».
- Слой «ИТ-сервисы». В нем расположены, к примеру, «Предоставление списка неоплаченных штрафов», «Предоставление данных по адресу регистрации».
- Слой «Подразделения». Слой организационных единиц, попадающих в охват стратегии трансформации. Включает, например, профильные подразделения ОИВ и подведомственные организации.
Таким образом, слой — это архитектурный класс, а элемент — конкретный представитель или экземпляр класса. 60+ слоев для удобства объединяют в шесть доменов:
1
домен стратегии и мотивации;
2
домен бизнес-деятельности;
3
домен данных;
4
домен ИТ-приложений;
5
домен ИТ-инфраструктуры;
6
домен физической инфраструктуры.
Основные домены и входящие в них слои, которые используются при проектировании архитектуры организации наиболее часто, схематически показаны на рисунке 5.3.
Рисунок 5.3
Основные домены и наиболее часто используемые слои архитектуры
В каждый слой войдут десятки, возможно, сотни элементов. Благодаря выделению слоев, их наполнению и связыванию появляется возможность управлять сложностью организации, ее элементами и их отношениями.
Осознание архитектуры организации, ее коррекция и развитие не могут происходить автоматически и должны быть чьей-то обязанностью. В организациях уже существуют подразделения, которые управляют отдельными компонентами архитектуры, например службы нормативно-справочной информации, группы ИТ-архитекторов. Цифровая трансформация требует консолидации усилий этих, нередко разрозненных, групп в выделенную группу управления архитектурой в команде ЦТ.
Управляемость достигается за счет выполнения группой управления архитектурой следующих обязанностей: поддержки целостности каждого слоя; назначения владельца слоя; создания паспорта для каждого элемента слоя; создания паспорта для каждой связи внутри слоя и с элементами других слоев.
Откуда аналитики и архитекторы берут элементы для каждого слоя? Во-первых, это стандартный результат работы профессионального аналитика. Во-вторых, используются (особенно на стадии зарождения архитектурной практики) референсные модели (например, APQC , TM_FORUM ). В-третьих, зрелая организация, функционирующая на протяжении многих лет, уже, как правило, имеет набор элементов для управления и развития. Однако при трансформации описать существующие слои и их элементы недостаточно, нужно определить их взаимосвязи и направления развития.
Чтобы лучше понимать, почему мы используем идею архитектурных слоев в организации, важно помнить, что мы говорим о цифровизации и цифровой трансформации, а значит, опираемся на подходы, работающие в сфере ИТ. Слои архитектуры можно воспринимать по аналогии с модулями информационной системы: модуль данных, бухгалтерский, модуль управления данными, модуль управления кадрами и т. д. Из них, как из элементов конструктора LEGO (которые далее будем называть условно «кубиками»), мы будем собирать нужную нам систему или организацию.
Тот, кто занимается стратегией, должен заранее описать эти «кубики» и их взаимосвязи. Но это не значит, что он обязан учесть абсолютно все виды «кубиков» и все возможные отношения между ними. В зависимости от типа организации, уровня цифровой зрелости и задач, которые должна решить стратегия, можно для начала ограничиться более узким набором строительных элементов. Например, для начала можно:
- выбрать и описать один слой (например, составить реестр ИТ-систем с рядом атрибутов, таких как производитель, ответственный, количество лицензий);
- построить карту процессов, описать их и провести оптимизацию некоторых из них (например, уменьшить количество шагов согласования отпуска или командировки);
- связать слой процессов со слоем систем, определив тем самым наиболее критичные для автоматизации области процессов.
Оптимальным вариантом будет выбор для трансформации только некоторых элементов и первого пилотного слоя. Речь не идет обязательно о масштабных технологических изменениях. Первые шаги трансформации в рамках одного-двух слоев можно реализовать быстро и без больших затрат за счет анализа и оптимизации некоторых процессов.
В свете цифровой трансформации большинство «кубиков» будет принимать все более цифровой вид, будь то действие по расчету стоимости услуги или принятие решения о размере страховой суммы. Владельцы процесса или продукта в дальнейшем будут управлять не бизнес-процессами, а функциями систем, интеграциями и, например, правилами в настройках искусственного интеллекта.
Рассмотрим, как изменяются несколько слоев архитектуры при трансформации в цифровой вид одной конкретной муниципальной услуги — выдачи муниципальным органом власти разрешения на строительство. В традиционном бумажном формате конкретное структурное подразделение работает на основании столь же традиционного регламента предоставления услуги. При этом у него есть полномочия запрашивать информацию как у заявителя, так и у смежных подразделений либо у органов государственной власти (также в бумажном, не цифровом виде).
В таблице 5.1 показано, что происходит с элементами слоев архитектуры при переводе этой услуги в цифровой вид. Списки изменений и затронутых слоев и элементов неполны, содержание изменений дано в упрощенном виде. В частности, не учитываются уровни органов государственной власти (федеральный, региональный, муниципальный) и соответствующие им уровни информационных систем. В приведенном примере очевиден рефакторинг, то есть радикальная переработка слоя деятельности и архитектуры в целом: бумажный регламент как единица контроля и управления уходит в прошлое и заменяется набором параметров работы сервиса.
Таблица 5.1
Изменение слоев архитектуры при цифровой трансформации муниципальной услуги по выдаче разрешений на строительство
Итак, архитектурный подход дает нам набор строительных элементов, с помощью которых может быть описано текущее или будущее состояние организации. Строительные элементы одного типа образуют слой. Таких типов более 60, а значит, более 60 слоев возможно выделить и описать с целью анализа текущего состояния или проектирования будущего.
5.1.2 Архитектурные решения
Еще одним важнейшим компонентом проектирования и создания архитектуры является собственно архитектурное решение — это управленческое решение, согласно которому на предприятии появляется тот или иной элемент (цель, подразделение, функция, процесс, система, объект данных или инфопоток и т. д.) с определенным набором свойств и взаимосвязей.
Не следует путать управленческое решение с платформенным, описанным в разделе 6.
С точки зрения архитектурного подхода управление развитием организации становится последовательностью архитектурных решений. Это могут быть не только решения типа «добавить новый элемент», но и решения типа «исключить ненужное» или «модифицировать устаревшее». Например, архитектурным решением может стать появление новой функции госоргана, что повлияет на оргструктуру и должно быть отражено в нормативных документах; кроме того, новая функция госоргана повлечет появление новых функций ИТ-систем, новых данных, изменение существующих процессов. Все эти изменения должны быть предметом внимания архитектора.
Набор решений предопределяет всю архитектуру организации и связывает цели с фактической реализацией. Таким образом, архитектура — это не только ответ на вопрос «что будет меняться», но также и обоснование этого изменения, или ответ на вопрос «зачем». Поскольку в архитектуре отражены не только структурные и поведенческие элементы, но и элементы мотивации и целеполагания, проектирование архитектуры позволит получить осознанные ответы на вопросы, что менять, как менять и зачем (для достижения каких именно целей).
В каждом решении можно выделить несколько ключевых моментов: структуру решения, включая причины принятия решения (указание вышестоящего органа, влияние внешней среды, устаревание объекта и необходимость создания нового); заинтересованных в решении лиц; объекты решения (элементы предприятия, к которым решение будет относиться); само решение; его последствия и т. д. Таким образом, набор решений — это набор обоснований, которые проясняют достижимость целей (замысел руководства и архитекторов), спецификации на реализацию и описание реализации (так как любое решение корректируется по факту его реализации).
Понятие архитектуры близко к понятию системности. Что делает некую систему системой? Инженерный подход утверждает, что система состоит из элементов и их связей, причем подбор элементов и связей обеспечивает системе эмерджентность — свойства и поведение, не характерные для составляющих систему элементов
Например, сеть связи состоит из кабелей, коммутаторов, колодцев, розеток, терминалов, инженеров, комнат, компьютеров. Все это по отдельности не может мгновенно передавать сообщения и файлы на любые расстояния, но будучи соединенным в систему под названием интернет, демонстрирует эмерджентные свойства — способность поддерживать коммуникации между тысячами пользователей Сети.
С точки зрения менеджмента хорошая архитектура — это набор архитектурных решений, воплощенных в жизнь в виде реально работающих компонентов предприятия (систем, сервисов, микросервисов, интеграций, ролей, процессов, функций, оборудования), причем эти компоненты выстроены и связаны так, чтобы обеспечить организации как работоспособность, так и адаптивность.
Классический пример из этой области — строительство дома. Будущий дом — это набор моделей:
Любое изменение одной из моделей приводит к перепроектированию других моделей. За этим следит главный конструктор здания, выполняющий роль архитектора. Адаптивность дома достигается за счет типизации оборудования и поэтажных планов, за счет повышенного объема закладных каналов для коммуникаций, несущих конструкций, допускающих свободную планировку, расширенных коридоров.
- модель (чертежи и решения) несущих конструкций дома;
- модель (чертежи и решения) электрификации дома;
- модель (чертежи и решения) отопления дома;
- модель (чертежи и решения) водоснабжения и водоотвода дома.
Любое изменение одной из моделей приводит к перепроектированию других моделей. За этим следит главный конструктор здания, выполняющий роль архитектора. Адаптивность дома достигается за счет типизации оборудования и поэтажных планов, за счет повышенного объема закладных каналов для коммуникаций, несущих конструкций, допускающих свободную планировку, расширенных коридоров.
Важным аспектом хорошей архитектуры является баланс между детальностью и простотой архитектурной модели, что критично и для стратегии, которая пишется на основании данной архитектуры.
С одной стороны, верхнеуровневая (или абстрактная) архитектура легче для понимания и изложения, она быстро передает замысел архитектора. С другой стороны, такая архитектура не позволяет точно предсказать все свойства и риски будущей конструкции организации (или группы организаций) и, как следствие, не «подсвечивает» трудности в реализации. Детальная архитектура учитывает больше нюансов и фактически может выступать в качестве технического задания на проработку реализации, но она сложна для изучения и понимания, ее тяжело обсуждать широким кругом вовлеченных лиц.
При выборе уровня детальности все зависит от рисков и стоимости ошибки. Чем выше цена ошибки, тем более тщательным и дорогим будет проектирование, тем более точными и детальными должны быть архитектурные модели. Как правило, в начале проектирования архитектурные модели носят верхнеуровневый характер. Но по мере работы они обрастают подробностями: уточнениями, вариантами решений, предположениями, ограничениями — и это приводит к усложнению моделей.
Сложные многоуровневые системы, например составные организации типа холдингов, групп компаний, головной организации и ее подведомственных организаций, а также федеральные округа, территории, местности, субъекты и макрорегионы, могут иметь архитектуру на каждом уровне агрегации. В этом случае архитектура верхних уровней иерархии состоит из строительных блоков нижних уровней иерархии.
Если построить архитектуру архитектур не представляется возможным (что, как правило, связано с нехваткой квалифицированных кадров, методологий и инструментов), то управление разработкой архитектуры выполняется через установку единых на всех уровнях системы принципов, руководств и соглашений о моделировании.
5.1.3 ИТ-архитектура и ее роль в архитектуре предприятия
Остановимся подробнее на том, что представляет собой ИТ-архитектура и какова ее роль в архитектуре предприятия. В предприятии вчерашнего дня ИТ обеспечивали возможность решения основных задач. В цифровом предприятии ИТ — это его сердце.
Тематике ИТ в архитектуре посвящено три домена: домен ИТ-приложений, домен данных и домен ИТ-инфраструктуры. Каждое конкретное предприятие может управлять ими не разрозненно, а вместе взятыми. В эти три домена входят такие слои, как:
- прикладные информационные системы;
- модули информационных систем;
- функции информационных систем, в том числе их представление и воплощение в виде микросервисов;
- объекты данных концептуального уровня;
- объекты данных логического уровня;
- объекты данных физического уровня;
- сервисы информационных систем, доступные через API;
- API, дающие организации нужную открытость и возможность интеграции в бизнес-экосистемы;
- инфопотоки, описывающие фактические интеграции систем со своим окружением;
- системное ПО и операционные системы;
- центры обработки данных;
- аппаратные средства;
- узлы, линии и каналы связи.
Ключевая интегральная способность всех ИТ-доменов — это реализация концепции DevOps как технологии частой и безопасной поставки предприятию новых функций ее прикладного ИТ-слоя. С одной стороны, частая поставка требует новой культуры разработки, с другой стороны, возникает новый класс программного обеспечения — платформы (подробнее см. раздел 6). Разработчики развивают и наращивают функционал платформы постоянно, не прерывая обслуживание пользователей платформы. При этом сервисы платформы могут развивать как штатные разработчики, так и третьи лица, желающие расширять границы бизнес-экосистемы, формирующейся вокруг платформы.
DevOps (DEVelopment OPeration) — повышение эффективности процессов разработки (Development) и эксплуатации (Operation) программного обеспечения за счет их непрерывной интеграции и активного взаимодействия профильных специалистов с помощью инструментов автоматизации. См. Вечугова А. DevOps // Школа Больших Данных.