Какая из методологий управления архитектурой предприятия является статической структурой

Обновлено: 05.07.2024

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

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

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

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

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

Введение

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

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

Глава 1. Новые технологии готовы. Итак, в чем проблема?

Чтобы преуспеть как на подъеме, так и на спаде рынка, компаниям из разных отраслей необходимо адаптироваться к возросшему темпу развития бизнеса. Они должны иметь возможность быстрее принимать решения, быстрее реагировать на запросы клиентов и быстрее выводить на рынок новые продукты и возможности. Однако скорость инноваций остается серьезным препятствием для роста и конкурентоспособности.

Многим организациям требуются новые цифровые инструменты и технологии, такие как искусственный интеллект, иногда без четкого представления о том, как именно они будут их применять. Одним из ключевых факторов, препятствующих внедрению, является продолжающееся использование подходов «старой школы» к архитектуре предприятия. Современные технологические организации просто не созданы таким образом, чтобы они могли двигаться быстро. Их техническая основа монолитна и трудно адаптируется. Доступ к новым источникам данных требует обширной и трудоемкой работы. Пользователи должны иметь возможность найти источник данных в тот момент, когда они им нужны, затрачивая на это день (или меньше), а не восьмимесячный проект интеграции.

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

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

Глава 2. Что такое архитектура современного предприятия?

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

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

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

Если «технология de jour», как того требует бизнес, соответствует бизнес-цели, современная архитектура упрощает для организации тестирование и проверку возможностей.

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

Глава 3: 5 основных принципов архитектуры современного предприятия

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

1. Правильный уровень «голоса» и лидерства в организации

Если цифровая стратегия становится бизнес-стратегией, то можно начать думать о корпоративной архитектуре как о новой бизнес-архитектуре. В недавнем опросе членов исследовательского круга Gartner каждый пятый респондент (21%) сказал, что корпоративные архитекторы являются «лидерами» в своей организации по оценке новых технологий и несут ответственность за стратегию и решения. Более половины (52%) заявили, что корпоративные архитекторы являются «сотрудниками» в оценке новых технологий, и только 1% назвали роль корпоративных архитекторов «внедрителями».

Это говорит о том, что корпоративная архитектура нуждается в большем голосе при определении бизнес-стратегии. Конечно, это не означает, что нужно отчитываться перед генеральным директором — это нецелесообразно.

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

2. Правильная организационная структура

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

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

Попытка организовать современную корпоративную архитектуру в рамках существующих организационных структур не увенчается успехом. Скорее, организация должна собрать новые команды, ориентированные на бизнес-лидеров и/или владельцев продуктов, а не на технологические дисциплины. Более того, эти команды должны работать не так, как сегодня привыкли работать профессионалы EA. Есть много примеров, на которых можно учиться. Например, Mastercard Labs создает «команды» для превращения инкубационных проектов в коммерческие продукты, члены которых увольняются с работы на шесть месяцев, чтобы работать над проектом.

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

Поскольку Spotify столкнулся с проблемой быстрого создания организационной структуры, которая позволила бы ему масштабироваться и конкурировать с Google и Amazon, он создал отряды, отделения, гильдии и племена, которые работают с «минимально жизнеспособной бюрократией» и «уравновешивают высокую автономию». с высоким выравниванием». Он также установил принципы организационного дизайна, называемые Agile а-ля Spotify, которые напечатаны на стенах его офиса.

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

При разработке архитектуры предприятия специалисты-практики используют как текстовые, так и графические представления, которые включают интегрированный набор составных моделей, обычно представленных в одном из основных инструментов EA. Как только модели включены в инструмент, он позволяет лицам, принимающим решения в организации или расширенном предприятии, запрашивать по всем моделям эффект ряби любого фактического или предлагаемого изменения. Таким образом, как выразился в личной беседе один банковский руководитель, «отключение сервера в автономном режиме на 30 минут повлияет на до полутора миллионов транзакций в разных местах». Точно так же бизнес-решение или изменение бизнес-процесса может оказать существенное влияние на технологию, данные и приложения, что приведет к множеству непредвиденных последствий и затрат. 1 .

Архитектурные представления с этой точки зрения

Архитектура рассматривается как явное представление элементов предприятия, решения или сегмента и их взаимосвязей. Предполагается, что без этого явного представления предприятие не может:

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

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

