Какая из методологий управления архитектурой предприятия является статичным фреймворком
Сафронов Алексей Андреевич 1 , Давлеткиреева Лилия Зайнетдиновна 2 , Макашова Вера Николаевна 3
1 Магнитогорский государственный университет, магистрант, 2-ой курс
2 Магнитогорский государственный университет, кандидат педагогических наук, доцент кафедры ИС
3 Магнитогорский государственный университет, кандидат педагогических наук, доцент кафедры ИТ
Аннотация
Данная статья посвящена сравнительному анализу методологий построения архитектуры предприятий.
Safronov Alexey Andreevich 1 , Davletkireeva Lily Zaynetdinovna 2 , Makashova Vera Nikolaevna 3
1 Magnitogorsk State University, 2nd year Master degree student
2 Magnitogorsk State University, Ph.D., Associate Professor, Department of IS
3 Magnitogorsk State University, Ph.D., Associate Professor, Department of IT
Abstract
This article focuses on the comparative analysis of methodologies for constructing enterprise architecture.
Архитектура предприятия – это ни что иное как совокупность технологических и человеческих факторов, главной задачей которых стоит развитие предприятия имеющего краткосрочные и долгосрочные цели. Успех современных предприятий зависит от того, насколько быстро и эффективно оно может отвечать требованиям в условиях меняющихся тенденций. Таким образом, «архитектура предприятия» показывает нам способы и методы бизнес-стратегии компании. Направление «Архитектура предприятия» появилось более четверти века назад, для решения таких задач как: организация работы бизнеса, сокращение расходов, гибкость управления предприятием.
Стоит отметить основные этапы разработки архитектура компании:
- Определение и обоснование цели архитектуры.
- Анализ текущего состояния архитектуры.
- Анализ рисков.
- Разработка плана миграции.
- Управление реализацией проекта внедрения.
- Выполнение намеченного плана.
Существует множество фреймворков для построения архитектуры предприятия, однако встречаются организации, для которых не подходят готовые решения, и приходится прибегать к так называемым смешанным фреймворкам. Для реализации «смешанного фреймворка» выбираются и изменяются необходимые разделы из каждой методологии и подстраивают под нужды и задачи организации. Несколько примеров фреймворков:
- Фреймворк Захмана – первый и самый известный фреймворк.
- FEAF- разработанный в США для правительственных нужд фреймворк.
- TOGAF- международный фреймворк, разработанный сотнями компаний, которые входят в единую организацию.
- EAF- фреймворк разработанный на основе TOGAF компанией SAP.
Рассмотрим более детально приведенные выше фреймворки, как наиболее популярные.
Методология TOGAF представляет собой инфраструктуру архитектуры предприятия, которая появилась 20 лет назад для разработки стандарта архитектуры предприятия. Фреймворк разработан независимым консорциумом The Open Group, для установки открытых стандартов в области информационных технологий.
TOGAF включает в себя 7 частей:
- Введение. Описание ключевых концепций.
- Методы разработки архитектуры.
- Руководящие принципы и методы.
- Содержимое фреймворка архитектуры.
- Континуум предприятия и инструменты.
- Эталонная модель TOGAF.
- Архитектурная возможность фреймворка.
Архитектура предприятия в TOGAF разделена на четыре домена (рис. 1)
Рисунок 1. – Компоненты архитектуры предприятия по TOGAF
Бизнес-архитектура содержит стратегию компании, методы управления, ключевые бизнес-процессы компании.
Архитектура информационных систем описывает, как устроена ИС в компании. Обычно делится на две части:
- Архитектура данных;
- Архитектура приложений.
Техническая архитектура описывает программное обеспечение и оборудование, необходимое для развертывания информационной инфраструктуры. В TOGAF процессы реализации архитектурных решений описаны в цикле ADM. ADM можно нужно изменять и адаптировать под нужды компании. Нет необходимости делать все документы или погружаться во все детали. На каждом последующем этапе ADM предлагает готовый набор инструментов и шаблонов, так называемый конструктор. Ниже на приведена схема ADM ( рис. 2)
Структура ADM включает в себе 10 этапов:
- Предварительная фаза.
- Видение архитектуры.
- Бизнес-архитектура.
- Архитектура информационных систем.
- Техническая архитектура.
- Возможности и решения.
- Планирование миграции.
- Управление реализацией.
- Управление изменениями архитектуры
- Управление требованиями.
Рисунок 2 – Схема TOGAF ADM.
Методология TOGAF и инфраструктура Захмана хоть и объединены к категории «инфраструктур предприятия», но имеют отличия в своих принципах, структурах и компетенциях. TOGAF- представляет собой функциональную и динамичную инфраструктуру, которая включает руководящие принципы моделей процесса их использования. В то время как фреймворк Захмана представляет собой статичную структуру архитектуры, наиболее эффективна для применения анализа и метаанализа фреймворков инфраструктур. Несмотря на значительные отличия данных фреймворков их можно использовать совместно.
Методология Захмана, как правило, представлена в виде таблицы имеющей 5 строк и 6 столбцов, которая представлена на рисунке 3.
Рисунок 3- Модель Захмана.
Верхние две строки в общем представлении описывают существующее окружение, планы и цели. Они, по сути, являются базовыми при построении «архитектуры предприятия», так называемый «фундамент», если сравнивать со строительством. Каждый последующий уровень является более детальным, но так, же является «абстрактным». Каждая из строк описывает точку зрения какого-либо участника проекта по созданию архитектуры.
FEA- фреймворк разработанный правительством США, как некий подход для развития информационных технологий правительственных учреждений, приведенный к использованию единой архитектуры.
В основе FEA лежат пять эталонных моделей:
- Исполнительная модель.
- Бизнес-модель.
- Сервисная модель Компонента.
- Техническая эталонная модель.
- Эталонная модель данных.
Одно из полезных свойств фреймворка FEA – принцип сегментного подхода, дает возможность ускорить внедрение «Архитектуры предприятия».
Процесс разработки архитектуры предприятия по методологии FEA изображен на рисунке 4.
Рисунок 4- Процесс разработки архитектуры по FEA.
Данная методология применима и за пределами государственного сектора экономики.
Методология Garther – по сути своей не является методологией, как например структурированная модель Захмана, ни процессом как TOGAF, ни как FEA. Garther – является набором практических рекомендаций. Данная методология является сборником советов по построению архитектуры предприятия от одной из наиболее известных в мире консалтинговых ИТ-компаний – Garther. Данный фреймворк представляет собой трехмерный куб, состоящий из слоев:
- Горизонтальные слои.
- Вертикальные домены.
- Вертикальные элементы технической архитектуры.
Так как выше описанные методологии сильно отличаются друг от друга, следует задать критерии для их сравнения.
- Полнота таксономии, определяет, насколько методология пригодна для классификации различных архитектурных артефактов. Полностью сосредоточена на фреймворке Захмана.
- Полнота процесса, определяет, насколько детально представлен процесс создания архитектуры предприятия.
- Руководство по эталонным моделям, определяет полезность методологии в создании адекватного набора эталонных моделей. На этом практически полностью сосредоточена методология FEA.
- Практическое руководство определяет, насколько методология позволяет воплотить в жизнь умозрительное представление об архитектуре предприятия и сформировать культуру, в которой эта архитектура будет использоваться. На этом практически полностью сосредоточена методология Gartner.
- Модель готовности определяет, насколько методология позволяет оценить эффективность использования архитектуры предприятия в различных подразделениях.
- Ориентированность на бизнес определяет, ориентирована ли методология на использование технологии для повышения ценности бизнеса, где ценность бизнеса определяется как снижение затрат или увеличение доходов.
- Руководство по управлению определяет, насколько методология полезна в понимании и создании эффективной модели управления для архитектуры предприятия.
- Руководство по разбиению определяет полезность методологии в эффективном разбиении предприятия на отделы, что весьма важно при управлении сложностью.
- Наличие каталога определяет, насколько эффективно методология позволяет создать каталог архитектурных активов, которые можно будет использовать в дальнейшем.
- Нейтральность по отношению к поставщикам услуг определяет вероятность того, что при внедрении методологии вы окажетесь привязанными к конкретной консалтинговой организации. Высокая оценка означает низкую степень привязки к конкретной организации.
- Доступность информации определяет количество и качество бесплатных или относительно недорогих материалов по данной методологии.
- Время окупаемости инвестиций определяет продолжительность периода, в течение которого вы будете использовать данную методологию, прежде чем сможете построить на ее основе решения, обеспечивающие высокую ценность бизнеса.
Каждой из методологий будет присвоена оценка по каждому из критериев от 0 до 5 (0 – непригодная для данной области, 5 –отлично работает в данной области)
В продолжение статьи о классическом PRINCE2 по запросу из комментариев попробовала сравнить ключевые методики управления проектами. Надеюсь, что получилось что-то полезное и при выборе подхода управления у читающих часть вопросов будут снята.
Краткие вводные:
PRINCE2 (Projects in a Controlled Environment) – структурированный метод управления проектами, разработанный в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании.
PMBoK – фреймворк (свод знаний) по управлению проектами, разработанный в 1996 году Project Management Institute (PMI) в США.
ISO 21500:2012 «Guidance on project management» - международный стандарт, разработанный проектным комитетом ISO/PC 236 «Управление проектами».
Как можно заметить, первое главное отличие – собственное позиционирование в проектном управлении. Остальные основные отличия с некоторыми субъективными выводами приведены в таблице.
PRINCE2
PMBoK (6 издание, 2017г.)
ISO 21500:20112
Определение проекта
Временная организация, которая создается с целью предоставления одного или нескольких бизнес-продуктов в соответствии с утвержденным экономическим обоснованием проекта.
Временное предприятие, направленное на создание уникального продукта, услуги или результата.
Уникальная совокупность процессов, состоящая из контролируемых и управляемых видов деятельностей с датами начала и завершения, предназначенная для достижения определенных целей.
Процессы
7 процессов: Начало проекта, руководство проектом, инициация проекта, контроль стадии, управление границами стадии, управление созданием продукта, закрытие проекта.
49 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, мониторинг и контроль, закрытие.
39 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, управление, завершение.
Предметные темы / группы (курсивом отмечены различающиеся темы)
7 тем:
1. Экономическое обоснование,
3. Управление качеством,
5. Анализ и управление рисками,
6. Управление изменениями содержания,
7. Принятие решений.
10 областей знаний:
1. Управление интеграцией проекта,
2. Управление содержанием,
3. Управление сроками,
4. Управление стоимостью,
5. Управление качеством,
6. Управление человеческими ресурсами,
7. Управление коммуникациями,
8. Управления рисками,
10. Управление заинтересованными сторонами.
10 предметных групп:
2. Заинтересованные стороны,
Жизненный цикл проекта
Структура стадий проекта:
1. Стадия инициации,
2. Последующие стадии (создание продуктов, соответствующих требованием),
3. Финальная стадия (приемка результатов, подведение итогов проекта).
Минимальное количество стадий в проекте – 2 (инициация и финальная).
Все проекты могут иметь следующую структуру жизненного цикла:
1. начало проекта;
2. организация и подготовка;
3. выполнение работ проекта;
4. завершение проекта.
В стандарте отсутствуют четкие требования/пояснения по стадиям проекта, стандарт определяет, что проект должен подразделяться на фазы, состав и содержание которых должно определяться потребностями управления и контроля.
Принципы
7 принципов (универсальны и не требуют обоснования):
1. Постоянная оценка целесообразности,
2. Учет предыдущего опыта,
3. Определенные роли и обязанности,
4. Управление по стадиям,
5. Управление по исключениям,
6. Фокус на продукте,
7. Адаптация к внешним условиям.
Шестое издание PMBoK основано на процессной составляющей с четкими входами, выходами и инструментарием.
Ожидается, что новое седьмое издание будет ориентировано на принципы.
ISO 21500 по аналогии с PMBoK основан на процессной составляющей.
Ответственность за результат проекта
Ответственный руководитель (куратор/спонсор проекта) полностью отвечает за успех проекта.
Менеджер проекта управляет проектом на ежедневной основе в рамках полномочий, делегированных Управляющим советом.
Руководитель проекта = единый ответственный за результат.
Руководитель проекта обеспечивает общее руководство и управление работами проекта и отвечает за получение результатов проекта.
Инструменты управления
В методологии отсутствуют примеры инструментов, данная область отдается на откуп Руководителю проектов.
Предоставляет расширенный список инструментов и методов по каждому процессу управления проектом.
Стандарт не описывает конкретных инструментов для реализации процессов управления.
Возможность гибкого применения
Допускает использование минимального количества документов с минимальным требуемым содержанием, гибкое использование метода с соблюдением всех 7 принципов позволяет подготавливать упрощенную отчетность и минимизировать процессы управления (с учетом целей и задач, которые соответствуют процессам PRINCE2).
Так как PMBoK является не методологией или стандартом, а фреймворком, его создатели рекомендуют использовать PMBoK для создания собственной методологии управления проектами в компании. При этом созданная методология должна учитывать особенности каждого отдельного проекта и позволять руководителю проектов изменять процессы управления в определенных пределах.
Описанные в стандарте процессы не должны применяться без изменений ко всем проектам или фазам жизненного цикла проекта. Руководитель проекта должен корректировать состав процессов управления конкретным проектом или фазой, отбирая подходящие процессы и условия их реализации. Такая адаптация должна выполняться в соответствии с существующими политиками организации.
Вторая статья про мифологическое сознание тоже будет короткой. Сегодня я расскажу, к каким проблемам приводит мифологическое сознание при моделировании архитектуры предприятия.
Известная модель Захмана пытается ответить на вопрос, что такое архитектура предприятия, и рассказывает о том, как она должна моделироваться. Основой этой модели являются вопросы, на которые предлагается ответить: кто, когда, где, почему и как совершает что-то над чем-то. Кажется, что это логичный фреймворк для описания архитектуры предприятия, и многие думают, что так оно и есть.
Однако, даже беглый взгляд на этот фреймворк оставляет чувство неудовлетворенности, потому что не понятно, как ответить на вопрос: кто и почему выточил деталь? Кто: Иван Иванович, или токарь, роль которого исполнял Иван Иванович? Почему: потому что токарь получил задание, или потому что Иван Иванович заключил контракт, в соответствии с которым он обязуется выполнять роль токаря в обмен на еду? Почему: потому что Иван Иванович хочет покушать, или затем, что деталь нужна в сборочном цехе?
Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!
Читатель, натренированный в описании архитектур предприятий, быстро меня поправит. Он скажет, что я неправильно ставлю вопросы. Надо спрашивать: кто выращивает, почему он выращивает, что выращивает. Но тогда получается, что я могу описать деятельность субъекта, который выращивает кукурузу, но не могу описать сам рост. Смирившись с тем, что я не могу описать процесс роста, у меня все равно остаются неразрешенные вопросы: кто и почему выращивает кукурузу (см. выше)?
Если посмотреть на вопросы, которые задаются в модели Захмана, можно убедиться, что они в точности соответствуют теории деятельности. Деятельность – это психическая функция субъекта (группы субъектов). Поэтому, отвечая на вопросы Захмана, мы строим модель психической функции субъекта (субъектов). Наука, изучающая психические функции субъектов, называется психология. Получается, что Захман отвечает на вопросы, которыми задаются психологи: зачем субъект делает то или иное действие? Или как мотивировать субъекта на выполнение тех или иных действий? Эти вопросы, безусловно, интересные и важные, но являются ли ответы на них описанием архитектуры предприятия? Чтобы ответить на этот вопрос, надо понять, что же такое предприятие?
Как же на самом деле происходит проектирование предприятия и какие артефакты при этом возникают? Прежде чем проектировать предприятие, строится модель требований к нему. Модель требований формируется на основе требований, которые предъявлены к этому предприятию со стороны всех его участников, контрагентов и стейкхолдеров. Аналог в ИТ — требования к программному продукту. Далее на основе этих требований строится модель процессов предприятия с необходимой степенью детализации. Аналогом в ИТ будет перечень функций программного продукта. Далее строится модель функциональных объектов, или, говоря специализированным языком, технических мест, которые должны участвовать в перечисленных ранее процессах. Аналогом в ИТ будет описание процедур, и объяснение какие процедуры в каких функциях участвуют. Далее подбираются те единицы оборудования, которые могут выполнять роли перечисленных технических мест. Аналог в ИТ — это программный код.
Предприятие – это функциональный объект, который создан удовлетворяющим определенным требованиям. В этом смысле предприятие ничем не отличается от такого объекта, как часы, или производственная линия. Часто вместо термина функциональный объект можно услышать термин техническое место. Техническое место отличается от единицы оборудования тем, что единица оборудования выполняет роль технического места. Например, трансформатор выполняет роль преобразователя напряжения, при этом в разное время разные трансформаторы могут выполнять роль одного и того же преобразователя. Еще одним примером технического места является должность, отдел, подразделение, штат. Например, токарь участвует в функции изготовления деталей. Это — техническое место, роль которого в разное время могут выполнять разные единицы оборудования (физические лица). О сложностях моделирования технических мест и единиц оборудования я кратко написал в статье Моделирование активов предприятия: современные стандарты и практика.
При моделировании технических мест, мы описываем процессы и участников этих процессов. Замечу, что именно участников, а не исполнителей, — трансформатор не может преобразовывать напряжение, потому что он не является одушевленным существом. Об этом я писал в прошлой статье Моделирование активности и мифологическое сознание. Если все же сказать, что трансформатор «преобразует» напряжение, то это – метонимия, которая раскрывается так: трансформатор, исполняет роль преобразователя напряжения, который (преобразователь) участвует в процессе преобразования напряжения. О метонимии можно прочитать в книге «Метафоры, которыми мы живем», авторы: Джордж Лакофф, Марк Джонсон. Другой распространенной метонимией будет высказывание: «компьютер решает задачи». Те же, кто действительно считают, что трансформатор, или компьютер что-то делает на самом деле, одушевляют неодушевленное, пользуясь мифическим сознанием.
Заметим, что до сего момента мы ни слова не сказали о целях, об исполнителях и причинно-следственных связях. Мы лишь говорили о требованиях, о функциях и участниках этих функций – технических местах. Цели остались на этапе формирования требований к предприятию и далее они не пошли. Мы можем знать эти цели, а можем не знать, — для модели предприятия это не имеет никакого значения. Модель предприятия отвечает на вопрос: как мы удовлетворяем требования, а не то, откуда взялись эти требования. Исполнителей тоже нет, потому что нам не надо пользоваться теорией деятельности, чтобы описать участников активности. Мы не строим причинно-следственные связи. Если же надо построить модель причинно-следственных связей, то это еще одна дополнительная модель. Это знания, которыми пользуются технологи при проектировании предприятия, и я не видел, чтобы кто-то строил такие модели. Это — отраслевые знания, и учат им в институтах по много лет. Смоделировать, почему летит самолет – нереально трудно, и никто этого не делает. Просто моделируют полет самолета.
Итак, модель Захмана не включает в себя требования к предприятию, включает в себя модель процессов, но довольно специфическим способом — с указанием на исполнителей процесса, которых, как я уже сказал можно найти только в теории деятельности, и не разделяет модель технических мест и модель единиц оборудования.
Как я сказал ранее, модель Захмана скорее про деятельность. При этом было бы неплохо, если бы модель Захмана использовалась по назначению, — как способ описания деятельности. Это давало бы возможность анализировать мотивы и заинтересованность людей в их работе, но беда в том, что эта модель используется неверно. Например, на вопрос «почему токарь точит деталь?» можно получить ответ: «она нужна в сборочном цехе». Но необходимость ее в сборочном цехе не отвечает на вопрос, почему токарь точит деталь. Ответ был не на поставленный вопрос, а на какой-то другой. Например, для такого ответа правильным был бы вопрос: в каком процессе, или в какой операции должна участвовать выточенная деталь? Или на каком рабочем месте она нужна? Вы видите, что это совсем не вопрос «почему?». Кроме того, меня сильно смущает наделение Захманом компьютера или информационной системы способностью что-то делать. Скорее всего, он не одушевляет их, но использует метонимию в моделировании, что на мой взгляд, недопустимо.
Правильными вопросами будут: Какие существуют требования к предприятию? Какие процессы протекают на предприятии? Какие технические места в каких процессах участвуют? Какие единицы оборудования выполняют роли каких технических мест и когда?
Контрольные вопросы
к лекции № 2 «Основные методологии описания архитектуры предприятия»
по предмету
«Архитектура предприятия»
- Впервые понятие «архитектура предприятия»появилось:
- Модель архитектуры предприятия, содержащая следующие 6 уровней абстракций: контекстуальный; уровень взаимодействия; концептуальный; логический; физический; трансформационный – это:
А) модель Захмана ;
Б ) модель Extended Enterprise Architecture Framework (E2AF);
В) модель Gartner .
- Модель архитектуры предприятия, содержащая следующие 6 описательных аспектов: данные; функции; сеть; люди; время; мотивация – это:
Б) модель Захмана;
В) модель META Group.
- Модель архитектуры предприятия, сформулированная в виде следующих 4-х взаимосвязанных, взаимозависимых и усложняющихся уровней: среда бизнес-взаимодействия; бизнес-процессы и стили бизнес-процессов; шаблоны; технологические строительные блоки – это:
А) модель Захмана;
Б) модель Gartner;
5. Модель архитектуры предприятия, в которой архитектура предприятия подразделяется на следующие 4 категории: архитектура бизнеса; архитектура приложений; архитектура данных; технологическая архитектура – это:
А) модель TOGAF ;
Б) модель Захмана;
В) модель Gartner .
- Мир архитектуры предприятия рассматривается как континуум архитектур: от максимально обобщенных до максимально специализированных:
А) в модели Захмана;
Б) в модели Gartner ;
В) в модели TOGAF .
- «Трехмерная» комбинация бизнес-архитектуры, технической архитектуры и информационной архитектуры представлена:
А) в модели Захмана;
Б) в модели Gartner ;
В) в модели «3 D -предприятие» .
- Модель архитектуры предприятия, построенная с учетом временного пространства – это:
А) модель «3 D -предприятие» ;
Б) модель Захмана;
В) модель Gartner .
- Организация рабочего процесса разработки архитектуры начинается с разработки Видения общих требований ( CRV – Common Requirements Vision ) в модели:
А) META Group ;
10. Методика ADM ( Architecture Development Method) и Базовая Архитектура (Foundation Architecture) являются компонентами модели :
В статье рассматриваются современные подходы в архитектуре предприятий, их особенности, достоинства и недостатки. Изучены фреймворк Захмана, подход TOGAF и методология компании “Gartner”.
Ключевые слова: архитектура предприятия, фреймворк, методы разработки, архитектурные подходы, управление предприятием
В современной информационной бизнес-среде многие организации имеют проблемы с изменением существующей архитектуры предприятия. Сложность может быть вызвана отсутствием понимания структуры предприятия и взаимодействия ее отдельных компонентов. В связи с этим возникает вопрос, как правильно организовать информационную систему бизнес-структуры, чтобы в дальнейшем ее можно было масштабировать и улучшать. Поэтому целью данной статьи является рассмотрение современных архитектурных подходов к устройству информационной системы организации, выделение их особенностей, достоинств и недостатков.
Родоначальником современных архитектурных подходов является Джон Захман с его методологией (фреймворком), которую он опубликовал в 1987 году. Суть ее заключается в том, что стадии жизненных циклов элементов относятся к точке зрения определенного представителя организации. Участники отвечают на одинаковые вопросы, расположенные в столбцах таблицы, но с различным уровнем абстракции. В целом архитектура представлена в виде матрицы, представленной на рисунке 1.
Рис. 1. Матрица архитектуры предприятия Захмана
Достоинства и недостатки подхода Захмана
Достоинства
Недостатки
простота и полнота понимания
отсутствие оси времени, для видения динамики развития организации.
бедность описания с технических позиций.
Один из самых известных архитектурных фреймворков это TOGAF . Он продвигается как методология архитектуры предприятия. Ядро этого фреймворка представлено методом разработки архитектуры (Architecture Development Method) или ADM. С точки зрения определения общего языка, у TOGAF есть два важных элемента.
- Структура архитектурного контента (Architecture Content Framework) — выделяет набор ключевых артефактов, произведенных для поддержки архитектуры
- Техническая эталонная модель (Technical Reference Model) — предоставляет модель и систематику общих сервисов на платформе.
TOGAF получил широкое распространение в индустрии за рубежом и в России. Большинство архитекторов предприятий стремятся получить его аккредитацию, однако нельзя сказать, что TOGAF это эталон проектирования, он довольно часто подвергается критике последователями других методологий. Схема представлена на рисунке 2.
Рис. 2. Структура разработки архитектуры по TOGAF
Достоинства и недостатки подхода TOGAF
Достоинства
Недостатки
Наличие метода разработки (ADM)
Высокий уровень абстракции, нет практической реализации
Свободное распространение и бесплатное использование для внутренних проектов
Отсутствие оценки качества архитектуры
Довольно известной методологией является архитектурный фреймворк от “Gartner” . Он разработан для поддержки принятия решений в организации при планировании развития архитектуры предприятия. Его использование предполагает оценку нынешнего состояния компании, определение инвестиций в технологии и процедуры для достижения желаемого результата, а также план управления компанией в переходный момент. Основная цель методологии состоит в том, чтобы использовать «Текущее состояние» и «Будущее состояние» для выявления прогрессивных практик и ресурсов, необходимых для устранения разрыва между архитектурой текущего и будущего состояния. Это можно четко увидеть на рисунке 3.
Рис. 3. Структура разработки архитектуры
Весь процесс перехода от текущего состояния к желаемому определяется в 5 фаз:
− Анализ и организация процессов в компании
− Определение целевой архитектуры
− Документирование текущей архитектуры
− Проведения анализа расхождения между двумя состояниями
Результаты сравнения были получены в ходе опроса 32 представителей организаций, занимающихся архитектурой предприятия. В таблице 1 представлены усредненные оценки по четырехбалльной шкале (от 0 до 3).
Сравнительный анализ архитектурных подходов
Критерий
TOGAF
Матрица Захмана
Gartner
Уровень Бизнес/IT согласованности
Руководство по эталонным моделям
Оценка зрелости процесса
Качество руководства по внедрению
Итого
17
6
13
По итогам анализа можно сделать следующие выводы:
Фреймворк Захмана — 6 баллов. Инновационный способ для конца XX века, который используется до сих пор на предприятиях, в связи с качеством систематизации и простотой внедрения. Сейчас метод устарел, так как он достаточно медленный в плане согласования, а скорость имплементации постоянно повышается.
TOGAF — 17 баллов. Самый популярный на данный момент фреймворк имеет множество достоинств, в числе которых масштабируемость, совместимость и согласованность, на деле является сильно абстрактным. Предприятия внедряют лишь части фреймворка в конкретных ситуациях, не основывая всю архитектуру на данном методе.
Gartner — 13 баллов. Фреймворк, подходящий к процессу развития компании с фокусом на будущий вид компании нежели настоящий, не имеет четких границ следования и подходит для идейного формирования понятного плана по развитию, без сложнейших схем и диаграмм.
Основные термины (генерируются автоматически): TOGAF, ADM, архитектура предприятия, достоинство, недостаток подхода, подход, структура разработки архитектуры.
Читайте также: