2.3. Методология архитектуры предприятия

1.

Методология «архитектуры предприятия»
Понятие архитектуры предприятия

2.

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

3.

Архитектура предприятия
Архитектура предприятия — это наиболее общее и всестороннее представление предприятия, как
хозяйствующего субъекта, имеющего краткосрочные и долгосрочные цели ведения своей основной
деятельности, определенные миссией на региональном и мировом рынке, и стратегией развития,
внешние и внутренние ресурсы, необходимые для выполнения миссии и достижения поставленных
целей, а также сложившиеся правила ведения основной деятельности (бизнеса).
В самом общем виде под архитектурой предприятия (ЕА - Enterprise Architecture) понимается
всестороннее и исчерпывающее описание (модель) всех его ключевых элементов и межэлементных
отношений.

4.

Архитектура предприятия
Согласно ISO 15704 (“Industrial Automation Systems – Requirements for Enterprise-Reference
Architectures and Methodologies. 1999”) архитектура предприятия должна включать роль людей,
описание процессов (функции и поведение), и представление всех вспомогательных технологий на
протяжении всего жизненного цикла предприятия. Архитектура является стратегической
информационной основой, определяющей:
• структуру бизнеса;
• информацию, необходимую для ведения бизнеса;
• технологии, применяемые для поддержания бизнес-операций;
• процессы преобразования, развития и перехода, необходимые для реализации новых технологий в
ответ на изменение/появление новых бизнес-потребностей.
Архитектура предприятия традиционно представляется в виде следующих слоев:
• корпоративные миссия и стратегия, стратегические цели и задачи;
• бизнес-архитектура;
• системная архитектура (ИТ - архитектура).

5.

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

6.

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

7.

Архитектура предприятия
Архитектура платформ включает в себя:
• аппаратные средства вычислительной техники - серверы, рабочие станции, накопители и другое
компьютерное оборудование;
• операционные и управляющие системы, утилиты и офисные программные системы;
• аварийные планы по обеспечению бесперебойной работы аппаратуры (главным образом - серверов)
и баз данных в условиях чрезвычайных обстоятельств.
Основными этапами процесса построения архитектуры предприятия являются следующие:
• осознание необходимости построения архитектуры;
• формирование рабочей группы;
• выбор среды моделирования, средств моделирования и репозитория;
• наполнение среды фактическим материалом (формирование архитектуры);
• использование;
• расширение и сопровождение.
В состав рабочей группы должен входить выделенный относительно новый ролевой участник –
архитектор, фактически являющийся постановщиком задач на архитектурные изменения на основании
как изменившихся внешних условий, так и понимания недостатков существующего положения дел.

8.

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

9.

Интеграция бизнес-процессов и ИТ-решений
Интеграцию применяют для целого списка процессов:
• Учёт и финансы. Интеграция системы учёта и бухгалтерской программы позволит автоматизировать
процесс финансовой отчётности, упростить запись транзакций, составление баланса и расчёт
налогов.
• Управление взаимоотношениями с потребителями и заказчиками, то есть CRM-система.
Объединение этой системы с иными инструментами в компании – электронная почта, календари и
техподдержка – поможе в удержании клиентов, автоматизации продаж.
• Менеджмент проектов. Интеграция управления проектами с коммуникационными инструментами –
чаты и видеоконференции – может облегчить работу и общение в коллективе.
• Поставки и логистика. Управление складом и планирование поставок стоит объединить с системой
отслеживания грузов и доставок. Это увеличит эффективность процессов, уменьшит время доставки
товаров и поможет избежать вручную отслеживать запасы и заказы.
• Человеческие ресурсы. Интеграция системы управления персоналом с системой оплаты, учётом
рабочего времени и системой подбора персонала поможет автоматизировать процессы найма,
оплаты и учёта рабочего времени.
В зависимости от специфики бизнеса можно найти и другие процессы, где интеграция может создать
значительные преимущества.

10.

Архитектура информационной системы
Методологии и фреймворки

11.

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

12.

TOGAF: принципы и этапы разработки архитектуры
TOGAF: Компаньон архитектора
TOGAF, аббревиатура от The Open Group
Architecture Framework, представляет
собой процесс, основанный на
инициативах, предназначенный для того,
чтобы направлять организации в
разработке и согласовании их
архитектурных целей с бизнес-задачами.
Он обеспечивает структурированный
подход к разработке и архитектуре
корпоративного программного
обеспечения, что делает его ценным
инструментом для организаций,
стремящихся создавать надежные и
эффективные программные системы.