Как бизнес-функции или возможности связаны со стратегией и целями предприятия?
Есть ли зависимости между возможностями или бизнес-функциями?
Как будет измеряться эффективность бизнес-функций или возможностей?
Когда будут реализованы возможности или бизнес-функции и какие проекты их предоставят?
Какие организации будут использовать возможности или бизнес-функции?
Какие организации отвечают за какие проекты?

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

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

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

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

Недопустимое количество неудачных крупных ИТ-проектов
Потребность в более быстром темпе операций приводит к необходимости обнаруживать и устранять задержки и сокращать продолжительность подключения к клиенту. В случае военных операций необходимость уменьшить задержку разведывательных данных, изображений и других элементов оценки ситуации и оперативных изображений для обеспечения лучшего оперативного планирования и возможностей выполнения;
Слияния и отчуждения, при которых новые части ИТ-среды приобретаются у объединенных предприятий, что приводит к разнообразию стандартов, представлений информации, архитектур, культур и оборудования.
Глобализация, при которой часть рабочей силы находится в разных регионах мира со своей собственной культурой и местными ограничениями по мощности, оборудованию, языкам и другим факторам.
Меняющаяся рабочая сила с новыми способами взаимодействия и совместной работы, различными ожиданиями от рабочей среды, более широким использованием компьютеров, приложений, информации и сетей.
Рост расходов на информационные технологии в целом, несмотря на резкое снижение удельной стоимости обработки и памяти из-за труда, необходимости контролировать устаревание, эволюцию изменений в стандартах и необходимость постоянно обеспечивать все более быструю обработку и увеличение памяти.
Увеличение сложности и масштаба ИТ-проектов как с точки зрения объема, так и охвата. Вытекающая из этого потребность в координации результатов работы большого числа профессионалов, расположенных по всему миру, для успешного завершения проектов. Невозможность полностью оценить влияние сложности и масштаба на уровне планирования или реализации.
Широкое внедрение технологий, основанное на использовании технологий конкурентами, нажиме поставщиков, а также на стремлении соответствовать современным стандартам.
Безудержный аутсорсинг, основанный на финансовом анализе, конкурентном ценовом давлении, а также текущей концентрации предприятия на основной миссии и решении передать все некритические вспомогательные услуги на аутсорсинг.
Потрясающие возможности, связанные с развивающимися стилями архитектуры, такими как сервисно-ориентированная архитектура и облачные вычисления, которые меняют способы построения систем в прошлом и создают новые проблемы планирования, связанные с миграцией громоздких текущих системных инфраструктур в другой тип архитектуры будущего.< /li>

Основная проблема с традиционной точки зрения заключается в том, что корпоративные архитектуры считаются статичными, а их схемы неизменны, если только они не будут целенаправленно пересмотрены. Эта точка зрения не рассматривает предприятия как возникающие сложные адаптивные системы, требующие гибкого подхода. Один крупный организационный теоретик постулировал несколько лет назад, что «Эффективная организация болтлива, неуклюжа, суеверна, лицемерна, чудовищна, восьминообразна, бродяга и ворчлива» (Weick, 1977). модели коммуникации, которые развиваются в ходе ведения бизнеса и в ответ на множество переменных среды в динамично меняющихся бизнес-ландшафтах. Предприятия являются экземплярами сложных адаптивных систем, имеющих множество взаимодействующих подкомпонентов, взаимодействие которых приводит к сложному поведению. Эти динамические взаимодействия на локальном уровне приводят к новым возникающим организационным структурам. Возникающие предприятия несовместимы с традиционным онтологическим взглядом на организацию как на объективно наблюдаемую деятельность. Этот объективный взгляд рассматривает предприятие как нечто, что можно измерить, обозначить, классифицировать и связать с другими организационными процессами. обсуждалось выше, с этой точки зрения ve, EA рассматривает предприятие как статический снимок, который служит основой для целевых архитектур.

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

Архитектура здания

Архитектура предприятия

Фиксированные функции определения

Высоко адаптивная и постоянно меняющаяся адаптивность

Беспорядок, а не проблемы, которые нужно решать

