научная статья. Проектирование функции архитектуры предприятия
 Скачать 53.59 Kb.
|
|
Проектирование функции архитектуры предприятия Архитектура предприятия (АП) становится все более зрелой полем для работы, но многие крупные организации по-прежнему борются с существенной и действительно эффективной функцией АП. В статье представлена фрагментированное изображение функции АП, описывающее различные отдельные элементы, общий пакет активов, ресурсов, навыков и компетенций АП. На наш взгляд, функция АП выходит за пределы доставки АП и также включает в себя заинтересованные стороны, структуры и процессы, связанные с АП принятия решений и соответствия АП. Целостный и интегральный взгляд на АП необходим для правильной оценки функции АП и дать возможность определить ключевые моменты улучшения. В этом статье, мы приводим такое описание функции АП, которое обеспечивает рекомендацию модели в оценках эффективности работы АП как часть нашей Нормализованный подход к индексу зрелости организации (NAOMI). Ключевые слова: архитектура предприятия, управление, организация, функция, эталонная модель, управление, соответствие.
Мечта каждого генерального директора состоит в том, чтобы иметь стандартизованный, интегрированный, гибкий и управляемый ландшафт согласованных бизнес-процессов и ИТ-процессов, систем и процедур. Полный контроль над всеми проектами, осуществляющими изменения в этом ландшафте так что они предоставляют решения, которые идеально подходят для корпоративных и ИТ-стратегий и делает эту мечту полной. Реальность для многих крупных организаций противоположна. Многие крупные организации изо всех сил стараются сохранить свою работу и изменить затраты на контроль. Основными причинами являются негибкость и огромная сложность их бизнес и ИТ-структуры, процессы, системы и процедуры, часто распространяемые бизнес линиях и бизнес-подразделениях, распределенные по различным регионам, странам или даже континентов. За последнее десятилетия предприятие Архитектура (АП) была одним из многих инструментов, используемых организациями в их попытках получить доступ к текущей операционной среде и реализации изменений. АП обеспечивает стандартизацию и устанавливает четкое направление для будущего для руководства. По сравнению с архитектурой в физическом мире, АП предоставляет механизм планирования города, где архитектура программного обеспечения является архитектурой одного здание. Таким образом, АП дает границы, в которых должен работать архитектор программного обеспечения. Эффективное применение АП приводит к сокращению эксплуатационных расходов на обслуживание из-за повышение дисциплины и контроля, а также повышенная отзывчивость, поскольку АП приводит к сокращению продолжительности проекта. Кроме того, АП улучшает управление рисками, поскольку приводит к снижению сложности, и это повышает удовлетворенность руководства, поскольку обеспечивает общеорганизационную оценку организационных изменений. Наконец, АП усиливает стратегические результаты бизнеса, поскольку это помогает повысить эффективность бизнес - процессов, приложений, данных и инфраструктуры посредством стандартизации. Хотя он рассматривается как важный инструмент управления многими крупными организациями, АП, как правило, не достиг желаемого результата. АП практикуется, по меньшей мере, десять лет, но он по-прежнему страдает от относительной незрелости, поскольку у нас нет опыта в различных оценках функций АП в организациях клиентов. У них есть трудности с установкой функции АП, которые полностью интегрированы в существующее корпоративное управление или управление ИТ, а также стимулируют эффективное сотрудничество между архитекторами и другими заинтересованными сторонами. Такая фрагментированная и плохо интегрированная функция АП, как правило, не оправдывает ожидания всех заинтересованных сторон АП, что приводит к целям, поставленным с АП – если не явно установлены - то не достигается вообще. В исследовании ЕА было предпринято много усилий в различных отдельных элементах: общий пакет мероприятий, ресурсы, навыки и компетенция, это зрелая структура АП, функция доставки должна иметь место - например, надлежащие инструменты, рамки и архитекторы. Чтобы измерить зрелость возможностей АП. Разработаны оценки эффективности функций АП. Они прежде всего сосредоточены на оценке того, будут ли элементы, определяющие зрелость функции доставки АП (например, архитектурный отдел или команда) на месте. Однако, исходя из нашего опыта, это ограниченное мнение. Деятельность АП функция должна выходить за рамки простого предоставления продуктов АП, а также включать другие организационные роли, органы и мероприятия, ответственные за принятие решений АП (например, совета по архитектуре) и соответствия АП (например, руководители проектов и дизайнеры). Организация будет эффективна только с корпоративной архитектурой, когда существует эффективное формальное и неформальное взаимодействие между членами АП функции доставки и заинтересованные стороны, ответственные за принятие решений АП и соответствия АП. Кроме того, вся функция АП должна быть правильно интегрирована в общие организационные и управленческие структуры для того, чтобы быть эффективными. В настоящее время в литературе отсутствует полная эталонная модель функции АП. Существующие подходы к оценке зрелости АП, включили эталонную модель в свою модель зрелости, но эта модель часто ограничивается функцией доставки АП. Другая литература практикующего обеспечивает фрагментированное представление элементов функции АП. В этой статье мы предоставляем четкое определение и интегральное описание функции АП, установленные функции в нашей эталонной модели. Эта модель описывает норму, которую мы сравниваем с клиентом организации, оценивая эффективность своих функций АП. Обе функции ссылочной модели АП и модель оценки являются частью нашего нормализованного Индекса зрелости архитектуры организации (NAOMI). Раздел 2 этой статьи содержит нашу справочную модель функции АП. Раздел 3 содержит тематическое исследование, в котором показано, как одна компания реализовала свою функцию АП. В разделе 4 мы обсудим уроки, извлеченные в отношении нашей справочной модели функции АП и основанные на этом исследования. Наконец, в разделе 5 мы делаем выводы и обсуждаем будущие исследования мы будем проводить по теме функции Enterprise Architecture.
Основываясь на научной и практической литературе и различных тематических исследованиях в глобальной Компании финансовых услуг, мы создали целостное описание Функция АП. Мы определяем функцию АП как: организационные функции, роли и органов, занимающихся созданием, поддержанием, ратификацией, соблюдением и наблюдением принятие решений в области архитектуры предприятия - установлено в архитектуре предприятия и политика АП - взаимодействие через формальные (управленческие) и неформальные (совместной работы) на уровне предприятия, домена, проекта и операционной системы. Основываясь на этом определении, мы опишем нашу справочную модель функции АП с Раздел 2.1, описывающий его структуру, раздел 2.2, его продукты, раздел 2.4, его процесс модель и раздел 2.5. Раздел 2.3 содержит подробные описание доставки АП как часть всей функции АП. На рисунке 1 показаны три основные функции АП: (1) решение АП (2) доставка АП и (3) соответствие АП (см. рис.1). Принятие решения АП по стратегический и тактический уровень отвечает за утверждение новых продуктов или изменений в АП в существующих продуктах АП и для обработки эскалаций относительно соответствия АП. Обычно это выполняется одним или несколькими органами управления (например, Советом АП). Наличие таких органов управления с надлежащим представлением от различных группы заинтересованных сторон (см. раздел 2.5.1) - приводит к более ощутимому значению, участия и поддержки как руководства, так и других заинтересованных сторон, и он улучшает эффективность функции АП. Органы управления АП различаются по степени которые у них есть консультативные или официальные полномочия по принятию решений. Доставка АП отвечает за предоставление рекомендаций для принятия решений АП по стратегическому и тактическому уровню. Кроме того, доставка АП создает и поддерживает продукты АП, проверяет результаты изменений, чтобы узнать, соответствуют ли они АП, а также обеспечивает поддержку при применении продуктов АП (см. раздел 2.3).
Рисунок 1. Ответственность трех основных функций Архитектуры предприятия Наконец, соответствие АП отвечает за выполнение организационных изменений через решения, описанные в целевых архитектурах, соответствующие требованиям АП политики и предоставления обратной связи о применимости продуктов АП к АП функция доставки. Ответственность АП обычно лежит на продуктах которые пострадали от АП во время выполнения проектов изменений (например, руководители проектов) или осуществления оперативных изменений (например, оперативных техническое обслуживание) на тактическом и оперативном уровне. 2.2 Продукты функции АП Обычно существуют два типа продуктов АП: (1) архитектуры и (2) политики АП. Документ архитектуры обеспечивает абстрагирование того, что сложная окружающая среда выглядит и действует как средство коммуникации и принятия решений относительно этой окружающей среды. Существуют три типа архивных документов: (1) целевая архитектура, которая обеспечивает абстрагирование желаемой ситуации, (2) текущее состояние, которое описывает текущую операционную среду и (3) дорожной карты, которая описывает путь реализации из текущего состояния к целевой ситуации. Эти типы архитектурных документов нацелены на одну или несколько, четыре аспекта: (1) бизнес-архитектура, (2) информационная архитектура, (3)информационных систем и (4) технической инфраструктуры. Первые два измерения представляют бизнес-аспекты организации; последние два представляют собой ИТ аспекты. На наш взгляд, Архитектура Предприятия включает как бизнес, так и ИТ аспекты организации и соответствие между ними. Политика АП предписывает, как проекты должны внедрять организационные изменения в различных LoB и BD посредством унифицированных принципов и практики. Политика АП может быть указана в трех возможных формах: (1) стандарты, (2) правила или (3) рекомендации. Оба стандарта и правила должны соблюдаться; руководство может отказаться от прав предоставления. Применение политики АП позволяет организациям влиять на изменяя и деятельность субъединиц, не диктуя точно, как они справляются со всей своей оперативной деятельности. Поддержание современных стандартов промышленности позволяет организациям изменить ответ на внешние события, такие как изменения рынка, технологические инновации и нормативные изменения. 2.3 Функция доставки АП Функция доставки АП часто организуется как отдельный отдел или команда, как правило, в качестве функции организационного персонала. В зависимости от размера организации, функция АП может также состоять из одного или нескольких архитекторов. Отдел или команда АП иногда возглавляется главным архитектором. Происхождение функции АП может отличаться, что приводит к различию в бизнес-аспектах или аспектах ИТ. Независимо от фокуса, как правило, четыре вида ответственности за доставку АП: Предоставлять рекомендации для поддержки принятия решений АП в отношении целевой архитектуры путем: • Помощь в построении видения и стратегии на будущее, основанная на его отношении с его внешней средой в отношении социальных, экологических и рыночных разработок, технологические инновации, нормативные изменения и т. д. Описывая альтернативные решения относительно целевой ситуации и выполняя анализ воздействия на предопределенные критерии и показатели оценки (например, финансовые, нормативные) для определения последствий этих альтернатив для того чтобы выбрать наиболее желательный. Создавать и поддерживать продукты АП, которые описывают: • Архитектура текущего состояния, которая обеспечивает понимание ситуации, сложившейся в операционной среде, а также ее узких мест и сопутствующих рисков • Конкретная целевая государственная архитектура, основанная на видении и стратегии, описывающая выбранную альтернативу решения, которая подробно, оценивается по ее способности справляться с возможными внутренними и внешними изменениями с использованием различных будущих сценариев • Дорожная карта от текущего состояния до целевой ситуации, в которой взаимная взаимосвязь и влияние элементов в архитектуре, и последовательность шагов реализации • Политика АП, основанная на современных знаниях отраслевых стандартов и развития внутри организации и определить их потенциальное воздействие. Подтвердить соответствие АП: • Проверка программ или проектов на их соответствии: - Целевые архитектуры на уровне предприятий и доменов, чтобы обеспечить результаты программ и проектов способствующих достижению общих бизнес-целей и целевая ситуация, описанная в этих целевых архитектурах - Политика АП, чтобы обеспечить изменение деятельности программ или проектов способствуют достижению целей стандартизации и интеграции, установленных с помощью EA - Современные архитектуры состояний, обеспечивающие оперативную готовность программы и результаты проекта перед развертыванием, тем самым гарантируя непрерывность операционных процессов системы. • Обращение с просьбами об отказе, оценка последствий предоставления программ и проекты, которые подают заявки на отклонение от конкретного руководства. Оказывать поддержку в применении продуктов АП к программам и проектам (например,через обучение и коучинг) в: • Создание целевых архитектур программ и проектов на основе продуктов АП на домен и уровень предприятия • Соответствие продуктам АП при выполнении программ и проектов. 2.4 Модель процесса EA Pulkkinen описывает модель процесса АП для управления архитектурными решениями в планировании архитектуры предприятия, которые имеют три уровня абстракции: (1)уровень предприятия, (2) уровень домена и (3) уровень системы. Решения, принятые на уровни управления становятся явными в продуктах АП, которые стекают вниз, чтобы снизить уровни, вводя более подробную информацию. Архитектуры и политики АП на более высоком уровне установлены границы для принятия решений и реализации более низкого уровня. От нас практический опыт внедрения функций АП, оказался подходящей моделью. Однако, основываясь на нашем практическом опыте и исследование восприятия участниками опыта АП, мы изменили и расширили модель процесса АП. Модель процесса АП проводит различие между постоянным (например, деловыми цепочками процессов, BD или LoB) и непостоянные (например, большие программы) домены. Однако также важно провести различие между конкретным и родовым бизнесом доменов из-за их конфликтных рабочих моделей в результате разных принципов оптимизации. Конкретный домен обычно влечет за собой обращение клиента к LoB, который предоставляет определенный продукт или услугу, обслуживающий определенный рынок или клиент - сегмент или работать в определенном географическом регионе. Поэтому он оптимизирует для точной настройки своих услуг и нужд своих клиентов. С другой стороны, общий бизнес-домен (например, общий сервисный центр) обычно предлагает общие или инфраструктурные услуги различным LoB и BD в рамках организации - таким образом, выступает в качестве МВЗ - оптимизирует свои структуры, процессы, системы и процедуры, что позволяет свести к минимуму его эксплуатационные расходы. Для того чтобы касавшейся горизонтальной интеграции конкретных и общих доменов, решения АП может быть централизовано, децентрализовано или реализовано в федеральной модели, в зависимости от организационных характеристик. Мы изменили название «системный уровень» на «уровень проекта». Это оставляет открытым, тип проектов решений. Термин «системный уровень» предполагает, что решение АП создание и внедрение всегда приводит к ИТ-решению. Однако в пределах области аспекта деловой и информационной архитектуры, проекты могут доставить дело процессы обработки, которые требуют участия человека и потоков физической информации (через бумажные формы); не всегда возможно полностью автоматизировать бизнес-процессы в прямолинейную обработку (STP) Кроме того, мы добавили операционный уровень в модель процесса из-за конфликта в принятии решений относительно организационных изменений на уровне проекта и организации стабильности и непрерывности на рабочем уровне. Принятие решения об использовании непрерывных и повторяющихся операционных сред направленных на уточнение, посредством небольших изменения воздействия, чтобы максимизировать его непрерывность и стабильность. Решение на уровне проекта часто различны по своему характеру, поскольку это предсказуемые высокие последствия изменения операционной ситуации, потенциально компрометирующие непрерывность и стабильность на оперативном уровне. Общепринятое принятие решений - как в случае с АП - должно охватывать обратную связи с группового и индивидуального уровней для обеспечения постоянного улучшения. Однако на практике такой процесс обратной связи вряд ли выполняется. Решение АП (например, высшее руководство) считают, что ежегодный цикл принятия решений адекватных в управлении изменениями. Модель процесса АП включает в себя обучение цикла с последующим потоком решений (вперед), а поток вверх по течению до укрепить успехи и трудности в реализации этих решений на более низких уровнях назад к более высоким уровням (обратная связь). Мы разрабатываем эти концепции, используя организационную структуру обучения Crossan et al. Мы перевели четыре лежащих в основе основных предпосылок их рамок для положения АП в целях. Параллельно с теорией организационного обучения архитектура предприятия практика испытывает напряжение между исследованием новых возможностей и эксплуатация старых определений. Исследование АП происходит во время решения на уровне предприятий и доменов, а также результаты в новых архитектурах АП и Таблица 1. Объекты организационного обучения, взятые у Crossan et al., Пространство архитектуры предприятия.
разрабатываемых и утвержденных политик. Следуя этим продуктам АП, описывая, как изменения должны быть реализованы, передаваться на проектный и операционный уровень, где они должны интерпретироваться и следовать. Функция доставки АП играет жизненно важную роль в качестве посредника между принятием решений АП и соблюдением АП, в получении этого общее понимание и общее поведение. Это требует более активного подхода чем просто записывать центральные решения и публиковать их так, чтобы они были доступны для более низких уровней. Наличие комплексного и эффективного развертывания и принятия плана жизненно важно для функции доставки АП для реализации этих организационных изменений. Обратная связь имеет жизненно важное значение в отношении ограничений и проблем, возникающих в ходе проекта или операционный уровень с применением предписанных продуктов АП. Возможно, они не были ожидаемы при принятии решений АП на уровне домена или предприятия. Неофициальный обратной связи во время сотрудничества между архитекторами и заинтересованными сторонами уровни позволяют постоянно улучшать продукты АП путем уточнения АП решений на более высоких уровнях. Это обеспечивает их практическую применимость и предотвращает их от использования исключительно архитекторами. Формальная обратная связь посредством эскалации. Заявления об исключениях и требованиях об отказе АП также предоставляют важную информацию для улучшение продуктов АП; количество запросов об эскалации и отказах в отношении определенные продукты АП действуют как показатель качества этого продукта. Кроме того, обратная связь позволяет включить то, что было изучено на более низких уровнях, посредством исследования, эксперименты и инновации, в продукты АП, предписанные в более высоких уровнях. Лучшие практики (например, доказательство концепции новой, инновационной технологии) в проектный или операционный уровень идентифицируются и оцениваются по их общей применимости. Это приводит к предложению об изменениях в существующих или созданных АП. При ратификации продукт АП получает официальный статус «одобрен» и будут проходить статусы действительности: будущие, фактические, ограниченные и устаревшие, до получения официального статуса об «отставке», вводя жизненный цикл продукта АП. 2.5. Тела и роли в функции АП В рамках модели процесса функции АП, описанной в разделе 2.4, различные тела и роли взаимодействуют, преследуя разные цели. 2.5.1. Органы и роли в принятии решений АП Органы управления АП в рамках функции АП отвечают за решение делая продукты АП, предоставляя им официальный статус. Кроме того, он обрабатывает эскалации и несоответствия. Эффективный орган управления АП на любом организационном уровне должен: (1) состоять из различных ролей, которые представляют потенциально конфликтующие интересы, которые происходят на этом организационном уровне, (2) выполнять прозрачное решение на основе объективных критериев, и (3) иметь надлежащий мандат для обеспечения соблюдения решений на этом организационном уровне. Совет АП на уровне предприятий выступает в качестве руководящего комитета, чтобы обеспечить горизонтальную интеграцию для координации принятия решений АП. Это состоящий из представителей доменов внутри организации, главный архитектор и председатель. Оба председателя - главный спонсор АП - и главный архитектор - отвечает за качество и эффективность всего предприятия. Архитектура - должна действовать в интересах общеорганизационных структур, процессов, систем и процедур для достижения корпоративной стратегии. Владельцами домена являются связанные с оптимизацией своих конкретных областей для достижения их специфических для домена стратегии. Когда проблемы не могут быть решены в совете АП, они эскалируют к высшему руководству, спонсирующему совет АП для принятия окончательного решения. Таблица 2. Функции и деятельность АП, выполняемые на предприятии, домене, в проекте и на операционном уровне; на каждом уровне вход и выход подаются вперед или назад, создавая цикл обучения АП.
На уровне домена может существовать официальный орган или неофициальный консультативный орган управления АП (например, совет по архитектуре домена), который отвечает за принятие решений АП в этом домене. Членство похоже на совет АП, только роли остаются в пределах домена. Совет по архитектуре доменных зон обрабатывает ратификацию продуктов АП для конкретных доменов и обрабатывает эскалации в отношении несоответствия этих продуктов АП. Только в тех случаях, когда споры о несоответствии не могут быть разрешены в рамках совета по архитектуре доменов или влияние решений, принятых советом по архитектуре домена, выходит за пределы этого домена, эта проблема эскалации в сторону совета АП на уровне предприятия. Это уменьшает нагрузку на совет АП только на непростые проблемы, связанные с доменом. На уровне проекта обычно нет официального органа управления АП. Руководящий комитет проекта может выступать в качестве неофициального органа управления АП. Проблемы несоответствия, которые не могут быть решены и могут привести к отклонению проекта от принудительных продуктов АП, будут усилены в сторону совета по архитектуре домена.
На уровне предприятия функция доставки АП обычно состоит из центральной команды АП или отдела персонала, состоящей из менеджера АП, главного архитектора предприятия и различных ролей архитектора предприятия. Каждый архитектор предприятия отвечает за конкретную область аспект АП (например, бизнес, информацию, информационную систему или техническую инфраструктуру ), выполняя основные функции функции доставки АП (см. Раздел 2.1) на уровне предприятия. Главный архитектор предприятия обычно выступает в качестве функционального руководителя функции доставки АП, контролируя все аспекты архитектуры предприятия. Он или она выступает в качестве доверенного советника CxO и отвечает за качество и эффективность общей архитектуры предприятия. Менеджер АП выполняет функцию доставки АП, выполняет управление бюджетом и ресурсами, планирование и координацию, а также другие задачи оперативного управления. В организационных доменах (например, LoB) обычно используются собственные архитекторы на уровне домена, которые являются экспертами в определенной области бизнеса или ИТ. Архитектор домена выступает в качестве доверенных советников владельцу домена (например, глава LoB). В зависимости от размера и структуры функции доставки АП на уровне домена могут присутствовать автономно работающие архитекторы, команда архитекторов или отдел формальной архитектуры. Эта функция доставки АП на уровне домена действует как подгруппа центральной функции доставки EA на уровне предприятия. 2.5.3. Роли в соответствии с АП. Члены проектной группы несут ответственность за управление проектами изменений и их выполнение. Эти проекты должны предоставлять решения, которые преобразуют определенные части операционной среды организации в желаемую ситуацию, описанную в целевой архитектуре (архитектурах) на уровне предприятия и домена. Кроме того, они должны соблюдать политику АП при запуске проекта. Особую роль играет архитектор проекта, который выступает в качестве советника, охраняющего качество проекта. Он или она консультирует на начальном этапе проекта для обсуждения важных решений по внедрению и отвечает за доставку проектной документации, которая соответствует действующим продуктам АП. Кроме того, архитектор проекта должен предоставить отзывы о практической применимости продуктов АП к функции доставки АП на уровне домена. Архитектор проекта не входит в функцию доставки АП. Эта роль несет ответственность за результат проекта и поэтому не может выполнять проверки проекта независимо. На операционном уровне функция доставки АП выполняет роль гейткипера, выполняя послепродажную проверку: (1) проектов решений и (2), изменения, внесенные в операционную среду. При проведении этих обзоров изменения оцениваются по степени готовности и соответствия требованиям АП до их развертывания. 3 Функция EA в крупной международной компании Мы провели тематическое исследование в крупной международной компании, отныне называемой компанией A, оценивая ее функцию АП против нашей справочной модели функции АП. Мы провели полностью структурированные интервью с различными ролями - владельцами доменов, членами совета АП, менеджерами программ и проектов, менеджерами по операциям, менеджерами архитектуры, архитекторами, дизайнерами, экспертами по тематике - рассмотрением тем оценки, которые являются частью нашего подхода NAOMI. Кроме того, оценщики изучили обширный набор стратегических, проектных, оперативных и коммуникационных документов, чтобы проверить результаты опросов. С помощью этих данных мы создали изображение функции АП и сравнили их с эталонной моделью, описанной в разделе 2. Мы провели второе тематическое исследование функции АП в сопоставимой организации (компания B) с использованием того же подхода. Это конкретное исследование имело сопоставимые результаты. По соображениям конфиденциальности нет никаких подробностей. В описании случая в этом разделе мы укажем, какие выводы мы подтвердили с помощью тематического исследования, проведенного в компании B, и какие результаты были разными. В проведенном нами исследовании участвовали оценка функции АП в рамках операций и ИТ-подразделения крупной международной компании с технической инфраструктурой в качестве основной области. Это подразделение бэк-офиса состоит из различных вертикалей, обеспечивающих оперативные и IS-сервисы для различных LoB в рамках оффиса, а также отдела технологий, обеспечивающего инфраструктурные услуги для вертикалей. Функция АП, входящая в состав технологического отдела, отвечает за создание корпоративных инфраструктурных политик и утверждение решений по их соответствию. Функция доставки АП состоит из группы архитекторов, каждая из которых является экспертом в отношении определенного инфраструктурного домена (например, хранилища, мэйнфрейма, Интернета и т. Д.), Ответственного за создание политики АП и проведение проверки соответствия, относящейся к этому домену. Когда решение касается нескольких инфраструктурных доменов, оно должно быть подтверждено каждым архитектором домена, ответственным за эти домены. Главный архитектор инфраструктуры и архитекторы доменных архитектур провели ежемесячное собрание для утверждения новых инфраструктурных политик. Это был не официальный совет АП с представителями вертикалей, ответственных за принятие решений АП в отношении инфраструктурной политики. Инфраструктурные политики оказали влияние на эти вертикали. Это ежемесячное собрание привело к тому, что несколько политик получили официальный статус. Стандартной процедуры для политик, получивших официальный статус, не было, чтобы хранить и публиковать их в одном центральном репозитории. Компания B имела официальный совет АП с надлежащим представительством в бизнес-подразделениях (BD) внутри компании. Совет АП, однако, также был не в состоянии оценить и утвердить предложения политики АП, созданные функцией доставки АП, и предоставить им официальный статус. Наша оценка функции АП в компании A показала, что не было зарегистрировано ни одной архитектуры инфраструктуры предприятия, которая описывает отношения и согласованность между доменами инфраструктуры. Это привело к непоследовательным и некогерентным политикам АП в инфраструктурных доменах. Архитекторы домена предоставили противоречивые рекомендации менеджерам проектов и дизайнерам, поскольку они недостаточно сотрудничали друг с другом и не имели архитектуры инфраструктуры предприятия, которая могла бы их вести. Это сделало создание согласованного решения, которое соответствовало политике АП для разработчиков, что расстроило их. У многих дизайнеров также мало опыта разработки решений в соответствии с шаблоном, предоставляемым функцией АП. Поэтому многие проекты решений, отправленные в функцию АП для проверки, были низкого качества и были либо признаны неприемлемыми, либо были отклонены. Компания B имела корпоративную архитектуру, которая описывала отношения и согласованность между доменами. Однако эта корпоративная архитектура недостаточно детально для предоставления конкретной ссылки для архитекторов домена. Это привело к аналогичным проблемам, связанным с конфликтующими архитектурами, политикой и советами с помощью функции доставки АП, которую мы нашли в компании A. Конфликты мнений и недостаточное сотрудничество между доменными архитекторами в компании A вызвали непредсказуемость результатов проверки дизайна решения; результат зависел от того, какой архитектор выполнил валидацию. Все вовлеченные архитекторы доменов должны были принять дизайн решения, чтобы проект получил разрешение на строительство. Иногда проектам приходилось ждать несколько месяцев, чтобы их дизайн был принят, поскольку архитекторы домена не смогли договориться о результатах. Проекты обратной связи получили обоснование, почему решение было отклонено, и объяснение того, что следует улучшить в их дизайне, чтобы успешно пройти проверку, часто было недостаточным. Чтобы отклоняться от политики или требовать разрешения на продолжение реализации решения, когда проект был отклонен функцией АП, руководители проектов в компании A могли запросить отказ. Принятие решения о предоставлении проектов отказ был непрозрачным; они были предоставлены на основе неопределенных критериев и неадекватно переданы заинтересованным сторонам. Архитекторы домена не всегда были информированы о предоставленном отказе. Во время очередной проверки решения они отклонили решение проекта, которому был предоставлен отказ. Это привело к тому, что проекты были прекращены, хотя был предоставлен отказ, к разочарованию различных групп заинтересованных сторон АП. Компания B имела аналогичную процедуру для проектов, требующих разрешения отклоняться от политики АП. Совет АП, который занимался этими запросами, не был полностью эффективным. В компании A. было слишком много политик АП. Они были неструктурированы, а формальный статус многих из них часто был неизвестен; не было никакого жизненного цикла и управления изменениями для политики. Политика АП, созданная архитекторами домена, часто не тестировалась до их реализации. Поскольку не было обратной связи от уровня проекта вверх, архитекторы домена не знали о практической применимости политик АП. Центральное управление эскалацией и просьбами об отказе отсутствовало, чтобы можно было выявить неисправные политики АП. Все это привело к тому, что многие проекты отклонялись от политики АП, поскольку с ними было невозможно работать. Политика АП в компании также не тестировалась до того, как они были реализованы, и не было обратной связи от проектов вверх. Компания B имела центральное управление запросами на эскалацию и отказ, но они не использовались для выявления сбоев в политике АП для улучшения.
Раздел 3 описывает только часть результатов, которые мы собрали во время оценки функции АП, которую мы провели в крупной международной компании A. Однако этот случай показывает, что уровень зрелости АП в этой компании требует довольно некоторого улучшения. В нем также показано, что недостаточно учитывать только эффективность АП, чтобы быть действительно эффективными с ЭА; необходимо принимать во внимание как принятие решений АП, так и АП. В этом разделе мы подробно рассмотрим основные уроки, которые мы изучили.
2) Не пропустите шаги в модели процесса; сохранить цикл обучения в такте. Цепь обратной связи имеет важное значение для получения и использования продуктов АП на уровне проекта. Например, тематическое исследование в компании A показывает, что политика АП не была проверена и не всегда применима на практике. Благодаря обеспечению обратной связи от проектов до доменов архитекторы решат эту проблему. Этот цикл обратной связи может быть реализован в формальных процессах (т. Е. Вносить изменения в политики на основе эскалаций и отказов) или неформальных процессов (например, путем регулярных встреч между архитекторами, которые создают политики и дизайнеры, которые их используют). Наличие архитектур на уровне предприятия и домена, которые связаны, имеет жизненно важное значение для обеспечения горизонтальной интеграции между доменами. Например, тематическое исследование компании A показывает, что для архитекторов домена не существует архитектуры инфраструктуры предприятия, чтобы интегрировать различные инфраструктурные домены. Это иллюстрирует, что если один или несколько шагов в модели процесса АП опущены, цикл обучения АП становится неполным с отрицательными результатами.
До сих пор в литературе представлено фрагментированное описание функции АП. В этой статье мы предлагаем интегральное описание функции АП, чтобы установить норму при выполнении оценки эффективности работы АП. Подробное описание данного примера в этой статье показывает, что зрелость функций АП обычно довольно низкая, что приводит к низкой производительности этих функций АП. Второе тематическое исследование - по причинам конфиденциальности мы не описываем это тематическое исследование подробно в этой статье, - подтвердил это. Чтобы правильно определить основные моменты совершенствования и составить эффективный план улучшения, для реализации функции ЭОС требуется комплексная перспектива. Сравнивая конкретную практику АП с нашей интегральной моделью функции АП, используя модель оценки, описывающую стандартные темы исследования, позволяет сравнивать методы АП друг с другом. Наш подход NAOMI обеспечивает как функцию функции АП, так и модель оценки. В этой статье мы описываем нашу справочную модель функции АП, которую мы используем для проектирования и реализации функций EA в организациях на основе результатов оценки. Чтобы лучше понять, что определяет эффективность функции АП, мы проводим эмпирическое исследование, чтобы подтвердить нашу оценку эффективности АП, в которой рассматриваются три основные темы эффективности АП эффективность АП и степень заинтересованности АП. Мы провели исследование с участием заинтересованных сторон АП восприятие эффективности работы АП, и в настоящее время мы строим подход оценки удовлетворенности заинтересованных сторон на основе этого исследовательского исследования, чтобы расширить наш подход NAOMI. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||