13.

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

14.

TOGAF: принципы и этапы разработки архитектуры
Модель разработки архитектуры (ADM) служит ядром TOGAF.
Он описывает процесс разработки архитектуры, проводя архитекторов через ряд фаз, каждая
из которых взаимодействует с фазой управления требованиями в центре. Вот девять ключевых
фаз ADM:
•Предварительная фаза: Эта начальная фаза включает подготовку, инициализацию и
настройку архитектурного процесса, закладывая основу для дальнейшей работы.
•Видение архитектуры: Эта фаза включает определение области действия, выявление
заинтересованных сторон, получение их поддержки и формирование четкого видения
архитектуры.
•Бизнес-архитектура: Здесь основное внимание уделяется идентификации изменений в
рабочем процессе, организационной структуре и стратегиях для поддержки видения
архитектуры. Например, это может включать внедрение контейнеризации для модернизации
приложений или изменение структуры команд.
•Архитектура информационной системы: Эта фаза фокусируется на данных, охватывая
изменения в логических и физических моделях данных для поддержки видения архитектуры.

15.

TOGAF: принципы и этапы разработки архитектуры
•Технологическая архитектура: Фаза технологической архитектуры определяет изменения,
связанные с аппаратным обеспечением, программным обеспечением, инфраструктурой,
платформами и многим другим, которые поддерживают видение архитектуры. Например,
переход с традиционных виртуальных машин на контейнеризацию с Docker.
•Возможности и решения: На этой фазе создается дорожная карта, демонстрирующая ряд
итераций от текущего состояния к целевому видению архитектуры. Каждая итерация может
включать один или несколько связанных проектов.
•Планирование миграции: Оценка деловой ценности каждой выполненной итерации и
расстановка приоритетов проектов на основе зависимостей, затрат, выгод и рисков.
•Управление внедрением: Цель этой фазы – обеспечить соответствие между реализацией и
видением архитектуры, путем проверки выполнения критериев приемки.
•Управление внедрением: Эта фаза направлена на обеспечение соответствия между
реализацией проекта и видением архитектуры. На этом этапе проверяется выполнение всех
критериев приемки.
•Управление изменениями архитектуры: Эта заключительная фаза фокусируется на
выявлении и управлении рисками. Она подразумевает управление и оценку изменений,
происходящих во время внедрения архитектурного видения.

16.

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

17.

Модель Захмана
Модель Захмана – одна из первых попыток создать систематизированный подход к построению
архитектуры предприятия, на котором информационные технологии являются лишь набором
отдельных разрозненных элементов. В основе методики заложена таблица для моделирования
архитектуры, получившая известность под названием ZachmanFramework.
В модели Захмана архитектура предприятия рассматривается, как «набор описательных
представлений (моделей), которые применимы для описания Предприятия в соответствии с
требованиями управленческого персонала (качество) и которые могут развиваться в течение
определенного периода (динамичность)».
Архитектура в модели Захмана рассматривается с точки зрения различных заинтересованных
лиц, где «архитектурное представление» - это ячейка таблицы, соответствующие пересечению
определенного столбца и строки. Таким образом, мы можем говорить не об одной
определенной архитектуре предприятия, а о нескольких различных представлениях
архитектуры, зависящих от предъявляемых требований.
Методика создает контекст описания различных архитектурных представлений в соответствии с
требованиями заказчика в виде нескольких различных аспектов.

18.

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

19.

Модель Захмана
Таблица включает в себя шесть строк и шесть столбцов. Шестая строка, отображенная в
таблице, описывает существующую структуру организации, то есть является элементом
документирования текущего состояния (текущая архитектура). На пересечении строк и
столбцов расположена модель, детализирующая архитектурное представление на
определенном уровне абстракции.

20.

Модель Захмана
Столбцы таблицы описывают основные аспекты, отражающие все сферы деятельности
организации, отвечающие на простые вопросы: что, как, где, кто, когда, почему.
Данные (DATA) - что?
Уровень описывает любые формы предоставления информации необходимой для
эффективного функционирования предприятия.
Функции (FUNCTION) – как?
Описывает набор бизнес-процессов, обеспечивающих функционирование предприятия.
Место (NETWORK) – где?
Определяет географическое расположение объектов и сетевую организацию предприятия.
Люди (PEOPLE) - кто?
Определяет участников процесса, описывает распределение ответственности и функции
работников.
Время (TIME) - когда?
Описывает временные характеристики. Время может быть абсолютным или относительным,
отражать взаимосвязь процессов.
Мотивация (MOTIVATION) - почему?
Определяет направление развития бизнес-цели и стратегии.