Этот взгляд на предприятие является переопределением характера проблем предприятия, которые решаются с помощью адаптивного и гибкого EA. Как описывает Расс Акофф (1987): «На самом деле проблем не существует. Они отвлекают от реальных ситуаций. Реальные ситуации, от которых они абстрагируются, представляют собой беспорядок. Беспорядок – это система взаимосвязанных проблем. Нас должны волновать беспорядки, а не проблемы. Решение беспорядка не равно сумме решений его частей.Решение его частей должно быть получено из решения целого; не наоборот. Наука предоставила мощные методы, приемы и инструменты для решения проблем, но мало что может помочь в решении неразберихи. Отсутствие возможностей для устранения беспорядка — самая важная проблема, с которой мы сталкиваемся». 5 Роберт Хорн далее описывает этот взгляд на организационные беспорядки 6 следующим образом:

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

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

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

Philip Agre 7 предлагает замену планированию, совместную импровизацию: «Импровизация, как и планирование, включает в себя идеи о том, что может произойти в будущем. ситуации того момента». Смысл взаимодействия ретроспективно придается посредством процесса, который Вейк называет «осмыслением». Это согласуется с переосмыслением EA в новой корпоративной архитектуре.

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

Это переопределение привело к критике преобладающих взглядов на системное мышление, использующих подходы на основе документов и методологии на основе UML для моделирования содержимого как статических, непоследовательных представлений с точки зрения системы. Традиционные технические архитектуры, разработанные с использованием артефактов из метамодели содержания архитектуры TOGAF и различных типов моделей, представленных в FEAF, DoDAF, MoDAF и аналогичных подходах и методологиях, полезны в качестве спецификаций для интеграции текущих систем и портфелей проектов, но также должны учитывать для разработки архитектуры динамической осведомленности о ситуации, необходимой для анализа и планирования миссии, а также сложной природы постмодернистского предприятия.

Мы должны знать, что часто существуют «хорошие организационные причины плохого организационного поведения». То, что мы видим на макроуровне как проблему, часто имеет оправданные причины, если внимательно присмотреться. Плохое поведение является эмерджентным.По мере того, как кто-то переходит от глобального к локальному или производственному уровню, мы часто «теряем явление». Предприятие возникает в результате локального взаимодействия часто независимых единиц, существующих в общей среде. Каждая единица или объект взаимодействует со своим непосредственным окружением в соответствии с набором правил низкого порядка. Комбинированные эффекты этих взаимодействий более низкого порядка в среде порождают организационный феномен более высокого порядка или организационную культуру. Организационная культура возникает из локализованных взаимодействий и основывается на локальном уровне. Следовательно, культура очень устойчива к изменениям. Изменение культуры и преобразование предприятия влечет за собой пересмотр правил на местном уровне, а не просто навязывание изменений сверху. В этом особая ценность активного моделирования знаний, когда структуры признаются динамичными, возникающими и адаптивными; но поддается описанию. Использование формирующейся корпоративной архитектуры, характеризуемой такими динамическими моделями, предлагает механизм для инициирования позитивных изменений.

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

Это имеет значение для EA и, в частности, для методологии разработки архитектуры (ADM) в TOGAF. С точки зрения постмодернистской нетрадиционной архитектуры «быть» — это движущаяся цель, и непрерывные итерации фаз ADM колеблются по мере того, как предприятие адаптируется к переходным архитектурным шагам. Следовательно, области фокусировки трансформируются в эллиптические модели циклов смены. Ожидается взаимодействие и вмешательство из различных областей деятельности, а управление требованиями принимает структуру «улья» или «роя». Это вызывает новый набор опасений:

Есть ли необходимость изменить язык архитектуры?
Нужен ли более динамичный подход, показывающий адаптацию с течением времени?
Возможно, архитектурные артефакты будущего станут больше похожи на фильмы, только с анимацией, растянутой на гораздо более длительный период времени?
Должны ли мы моделировать кластеры, рои и центроиды архитектур с некоторым уровнем связанности (сильно или слабо) и общей функциональностью для подархитектур (например, обобщенные журналы аудита для SOA- системы)?
Будет ли в будущем все больше внимания уделяться дизайну, ориентированному на взаимодействие с пользователем, при этом его будут ограничивать потребности в обеспечении качества обслуживания и стоимость ресурсов?
Какова роль моделирования знаний как артефактов?
Как мы можем создать процесс приобретения, который допускает появление?

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

Примечание. Это обсуждение взято из ранее опубликованной статьи о Emergent and Adaptive EA, написанной в соавторстве с Кеном Гризи и Марком Бергманом из MITRE.

См. Рао, Риди и Беллман, 2011 г.
Книга FEAC по архитектуре предприятия, университетские читатели, 2007 г.
См. Рао, Риди и Беллман, Сертифицированный корпоративный архитектор All-in-On McGraw Hill, 2011 г., глава 2.
Повторная пунктуация в руководстве перед экзаменом
Акофф, Расс, Искусство решения проблем, 1987 г., Wiley.
Хорн, Р. Э. (1998 г.) Визуальный язык: глобальная коммуникация для 21 века, Macro VU, Inc., остров Бейнбридж, Вашингтон.
Philip Agre Computation and Human Experience, Cambridge University Press (28 июля 1997 г.)
См. Hatch, 2006, Организационная теория: современные, символические и постмодернистские перспективы.

Беллман, Берил (редактор), Книга FEAC по архитектуре предприятия, 2007 г., университетские читатели.
Хэтч, М., Организационная теория: современные, символические и постмодернистские перспективы, Oxford University Press, 2006 г.
Лиллехаген Ф. и Крогсти Дж. Активное моделирование знаний предприятий, Springer, 2008 г.
Рао П., Риди А. и Беллман Б., Руководство FEAC по сертификации архитектуры предприятия, McGraw Hill, 2011 г.
Росс, Вейл и Робертсон, Архитектура предприятия как стратегия: создание основы для бизнес-исполнения, HBR Press, 2006 г.
TOGAF 9.2 Издательство Ван Харен; 11-е издание, 2018 г.
Вейк, Карл О повторном акцентировании проблемы в новых взглядах на организационную эффективность; Джосси Басс, 1 977

Не можете найти то, что ищете? Позвоните (703) 333-6098 или свяжитесь с нами.
Если у вас возникли проблемы с нашим веб-сайтом, свяжитесь с нашим веб-мастером.

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

Опубликовано: 14 сентября 2020 г. | Боб Реселман (Red Hat, ведущий участник)

TOGAF, аббревиатура от The Open Group Architecture Framework, предназначен для использования в качестве стандартного способа проектирования и реализации архитектур для очень больших компьютерных систем. Сегодня 80% компаний из списка Global 50 используют TOGAF. Сказать, что у него есть поклонники, это ничего не сказать. Но, каким бы мощным ни был TOGAF, он применим не во всех ситуациях. Те, кто рассматривает TOGAF, должны понимать основы структуры и возможные компромиссы.

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

Зарождение корпоративной архитектуры и TOGAF

Сегодня термин "архитектор" широко используется во всех ИТ-отделах. Это также позиция, к которой многие стремятся. Сегодня у вас есть облачные архитекторы, архитекторы приложений, архитекторы решений, архитекторы безопасности и тому подобное. Кажется, что в ИТ-ландшафте произошел взрыв архитектурной активности. Все это может показаться новым, но дело в том, что разработка крупномасштабных программных систем — это дисциплина, которая существует уже давно, начиная с мэйнфреймов.

Крупные компании стали первыми заказчиками крупномасштабных вычислительных систем. Им нужны были компьютерные системы, чтобы выжить. Для сравнения: в 1955 году в GM работало более полумиллиона человек. И в General Electric, и в U.S. Steel в то время работало более 200 000 человек. Что касается производства, то в 1955 году ведущие производители автомобилей выпустили более семи миллионов автомобилей. Такой масштаб приводит к определенным проблемам. Мало того, что работникам нужно было платить, и их налоговые записи должны были быть выверены соответствующим образом, но каждая часть, которая вошла в продукты компании, должна была быть куплена, распределена и подвергнута инвентарному контролю. Ручная работа, необходимая для поддержки предприятий такого масштаба, была медленной, утомительной и насыщенной деталями. Отсюда появление компьютеров и крупномасштабных программных систем.

Компьютерные бизнес-системы обеспечили огромные преимущества в сокращении ручного труда и ускорении бизнес-процессов. Однако когда дело дошло до создания необходимых программных систем, пришлось много раз изобретать колесо. Это не то же самое, что иметь 40-летнюю историю производства автомобилей. В то время не было истории проектирования программных систем, поэтому много времени уходило на выяснение вещей с нуля. Но выяснение вещей с нуля — это не то же самое, что выяснение вещей случайным образом. Те первые дизайнеры были профессиональными инженерами бизнес-процессов с формальной подготовкой в области логистики, закупок, бухгалтерского учета и организационного управления. Они понимали ценность создания повторяемых и контролируемых методологий проектирования. В начале у этих компаний, возможно, не было ноу-хау для создания компьютерных систем, но они знали, как хорошо делать другие вещи в очень больших масштабах. Помните, что во время Второй мировой войны у Ford Motor Company были организационные возможности для производства одного B-24 Liberator каждый час в режиме 24/7. Этот невероятный темп был обеспечен бизнес-процессами и эффективностью, возможной только при стандартизации. Таким образом, стандартизация методологии проектирования стала следующим шагом в создании крупномасштабных программных систем для того, что впоследствии стало известно как предприятие. Это стремление к стандартизации привело к TOGAF.

Что такое ТОГАФ?

Стандарт TOGAF описывает архитектуру предприятия. Он публикуется и обновляется Open Group. Open Group — это международная организация, насчитывающая более 600 членов из самых разных областей, включая бизнес, правительство и академические круги, в которую входят такие компании, как ExxonMobil, Lockheed Martin, Nissan Motors, и даже организации, типичные для программного обеспечения, такие как Microsoft. , Oracle и Amazon Web Services.

Первая версия TOGAF была опубликована Open Group в 1995 году. Текущей версией TOGAF на момент написания этой статьи является версия 9.2, которую вы можете прочитать здесь как зарегистрированный пользователь. Спецификация TOGAF огромна. Документация TOGAF разделена на семь частей и содержит 52 главы. Кроме того, в публикации есть приложения с описанием терминов, определений и сокращений.

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

Как утверждает Юваль Харари в своей книге Sapiens, максимальное количество людей, которое может состоять в группе, где все члены знают друг друга, составляет около 150 человек, что соответствует размеру растущего стартапа на ранней стадии. Когда группа небольшая, возможна точная устная коммуникация. За пределами этого порога группам необходимо найти другие способы обмена знаниями и налаживания сотрудничества между сотрудниками, которые по сути незнакомы. Таким образом, крупные компании полагаются на документацию в различных форматах, начиная от руководств по политике и процедурам, руководств по персоналу, планов аварийного восстановления и положений о налогах с продаж до информационных бюллетеней для инвесторов, квартальных финансовых отчетов и стратегических официальных документов на уровне руководителей. Какими бы необходимыми ни были эти формы коммуникации, их эффективность зависит от их доступности, и во многих случаях их доступность не оптимальна. Без четкого понимания бизнес-целей, операционных процедур и ограничений вполне возможно создать программную систему, которая полностью не соответствует цели и тратит впустую годы времени и денег. Это критическое ценностное предложение TOGAF. Это архитектурная структура, которая при правильном соблюдении гарантирует, что созданная цифровая система соответствует целям бизнеса. Помните, что TOGAF предназначен для разработки и реализации архитектуры предприятия; программное обеспечение является лишь частью большего целого.

Четыре архитектурных домена TOGAF

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

Таблица 1: 4 архитектурных домена TOGAF

Архитектурный домен	Описание
Бизнес	Формулирует ключевые бизнес-процессы, руководящие принципы управления, организационную структуру и бизнес-стратегию в четко определенный, понятный, унифицированный все. Описывает, как работают текущие бизнес-процессы и как они должны работать для достижения намеченных бизнес-целей в соответствии с документом «Архитектурное видение». Целью документа «Архитектурное видение» является «разработка перспективного видения высокого уровня возможностей и ценности для бизнеса, которые будут реализованы в результате предлагаемой архитектуры предприятия».
Приложение	Предоставляет план приложений, которые необходимо разработать для поддержки бизнес-целей, определенных в документе Architectural Vision. Предполагаемый план описывает определения логических служб приложений, которые необходимо создать или реорганизовать, а также описание интерфейсов, которые представляют данную службу.
Данные	Архитектурная область, в рамках которой разрабатываются логические и физические модели данных. Действия включают разработку новых режимов данных и рефакторинг существующих. Определяет инструменты и технологии управления данными.
Технические	Определяет требуемые аппаратные ресурсы. реализовать задуманную архитектуру. Сюда входят вычислительные, сетевые ресурсы и ресурсы хранения.

Модель разработки архитектуры TOGAF (ADM)

