Тема1 Архитектура предприятия: Основные понятия и концепции
Взаимосвязь видов архитектуры
Архитектура информационных технологий и архитектура предприятия в целом как раз и является основным механизмом интерпретации и реализации целей организаций через адекватные ИТ-инфраструктуры и системы. Это достигается через создание определенного количества взаимосвязанных архитектурных представлений. Имеется множество методик описания архитектуры, и все они разбивают Архитектуру предприятия на различное количество моделей и определений, которые относятся к таким областям, как бизнес, информация, прикладные системы, технологическая инфраструктура.
Бизнес-модели описывают стратегию организации, структуры управления, требования, ограничения и правила, а также основные бизнес процессы, включая взаимосвязи и зависимости между ними. Т.е. бизнес-архитектура описывает на уровне предприятия в целом то, как реализуется основные функции организации, включая организационные и функциональные структуры, роли и ответственности.
Архитектура информации определяет ключевые активы, связанные со структурированной и неструктурированной информацией, требующейся для бизнеса, включая расположение, время, типы файлов и баз данных и других информационных хранилищ.
Архитектура прикладных систем описывает те системы, которые и обеспечивают необходимый функционал для реализации логики бизнес-процессов организации.
Определение архитектуры Gartner
В самом общем виде, в соответствии с определениями Gartner архитектура – это:
· общий план или концепция, используемая для создания системы, такой как здание или информационная система, или «абстрактное описание системы, ее структуры, компонентов и их взаимосвязей»;
· семейство руководящих принципов, концепций, правил, шаблонов, интерфейсов и стандартов, используемых при построении совокупности информационных технологий предприятия.
Обратите внимание, что первое определение сфокусировано на описании существующих и будущих систем, второе – на процессе их построения.
Элементы архитектуры предприятия
Уровни АП (1)
Архитектура предприятия определяет общую структуру и функции систем (бизнес и ИТ) в рамках всей организации в целом (включая партнеров и другие организации, формирующие так называемое «расширенное предприятие») и обеспечивает общую рамочную модель (framework), стандарты и руководства для архитектуры уровня отдельных проектов. Общее видение, обеспечиваемое Архитектурой предприятия, создает возможность единого проектирования систем, адекватных, с точки зрения обеспечения потребностей организации, и способных к взаимодействию и интеграции там, где это необходимо. Чуть позже мы вернемся к определению понятия Архитектура предприятия.
Архитектура уровня отдельных проектов определяет структуру и функции систем (бизнес и ИТ) на уровне проектов и программ (совокупностей проектов), но в контексте всей организации в целом, т.е. не в изолированном рассмотрении индивидуальных систем. Архитектура уровня отдельных проектов детализирует, соответствует и существует в рамках Архитектуры предприятия.
Уровни АП (2)
Архитектура прикладных систем определяет структуру и функции приложений, которые разрабатываются с целью обеспечения требуемой функциональности. Некоторые элементы этой архитектуры могут быть определены на уровне Архитектуры предприятия или Архитектуры отдельных проектов (в формировании стандартов и руководств) в целях использования лучшей практики и соответствия принципам всей архитектуры в целом.
Типы архитектуры
· концептуальная архитектура определяет компоненты системы и их значения, обычно в неформальном виде. Это представление часто используется для обсуждения с нетехническими специалистами, такими как руководство, бизнес-менеджеры и конечные пользователи функциональных характеристик системы (что система должна уметь делать, в основном, с точки зрение конечного пользователя);
· логическая архитектура выделяет, прежде всего, вопросы взаимодействия компонент системы, интерфейсы и используемые протоколы. Это представление позволяет эффективно организовать параллельную разработку;
· физическая реализация, которая описывает привязку к конкретным узлам размещения, типам оборудования, характеристикам окружения, таким как, например, используемые операционные системы и т.п.
Понятие Корпоративной архитектуры
«Корпоративная Архитектура» или «ИТ-Архитектура» являются терминами, которые специалисты очень часто используют, но при этом редко бывает ясно, что имеется в виду на практике. В реальности профессионалы в области информационных технологий, как уже отмечалось. Понимают под архитектурой ИТ достаточно большой спектр понятий – структурированное семейство технических руководств, включая концепции, принципы правила, шаблоны и интерфейсы, а также взаимосвязи между ними, которые используются при создании новых информационных систем и развитии существующих систем. В отличии от них, профессионалы в области бизнеса не рассматривают этот вопрос как вопрос исключительно технологий. Наоборот, они разговаривают в терминах бизнес-моделей, бизнес-процессов и иногда – бизнес-архитектуры.
Эволюция термина «Архитектура предприятия»
Информационно-технологическая архитектура
Следующей ступенькой явилось понятие Корпоративной информационно-технологической архитектуры масштаба предприятия (EWITA – Enterprise-Wide Information Technology Architecture). Стало понятно, что усилия по описанию архитектуры предприятия должны включать в себя описание Архитектуры информации и Архитектуры прикладных систем, а не только технологический уровень. Основное направление работ при этом состоит в совместном использовании общих данных, исключении дублирования бизнес-функций, координации управления пользователями, ресурсами, информационной безопасностью за счет улучшений в управлением портфелем прикладных систем.
Корпоративная информационно-технологическая архитектура масштаба предприятия описывает то, как компоненты информационной системы связаны между собой; точно так же бизнес-архитектура описывает то, как элементы бизнеса связаны между собой.
Преимущества наличия информационно-технологической архитектуры
Такой подход обеспечивает более эффективное взаимодействие различных структурных подразделений организации:
· совместный доступ к информации различных подразделений, а также внешних организаций (клиентов, партнеров, поставщиков);
· уменьшение дублирования с точки зрения параллельной реализации близких по функционалу прикладных систем для различных бизнес-подразделений;
· решение проблем, которые затрагивают интересы нескольких подразделений, например, интеграция и взаимодействие информационных систем. Получаемые преимущества носят, в основном, тактический характер.
Преимущества объединения бизнес-архитектуры и IT-архитектуры в общую архитектуру предприятия
· обеспечение вариативности бизнес-стратегии за счет возможности изменений в обеспечивающих процессах и технологических решениях;
· лучшие перспективы, с точки зрения использования возможностей информационных технологий по формированию самой бизнес-стратегии.
Эффект расширения понятия архитектура предприятия
Определение GAO (1)
В соответствии с интерпретациями Финансово-контрольного управления США (GAO) «…архитектура предприятия является необходимым инструментальным средством для того, чтобы повысить результативность и эффективность существующих в организации бизнес-процессов, а также средством для разработки и реализации поддерживающих их технических систем. В наиболее простой интерпретации организация, учреждение, предприятие и т.д. представляют собой совокупность целенаправленных операционных действий, а архитектура предприятия даёт структуру (или структурное описание) этого действия. Архитектура предприятия систематизирует и даёт фиксированное описание в виде работоспособных моделей, диаграмм и функциональных описаний всех режимов деятельности данного объекта. Как отмечалось выше, в роли такого объекта моет выступать либо отдельная автономная организация, либо функциональная или предметная область, которая охватывает несколько организационных границ (например, финансовое управление, управление сбором данных, управление материального обеспечения и т.п.)».
Определение GAO (2)
«Архитектура предприятия описывает деятельность предприятия с двух позиций:
· с позиции логических терминов, таких как взаимодействующие бизнес-процессы и бизнес-правила, необходимая информация, структура и потоки информации, места расположения работы и пользователей;
· с позиции технических понятий, таких как аппаратные и компьютерные средства, программное обеспечение, коммуникация данных, защита и безопасность, а также используемые стандарты.
При этом обе группы понятий охватывают с одной стороны текущее состояние «как есть» и перспективное (или целевое) состояние «как должно быть». Одна из главных задач архитектуры предприятия состоит в том, чтобы оптимизировать взаимные зависимости и существующие взаимоотношения и создать для этого соответствующую инфраструктуру и приложения которые поддерживали бы все эти действия. Опят работы показал, что попытки определить и построить основные ИТ-системы без ориентации на концепцию архитектуры предприятия, как правило, приводят к дублированию усилий и, ч то самое главное, сопровождаются трудностями взаимодействия по интерфейсам и, как следствие, препятствуют интеграции различных систем.»
Контекст АП
Когда организация рассматривает аспекты, связанные с изменениями в бизнесе, то традиционным является подход к такому анализу «сверху-вниз» в терминах людей и процессов. В тоже время традиционные подходы к разработке приложений и даже комплексных традиционных систем имеют тенденцию уделять больше внимания идентификации и реализации специфических, функциональных свойств, которые требуются для автоматизации отдельных задач – как бы двигаясь в обратном направлении. Гораздо меньше внимания уделяется тому, как в итоге система в целом будет взаимодействовать с другими системами из этой же и других областей в целях достижения преимуществ для бизнеса организации. В результате появляется разрыв между высокоуровневым бизнес-видением, организационной структурой и информационными системами, которые по идее, призваны обеспечивать им поддержку.
Синхронизация потребностей бизнеса
Связь требований бизнеса и архитектуры IT
Пользователи АП
· профессионалы в области создания информационных систем, которые вовлечены в соответствующие корпоративные проекты создания важных для предприятия приложений;
· системные архитекторы, которые отвечают за создание архитектуры отдельных информационных систем;
· бизнес-аналитики, которые ведут процесс проектирования организационных структур и бизнес-процессов;
· руководители, заинтересованные в систематическом, структурированном анализе проблем и возможностей, которые открываются перед бизнесом.
· Контекст и уровни архитектуры 
Аспекты АП
· перспектива (perspective) или уровень абстракции;
· представление (view) или предметная область, домен архитектуры.
Большинство методик разделяет проблему описания Архитектуры предприятия на некоторое количество представлений или предметных областей (доменов), таких как:
· бизнес-архитектура – люди и процессы;
· архитектура информации – данные, информация и знания;
· архитектура прикладных систем;
· технологическая архитектура.
Уровни абстракции
· уровень контекста – ориентирован на бизнес-руководство;
· концептуальный уровень или «Видение Общих Требований» - ориентирован на «владельцев» бизнес-процессов;
· логический уровень – ориентирован на архитекторов и проектировщиков систем;
· физический уровень – уровень на проектировщиков и разработчиков систем.
Интегрированная концепция АП
Содержание уровня контекста
Уровень контекста описывает внешнюю среду, движущие силы и факторы, оказывающие действия на бизнес организации, видение, стратегию и то, как они влияют на деятельность организации приоритеты. Этот достаточно полный набор утверждений затем используется в последовательной манере на различных этапах процесса понятия решений, что обеспечивает возможность отследить «в обратную сторону» то, какими внешними факторами, стратегий и видением определялись те или иные решения. В конечном итоге это создает возможность обеспечения соответствия информационных систем требованиям бизнеса.
Обычно «технические люди» игнорируют эти модели по причине того, что считают их слишком упрощенными и абсолютно «нетехнологичными». Однако контекст является важным для понимания тех или иных, в том числе технологических, решений и компромиссов.
Вопросы уровня контекста
· Каких целей хочет добиться организация?
· Почему организация занимается таким бизнесом: видение, миссия и цели?
· Каковы тенденции в индустрии, в которой работает организация?
· Как организация расположена и где она работает географически?
· Каковы факторы, определяющие достижения высоких результатов в бизнесе (value drivers)?
· Каковы на самом высоком уровне классы информации, которыми оперирует организация?
· Каковы функции этого бизнеса?
· В каких областях сосредоточена ключевая компетенция организации?
Содержание концептуального уровня
Концептуальный уровень является наиболее абстрактным и описывает те или иные элементы архитектуры в терминах бизнеса организации и в терминах конечных (непрофессиональных в смысле ИТ) пользователей системы. Эта перспектива отвечает на вопрос о том, как организованно и работает предприятие с целью успешной реализации своих задач в условиях, которые накладывает на организацию внешняя среда (контекст). Это все еще «нетехнологический » уровень описания, но он уже показывает, как требования, накладываемые на организацию контекстом, могут быть удовлетворены.
Концептуальный уровень используется для определения функциональных требований и описания систем с точки зрения бизнес-пользователей для построений бизнес-моделей. Таким образом, если мы говорим о прикладной системе, то бизнес-модели определяют ее концептуальную архитектуру (перспективу).
Концептуальный уровень описывает сервисы и взаимосвязи между сервисами. которые должны быть реализованы для обеспечения принципов, определенных на уровне контекста. Модели, которые создаются на этом уровне, основаны на понятии сервисов (они не содержат специфических деталей стандартов и продуктов, реализующих сервисы), поэтому они носят стабильный характер, если только сам бизнес сам не претерпевает фундаментальных изменений с точки зрения общего видения и целей. Этот уровень анализа обеспечивает фундамент, на котором можно строить логическую архитектуру. Ключевые вопросы, которые рассматриваются на данном уровне, следующие:
Вопросы концептуального уровня
· Какие области бизнеса должны быть поддержаны информационными технологиями?
· Какая общая бизнес-архитектура (например, «фронт-офис», «мид-офис», «бэк-офис») будет использоваться?
· Как системы будут соотноситься с организационными структурами и бизнес-архитектурой, насколько информационные системы отдельных департаментов будут консолидированы в единый набор ключевых прикладных систем?
· Как выглядят бизнес-процессы, которые обеспечивают создание продуктов и оказания услуг?
· Какая информация требуется для каждого бизнес-процесса и как эта информация может повторно использоваться?
· Организован ли бизнес организации в централизованном или децентрализованном виде?
· Какой уровень делегирования полномочий должны обеспечить системы?
· Какие существуют общие принципы по использованию технологий, характерны для индустрии, в которой работает организация, и типы оказываемых услуг?
· Какие вопросы по надзору и руководству использованием технологий должны быть рассмотрены на данном этапе?
Содержание логического уровня
Логический уровень архитектуры показывает основные функциональные компоненты и их взаимосвязи между собой без технических деталей того, как на практике реализована функциональность этих компонент. Логический уровень является «последним» уровнем, который изолирует требования бизнеса от обеспечивающих выполнение этих требований технологий. Он определяет классы прикладных систем, технологий и данных, которые должны быть поддержаны, но не в терминах конкретных продуктов и технологических решений. Логические модели отвечают не вопрос о том как требования, идентифицированные в концептуальных моделях, будут реализованы. На этом уровне определяются общие принципы, которые будут накладывать определенные ограничения на решения, принимаемые на более низких уровнях (например, ориентация на технологии web-сервисов).
Вопросы логического уровня
· Какие приложения необходимы для поддержки бизнес-процессов?
· Кто является основными пользователями и заинтересованными сторонами в реализации данных прикладных систем?
· Как выглядят нормализованные модели данных для этих приложений?
· Какие прикладные системы нужны для управления данными: создания, чтения, внесения изменений и удаления данных?
· Какие нужны технологии для реализации этих прикладных систем?
· Как будет выглядеть распределенная архитектура прикладных систем?
· Как будет выглядеть распределенная архитектура прикладных систем?
· Как стандарты должны быть приняты организацией?
Содержание физического уровня
Физический уровень описывает принципы проектирования, стандарты и правила, включая группирование критически важных компонент, а также моделей развертывания. Это обеспечивает общую основу. В рамках которой на уровне реализации будет выполнена непосредственно разработка. Здесь же определяются критерии отбора технологических решений. Которые должны быть либо разработаны, либо приобретены.
Если мы говорим о физическом уровне (архитектуре) прикладной системы, то каждый элемент модели приложения необходимо соотнести с реальными технологиями и технологическими стандартами. Что делается через создание технологических моделей приложения. Как говорит само название, данный уровень абстракции описывает то, как логические структуры будут физически реализованы.
Вопросы физического уровня
· Каковы функциональные спецификации каждой прикладной системы?
· Будет ли организация разрабатывать специализированные приложения или покупать стандартные?
· Каковы критерии выбора и как будут оцениваться различные инициативы по реализации системы?
· Как данные будут представлены на физическом уровне?
Пример взаимосвязи уровней абстракции
| Перспектива (уровень абстракции) | Уровень детализации |
| Контекст | · Компания представляется в виде «черного ящика» и является центральным «действующим лицом» (актором). · Бизнес моделируется с точки зрения внешних для бизнеса акторов. · Моделируется только бизнес-взаимодействия, средства игнорируются. |
| Концептуальный | · Моделируется потоки работ бизнес-процессов, идентифицированных на концептуальном уровне. · Система, реализующая процессы, является центральным актором в форме «черного ящика». · Бизнес-процессы моделируются с точки зрения внешних для системы акторов. Рассматриваются средства коммуникаций, используемой для выполнения транзакции. |
| Логический | · Моделируется внутренняя архитектура системы. · Основные компоненты системы являются основными акторами. · Поведение системы моделируется с точки зрения внутренних для системы «черных ящиков». |
| Физический | · Моделируется физическая структура реализации системы. |
Тема 2 архитектура предприятия и ее моделирование
Определение АП
В самом общем виде под архитектурой предприятия (EA – Enterprise Architecture) понимается всестороннее и исчерпывающее описание (модель) всех его ключевых элементов и межэлементных отношений. Согласно ISO 15704 (“Industrial Automation Systems – Requirements for Enterprise-Reference Architectures and Methodologies/ 1999”) архитектура предприятия должна включать роль людей, описание процессов вспомогательных технологий на приложения всего жизненного цикла предприятия.
АП определяет
· Структура бизнеса;
· Информацию, необходимую для ведения бизнеса;
· Технологии, применяемые для поддержания бизнес-операций;
· Процессы преобразования, развития и перехода, необходимые для
· Реализации новых технологий в ответ на изменение/появление новых бизнес-потребностей.
Структура АП
· Корпоративные миссия и стратегия, стратегические цели и задачи;
· Бизнес-архитектура;
· Системная-архитектура (ИТ-архитектура).
Корпоративные миссия и стратегия определяют основные направления развития предприятия и ставят долгосрочные цели и задачи.
Бизнес-архитектура на основании миссии, стратегии развития и долгосрочных бизнес-целей определяет необходимые бизнес-процессы, информационные и материальные потоки, а также поддерживающую их организационно-штатную структуру.
Системная архитектура определяет совокупность методологических, технологических и технических решений для обеспечения информационной поддержки деятельности предприятия, определяемой его бизнес-архитектурой, и включает в себя архитектуру приложений, архитектуру данных и техническую архитектуру.
Структура АП
| Корпоративные миссия и стратегия | ||
| Бизнес-архитектура | ||
| Бизнес-процессы | Организационно-штатная структура | Система документооборота |
| Системная архитектура | ||
| Приложения | Данные | Оборудование |
Цикл построения АП
Этапы процесса построения АП
· Осознание необходимости построения архитектуры;
· Формирование рабочей группы;
· Выбор среды моделирование и репозитория;
· Предложение изменений в процессах;
· Наполнение среды фактическим материалом (формирование архитектуры);
· Использование;
· Расширение и сопровождение.
Моделирование архитектуры
Модель архитектуры предприятия аккумулирует знания о его процессах, поведении, информационных и материальных потоках, ресурсах и организационных единицах, инфраструктуре и архитектуре систем. При этом главной целью моделирования должно являться не только повышение интегрированности предприятия, но и поддержка его анализа в самых различных разрезах (экономических, организационных, качественных, количественных и т.д.) для совершенствования деятельности по принятию решений, контролю, координации и мониторингу различных его частей. Чтобы иметь полное понимание бизнеса. Необходимо иметь ответы на вопросы – кто, что, когда, зачем, где и как осуществляет.
Компоненты среды моделирования
· Блок элементарных объектов предприятия;
· Блок моделей архитектуры предприятия;
· Блок языков и методологий моделирования;
· Блок языков и мета-моделирования и методологий определения методологий.
Блок элементарных объектов предприятия
· описания (представления) элементарных объектов (например, конкретного продукта/услуги, производимого на предприятии в настоящие время);
· средства, используемые для порождения таких представлений (т.е. данных по объектам) согласно определенным правилам (например, ERP, SCM, CRM, СУБД).
Блок моделей архитектуры предприятия
· собственно модели различных видов (процессно-функциональные, информационные, ресурсные, организационные и другие), состоящие из
· элементов, абстрактно отображающих элементарные объекты; средства моделирования, обеспечивающие анализ, проектирование и использование моделей.
Блок языков методологий моделирования
· общемодельные конструкции;
· процессы моделирования архитектуры предприятия;
· средства, поддерживающие процесс определения и модификации методологий и языков.
Блок языков мета-моделирования и методологий определения методологий
Блок языков мета-моделирования и методологий определения методологий моделирования (мета-методологий), соответственно, для описания концепции, синтаксиса и семантики языков моделирования, и методологий их применения, а также для описания процессов построения этих языков и методологий.
Этапы моделирования АП (1)
· определение бизнес-целей и требований, охватывающих направления бизнеса, миссию, цели, критические факторы успеха, критические бизнес-результаты, видение, выявление требований различных типов (функциональных, системных, технологических) и их документирование;
· моделирование бизнеса с позиции менеджера, включающие построение концептуальных с использованием графических образов (пиктограмм) для представления бизнес-объекта и событий.
Этапы моделирования АП(2)
• моделирование бизнес-процессов;
• моделирование бизнес-функций;
• моделирование оргструктуры, включая ее нисходящую логическую схему, а так же логические схемы принятия решений;
• моделирование ресурсов;
• преобразование бизнес-моделей в модели приложений и технической архитектуры.
Среды моделирования архитектуры предприятий
• универсальные интегрирующие среды (например, Zachman Framework, GERAM)
• языки моделирования предприятий (например, IDEF, ARIS, BPML)
• программные среды моделирования (например, ARIS 6 Collaborative Suite, Popkin System Architect, METIS)
• мета-модели и языки мета-моделирования (например, UML Profile for Business Process Definition, UEML).
Основные программные средства по моделированию АП
Соответствующий рынок инструментальных средств достаточно развит, в таблице приведен перечень лидирующих по объемам продаж пакетов (в алфавитном порядке по вендором)
| Вендор | Продукт | Сайт |
| Casewise | Corporate Modeler | www.casewise.com |
| Computas | Metis | www.computas.com |
| IDS Scheer | Aris | www.ids-scheer.com |
| Mega | Mega Suite | www.mega.com |
| Popkin | System Architect | www.popkin.com |
| Proforma Corp. | ProVision | www.proformacorp.com |
| Ptech | Enterprise Framework | www.ptechinc.com |
Задачи IT-решений по моделированию АП
Архитектура предприятия в одном из главных средств управления изменениями, обеспечивая при этом:
· Оказание помощи менеджерам при анализе потенциальных изменений и их реализации;
· Предоставление основы для современной работы бизнес-менеджеров и ИТ-менеджеров над целями, бизнес-процессами и выстраиванием предприятий в целом;
· Предоставление единого хранилища всей информации о предприятии;
· Обеспечение менеджерам поддержки в принятии решений: они могут обозревать отношения, задавая вопросы, идентифицировать проблемы, выполнять моделирование
Заключение
Значение архитектуры предприятия постоянно увеличивается за счет обеспечения возможностей эффективного использования существующих технологий и эволюционного перехода к новейшим технологиям. В некоторых странах, например, в США, правительственные директивы требуют, чтобы предприятия имели четко описанную архитектуру.
Фактически, создание архитектуры предприятия является первым шагом на пути к предприятию, которое может реагировать на изменения в реальном времени(RTE).