21.

Модель Захмана
Строки в таблице соответствуют уровню абстракции, в соответствии с которым описывается
предприятие.
Сфера действия (SCOPE)– это самый верхний (глобальный) уровень абстракции,
отображающий основные элементы планирования бизнеса. Документы, составленные на этом
уровне, не являются техническими и оперируют такими понятиями, как продукты, услуги,
клиенты.
• Данные: определяется список важных понятий и объектов.
• Функции: список основных бизнес-процессов.
• Место: территориальное расположение производственных подразделений.
• Люди: список ключевых бизнес подразделений организации.
• Время: важнейшие события, календарный план.
• Мотивация: бизнес-цели и стратегии предприятия.

22.

Модель Захмана
Модель бизнеса (BUSINESS MODEL) – уровень описывает концептуальную модель и
предназначен для описания предприятия в терминах бизнеса. Уровень описывает структуру
организации, ключевые и вспомогательные бизнес-процессов. Модель бизнеса рассматривает
архитектуру с точки зрения менеджера, владельца процесса.
• Данные: концептуальная модель данных.
• Функции: модель ключевых и вспомогательных бизнес-процессов.
• Место: логистика процессов.
• Люди: модель потока работ (workflow).
• Время: мастер – план реализации.
• Мотивация: бизнес-план.

23.

Модель Захмана
Системная модель (SYSTEM MODEL)– описывает логическую модель построения
предприятия и соответствует точке зрения системного архитектора, проецирует взгляд бизнеса
(заказчика) на информационные системы. На этом уровне бизнес-процессы рассматриваются с
точки зрения информационных систем, дается детализированное описание данных и правила
их преобразования.
• Данные: логические модели данных.
• Функции: архитектура приложений.
• Место: модель распределенной архитектуры.
• Люди: архитектура интерфейса пользователя.
• Время: структура процессов.
• Мотивация: роли и модели бизнес-правил.

24.

Модель Захмана
Технологическая модель (TECHNOLOGY MODEL)– обеспечивает привязку архитектуры к
программно аппаратным средствам с точки зрения проектировщика. На этом уровне
рассматривается физическая модель и описывается взгляд проектировщика на выбор
технологий реализации.
• Данные: физическая модель данных.
• Функции: архитектура информационных систем.
• Место: технологическая архитектура.
• Люди: архитектура представления.
• Время: структура управления.
• Мотивация: описание правил бизнес - логики.

25.

Модель Захмана
Детали реализации (DETAILED REPRESENTATIONS)– определяет набор работ и конкретные
программно-аппаратные средства, обеспечивающие функционирование предприятия. Это
уровень разработчика, на котором происходит распределение работ между внутренними
подразделениями и субподрядчиками.
• Данные: спецификации форматов данных.
• Функции: код программных компонентов.
• Место: спецификации архитектуры сети.
• Люди: определение ролей и прав доступа.
• Время: определение сроков.
• Мотивация: реализация бизнес - логики.

26.

Модель Захмана
Работающая организация (FUNCTIONING ENTERPRISE) - описывает реальную структуру
предприятия и позволяет соотнести с желаемое состояние с вынесенными изменениями. Этот
уровень текущей архитектуры предприятия, то есть набор документов, описывающих их
текущее состояние.
С точки зрения Захмана «путь к эффективным информационным системам требует
систематических подходов в проектировании». По мере необходимости, производится
последовательная детализация каждого элемента предприятия и, таким образом, получается
сложная связанная структура обеспечивающая целостное восприятие всей организации.
Основными достоинствами модели Захмана является:
• Простота понимания.
• Целостность в отношении предприятия.
• Возможность применения для планирования.
• Использование нетехнических понятий.
• Независимость от различных инструментов.
Методика Захмана, является одной из первых появившихся методик. Она не потеряла свою
актуальность в настоящее время и постоянно используется, как основа для методологий
различных аналитических и коммерческих компаний.

27.

Архитектура информационной системы
Практическое применение методологий

28.

Практическое применение методологий
1. Coca-Cola (США) — TOGAF
Цель: Оптимизация ИТ-инфраструктуры для поддержки глобального роста и улучшения
взаимодействия между отделами.
Описание кейса: Coca-Cola столкнулась с проблемой управления разнообразными и
изолированными ИТ-системами в различных регионах. Применение TOGAF помогло компании
стандартизировать архитектуру ИТ-систем, создав общую основу для интеграции и управления
данными. Это позволило:
• Обеспечить унифицированный доступ к данным в реальном времени, что упростило
принятие решений.
• Снизить избыточность и расходы на ИТ за счет удаления дублирующихся систем.
• Увеличить адаптивность и гибкость системы, благодаря чему компания стала быстрее
реагировать на изменения на рынке.
Результат: После внедрения TOGAF Coca-Cola смогла снизить операционные расходы на ИТ,
повысить безопасность данных и стандартизировать процессы, что позволило им более гибко
адаптироваться к изменениям в бизнесе.

29.

Практическое применение методологий
2. British Petroleum (BP) — Zachman Framework
Цель: Управление комплексностью ИТ-систем, обеспечение их устойчивости и улучшение
интеграции данных.
Описание кейса: British Petroleum выбрала Zachman Framework для систематизации
архитектуры своей ИТ-инфраструктуры и оптимизации управления данными. Структурный
подход Zachman помог BP:
• Сформировать комплексную модель всей ИТ-инфраструктуры, включая оборудование,
программное обеспечение и процессы.
• Обеспечить единое хранилище для всех данных, что уменьшило количество ошибок и
дублирование данных.
• Улучшить интеграцию и взаимодействие между различными ИТ-компонентами, что
упростило обмен информацией между подразделениями.
Результат: BP улучшила совместимость и взаимосвязь своих систем, снизила расходы на
поддержку и оптимизировала процесс принятия решений на основе более точных данных.

30.

Практическое применение методологий
3. Сбербанк (Россия) — Методология TOGAF
Цель: Разработка стратегии цифровизации и создание гибкой архитектуры для внедрения
новых ИТ-услуг.
Описание кейса: Сбербанк, один из крупнейших банков России, стремился трансформировать
свой бизнес, ориентируясь на цифровизацию. TOGAF помог:
• Построить стандартизированную архитектуру, которая поддерживала бы быструю
интеграцию новых сервисов.
• Упростить развертывание ИТ-продуктов за счет создания модульной архитектуры.
• Снизить расходы на разработку и обслуживание за счет переиспользования компонент.
Результат: Внедрение TOGAF позволило Сбербанку быстрее запускать новые продукты и
услуги, такие как мобильные приложения и онлайн-банкинг, что улучшило взаимодействие с
клиентами и увеличило конкурентоспособность.

31.

Практическое применение методологий
4. Газпром нефть (Россия) — Использование методологии ArchiMate
Цель: Оптимизация архитектуры ИТ-инфраструктуры для поддержки стратегических целей и
повышения прозрачности процессов.
Описание кейса: Газпром нефть, чтобы управлять сложной ИТ-инфраструктурой, внедрила
методологию ArchiMate. ArchiMate позволила компании:
• Создать карту всех ИТ-компонентов и их взаимодействий, что упростило выявление узких
мест и избыточностей.
• Оценить влияние изменений в инфраструктуре на весь ИТ-ландшафт, что помогло избежать
потенциальных сбоев.
• Увеличить прозрачность процессов и облегчить взаимодействие между отделами.
Результат: Газпром нефть повысила производительность и безопасность, улучшила адаптацию
системы к изменениям и снизила затраты на техническое обслуживание.

32.

Практическое применение методологий
5. General Electric (GE) — Применение TOGAF и Six Sigma
Методология: TOGAF совместно с Six Sigma
Цель: Снижение операционных затрат и повышение эффективности ИТ-процессов.
Описание кейса: General Electric использовала TOGAF для стандартизации архитектуры своих
ИТ-систем, а Six Sigma — для оптимизации процессов. Этот подход позволил GE:
• Повысить прозрачность архитектуры, что облегчило управление и внедрение изменений.
• Оптимизировать производственные процессы и сократить издержки.
• Обеспечить быстрое масштабирование решений по мере роста компании.
Результат: GE смогла сократить издержки, повысить производительность и улучшить процессы
разработки и внедрения новых решений в своих подразделениях.