TOGAF не только определяет, что должно быть создано в архитектуре предприятия, что является целью четырех архитектурных доменов, но и определяет, как должна создаваться архитектура.Эта спецификация называется методом разработки архитектуры (ADM). ADM – это восьмиэтапный последовательный процесс, показанный ниже на рис. 1.

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

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

Как узнать больше о модели разработки архитектуры TOGAF?

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

Для чего хорош TOGAF?

Короче говоря, TOGAF хорош для внедрения очень больших систем в очень больших компаниях. Он буквально пытается сделать все возможное, когда дело доходит до создания архитектур, предназначенных для работы в масштабах предприятия.

TOGAF предполагает, что его будут использовать компании со многими отделами, иерархическими с точки зрения структуры и принятия решений. Таким образом, структура отображается непосредственно на эти типы организационных структур. Например, целая глава посвящена описанию того, как создать и управлять архитектурным советом. Архитектурный совет — это центральный комитет по планированию, который наблюдает за проектированием и реализацией архитектуры предприятия. Есть главы об управлении рисками, разделении архитектуры и архитектурных контрактах. Помните, как упоминалось ранее, TOGAF состоит из 52 глав. Это исчерпывающе. Однако, хотя TOGAF хорошо структурирован, он может работать с другими методологиями, такими как Agile и DevOps. TOGAF понимает, что лучше всего подходит компаниям, которые являются хорошо структурированными организациями, но также понимает, что нет двух одинаковых компаний.

TOGAF поддерживает универсальность. TOGAF принимает итеративную модель, которая является важным компонентом Agile. На самом деле в TOGAF есть глава под названием «Применение итерации к ADM», в которой обсуждается природа и реализация итерации в модели разработки приложений. Кроме того, TOGAF может обеспечить DevOps.

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

TOGAF – большой, детализированный и абстрактный инструмент. Эти качества позволяют применять его в самых разных компаниях. Имейте в виду, однако, что TOGAF подходит не всем. У него есть ограничения.

Какие ограничения?

Как упоминалось в начале этой статьи, TOGAF предназначен для очень крупных компаний, которые хотят внедрить очень большую корпоративную архитектуру. Помните, что системы, построенные по TOGAF, обычно затрагивают тысячи сотрудников. Бюджет корпоративной архитектуры нередко начинается с миллионов долларов. Следовательно, ключевым ограничением TOGAF является цена. Компания должна иметь глубокие карманы, чтобы покрыть расходы. Если ваша компания имеет стартовый капитал в размере 100 000 долларов, TOGAF не для вас. Вы съедите эти 100 000 долларов только за встречи.

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

Последнее ограничение TOGAF заключается в том, что для изучения деталей спецификации требуется много времени. Спецификация TOGAF составляет более 800 страниц. Это много информации, которую нужно усвоить и запомнить.

Как правило, компании, намеревающиеся использовать TOGAF, хотят, чтобы их корпоративные архитекторы были сертифицированы TOGAF.Чтобы получить сертификат, кандидаты должны сдать экзамен, который состоит из двух частей. Часть 1 представляет собой тест из 40 вопросов с несколькими вариантами ответов, который проверяет ваши базовые знания структуры TOGAF. Часть 2 — это основанный на сценариях тест, в котором вам дается восемь сценариев, описывающих различные ситуации, в которых будет использоваться TOGAF. К каждому сценарию прилагается вопрос с несколькими вариантами ответа. В отличие от части 1, где ответы либо правильные, либо неправильные, за ответы на вопросы части 2 начисляются баллы в зависимости от степени правильности.

Как видите, для изучения TOGAF требуется значительное количество времени и еще больше времени для получения опыта, необходимого для грамотной работы с ним. Если у вас есть время и средства для изучения TOGAF и вы хотите работать в крупной компании, которая получит от этого выгоду, тогда TOGAF для вас. В противном случае его профессиональная ценность ограничена.

Собираем все вместе

Архитектура предприятия (EA) — сложная задача. По словам эксперта по EA Кена Гейзи в статье в журнале Forbes, «EA — это умелое манипулирование структурой и поведением предприятия в сложной среде».

Когда вы станете размером с Boeing или Hewlett Packard, вы не сможете наверстать упущенное в процессе работы. Вам нужна структура, такая как TOGAF, чтобы обеспечить формальность, структуру и дисциплину, которые необходимы крупным компаниям для внедрения архитектур предприятия, которые затрагивают десятки или, может быть, сотни тысяч сотрудников. Риски слишком велики, чтобы поступать иначе. Не случайно TOGAF используют 60% компаний из списка Fortune 500. TOGAF предназначен для того, чтобы делать большие дела в больших компаниях по-крупному.

