Специалисты в области информационных технологий под термином «ИТ-архитектура» представляют достаточно большой спектр понятий: структурированное семейство технических руководств, включая концепции, принципы, правила, шаблоны и интерфейсы, а также взаимосвязи между ними, которые используются при создании новых информационных систем и развитии существующих систем. В отличие от них, специалисты в области управления бизнесом рассматривают этот вопрос в терминах бизнес-моделей, бизнес-процессов, бизнес-архитектуры.
В ранних работах ИТ-архитектура рассматривалась, в основном, как технологическая архитектура или архитектура, определяющая инфраструктуру информационной системы. Работы по описанию архитектуры были сосредоточены на формировании технологических стандартов и принципов. Такой подход позволяет добиться определенных частных выгод, связанных прежде всего с уменьшением стоимости закупок и эксплуатации информационных систем и уменьшением затрат на разработку приложений и обучение персонала. Однако он является ограниченным, так как не ориентирован на решение бизнес-задач организации.
Следующей ступенью развития ИТ-архитектуры явилось понятие корпоративной информационно-технологической архитектуры масштаба предприятия (EWITA – Enterprise-wide information technology architecture ). На этом этапе ИТ-архитектура включала в себя помимо технологического уровня описания архитектуры информации и архитектуры прикладных систем. Основное направление работ в этом случае состоит в совместном использовании общих данных, исключении дублирования бизнес-функций, координации управления пользователями, ресурсами, информационной безопасностью за счет улучшений в управлении портфелем прикладных систем. Обобщенная ИТ - архитектура должна включать в себя как логические, так и технические компоненты. Логическая архитектура предоставляет высокоуровневое описание миссии предприятия, его функциональных и информационных требований, системных компонентов и информационных потоков между этими компонентами. Техническая архитектура определяет конкретные стандарты и правила, которые будут использоваться для реализации логической архитектуры.
Такой подход обеспечивает более эффективное взаимодействие структурных подразделений организации 8:
· совместный доступ к информации различных подразделений, а также внешних организаций (клиентов, партнеров, поставщиков);
· уменьшение дублирования близких по функционалу прикладных информационных систем для различных бизнес-подразделений;
· решение проблемы интеграции и взаимодействия информационных систем.
· Традиционно ИТ - архитектуру предприятия представляют в виде трех взаимосвязанных компонентов:
· Enterprise Information Architecture (EIA) – информационная архитектура;
· Enterprise Solution Architecture (ESA) – архитектура прикладных решений;
· Enterprise Technical Architecture (ETA) – техническая архитектура.
В ходе разработки архитектуры предприятия создается его модель, включающая информацию о производственных процессах, информационных и материальных потоках, ресурсах и организационных единицах. При этом ИТ-архитектура, как часть архитектуры предприятия, непосредственно зависит от роли, которую выполняют информационные системы на данном предприятии: стратегическая (ориентированная на выполнение сложившихся стратегий и операций), сдвигающая (инструмент для увеличения эффективности бизнеса), поддерживающая (ИС не играют особой роли в функционировании предприятия), заводская (ИС являются обязательным элементом, обеспечивающим функционирование бизнеса).
Модель предприятия (с соответствующей ИТ-архитектурой) позволяет не только давать лучшее представление о структуре предприятия, но и является эффективным инструментом для анализа экономических, управленческих, организационных и других аспектов его функционирования. ИТ-архитектура предприятия определяет правила формирования всех компонентов ИС и ИТ, взаимосвязи между ними и бизнес-архитектурой предприятия. При отсутствии на предприятии взаимосвязи ИТ-архитектуры и бизнес-архитектурой информационная система быстро утрачивает практическую ценность.
Информационная архитектура (EIA - Enterprise Information Architecture) или архитектура информации – это (с точки зрения аналитиков компании Meta Group) управляемый набор методик, описывающий информационную модель предприятия и включающий в себя:
· базы данных и хранилища данных;
· информационные потоки (как внутри организации, так и связи с внешним миром).
Архитектура информации включает в себя видение, принципы, модели, и стандарты, которые обеспечивают процессы создания, использования и поддержания информации, относящейся к деятельности предприятия. Архитектура информации определяет ключевые активы, связанные со структурированной и неструктурированной информацией, требующейся для бизнеса, включая расположение, время, типы файлов и баз данных.
Информационную архитектуру предприятия можно условно назвать архитектурой потоков данных. Однако это не просто построение моделей данных в рамках всего предприятия. Данные и архитектура данных являются частным случаем информационной архитектуры. Архитектура информации определяет высокоуровневую информационную топологию в рамках всего предприятия и описывает уровни ограничений, накладываемых на архитектурную модель. При построении информационной архитектуры предприятия нет необходимости создавать модели всех видов данных, используемых на предприятии. Достаточно обеспечить выбор наиболее важных (критичных для предприятия) данных и моделировать их на высоком уровне абстракции.
В современном мире информация является важным стратегическим ресурсом, обеспечивающим функционирование предприятия, а информационные системы это инструменты, обеспечивающие корректное и эффективное использование этого ресурса. Архитектура информации описывает связь между информацией и информационными системами.
Формирование информационной архитектуры предприятия требует определения связей между функциями ИС и автоматизированными операциями в бизнес-процессах предприятия. При этом уточняется, какая информация необходима для функционирования текущих бизнес-процессов компании, а какая – для создания новых.
В процессе разработки информационной архитектуры предприятия решаются следующие задачи:
· идентификация существующих данных, определение их источников и процедур использования;
· оптимизация данных за счет сокращения дублирования, исключение неоднозначности и противоречивости информации;
· минимизация перемещения данных за счет их оптимального расположения;
· интеграция метаданных для обеспечения их целостного представления;
· сокращение числа используемых технологий, обеспечивающих хранение и доступность информации.
В ходе построения информационной архитектуры разрабатываются графические модели, описывающие потребность бизнес-процессов и структурных подразделений предприятия в информации. Таким образом, можно говорить о том, что архитектура информации связывает бизнес-архитектуру и архитектуру приложений в единое целое (Рис. 1.18).
Модели, описывающие информационную архитектуру, различаются уровнем абстракции:
· концептуальный уровень – описывает высокоуровневые модели, включающие общую информацию об информационных потоках между функциональными подразделениями (на этом уровне данные рассматриваются с точки зрения бизнеса);
· логический уровень – включает в себя детализированную информацию об имеющихся данных и обеспечивает связь между бизнес-процессами и поддерживающими их информационными системами (на этом уровне формируются требования к необходимой информации, форма ее передачи и представления; здесь данные рассматриваются уже с точки зрения информационных технологий: происходит анализ данных и их структуры);
· физический уровень – описывает реальное расположение данных внутри информационных систем и места их хранения.
Рис. 1.18. Информационная архитектура
Архитектура прикладных решений (ESA - Enterprise Solution Architecture) или архитектура приложений состоит из совокупности программных продуктов и интерфейсов между ними.
В архитектуре прикладных решений выделают два направления:
· разработка прикладных систем;
· использование прикладных систем.
Область разработки прикладных систем составляет технологическую часть архитектуры прикладных решений и включает в себя: программные продукты, модели данных, интерфейсы (API), пользовательские интерфейсы.
Область разработки прикладных систем состоит из технических описаний конкретных приложений. Соответственно, информацию о данных модулях проще всего представить в виде двух следующих схем:
· компоненты и структура системы – внутренняя структура системы, включающая в себя информацию о программных продуктах и базах данных;
· интерфейсы – описывают взаимодействие приложений с внешними объектами (программными продуктами, пользователями).
Информационная система (ИС или приложение – Application) – это программно-аппаратный комплекс, объединяющий в себе компоненты системы, хранилище данных и базы данных, обеспечивающий выполнение определенных бизнес функций предприятия. ИС может иметь одну или несколько инсталляций (экземпляров – Application Instance), которые установлены на серверах и дисковых массивах (Рис. 1.19).
Приложение имеет определенный набор функций (Application function), обеспечивающих поддержку ИТ-сервисов (IT service) и бизнес-процессов (Business process).
Архитектура прикладных решений описывает ситуацию, сложившуюся в ИТ-подразделении на текущий момент времени («технологическое обеспечение» бизнес-процессов, где каждой основной бизнес-функции соответствуют определенные приложения). На основе архитектуры прикладных решений строятся планы развития информационных технологий в компании, разрабатываются планы мероприятий и проектов, необходимых для достижения стратегических целей.
На данном уровне наиболее наглядно проявляется соответствие бизнес-архитектуры предприятия и ИТ-архитектуры, так как здесь можно определить взаимосвязи между организационной структурой предприятия и используемыми приложениями. В этом случае, с точки зрения информационного менеджмента, для оптимизации управления приложениями их разделяют в соответствии с функциональными возможностями на определенные группы – домены . Подобное разделение позволяет проще идентифицировать владельца приложения, определять его соответствие бизнес-требованиям.
Рис. 1.19. Связи информационной системы
Дать однозначную классификацию современным информационным системам предприятий достаточно сложно. Это в первую очередь связано с тем, что системы обладают модульной конструкцией и предприятие имеет возможность закупать только необходимые ему компоненты. При этом одна фирма-поставщик, как правило, выпускает модули для различных областей.
Один из вариантов классификации ИС делит существующие информационные системы на группы в соответствии с архитектурными стилями, по которым они построены (различные бизнес-процессы требуют разную по характеру среду информационных технологий, отличающуюся производительностью и надежностью). Архитектурный стиль – это совокупность корпоративных технологий и операционных сред, ориентированных на обслуживание определенных групп бизнес-процессов. Такая классификация позволяет отслеживать взаимосвязи между требованиями, предъявляемыми различными типами бизнес-процессов предприятия, и информационными системами.
В соответствии с классификацией по архитектурным стилям принято выделять следующие основные группы информационных систем:
· приложения, обслуживающие большое количество транзакций (Transaction Processing ) – к таким приложениям относят биллинговые системы, поддерживающие функционирование телекоммуникационных компаний, банковские системы, обеспечивающие транзакции по кредитным картам;
· приложения, осуществляющие операции в реальном времени (Real-Time operations ) – это информационные системы, обеспечивающие бизнес-процессы организации, требующие непрерывного мониторинга и информационного обеспечения (к таким системам можно отнести ИС, обеспечивающие транспортных операций в аэропорту и на железной дороге);
· аналитические приложения, бизнес-аналитика, поддержка принятия управленческих решений (Analytical and Business Intelligence ) – то есть все ИС, связанные с управлением знаниями, обеспечивающие сбор и анализ больших массивов данных в короткие промежутки времени;
· приложения для осуществления совместной работы (Collaborative ) - включает различные средства взаимодействия пользователей внутри компаниями;
· корпоративные и обслуживающие приложения (Utility ) – включают в себя стандартные приложения, обеспечивающие функционирование основных бизнес-процессов компании (в этот раздел попадают такие группы систем как CRM-системы для управления взаимоотношением с клиентами, ERP-системы для управления ресурсами предприятия и другие).
В таблице (Таблица 1.2) представлены характеристики основных типов прикладных систем. Следует отметить, что большое количество приложений может попадать одновременно в несколько групп по данной классификации.
Таблица 1.2 - Характеристики основных типов прикладных систем
| Процессы с большим количеством транзакций | Операции в реальном времени | Аналитические процесссы и бизнес- аналитика | Совместная работа | Корпора-тивные (обслужи-вающие) | |
| Стратегичес-кие потребности | Предоставление услуг | Время реакции системы | Поддержка принятия управленчес-ких решений | Распределение знаний. Скорость. инновации. | Надеж-ность Низкая стоимость с точки зрения ИТ. |
| Бизнес- требования | Обслуживание клиентов. Уменьшение затрат. Работа 24чХ365д. Целостность данных. | Экономичность и безопасность Работа 24чХ365д. | Повышение эффективности производитель-ности и наглядности предоставления информации. | Скорость выпуска услуг. Повторное использование знаний. | Экономии-чность. Улучшение в процесссах. |
| Отличитель-ные характерис-тики. | Низкая стоимость транзакции. Надежность. Масштаби-руемость. Производи-тельность. Резервиро-вание. | Сканирование и фильтрация потока данных. Приоритезация запросов. Надежность. Публикация и подписка на данные. | Механизм аналитики. Мощность обработки. Объединение данных. | Простота использования. Надежность. Высокая пропускная способность. | Стандарт-ные процессы. Возмож-ность аутсорсинга |
| Интегрирующие технологии | Системы интеграции корпоративных приложений. | Специально разработанный программный код. | Хранилища данных. | Совместно используемые данные и обмен данными. | Стандарт-ные интер-фейсы. |
Портфель прикладных систем составляется на основании потребностей бизнес-процессов предприятия в информационных технологиях и включает в себя набор интегрированных информационных систем.
Текущий профиль информационных систем (existing portfolio ) – описывает существующие приложения, компоненты, интерфейсы и связанные с ними бизнес-процессы (текущая архитектура приложений ).
Планируемый профиль информационных систем (planned portfolio ) – описывает необходимую для бизнеса функциональность информационной системы в будущем (целевая архитектура приложений ).
План миграции (migration planning ) – это документ, описывающий набор изменений, необходимых для перехода из текущего состояния информационной системы в планируемое (целевое). На основании плана миграции активируются проекты внедрения новых информационных систем или внесения изменений в существующие системы.
Оценка портфеля информационных систем (Application portfolio assessment ) – используется для идентификации проблемных областей и возможностей удовлетворения потребностей бизнеса и состоит из следующих разделов:
· вывод приложений из эксплуатации, замена (phase out / replace);
· переоценка необходимости приложений (re-evaluate / reposition);
· разработка новой инфраструктуры ИС (application infrastructure development);
· обеспечение сопровождения и развития ИС (maintain / evolve).
В соответствии с принципом «ценности приложения для выполнения ключевых функций организации» можно выделить приложения, наиболее необходимые для функционирования бизнеса. При этом следует помнить, что уровень необходимости ИС для бизнеса компании или, другими словами уровень критичности ИС, непосредственно связан с их надежностью.
Надежность информационных систем характеризуется прямой зависимостью количества отказов за определенный промежуток времени, напрямую зависит от качества программно-аппаратных средств и уровня резервирования. То есть, надежность ИС напрямую зависит от финансовых затрат на них. Появляется классическая зависимость – чем выше затраты на ИС, тем выше надежность подобной системы. Для сокращения затрат на ИС можно снизить надежность отдельных приложений, не являющихся критичными для бизнес-процессов предприятия. Все ИС можно распределить по нескольким уровням в соответствии с их важностью (критичностью) для компании по следующим показателям:
1) Компания перестает предоставлять услуги клиентам . Данный показатель представляется наиболее важным для функционирования компании. Простой предприятия влечет не только финансовые потери, но и возможные потери клиентов, и судебные иски с их стороны.
2) Компания несет существенные финансовые потери . Одна из основных целей любой компании – получение прибыли и, соответственно, минимизация возможных убытков.
3) Большое количество сотрудников (свыше 500) не может выполнять свои непосредственные обязанности. Подобная ситуация может привести к совершенно неожиданным потерям для предприятия.
В соответствии с представленными выше критериями все ИС на предприятии можно разделить на следующие уровни критичности:
Level 1. Mission-Critical . Системы непрерывного действия для решения особо важных (критичных) задач. Сбой систем подобного уровня выводит из строя, парализует работу всего комплекса информационных систем или оказывает существенное влияние на функционирование компании.
Показатель функционирования ИС уровня Mission-Critical – сбой ИС парализует работу компании (например, компания не может предоставлять основные услуги Абоненту).
Level 2. Business-Critical. Системы, критичные для бизнеса. Системы, обеспечивающие эффективное выполнение бизнес-процессов компании, но при этом не оказывающие прямого воздействия на них. Предприятие может функционировать без информационных систем этого уровня (т.к. подобные операции могут быть выполнены вручную), но, в случае их остановки, будет нести существенные финансовые потери. К подобному уровню также относятся системы, чрезвычайно чувствительные к временным рамкам (например, ИС – периодически передающие информацию в системы Mission-Critical). Соответственно, информационные системы данного класса должны функционировать в непрерывном режиме при условии, что потери, связанные с их остановкой, существенно превышают расходы на содержание.
Показатели функционирования ИС уровня Business-Critical:
· сбой ИС приводит к существенным финансовым потерям;
· сбой ИС может привести к сбою работы систем Mission-Critical;
· данной ИС пользуются более 500 человек, непосредственно связанных с обслуживанием клиентов.
Level 3. Business Operational. Системы, обеспечивающие функционирование бизнеса. Информационные системы данного уровня используются бизнесом для увеличения его эффективности, но при этом, их отключение на непродолжительное время не приведет к существенным финансовым потерям. Долгосрочное отключение этих систем будет влиять на эффективность бизнеса.
Показатели функционирования ИС уровня Business Operational:
· сбой ИС приводит к финансовым потерям;
· сбой ИС, возможно, приводит к сбою работы систем Business-Critical.
Level 4. Office Productivity. Системы внутреннего использования. К данному уровню относятся информационные системы, обеспечивающие эффективность выполнения офисных операций. Эти системы не являются важными для функционирования предприятия в целом, но необходимы для увеличения эффективности работы персонала. Показатель функционирования ИС уровня Office Productivity – сравнение с прочими аналогичными системами.
Алгоритм определения уровня критичности систем:
1) Определение перечня основных бизнес-процессов предприятия, остановка функционирования которых парализует работу компании или ведет к существенным финансовым потерям.
2) Анализ существующих ИС и их взаимосвязь с основными бизнес-процессами компании. Определение важности тех или иных ресурсов (информационных систем и их компонентов) для функционирования основных бизнес-процессов компании.
3) Построение общей модели информационных систем, определяющей взаимосвязи между информационными, программными, техническими и людскими ресурсами, их взаимное расположение и способы взаимодействия.
4) Оценка экономического ущерба, связанного с остановкой ИС и вероятность его возникновения.
5) Оценка уровня критичности ИС для функционирования предприятия на основании информации собранной на предыдущих шагах.
1.2.5. Техническая архитектура ИС предприятия (ETA)
Техническая архитектура ИС предприятия (ETA – Enterprise Technical Architecture ) формируется из совокупности программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений ИС. Основное назначение технической архитектуры – это обеспечение надежных ИТ-сервисов в рамках всего предприятия в целом.
Разработка ИТ-стандартов определяет существенное сокращение затрат на обеспечение функционирования информационных систем предприятия и упрощает управление ИТ-подразделением. По мере внедрения стандартов сокращаются средства на подготовку специалистов (нет необходимости в уникальных специалистах), закупку расходных материалов, ремонт и поддержку программно-аппаратного комплекса (большое количество однотипного оборудования). С возникновением новых стандартов появляются новые рекомендации по формированию ИТ- архитектуры предприятия.
Специалисты компании Gartner Group выделяют шесть архитектурных компонент (сервисов), которые заложены в основу технологической архитектуры ИС:
· сервисы данных : системы управления базами данных, хранилища данных, системы поддержки принятия решений (Business Intelligence);
· прикладные сервисы : языки программирования, средства разработки приложений, системы коллективной работы;
· программное обеспечение ;
· вычислительная инфраструктура : операционные системы и аппаратные средства;
· сетевые сервисы, локальные сети : сетевое аппаратное обеспечение.
На уровне технической архитектуры выделяют две группы требований к программно-аппаратным средствам:
· функциональные требования описывают задачи, поставленные бизнесом перед информационными системами, с точки зрения бизнеса;
· операционные требования описывают задачи с точки зрения технологий и оперируют такими терминами как надежность, управляемость, производительность.
Инвестиции в инфраструктуру информационных систем и технологий являются крупными и долгосрочными. При этом оценка их экономической эффективность для предприятия с точки зрения бизнеса очень часто сопряжена со значительными трудностями. Построение архитектуры предприятия позволяет в какой-то мере решить эту проблему путем построения модели, объединяющей бизнес-процессы, приложения и поддерживающие их программно-аппаратные средства в единую систему.
Для построения такой модели необходимо организовать процесс сбора и обработки информации об ИТ-инфраструктуре, приложениях, организационных единицах и бизнес-процессах. Для упрощения процесса сбора и моделирования, всю информацию в рамках этого процесса обычно заносят в базу данных. Сбор и обработка этих данных является элементом процесса управления конфигурацией (Configuration Management) ITIL/ITSM, который осуществляет централизованную регистрацию и контроль над информацией об инфраструктуре и включает в себя следующие шаги:
· обеспечение реализации процесса;
· контроль качества процесса.
Данные процесса управления конфигурациями обычно хранятся в базе данных Configuration Management (CMDB) и включают в себя информацию об инцидентах, проблемах, изменениях, релизах и связях между ними. Таким образом, эффективно работающий процесс управления конфигурациями обеспечивает большую часть информации, необходимой для построения текущей архитектуры предприятия и является элементом архитектурного процесса.
Вопросы для самоконтроля к теме 1
1) Охарактеризуйте содержательную часть информационного менеджмента.
2) В чем заключаются основные цель и задачи информационного менеджмента?
3) Что представляет собой информация как фактор производства и как основа процесса принятия управленческого решения?
4) Что принято относить к информационным технологиям?
5) Назовите, какие Вы знаете технологии построения корпоративной информационной сети?
6) Для каких целей в крупных организациях используют хранилища данных?
7) Что такое OLAP-технологии и для чего их используют?
8) В чем проявляется связь между информационными системами и информационными технологиями?
9) Назовите основные требования, предъявляемые к информационной системе организации.
10) Что понимают под термином «метамодель» организации, как она формируется?
11) Охарактеризуйте взаимосвязь архитектур бизнеса и его информационной системы.
12) На чем основано управление ИТ-портфелем предприятия?
13) Какие уровни абстракции архитектуры предприятия Вы знаете?
14) В чем проявляется стратегическое соответствие бизнеса и информационной системы предприятия?
15) Какова взаимосвязь стратегии и архитектуры информационных технологий предприятия?
16) Как формируется бизнес-архитектура предприятия?
17) Какие уровни критичности информационной системы предприятия существуют и как они определяются?
18) Что понимают под технической архитектурой информационной системы предприятия?
Лекция 5 (4 часа). Раздел 3. Архитектура предприятия.
3.1. Понятие и общее представление об архитектуре предприятия.
Существует несколько определений и моделей архитектуры, предлагаемых в различных национальных и международных стандартах. Приведем одно из них, дополнив комментариями из других, которые расширяют и уточняют понятие архитектуры.
Архитектура системы (предприятия) представляет стратегическую информационную основу, которая определяет:
- структуру бизнеса;
- информацию, необходимую для проведения этого бизнеса;
- технологии, применяемые для поддержания деловых операций;
- переходные процессы преобразования, развития, которые необходимы для реализации новых технологий в ответ на появление новых изменяющихся бизнес - потребностей.
Эта модель должна отвечать определенным требованиям полезности. Поэтому качество описательных представлений должно быть настолько конструктивным, чтобы на их основе можно было создать (продуцировать) описанный объект и поддерживать его на дальнейшем протяжении жизненного цикла.
Предприятие является гибридной системой, определяемой свойствами людей и машин. Люди как объекты модели или ресурсы характеризуются поведением (они обучаются, решают различные задачи). Машины осуществляют действия или реагируют на другие действия. В этой связи подчеркнем, что эти объекты системы нуждаются в различных видах информации.
Приведенное определение качественно описывает базовое понятие архитектуры.
Для представления общей архитектуры предприятия используются модели, содержащие слои отдельных архитектурных представлений. Как правило, в верхнем слое отражены функциональные требования к предприятию, связанные с его деятельностью. В нижних слоях отражаются технические особенности используемых информационных систем и технологий.
В качестве исходной для представления базовой схемы можно использовать модель архитектуры предприятия (Enterprise Architecture Model), предложенную национальным институтом стандартов и технологий США (National Institute of Standards and Technology - NIST), представленную на рис.3.1.
3.2. Основные цели создания архитектуры предприятия.
Основные цели создания и использования архитектуры предприятия и его систем позволяют осуществить:
- выбор рационального (реализуемого, достигающего цели) решения задач основной деятельности бизнеса предприятия;
- сохранение взгляда на целое в стратегической перспективе;
- исключение провалов в устройстве системы и при ее эксплуатации;
- создание основы и критериев для оценки частных архитектур;
- оптимальное планирование инвестиций предприятия.
Рис. 3.1. Схема архитектуры компьютеризированного предприятия по NIST (HW-hardware-аппаратное обеспечение, SW-software-программное обеспечение).
3.3. Общие методические принципы создания архитектуры.
К общим методическим принципам создания архитектуры предприятия можно отнести целый ряд принципов.
1. Принцип согласованности слоев. Архитектурные слои связаны так, как это представлено на рис. 3.1. Качество связи слоев должно быть таким, чтобы бизнес-потребности и ИТ-решения оставались согласованными на стратегическую перспективу.
2. Принцип независимости слоев. С учетом первого принципа согласованности слои должны быть независимы в том смысле, что изменения, производимые в том или ином слое, требовали бы минимально возможной степени изменений в других слоях.
3. Принцип свободы выбора. Все решения по выбору своей архитектуры и стандартов своего предприятия осуществляет само предприятие и несет ответственность за решение своих задач.
4. Принцип постепенной детализации архитектуры. Архитектурные продукты концептуального значения создаются постепенно по шагам. На каждом шаге свои продукты с постоянной проверкой на удовлетворение требований.
5. Принцип постоянной трансформации архитектуры предприятия. С учетом изложенных выше принципов архитектура предприятия и его система должна находиться в постоянно актуализируемом состоянии, чтобы отвечать на новые требования внешней среды: новые потребности клиентов, новые возможности информационных технологий (ИТ), новые угрозы со стороны внешней среды.
3.4. Формирование архитектуры в процессе детализации.
Разработка концептуальной архитектуры предприятия на перспективу осуществляется как пошаговый процесс формирования целевой архитектуры, отталкиваясь от текущей архитектуры и двигателей ее преобразования. В этот пошаговый процесс входит использование сегментного подхода к архитектуре и принципа постепенной (пошаговой) детализации архитектуры.
3.4.1. Подходы при построении архитектуры.
Вообще говоря, известны три возможных подхода построения архитектуры.
Стандартный подход. В этом подходе вначале разрабатывается общая схема и правила для будущего описания архитектуры. Затем описывается вся текущая база, и после этого представляется вся целевая архитектура. Только после этого начинается конструирование, приобретение, реализация систем.
Этот подход требует существенных начальных инвестиций - финансовых и временных, с одной стороны. С другой стороны, этот подход может привести к тому, что называется "паралич из-за анализа".
Подход "статус-кво" . Разработка рассматривается как реакция на те или иные возникающие затруднения.
Сегментный подход. Этот подход опирается на модель разработки сегментов архитектуры в рамках общей структурированной схемы. Он сосредотачивается на главных областях бизнеса (например, система управления финансами, кадрами, служба документационного обеспечения управления и т.п.).
Для того, чтобы сократить возможные риски, обеспечить снижение начальных затрат и добиться быстрой отдачи от проекта используется сегментный подход.
3.4.2. Компоненты архитектуры предприятия.
Выделяют следующий набор компонентов архитектуры.
Двигатели архитектуры (Architecture Drivers) отражают внешние стимулы изменения архитектуры: бизнес-стимулы и технические стимулы.
В качестве бизнес - стимулов может выступать новое законодательство, новые инициативы администрации, ассигнования для ускорения развития отдельных сфер, рыночные силы.
В роли технических двигателей могут выступать новое и улучшенное программное обеспечение, аппаратные средства ЭВМ и их комбинации.
Стратегическое направление (Strategic Direction) - руководство для разработки целевой архитектуры, которое содержит видение миссии предприятия, принципы его построения, цели и объекты предприятия.
Текущая архитектура (Carrent Architecture) определяет архитектуры предприятия "как есть" и состоит из двух частей: текущая бизнес-архитектура и техническая архитектура (данные, приложения и технологии). Она отражает текущие возможности и технологии, а также служит объектом для дальнейшего расширения.
Целевая архитектура (Target Architecture) определяет архитектуру предприятия "как должно быть построено" и состоит из двух частей: целевая бизнес-архитектура и техническая архитектура (т.е. данные, приложения и технологии). Она представляет будущие возможности и технологии, которые являются результатом улучшения проекта поддержки изменяющихся бизнес - потребностей.
Переходные процессы (Transitional Processes) поддерживают переход от текущей архитектуры к целевой архитектуре. Критические переходные процессы для предприятия включают планирование инвестиций в сферу ИТ, планирование перехода, управление конфигурацией, контроль и управление проектом.
Архитектурные сегменты (Architectural Segments) отражают ориентацию отдельных частей общей архитектуры на главные бизнес - области.
Архитектурные модели (Architectural Models) определяют бизнес - модели и конструкторские (технические) модели, которые отражают все необходимые сегменты для полного описания предприятия.
Стандарты (Standards) включают все стандарты, руководящие принципы (руководящие материалы), а также передовой опыт. Примерами стандартов являются:
Стандарты безопасности;
Стандарты данных относятся к данным, метаданным и другим связанным структурам;
Стандарты приложений относятся к прикладному ПО;
Стандарты технологий относятся к операционным системам и аппаратным платформам.
3.5. Комплексная архитектура предприятия. Модельные и организационные подходы.
С целью дальнейшей проработки архитектурных слоев целесообразно переходить на другое, более детальное, представление архитектуры. В качестве такого представления предлагается использовать схему архитектуры предприятия Дж. Захмана, которая в 90-х годах стала стандартом де-факто.
Схема Дж. Захмана версии 1987, 1992, 2000 гг. отличается более гармоничным и комплексным учетом архитектурно существенных факторов, начиная со слоев бизнес - архитектуры.
В то же время она не навязывает конкретных инструментальных особенностей при формировании моделей.
Благодаря этому схема архитектуры предприятия Дж. Захмана может использоваться в качестве референсной модели для разработки адаптированных методических материалов для конкретных предприятий. Здесь под референсной понимается ссылочная, рамочная эталонная модель.
Свойство моделей, описаний, проектов, имеющих статус стандартизованного образца, характеризует их как шаблоны, которые могут быть использованы в разработках различных конкретных систем.
Однако эта схема, как и изложенные выше схемы архитектурных слоев, обладает недостатками с точки зрения представления динамики развития предприятия и его ИС. Этот недостаток преодолевается расширенной схемой Захмана – схема и подход «3Д-предприятие» (опубликована в 2000 году).
При описании процесса разработки и использовании архитектуры конкретного предприятия рассматривается схема движения от архитектуры «как есть» к архитектуре «как должно быть».
Вышесказанное имеет особое значение для предприятия, включенного в программу трансформации.
3.5.1. Матрица согласованных моделей в архитектурах.
Сложные системы характеризуются выполняемыми процессами (функциями), структурой и поведением во времени. Для адекватного моделирования этих аспектов в автоматизированных информационных системах различают организационные, функциональные, информационные и поведенческие модели пересекающиеся друг с другом.
Функциональная модель системы описывает совокупность выполняемых системой функций, характеризует морфологию системы (ее построение)- состав функциональных подсистем, их взаимосвязи.
Информационная модель отражает отношения между элементами системы в виде структур данных (состав и взаимосвязи).
Поведенческая (событийная) модель описывает информационные процессы (динамику функционирования). В ней фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий.
Организационная модель описывает подразделения из которых состоит предприятие.
Все эти модели должны быть соединены в единую систему понятным и непротиворечивым образом. Поэтому даже вопросов «простого» согласования компонентов системы достаточно для того, чтобы прилагать специальные усилия на уровне формирования архитектуры.
Идея такого согласования состоит в том, что его надо начинать с самых главных характеристик предприятия, рассматривая важнейшие содержательные аспекты. В идеальном случае согласование начинают с конструирования системы управления предприятием, а именно с создания сбалансированной системы целей и планов. В эту сбалансированную систему целей и планов входят: миссия предприятия, стратегические цели, индикаторы достижения целей и их целевые значения; мероприятия по достижению целей, включая архитектуру информационной системы и информационно-технологическую платформу, а также обновленные бизнес – процессы и оргструктуры; система мотивации работников и планы их профессионального обучения и т.д. Согласование проводят на явно изложенных описаниях предприятия, которые позволяют видеть все существенные взаимосвязи, т.е. на его моделях.
Суть этого метода сводится к формализованному представлению предприятия в виде матрицы (Таблица 3.1).
Строки таблицы отражают уровни представления системы , к ним относятся уровни моделирования, уровни решения проектных задач. Более детально это следующие представления:
- бизнес среда системы,
- концептуальная модель,
- логическая модель,
- технологическая, «физическая модель»,
- детальная реализация (часто поблочная),
- представление пользователя (эксплуатация).
- информационное обеспечение (данные),
- функциональное обеспечение (функции),
- коммуникационное обеспечение (сеть),
- организационное обеспечение (структура организации) и т.д.
В строках этой матрицы описываются модели предметной (проблемной) области с позиции различных категорий участников процесса проектирования, к которым относятся представители будущих пользователей системы (заказчиков), проектировщики (консультанты), участвующие в процессе получения и формирования знаний о проблемной области и формулирующие требования к ИС; разработчики и эксплуатационщики ИС.
Проектировщики вместе с заказчиками должны формировать модели предметной (проблемной) области, отражающие содержательную сторону функционирования системы, при этом проектировщики закладывают технологические требования к реализации системы, скрытые от взгляда пользователей.
Таблица 3.1. Матрица согласованных моделей в архитектурах.
| Виды моделей и их реализация
| Цели (почему?) Дерево целей
| Люди (кто?) Архитектура организации
| Функции (как?) Архитек-тура прило-жений
| Объекты-данные (что?) Архитек- тура данных
| Коммуникации (где?) Архитек- тура технологи-ческая
| Время события (когда?
) |
|
| 1 | Укрупненная модель организации (планировщик, пользователь) | Список целей и задач | Список организаций (подразделе- Ний) | Список процесс-сов | Список сущностей | Узлов | Список основных событий |
| 2 | Концептуальная модель организации (проектировщик, Пользователь) | Стратегичес-кая модель: цель – стратегия. | Структурные модели: подразделе-ния – работа | Функцио-нальные модели: процесс – ресурс. | Информацион-но-логические модели: ER-диаг-раммы | Модель топологии узлов | Модель корпоратив-ных событий |
| 3 | Системная модель ИС (консультант-проектировщик) | Критерии достижения целей | Роли персонала | Диаграммы потоков данных | Логическая модель данных | Логическая модель сетей организации | Модель системных событий |
| 4 | Технологическая модель (разработчик ИС) | Модель «состояние-действие» | Модель интерфейса | Модель приложе- Ний | Модель внутреннего представления | Физическая модель коммуникаций | Модель технических событий |
| 5 | Компоненты (разработчик ИС, субподрядчик) | Шаг/задача | Пользователь – транзакция | Програм- мные модули | Данных | Протоколы | Компонент-ные события |
| 6 | Функционирую-щая система (эксплуатацион-щики) | Варианты исполнения | Сеансы работы | Проце- дуры | Ограничения целостности | Клиент – сервер | Операцион-ные события |
На основе модели требований разработчики ИС проводят технологическую детализацию проекта и его последующую реализацию. На основе сформированной рабочей документации и полученного конечного продукта системы эксплуатационщики осуществляют поддержку функционирования системы в новых условиях.
Архитектуры рассматривают систему в разрезе одних и тех же аспектов, но под разными углами зрения.
В качестве основных аспектов построения архитектур рассматриваются следующие:
– цели, бизнес-правила (мотивация того, почему функционирует система);
– объекты (что проходит преобразования);
– функции (как осуществляется преобразование в процессе);
– участники (субъекты) процесса (кто осуществляет процесс);
– место (где выполняется процесс);
– время (временные требования к выполнению процесса, событиям).
В двух первых строках представлены модели, относящиеся к точке зрения будущих пользователей системы, третья строка соответствует взгляду консультанта-проектировщика, четвертая и пятая строки – точке зрения разработчика ИС, шестая строка – точке зрения эксплуатационных служб.
Подход на основе архитектур Д.А. Захмана не определяет собственно методы построения моделей проблемной области, тем не менее, развитые методологии моделирования предметных областей предполагают реализацию принципов последовательной детализации абстрактных категорий: целей, объектов, функций, организационных единиц и т.д. на уровнях определения требований к системе, их спецификации и реализации.
3.5.2. Примеры заполнения ячеек схемы Захмана.
Приведем примеры того, как может быть раскрыт содержательный смысл каждой ячейки матрицы, который представляет собой конкретный план действий по реализации архитектуры предприятия.
Начнем пояснения с первого столбца матрицы: цели (почему?).
Позиция планировщика. Приводится список главных целей, объектов, стратегий и критических факторов успеха бизнеса предприятия, определяющих мотивации его деятельности. Перечень имеет достаточно высокий уровень агрегирования и определяет границы модели предприятия.
Позиция пользователя (собственника). Цель и стратегия предприятия, которые составляют основную мотивацию для деятельности предприятия и принятия решений. Создание бизнес-плана. Бизнес-план в основном ориентирован на проблемы управления, но в нем также должно уделяться внимание вопросам мотивации деятельности.
Позиция проектировщика. Логическая модель реализации бизнес-правил предприятия в терминах намерений и ограничений.
Позиция разработчика. Правила проекта являются физической реализацией спецификации бизнес-правил. Эти правила, представленные в виде входящих элементов, отражаются в моделях данных, в процедурных кодах и в спецификациях технических требований.
Второй столбец матрицы: люди (кто?)
Позиция планировщика. Список организаций, за которые данное предприятие несет определенную ответственность. Перечень имеет высокий уровень агрегирования и определяет границы модели предприятия.
Позиция собственника. Модель потока работ определяет обязанности и спецификации работ, выполняемых на данном предприятии. Обычно организационная диаграмма отражает распределение обязанностей, а сопутствующие документы описывают процессы производства изделий. Организационная диаграмма должна дополняться процессами по производству изделий, включая управление работами, координацию работы и проведение работ.
Позиция проектировщика. Архитектура человеческого интерфейса. Логические системы отражают поток работ, который, включает спецификации ролей и ответственность участников: менеджмент, администрацию, работников высокой квалификации, разработчиков, специалистов по маркетингу и т.д. Сюда относятся также спецификации процессов разработки изделий (например, текст, графика, видео и т.д.).
Позиция разработчика. Представление архитектуры интерфейса. Данный документ является физическим выражением потока работ, осуществляемых на предприятии конкретными служащими, а также их эргономические требования и форматы представления результатов работы.
Третий столбец: функции (архитектура приложений).
Позиция планировщика. Описывается перечень процессов или бизнес-функций, осуществляемый данным предприятием. Этот перечень определяет возможности, границы или модели процессов, которые характеризуют бизнес-деятельность предприятия.
Позиция владельца (модель предприятия). Модель предприятия представляется моделью действующих бизнес-процессов, которые осуществляет предприятие вне зависимости от каких-либо системных или иных соображений и организационных ограничений. Модель может быть представлена как структурированная модель методов, которая отражает бизнес-преобразования (бизнес-процессы), происходящие на предприятии, а также их входы и выходы.
Позиция проектировщика (модель информационной системы). Содержит логическую модель реализации систем, поддерживающих ручным или автоматизированным способом бизнес-процессы предприятия. В модели отражаются сферы действия, как человека, так и машин. Модель может включать средства и механизмы управления, а также входные и выходные данные для логических систем, которые отражают систему функций/процессов предприятия.
Позиция разработчика (технологическая модель). Приводится конструкция системы. С технической точки зрения это техническая конструкция. На высоком уровне абстракции это может быть структурная схема. При большей детализации она представляется диаграммами действий, которые впоследствии будут переходить в реализацию логических систем или в архитектуру приложений. В случае объектно-ориентированных нотаций это будут различные методы и их реализации.
Позиция субподрядчиков (детализированные спецификации). Представляются программы (поддержка компонентов программного обеспечения, например, операционные системы). Программы, полученные на основе диаграмм действий или объектно-ориентированных спецификаций. Эти программы могут основываться на ранее разработанных компонентах путем их компоновки в требуемом сочетании.
Четвертый столбец: объекты-данные (архитектура данных).
Позиция планировщика. Объекты/сфера действия. Приводится перечень бизнес - объектов. Перечень объектов (изделий или активов), в которых заинтересовано данное предприятие. Модель представляет сферу влияния и границы, которые определяют круг интересов данного предприятия (подробнее это отражается в последующих строках таблицы).
Позиция владельца (модель предприятия). Представляется семантическая модель. Модель фактических объектов бизнес - деятельности предприятия (т.е. изделия или активы), которые являются наиболее существенными для предприятия. Обычно семантическая модель представляется как модель «сущность-связь» и отражает на уровне концептуальных определений (т.е. терминов и фактов) наиболее существенные цели и стратегии бизнеса. Впоследствии эта сущностная модель преображается в бизнес-правила.
Позиция проектировщика (модель ИС). Описывается логическая модель данных. Она представляет собой объекты и цели предприятия, отражаемые в соответствующих записях или отчетах в автоматизированной и в неавтоматизированной форме.
Модель представляется как атрибутивная и нормализованная модель «сущность-связь», отражающая все намерения, которые были ранее представлены в семантической модели.
Позиция разработчика (технологическая модель). Описывается физическая модель данных. Модель отражает технологические ограничения или физическое представление объектов и целей предприятия. Стиль модели зависит от технологии реализации. Если выбрана реляционная технология, модель данных имеет табличную структуру, чтобы поддерживать реляционные модели. В случае объектно-ориентированных нотаций это будет иерархическая/ассоциативная модель.
Позиция субподрядчиков (детализированные спецификации). Приводятся описания данных (библиотека). Определение всех объектных данных, специфицированных физической моделью данных и включающих все описания данных в соответствии с языком описания. Описания данных необходимы для реализации программы.
3.5.3. Схема «3Д-предприятие».
Плоские схемы моделей архитектуры – это средство для организации знаний предприятия, которые важны в условиях приспособления к изменениям предприятия во времени. Для управления проектами развития ИС и трансформации предприятия вводится трехмерная схема, которая образуется путем введения оси стратегического времени.
Модель «3Д-предприятие» строится в трех измерениях.
1. Ось уровня проектирования и использования предприятия. На рисунке (Рис.3.2.) шесть «горизонтальных» уровней:
– потребности и планы,
- бизнес-модель,
- логическая модель,
- техническая конструкция,
- детальная реализация,
- практика использования.
Рис. 3.2. Модель « 3-Д предприятие ».
2. Ось раздела обеспечения и аспекта работы предприятия/АС; шесть вертикальных разделов: цели, люди, функции, объекты, коммуникации, время.
3. Ось времени, в котором развивается предприятие и его АИС стадии на «верхней грани» модели, соответствующих возможным стадиям жизненного цикла системы: анализ (стратегический может отделяться от детального анализа), проектирование (конструирование), реализация и ввод в действие (могут рассматриваться отдельно), совершенствование.
Первые две оси аналогичны (но не обязательно строго совпадают) тем, что использованы в плоской модели Захмана для схемы архитектуры предприятия. Третья ось позволяет явно определить те изменения, которые происходили или будут происходить с предприятием, его информационной системой и проектами создания ИС в процессах их развития и трансформации.
3.5.4. Требования к «3Д-модели».
Описание, создаваемое в указанных осях, становится 3Д-моделью после того, как в элементарных ячейках («кубиках») будут приведены согласованные описания, частные модели. К этим описаниям предъявляются определенные требования. При построении 3Д-модели не следует использовать формализованные нотации и узкопрофессиональные жаргоны.
Модель 3Д-предприятия должна отвечать следующим требованиям:
– простота и доступность для (технических и нетехнических) руководителей и специалистов;
– целостность, каждая проблема рассматривается в рамках предприятия в целом, как в данное время, так и в будущем;
– открытость, каждая проблема или проект могут быть включены в контекст событий будущего;
– использование инструментов планирования, благодаря чему решение не будет приниматься в «пустоте»;
– независимость от каких-либо инструментов (программных, математических), для того чтобы любой инструмент или методология могли быть отображены в модели 3Д-предприятия.
Описание каждой частной модели должно содержать оценку состояния дел с точки зрения данной модели как компонента системы.
Создаваемые в ячейках частные модели должны быть согласованы в своих взаимосвязях.
Правилом описания взаимосвязей частных моделей является явное выделение и описание связей каждой модели-ячейки с ближайшими ячейками более высокого и более низкого уровней представления архитектуры предприятия и ИС; связей каждой модели-ячейки с ближайшими ячейками, отражающими предшествующее и будущее состояния компонента архитектуры; связей каждой модели-ячейки с другими типами моделей данного уровня.
– необходимость компонента и формальные требования к нему;
– качество и степень готовности компонента;
– соответствие плановому графику работ и согласованности различных графиков;
– обоснованность графиков инвестиций и их окупаемости;
– возможность изменений (прогноз) наиболее близкого по времени изменения потребностей, требований и обеспеченности этих изменений ресурсами;
– смысловая целостность модели одного уровня.
Сущности на оси стратегического времени в конкретных 3Д-моделях могут представлять проекты или работы не только по развитию ИС, но и по развитию бизнеса предприятия (как, впрочем, и сущности плоских схем). В ряде случаев не требуется обязательного оформления всех работ на оси стратегического времени в виде проектов (в частности, для того, чтобы не вступать в непродуктивный конфликт с обычаями предприятия).
Например, работами по развитию бизнеса предприятия могут быть фазы управления предприятием:
– ситуационный и диагностический анализ;
– выдвижение целей и выбор стратегий;
– разработка плана мероприятий осуществления стратегий;
– планирование оперативных действий, выполнение подготовительных и запускающих мероприятий;
– тактический и оперативный мониторинг;
– стратегический мониторинг, возобновление анализа и совершенствование стратегий.
Эти фазы тоже могут быть элементами базовой классификации сущностей на оси времени развития предприятия, как и элементы проектного цикла, указанные ранее.
Поскольку ИС должна отвечать конкретным потребностям предприятия, результатом осуществления этого развития могут быть проекты создания новых компонентов ИС. Проект развития ИС вычленяется и оформляется как подпроект проекта развития предприятия.
Заключение.
Рассмотрение концептуального уровня схем архитектуры предприятия показывает:
Архитектура предприятия определяется как базовое свойство и важнейший информационный инструмент предприятий всех типов, что отражается и в международных стандартах;
Важнейшим компонентом архитектуры предприятия являются люди; не учет этого является методической ошибкой;
Архитектура получает свое информационное воплощение в виде архитектурных продуктов, описаний и моделей разных типов;
Согласование архитектур рассматривается как согласование архитектурных продуктов (бизнес - моделей с техническими моделями);
Согласование архитектур рассматривается как процесс, позволяющий получить многократную экономию средств на создание и развитие ИС;
Для использования архитектурных продуктов (как стратегического информационного ресурса) необходимы комплексы организационных решений и инструментальных средств согласования и интеграции архитектур;
Определены принципы, позволяющие выбирать и оценивать архитектурные решения и строить процессы формирования архитектуры, "пошаговость" детализации при построении архитектуры и др.
Эти принципы имеют конструктивное описание, позволяющее использовать их как "руководство к действию":
Главным движущим слоем является бизнес-архитектура;
Кроме указанной бизнес - архитектуры предусмотрены слои архитектуры данных (или данных и информации), приложений, технологий (имеются в виду базовые ИТ);
Рассмотрены бизнес - модели, модели данных, концептуальная модель, а именно (модель процессов, модели интероперабельности (поддержки взаимодействия), технические модели, референсная модель взаимодействия, открытые стандарты (для технологической архитектуры)).
Литература
1. Методический материал «Методология и практические рекомендации по построению автоматизированных систем трансформирующихся государственных предприятий»/ Под общ. ред. Е.З. Зиндера, Фонд ФОСТАС, 2003 год.
2. Тельнов Ю.Ф. Реинжиниринг бизнес – процессов. - М.: Финансы и статистика, 2003. – 256 с.: ил.
Контрольные вопросы
Лекция 5. Раздел 3. Архитектура предприятия.
3.1. Понятие и общее представление об архитектуре предприятия.
3.2. Основные цели создания предприятия.
3.3. Общие методические принципы создания предприятия.
3.4. Формирование архитектуры в процессе детализации.
3.4.1. Подходы при построении архитектуры.
3.4.2. Компоненты архитектуры предприятия.
3.5. Комплексная архитектура предприятия. Модельные и организационные подходы.
Архитектура предприятия какинформационная основа корпоративной структуры
телекоммуникационной компании
А.Р. Диязитдинова ,
доц. каф. ЭИС, к.т.н., доц. dijazitdinova @ mail . ru ,
Е.А. Матвеева,
проф. каф. ЭИС, к.т.н., доц. helen _ matveev а @ mail . ru ,
О.Н. Ольховая,
доц. каф. ЭИС, к.э.н ., olkhovaya @ inbox . ru ,
ПГУТИ, г. Самара
В статье рассматривается место системы поддержки архитектуры предприятия в контуре управления компанией. Приводится алгоритм работы данной системы и взаимосвязь ее основных компонентов.
The article describes a place of enterprise architecture supporting system in a company management cycle. An algorithm of operating this system is provided, and an interconnection of its main components is described.
Введение
В ходе своего развития информационные технологии (ИТ ) заняли прочное место в управлении любым предприятием. Сегодня невозможно достичь эффективности бизнеса без применения ИТ-инструментов , обеспечивающих автоматизацию различных сложных операций.
В то же время новые возможности порождают и новые проблемы, значительная часть которых связана с трудностью разработки системы управления разнородной инфраструктурой. Сложность решения данной задачи связана с двумя аспектами. Во-первых, на предприятиях, как правило, функционирует несколько информационных систем, созданных и внедренных в разное время различными производителями. Во-вторых, жизненный цикл продуктов и ритм постоянных изменений, происходящих на рынке и вызывающих необходимость адаптации структуры предприятий, становится все более коротким.
Телекоммуникационные компании имеют ряд особенностей [
\\* MERGEFORMAT "">6 ], обуславливающих объективную необходимость развития и концепции поддержки архитектуры предприятия:
- непрерывность предоставления услуги;
- высокая технологичность и зависимость от сетевой и ИТ-инфрастуктуры .
Одним из эффективных инструментов осуществления организационных изменений с использованием ИТ в компаниях различных отраслей, способным обеспечить непрерывность бизнеса, стала архитектура предприятия. Поддержка архитектурного подхода в высокотехнологичной телекоммуникационной отрасли должна стать неотъемлемым элементом управления всей деятельностью компании – как операционной,такистратегической.
Архитектура предприятия (АП) должна давать возможность корректировать бизнес-процессы «на лету» таким образом, чтобы изменения сразу же отражались в работе управляющей системы. В докладе предлагается схема адаптации архитектуры предприятия к внешним изменениям.
1. Понятие архитектуры предприятия
Архитектура предприятия становится информационной основой корпоративной структуры компании. Она преследует две цели: во-первых, дать подробное системное описание самой организации для поддержания порядка ее функционирования, а, во-вторых, иметь стратегический план развития компании, учитывающий существующее внешнее окружение компании и ее техническую и технологическую оснащенность.
Архитектура предприятия представляет собой процесс сбора и распространения информации о том, как организация использует и должна использовать ИТ в своей деятельности . По сути, архитектура предприятия представляет собой информационную основу корпоративной структуры компании. Непосредственно архитектура предприятия не описывает конкретные технические решения отдельных информационных систем, но позволяет получить существенную выгоду для бизнеса организации в целом, что связано с повышением степени использования и эффективности информационных систем и программных продуктов, стандартизацией и повторным использованием ИТ-ресурсов , а такжеснижением рисков инвестиций в ИТ-сфере .
В настоящее время существует несколько широко применяемых определений данного понятия (подробно можно посмотреть в ). В качестве рабочего предлагается использовать следующее определение : архитектура предприятия – это всестороннее описание (модель) всех его ключевых элементов и связей между ними (включая бизнес-процессы, технологии и информационные системы), а также процесс поддержки изменения бизнес-процессов предприятия со стороны информационных технологий.
В литературе широко освещены следующие методологии построения АП: модель Захмана , метод EAP (Enterprise Architecture Planning ) С. Спивака ,TOGAF, методика META Group , методология Gartner , FEAF; DoDAF и т.д. Специфика отрасли связиобусловила развитие концепции NGOSS, которую можно рассматривать как референтную модель архитектуры телекоммуникационной компании. Несмотря на наличие значительного числа методик по созданию АП, ни одна из них не имеет доминирующего положения на рынке.
Независимо от выбранной методики построения архитектуры предприятия необходимо понимать, что построение архитектуры – это циклический процесс. Управление меняющимися бизнес-процессами и адаптацией к ним корпоративной системы предприятия должно превратиться в «рутинную» деятельность, поскольку фактически управление предприятием – это есть управление архитектурой предприятия в контексте достижения наибольшей эффективности его функционирования.
2. Концепция системы поддержки архитектуры предприятия
С точки зрения системного подхода в структуре организации следует выделить контур управления, где объектом управления выступает собственно архитектура предприятия, а субъектом – некоторая специально создаваемая система поддержки архитектуры предприятия, центральной задачей которой является отслеживание текущего состояния архитектуры (для оценки состояния возможно использование совокупности показателей бизнес-процесса) для дальнейшей выдачи рекомендаций по возврату на желаемую траекторию.
К основным компонентам системы поддержки архитектуры предприятия следует отнести: блок бизнес-процессов, блок анализа бизнес-процессов, блок моделей и блок управленческих решений.
Блок бизнес-процессов представляет собой блок поддержки бизнес-процессов предприятия. Все бизнес-процессы предприятия должны быть задокументированы , и за каждым бизнес-процессом должны быть закреплены его владельцы.
Блок анализа бизнес-процессов предназначен для отслеживания динамики изменения. Каждый бизнес-процесс оценивается с точки зрения различных показателей, а также происходит мониторинг динамики изменения данных показателей. Мониторинг должен осуществляться отдельным подразделением в организации.
Блок моделей включает в себя блок прогноза и блок моделирования взаимного влияния бизнес-процессов.
Блок управленческих решений, по сути, представляет собой некоторую систему управления знаниями, в которой хранятся различные альтернативы развития архитектуры предприятия.
Обобщенный алгоритм представлен на рисунке.
3. Оценка эффективности бизнес-процессов
Центральным блоком системы является блок анализа бизнес-процессов. Анализ параметров работы современного предприятия является ключевым компонентом. Традиционная система финансовых показателей не может полностью описать существующую ситуацию в компании.
Телекоммуникационные компании как объекты управления характеризуются не только большим количеством составляющих элементов, но и многообразием функций, выполняемых этими элементами. Например, весьма специфичной задачей является управление качеством предоставления услуг. Другой особенностью компании связи является высокая технологичность и инновационность . Важной особенностью ИТ в телекоммуникациях является участие информационных технологий в создании добавленной стоимости. Если в большинстве отраслей ИТ рассматриваются сугубо как затратная часть технологической инфраструктуры, то в современной телекоммуникационной компании ИТ непосредственно участвуют в создании и предоставлении услуг.
рис.Обобщенный алгоритм работы системы поддержки архитектуры предприятия
Авторамипредлагаетсяввестиряд дополнительных специфическихпоказателей,отражающих особенности деятельности телекоммуникационной компании. В качестве таких показателейестественнорассмотреть (1)зонупокрытия (км² / %); (2)охват населения (чел. / %); (3) общую мощность передатчиков (Вт, кВт); (4) скорость передачи (мощность) радиорелейных линий (РРЛ) (Мбит/с); (5)количество ретранслируемых каналов; (6)времявещанияканалов (час); (7)количествоивысотумачтибашен, предназначенныхдляразмещенияпередатчиков (шт.,метров); (8)количество передатчиков,спутниковыхприемников; (9)протяженностьРРЛ; (10)количествочасовпростояпередатчиков (час).
Положительнуютенденциюразвитиякомпаниибудетхарактеризовать увеличение значений показателей (1) – (7) и уменьшение показателей (8) – (10).
Существенноеотличиеданныхпоказателейот традиционноиспользуемых выражается в том, что они измеряются в абсолютных единицах.
Заключение
Технологии, используемые в работе телекоммуникационной компании, меняются чрезвычайно динамично. Обновление услуг и технологий естественным образом влечет изменение компонентов управляющих информационных систем оператора, а также собственно бизнес-процессов. В данных условиях использование системы поддержки архитектуры предприятия дает возможность оценивать и в дальнейшем адаптировать сформированную архитектуру предприятия к меняющимся внешним условиям.
Литература
1. Архитектура предприятия: основные определения [Электронный ресурс] / Данилин А.В., Слюсаренко А.И. / – Интернет-университет информационных технологий. – Режим доступа: http://citforum.ru/consulting/articles/enterprise_arch/2.shtml.-Загл . с экрана.
2. Калянов Г.Н. Управление развитием информационных систем [Электронный ресурс] / Васильев Р.Б., Калянов Г.Н., Левочкина Г.А. – Интернет-университет информационных технологий. – Режим доступа: http://www.intuit.ru/department/itmngt/mandevisys. - Загл . с экрана.
3. Краснов С.В., Диязитдинова А.Р. Концепция системы поддержки архитектуры предприятия [Текст] // Вестник Волжского университета им. В.Н. Татищева №2 (19) 2012, с. 60 – 65.
4. Самуйлов К.Е. Бизнес-процессы и информационные технологии в управлении телекоммуникационными копаниями / К.Е. Самуйлов , А.В. Чукарин , Н.В.Яркина . – М.: Альпина Паблишерз , 2009. – 442 с.
Мы уже отмечали, что многие организации испытывают постоянные трудности и находятся в постоянном поиске синхронизации целей и задач бизнеса и процессов развития своих информационных систем. Существует как бы "облако неопределенности" между определением организацией и обеспечивающей ее ИТ-инфраструктурой своих целей и задач .
Процесс транслирования этих целей в конкретные ИТ-системы часто носит очень неразвитый характер и ограничивается ежегодным бюджетным процессом, участие в котором представителей бизнеса и ИТ является основным способом общения и взаимодействия.
Рис.
3.1.
"Облако неопределенности" между целями организации и информационными технологиями
Архитектура информационных технологий и архитектура предприятия в целом как раз и является основным механизмом интерпретации и реализации целей организации через адекватные ИТ-инфраструктуру и системы. Это достигается через создание определенного количества взаимосвязанных архитектурных представлений. Имеется множество методик описания архитектуры, и все они разбивают архитектуру предприятия на различное количество моделей и определений, которые относятся к таким областям, как бизнес, информация , прикладные системы, технологическая инфраструктура .
Бизнес-модели описывают стратегию организации, структуры управления, требования, ограничения и правила, а также основные бизнес-процессы , включая взаимосвязи и зависимости между ними. Т.е. бизнес- архитектура описывает на уровне предприятия в целом то, как реализуются основные функции организации, включая организационные и функциональные структуры, роли и ответственности.
Архитектура информации определяет ключевые активы , связанные со структурированной и неструктурированной информацией, требующейся для бизнеса, включая расположение, время, типы файлов и баз данных и других информационных хранилищ.
Архитектура прикладных систем описывает те системы, которые и обеспечивают необходимый функционал для реализации логики бизнес-процессов организации.
С точки зрения технологической архитектуры, важные модели включают описание ИТ-сервисов, которые требуются для реализации перечисленных выше трех других областей архитектуры. Причем логические модели ИТ-сервисов построены в абстрактной, технологически независимой форме и оставляют свободу для оптимального выбора конкретных технологий. Но, в конце концов, архитектура предприятия завершается физическими моделями, которые определяются технологиями, аппаратными и программными платформами, выбранными для реализации ИТ-сервисов.
Термин "ИТ- архитектура " может означать множество близких по смыслу, но, тем не менее, различающихся понятий. Для различных людей смысл одного и того же термина может быть разным. Каждый из нас, на самом деле, может достаточно быстро сформулировать интуитивное определение , которое после анализа окажется вполне применимым. Известных формальных определений архитектуры существует несколько сотен. Для этого достаточно зайти на сайт Института Проектирования Программного Обеспечения Карнеги-Меллона ( SEI – Carnegie Mellon Software Engeneering Institute) www.sei.cmu.edu . Одно из самых простых (словарь Уэбстера) заключается в том, что ИТ- архитектура – это "способ, который используется для организации и интеграции компонент компьютерной системы".
Более изощренное определение в хорошо знакомом программистам стиле заключается в том, что " Архитектура системы состоит из нескольких компонент , внешних свойств и интерфейсов, связей и накладываемых ограничений, а также архитектуры этих внутренних компонент ". Такое рекурсивное определение удобно тем, что является достаточно общим, применимым практически к любой системе, а не обязательно только к системе, использующей информационные технологии , и при этом позволяет ограничить степень детализации на нужном уровне. Отметим, что упоминание внутренних компонент специально перенесено в конец определения – для отражения того факта, что "хорошая" архитектура позволяет обеспечить повторное использование или модернизацию/замену таких внутренних компонент без изменения внешней охватывающей системы. Итеративное, иерархическое построение архитектуры позволяет решить и еще одну важную задачу – облегчить ее восприятие человеком.
Рис. 3.2.
Хорошо известно, что оптимальным в этом смысле числом элементов на отдельном уровне любой схемы абстракции или в каком-либо списке является всего 7 плюс или минус 2 объекта. Именно поэтому, как мы увидим ниже, большинство подходов к описанию архитектуры включает в себя ее разбиение на предметные области (или представления), общее количество которых как раз и находится в этом диапазоне. Примерами таких предметных областей являются архитектура прикладных систем, архитектура данных, технологическая архитектура и т.д. Старый, как мир, принцип "разделяй и властвуй" как нельзя лучше подходит для того, чтобы справляться с объективной сложностью корпоративных информационных систем. При этом такое разбиение позволяет рабочим группам, специализирующимся на различных предметных областях, работать параллельно, что делает проблему осознаваемой с интеллектуальной точки зрения.
Прежде чем давать, наконец, полное определение архитектуры ИТ, сделаем еще одно предварительное замечание. В соответствии с тезисом, сформулированным Giga
