дисциплина Архитектура корпоративных информационных систем 3 лекция Архитектура

дисциплина “Архитектура корпоративных информационных систем” 3 лекция Архитектура корпорации (предприятия) Проф. Замятин Николай Владимирович zam@fet. tusur. ru 1

Вопросы на лекцию 3 “Архитектура корпорации (предприятия)” 1. Необходимость построения архитектур (моделей) предприятия 2. История развития архитектуры предприятия 3. Осознание необходимости построения архитектуры корпорации 4. Состав архитектуры предприятия 5. Общие методические принципы создания архитектуры 6. Цикл (этапы) построения архитектур предприятия 7. Стандарт ISO 15704 8. Миссия корпорации (предприятия) 9. Стратегия корпорации 10. Цели корпорации 11. Модель архитектуры корпорации 12. Бизнес-архитектура корпорации 13. Бизнес-процессы корпорации 14. Формирование рабочей группы 15. Среды моделирования архитектуры 16. Состав среды моделирования архитектуры предприятий 17. Средства моделирования 18. Языки моделирования 19. Формирование референсных моделей 20. Переход от архитектуры предприятия к архитектуре КИС

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

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

Предприятие является гибридной системой, определяемой свойствами людей и машин. Люди как объекты модели или ресурсы характеризуются поведением (они обучаются, решают различные задачи). Машины осуществляют действия или реагируют на другие действия. Все эти объекты системы нуждаются в различных видах информации

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

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

Общие методические принципы создания архитектур 1. Принцип согласованности слоев. Качество связи слоев должно быть таким, чтобы бизнес-потребности и ИТ-решения оставались согласованными на стратегическую перспективу. 2. Принцип независимости слоев. С учетом первого принципа согласованности слои должны быть независимы в том смысле, что изменения, производимые в том или ином слое, требовали бы минимально возможной степени изменений в других слоях. 3. Принцип свободы выбора. Все решения по выбору своей архитектуры и стандартов своего предприятия осуществляет само предприятие и несет ответственность за решение своих задач. 4. Принцип постепенной детализации архитектуры. Архитектурные продукты концептуального значения создаются постепенно по шагам. На каждом шаге свои продукты с постоянной проверкой на удовлетворение требований. 5. Принцип постоянной трансформации архитектуры предприятия. С учетом изложенных выше принципов архитектура предприятия и его система должна находиться в постоянно актуализируемом состоянии, чтобы отвечать на новые требования внешней среды: новые потребности клиентов, новые возможности информационных технологий (ИТ), новые угрозы со стороны внешней среды.

Предприятие Организация • Организация - группа работников и необходимых средств с распределением ответственности, полномочий и взаимоотношений (ИСО 9000: 2000) • Организация – систематизированное, сознательное объединение действий людей, преследующих достижение определенных целей посредством выполнения определенных действий • Организация – социальная технико-экономическая система может являться Учреждение Предприятие является экземпляром может являться Государственное (министерство) Завод Фабрика Научное (НИИ) Фирма Корпорация Образовательное Консорциум Банк Картель (ВУЗ) Компания может являться Холдинг Горизонтальный Вертикальный Смешанный

Развитие архитектурного подхода Переход от рынка продавца к рынку покупателя TQM Total Quality Management Маркетинговое управление, процессый подход Современный подход к АП стандарты CMM Capability Maturity Model. Принципы Деминга CPI Continuous Process Improvement согласование ИТсистем с реальными потребностями бизнеса методика BSP Business Systems Planning

Начало 80 -х годов ХХ века. • Рынки наполнились. Принцип « 3 С» – Customers, Competition, Changes • Изменился статус «продавец-покупатель» – решение принимает клиент. Не работает принцип «они купят все, что мы произведем» – Компания должна быть клиентно-ориентированной – Использование методологии CRM - Customer Relationship Management - управление взаимоотношениями с клиентами • Жесткая и многообразная конкуренция – Для выживания на рынке необходимо иметь: • наименьшую цену • наивысшее качество • лучшее обслуживание • Нормальное состояние современной компании - постоянные изменения – глобализация экономики, повышение мобильности бизнеса – технологический прогресс, сокращение жизненного цикла продукта/услуги и как следствие время разработки нового и выхода

Функциональное управление Большинство организаций сегодня построены по функциям и уровням иерархии, считается что это естественный и эффективный способ организации • Научный подход к управлению (Scientific Management), разработанный Фредериком Тейлором, является, возможно, самым лучшим выражением этих идей. Он утверждал, что работа может быть выполнена наиболее производительно, если разбить ее на простые элементы и если люди, особенно рабочие, распределяются управляющими и специализируются на конкретной простой части работы. • Важная роль управления. "Только через более полную стандартизацию методов, ускоренное внедрение лучших достижений и условий труда, а также усиление кооперации можно обеспечить более быстрое выполнение работы. Естественным следствием этих взглядов стало распространение функционально-ориентированных

