Информационная архитектура - сочетание схем организации, предметизации и навигации, реализованных в информационной системе.
Информационная архитектур а дает целостное понимание существующей бизнес-среды и используется для решения текущих актуальных проблем бизнеса, обеспечивая в то же время инфраструктуру для проектирования новых бизнес-ориентированных решений. Она помогает свести к минимуму риск и поддерживает полноценное планирование любых ИТ-проектов.
Информационная архитектура охватывает различные контексты, в которых используется информация, такие как направления бизнеса и отдельные функции (финансы, продажи и маркетинг, бизнес-аналитика) и заключает в себе не только модель данных, но и метаданные, необходимые для поддержки всех оперативных систем и внутренних сервисов, таких как хранилище данных. Информационная архитектура помогает увидеть данные и образ их использования так, чтобы преобразовать их в полезную информацию; ее применение позволяет обеспечить гибкость и расширяемость интегрированного решения, а также его способность адекватно реагировать на изменения потребностей бизнеса.
Информационная архитектура используется для оценки эффективности ИТ-проектов, а также проверки спроектированных решений на предмет полноты удовлетворения как текущих нужд, так и перспективных потребностей. Она применяется для испытания сценариев бизнес-процессов и определения того, позволяют ли они удовлетворить более широкие потребности бизнеса, такие как анализ и отчетность.
Основные составляющие информационной архитектуры следующие:
Бизнес-модель, включающая различные представления организационной структуры, заинтересованных сторон, их интересов и мотивации, а также описание бизнес-процессов и выполняемых функций;
Информационная модель, в которую входят информационные объекты («сущности»), описывающие их метаданные, таксономии классификаций объектов, а также онтологии для соответствующих информационных объектов;
Методология для извлечения, анализа и сохранения характеристик бизнес- и информационных объектов;
Инструменты, такие как репозиторий, в который помещаются все артефакты и знания, создаваемые в ходе построения архитектуры, в том числе описания бизнес-объектов, объектов данных,
Информационная архитектура предоставляет базис для сопоставления потребностей и ожиданий бизнеса, требований к процессам и используемой в них информации таким способом, который позволит объединить разрозненные области бизнес- информации и организационные уровни на предприятии. Информационные концепты, смоделированные без привязки к направлениям бизнеса, приложениям, бизнес-процессам, функциям и департаментам, обеспечивают гибкость связывания организационных данных и метаданных, использования объектов и учета их происхождения. Создание пригодных для многократного использования в различных функциональных областях моделей этих информационных объектов позволяет проектировать и создавать легко взаимодействующие друг с другом приложения обработки данных, органично связанные с лежащими в их основе информационными моделями.
34.Основные характеристики модели «клиент-сервер». Ограничения модели
Клиент-сервер -- это модель взаимодействия процессов в вычислительной системе, при которой один процесс (клиент) делает запрос, другой процесс (сервер) его обрабатывает и возвращает первому ответ или предоставляет определенную услугу в виде вычислений, каких-либо данных и т.п. Это вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами. Физически клиент и сервер - это программное обеспечение. Обычно они взаимодействуют через компьютерную сеть посредством сетевых протоколов и находятся на разных вычислительных машинах, но могут выполняться также и на одной машине. Программы - сервера, ожидают от клиентских программ запросы и предоставляют им свои ресурсы в виде данных (например, загрузка файловпосредством HTTP, FTP, BitTorrent, потоковое мультимедиа или работа с базами данных) или сервисных функций (например, работа с электронной почтой, общение посредством систем мгновенного обмена сообщениями, просмотр web-страниц во всемирной паутине).
Основной принцип технологии "клиент-сервер" заключается в разделении функций приложения на группы. Программы имеют распределенный характер, т.е. одна часть функций прикладной программы реализуется в программе-клиенте, а другая - в программе-сервере, а для их взаимодействия определяется некоторый протокол.
Рассмотрим эти функции:
Функции ввода и отображения данных.
Прикладные функции, характерные для данной предметной области (для банковской системы - открытие счета, перевод денег и т.д.).
Функции хранения и управления информационно-вычислительными ресурсами (базами данных, файловыми системами и т.д.).
Служебные функции, осуществляющие связь между функциями первых трех групп.
Лекция 2. Информационная система как компонент эффективной системы управления организации
Современные ИС рассматриваются как эффективный инструмент в конкурентной борьбе предприятия. В связи с этим ИС призваны быстро адаптироваться к новым потребностям бизнеса (его целям и задачам) и полностью соответствовать архитектуре предприятия (Enterprise Architecture – EA).
Многие из аналитиков крупных компаний (например, Клиф Финкельштейн) считают, что в настоящее время большинство из них просто перешли от состояния ручного хаоса к состоянию хаоса автоматизированного. Соответственно, практически любые крупные организации требуют структуризации и документирования как бизнес-процессов, так и обеспечивающих их информационных систем.
Организациярассматривается как стабильная формальная социальная структура, которая получает ресурсы из окружающего мира и перерабатывает их в продукты своей деятельности. Организации обладают как рядом общих черт, присущих им всем, так и многими индивидуальными особенностями.
Различают следующие способы описания организации:
· путем задания структуры (структурная модель);
· путем описания состояний (статика и динамика, состояние организации–набор показателей)
· с помощью описания оператора (функциональная модель).
При анализе эффективности использования корпоративной ИС на предприятии достаточно часто возникает вопрос о необходимости соответствия ее архитектуры архитектуре самого предприятия. Внедрение информационных систем на предприятии является сложным трудоемким процессом. Вместе с тем многие организации тратят большие денежные средства на внедрение различных информационных систем без анализа общей концепции развития предприятия. Построение комплексной информационной системы современного предприятия можно сравнить по сложности с проектированием города, где информационные системы соответствуют зданиям. Информационные системы, как и отдельные здания, требуют поддержки и правильной эксплуатации, ремонта и модернизации. Но жизненный цикл информационной системы существенно короче жизненного цикла здания.
Поэтому при проектировании корпоративной ИС необходимо представлять метамодель организации. Метамодель организации - это наиболее общее и всестороннее представление ее как единой системы, имеющей краткосрочные и долгосрочные цели ведения деятельности, определенные миссией и стратегией, обладающей внешними и внутренними ресурсами, необходимыми для выполнения миссии и достижения поставленных целей, а также сложившимися правилами осуществления деятельности - способами реализации бизнес-процессов и бизнес-функций.
Задание метамодели организации означает определение ее архитектуры и инфраструктуры .
Архитектура организации (EA - Enterprise Architecture) – некоторая концепция (логическое построение), определяющая, что и как она делает (миссия, цели, стратегия, основные функции), на какие части она распадается (свойства элементов), где они размещены (структура организации) и как эти части и на каких принципах взаимодействуют (взаимосвязь компонентов). Архитектура организации, как описание организации высшего для нее уровня, содержит в себе понятия более низкого уровня - архитектуры функциональных и структурных частей организации.
Архитектура предприятия определяет общую структуру и функции подсистем (бизнес и ИТ) в рамках всей организации в целом (включая партнеров и другие организации, формирующие так называемое «предприятие реального времени»), обеспечивает общую рамочную модель (framework), стандарты и руководства для архитектуры уровня отдельных проектов. Общее видение, обеспечиваемое архитектурой предприятия, создает возможность единого проектирования систем, адекватных, с точки зрения обеспечения целей организации , и способных к взаимодействию и интеграции там, где это необходимо.
Для построения архитектуры организации необходима определенная инфраструктура организации – комплекс взаимосвязанных обслуживающих структур, составляющих и/или обеспечивающих основу для решения некоторой проблемы или задачи, т.е. инфраструктура - это набор средств реализации архитектуры. Выбор определенной архитектуры организации предопределяет необходимую для этого инфраструктуру. Для понятия «инфраструктура» также как и для понятия «архитектура» характерно содержание описания инфраструктур нижнего уровня иерархии и инфраструктур функциональной нацеленности
В соответствии со стандартом ANSI/IEEE 1471 архитектура организации рассматривается, как «фундаментальная организация системы , состоящая из совокупности компонент, их связей между собой и внешней средой, и принципы, которыми руководствуются при их создании и развитии».
Архитектура организации имеет две составляющие, которые описывают деятельность компании с двух основных позиций (Рис. 1.8):
· бизнес-архитектура описывает бизнес-правила и взаимодействие бизнес-процессов, структуру и потоки необходимой информации;
· архитектура информационных технологий описывает предприятие с позиции технических понятий, таких как аппаратные и компьютерные средства, программное обеспечение, защита и безопасность.
Рис. 1.8 Взаимосвязь архитектур бизнеса и ИС
Формализация архитектуры информационных систем предприятия обеспечивает уменьшение их уровня сложности и упрощает интеграцию. Оптимизация бизнес-процессов компании и оптимизация функциональности информационных систем, используемых для автоматизации бизнес-процессов, увеличивает приток инвестиций в информационные технологии. Архитектура предприятия в первую очередь объединяет архитектуры информационных технологий и бизнеса, обеспечивая системный подход к вопросам управления предприятием
Архитектура предприятия является связующим звеном между информационными системами и потребностями бизнеса предприятия для чего объединяет в себе процессы стратегического бизнес-планирования, прикладные информационные системы и процессы их сопровождения.
При этом архитектура предприятия неразрывно связана с основными рабочими процессами:
· стратегия и планирование на уровне предприятия;
· управление корпоративными проектами.
При разработке стратегии предприятия (Strategy and Planning) и в процессе управления корпоративными проектами (Enterprise program management) в настоящее время принято учитывать направление, непосредственно связанное с информационными технологиями. Современный менеджмент рассматривает ИТ-проекты и стратегические инициативы в области ИТ как определенный актив компании, которым можно управлять.
Специалисты компании META Group считают, что Business and IT portfolio management включает в себя управление портфелем информационных технологий, которое рассматривается, как процесс управления инвестициями в области управления ИТ-проектами. Под портфелем понимается совокупность проектов, выполняемых на общем пуле ресурсов (финансы, люди, оборудование, материалы, энергия). При этом пул ресурсов и результаты всех проектов портфеля находятся в компетенции одного центра ответственности – область пересечения архитектуры предприятия, стратегии предприятия и управления корпоративными проектами (Рис. 1.9). Стратегия и планирование при этом обеспечивают основу для выработки ИТ-стратегии предприятия, в соответствии с которыми появляются проекты внедрения (модернизации) информационных систем. Управление проектами – можно рассматривать, в первую очередь, как механизм, обеспечивающий переход от текущего состояния предприятия к планируемому, или, другими словами, переход от текущей архитектуры предприятия к целевой архитектуре.
Рис. 1.9 Управление портфелем информационных технологий
Представление информационных технологий в виде активов компании, позволяет корректно оценивать и расставлять приоритеты при вложении инвестиций и управлении ИТ-проектами (активами) с учетом приемлемого уровня риска, и, таким образом планировать инвестиции в эту область. Считается, что управление ИТ-портфелем должно преследовать три основные цели:
· максимизация эффективности ИТ-портфеля;
· синхронизация ИТ-портфеля с требованиями бизнеса;
· поиск оптимального баланса между риском и потенциальной отдачей от ИТ-портфеля.
Архитектура предприятия является одним из элементов управления ИТ-портфелем. Архитектура предприятия позволяет увидеть весь комплекс видов деятельности предприятия в целом, создает многоуровневые связи (стратегический уровень, структурный уровень, операционный уровень), отражающие воздействие отдельных элементов стратегии развития предприятия на его бизнес-процессы (Рис. 1.10), и их зависимость от информационных систем и технологических элементов. Она предоставляет необходимую информацию о бизнес-процессах и технологиях, необходимых для создания на предприятии эффективной информационной системы. Архитектура предприятия не только является основой для формирования портфеля активов, но также обеспечивает весь жизненный цикл многих ИТ-активов.
Рис. 1.10. Управление предприятием
В соответствии со структурой системы управления предприятием выделяют уровни абстракции архитектуры предприятия. На каждом из них существует единый набор моделей, принципов, руководства и, которые используются для создания и развития систем в контексте деятельности всего предприятия в целом. Можно выделить следующие три уровня абстракции (Рис. 1.11) 7: уровень архитектуры предприятия; уровень архитектуры отдельных решений; прикладной уровень (дизайн и разработка решений).
Рис. 1.11. Уровни абстракции архитектуры предприятия в контексте его видов деятельности
Уровень архитектуры предприятия – описывает элементы архитектуры стратегического уровня, ориентированные на создание общей концепции развития в масштабах всего предприятия в целом. На этом уровне рассматриваются основные цели и задачи предприятия, стратегия его развития, на основе которых разрабатывается ИТ-стратегия и ИТ-архитектура предприятия (формирование стратегии или предварительное планирование) . Здесь определяется общая структура информационных систем в рамках всей организации, в целом, и выделяются их основные функции.
Уровень архитектуры предприятия – это в первую очередь общая схема функционирования всего предприятия в целом, открывающая возможность проектирования всего комплекса информационных систем, обеспечивающих потребности предприятия, и их эффективную интеграцию. Построение такой схемы позволяет не только показать, какие именно бизнес-процессы, и информационные системы обеспечивают достижение основных целей предприятия, но и избежать их дублирования, повысить эффективность совместной работы.
Уровень отдельных решений – соответствует структурному уровню управления и определяет структуру и функции отдельных проектов. На этом уровне, формируется детализированная информация о приложениях, бизнес-процессах и их взаимосвязях. Здесь определяется структура информационных систем, их интерфейсы и функции. Определяются планы и схемы их развития, разрабатывается соглашение об уровне обслуживания (SLA).
Архитектура уровня отдельных проектов оценивает проект внедрения новых элементов информационной системы предприятия: как новые информационные системы будут вписываться в контекст всего предприятия, с кем они будут взаимодействовать и какие технологии использовать.
Прикладной уровень , включающий в себя дизайн отдельного решения и его архитектуру, планы реализации проектов. На этом уровне происходит работа уже непосредственно с информационными системами. Определяется структура и функции отдельных приложений, которые разрабатываются с целью обеспечения конкретной функциональности. Здесь происходит реализация стандартов и руководств, определенных на верхних уровнях.
Информационная система, на данном уровне рассматривается как сложный комплексный объект, динамически изменяющийся во времени. Конкретная реализация системы включает в себя приложения, базы данных и их реальное размещение, архитектуру, фактические потоки данных и реализацию процессов управления.
Количество уровней абстракции и их тип могут изменяться в зависимости от поставленных задач. Использование уровней абстракции позволяет осуществлять декомпозицию предприятия на отдельные подсистемы и элементы с последующим их анализом. Концепция разделения архитектуры предприятия на различные уровни абстракции помогает менеджерам принимать обоснованные управленческие решения на основе анализа влияния планируемых изменений на предприятие в целом.
При внесении изменений в архитектуру предприятия используют различные уровни абстракции. Это связано с тем, что каждый уровень абстракции использует свои модели, описывающие определенные предметные области. Например, при внедрении информационных технологий на предприятии принято выделять следующие уровни абстракции:
· уровень контекста (почему?) ориентирован в первую очередь на руководство и обосновывает необходимость проектов;
· концептуальный уровень (что?) определяет общие требования к проекту и возможные варианты его реализации;
· логический уровень (как?) описывает способ реализации данного проекта;
· физический уровень определяет решения, стандарты и технологии, позволяющие реализовать проект
Таким образом, можно говорить, архитектура предприятия является инструментом управления, обеспечивающим процесс принятия решений об инвестициях в информационные технологии, стирающим грань между управлением бизнесом и ИТ-подразделением.
Традиционно считалось, что новые инициативы по внедрению информационных технологий должны отражать требования бизнеса, и новые информационные системы должны создаваться в соответствии с этими требованиями. Однако на современном этапе развития общества бизнес должен не только формировать свои требования к ИС, но и адекватно реагировать на «сигналы» ИТ-подразделений, которые открывают предприятиям новые возможности повышения конкурентоспособности вследствие использования достижений научно-технического прогресса в области информационных систем и технологий. Таким образом, архитектуру предприятия можно рассматривать как инструмент инновационного развития организационных принципов построения деятельности предприятия, обеспечивающий его эффективное функционирование (Рис. 1.12).
Рис. 1.12. Эволюция организационных принципов управления предприятием
С точки зрения развития предприятия принято рассматривать две составляющие его архитектуры:
· целевую архитектуру (Target Architecture) – отражает план развития архитектуры предприятия («To be»);
· текущая архитектура (Current architecture) – описывает текущее состояние архитектуры предприятия («As is»).
Текущая архитектура отражает объективную реальность, существующую на предприятии в данный момент времени, и включает в себя соответствующие компоненты (бизнес-процессы, информационные системы, технологические элементы) и их связи. Это набор моделей с неизбежными упрощениями, ограничениями, отражающими субъективизм менеджеров.
Основу разработки текущей архитектуры составляет процесс документирования и поддержания информации о состоянии предприятия в актуальном виде, обеспечивающий регистрацию и контроль информации обо всех элементах архитектуры предприятия, включающий в себя ведение базы данных по архитектурным объектам, ведение управленческого учета и учета состояния.
Процесс разработки текущей архитектуры аналогичен процессу ITIL/ITSM (управление конфигурацией - Configuration Management). Для упрощения работы по разработке текущей архитектуры многие компании используют базу данных конфигурационных единиц (CMDB), дополнив ее необходимой информацией. Процесс разработки текущей архитектуры аналогичен процессу, реализованному в концепции ITIL/ITSM (концепция управления ИТ-подразделением предприятия).
Целевая архитектура - описывает желаемое будущее состояние предприятия или "что должно быть сформировано", то есть – целевая архитектура является перспективной (идеальной) моделью предприятия.
Основу целевой архитектуры составляют:
· стратегические требования к бизнес-процессам и информационным технологиям;
· информация о выявленных «узких местах» и путях их устранения;
· анализ технологических тенденций и среды деятельности бизнеса предприятия.
Целевая архитектура (модель «Тo be») и текущая архитектура (модель «Аs is») описывают начальное и конечное состояние предприятия (до и после внесения изменений в его инфраструктуру). При этом сам процесс изменений не рассматривается. Смена текущей архитектуры предприятия на целевую означает перевод предприятия на новый этап развития. Следовательно, архитектура предприятия характеризуется определенным жизненным циклом, связанным, в некоторой степени, с жизненным циклом информационных систем.
Современные подходы к построению архитектуры предприятия традиционно разделяют ее на несколько предметных областей (слоев). Количество предметных областей зависит от используемых методик. Рассмотрим предметные области, использующиеся в большинстве из существующих методик (Рис. 1.13):
· стратегические цели и задачи предприятия;
· бизнес-архитектура предприятия;
· архитектура информационных технологий (ИТ архитектура предприятия).
Рис. 1.13. Предметные области архитектуры предприятия
Архитектуру ИТ, в свою очередь, разделяют на:
· информационную архитектуру (Enterprise Information Architecture);
· архитектуру прикладных решений (Enterprise Solution Architecture);
· технологическую архитектуру (Enterprise Technical Architecture).
Построение архитектуры предприятия
Не надо питать иллюзий насчет того, что работа архитектора заканчивает-ся строительством видения великолепной архитектуры предприятия. Архитек-тура информационных технологий - это только на 10% видение, а на 90%- кропотливая работа по реализации.
Реализация архитектуры предприятия не является проектом в строгом смысле этого слова. Дело в том, что за фазой разработки неизбежно должна по-следовать деятельность по поддержанию и постоянному развитию архитектуры предприятия, а это более удобно описывать в рамках процессной модели. Одна-ко на практике часто встречаются следующие два случая, когда целесообразно организовать выполнение специального архитектурного проекта.
С учетом существующего реального состояния дел большинство организаций либо не имеют формализованной определенной архи-тектуры, либо эти определения неполны и недостаточно четко связаны с требова-ниями бизнеса. В таких случаях имеет смысл организовать работу в рамках специ-ального проекта с определенными сроками и результатами, основной целью кото-рого будет являться создание первоначального описания архитектуры организа-ции и создание механизмов для ее последующего поддержания и развития.
Первоочередными задачами такого проекта являются:
· организация необходимых структур с привлечением руководства предпри-ятия, бизнес-подразделений и планирование работ;
· понимание стратегии развития бизнеса организации;
· формирование общих для бизнеса и ИТ требований к целевой архитектуре;
· разработка концептуальной архитектуры в виде согласованного и полного набора принципов, в соответствии с которыми будет проводиться разра-ботка архитектуры отдельных доменов (предметных областей или частных архитектур).
Для многих организаций отправной точкой в создании общей архитектуры предприятия может стать существующая ИТ-архитектура.
Другим возможным вариантом выделения такой деятельности в отдельный проект может явиться потребность в проведении эволюционного скачка в архи-тектуре. Например, открытие нового бизнес-направления или внедрение новой ERR-системы потребует значительных изменений в вычислительной и сетевой инфраструктуре, реорганизации ИТ-службы и т.п. Возможностей существующей группы поддержки архитектурного процесса окажется недостаточна для реше-ния таких задач, и потребуется привлечение дополнительных внутренних и внешних ресурсов, что опять-таки удобнее выполнять в рамках четка опреде-ленного проекта.
Какую бы архитектурную методику вы ни выбрали, при всех расхождениях в деталях проект работы над созданием архитектуры обычно включает решение следующих задач:
· Определение и обоснование цели - ответы на вопросы Почему? и Что?
· Выполнение ряда шагов, связанных с инициацией процесса разработки ар-хитектуры (см. ниже).
· Определение существующего состояния архитектуры («as-is») для каждой выбранной области (домена) - отправная точка ответа на вопрос где?
· Определение целевой архитектуры - конечная точка ответа на вопрос где ?
· Анализ расхождений между текущим и желаемым состоянием.
· Разработка плана перехода - ответы на вопросы Когда? и Как?
· Подтверждение (проверка) достижимости - можно ли на самом деле до-стичь конечного состояния из данного начального состояния с учетом су-ществующих ограничений?
· Выполнение намеченного плана.
Здесь стоит особенно отметить важность усилий для решения третьей за-дачи. С одной стороны, формирование целостного описания существующей ар-хитектуры может потребовать проведения настоящих «археологических раско-пок» в ранее существовавшей документации, изучения существующих преданий и посвящения в «тайные знания» о годами работающих системах. С другой сто-роны, здесь важно определить набор целевых метрик (надежность, стоимость эксплуатации и т.п.) и их начальных значений - иначе потом будет очень труд-но объективно оценить, достигнуты ли цели проекта.
Начальные действия по инициации самого проекта разработки архитекту-ры включают следующие шаги:
· определение «устава» (основных правил) и границ проекта;
· бизнес-обоснование реализации проекта разработки архитектуры пред-приятия;
· получение поддержки высшего руководства;
· определение состава рабочей группы (организационная структура и уча-стники);
· проведение рабочей встречи, посвященной началу проекта разработки архитектуры и определения других высокоуровневых документов, которые необходимы для более детальных работ по разработке архитектуры;
· создание рабочих групп, которые будут разрабатывать различные фокусные области или домены в рамках общего проекта (например, бизнес-архитек-тура, архитектура информации, прикладных систем, инфраструктуры).
Высокоуровневые документы, которые должны быть результатом первооче-редных шагов, являются ключевыми для дальнейшей, более детальной проработ-ки архитектуры. Они создают некоторый культурный контекст всех усилий и обес-печивают связь работы по созданию архитектуры с бизнес-стратегиями и приори-тетами предприятия. Список этих высокоуровневых документов может включать:
· бизнес-факторы, влияющие на деятельность предприятия;
· внутренние и внешние технологические факторы;
· формулировку общего видения Архитектуры предприятия;
· высокоуровневые принципы.
Важной составляющей всего проекта является создание структур управле-ния и контроля архитектурного процесса (governance), который должен обеспе-чить то, что сообщество специалистов на практике использует результаты этих работ; вторая серьезная задача - обеспечение связей процесса разработки ар-хитектуры с процессами бизнес-планирования и выработки ИТ-стратегии.
Общая блок-схема процесса в итоге выглядит, как показано на рис. 1.7.
Рис. 1.7. Общая схема построения архитектуры предприятия
В принципе, существуют три возможных подхода к организации процесса разработки архитектуры:
· Традиционный обычный подход. Он требует существенных начальных за-трат времени и ресурсов для достижения первых ощутимых результатов. В этом подходе в первую очередь разрабатывается регламент для будущего описания архитектуры. Затем должно быть определено текущее базовое состояние архитектуры и только после этого представлена целевая архи-тектура. Лишь когда все зги действия закончены, начинается детальное проектирование и разработка необходимой Архитектуры предприятия.
· Сегментный подход. Суть этого подхода состоит в постепенной поступа-тельной разработке сегментов архитектуры в рамках общей структуры, описывающей принципы Архитектуры ИТ. Этот подход сосредоточивается на главных бизнес-сферах и областях архитектуры и имеет больше шансов на успех, поскольку усилия ограничены пределами общих выполняемых функций, а также сфер специфической деятельности предприятия.
· Подход статус-кво или «оставить все как есть». Результатом этого будут провалы в попытках наладить информационный обмен, невозможность реакции на быстроменяющееся окружение. Этот подход также означает постоянную переделку бизнес-функций, снижение производительности, потерянные или упущенные возможности.
Традиционный, обычный подход при всей кажущейся его правильности связан с риском «паралича анализа», который особенно неконструктивен в рос-сийских условиях переходной экономики и процессов реформирования госу-дарства. Чтобы сократить возможные риски неудач, обеспечить снижение на-чальных затрат и добиться быстрой отдачи от проекта разработки Архитектуры ИТ, рекомендуется второй, т.е. сегментный подход.
Один из признанных авторитетов в области корпоративной архитектуры Стивен Спивак (Steven Spewak) предложил удачную модель планирования Ар-хитектуры предприятия, которая называется ЕАР (Entrerprise Architecture Planning - Планирование архитектуры предприятия). Модель EAP соответствует описанному нами выше принципу сегментного подхода к разработке архи-тектуры и включает 7 шагов, определяющих эту архитектуру и соответствующий план ее реализации (миграции). Эти 7 компонент, условно изображенных на рис. 1.8 в виде «свадебного торта», обозначают смещение фокуса приложе-ния сил на каждом из шагов.
Рис. 1.8. Методика Спивака
Подход Спивака уже помог очень многим компаниям и государственным ведомствам в организации процесса моделирования, стратегического бизнес-планирования, реорганизации деловых процессов, проектировании различных систем, выработки стандартов на данные, управления проектами. В частности, этой методикой пользовались такие организации, как Federal Express, Министер-ство энергетики США, Штаб Военно-воздушных сил США и другие. Например, в Министерстве энергетики США основная фаза процесса разработки архитектуры («проект») заняла примерно б месяцев.
Методика ЕАР обеспечивает высокоуровневый взгляд на предприятие с точки зрения его бизнес-функций и требований в области информации. Это ин-струмент планирования, а не детального проектирования архитектуры. Резуль-таты планирования используются в качестве основы для интегрированной раз-работки прикладных систем и технологий, которые обеспечивают потребности бизнеса. Отличительными характеристиками этого подхода к планированию ар-хитектуры являются следующие:
· в основе - потребности бизнеса, а не технологические факторы;
· основное внимание сосредоточено более на данных и потребностях в ин-формации, чем на процессах;
· ответственность за процесс в большей степени несут представители биз-нес-подразделений,чем специалисты по ИТ.
Если «наложить» методику ЕАР Спивака на модель архитектуры Захмана (см. пункт 2.2),то можно сказать, что методика ЕАР является руководством по заполнению первых двух строк таблицы Захмана, которые описывают контекст архитектуры и концептуальную модель бизнеса предприятия, т.е. зто перспекти-вы, соответствующие представлениям об архитектуре бизнес-руководителей: «планировщика» и «владельца». Проектирование систем, которое начинается с третьей строки таблицы Захмана, остается за рамками методики Спивака.
Это замечание ничуть не умаляет достоинств методики Спивака, но ниже мы рассмотрим более подробно и остальные элементы архитектурного процесса.
Какое бы определение Архитектуры предприятия мы, в конечном итоге, ни выбрали, общими для всех методик описания архитектуры является системати-ческое и рекурсивное применение таких принципов, как:
· декомпозиция на различные представления архитектуры (предметные об-ласти): область прикладных систем, технологическая архитектура и т.д.;
· различные уровни детализации и абстракции для описания каждой из этих областей.
Схема процесса разработки в самом общем виде представлена на рис. 1.9. Об-ратим внимание на то, что фактически здесь идет речь о параллельных активностях по определению как целевой архитектуры, так и стратегии ее достижения. 
Рис. 1.9. Общая схема процесса разработки архитектуры
Эта схема состоит из следующих шагов:
· Общим фоном для этого процесса является мониторинг существующих тен-денций в области деятельности организации и тенденций в области разви-тия информационных технологий.
· Анализ на бизнес-уровне. На первом этапе проводится анализ движущих сил, которые влияют на необходимость использования ИТ с точки зрения основных функций и бизнеса организации. Определяются требования биз-неса и технологии на текущем этапе и на перспективу, которые задают тре-бования к информационным системам. Учитываются тенденции в развитии информационных технологий и мировых аналогов с учетом перспектив развития бизнеса.
· На основе этого анализа формулируются в самом общем виде требования к информационным технологиям с точки зрения информации (данных) и архитектуры ИТ.
· Принимаются общие для организации стандарты и понятия о том, что такое архитектура предприятия: принципы, общие методы описания архитекту-ры и ее разделы, стандарты, конкретные продукты и технологии.
Параллельно с этими процессами выполняется анализ на «системном уровне»: аудит используемых информационных технологий и программно-технических средств, аудит организации процессов управления ИТ, внед-рения технологий и приложений.
Результаты вышеперечисленных этапов являются основой для выполнения «GAP-анализа», т.е. выявления расхождений и различий между существу-ющей ИТ-инфраструктурой и желаемой архитектурой предприятия. Результаты Gap-анализа ложатся в основу Плана миграции: определяются цели создания (модернизации) информационных систем и решаемых ими задач, согласовывается стратегия разработки и внедрения информацион-ных технологий (перечень критических процессов, подлежащих автомати-зации в первую очередь и т. д.), обсуждается план детального анализа.
После этого начинается фаза реорганизации конкретных проектов в рамках выработанной на данный момент архитектуры предприятия.
С практической точки зрения, реализация инициативы в области разработ-ки архитектуры предприятия разделяется на несколько фаз или этапов. На каж-дом этапе готовится совершенно определенный набор документов и иных мате-риалов, которые создают основу архитектуры и которые позволяют предъявлять видимые результаты деятельности рабочей группы, ответственной за всю иници-ативу разработки архитектуры в целом.
Основой работы на этих этапах является эволюционный, итеративный про-цесс, связанный с определением и описанием текущего и желаемого состояния архитектуры, совмещенный с процессом анализа результатов, идентификацией направлений и планов развития ((GAP-анализ), который обеспечит синхрониза-цию архитектуры с изменениями в функциях подразделений, с изменениями в бизнес-требованиях и изменениями в технологиях.
Архитектура, в результате, является одновременно как постоянным организационным процессом, так и результатом,который мате-риализуется в форме моделей и документов, описывающих существующее и бу-дущее состояние архитектуры.
Разработка архитектуры является сложным процессом, который обеспечи-вает движение от описания общего положения с имеющимися информационны-ми системами и инфраструктурой к практической реализации информационных систем, их эксплуатации и оценке результатов. Процесс носит нелинейный, цик-лический характер, и было бы ошибкой считать, что разработка архитектуры- это одноразовая кампания, которая обеспечивает простое перемещение инфор-мационных систем предприятия из состояния «А» в состояние «Б». Архитектура - это постоянный процесс, который нацелен на обеспечение постоянных улуч-шений в той области, которая связана с отдачей от использования информаци-онных технологий для реализации бизнес-функций предприятия и его соответ-ствующих подразделений.
Процесс разработки и обновления архитектуры должен идти параллельно и одновременно с практической реализацией информационных систем пред-приятия. Это два взаимосвязанных процесса, которые, однако, имеют различные «скоростные характеристики». Архитектурный процесс по своей природе является концептуальным, имеетдлительный временной горизонт, в та время как реали-зация систем ориентирована на внедрение конкретных решений и реализацию проектов с более коротким временным горизонтом.
Архитектура задает цели для отдельных проектов и инициатив, но важна и обратная связь: систематический анализ опыта реализации отдельных проектов и систем является неотъемлемой частью всего процесса планирования и разра-ботки архитектуры.
Ниже описаны этапы каждой итерации процесса разработки и обновления архитектуры, которые следуют, в основном, рекомендациям МЕТА Group. Харак-терными для этого подхода элементами описания архитектуры являются такие документы, как Общее видение и Концептуальная архитектура. Заметим, что, да-же в случае выбора какой-то другой методики, скорее всего придется созда-вать аналоги этих документов. Каждая итерация включает:
· Этап 1: Описание или уточнение Общего видения (видение общих требова-ний к архитектуре).
· Этап 2: Описание или уточнение Концептуальной архитектуры, а также разработка и уточнение архитектуры отдельных представлений (или предметных областей, доменов): бизнес-архитектура, архитектура инфор-мации, архитектура приложений, технологическая архитектура и пр.
· Этап 3: Разработка или уточнение Плана реализации.
При первой итерации этого процесса разрабатываются только те пред-ставления (view) архитектуры (предметные области, или домены, архитектуры), которые идентифицированы как наиболее приоритетные (2-3 области). Напри-мер, если будет принято решение, что наиболее острой проблемой является ин-вентаризация существующих на предприятии прикладных систем и составление плана изменения их портфеля (вывод из эксплуатации ряда прикладных систем, обновление или разработка новых), то такая область, как Архитектура прикладных систем,должна разрабатываться в приоритетном порядке.
После завершения всех трех этапов первой итерации рабочая группа, от-вечающая за разработку архитектуры, продолжает разработку архитектур ос-тальных доменов (предметных областей), не проработанных ранее, с учетом на-копленного опыта и информации на предыдущих итерациях.
Итого пересматривая состав этапов можно заметить следующее:
Этап 1: Разработка Общего видения архитектуры
Общее видение обеспечивает единое понимание проблемы между функци-ональным (бизнес-) руководством и людьми, отвечающими за информационн--коммуникационные технологии. Оно задает контекст для всей последующей разработки элементов архитектуры.
Основными элементами Общего видения являются:
· описание технологических тенденций, важных для предприятия;
· идентификация бизнес-требований и стратегий;
· идентификация основных требований к информации и технологиям, кото-рые важны с точки зрения реализации бизнес-стратегий;
· идентификация требований к Архитектуре предприятия в целом.
Контекст и основные элементы бизнес-архитектуры
Большинство организаций имеют достаточно широкие определения того, что является бизнес-архитектурой и бизнес-моделями. Бизнес-архитектура является областью, которая определяется высшими руководителями, отвечающими за основные функции (бизнес) организации . Как правило, она включает в себя утверждения по поводу миссии и целей организации, критические факторы успеха, бизнес-стратегии, описания функций, а также структуры и процессы, необходимые для реализации функций.
По оценке Gartner, вплоть до конца 2005 года около 70% всех предприятий будут вести определенные проекты, связанные с анализом и совершенствованием бизнес-процессов, несмотря на некоторый негативный осадок, который в корпоративном мире имела практика реинжиниринга бизнес-процессов середины 1990-х годов. "На самом деле, большинство предприятий в действительности не понимают всей глубины и масштабов выполняемых ими бизнес-процессов, если они не занимались бизнес-моделированием в последнее время", – считает Джим Синур (Jim Sinur), аналитик Gartner.
Ключом к построению хорошей бизнес-архитектуры является определение бизнес-процессов, их функций и характеристик. Это становится основой для построения архитектуры приложений, которые обеспечивают эти процессы. Хотелось бы в связи с этим привести следующую цитату из книги Unleashing the Killer App "Вы тогда достигаете цели, когда становится невозможно определить, где заканчиваются бизнес-аспекты, и где начинаются технологии".
Таким образом, можно сказать, что Бизнес-архитектура включает в себя, как правило, следующие аспекты:
- Бизнес-стратегия, функции и организационные структуры – собрание целевых установок, планов и структур организации. Данная информация может быть представлена в самых разных форматах, но наиболее важный аспект состоит в создании контекста для описания бизнес-процессов. Эта часть архитектуры не является технической, но она критически важна с той точки зрения, что архитектура информационных технологий (информации, прикладных систем, технологическая архитектура) строится на ее основе и обеспечивает реализацию ключевых функций организации.
- Архитектура бизнес-процессов, которая определяет основные функциональные области организации. Для министерства – это могут быть функции, перечисленные в Положении о министерстве, для коммерческой организации – процессы разработки новых продуктов, услуг и сбыта товаров и т.п. Она также описывает специфические процессы внутри каждой функциональной области и их операционные параметры – например, объемы операций, роли, реализацию централизованной или децентрализованной модели операций и т.д. Эта часть является как бы "точкой соприкосновения" между бизнес-архитектурой и архитектурой приложений и обеспечивает взгляд на бизнес и функции организации, достаточно детализированный для того, чтобы использовать его при выработке стратегии и планов создания приложений.
- Показатели эффективности. Этот аспект состоит в определении ключевых показателей эффективности (КПЭ) работы организации, их текущих уровней и желаемых, будущих уровней и включает в себя также разработку на верхнем уровне модели КПЭ для мониторинга.
"Если архитектура ИТ предприятия описывает то, как компоненты ИТ объединяются вместе для достижения нужного результата, то точно также бизнес-архитектура описывает, как элементы бизнеса соединены вместе" .
Построение бизнес-архитектуры начинается с общего обзора ситуации, который предполагает поиск ответов на следующие вопросы:
- Каков внешний контекст деятельности организации?
- В чем состоят основные функции и добавочная стоимость, которая является итогом деятельности организации?
- Какие сценарии развития бизнеса необходимо учитывать, и какова вероятность их реализации?
- Какие необходимы информационные взаимосвязи и процессы обработки информации?
Рис.
5.7.
Усилия по построению бизнес-архитектуры, которая представляется в виде бизнес-моделей, быстро окупают себя и имеют большое количество дополнительных преимуществ . Под бизнес-моделями понимается динамический поток событий, связанных с бизнесом, в который вовлечены различные функции бизнеса, организационные единицы и активы предприятия. Возможная отдача от реализации таких моделей достаточно подробно изучалась и описывалась на протяжении последнего столетия. Основная проблема состоит в том, чтобы убедить руководство в этих преимуществах и добиться от него поддержки проведения проекта разработки бизнес-моделей. А преимущества от построения таких моделей лежат в двух плоскостях: дополнительных возможностях для бизнеса и уменьшении затрат. По оценкам, создание бизнес-моделей и связанная с этим оптимизация затрат даже без радикальных изменений бизнеса может дать до 10% экономии. А при моделировании альтернативных вариантов бизнес-процессов организации могут сэкономить до 20% . Но не менее важная роль бизнес-моделей состоит в том общем языке, которые они дают представителям бизнеса и ИТ в обсуждении соответствующих возможностей.
Важную роль в процессе формирования целевой архитектуры предприятия играют модели бизнес-процессов. На самом деле, обеспечение соответствия между ключевыми бизнес-процессами и архитектурой информационных технологий является самой важной составляющей всех усилий по созданию архитектуры. Эти модели также могут быть реализованы различными способами, т.е. являются описательными или исполняемыми, качественными или количественными и т.п. Они могут применяться как на исключительно "бизнес-уровне" для оптимизации соответствующих процессов, так и для облегчения взаимопонимания между бизнес-пользователями и специалистами в области ИТ. Обычно в организации имеется 10-20 основных процессов. Предложенные ниже методики помогают реализовать самый трудный начальный этап описания и документирования этих процессов. Подчеркнем, что бессмысленно разрабатывать детальные модели подпроцессов для всех основных процессов. Важно сосредоточиться на тех из них, которые будут подвергнуты изменениям. Это соответствует принципам "минималистской архитектуры", описанным в "Процесс разработки архитектур: оценка зрелости, детализация и распределение усилий. Инструментальные средства и мониторинг технологий" .
Gartner рекомендует начать с построения высокоуровневых моделей бизнес-процессов предприятия. Начальным этапом для этого является определение классов бизнес-процессов. Под классом бизнес-процессов понимается группа процессов, которые состоят из большого числа одинаковых бизнес-активностей. Например, Австралийское бюро статистики выделило для себя такие классы бизнес-процессов как сбор информации о хозяйствующих субъектах, сбор информации о домохозяйствах, сбор вторичных статистических материалов, распространение информации, анализ данных, административные процессы.
Шаг 1 . Идентификация критически важных для предприятия процессов (обычно не более восьми).
Хорошими кандидатами для включения в рамки архитектуры предприятия являются те ключевые процессы, которые максимально влияют на способности организации реализовывать свою миссию, достигать цели, выполнять основные функции, а также следующие процессы :
- процессы, которые открывают новые возможности, например, новые каналы предоставления услуг;
- процессы, которые в настоящее время выполняются плохо и являются источниками неудовлетворенности клиентов;
- процессы, в которых имеются возможности для экономии.
Желательно, чтобы рекомендуемое число таких процессов, не превышало "волшебного числа" 8 в соответствии с известным принципом: "семь плюс-минус два" объекта. При необходимости схожие бизнес-процессы могут быть объединены в группы или классы.
Шаг 2 . Отследить связи между этими процессами и бизнес-стратегиями, движущими силами и критически важными факторами успеха. Это можно сделать с помощью матрицы взаимных связей. Для каждого элемента этой матрицы определяется качественная оценка по принципу "важно" – "неважно" или по некоторой условной шкале. Например, можно использовать так называемую шкалу 9-3-1, в соответствии с которой 9 обозначает сильную взаимосвязь, 3 – промежуточную, 1 – слабую.
Шаг 3 . Построить модели высокого уровня для ключевых бизнес-процессов (см. следующий раздел). Это включает последовательность основных шагов (желательно, не более восьми на процесс).
Шаг 4 . Для каждого шага процессов, идентифицированных на этапе 3, определить ответственных за выполнение шага. Это может быть функциональное подразделение внутри организации, партнер, клиент, внешний регулирующий орган.
Шаг 5 . Идентифицировать и документировать основные категории информационных объектов (опять же рекомендуется не более восьми).
Такое небольшое количество высокоуровневых моделей и понимание их связей с ключевыми факторами и факторами успеха позволяет понять в целом деятельность организации и использование ИТ-ресурсов. Более детальные модели, создание которых мы опишем в следующем разделе, полезно привязывать к этим высокоуровневым моделям.
Бизнес-архитектура предприятия неразрывно связана с процессом его управления. Под управлением предприятием обычно понимается деятельность компании с учетом изменений в окружающей экономической и социальной среде. Управленческий персонал распределяет финансовые, трудовые и материальные ресурсы для максимально эффективного достижения стратегических целей и задач предприятия.
В ходе разработки бизнес-архитектуры подробно рассматриваются различные модели построения предприятия, соответствующие стратегии его развития. Модели бизнес-архитектуры могут быть разделены на три класса: классические (эталонные), специализированные и специфические.
ИТ-архитектура предприятия, или, другими словами, архитектура информационных технологий, представляет собой совокупность технических и технологических решений для обеспечения эффективного функционирования бизнес-процессов предприятия в соответствии с правилами и концепциями, определяемыми бизнес-архитектурой [Данилин, Слюсаренко, 2005].
Архитектура информационных технологий описывает основные информационные системы, их взаимосвязи и включает их принципы развития, совершенствования и поддержки. Таким образом, мы можем говорить о том, что архитектура является самодостаточной и полной динамической моделью системы.
Архитектура информационных технологий является неотъемлемым элементом архитектуры всего предприятия и зависит от его целей и задач, стратегии развития, сложившейся модели бизнес-процессов.
В настоящее время существует множество работ, посвященных исключительно архитектуре информационных систем. Следует отметить, что практически во всех существующих методиках архитектура информационных технологий является производной (частным случаем) архитектуры предприятия в целом и рассматривать ее отдельно от контекста предприятия нецелесообразно.
Обобщенная ИТ-архитектура должна включать как логические, так и технические компоненты. Логическая архитектура предоставляет высокоуровневое описание миссии предприятия, его функциональных и информационных требований, системных компонентов и информационных потоков между этими компонентами. Техническая архитектура определяет конкретные стандарты и правила, которые будут использоваться для реализации логической архитектуры.
Традиционно ИТ-архитектуру предприятия представляют в виде трех взаимосвязанных компонентов:
Enterprise Information Architecture (EIA) – информационная архитектура;
Enterprise Solution Architecture (ESA) – архитектура прикладных решений;
Enterprise Technical Architecture (ETA) – техническая архитектура.
В ходе разработки архитектуры предприятия создается модель, включающая информацию о его производственных процессах, информационных и материальных потоках, ресурсах и организационных единицах. При этом модель ИТ-архитектуры непосредственно зависит от роли, которую выполняют информационные системы на предприятии: стратегическая (ориентированная на выполнение сложившихся стратегий и операций), сдвигающая (инструмент для увеличения эффективности бизнеса), поддерживающая (ИС не играют особой роли в функционировании предприятия), заводская (ИС являются обязательным элементом, обеспечивающим функционирование бизнеса). Модель предприятия (соответствующая ее роли) не только дает лучшее представление о структуре предприятия, но и является эффективным инструментом для анализа экономических, организационных и многих других аспектов его функционирования.
ИТ-архитектура предприятия определяет правила формирования всех компонентов ИТ, взаимосвязи между ними и бизнес-архитектурой предприятия. Это связано с тем, что документирование ИТ-архитектуры без ее увязки с бизнес-архитектурой предприятия быстро утрачивает практическую ценность.
Информационная архитектура
(Enterprise Information Architecture, EIA), или архитектура информации, – это (с точки зрения аналитиков компании Meta Group) управляемый набор методик, описывающий информационную модель предприятия и включающий:
базы данных и хранилища данных;
информационные потоки (как внутри организации, так и связи с внешним миром).
Информационную архитектуру предприятия условно можно назвать уровнем потоков данных. Но при построении информационной архитектуры предприятия нет необходимости создавать модели всех видов данных, используемых на предприятии. Достаточно обеспечить выбор наиболее важных (критичных для предприятия) данных и моделировать их на высоком уровне абстракции.
Архитектура прикладных решений
(Enterprise Solution Architecture, ESA), или, другими словами, архитектура приложений, включает совокупность программных продуктов и интерфейсов между ними.
Архитектуру прикладных решений разделяют на два направления:
область разработки прикладных систем;
портфель прикладных систем.
Область разработки прикладных систем
описывает технологическую часть архитектуры прикладных решений и включает программные продукты; модели данных; интерфейсы; пользовательские интерфейсы.
Область разработки прикладных систем является техническим описанием конкретных приложений. Соответственно, информацию о данных модулях проще всего представить в виде двух следующих схем:
компоненты и структура системы – внутренняя структура системы, включающая информацию о программных модулях и базах данных;
взаимодействие с другими системами (интерфейсы) – описывает взаимодействие приложения с внешними объектами (программными продуктами, пользователями).
Архитектура прикладных решений описывает ситуацию, сложившуюся в ИТ-подразделении на текущий момент времени (т. е. это картина, демонстрирующая «технологическое обеспечение» бизнес-процессов, где каждой основной бизнес-функции соответствуют определенные приложения). На основе архитектуры прикладных решений строятся планы последующего развития информационных технологий в компании, разрабатываются планы мероприятий и проектов, необходимых для достижения стратегических целей.
На данном уровне лучше всего отслеживается взаимодействие бизнес-архитектуры предприятия и ИТ – архитектуры, так как можно определить взаимосвязи между организационной структурой предприятия и используемыми приложениями. В этом случае для оптимизации управления приложениями их разделяют на определенные группы (домены) в соответствии с функциональными возможностями. Следует отметить, что подобное разделение позволяет проще идентифицировать владельца приложения, определять его соответствие бизнес-требованиям.
Техническая архитектура предприятия
(Enterprise Technical Architecture, ETA) – это совокупность программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений. Другими словами, под технической архитектурой мы будем понимать полное описание инфраструктуры предприятия, включающее:
информацию об инфраструктуре предприятия;
системное программное обеспечение (СУБД, системы интеграции);
стандарты на программно-аппаратные средства;
средства обеспечения безопасности (программно-аппаратные);
системы управления инфраструктурой.
Техническую архитектуру предприятия можно визуально представить в виде совокупности архитектурных схем приложений, используемых на предприятии. Визуально техническую архитектуру приложения, в свою очередь, можно представить в виде схемы, включающей информацию о серверах, компонентах системы, стандартах (использующихся в данном приложении) и взаимосвязях между ними.
Литература
Данилин А.В., Слюсаренко А.К Архитектура и стратегия. Инь и янь информационных технологий предприятия. М.: Интернет-университет информационных технологий, 2005.Ермошкин Н.Н., Тарасов АЛ. Стратегия информационных технологий предприятия. М.: Московский гуманитарный университет, 2003.
Сизов А. В. Разработка архитектуры и модернизация системы управления предприятием. М.: Оверлей, 2008.
CIO Council. A Practical Guide to Federal Enterprise Architecture, 2001.
META Group. Executive Insights. Enterprise Architecture Desk Reference, 2002.
Schekkerman J . How to Survive in the Jungle of Enterprise Architecture Frameworks, TRAFFORD 2003.
Scott A.B. Introduction to Enterprise Architecture; Publisher: authorHOUSE™, 2005.
Контрольные вопросы
1. Что такое архитектура предприятия (Enterprise Architecture)?2. Зачем нужна архитектура предприятия?
3. Перечислите основные слои архитектуры предприятия.
4. Опишите основные объекты Enterprise Business Architecture.
5. Опишите основные объекты Enterprise Information Architecture.
6. Опишите основные объекты Enterprise Solution Architecture.
7. Опишите основные объекты Enterprise Technical Architecture.
8. Что представляет собой текущая архитектура предприятия – ЕТА?
9. Объясните назначение и сущность архитектурной модели МЕТА Group.
Лекция 2. Процесс разработки архитектуры предприятия
Цель
Рассмотрение принципов и основных методик процесса разработки архитектуры предприятия и разработки ИТ-архитектуры, являющейся элементом общей архитектуры предприятия. Ознакомление студентов с известными моделями архитектуры предприятия.Длительность – 2 часа.
План
1. Общая схема архитектурного процесса.2. Принципы построения архитектуры предприятия.
3. Современные методики описания архитектуры предприятия:
модель Захмана;
МЕТА Group;
Gartner;
TOGAF;
методики Microsoft.
Краткий конспект лекции
Описание процесса разработки архитектуры предприятия является одним из самых важных элементов наряду с принципами построения архитектуры предприятия. Как уже было сказано выше, разработка ИТ-архитектуры – это элемент общей архитектуры предприятия. Разработанная архитектура представляется лишь «застывшей картинкой», отображающей текущее состояние предприятия. В целом архитектура предприятия представляет совокупность скоординированных проектов, необходимых для преобразования сложившейся архитектуры организации в состояние, определяемое как долгосрочная цель.Аналитики выделяют следующие подходы к процессу построения архитектуры предприятия .
Традиционный подход . Требует существенных затрат времени и ресурсов для построения архитектуры предприятия. Первый этап построения архитектуры рассматривается как проект, в ходе которого собирается детализированная информация о состоянии предприятия (текущая архитектура) и на ее основе начинают разрабатываться планы развития (целевая архитектура). Основу данного подхода составляет процесс построения архитектуры предприятия.
Сегментный подход. Позволяет сосредоточить работы на ключевых бизнес-функциях предприятия и постепенно внедрять архитектурный процесс по мере появления ресурсов. В основе такого подхода заложены принципы построения архитектуры предприятия, в соответствии с которыми внедряются новые технологии (информационные системы), стандарты, продукты и услуги.
Следует отметить существование третьего подхода к процессу построения архитектуры предприятия: подхода статус-кво . Суть данного подхода в том, чтобы не внедрять архитектурный процесс на предприятии, или, другими словами, оставить все как есть.
Архитектура предприятия развивается циклично. В ходе разработки стратегии развития предприятия выявляются изменения в бизнес-архитектуре предприятия, позволяющие оптимизировать его бизнес-процессы, а изменение бизнес-процессов предприятия непосредственно влияет на изменение ИТ-архитектуры. Далее разрабатывается план миграции, в ходе выполнения которого происходит переход из текущего состояния в планируемое. При этом процесс миграции является лишь очередным шагом на пути преобразования предприятия, и его окончание означает переход предприятия на новый виток развития, вновь начинающийся с разработки стратегии.
Один из самых первых и наиболее удачных процессов разработки архитектуры предприятия был предложен Стивеном Спиваком (Steven Spewak) и назывался ЕАР (Enterprise Architecture Planning). Модель выделяет в архитектуре предприятия семь шагов, разделенных на четыре уровня, и обеспечивает высокоуровневый взгляд на предприятие с точки зрения бизнеса [Сизов, 2008].
Уровень 1. Это уровень начала работ и активации архитектурного процесса. На этапе инициирования процесса планирования разрабатываются и описываются основные концепции развития архитектуры предприятия. Разрабатываются принципы построения архитектуры.
Уровень 2. Этот уровень описывает состояние предприятия в настоящий момент времени. Другими словами, это уровень разработки текущей архитектуры предприятия. Здесь происходят бизнес-моделирование (разработка текущей бизнес-архитектуры) и описание текущих систем и технологий (документирование текущей архитектуры информационных систем).
Уровень 3. Этот уровень описывает возможные варианты развития архитектуры данных, архитектуры приложений, технологической архитектуры в соответствии с требованиями бизнеса. Другими словами, на этом уровне происходит разработка целевой архитектуры.
Уровень 4. Это уровень, обеспечивающий разработку плана перехода из текущего состояния в будущее. На этом уровне разрабатывается план миграции.
Процесс разработки архитектуры предприятия имеет циклическую структуру.
Одной из основных составляющих проекта разработки архитектурного процесса является создание структур, обеспечивающих управление и контроль за всем процессом. Архитектура предприятия должна являться основополагающим правилом, законом, в соответствии с которым происходят изменения деятельности компании.
Основу управления и контроля архитектурного процесса, как правило, составляет набор руководящих принципов. Многие аналитики выделяют следующий набор принципов:
Внедрение новых систем и модернизация существующих должны проходить оценку эффективности, целесообразности для компании и соответствовать ее стандартам.
Необходимо контролировать изменения бизнес-процессов и информационных систем в рамках их влияния на другие обеспечивающие (зависимые) бизнес-процессы и информационные системы.
Архитектурные модели должны поддерживаться в актуальном состоянии. Необходимо обеспечивать контроль целостности моделей и связей между ними.
Должны быть разработаны и поддерживаться в актуальном состоянии стандарты, правила и политики. Все проекты должны контролироваться на соответствие стандартам.
Результаты работы архитектурного процесса должны готовиться в виде рекомендаций, подлежащих утверждению высшим руководством организации.
Одним из инструментов, обеспечивающих управление и контроль за архитектурным процессом, является создание архитектурного комитета во главе с одним из топ-менеджеров. Функции архитектурного комитета заключаются в отслеживании и одобрении проектов и инициатив, существующих в компании, и оценке целесообразности их проведения. Следует отметить, что вместе с созданием архитектурного комитета на предприятии создается еще один бюрократический уровень, позволяющий активировать и останавливать проекты. Недостатком архитектурного комитета может оказаться возможность задержек при рассмотрении вопросов в ситуации, когда требуется быстрое принятие решений.
Разработка архитектуры – процесс, требующий привлечения большого числа участников и рациональной организации их работы. В связи с этим выбор методологии является необходимой и важной задачей, так как от правильного ее решения зависит успешность усилий, затрачиваемых на разработку и поддержание архитектуры.
В настоящее время существует множество методик построения архитектуры предприятия. Данная лекция не ставит своей целью описать все существующие методики разработки архитектуры предприятия, поэтому ниже приведена информация о наиболее популярных сейчас моделях.
Следует отметить, что архитектурные методики претерпевают постоянные изменения вместе с новыми тенденциями в области управления предприятием и развитием информационных технологий.
Первые версии многих современных методик были разработаны еще в 1990-х гг. . Многие из них постоянно модернизируются или становятся основой для других, более современных методологий:
Zachman Framework – методика, опубликованная впервые в 1987 г. Zachman Institute for Framework Advancement (ZIFA). Методика постоянно обновляется и поддерживается в актуальном состоянии. Лежит в основе многих программных продуктов для архитектурного моделирования (например, CASE Wise).
ЕАР (Enterprise Architecture Planning) – коммерческая методика, разработанная в 1992 г. Стивеном Спиваком на основе двух верхних уровней Zachman Framework: Scope (Planner) и Business Model (Owner). Методика представляет собой архитектурный процесс, обеспечивающий инициализацию и разработку архитектуры в рамках всего предприятия.
PERA (Purdue Enterprise Reference Architecture). Методика разрабатывалась в 1989–1992 гг. в Purdue Laboratory for Applied Industry Control (PLAIC). В основе методики заложена декомпозиция плана внедрения информационной системы на отдельные шаги и упрощения за счет этого ее внедрения и интеграции. В настоящее время эту методику не поддерживают в актуальном состоянии.
TOGAF (The Open Group Architecture Framework). Методика была разработана в 1995 г. и позиционируется авторами как средство разработки информационных систем. Методика сфокусирована на эффективном функционировании приложений, критичных для бизнеса.
CIMOSA (Computer Integrated Manufacturing Open Sys), известная как CIM Open System Architecture, была разработана компанией AMICE Consortium в 1996 г. Методика была одной из инициатив в рамках программы European ESPRIT. В настоящее время можно говорить, что CIMOSA является европейским архитектурным стандартом для построения комплексных автоматизированных производств (CIM – Computer-Integrated Manufacturing) и поддерживает все этапы их жизненного цикла.