Хотя некоторые недоброжелатели говорят, что TOGAF хорош в теории, но редко применяется на практике, факт остается фактом: сегодня в мире насчитывается более 77 000 корпоративных архитекторов, сертифицированных по TOGAF. TOGAF по-прежнему занимает важное место в ландшафте корпоративной архитектуры. Хотя это высокоструктурированная структура, она не статична. С момента дебюта в 1995 году он претерпел девять изменений. Будем надеяться, что, как показывает его история, он продолжит меняться. Предприятию нужен TOGAF, и он должен меняться, чтобы идти в ногу с новыми технологиями и тенденциями, которые появятся на предприятии в ближайшие годы.

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

Откройте для себя мировые исследования

20 миллионов участников
135 миллионов публикаций
Более 700 тыс. исследовательских проектов

<р>. [7]. Чтобы найти решение этой проблемы, исследователи, с одной стороны [8][9], [10], [11], и промышленность [12], с другой, тестировали различные решения, основанные на архитектуре предприятия, создавая эталонные фреймворки, называемые фреймворками. . [13]. .

Информационные технологии (ИТ) обещают большие преимущества. Однако у компаний возникают проблемы согласования бизнеса, влияющие на инвестиции, производительность и гибкость. Для достижения согласованности были разработаны эталонные модели архитектуры предприятия (EA), называемые Frameworks. Эти предложения родились в крупных компаниях и их разработка имеет традиционный подход к этим реалиям. Однако в Перу большинство компаний являются микропредприятиями, то есть небольшими организациями (SO) со своими особенностями. SO имеют низкий индекс сетевой готовности (NRI), что оказывает незначительное влияние на развитие Перу.Таким образом, в этой статье предлагается новая методология бизнес-архитектуры, разработанная для небольших перуанских и латиноамериканских организаций. Был разработан общий метод, основанный на критериях EA и SO, что позволило создать метамодель, из которой конкретизируются элементы методологии, объединяющей четыре подхода к управлению ИТ. Разработанная методология была проверена в перуанской SO и экспертами. Предварительные результаты показывают, что его использование дает преимущества по сравнению с конкурентами.

<р>. Как видно из таблицы 2, определение EA зависит от источника. [4]; [7]; [17]; [20]; [21]; [31]; [32]; [34]; [39]; [40]; [48] [3]; [5] ; [16]; [19]; [27]; [42]; [45]; [46]; [47] [1]; [10]; [11]; [13]; [15]; [24]; [25]; [35] Практик Определения, встречающиеся в литературе и данные опрошенными практикующими врачами, распределяются по классам примерно одинаково. Анализ хи-квадрат (5,202, p = 0,158) таблицы непредвиденных обстоятельств также не предполагает, что переменные будут зависимыми. .

В этом исследовании рассматривается развивающаяся дисциплина архитектуры предприятия (EA) и различные определения, данные EA в литературе и практиками. Из-за потенциальных преимуществ, таких как согласование бизнеса и ИТ, ученые и практики сохраняют интерес к архитектуре предприятия. EA был разработан вне научно проверенных основ и характеризуется разнообразными взглядами, проявляющимися в различных определениях, данных понятию. Предыдущие исследования определили необходимость концептуального укрепления как необходимость для созревания дисциплины. Мы вносим свой вклад в эту продолжающуюся дискуссию систематическим обзором литературы по современным определениям EA и 26 подробными интервью с практиками. Наше исследование показывает, что, хотя общего определения EA до сих пор нет, его масштабы и цели все больше расширяются от первоначальной цели согласования ИТ-бизнеса до инструмента целостного организационного проектирования и разработки в условиях системы в среде. <р>. Как видно из таблицы 2, определение EA зависит от источника. [8]; [9]; [12]; [36]; [41]; [43]; [44] [4]; [7]; [17]; [20]; [21]; [31]; [32]; [34]; [39]; [40]; [48] [3]; [5] ; [16]; [19]; [27]; [42]; [45]; [46]; [47] [1]; [10]; [11]; [13]; [15]; [24]; [25]; [35] Практик .

