- Совокупность сопряжённых производств, имеющих единый технический уровень и развивающихся синхронно
- Прогнозируемое событие, массовое внедрение киберфизических систем в производство
- Масштабные изменения для различных областей жизнедеятельности
- Использование современных технологий для кардинального повышения производительности и ценности предприятий
Мы живем в мире, в котором огромное количеством вещей происходит впервые
- Высокие риски
- Глобальные вызовы
- Большая неопределенность
- Быстрые и масштабные изменения
- Скорость, с которой происходят изменения
- Масштаб преобразований
- Системный характер последствий
Сложность нарастает: Управление развитием / трансформацией в быстроменяющейся среде – это словно стрельба по движущимся мишеням
«Управляющая система не может быть проще управляемой» Принцип кибернетики.
Регулирующие органы, Поставщики, Партнёры -> Компания -> Потребители
УПРАВЛЯТЬ КОМПАНИЕЙ ЗНАЧИТ УПРАВЛЯТЬ НЕ ТОЛЬКО ТЕМ, ЧТО ВНУТРИ, НО И СВЯЗЯМИ СО СРЕДОЙ. Все друг с другом связаны.
В период ближайших 10-15 лет необходимо будет «пересобрать» существующие организации и создать большое количество новых
- Для формализации мыслей
- Для формирования целостных описаний (проверки своих мыслей и их доработки)
- Для коммуникации (формальная модель легко читается другими участниками)
- Для автоматизации (общение между представителями бизнеса и ИТ)
- Для автоматического преобразования (модели для машины)
ИССЛЕДОВАНИЕ РЕАЛЬНОГО ОБЪЕКТА МОЖНО ЗАМЕНИТЬ НА ИССЛЕДОВАНИЕ МОДЕЛИ, А РЕЗУЛЬТАТ ПРИМЕНИТЬ К РЕАЛЬНОМУ ОБЪЕКТУ
Модель – это всегда упрощение реального объекта.
Можно прдеставить как: Модель -> [Пробразование и анализ модели] -> Модель, результаты анализа Исходные обхекты -> [Преобразование реальных объектов] -> Результат
Исходные обхекты -> Модель Модель, результаты анализа -> Результат
- Для кого? - Целевая аудитория
- Что? - Предмет моделирования
- Для чего? - Цель моделирования
Для моделирования необходим единый язык
- Различные представления концепций
- Различные уровни детализации
- Различные уровни масштабирования
- Различная терминология
ПЕРВЫЕ ЯЗЫКИ МОДЕЛИРОВАНИЯ ВОЗНИКЛИ В 80-Х ГОДАХ XX ВЕКА:
- IDEF0 (Входы, Выходы, Механизм, Управления) -> Контроль качества продукции
- EPC (EVENT PROCESS CHAIN)
(Откуда, С чего началось?, Что использовали?) -> Что сделали? Что сделали? -> (Куда?, К чему привело?, Что получили?) Что сделали? - (Кто?, При помощи чего?)
-
UML (UNIFIED MODELING LANGUAGE)
-
BPMN
На момент версии 3.1:
- 59 Элементов
- 7 Групп элементов
- 11 Видов связей
Техническое задание -> Эскизный проект -> Проект -> Анализ -> Рабочая документация -> Производство -> Строительство 4D/5D -> Логистика -> Эксплуатация и ремонт -> (Возможен демонтаж) -> Реконструкция -> Техническое задание
- Бизнес архитектура - Бизнес-стратегия, управление, организационная структура, ключевые бизнес-процессы (Бизнес-процессы, KPI, Цели, Организационные подразделения, Роли, Функции)
- Архитектура данных - Логические и физические сущности данных предприятия и ресурсы управления данными (Данные, Потоки данных)
- Архитектура приложений - Схема развернутого прикладного ПО, его взаимодействие, его связи с ключевыми бизнес-процессами (Информационные системы, Модули информационных систем, Интеграция)
- Технологическая архитектура - Системное ПО и аппаратное обеспечение, которые требуются для поддержки бизнес-сервисов и сервисов приложений (Платформы, Операционные системы)
ОБЪЕКТЫ УПРАВЛЕНИЯ = EA BUILDING BLOCKS
Репозиторий:
- Диаграммы (и объекты внутри представления)
- Карточки (паспорта) объектов
- Реестры
- Матрицы
- Объекты
- Представления
Прдеставления -> (Карточки объектов, Матрицы)
Репозиторий:
- Документы
- Артефакты
- Использование артефакта в документе
Репозиторий связывается с процессами управления архитектурой через выходы и выходы
- Инструменты для «рисования» (например, MS Visio)
- Инструменты для моделирования архитектуры в режиме индивидуальной работы (например, Archi)
- Инструменты для моделирования архитектуры с единым репозиторием объектов и коллективной работой
- Инструменты с портальным решением, расширенной аналитикой и возможностями статического и динамического имитационного анализ
- Инструменты, интегрированные с инструментами управления проектами, управления активами и др.
Архитектура фон Неймана широко известный принцип совместного хранения команд и данных в памяти компьютера.
- Процессор (+ Арифметико-логическое устройство, Устройство управления)
- Устройство ввода/выводы
- Внешнее запоминающее устройство (ВЗУ)
- Оперативное запоминающее устройство (ОЗУ)
- Технологическая архитектура предприятия, 1980-е
- Информационно-технологическая архитектура предприятия, 1990-е
- Элементы бизнес-архитектуры (бизнес-процессы), 2000-е
- Расширенная бизнес-архитектура, 2010-е
- Расширенная информационно-технологическая архитектура, 2017
- Архитектура – это основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития.
- Архитектура – основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития.
- Предприятие – это одна или несколько организаций, разделяющих определенную миссию, цели и задачи для получения выхода (результата) в виде продукции и услуг.
ЭЛЕМЕНТЫ ПРЕДПРИЯТИЯ ИМЕЮТ ОБЩИЕ ЦЕЛИ. АДМИНИСТРАЦИЯ ГОРОДА - ПРЕДПРИЯТИЕ. ГОРОД — НЕТ.
- Стейкхолдеры и их интересы
- Архитектура предприятия как набор компонентов каждого слоя и взаимосвязь между ними
- Артефакты (набор описаний, моделей) в интересах стейкхолдеров
- Совокупность отдельных представлений о предприятии, которые дают описание целого
- Мета-метамодель предприятия
- Необходимость в едином репозитории для хранения всех моделей предприятия
- Метод перехода от текущего к целевому состоянию
ПОТРЕБНОСТЬ В ИНФОРМАЦИИ ОБ ОТДЕЛЬНЫХ ЧАСТЯХ ОРГАНИЗАЦИИ, ИХ ВЗАИМОСВЯЗЯХ И ПРИНЦИПАХ РАЗВИТИЯ (АРТЕФАКТАХ АРХИТЕКТУРЫ)
(1) ОЦЕНИТЬ ТЕКУЩУЮ СИТУАЦИЮ в компании и сформировать (2) ЦЕЛЕВУЮ МОДЕЛЬ бизнеса на всех уровнях с (3) ПЛАНОМ ДЕЙСТВИЙ по достижению этого целевого состояния&
-
Заинтересованная сторона – человек или организация, имеющие право, долю, требование или интерес в отношении системы или ее характеристик, соответствующих их нуждам и ожиданиям (ISO 42010)
-
Интересы – это такие заинтересованности, которые относятся к разработке системы, ее эксплуатации или иным аспектам, критически важным для одной или более заинтересованных сторон. Интересы включают такие системные характеристики, как производительность, надежность, защиту, распределенность и способность к эволюции (ISO 42010)
- Руководство организации
- CEO, CIO, COO
- Архитектор предприятия
- Архитектор процессов, архитектор приложений, архитектор инфраструктуры
- Операционные менеджеры
- Владельцы процессов
- Сотрудники организации
- Акционеры
- Партнеры компании
- Консалтинговые компании
- Заинтересованные стороны – спонсоры изменений
Основные вопросы:
- Действительно ли мы в состоянии поставить новый продукт? Какие части могут быть произведены «внутри» и какие части должны быть созданы «вовне»?
- Каковы условия трансформации? Во сколько она обойдется? Как велика прибыль?
- Каковы последствия от сотрудничества с внешними сторонами? Какие возможности предлагают внешние стороны?
- Каково влияние их решений на различных уровнях, будь то уровень предприятия, уровень подразделения или уровень отдела?
- Каковы последствия значительных изменений во внешнем окружении предприятия, будь то технологические сдвиги, слияния или разделения, аутсорсинг или централизация, внедрение новых форм законодательства?
- Как текущий процессный ландшафт отражает приоритеты бизнеса?
- В какой степени конкретный проект может создавать нежелательные побочные эффекты?
- Заинтересованные стороны, вовлеченные в процесс изменений
Заинтересованные стороны, вовлеченные в трансформацию, нуждаются в понимании процесса и его контроле в зависимости от масштаба их участия.
Основные вопросы:
- На какую часть предприятия окажет влияние трансформация?
- Каковы границы частей предприятия, которые будут трансформироваться?
- Какие существуют отношения и зависимости с другими преобразованиями и проектами?
- Заинтересованные стороны, на которых влияют изменения
В зависимости от типа трансформации могут быть затронуты: сотрудники, менеджеры, клиенты, деловые партнеры
Основные вопросы:
- Как новые условия, достигнутые в результате трансформации, будут отличаться от текущих условий?
- Как я могу подготовиться к новым условиям?
- Чем обоснована необходимость трансформации?
- Когда результаты трансформации станут эффективными?
- Каким образом будут происходить изменения и как можно внести вклад в трансформацию?
Заинтересованные стороны:
- Управляют объектами
- Используют для этого артефакты
При описании архитектуры предприятия все объекты отражаются в специальных документах – артефактах. Артефактами могут быть:
- Реестры
- Матрицы (таблицы соответствия)
- Диаграммы
Еще примеры:
- Схема организационной структуры
- Реестр ИС
- Модель процессов предприятия
- Таблицы ССП
- Информационная модель
Это списки, в которых перечисляются объекты архитектуры предприятия (+ указываются их атрибуты в случае необходимости).
Список ролей, процессов, реестр приложений и т.д.
Это таблицы, в которых отражается отношения между двумя категориями объектов архитектуры предприятия, например: матрица ролей / ИС.
Матрица RACI, Матрица соотношения ролей и процессов, Матрица соотношения действующих лиц и ролей, Матрица соотношения процессов и ИС, Матрица соотношения ролей и ИС.
Это графическое представление объектов архитектуры предприятия и их взаимосвязей с использованием специальных нотаций, например:
- Модели слоев архитектуры
- Мотивационная модель
- Модели отдельных слоев
- Модель перехода
-
Представление (View) – представление системы в целом с точек зрения связанного набора интересов.
-
Ракурс (Viewpoint) – спецификация соглашений для разработки и использования представления.
TOGAF ADM - описывает процесс создания архитектуры предприятия, отвечающей бизнес-требованиям, в конкретной организации
Текущее состояние (AS-IS) -> ADM -> Целевое состояние (TO-BE)
ADM -> (В цикле) -> Описыватся (Цели, Подходы, Шаги, Выходы, Входы) AMD -> Подготовительная фаза
1 "прокрутка" ADM = проект
Способность к применению архитектурного подхода и управление
- Подготовка ADM к работе.
- Оценка работы, проектирование и создание всех условий для успешной работы практики управления архитектурой.
Артефакты на следующий этап: Запрос на архитектурную работу
- Это еще «предпроект».
- Разрабатывается видение архитектуры.
- Принимается решение о том, запускается ли цикл детального проектирования, или проект останавливается.
Артефакты на следующий этап: Концепция архитектура, Решение о начале архитектурных работ
-
B - Бизнес-архитектура - Бизнес-слой
-
С - Архитектура информационных систем - Слои данных и приложений
-
D - Технологическая архитектура - Технологический слой
-
Детальное описание текущей архитектуры и проектирование целевой.
-
Определение разрывов между ними.
-
Определение компонентов для включения в дорожную карту
Артефакты на следующий этап: Компоненты для включения в дорожную карту
-
E - Возможности и решения
-
F - Планирование миграции
-
Планирование перехода, оценка проектов.
-
Формирование дорожной карты.
Артефакты на следующий этап: Дорожная карта
- Управление реализацией, архитектурный надзор.
- Аудит архитектурных решений.
- Управление изменениями, принятие решений о завершении или запуске повторных циклов
- Управление требованиями на всех фазах ADM.
- Ведение реестра требований.
- Начальный этап (Подготовка и A)
- Этап анализа и разработки архитектуры (B, C, D)
- Этап реализации и перехода (E, F, G)
- Этап оценки реализации архитектуры (H)
Также можно посмотреть на это как:
- Определение контекста архитектуры
- Проектирование архитектурных решений
- Планирование преобразований
- Управление архитектурой
Проблема: Отсутствие интегрированного подхода к работе с различными областями деятельности предприятия Решение: Создание языка, на котором описываются различные домены предприятия и отношения между ними.
- Archimate 1 (2009)
- Archimate 2 (2012)
- Archimate 2.1 (2013) — Расширение мотивации, расширение реализации и перехода.
- Archimate 3 (2016) — Стратегическое расширение, физическое расширение.
Создан The Open Group.
- Индивидуальные программы сертификации
- Аккредитация обучающих курсов по ArchiMate
- Сертификация инструментов ArchiMate
- деятельность и развитие предприятия, его окружение
- продукты и услуги для внешних потребителей
- основные бизнес-процессы и сервисы
- бизнес-исполнители и бизнес-роли, выполняющие процессы
- используемая информация (бизнес-объекты)
- Приложения, их функциональность и отношения между ними
- Сервисы приложений, оказывающие поддержку бизнес-слою
- Основные объекты данных, используемые приложениями
- Узлы (включают устройства и системное программное обеспечение)
- Артефакты, которые формируют физическую реализацию компонентов или объектов данных
- Инфраструктурные сервисы (например, обработка, хранение, коммуникация, …), которые нужны для выполнения приложений
Некая сущность, которая способна выполнять определенные действия
Примеры: Бизнес-роль, Компонент приложения, Узел
Некоторый объект, над которым выполняется действие
Примеры: Прдукт, Объект данных, Артефакт
Единица действия, выполняемая одним или несколькими активными структурными элементами.
Поведение может выполняться одним или несколькими структурными элементами.
Примеры: Бизнес-функция, Функция приложений, Информационная функция
- Расширение мотивации позволяет выравнивать архитектуру предприятия в соответствии с контекстом
- Расширение реализации и перехода служит для поддержки последних фаз TOGAF ADM, относящихся к реализации и переходу на целевую архитектуру
- Стратегическое расширение используется для выбора той точки, через которую будет осуществляться влияние на архитектуру предприятия.
- Физическое расширение позволяет расширить технологический слой архитектуры предприятия с целью моделирования объектов физического мира. 143
| Ракурс | Типичные заинтересованные стороны | Цели | Пример диаграммы |
|---|---|---|---|
| Для проектирования | Архитектор, разработчик ПО, разработчик бизнес-процессов | Обзор, проектирование, поддержка проектирования решений, сравнение альтернатив | Диаграмма организационной структуры |
| Для принятия решений | Менеджмент, CEO, CIO | Принятие решений | Мотивационная модель |
| Для информирования | Сотрудники, клиенты и др. | Объяснение, убеждение, получение обязательств | Верхнеуровневая модель архитектуры |
| Детальный уровень | Владельцы процессов, программные инженеры | Проектирование, управление | Диаграмма состояния процесса |
| Уровень связности | Операционные менеджеры | Анализ различий, влияние изменений | Диаграмма обеспечения процессов приложениями |
| Обзорный уровень | Архитектор, CIO, CEO | Управление изменениями | Карта процессов |
| № | Название | Назначение |
|---|---|---|
| 1 | Вводный способ представления | Объяснение сути архитектурной модели не для архитекторов (обычно применяется в начале проектирования, когда не нужна особая детализация). |
| 2 | Организационная структура | Определение внутренней организации компании, отдела, сети компаний или другой организационной единицы. |
| 3 | Совместная деятельность исполнителей | Исследование отношений исполнителей друг с другом и их окружением, а также описание того, как несколько взаимодействующих бизнес-исполнителей и/или компонентов приложений вместе реализуют бизнес-процесс. |
| 4 | Бизнес-функции | Исследование главных бизнес-функций организации и их взаимосвязей с точки зрения потоков (передачи) информации, ценностей или продуктов между ними. |
| 5 | Бизнес-процессы | Исследование главных бизнес-процессов организации с точки зрения потоков (передачи) информации, ценностей или продуктов между ними. |
| 6 | Совместная работа бизнес-процессов | Исследование отношений одного или более бизнес-процессов друг с другом и/или с их окружением. |
| 7 | Продукты | Анализ ценности, которую продукты предлагают потребителям, и анализ построения одного или более продуктов с точки зрения составляющих сервисов (бизнес- или приложений) и связанных с ними контрактов или других соглашений. |
| 8 | Поведение приложения | Описание внутреннего поведения приложения. |
| 9 | Совместная работа приложений | Описание отношений между компонентами приложений с точки зрения информационных потоков между ними или с точки зрения сервисов, которые они предлагают и используют. |
| 10 | Структура приложений | Описание структуры одного или более приложений и связанных с ними данных. |
| 11 | Использование приложений | Описание использования приложений для поддержки одного или более бизнес-процессов и использования приложений другими приложениями. |
| 12 | Инфраструктура | Описание элементов инфраструктуры технического и программного обеспечения, которые поддерживают слой приложений. |
| 13 | Использование инфраструктуры | Описание поддержки приложений программной и технической инфраструктурой. |
| 14 | Внедрение и развертывание | Описание реализации одного или более приложений на инфраструктуре. |
| 15 | Структура информации | Описание структуры информации, используемой в организации или определенным бизнес-процессом или приложением, с точки зрения типов данных или (объектно-ориентированных) структур классов. |
| 16 | Реализация сервисов | Описание реализации одного или более бизнес-сервисов, лежащих в основе процессов и компонентов приложений. |
| 17 | Верхнеуровневая диаграмма (многослойный способ представления) | Обзор на одной диаграмме нескольких слоев и аспектов архитектуры предприятия. |
| 18 | Ландшафтная карта | Назначение ресурсов по бизнес-процессам/функциям (одно измерение) и продуктам, услугам (второе измерение). |
МЕТАМОДЕЛЬ – ЭТО МОДЕЛЬ НА ОСНОВЕ КОТОРОЙ СТРОЯТСЯ ВСЕ ОСТАЛЬНЫЕ МОДЕЛИ.
- Вся деятельность предприятия
- Используется для помощи в приоритезации и трансляции стратегии предприятия Архитектура данных
- Информационная модель с базами и хранилищами данных и потоками информации
- Все приложения и программы компании
- Области применения приложений
- Взаимодействие приложений
- Вычислительная инфраструктура, сетевая инфраструктура, инженерная инфраструктура предприятия
По TOGAF ADM: B.
- Первичность принципов
- Максимизация ценности для предприятия
- Соответствие законам
- Поддержка непрерывности бизнеса
Цели (Смыслы) <-> Деятельность (Функции) <-> Структура (Конструкция). Строится поверх ресурсов.
Выделение трех аспектов бизнес-архитектуры в TOGAF:
- Motivation (к примеру: Driver, Goal, Objective)
- Behavior (к примеру: Function, Process, Service, Capability, Value Stram)
- Organization (к примеру: Org. Unit, Actor, Role)
| Параметр | Функция | Процесс |
|---|---|---|
| Описание | Позволяет группировать однородную деятельность по целевому назначению | Пересобирает деятельность в логике совместного создания результатов (цепочки ценности) |
| В основе | Разделение труда | Взаимодействие для результата |
| Взгляд на деятельность предприятия | Вертикальный взгляд | Горизонтальный взгляд |
| Аналогия | Модуль | Поток |
| Ключевое назначение | Производительность | Оптимизация операций, гибкость |
| Параметр | Сервис | Продукт |
|---|---|---|
| Описание | Представляет деятельность в виде «чёрного ящика» с понятными интерфейсами | Деятельность направлена на предоставление законченного результата, не требующего от клиента дополнительных действий |
| В основе | Логика услуг | Рынок потребления |
| Взгляд на деятельность предприятия | Взгляд на деятельность как на каталог сервисов | Взгляд на деятельность как на каталог продуктов |
| Аналогия | Взаимодействие | Сеть |
| Ключевое назначение | Ценность для клиента, утилитарность | Ценность для клиента, комплексность |
- Бизнес-модель
- Система целей и показателей
- Модели цепочек ценности
- Модели бизнес-процессов
- Модели бизнес-способностей
- Модель организационной структуры
- Модели ресурсов
- Матрица ответственности
- Модели ценностного предложения
- Модели путешествия пользователей
Этапы по TOGAF ADM: C, D.
По TOGAF ADM: C.
Архитектура данных описывает структуру логических и физических активов данных организации и ресурсы управления данными (TOGAF v9)
- Структурированная
- Полуструктурированная
- Неструктурированная
- Нормативно-справочная информация
- Исторические данные
- Транзакционные данные
- Технологические данные
- Мета-данные
- Аналитические данные
- Неструктурированная информация
Воронка:
- Мудрость (Когда?, условия использования)
- Знания (Как?, механизм использования)
- Информация (Структуризация, классификация)
- Данные (Первичные данные)
- Документированное описание всех источников данных
- Модели данных
- Описание существующих и планируемых инф. потоков
- Описание решений по организации хранения данных
- Средства для преобразования и управления данными
- Концептуальный уровень — Высокоуровневое описание информационных потоков в самом общем виде
- Логический уровень — Модели данных описывают в терминах сущностей, атрибутов и отношений
- Физический уровень — Точные ответы на вопросы (пример): Каков набор элементов данных каждой сущности?
Компоненты архитектуры данных в метамодели TOGAF:
- Сущность данных
- Логический компонент данных
- Физический компонент данных
Предоставляет проект для разработки системы индивидуальных приложений, ее развертывания, взаимодействия приложений и их отношений с ключевыми бизнес-процессами организации (TOGAF v9)
По TOGAF ADM: C.
- Поведение, предоставляемое приложением (например, визуализировать данные, осуществить расчет, войти в систему и пр.)
- Инкапсуляция функциональности приложения, которая не зависит от конкретной реализации
- Физический элемент ПО (артефакт), модуль приложения или иной развертываемый модуль, обеспечивающий функциональность
По TOGAF:
- Сервис информационной системы
- Логический компонент приложений
- Физический компонент приложений
Общий план, как потребности бизнес-процессов обеспечиваются набором приложений. Приложения для выполнения функций организации и обмена информацией с контрагентами.
Правила для построения систем, разделения их на функциональные составляющие, создания интерфейсов, шаблоны, руководства и т.п.
Каталог приложений и компонентов, включая связи с бизнес- процессами/способ- ностями; интерфейсы взаимодействия с другими системами
Функциональность ПО, которую необходимо достичь для достижения предприятием желаемого состояния в будущем
Процесс перехода от текущего к будущему портфелю прикладных систем в рамках ИТ-проектов
Legacy Systems (унаследованные системы) – системы, более не соответствующие текущим потребностям бизнеса, но попрежнему эксплуатирующиеся компанией. Оптимальный вариант – ликвидация и миграция данных в новую систему.
| Матрица оценки | Низкая ценность для бизнеса | Высокая ценность для бизнеса |
|---|---|---|
| Превосходное техническое состояние | Перепозиционирование и оценка Недавно введённые в эксплуатацию ИС, которые не достигли поставленных целей |
Обеспечение сопровождения и развития Самые перспективные системы. Критически важны для успеха бизнеса |
| Неудовлетворительное техническое состояние | Вывод из эксплуатации / замена / консолидация Ситуация наличия унаследованных систем |
Обновление инфраструктуры прикладной системы Возможен постепенный переход на более современные решения |
- Название системы
- Описание системы
- Список технологических компонентов
- Область применения с точки зрения бизнеса
- «Владелец» системы со стороны бизнеса
- Оценка пользы прикладной системы (по HealthGrid)
- Ответственный со стороны ИТ-подразделения
- Оценка технического состояния (по HealthGrid)
- Оценка возможностей по обеспечению новых потребностей бизнеса
- Дата последнего обновления информации
- ДИАГРАММА СТРУКТУРЫ ПРИЛОЖЕНИЯ
- ДИАГРАММА ПРЕЦЕДЕНТОВ
- ДИАГРАММА КОМПОНЕНТОВ
- Диаграмма последовательности
- Диаграмма состояний
- Диаграмма кооперации
- ДИАГРАММА ПОДДЕРЖКИ СИСТЕМОЙ ЦЕЛЕВОГО ОСТОЯНИЯ ПРОЦЕССА
Диаграмма компонентов показывает, как ИС разбивается на структурные компоненты как они соотносятся друг с другом.
Основные элементы диаграммы компонентов:
- Компоненты
- Интерфейсы
- Отношения
Бизнес: Функциональная модель, исполнение распоряжений первого лица, личные связи и лояльность сотрудников.
Условия: Изменчивость внешней среды, острый дефицит ресурсов.
Интеграция: Отдельные элементы интеграции «точка-точка».
Приложения: Минимально необходимый набор приложений для операционной деятельности.
Инфраструктура: Нестандартизированная инфраструктура (задача–сервер).
Ожидания от ИТ: Выживание.
Данные: Слабо связанные данные, дублирование, различная интерпретация.
Бизнес: Процессная централизованная модель, сильная информационная взаимозависимость подразделений.
Условия: Внутренняя стабильность, умеренный рост.
Интеграция: Бесшовная интеграция модулей главного приложения и отдельные связи с другими приложениями.
Приложения: Функциональность направлена на автоматизацию бизнес-процессов.
Инфраструктура: Надёжный центр обработки данных.
Ожидания от ИТ: Эффективность.
Данные: Устойчивая и целостная модель данных, отсутствие дублирования.
Бизнес: Многопрофильная деятельность, уникальные функции, согласованное выполнение при создании продукта или услуги.
Условия: Рост, конкуренция, небольшие изменения.
Интеграция: Единые средства гармонизации данных в различных приложениях.
Приложения: Автоматизация всех бизнес-требований оптимальным набором решений.
Инфраструктура: Стандартизация и консолидация вычислительных ресурсов.
Ожидания от ИТ: Инновационность.
Данные: Выделенная система НСИ, полная и целостная модель данных.
Бизнес: Многопрофильная деятельность, высокая степень децентрализации, бизнес-правила и делегирование полномочий.
Условия: Внутренняя и внешняя изменчивость.
Интеграция: «Слабосвязанная» интеграция функций и данных едиными средствами промежуточного слоя.
Приложения: Единое сервисное пространство работы с информацией.
Инфраструктура: Виртуализация вычислительных ресурсов.
Ожидания от ИТ: даптивность.
Данные: Полная модель данных, управляемое дублирование.
Этап по TOGAF ADM: D.
Технологическая архитектура описывает логические программные и аппаратные мощности, которые требуются для поддержки развертывания бизнес-сервисов, сервисов данных и сервисов приложений. ТА включает аппаратную составляющую, сетевое оборудование, коммуникации, процессинг, стандарты и т.п. (TOGAF v9)
Уровень технической архитектуры отвечает за повышение эффективности использования вычислительных ресурсов и их оптимальное распределение (системное ПО, СХД, ЛВС, ЦОД, базовые инфраструктурные сервисы)
| Категория | Элементы |
|---|---|
| Вычислительная инфраструктура | Базовые инфраструктурные сервисы |
| Сервисное и пользовательское оборудование и системы хранения данных | |
| Сервисные площадки и центры обработки данных | |
| Системное ПО | |
| Сетевая инфраструктура | Инфраструктура локальных вычислительных сетей |
| Корпоративные сети передачи данных | |
| Телефония, подключение к сети Интернет | |
| Инженерная инфраструктура | Устройства бесперебойного питания, электропитания, охлаждения, кабельная инфраструктура и др. |
| Прочие технические устройства | Устройства ввода, устройства вывода,… |
- Техническая способность предоставить необходимую ИТ- инфраструктуру для обеспечения выполнения приложений
- Класс технологического продукта
- Конкретный технологический продукт
По TOGAF:
- Сервис платформы
- Логический технологический компонент
- Физический технологический компонент
Домены:
- Базовые — Технологии, используемые практически каждой ИС. Сети, аппаратное обеспечение, ОС, системы хранения, системы управления БД и т.п.
- Прикладные — Более специфические с точки зрения бизнеса. Мобильные терминалы ввода, устройства ввода в супермаркетах, банкоматы и т.п.
Классы:
- Прикладные системы: языки программирования, средства разработки приложений, гео-ИС, средства коллективной разработки
- Сетевые сервисы: локальные сети, глобальные сети, технологии доступа, сетевое аппаратное обеспеч., голосовой доступ
- Вычислительная инфраструктура: ОС и аппаратное обеспечение, системы хранения, топология, средства системного управления
- Программное обеспечение промежуточного слоя (middleware)
- Сервисы безопасности: авторизация, аутентификация, сетевая и физическая безопасность.
- Сервисы данных: системы управления БД, хранилища данных, системы поддержки принятия решений.
Единый каталог содержащий информацию обо всех ИТ-объектах компании и связях между ними, включая:
- Серверы и автоматизированные рабочие места пользователей
- Оборудование и комплектующие
- Программное обеспечения
- ИТ-сервисы, включая облачные
- Сетевое оборудование
- Прочее оборудование
- ДИАГРАММА ТЕХНОЛОГИЧЕСКОГО СЛОЯ
- ДИАГРАММА ТЕХНОЛОГИЧЕСКОГО СЛОЯ (ЦЕЛЕВАЯ)
- ДИАГРАММА РАЗВЕРТЫВАНИЯ
Диаграмма развертывания включает:
- Узлы
- Экземпляры узлов
- Компоненты
- Артефакты
4-х уровневая модель АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ была представлена впервые THE OPEN GROUP,
и с тех пор на её основе разработаны многие другие подходы и стандарты.
Бизнес-цели → Бизнес-архитектура
Бизнес-архитектура стоит на ИТ-архитектуре
ИТ-архитектура из следующих компонентов:
- Архитектура данных
- Архитектура приложений
- Техническая архитектура
1960 — Мейнфреймы
1970 — Мини-компьютеры
1980 — Клиент-сервер
1990 — Веб технологии
2000 — Виртуализация
2007 — Облачные технологии
Большой универсальный производительный отказоустойчивый сервер с большими ресурсами ввода-вывода, большим объемом оперативной и внешней памяти с интенсивной пакетной и транзакционной обработкой.
-
Время наработки на отказ современных мейнфреймов оценивается в 12-15 лет. Надёжность мейнфреймов — это результат их почти 60-летнего совершенствовани
-
Повышенная устойчивость систем. Мейнфреймы могут изолировать и исправлять большинство аппаратных и программных ошибок за счёт использования следующих принципов:
- Дублирование: два резервных процессора, резервные модули памяти, альтернативные пути доступа к периферийным устройствам
- Горячая замена всех элементов вплоть до каналов, плат памяти и центральных процессоров
- Целостность данных. В мейнфреймах используется память с коррекцией ошибок. Ошибки не приводят к разрушению данных в памяти, или данных, ожидающих вывода на внешние устройства. Дисковые подсистемы построенные на основе RAID-массивов с горячей заменой и встроенных средств резервного копирования защищают от потерь данных
- Пропускная способность. Подсистемы ввода-вывода мейнфреймов разработаны так, чтобы работать в среде с высочайшей рабочей нагрузкой на ввод-вывод данных
- Рабочая нагрузка. Рабочая нагрузка мейнфреймов может составлять 80-95 % от их пиковой производительности. Операционная система мейнфрейма будет обрабатывать всё сразу, причём все приложения будут тесно сотрудничать и использовать общие компоненты
АРХИТЕКТУРА ЦЕНТРАЛИЗОВАННЫХ СИСТЕМ (ВЫЧИСЛИТЕЛЬНЫЕ ЦЕНТРЫ)
Множество терминалов -> Хост-ЭВМ
Плюсы:
- Совместное использование дорогих ресурсов ЭВМ и дорогих периферийных устройств
- Облегчённая эксплуатация и обслуживание
- Нет потребности в администрировании рабочих мест
Минусы:
- Пользователи полностью зависят от администратора хост-ЭВМ
1970-е– распространение персональных компьютеров. Происходит кризис рынка мейнфреймов из-за распространения РС- и UNIX-ориентированных машин. Распространение архитектуры «Файл-сервер».
Множество клиентов (прикладная часть, управление БД, сетевой доступ) -> Файл-сервер
Плюсы:
- Многопользовательский режим работы с данными
- Централизованное управление доступом
- Низкая стоимость разработки
- Высокая скорость разработки
- Низкая стоимость обновления
Минусы:
- Проблемы многопользовательской работы с данными
- Низкая производительность
- Ненадёжность системы
- Проблемы с подключением новых клиентов
Множество клиентов (клиентская часть приложения, клиентская часть управления БД, сетевой доступ) -> Сервер БД (серверная часть приложения)
Плюсы:
- Распределение функций вычислительной системы между независимыми компьютерами
- Данные хранятся на защищённом сервере
- Многопользовательская работа
- Гарантия целостности данных
Минусы:
- Неработоспособный сервер может «обрушить» информационную систему
- Сложное администрирование
- Высокая стоимость оборудования
- Бизнес-логика приложений осталась в клиентском ПО
Множество клиентов (пользовательский интерфейс) -> Сервер приложений (бизнес-логика) -> Сервер БД (управление данными)
Плюсы:
- Клиентское ПО не нуждается в администрировании
- Масштабируемость
- Конфигурируемость
- Высокая безопасность и надёжность
- Низкие требования к скорости канала между терминалами и сервером приложений
- Низкие требования к производительности и техническим характеристикам терминалов
Минусы:
- Сложность администрирования и обслуживания
- Более высокая сложность создания приложений
- Высокие требования к производительности серверов приложений и серверов базы данных
- Высокие требования к скорости канала (сети) между сервером базы данных и сервисами приложений
Множество клиентов (браузер) -> Веб-сервер (бизнес-логика, внешние процедуры) -> Сервер БД (управление данными)
Плюсы:
- Независимость от клиентской платформы
- Централизованное хранение данных
- Не требует наличия ПО на компьютере (кроме браузера)
- Простота в обновлении версий веб-приложения (обновляется только один раз на сервере)
- Практически неограниченное число клиентов
- Сохранение данных при смене компьютера
Минусы:
- Низкая защищённость канала передачи информации и доступность для сетевых атак
- Недоступность сервиса при отсутствии работоспособности сервера или каналов связи
- Относительно низкая скорость работы веб-сервиса и каналов передачи данных
Ппредоставление вычислительных ресурсов или их логического объединения, абстрагированное от аппаратной реализации, при этом обеспечивающее логическую изоляцию вычислительных процессов.
Виртуализация скрывает истинный вид объекта для конечного пользователя. Объект становится привычным, удобным и понятным.
-
Виртуализация платформ* — Создание виртуальных машин и эмуляторов платформ, виртуализация операционных систем, виртуализация приложений.
-
Виртуализация ресурсов — Объединение и агрегация ресурсов, распределённые вычисления, кластеризация компьютеров, разделение ресурсов.
Плюсы:
- Снижение затрат на аппаратное обеспечение
- Обеспечение совместимости
- Возможность изолировать вредоносное окружение
- Создание аппаратных конфигураций
- Создание виртуальных образов устройств
- Одновременный запуск виртуальных машин, объединённых в виртуальную сеть
- Обучение работе с ОС
- Повышение мобильности
- Организация «пакетов приложений»
- Высокие показатели управляемости
Минусы:
- Невозможность эмуляции всех устройств, в результате чего не все устройства виртуализируются
- Виртуализация требует дополнительных аппаратных ресурсов
- Некоторые платформы виртуализации требовательны к конкретному аппаратному обеспечению
- Хорошие платформы виртуализации имеют высокую стоимость
блачные вычисления – информационно-технологическая концепция, которая подразумевает удобный сетевой доступ по требованию к общему пулу конфигурируемых вычислительных ресурсов, причём ресурсы могут оперативно предоставляться и освобождаться с минимальными затратами.
Основные характеристики:
- Самообслуживание по требованию
- Универсальный доступ по сети
- Объединение ресурсов
- Эластичность
- Учёт потребителя
Парадигма, используемая для обеспечения сетевого доступа к масштабируемому и эластичному пулу физических или виртуальных ресурсов, с возможностью самостоятельного выделения ресурсов и управления ими по требованию.
Парадигма облачных вычислений состоит из:
- Набора ключевых характеристик
- Функциональных ролей и видов деятельности
- Категорий оказываемого сервиса (Приложения, Платформа, Инфраструктура)
- Видов облачных услуг
- Моделей распространений
- Свойств и возможностей
Облачная инфраструктура, предназначенная для использования только одним клиентом, включающим в себя несколько потребителей (например, отделов компании).
Может находиться в собственности и управляться как самой организацией, так и сторонней.
- Внешнее частное облако — ресурсы облачного провайдера, выделенные для конкретного предприятия.
- Внутреннее частное облако — ресурсы принадлежат самому предприятию и управляются им.
Облачная инфраструктура, открытая для использования различными клиентами.
Является собственностью провайдера услуг и управляется его специалистами.
Провайдер может быть коммерческой, академической или государственной организацией.
- Ресурсы облачного провайдера предоставляются множеству клиентов (предприятий, пользователей).
Облачная инфраструктура, предназначенная для эксклюзивного использования сообществом клиентов, объединённых по одному или нескольким критериям (например, по отрасли или стандартам безопасности).
Может находиться в собственности и управляться как одним из клиентов, так и сторонней организацией.
- Совместное использование ресурсов между организациями, имеющими общие цели.
Облачная модель, представляющая собой комбинацию нескольких моделей (частной, публичной, общественной), объединённых с помощью открытых или проприетарных технологий, обеспечивающих прозрачность обмена данными и приложениями.
- Интеграция частных и публичных облаков для оптимального распределения нагрузки и безопасности.
- тип возможностей приложений: тип возможности облака, в котором потребитель службы облачных вычислений может использовать приложения поставщика службы облачных вычислений;
- тип возможностей инфраструктуры: тип возможностей облака, в котором потребитель службы облачных вычислений может получить и использовать вычислительные ресурсы, ресурсы для хранения данных или сетевые ресурсы;
- тип возможностей платформы: тип возможностей облака, в котором потребитель службы облачных вычислений может устанавливать, управлять и запускать приложения, созданные или приобретенные потребителем, используя один или несколько языков программирования и одну или более сред выполнения, поддерживаемых поставщиком службы облачных вычислений.
Группа служб облачных вычислений, которая обладает некоторым набором общих качеств.
- обмен информацией как услуга (CaaS): категория служб облачных вычислений, в которой потребителю службы облачных вычислений предоставляются следующие возможности: взаимодействие в реальном времени и совместная работа;
- вычисления как услуга (CompaaS): категория служб облачных вычислений, в которой потребителю службы облачных вычислений предоставляются следующие возможности: получение и использование вычислительных ресурсов, необходимых для развертывания и выполнения программного обеспечения;
- инфраструктура как услуга (IaaS): категория служб облачных вычислений, в которой потребителю службы облачных вычислений предоставляется следующий тип возможностей облака: тип возможностей инфраструктуры;
ИТ-сервис — это ИТ-услуга, которую ИТ-подразделение или внешний провайдер предоставляет бизнес-подразделениям предприятия для поддержки их бизнес-процессов.
Компоненты:
- Приложение
- Данные
- Среда выполнения
- Платформенное ПО
- Операционная система
- ПО виртуализации
- Серверы
- Устройства хранения данных
- Сеть передачи данных
Провайдер предоставляет:
- Виртуальные машины
- Дисковое пространство
- Сетевые сервисы
Клиент управляет:
- Приложением
- Данными
- Средой выполнения
- Платформенным ПО
- Операционной системой
Провайдер управляет:
- ПО виртуализации
- Серверами
- Устройствами хранения данных
- Сетью передачи данных
Примеры провайдеров:
- Microsoft Azure
- Amazon Web Services
- Softlayer
- Rackspace
- DataLine
- Ростелеком
- Softline
Провайдер предоставляет:
- Платформу для разработки
- СУБД (систему управления базами данных)
Клиент управляет:
- Приложением
- Данными
Провайдер управляет:
- Средой выполнения
- Платформенным ПО
- Операционной системой
- ПО виртуализации
- Серверами
- Устройствами хранения данных
- Сетью передачи данных
Примеры провайдеров:
- Microsoft Azure
- Amazon Web Services
- Ростелеком
Провайдер предоставляет: Приложения
- SalesForce
- Amazon Web Services
- Манго-Телеком
- Барс Груп
- Мой склад
Вот содержимое таблицы в формате Markdown-списка:
- Низкие капитальные затраты
- Легкость внедрения
- Легкость поддержки
- Горизонтальное масштабирование
- Вертикальное масштабирование
- Отказоустойчивость данных и сервисов
- Задержки сети
- Потери данных
- Отсутствие выделенного персонала
- Ограниченные возможности по конфигурациям
- Ограниченные возможности по кастомизации
- Удобство использования
- Эластичность
- Переход от CAPEX к OPEX
- Гибкое ценообразование (плата за фактическое использование)
- Устойчивость к потере доходов во время кризиса
- Быстрый выход на рынок
- Конфиденциальность, целостность, доступность данных
- Трудность замены поставщика
- Проблемы совместимости
- Трудность трансграничной обработки данных
- Проблемы с гарантированным временем восстановления или политикой возмещения
Кроме традиционных моделей, в последнее время получили распространение более узкоспециализированные модели предоставления облачных услуг:
Данная услуга включает в себя предоставление набора всех необходимых процессов вместе с компонентами ИТ-инфраструктуры (бухгалтерия, почта, CRM-системы, набор приложений и т.д.) для средних и крупных компаний
При использовании данной услуги пользователь получает заранее настроенное и готовое к работе виртуальное рабочее место
Особенностью данной услуги является передача провайдеру управления всеми системами обеспечения информационной безопасности компании (межсетевой экран, антивирусная защита, системы обнаружения и предотвращения вторжений, и т.д.)
Провайдер предоставляет пользователю услугу по резервированию наиболее важных сервисов или данных
Данная услуга предоставляет возможность экстренного восстановления сервисов пользователя после возможных аварий и катастроф
-
Ориентация на клиента
-
Лидерство
-
Вовлеченность персонала
-
Процессный подход
-
Улучшения
-
Принятие решений на основе фактов
-
Определение ценности продукта
-
Определение потока создания ценностей
-
Обеспечение непрерывного течения потока
-
создания ценности продукта
-
Вытягивание продукта
-
Декомпозиция
-
Инкапсуляция
-
Открытость
-
Унификация
- Миссия и планы предприятия
- Стратегические инициативы предприятия
- Внешние ограничения
- Используемые системы и технологии
- Актуальные отраслевые тренды
Архитектурный принцип – это утверждение о некотором намерении, которому должна соответствовать архитектура предприятия (TOGAF 9.2)
Принципы предприятия (Корпоративное управление) включает Архитектурные принципы (управление архитектурой).
Принципы предприятия — Руководство и ЛПР. Архитектурные принципы — Архитекторы.
- Принципы бизнес-архитектуры
- Принципы архитектуры данных
- Принципы архитектуры приложений
- Принципы технологической архитектуры
Требования -> Принятие решения -> Архитектура
Принипы -> Принятие решения
- Название (к примеру: Самообслуживание)
- Утверждение (к примеру: Утверждение Клиенты должны иметь возможность обслужить себя самостоятельно)
- Обоснование (к примеру: повысит удовлетворенность клиентов, сократит административные расходы)
- Описание
- Понятность
- Устойчивость
- Полнота
- Непротиворечивость
- 1: Первичность принципов
- 2: Максимизация ценности для предприятия
- 5: Совместное использование приложений
- 6: Сервис-ориентированная архитектура
- 11: Данные являются общими
- 16: Технологическая независимость
Для формирования архитектуры предприятия могут использоваться строительные блоки (building blocks). Строительные блоки абстрактны и могут использоваться в разных областях, разными компаниями.
Главная характеристика строительного блока – это возможность повторного использования. Описанный один раз строительный блок применяется многократно. Всю архитектуру предприятия можно представить как набор строительных блоков
Вот структура изображения в формате Markdown-списка:
-
Строительный блок
- Строительный блок архитектуры Используется для общего описания и разработки архитектуры предприятия.
- Строительный блок решения Используется для описания и разработки конкретного архитектурного решения (чаще всего в терминах конкретных продуктов).
Описанная один раз структура организации может применяться в дочерних компаниях, в филиалах, … Целая модель может быть строительным блоком.
Отдельный объект архитектуры предприятия тоже может рассматриваться как строительный блок
Готовые строительные блоки часто можно найти в референтных моделях
Классификатор (справочник) процессов (Process Classification Framework, PCF) APQC (American Productivity and Quality Center — Американский центр производительности и качества) выступает в качестве обобщённой модели процессов для предприятий независимо от сферы их деятельности. Позволяет организациям увидеть свои процессы с межотраслевой точки зрения.
-
APQC — открытый стандарт для содействия улучшению посредством процессов управления и бенчмаркинга, независимо от отрасли, размера или географии организации.
-
PCF выделяет 12 категорий процессов, которые подразделяются на группы процессов, внутри которых уже выделяется более 1000 процессов и операций.
1.0 Разрабатывать видение и стратегию 2.0 Разрабатывать продукты / услуги 3.0 Продавать продукты / услуги 4.0 Производить и поставлять продукты / услуги 5.0 Оказывать сервисную поддержку
6.0 Управлять человеческими ресурсами 7.0 Управлять информационными технологиями 8.0 Управлять финансовыми ресурсами 9.0 Управлять основными активами 10.0 Управлять экологическими воздействиями и безопасностью 11.0 Управлять внешними связями 12.0 Развивать бизнес-способности и управлять ими
-
2.1. Разрабатывать концепцию и план продукта/услуги:
- 2.1.1. Перевести потребности и желания потребителя в требования к продукту/услуге
- 2.1.2. Планировать и детализировать цели по качеству
- 2.1.3. Планировать и детализировать цели по стоимости
- 2.1.4. Разрабатывать жизненный цикл продукта и определять цели по времени
- 2.1.5. Разрабатывать и интегрировать лидирующие технологии в концепцию продукта/услуги
-
2.2. Разрабатывать, создавать и оценивать прототипы продуктов и услуг*
-
2.3. Совершенствовать существующие продукты/услуги*
-
2.4. Тестировать эффективность новых или изменённых продуктов или услуг*
-
2.5. Управлять процессом разработки продукта/услуги**
Референтная модель – это эталонная (рекомендуемая) схема организации бизнеса, разработанная для предприятия конкретной отрасли на основе реального опыта внедрения, включающая проверенные на практике способности и методы организации управления и предназначенная для использования на других предприятиях.
SAP for Retail – интегрированное решение, которое охватывает все процессы компании, включая планирование потребностей, формирование заказа поставщику, отслеживание цепочки поставок, приемка/отпуск товара, распределение товара по магазинам, последующие расчеты с поставщиком и т.п.
Измерения бизнес-компонента:
- Бизнес-цель
- Активности
- Ресурсы
- Управление
- Бизнес-сервисы
SCOR применяется для описания взаимодействия между участниками цепи поставок и содержит библиотеку типовых бизнес-функций и бизнес- процессов по управлению цепями поставок
SCOR основан на:
- Стандартном описании процессов управления цепями поставок
- Стандартизации взаимоотношений между бизнес-процессами
- Стандартных метриках
- Практике управления цепями поставок
SROR охватывает сферы:
- Управления отношениями с потребителем товаров
- Управления материальными и нематериальными потоками, идущими от поставщиков до потребителей
- Управления отношениями с поставщиками (от формирования заявки до выполнения заказа на поставку) Вот структура изображения в формате Markdown-списка:
- Уровень 1 — Возможности
- Пример: Supply-Chain Source
- Направления бизнеса
- Оценка возможностей
- Язык модели
-
Уровень 2 — Конфигурация
- Пример: S1 Source Stocked Product
- Комплексные процессы
- Оценка способностей
- Язык модели
-
Уровень 3 — Процессы
- Пример: S1.2 Receive Product
- Наименования задач
- Связи, метрики, задачи и практики
- Язык модели
-
Уровень 4 — Технологический процесс
- Алгоритмы
- Детализация работ
- Специальный язык компании или отрасли
-
Уровень 5 — Операции
- Транзакции звеньев (например, EDI, XML)
- Детали автоматизации
- Специальный технологический язык
SCOR-уровни (1–3) — это стандарты SCOR, а уровни 4–5 — стандарты компании или отрасли.
Вот структура изображения в формате Markdown-списка:
- Конкурентоспособность ЦП (цепи поставок)
- Стратегические карты ЦП
- Измерители эффективности
- Анализ разрывов стратегических показателей
- План проекта реинжиниринга
Сравнительный бенчмаркинг
- Географическая карта «как есть»
- Диаграмма потоков «как есть»
- Географическая карта «как должно быть»
- Диаграмма потоков «как должно быть»
- Карты процессов «как есть»
- Анализ разрывов
- Карты процессов «как должно быть»
Процессный бенчмаркинг
- Организация (изменение системы управления)
- Технологии
- Процессы
- Персонал
В 2000 г. все инициативы TM Forum объединились в рамках проекта New Generation Operation Systems and Software (Следующее поколение систем и программного обеспечения для управления операционной деятельностью телекоммуникационной компании), или сокращенно — NGOSS
- расширенная карта бизнес-процессов еТОМ, описывающая структуру бизнес-процессов телекоммуникационных компаний
- информационная модель SID, определяющая подход к описанию и использованию данных, задействованных в бизнес-процессах компании связи
- карта приложений ТАМ, описывающая типовую структуру компонентов информационной среды компании связи
- архитектура интеграции TNA & CID (Technology Neutral Architecture and Contract Interface Definitions), определяющая принципы взаимодействия и интеграции приложений, данных и бизнес-процессов в распределенной среде NGOSS
- система контроля соответствия принципам NGOSS (NGOSS Compliance), позволяющая проверить компоненты NGOSS-решения на соответствие принципам концепции
В 2010 году, на смену NGOSS пришла концепция Frameworx.
eTOM — это многоуровневая модель бизнес-процессов управления производством, базой которой является расширенная карта процессов деятельности телекоммуникационной компании.
- Акцент на связи между бизнес-процессами
- Учтено взаимодействие с внешней средой
- Универсальность и открытость
- Возможность интеграции с другими моделями (ITIL и др.)
- Регулярное развитие модели
- Экономию времени и затрат на решение типичных задач анализа и оптимизации бизнес-процессов (БП)
- Выявление и устранение дублирующихся БП
- Основу для управления ИТ-приложениями
- Возможность создания моделей потоков БП
- Возможность дальнейшего применения знаний в области БП