Что описывает корпоративная архитектура
Корпоративная архитектура и ее составляющие
Григорьев Л.Ю., Кудрявцев Д.В., Горелик С.Л.
Перевод на операционный язык известного выражения «хаос автоматизировать нельзя, иначе будет автоматизированный хаос» 1 сводится к тому, что сначала нужно грамотно выстроить процессы, а потом запускать процесс автоматизации.
Происхождение понятия
Понятие «корпоративная архитектура» в последнее время все чаще стало востребовано для описания новых реалий в информатизации бизнеса. Оно все прочнее утверждается в сфере взаимодействия информационных технологий и бизнеса: ИТ-службы современной компании перестают быть простыми поставщиками технологических компонентов, приложений и сервисов для бизнес-подразделений. На первый план выходит синхронизация развития бизнеса и ИТ.
У наиболее продвинутых компаний целью информационной стратегии сегодня становится построение глобальной информационной инфраструктуры, так называемого «адаптивного предприятия» (Adaptive Enterprise).
Происходит очередная смена парадигмы компьютеризации бизнеса: как в свое время процессы (ERP, CRM, SCM и т.п.) пришли на смену функциям (АРМ), так теперь их место занимает развивающаяся бизнес-система (Adaptive Enterprise). Новый объект информатизации требует новых методов и средств описания, а именно систем моделирования, охватывающих не отдельные процессы, а эту самую «корпоративную архитектуру», организацию деятельности всего предприятия в целом (см. Рис. 1).
Рис. 1. Парадигмы информатизации управления в бизнесе
Определение терминов в области «корпоративной архитектуры»
Будем исходить из того, что в самом общем виде «архитектура» – это выражение закономерностей строения, присущих системе (например, зданию, технической или информационной системе), общий план или концепция, используемая для ее создания, а, с другой стороны, абстрактное описание системы, ее структуры, компонентов и их взаимосвязей.
Исходя из этого «корпоративную архитектуру» следует рассматривать в двух аспектах:
В первом аспекте корпоративная архитектура – это реально существующая организация бизнеса, которая специфична для той или иной компании, несмотря на большие возможности типизации.
Во втором – корпоративная архитектура систематизирует и дает фиксированное описание бизнеса в виде полезных моделей, диаграмм и функциональных комментариев по организации деятельности компании.
Наличие двух точек зрения требует понимания, о каком аспекте идет речь в каждом конкретном случае, в каждом определении. Но так как тема новая, сделать это разделение пока достаточно трудно. Частично термины, относящиеся к другому аспекту, а также синонимичные термины мы будем приводить в скобках.
Синонимия возникает еще и потому, что желательно максимально соответствовать той терминологии, которая уже сложилась в компьютерной прессе. Конечно, мы не будем пытаться интегрировать все, подчас противоположные, точки зрения.
Например, некоторые авторы включают в сферу действия понятия «корпоративная архитектура» руководящие регламенты в виде миссии, концепций, политик, правил, шаблонов и стандартов, используемых для общей организации эффективной работы, целенаправленного развития и информационной поддержки деятельности предприятия. Эти регламенты, конечно, являются необходимым компонентом деятельности любого предприятия, но это не есть достаточное основание для вынесения их на верхний уровень понятия. Они попадают туда через систему частных моделей, связанных с корпоративной архитектурой.
С учетом этих ограничений, приведенные ниже определения надо рассматривать как некое первое приближение к точной терминологии в этой области. Для более наглядного отображения соотношения понятий мы воспользуемся схемой, приведенной на рис. 2, где понятием верхнего уровня собственно и выступает «корпоративная архитектура». Далее приведены первые попытки определения терминов и их вариации.
Корпоративная архитектура (бизнес-модель) – это общая модель бизнеса, определяющая политику инвесторов, стратегии, продукты, технологии, процессы, структуры и информационную поддержку деятельности.
Многие авторы, особенно из сферы ИТ, прежде всего разделяют основное понятие на два: бизнес-архитектура и информационная архитектура.
Начнем с последней, чтобы потом сосредоточиться на первой.
Хотя «информационная архитектура», вроде, дело сугубо специальное, нижний уровень поддержки управления, задача «технарей», но и здесь наблюдаются интересные тенденции. Понятие «информационная архитектура» ранее, да и сейчас, часто интерпретируется как «корпоративная информационная система», включающая прежде всего программные приложения и технические средства доведения их до конечных пользователей в бизнес-подразделениях (в том числе корпоративные сервисы).
До недавнего времени, да и в течение последних пятидесяти лет, информационные технологии были сосредоточены на операциях с данными – их сборе, хранении, передаче, обработке и представлении. То есть главной в аббревиатуре ИТ была буква «Т».
Информационные системы, благодаря этому подходу, поддерживаемому крупными системными интеграторами, были похожи на водопроводы большого диаметра с мощными насосами, по которым нормально не текла вода (либо это была тонкая струйка, либо мутный канализационный поток).
Только в последнее время акцент в ИТ начал переноситься на букву «И», и оценка информационных технологий начала строиться с учетом ценности знаний как экономического фактора. Сами по себе технологии не прибыльны — прибыль приносят адекватное использование информации, высшей формой организации которой являются корпоративные знания. Именно поэтому в последнее время начали отделять задачи управления информацией («контентом») от традиционных технологий обработки данных.
Рис. 2. Составляющие корпоративной архитектуры
В связи с этим понятие «информационная архитектура» было переопределено. В новой трактовке под ней стали понимать принципы систематизации информации и навигации по ней с целью помочь людям более успешно находить и обрабатывать нужные им знания.
Чтобы разрешить противоречие между традиционным и новым пониманием термина информационная архитектура, мы зарезервируем для исключительно важного аспекта работы собственно с информацией термин «архитектура знаний».
Т.е в этой части «корпоративного здания» должны содержаться правила и структуры организации информации, которые позволяют эффективно предоставлять лицу, принимающему решения, нужные сведения, позволяющие ему действовать более успешно. 6
Кроме того, необходимо обеспечить описание данных, которые требуются для работы традиционных прикладных систем. Если рассмотреть переход от «данных» к «знаниям» с точки зрения уровня организации информации, то этот переход характеризуется все большим усложнением информационных структур и появлением многочисленных связей между ними, а также разных способов обработки.
Другую часть будем традиционно называть «корпоративной информационной системой» со всеми ее компонентами, сервисами и приложениями. Имея в виду, что в ее состав могут также входить «системы управления корпоративной информацией» или «корпоративным контентом», тесно связанные с архитектурой знаний.
Следующее понятие – это бизнес-архитектура, которую мы только что отделили от «информационной».
При рассмотрении бизнес-архитектуры первая задача – разделить объект и субъект управления (см. рис.3). Т.е. сам бизнес и систему управления этим бизнесом!
Рис. 3. Управление – целенаправленное влияние на объект со стороны субъекта
Опять-таки, отделим более простую (для описания!) часть – «бизнес» – от сложной многоуровневой «системы управления».
В контексте описания корпоративной архитектуры мы будем понимать «бизнес» как совокупность бизнес-процессов (состоящих из последовательности бизнес-операций).
В процессах же управления, находящихся на рис. 4 сверху, единственным преобразуемым ресурсом является «информация». Совокупность этих процессов лежит в основе системы управления компанией, к рассмотрению которой мы и перейдем.
Рис. 4. Пятиуровневая модель системы процессов компании
Архитектура системы управления структурируется как по уровням (корпоративный, стратегический, операционный), так и по функциональным областям:
Но все же будем придерживаться основной магистрали классификации и, прежде всего, выделим в системе управления три основных уровня или системы управления второго порядка:
Итак, корпоративное управление (corporate government) – контролирующая и управляющая система акционерного общества, которая устанавливает права и обязанности различных участников организации (членов Советов директоров, менеджеров и акционеров), а также содержит основные правила и процедуры, обеспечивающие принятие управленческих решений.
Модель корпоративного управления отражает закрепленный в уставе и регламентах корпорации текущий баланс прав, обязанностей и ответственности, текущую роль и текущее влияние субъектов корпоративных отношений на принятие решений по делам корпорации. Таким образом, корпоративная модель отражает актуальное распределение власти в корпорации как социальной системе.
Система управления бизнесом (corporate management) в свою очередь распадается на две подсистемы (или модели) – стратегическую и операционную (рис. 5)
Рис. 5. Два уровня системы управления бизнесом (corporate management)
Каждый из этих уровней или систем управления имеет свои задачи:
Таким образом, мы подходим к определению наиболее сложного объекта корпоративной архитектуры – операционной модели, модели организации текущей деятельности, выстроенной в соответствии с корпоративной стратегией.
Операционная модель (операционная архитектура) определяет систему взаимодействия базовых элементов корпоративной архитектуры, ориентированную как на повышение эффективности текущей операционной деятельности, так и на достижение стоящих перед компанией стратегических целей. Она содержит описание системы процессов в привязке к организационной структуре, отражающей основные подразделения и центры компетенции, а также распределение ответственности за отдельные элементы деятельности.
Какие преимущества получает компания, грамотно выстроившая свою корпоративную архитектуру
Сегодня множество российских компаний, желающих улучшить управление своим бизнесом, реализуют проекты изменений, касающиеся того или иного фрагмента корпоративной архитектуры. Их успешность во многом зависит от того, насколько менеджеры компании или консультанты, помогающие им в проведении этих изменений, могут, проводя частные изменения, адекватно представить целое. А, не видя это целое, невозможно не только найти оптимальное решение, отвечающее стратегическим интересам фирмы, но и просто грамотно сформировать требования к необходимым изменениям. Происходит это потому, что все части корпоративной архитектуры тесно связаны между собой.
Наибольшей опасностью при принятии решений отец менеджмента качества Деминг считал «локальную оптимизацию или субоптимизацию». Функционирование любого, составляющего систему процесса должно оцениваться в терминах его вклада в достижение целей всей системы, а не по его индивидуальной эффективности.
Например, проблематично реализовать проект постановки эффективной системы управления персоналом, не имея точной организационно-функциональной, а еще лучше процессной модели, определяющей ролевые задачи, из которых вытекают требования к обязанностям и компетенциям сотрудников. Систему мотивации невозможно правильно настроить, не связав ее со стратегической моделью, задающей вектор развития и направления концентрации усилий сотрудников и т.п. С другой стороны, при постановке стратегического управления по методологии BSC ключевые цели должны быть связаны с процессами, идентифицированными на операционном уровне управления. А вернее, не с самими процессами, а с результатами этих процессов, что позволяет правильно назначить показатели операционной эффективности. В тоже время при существующей практике независимой реализации проектов постановки системы BSC от проектов постановки процессного управления операционные цели закрепляются непосредственно за подразделениями или сотрудниками, а не процессами, что снижает точность стратегической фокусировки деятельности.
Таким образом, хорошие идеи могут не работать из-за их локальной реализации, т.е. реализации вне связи с другими компонентами системы. Именно эту системную целостность, создающую предпосылки оптимального решения, и обеспечивает корпоративная бизнес-модель.
Известны факторы, в наибольшей степени сказывающиеся на стоимости компании: четкая стратегия, прозрачность и стабильность бизнеса, современное корпоративное управление и т.д.
Повышение стоимости бизнес-системы с точки зрения финансового инвестора зависит от ожидаемых доходов компании в будущем, с учетом дисконта, зависящего от связанных с ней рисков. Кроме того, инвестор должен быть уверен, что его права, как состоявшегося акционера, надежно защищены.
По результатам опроса, проведенного компанией McKinsey еще в 2003 году, инвесторы готовы пойти на премию до 40 % за российские компании с современными стандартами корпоративного управления, имеющими внятную стратегию и ощутимые конкурентные преимущества, включая эффективную систему управления.
Составляющие стоимости компании, отражающие взгляд инвестора отражены на схеме ниже (рис.6):
Рис.6 Составляющие стоимости компании с точки зрения инвестора
Дадим некоторые пояснения к этой схеме, раскрывающие логику связей.
Состояние и перспективы развития бизнеса, с одной стороны, определяются стадией жизненного цикла отрасли и существующей позицией компании в этой отрасли, а с другой стороны – наличием четкой стратегии развития. Грамотно выстроенный операционный уровень управления, во-первых, позволяет реализовать выбранную стратегию развития, а во-вторых, повышает эффективность и стабилизирует текущую деятельность, тем самым, снижая риски.
Отдельная задача – это совершенствование корпоративного управления, построения системы отношений и регламентов взаимодействия акционеров и менеджмента компании. Качество решения этой задачи, как отмечалось выше, также существенно влияет на стоимость бизнеса.
Данный подход предполагает применение инженерных методов к проектированию бизнес-систем и основан на современных технологиях и средствах моделирования структур и процессов предприятия. Эти средства 10 позволяют получить и поддерживать в актуализованном состоянии точную электронную модель организации бизнеса, закрепленную в пакете корпоративных регламентов.
Все это создает необходимую организационную прозрачность компании, что делает ее не только более управляемой, но и позволяет наглядно представить потенциальному инвестору.
Есть и другая причина повышенного интереса компаний к управлению корпоративной архитектурой, которая обусловлена действующей в настоящее время моделью конкуренции.
Предприятие с управляемой и легко перестраиваемой корпоративной архитектурой развивается, опережает конкурентов по таким важнейшим показателям как:
Поэтому нет ничего удивительного в том, что компания Hewlett-Packard, которая разработала новую модель адаптивной корпоративной архитектуры, определяющую основные компоненты ИТ, бизнеса и их взаимосвязи, дала ей название Darwin Reference Architecture.
Заключение
Мы надеемся, что подробное рассмотрение терминологии в такой новой области, как управление корпоративной архитектурой, принесет пользу как российским менеджерам, так и консультантам, т.к. в настоящее время путаница в системе понятий мешает всем в практической деятельности.
В связи этим вспомним слова Питера Друкера, гуру менеджмента 20-го века: «Результаты ведь не в науке, а в том, что на самом деле происходит. Наука является опорой для менеджера, предлагает инструменты для достижения желаемых результатов. Но применение этих инструментов – это практика, а не наука».
Архитектура системы и Бизнес-архитектура
После достаточно продолжительного созерцания того, как различные специалисты объясняют (устанавливают) своё понимание архитектуры, я решил, что нужно им, всё-таки, помочь 🙂
Критиковать не стал, но предложить есть что.
Архитектура и строительные конструкции
Архитектура – это искусство проектирования и строительства зданий, сооружений и их комплексов, то есть искусство создания материально-организованной среды.
Архитектор – специалист, который на профессиональной основе осуществляет архитектурное проектирование, включая проектирование зданий, в том числе разработку объёмно-планировочных и интерьерных решений.
Строительный проект состоит из двух основных частей: архитектурно-строительной и инженерной.
Архитектурно-строительная часть проекта включает:
… место для размышлений …
Архитектура системы
Теперь рассмотрим определение, которые ближе к IT. За основу возьму выдержки из статьи.
Архитектура – фундаментальные понятия или свойства системы в ее окружении, воплощенные в ее элементах, отношениях и принципах ее проектирования и эволюции. (Из: ISO/IEC/IEEE 42010:2011)
Архитектура – это проектные решения, которые тяжело изменить. (Мартин Фаулер)
Однако, существует тонкость с характеристикой «тяжело изменить».
Предположим, у вас есть проектное решение, которое описывает для ваших разработчиков, как они должны структурировать свой код на Java. Если у вас есть много кода, для изменения всего этого кода из одной структуры в другую потребует много работы. Другими словами, это тяжело. Следовательно, это выбранное решение является «архитектурой», в данном случае программной архитектурой. Но один разработчик может легко проигнорировать это решение и написать код, который делает всё по-другому. В конце концов, вносить «изменения» в программное обеспечение легко. Хотя всю реализованную архитектуру изменить тяжело, в ней часто достаточно легко можно изменять только отдельные части.
Нет никакой теоретической причины, что что-то трудно изменить в отношении программного обеспечения. Если вы выбираете какой-либо один аспект программного обеспечения, вы можете легко изменить его, но мы не знаем, как сделать всё легко изменяемым. Сделать что-то легким для изменения — делает общую систему немного сложнее, а сделать всё легким для изменения — делает всю систему очень сложной. (Ральф Джонсон)
Суть создания архитектуры — структурирование. Структурирование может означать превращение формы в функцию, извлечение порядка из хаоса, или преобразование частично сформированных идей клиента в пригодную для работы концептуальную модель (Эберхард Рехтин).
Создание архитектуры – это деятельность по организации и поддержки системы из составляющих ее элементов. И все архитектурные принципы направлены на декомпозицию и организацию составных частей системы.
Проблема
Проблема у указанных выше определений, хотя они и полезные, всё же есть, они оторваны от идеи, заложенной в систему. Выделять архитектуру по критерию «тяжело изменить» довольно странно.
Также определение через составляющие в данном случае не передает необходимый смысл.
… место для размышлений …
Большая часть системных архитекторов вышло из программистов, они все технократы. Это всё придумали они. 🙂
При работе с архитектурой лучше сфокусироваться на назначение Системы.
Архитектура – это проектное решение, которое набор проектных решений организует в Систему, соответствующую целевому назначению.
Это проектное решение, которое колеса, двигатель, корпус и рулевое управление организует в автомобиль.
Другими словами, Архитектура – это проектное решение, которое дает эффект эмерджентности. Эмерджентность — появление у системы свойств, не присущих её элементам в отдельности; несводимость свойств системы к сумме свойств её компонентов.
Важно не смешивать уровни абстракции. Также позже, может возникнуть вопрос, что такое хорошая архитектура? Архитектура должная обеспечивать реализацию трех основные атрибутов качества системы: надежность, эффективность, гибкость. Есть и другие, например, масштабируемость, тестируемость, ремонтопригодность и др., но они не всегда так важны.
Бизнес-архитектура
В случае с бизнес-архитектурой есть свои особенности. Во-первых, есть действующая архитектура, ее нужно понять и описать. Во-вторых, в бизнесе есть свои принципы и базовые концепции которые нужно знать. Только понимая бизнес и базовые концепции можно предлагать изменения.
Для описания основы бизнес-архитектуры, как любой другой архитектуры, используются три аспекта:
Концепция «Три вида деятельности»
Существуют три вида деятельности:
Концепция «Циклы Деминга»
Итак, мы как архитекторы разделили деятельность компании на три части. Теперь нужно понять, а как же это все вместе работает. Для этого нам потребуется еще одна старая, но по-прежнему актуальная концепция – цикл Деминга, он же PDCA:
Посмотрим нашу конкретную проектную работу, производство продукта или оказание услуги:
Концепция «Принятие решения»
Тут нам понадобится третья концепция – Принятие решения. Это универсальный подход для решения управленческих задач и проектного управления.
Давайте сопоставим эту концепцию с нашими проектами:
Принцип «Целевое назначение должно определять архитектуру»
Тут важно напомнить определение архитектуры:
Архитектура – это проектное решение, которое набор проектных решений организует в Систему, соответствующую целевому назначению.
Целевым назначением обычно является основная деятельность. Управляющая деятельность направлена на основную деятельность. Поддерживающая деятельность обеспечивает ее.
Также не забываем указанные выше атрибуты качества: надежность, эффективность и гибкость. Основная деятельность вещь индивидуальная, но тут, я думаю, вы сможете разобраться с ней сами.
Принцип «Архитектура должна соответствовать руководству»
Без поддержки заинтересованных сторон архитектура не будет реализована. Нам придется изучить всех стейкхолдеров, их мотивы и цели.
Возможен внутренний конфликт.
… место для размышлений …
Определение Бизнес-архитектуры
Что касается специализированного определения, то с учетом того, что бизнес и IT идут сейчас плечом к плечу, по моему мнению, лучше Бизнес-архитектуру воспринимать как набор решений на верхнем уровне абстракций Архитектуры предприятия.
Из существующих определений мне нравится, которое дала группа Architecture Board Special Interest Group (BASIG) (Специальный совет по архитектуре OMG)
A Blueprint Of The Enterprise That Provides A Common Understanding Of The Organization And Is Used To Align Strategic Objectives And Tactical Demands.
План предприятия, который обеспечивает общее понимание организации и используется для согласования стратегических целей и тактических требований.
Архитектор
Если дать нормальное понятие архитектуры, то роль архитектора становится предельно понятной.
Задача сапожника изготавливать и ремонтировать обувь.
Задача архитектора создавать и управлять архитектурой. Он должен создать решение, которое соберет все другие решения в систему.
Какими компетенциями он должен обладать?
Архитектор должен знать архитектурные принципы и концепции на своем уровне бизнеса или системы, это его hardskills.
Также архитектор должен быть драйвером, описать архитектуру это половина дела, а вот убедить людей воплотить и постоянно поддерживать её — это вторая, не меньшая задача.
Для этого у архитектора должны быть хорошо прокачены softskills.
Есть еще одна характеристика, которая отличает архитектора от аналитика и программиста, он должен владеть оперативным искусством.
Что описывает корпоративная архитектура
Рисунок 5.1
Архитектура организации
Рисунок 5.2
Базовые компоненты (слои) архитектуры в методологии TOGAF
Рисунок 5.3
Основные домены и наиболее часто используемые слои архитектуры
Таблица 5.1
Изменение слоев архитектуры при цифровой трансформации муниципальной услуги по выдаче разрешений на строительство
Подразделения;Структурное подразделение органа власти теперь предоставляет и принимает информацию в цифровом виде через веб-формы и API с фокусом на ценность сервиса для его потребителя и анализом поступающей обратной связи в целях непрерывного совершенствования (на клиентоцентричной основе). Процессы;• Процесс приема заявлений по нецифровым каналам (письма, личные обращения) переходит в преимущественно онлайн-формат.
• Процесс контроля заявления по форме (полнота представленных данных) переходит от сотрудников к форматно-логическому контролю.
• Процесс принятия решений переходит в алгоритмический автоматический вид и основывается на данных. Функции подразделений;• Рутинная работа от приема заявлений до вынесения решения переходит от сотрудников к алгоритмам. Вмешательство человека происходит только при обработке отклонений. Это влияет на численность сотрудников, которая необходима для выдачи разрешений. Функциональные границы устраняются кросс-функциональным (межведомственным) взаимодействием, совершенствуется обмен информацией.
• Для пользователей цифрового сервиса запущен чат-бот, поддержка и актуализация базы знаний внесена в число функций подразделения, ранее занятого ручной обработкой заявлений на получение разрешения на строительство. Логические данные;Полностью пересматривается логическая структура данных под потребности работы алгоритмов. Создаются ведомственные дата-сеты. они становятся, по сути дела, библиотеками, которые остальные министерства и ведомства могут использовать как конструктор. Компоненты, функции, доступ к реестрам можно масштабировать не только на уровне министерств, но и в субъекты Федерации. Технологическая ИТ-архитектура: ЦОДы;Рассчитываются инфраструктурные мощности, необходимые для функционирования сервиса предоставления разрешений с целевыми параметрами:
• доступность (24/7) по всем необходимым средствам всем заинтересованным сторонам.
• мощность (способность обслужить поток заявлений конкретного муниципального образования).
• непрерывность (возможность продолжения предоставления сервиса в ситуации сбоев и высоких нагрузок). Интеграции;Запрос информации из смежных ОИВ осуществляется через API.