<р>. Некоторые считают его неполным. Существует множество терминов и три школы мысли об EA (Buckl, Matthes, & Schweda, 2009; Lapalme, 2012; Schöenherr, 2008). .

Целью этой статьи является исследование влияния архитектуры предприятия (EA) на прозрачность. Исследование носит ознакомительный характер и основано на одном случае (Yin, 2011). Проведено несколько интервью и проведено количественное исследование. Это исследование показало, что советник считается запутанным, а не инструментом управления. Предпосылка, как утверждается в литературе, о том, что ЭА увеличивает прозрачность, в данном случае не обнаруживается. Следовательно, эта предпосылка не всегда может быть справедливой для организаций. Однако необходимы дальнейшие исследования, поскольку это только один случай.

В этой диссертации обсуждается архитектура предприятия (EA) с системной точки зрения в контексте экосистем финского государственного сектора. ЭА касается элементов и отношений, которые существуют в социотехнической организации, описывая и проектируя согласованные целостности. В последнее время возрос интерес к изучению взаимосвязи между АП и системными подходами, а также к разработке АП для решения проблем, связанных со взаимосвязанностью организаций. Хотя АП и системные подходы по своей сути имеют общие черты, предшествующих исследований по теоретической поддержке системных подходов в области АП мало. Кроме того, практическое применение ЭА в экосистемных средах является новой, но малоизученной темой. На исследовательский вопрос этой диссертации — как следует развивать EA, чтобы лучше использовать его в общественных экосистемах? — отвечает прояснение концепций и отношений между концепциями, связанными с проблемой, и определение роли различных теоретических, концептуальных и эмпирических конфликтов в проблемный домен. Практическое применение EA в экосистемах решается путем создания артефактов науки о проектировании, а именно модели управления и принципов проектирования целевого состояния архитектуры государственной экосистемы. Этот тезис способствует как теоретическим, так и практическим дискуссиям. Во-первых, предлагается всесторонний и всеохватывающий взгляд на текущее состояние EA, отмечая, что объем и цель EA, кажется, смещаются, чтобы включить новую роль в целостном проектировании и развитии организаций в системных средах. Во-вторых, системные подходы исследуются как обеспечивающие возможные теоретические основы для EA для проектирования, моделирования и управления социотехническими системами. В-третьих, созданные артефакты науки о дизайне способствуют практическому применению EA в экосистемах.Вопреки традиционному взгляду на EA как на структуру одной организации, в этом тезисе EA предлагается как концепция организационного дизайна экосистемы государственного сектора.

Архитектура предприятия – это набор артефактов, описывающих различные аспекты организации с точки зрения интегрированного бизнеса и ИТ. Практика архитектуры предприятия в организациях подразумевает использование этих артефактов для облегчения планирования информационных систем и улучшения согласования бизнеса и ИТ. Несмотря на свою долгую историю, дисциплина архитектуры предприятия по-прежнему остается в значительной степени атеоретической и не имеет прочной теоретической базы. Основываясь на наших предыдущих эмпирических исследованиях практического использования артефактов архитектуры предприятия в различных организациях и обширном анализе литературы, в этой концептуальной статье определяются и подробно обсуждаются 10 теорий, которые можно считать ключевыми для понимания того, как работает практика архитектуры предприятия: теория актор-сетей , теория пограничных объектов, теория когнитивного соответствия, теория сообществ практики, теории принятия решений, теория обработки информации, теория управления знаниями, теория моды управления, теория богатства медиа и принцип неопределенности. Взятые вместе, эти теории предлагают всесторонний теоретический взгляд на практику архитектуры предприятия, объясняя роль артефактов архитектуры предприятия, их удобство использования и участие заинтересованных сторон и, следовательно, могут составлять теоретическую основу всей дисциплины архитектуры предприятия. Хотя эта статья не развивает ни одну из этих теорий, она проливает свет на эти теории, устанавливает их критическую важность для понимания практики архитектуры предприятия и позиционирует их как центральные в дискурсе архитектуры предприятия. Каждая из этих теорий может быть использована исследователями архитектуры предприятия в своих будущих исследованиях для анализа практик архитектуры предприятия через соответствующие теоретические призмы. Эта статья призвана предоставить свежие теоретические сведения об архитектуре предприятия, вызвать новые волны теоретических исследований в области архитектуры предприятия и внести вклад в разработку прочной теоретической основы для дисциплины архитектуры предприятия.

Читайте также: