Презентация на тему Архитектура предприятия

представлений об архитектуре предприятия
Методики описания АП

поставщиков типа:
серверная ОС MS Windows 2007,
СУБД MS

SQL,
серверы на платформе Intel
телекоммуникационное оборудование Cisco.

комплекса:
ЧМК не только имеет цели и поведение, но

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

АП
стандарты CMM Capability Maturity Model.
TQM Total Quality Management
CPI Continuous

Process Improvement

методика BSP Business Systems Planning

Переход от рынка продавца к рынку покупателя

Принципы Деминга

Маркетинговое управление, процессый подход

согласование ИТ-систем с реальными потребностями бизнеса

подход к формулировке архитектуры ИТ должен основываться на анализе

общекорпоративных процессов и переоценке своих бизнес-процессов и поддерживающих их приложений.


Современные подходы к формулировке понятия архитектуры являются попытками предоставить язык, понятный и полезный одновременно для бизнес-руководства и для специалистов в области ИТ.

упорядоченная для достижения одной или нескольких поставленных целей». (ISO/IEC

15288:2002)
Определение распространяется на самые разные по характеру и масштабу системы - от локального устройства (например, мобильного телефона) до целой отрасли (включая ее работников).
Другие стандарты дополнительно указывают, что в составе систем рассматриваются машины, люди, программное обеспечение.
Эберхард Речтин (основатель понятия «системное мышление»): система, когда "целое составляет нечто большее, чем механическая сумма составляющих, т.е. система обладает свойствами, которые отсутствуют у составляющих ее элементов"

иметь в виду формальное объединение, не обязательно связанное с

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

инструментов организационных изменений предприятия в целом с использованием ИТ.

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

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

интерпретации и реализации целей организации через адекватные ИТ-инфраструктуру и системы.

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

и правила,
основные бизнес-процессы, включая взаимосвязи и зависимости между

ними.

Бизнес-архитектура описывает на уровне предприятия в целом то, как реализуются основные функции организации, включая организационные и функциональные структуры, роли и ответственности

неструктурированной информацией, требующейся для бизнеса, включая:
расположение,
время,
типы

файлов и баз данных;
других информационных хранилищ.

для реализации логики бизнес-процессов организации.

перечисленных выше областей архитектуры.

Логические модели ИТ-сервисов построены в

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

Физические модели определяются:
технологиями,
аппаратными платформами
программными платформами,

выбранными для реализации ИТ-сервисов.

и интерфейсов, связей и накладываемых ограничений, а также архитектуры

этих внутренних компонент".
Такое рекурсивное определение удобно тем, что является достаточно общим, применимым практически к любой системе, а не обязательно только к системе, использующей информационные технологии, и при этом позволяет ограничить степень детализации на нужном уровне.
Упоминание внутренних компонент используется для отражения того факта, что "хорошая" архитектура позволяет обеспечить повторное использование или модернизацию/замену таких внутренних компонент без изменения внешней охватывающей системы. Итеративное, иерархическое построение архитектуры позволяет решить и еще одну важную задачу – облегчить ее восприятие человеком.
Оптимальным числом элементов на отдельном уровне любой схемы абстракции или в каком-либо списке является 7 плюс или минус 2 объекта. Именно поэтому большинство подходов к описанию архитектуры включает в себя ее разбиение на предметные области (или представления), общее количество которых как раз и находится в этом диапазоне.
Примерами таких предметных областей являются архитектура прикладных систем, архитектура данных, технологическая архитектура и т.д. Старый, как мир, принцип "разделяй и властвуй" как нельзя лучше подходит для того, чтобы справляться с объективной сложностью корпоративных информационных систем. При этом такое разбиение позволяет рабочим группам, специализирующимся на различных предметных областях, работать параллельно, что делает проблему осознаваемой с интеллектуальной точки зрения.

правильного стандарта на определение архитектуры ИТ, поэтому общие соглашения

внутри организации важнее теоретической точности".

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

для создания системы, такой как здание или информационная система,

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

стандарты процессов, технологий и интерфейсов в целях улучшения возможностей

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

задуманной или развиваемой системы на уровне ее компонентов, детализированное

в достаточной мере для руководства ее воплощением, а также принципы и руководящие материалы, определяющие руководство конструированием и развитием системы во времени;
2) структура существующей системы как совокупность ее компонентов и их взаимосвязей.

в рамках представления об "архитектуре" существуют, и как они

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

и ИТ) в рамках всей организации в целом (включая

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

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

(бизнес и ИТ) на уровне проектов и программ (совокупностей

проектов), но в контексте всей организации в целом, т.е. не в изолированном рассмотрении индивидуальных систем.
Архитектура уровня отдельных проектов детализирует, соответствует и существует в рамках архитектуры предприятия.

разрабатываются с целью обеспечения требуемой функциональности.

Некоторые элементы этой

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

реальности

сложным, глубоким и неявным понятием. Только часть этого общего

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

1471

определенным образом описана с различных точек зрения в зависимости

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

(архитектура систем – System Architecture) и программная архитектура (архитектура

программного обеспечения – Software Architecture).
Уровни архитектур
концептуальная архитектура определяет компоненты системы и их назначения, обычно в неформальном виде. Это представление часто используется для обсуждения с нетехническими специалистами, такими как руководство, бизнес-менеджеры и конечные пользователи функциональных характеристик системы (что система должна уметь делать, в основном, с точки зрения конечного пользователя);
логическая архитектура выделяет, прежде всего, вопросы взаимодействия компонент системы, интерфейсы и используемые протоколы. Это представление позволяет эффективно организовать параллельную разработку;
физическая реализация, которая описывает привязку к конкретным узлам размещения, типам оборудования, характеристикам окружения, таким как, например, используемые операционные системы и т.п.

архитектуры были сосредоточены на формировании технологических стандартов и принципов,

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

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

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

состоит в совместном использовании общих данных, исключении дублирования бизнес-функций,

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

архитектура
Архитектура предприятия (Enterprise Architecture) объединяет корпоративную ИТ - архитектуру

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

целостный подход, взгляд на организацию в целом

план реализации миссии организации через оптимальное выполнение своих ключевых

бизнес-процессов в условиях формирования эффективной инфраструктуры информационных технологий

сформулировано в стандарте ISO 15704.
Идея состояла в том,

чтобы разработать максимально общую, так называемую эталонную (reference) модель архитектуры предприятия, которая охватывала бы дополнительно процесс развития предприятия во времени как проект, а также учитывала бы роль человеческого фактора.
Архитектуры отдельных подсистем, в том числе ИТ-системы предприятия, могут быть тогда разработаны как специфические уточнения такой общей модели. Разработанная как приложение к данному стандарту, такая общая эталонная модель архитектуры получила название GERAM (Generalized Enterprise Reference Architecture and Methodology).

всеобъемлющий взгляд на следующие аспекты:
бизнес, включая движущие силы (ключевые

факторы), видение и стратегию;
организационные структуры и сервисы, которые требуются для реализации этого видения и стратегии;
информация, системы и технологии, которые требуются для эффективной реализации этих сервисов.

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

компоненты, связанные с функциональной архитектурой (бизнесом), информационными технологиями и

управлением архитектурным процессом.
Диаграмма отражает подход NASCIO (Национальной Ассоциации CIO США), на то, как различные компоненты взаимодействуют и влияют друг на друга.

стратегий организации, связанных с бизнесом, информацией, прикладными системами и

технологиями, а также их влиянием на функции и бизнес-процессы организации.
Имеется множество методик описания архитектуры, и все они разбивают архитектуру предприятия на различное количество моделей и определений, которые относятся к таким областям, как бизнес, информация, прикладные системы, технологическая инфраструктура.
методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, META Group и другими;
модель Захмана;
методика TOGAF;
методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году.

Джона Захмана,
1992 год - вторая (в

соавторстве с Дж. Сова) статья Джона Захмана (1. Sowa J. F., Zachman J. A. Extending and Formalizing the Framework for Information System Architecture // IBM Systems Journal. 1992. V. 31. № 3.
предложен вариант обобщенной схемы или структуры (framework, или «фреймвок») для описания и анализа архитектуры: формально (по названию) еще архитектуры ИС, но по содержанию - уже предприятия.

КТО?

ЧТО? КАК? ГДЕ? КОГДА?

Бизнес-архитектура

факторы
Моделирование бизнес-функций
Ряд 2 – Модель бизнеса
Модели бизнес-процессов
Ряд 3 –

Системная модель
Логические модели

Ряд 4 – Технологическая модель
Физические модели
Определение и разработка решения

Ряд 5 – Детальное
представление
(Как выстроено)
Как выстроено
Внедрение

Ряд 6 – Работающая
организация
Функционирование организации
Оценка

Каждая колонка имеет в основе простую, базовую модель
Правило

3:
Базовая модель в каждой колонке уникальна

Правило 4:
Каждый ряд представляет различную
точку зрения (взгляд на систему)

Правило 5:
Каждая клетка уникальна

Правило 6:
Совокупность клеток одного ряда формирует полное описание системы
с соответствующей точки зрения

и движущие факторы
Моделирование бизнес-функций
Функции/Как
Бизнес-функции верхнего уровня
Данные/Что
Классы данных верхнего уровня,

связанные с каждой функцией

Люди/Кто
Держатели акций, имеющие отношение к каждой функции

Место/Где
Местоположения, связанные с каждой функцией

Время/Когда
Циклы и события, относящиеся к каждой функции

Мотивация/Почему
Цели бизнеса, задачи и результаты деятельности
Меры, относящиеся к каждой функции

бизнес-функций
Ислючение пересечения и дублирования функций
Функции/Как
Бизнес-процессы
Данные/Что
Информация о бизнесе

Люди/Кто
Роли и ответственность

в каждом процессе

Место/Где
Местоположения, связанные с каждым процессом

Время/Когда
Действия в рамках каждого процесса и последовательность интеграции и оптимизации процессов

Мотивация/Почему
Политики, процедуры и стандарты для каждого процесса

проектами
Определение требований
Функции/Как
Логическое представление информационных систем и их взаимосвязей
Данные/Что
Логические модели

данных и взаимосвязи между данными

Люди/Кто
Логическое представление прав доступа в зависимости от роли и ответственности

Место/Где
Логическое представление распределения системной архитектуры по местам

Время/Когда
Логические события и их следствия в рамках бизнес-событий и их следствий

Мотивация/Почему
Политики, процедуры и стандарты в рамках модели бизнес-правил

технологиями
Выбор решений и их реализация
Функции/Как
Спецификация приложений, функционирующих на основе

выбранных технологических платформ

Данные/Что
Требования к типам систем управления базами данных в рамках логических моделей данных

Люди/Кто
Спецификация прав доступа в рамках выбранных платформ и технологий

Место/Где
Спецификация сетевых устройств и их взаимосвязей в пределах физических
границ системы

Время/Когда
Спецификация «переключателей» событий в системе в рамках выбранных платформ и технологий

Мотивация/Почему
Бизнес-правила в рамках стандартов информационных систем

конфигурацией
Внедрение
Функции/Как
Программы, написанные для работы на основе выбранных технологических

платформ

Данные/Что
Определение данных в рамках физических моделей данных

Люди/Кто
Права доступа, созданные для контроля доступа к выбранным платформам и технологиям

Место/Где
Сетевые устройства, формируемые для соответствия спецификациям узлов

Время/Когда
Программирование временных промежутков для упорядочивания последовательности действий в рамках выбранных платформ и технологий

Мотивация/Почему
Бизнес-правила в рамках выбранных технологических стандартов

операциями
Оценка
Функции/Как
Функционирующие компьютерные инструкции
Данные/Что
Внесение данных и их хранение в

активных базах данных

Люди/Кто
Сотрудники и ключевые акционеры, работающие с системой в рамках своих ролей и уровня ответственности

Место/Где
Отправка и получение сообщений

Время/Когда
Установление временных промежутков для задания последовательности событий

Мотивация/Почему
Использование возможностей специальных технологий в рамках стандартов

и метамоделей на основе одной обобщенной схемы;
использование репозитория

архитектурной информации для работы с разными моделями и их состояниями;
управление архитектурой и изменениями предприятия на основе репозитория.

его конкретной системы и в то же время не

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

EAP Спивака ориентирован на планирование ИС. При этом EAP

представлялся как процесс, определяемый бизнесом или данными, поскольку:
основанием для формируемых архитектур являлась устойчивая бизнес-модель;
данные (понимаемые как бизнес-информация, описываемая в стиле «сущности-связи») определялись до определения приложений;
зависимости в данных определяли последовательность внедрения прикладных систем.

GERAM (Generalised Enterprise Reference Architecture and Methodology) - Обобщенная

референсная архитектура и методология предприятия.
GERAM включено в качестве приложения в действующий базовый стандарт - ISO 15704:2000 «Requirements for enterprise-reference architectures and methodologies».

представлениями (Views) - типы моделей («функции», «данные», «ресурсы», «организация»,

что уже, чем шесть аспектов Захмана), назначения (может быть ассоциировано со столбцом «ЗАЧЕМ» Захмана), реализации и «физические представления» (аппаратура, ПО) и возможность определять дополнительные аспекты;
описание всех аспектов или какой-то их части на каждой из семи или восьми фаз формирования архитектуры и функционирования предприятия;
конкретизацию модели архитектуры на трех уровнях - обобщенном, уровне частичных моделей (они же повторно используемые референсные, reference) и конкретных моделей.

enterprise-reference architectures and methodologies.
Стандарт предназначен для

определения требований к архитектурам и методологиям предприятия (enterprise-reference architectures and methodologies).
Стандарт нацелен на решение задач трех типов: создание предприятия, его реструктуризация и инкрементальные изменения.
Стандарт ориентирован как на людей, так и на технологии.

основной компоновки и взаимодействия частей системы (будь то физический

либо абстрактный объект или сущность).
Примечание. Есть два и только два типа архитектур, относящихся к интеграции предприятий:
архитектуры систем (иногда называемые архитектурами типа 1), которые имеют дело с конструкцией некоторой системы, например, компьютерной системы управления как части всеобъемлющей системы интеграции предприятия;
архитектуры (планы/проекты) предприятия (иногда называемые архитектурами типа 2), которые имеют дело с таким проектом, как интеграция всего предприятия, или с иной программой его развития».

физической реализации

на моделях, согласно стандарту должны поддерживать идею «многократно применимых

референсных моделей» (reusable reference models). Такие модели вводятся стандартом для того, чтобы за счет использования концепций, применимых на многих предприятиях, можно было повышать эффективность моделирования. При этом указывается, что референсные модели требуют адаптации к конкретному предприятию, то есть не рассматриваются как эталон для непосредственного применения. Предусматривается также возможность создания специфических/детальных (particular) моделей, которые описывают некоторую сущность конкретного предприятия или его части.

делового процесса, созданная для предприятия конкретной отрасли, внедренная на

практике и предназначенная для использования при разработке/реорганизации деловых процессов на других предприятиях.