Функционально-ориентированная организация Особенности § Строгая вертикальная иерархия управления § Жесткое разделение труда, сгруппированное в соответствии со спецификой выполняемых действий § Управление, ориентированное на выполнение однородных действий Управлен ие Процес сы Функционально-ориентированная организация – организация, структура которой неизменна, имеет вертикальную топологию, построенную в соответствии с выполняемыми функциями, и строгую иерархическую подчиненность «сверху - вниз»

Противоречие между функциональными отделами и процессами организации Функциональные отделы Отдел снабжения Производственный отдел Конструкторский отдел Материально-техническое обеспечение Прохождение договоров Разработка продукции Процессы Управляющие воздействия Отдел продаж

Недостатки функциональной структуры • Невозможность быстрой реакции на изменения в силу самой природы вертикальной иерархии • Буфер на пути инноваций – защита от изменений, которые могут привести к неоправданному риску • Нет ориентации на клиента, главный потребитель - вышестоящий начальник • Непроизвольная разрушительная конкуренция между подразделениями, принадлежащими к различным функциональным структурам • Нет заинтересованности работающих в конечном результате - системы их оценки оторваны от результативности работы • Рост накладных расходов – сначала процесс разбивается на множество операций, а затем «склеивается» через управленческий аппарат ( «отрицательная экономия на масштабе» - предприятия больше платят за «клей» чем за работу) • Каждое подразделение - обособленный островок методов управления и автоматизации – 20% - время выполнения операции, 80% - передача результатов

Эволюция организации бизнеса § ГИБКОСТЬ – быстро приспосабливаться к изменениям рынка 2000 - … § ЭФФЕКТИВНОСТЬ – побеждать в ценовой конкуренции § ИННОВАЦИОННОСТЬ – товары и услуги должны быть технологически «свежими» § ОРИЕНТИРОВАННОСТЬ на клиента – обеспечение 1999 Процесснопродуктами и услугами наивысшего качества 1985 ориентированное партнерство 1995 Интеграция бизнеспроцессов предприятий в Взаимодействие рамках холдинга или (партнерство) со вертикально“стенами между интегрированной компаний Процессно. Функциональная ориентированные компаниями” организация: компании “стены между Сокращение издержек подразделениями” и повышение эффективности

Модель процессного подхода Требования и обратная связь Вход Выход Процесс Поставщик Потребитель Требования и обратная связь Модель «поставщик/потребитель» : каждый отдельный процесс имеет поставщика и потребител

Организация по процессам Руководитель Владелец процесса Материально-техническое обеспечение Участник процесса Владелец процесса Участник процесса Прохождение договоров Участник процесса Владелец процесса Проектирование продукции Привлечение потребителей Участник процесса Владелец процесса Оформление договоров Привлечение потребителей Привлечение клиентов Участник процесса Владелец процесса Изготовление опытных образцов Привлечение потребителей Участник процесса Процессы Управляющие воздействия

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

Противопоставление функционального и процессного подходов • Противопоставление процессного и "функционального" подхода принципиально неверно • Функции, так же, как и процессы, являются равнозначными понятиями управленческой деятельности, и не могут существовать в отрыве друг от друга. При этом результатом и функционального, и процессного подходов является проектирование одновременно организационной структуры (т. е. функциональных областей) и порядка взаимодействия в ее рамках (т. е. процессов). Разница только в исходных точках проектирования: распределять ли функциональные обязанности на основе процессов или проектировать процессы взаимодействия между функциональными областями • У этих двух подходов есть существенное сходство в базовых посылках: и то и другой подход постулируют изначальный набор типовых процессов/функций, который в дальнейшем детализируется и привязывается к конкретному предприятию • Функциональный подход отвечает на вопрос «Что делать? » , процессный «Как делать? » • Противоречий между двумя подходами не существует - они не только дополняют друга, но и в известной степени должны применяться

Функциональный и процессный подходы Начальник отдела Функциональный Отдел Отдел Отдел Функции отдела Функции отдела Функции отдела Процессный подход Владелец процесса 1 Процесс 1 Владелец процесса 3 Владелец процесса 2 Процесс 2 Регламентированный интерфейс взаимодействия процессов Процесс 3

Регламентация деятельности при функциональном подходе

Регламентация деятельности процессном подходе Реглам ент процес са 1 Реглам ент процес са 2 Регламент подраздел Регламент подраздел ения ения Регламент должности Регламент должности Реглам ент процес са 3

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

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

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

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

Блок элементарных объектов предприятия: • описания (представления) элементарных объектов (например, конкретного продукта/услуги, производимого на предприятии в настоящее время); • средства, используемые для порождения таких представлений (т. е. данных по объектам) согласно определенным правилам (например, ERP, SCM, CRM, СУБД).

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

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

Блок языков мета-моделирования и метаметодологий для описания концепции, синтаксиса и семантики языков моделирования, и методологий их применения, а также для описания процессов построения этих языков и методологий

Существующие среды моделирования архитектуры предприятий могут быть представлены следующим образом: • универсальные интегрирующие среды (например, Zachman Framework, GERAM), • языки моделирования предприятий (например, IDEF, ARIS, BPML), • программные среды моделирования (например, ARIS 6 Collaborative Suite, Popkin System Architect, METIS), мета-модели и языки мета-моделирования (например, UML Profile for Business Process Definition, UEML)

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

К наиболее распространенными в настоящее время языкам моделирования предприятий относятся, прежде всего, IDEF, ARIS и BPML Основными недостатками IDEF являются: • наличие всего трех типов моделей – функциональной, информационной и процессной, остальные аспекты архитектуры если и могут быть отображены, то на примитивном, недостаточном для серьезного анализа уровне,

ARIS в целом преодолевает перечисленные недостатки IDEF, однако его методология по сути является методологией-оболочкой: Нет четко описанных регламентов действий, не предлагается уникального подхода к проблеме моделирования архитектуры предприятия. Сам язык включает более 100 типов моделей, 90% из которых практически никогда не используются, инструментальная поддержка осуществляется продуктом той же компании – разработчика методологии. Этот продукт имеет цену, на порядок превышающую стоимость инструментов аналогичного класса для аналогичных платформ, и огромные трудозатраты на его разработку, что вряд ли позволит создать когда-либо конкурирующий инструментарий, поддерживающий данный язык.

Одной из последних разработок в данной области является создание специального языка, ориентированного на моделирование бизнес-процессов BPML (Business Process Modeling Language) Этот язык обеспечивает построение абстрактной исполняемой модели взаимодействующих процессов на основе концепции конечного автомата (машины конечных состояний). BPML представляет бизнес-процессы посредством объединения описания взаимодействий управляющих потоков, потоков данных и потоков событий с дополнительными ортогональными средствами моделирования бизнес-правил, ролей, контекста взаимодействия. Он поддерживает синхронные и асинхронные распределенные транзакции, поэтому может быть использован как исполняемая модель для встраивания существующих приложений в качестве процессных компонент внутрь е-бизнес-процессов

Взаимосвязь бизнес архитектуры и ИТ

Цикл выстраивания архитектуры предприятия основными участниками процесса

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

Состав архитектуры предприятия

Модель, используемая для описания стратегии и архитектуры

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

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

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

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

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

Эволюция представлений об архитектуре предприятия

Позиционирование понятия АП

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

Интегрированная концепция АП: ". . . концепция архитектуры предприятия – это план реализации миссии организации через оптимальное выполнение своих ключевых бизнес-процессов в условиях формирования эффективной инфраструктуры информационных технологий

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

Связь требований бизнеса и различных областей архитектуры ИТ

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

Требования к архитектуру предприятия • • · Навыки мотивации. Архитектор предприятия должен уметь мотивировать и вдохновлять сотрудников. Задача архитектора во многом заключается в формировании и пропаганде идеалов. · Навыки ведения переговоров. В процессе принятия решения часто возникает ситуация, когда именно архитектор предприятия должен встать и сказать свое веское слово. Большинство архитекторов предприятия — индивидуалисты и не обладают организаторскими способностями. · Навыки критического мышления. Умение быстро думать и постоянно быть наготове — крайне полезный навык. · Навыки решения проблем. Архитекторы предприятия часто сталкиваются с целым рядом сложных уникальных проблем, поэтому они должны уметь оценивать и решать такие проблемы. · Глобальное мышление. Умение уйти от узкого взгляда на проблему и рассмотреть ее под различными углами, а затем грамотно обосновать решение критически важно для архитектора предприятия. · Деловая хватка. Знание отрасли, в которой работает архитектор предприятия, помогает ему понять, как технология влияет на бизнес. Работа «в унисон» с бизнесом позволяет архитекторам предприятия заслужить столь остро необходимое им доверие. · Ориентация на процесс. Архитектору предприятия важно уметь мыслить в терминах процесса. Построение регулярных процессов с возможностью повторного использования, а также создание артефактов на основе опыта — это суть работы архитектора. · Навыки работы с людьми. Работа архитектора предприятия подразумевает постоянное взаимодействие с людьми, поэтому отсутствие соответствующих навыков может привести к проблемам.