Назначение и состав информационных систем

НАЗНАЧЕНИЕ И СОСТАВ ИНФОРМАЦИОННЫХ СИСТЕМ Лекция 1 Информационная система • Информационная система представляет собой сложный комплекс разнородных составляющих, которые взаимодействуют между собой и создают необходимые потребителю свойства системы. Технологические элементы, обеспечивающие функционирование системы: • информационная модель предметной области; • кадровые ресурсы, отвечающие за формирование и развитие информационной модели; • программный комплекс; • кадровые ресурсы, отвечающие за конфигурирование программного комплекса; • аппаратно-техническая база; • эксплуатационно-технические кадровые ресурсы; Управленческие элементы, обеспечивающие организацию эксплуатации системы • регламент развития информационной модели и правила внесения в нее изменений; • регламент технической и пользовательской поддержки программного комплекса; • регламент внесения изменений в конфигурацию программного комплекса и состав его функциональных модулей; • регламент использования программного комплекса и пользовательские инструкции; • регламент обучения и сертификации пользователей. Задачи внедрения информационных систем • необходимость в реализации единой ИТстратегии предприятия • развитие (создание) программной и аппаратной частей системы параллельно с комплексом работ по развитию существующей ИТ-инфраструктуры компании. Проблемы внедрения информационных систем • проектирование систем без учета стратегии развития бизнеса — необходимо представлять структуру и масштабы бизнеса в перспективе как минимум на 3 года; • нарушение принципа построения системы «сверху-вниз» и, как следствие, отсутствие информационной поддержки принятия управленческих решений на верхних уровнях управления; • чрезмерное увлечение реинжинирингом бизнес-процессов и порой неоправданное их подчинение требованиям стандартной функциональности базовой ERP-системы; • кардинальная переработка базовой функциональности ERPсистемы; • нереалистичные ожидания вследствие неверной оценки экономической эффективности внедрения ERP-системы. Факторы успеха проекта внедрения Реинж иниринг бизнес-процессов до внедрения 8% Качество системы и команды консультантов 11% Наличие стратегии у Клиента 8% Участие специалистов клиента 16% Получение быстрой и эффективной отдачи 2% Ясные цели и четкие требования 16% Участие руководства в проекте 20% Наличие и соблюдение плана внедрения 19% Назначение методологии внедрения ИС • Методологии внедрения обычно разрабатываются ведущими производителями информационных систем с учетом особенностей их программных продуктов, а также сферы внедрения. • Положительная сторона таких стандартов — их практическая направленность. Они представляют собой глубоко проработанные, проверенные, многократно апробированные рабочие инструкции и шаблоны проектных документов. • Отрицательные стороны: даже методологии, предназначенные для систем, близких по классу, не взаимозаменяемы. Состав методологии внедрения ИС • разработки компании Microsoft — методологии «OnTarget», «MSF (Microsoft Solutions Framework)», «Business Solutions Partner Methodology»; • разработки компании SAP — методологии «Процедурная модель SAP», «ASAP (Accelerated SAP)»; • разработки компании Oracle — комплекс методологий «Oracle Method». Основные результаты использования методологии • создание решения, оптимально соответствующего требованиям клиента; • максимально эффективное использование ресурсов проекта; • минимизация сроков и затрат на внедрение; • уменьшение рисков проекта. Составляющие методологии внедрения Технология создания продукта Технология управления проектом Корпоративная методология внедрения Организационная структура проекта Отвечает за обеспечение сотрудников ресурсами Руководитель проекта 1 Руководитель проекта 2 Руководитель проекта 3 Отвечает за выполнение проекта Руководство организацией Начальник Начальник Начальник Начальник отдела 1 отдела 2 отдела 3 отдела 4 Сотрудник 1.1 Сотрудник 2.1 Сотрудник 3.1 Сотрудник 4.1 Сотрудник 1.2 Сотрудник 2.2 Сотрудник 3.2 Сотрудник 4.1 Сотрудник1.1 Сотрудник2.2 Сотрудник3.3 Сотрудник4.2 Основные типы структур организаций, осуществляющих внедрение ИС Куратор проекта (Спонсор) со стороны Заказчика <ФИО> Куратор проекта (Спонсор) со стороны Исполнителя <ФИО> Управление проектом Заказчик: Руководитель проекта <ФИО> Команда управления проектом Исполнитель: Руководитель проекта <ФИО> Команда управления проектом : Проектная группа Заказчика Проектная группа Исполнителя Специалисты Заказчика с необходимыми в рамках проекта компетенциями Специалисты Исполнителя с необходимыми в рамках проекта компетенциями Бизнес и информационные технологии Лекция 2 Роль ИТ-систем для бизнеса • Возможность увеличения эффективности использования информационных технологий (ИТ) для основной деятельности организации. • Развитие бизнеса неминуемо сопровождается соответствующими изменениями в ИТсистемах. • ИТ-стратегия определяет возможные способы достижения целевого состояния информационной системы. Архитектура и стратегия: информационных технологий предприятия Наиболее существенные области изменения роли ИТ для бизнеса Business process fusion • Создание "более совершенных" процессов через объединение ранее существовавших автономных на основе интенсивного использования возможностей ИТ. • Слияние бизнес-процессов будет определять инвестиции в ИТ в крупных компаниях. • Однако именно существующие информационные системы, наряду с корпоративной культурой, являются одним из важнейших ограничений на пути таких преобразований. Характерные изменения бизнеса • глобализация бизнеса, связанная с необходимостью объединения различных национальных процессов, данных и персонала; • динамика слияний и поглощений, приводящая к объективно необходимой интеграции различных информационных систем, объединению ИТ-служб; • появление адаптивного стиля бизнеса – переход от модели, основанной на имеющейся линейке продуктов, к модели, основанной на гибком реагировании на потребности рынка; • сокращение характерных длительностей бизнеспроцессов и виртуализация бизнеса. Сокращение характерных длительностей бизнес-процессов • Современные условия бизнеса характеризуются существенным сокращением времени выполнения всех процессов. • Изменения в окружающей среде все чаще случаются за более короткие промежутки времени. • Что является причиной того, что время, требующееся для перехода на новые бизнеспроцессы и для реализации бизнес-стратегии сокращается. • Основной критический фактор для обеспечения функциональности предприятия связан с развитием коммуникационных возможностей. Направления развития ИТ-систем • широкое внедрение беспроводных технологий • существенное увеличение пропускной способности или качества традиционно используемых каналов связи • электронный документооборот • взаимодействие и обмен сообщениями в реальном времени • системы позиционирования/слежения за объектами • хранилища данных реального времени Архитектура информационной системы • Концепция предприятия реального времени базируется на интеграции практически всего, что связано с деятельностью организации: – – – – – инфраструктуры, систем, информации, процессов людей. • А основой этого является архитектура информационных технологий, а в более широком смысле – архитектура предприятия в целом. Сервис-ориентированная архитектура • Включает: – модульную реализацию прикладных систем – "открытие" отдельных функций, в виде сервисов • Технологической основой такого взаимодействия между системами по принципу предоставления услуг друг другу является технология web-сервисов Эволюция роли ИТ Изменение целей и результатов применения ИТ Цепочка создания добавочной стоимости, связанная с ИТ Интеграция ключевых процессов управления ИТ-системой Парадокс • Рост роли ИТ для бизнеса связан с тенденцией уменьшения возврата от инвестиций в ИТ. • Подходы, основанные на использовании принципов архитектуры информационных технологий предприятия, могут привести к радикальным изменениям в негативной тенденции отдачи от инвестиций в информационные технологии. Архитектура ИТ-системы предприятия Лекция 3 Архитектура ИТ-системы и ИТ-проекты Элементы Архитектуры предприятия • Бизнес-архитектура. Описывает деятельность организации с точки зрения ее ключевых бизнес-процессов. • Архитектура информации (данных). Определяет, какие данные необходимы для поддержания, а также для обеспечения стабильности и возможности долговременного использования этих данных в прикладных системах. • Архитектура приложений. Определяет, какие приложения используются и должны использоваться для управления данными и поддержки бизнес-функций. • Технологическая архитектура (инфраструктура или системная архитектура). Определяет, какие обеспечивающие технологии (аппаратное и системное программное обеспечение, сети и коммуникации) необходимы для создания среды работы приложений. Области, входящие в понятие Архитектуры предприятия Основные составные элементы стратегии и архитектуры ИТ Общие принципы построения Архитектуры ИТ – Все подразделения должны использовать в своей работе архитектуру, разработанную для организации в целом. – Функциональное руководство и руководство в области ИТ должно основываться на общем видении. – Архитектура должна обеспечивать решение вопросов бесперебойного выполнения организациями своих функций, безопасности и восстановления. – Функциональные (бизнес-) требования должны формировать архитектуру. – Архитектура должна обеспечивать совместимость и взаимодействие. – Архитектура должна быть расширяемой, масштабируемой и адаптивной. – Архитектура должна быть инструментом реализации изменений. – Архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнес-процессов. – Тенденции рынка должны учитываться при проектировании технологической архитектуры. Динамическая концептуальная модель процесса закупки товара Построение бизнес-архитектуры Формы информации • 1) структурированная информация (реляционные и объектные модели); • 2) развивающиеся, основанные на XML стандарты для полуструктурированной информации; • 3) неструктурированная информация в форме текстов, графиков, образов, сопровождаемая определенными описательными данными (метаданными и каталогами). Элементы архитектуры информации Пример потоков данных на предприятии Процессы управления информацией • • • • • • • • • получение данных из внутренних и внешних источников; классификация данных по типам; хранение и извлечение данных; редактирование (или обновление) данных; контроль качества (удаление или исправление некорректных данных); презентация (трансформирование данных для определенной аудитории потребителей); распространение информации для различных групп потребителей; оценка (полезности, а также соотношения цены/качества данных); обеспечение безопасности информации. Общая архитектура информации Принципы интеграции информации на основе управления данными Принципы интеграции информации на основе управления данными • В нижней части мы имеем набор различных физических систем управления данными. • Уровень выше представляет набор моделей этих систем, независимых от платформы реализации. • Уровень запросов выполняет трансформацию и устанавливает соответствие для создания виртуальных моделей объектов, чьи физические аналоги могут и не существовать в физических системах. • Виртуальные модели для различных пользователей могут представляться по-разному – базами данных, бизнесобъектами, представлениями (выборки из базы), моделями данных предприятия, документами, сервисами или компонентами в зависимости от потребностей. Оценка портфеля прикладных систем Анализ портфеля инвестиций в приложения «Пирамида" из четырех категорий активов Технологическая инфраструктура Взаимосвязи функциональных и операционных требований с архитектурой приложений и технологической архитектурой Жизненный цикл ИТ-систем Организация процесса разработки архитектуры ИТ-системы Технологическая модель предприятия Основные элементы архитектурного процесса Интегрированная концепция архитектуры предприятия Лекция 4 Эволюция организационных принципов Процессы информационных технологий • моделирование информации (разработка архитектуры информации), которая обеспечивает выполнение бизнес-процессов вашей организации (удовлетворение существующих требований к информации); • формирование портфеля прикладных систем (определение архитектуры приложений), которые обрабатывают эту информацию в соответствии с некоторыми функциональными требованиями; • построение инфраструктуры (формирование технологической архитектуры), которая обеспечивает работу прикладных систем на уровне, описанном в операционных требованиях (надежность, масштабируемость и т.д.). Синхронизация потребностей бизнеса и возможностей ИТ Бизнес-процессы и обеспечивающие информационные системы Необходимость сбора и анализа бизнес-информации • Характерной чертой современного бизнеса является исключительно высокая скорость происходящих изменений в окружающей среде, постоянные изменения становятся скорее нормой, чем исключением. • Большой интерес представляет создание модели адаптивной организации, которая должна содержать внутренние механизмы для изменения в соответствии с требованиями внешнего окружения. • Необходимым условием для этого является гибкость организационной структуры и формализация процессов деятельности, прежде всего, связанных с цепочкой создания добавленной стоимости и и эффективным управлением процессами изменений. Задачи архитектуры предприятия • Архитектура предприятия является динамичным и мощным инструментом, который помогает организациям в процессе понимания своей собственной структуры и способов выполнения своей работы и функций. • Хорошая архитектура предприятия обеспечивает сбалансированный анализ фактов об организации и дает руководству способы изучения своих организаций и их функционирования, помогает им формулировать новые стратегии, дает направление в процессе планирования развития для того, чтобы организации соответствовали постоянно меняющимся условиям и приоритетам. Пользователи архитектуры предприятия • профессионалы в области создания информационных систем, которые вовлечены в соответствующие корпоративные проекты создания важных для предприятия приложений; • системные архитекторы, которые отвечают за создание архитектуры отдельных информационных систем; • бизнес-аналитики, которые ведут процесс проектирования организационных структур и бизнеспроцессов; • руководители, заинтересованные в систематическом, структурированном анализе проблем и возможностей, которые открываются перед бизнесом. Уровни абстракции архитектуры Представления и перспективы описания архитектуры предприятия Интегрированная концепция архитектуры предприятия Концептуальный уровень • Концептуальный уровень описывает сервисы и взаимосвязи между сервисами, которые должны быть реализованы для обеспечения принципов, определенных на уровне контекста. • Основная задача на этапе концептуального проектирования и создания бизнес-модели состоит в описании ключевых бизнес-процессов и данных, которые эти процессы используют таким образом, чтобы подчеркнуть цели и требования с точки зрения бизнеса в форме, свободной от описания применяемых технологий. Логический уровень • На этом уровне определяются общие принципы, которые будут накладывать определенные ограничения на решения, принимаемые на более низких уровнях. • Логический уровень описывает решение в виде набора сервисов или компонент в независимой от технологической реализации форме. Это включает четкое определение интерфейсов (или так называемых контрактов), связанных с интеграцией и совместной работой этих сервисов и компонент. Физический уровень • Физический уровень описывает принципы проектирования, стандарты и правила, включая группирование критически важных компонент, а также модели развертывания. Это обеспечивает общую основу, в рамках которой на уровне реализации будет выполнена непосредственно разработка. • Каждый элемент модели приложения необходимо соотнести с реальными технологиями и технологическими стандартами, что делается через создание технологических моделей приложения. Цепочка создания добавочной стоимости, связанная с ИТ Эффективное управление портфелем ИТ на уровне предприятия • стратегия и планирование на уровне предприятия. • архитектура предприятия. • управление ИТ-программами и проектами. Интеграция ключевых процессов управления ИТ предприятия Архитектура, ИТ-активы и ИТ-проекты Общие элементы определений, связанных с архитектурой • архитектура определяет основные компоненты (бизнес-архитектура, архитектура приложений и т.д.); • архитектура определяет взаимосвязи между компонентами и взаимодействия между ними; • уровень детализации архитектуры выбирается таким, что "опускается" вся информация о компонентах, которая не имеет значения вне вопросов взаимодействия с остальными компонентами архитектуры; • поведение компонент является частью архитектуры настолько, насколько это важно с точки зрения взаимодействия с другими компонентами; • каждая система имеет архитектуру – даже система, которая состоит из одной компоненты; • архитектура содержит объяснения и обоснования по поводу своих компонент и структуры; • определения архитектуры не содержат описания самих компонент. Управление ИС Лекция 5. Элементы информационной системы предприятия Элементы ИС предприятия • Бизнес-архитектура. Описывает деятельность организации с точки зрения ее ключевых бизнес-процессов. • Архитектура информации (данных). Определяет, какие данные необходимы для поддержания бизнес-процессов (например, модель данных), а также для обеспечения стабильности и возможности долговременного использования этих данных в прикладных системах. • Архитектура приложений. Определяет, какие приложения используются и должны использоваться для управления данными и поддержки бизнес-функций (например, модели приложений). • Технологическая архитектура (инфраструктура или системная архитектура). Определяет, какие обеспечивающие технологии (аппаратное и системное программное обеспечение, сети и коммуникации) необходимы для создания среды работы приложений, которые, в свою очередь, управляют данными и обеспечивают бизнес-функции. Эта среда должна обеспечивать работу прикладных систем на заданном уровне предоставления сервисов своим пользователям. Другие представления • Архитектура интеграции. Определяет инфраструктуру для интеграции различных приложений и данных. Например, в проектах в области "электронного правительства", когда имеется большое количество государственных информационных систем различных ведомств, возникает настоятельная потребность создания самостоятельной инфраструктуры интеграции (архитектура интеграции), с целью предоставления государством интегрированных услуг гражданам и бизнесу по принципу "одного окна". • Архитектура общих сервисов. Примерами их являются такие сервисы, как электронная почта, каталоги, общие механизмы безопасности (идентификации, аутентификации, авторизации). То есть, это достаточно большое количество прикладных систем, которые носят "горизонтальный характер". • Сетевая архитектура. Определяет описания, правила, стандарты, которые связаны с сетевыми и коммуникационными технологиями, используемыми в организации. • Архитектура безопасности и т.д. Области, входящие в понятие Архитектуры ИС предприятия Модель для описания стратегии и архитектуры информационной системы предприятия Общие принципы, связанные с архитектурой ИС предприятия • • Тематика и список конкретных принципов определяется уровнем развития информационных систем предприятия, существующими приоритетами, и спектр этой тематики очень широкий. Принципы: – Все подразделения (ведомства) должны использовать в своей работе архитектуру, разработанную для организации (правительства) в целом. – Функциональное руководство и руководство в области ИТ должно основываться на общем видении. – Архитектура должна обеспечивать решение вопросов бесперебойного выполнения организациями своих функций, безопасности и восстановления в случае катастрофических событий. – Функциональные (бизнес-) требования должны формировать архитектуру. – Архитектура должна обеспечивать совместимость и взаимодействие. – Архитектура должна быть расширяемой, масштабируемой и адаптивной. – Архитектура должна быть инструментом реализации изменений. – Архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнес-процессов. – Тенденции рынка должны учитываться при проектировании технологической архитектуры. Принципы в области ИТ-инфраструктуры • Инфраструктура должна быть основана на использовании технологий, поддерживающих открытые стандарты. • Инфраструктура (совместно с принципами управления данными и разработки приложений) должна обеспечивать взаимодействие систем. Принципы в области управления данными • Бизнес-структуры (отделы, департаменты, ведомства), являющиеся владельцами данных, отвечают за целостность и распространение данных. • Данные уровня отдельных бизнес-структур (департамента, региона, города) должны быть явно описаны и доступны всем остальным бизнес-структурам (департаментам, ведомствам). • Ведомства собирают только самый необходимый минимум данных и стремятся уменьшить нагрузку на тех, кто должен предоставлять данные. • Данные вводятся в информационные системы один раз, и тут же выполняется проверка их корректности. • Информация является ценным ресурсом, который передан в управление менеджерам (государственным служащим), и этим ресурсом необходимо соответствующим образом управлять. Принципы, связанные с прикладными системами • Прикладные системы разрабатываются на основе стандартной, единой методологии. • Все структурные подразделения (ведомства) используют общие методы представления информации пользователям в своих приложениях и координируют работы по созданию пользовательского интерфейса межфункциональных (межведомственных) систем. • Создание межфункциональных прикладных систем приветствуется. • Руководство заранее планирует процесс замены устаревших прикладных систем. Принципы, связанные с управлением и контролем • Единая архитектура, соответствующие стандарты и руководства используются всеми структурными подразделениями (ведомствами) в процессе принятия решений о своих информационных системах. • Стандарты пересматриваются регулярно не реже одного раза в два года с участием представителей структурных подразделений (ведомств). • Руководство структурных подразделений (ведомств) стремится к кооперации и партнерству с другими структурными подразделениями (ведомствами) в области информационных технологий. Модели и моделирование • Модель содержит конкретные данные, определяющие характеристики системы. Эти данные используются как некоторое представление реальной системы в целях ее концептуального осмысления, описания процессов обмена информацией с этой системой, понимания того, как система работает с точки зрения конечных пользователей. Классификация моделей • формальные (использующие общепринятые правила, нотации и средства) и неформальные ; • количественные – позволяющие производить численные оценки и проверки, и качественные, предназначенные для понимания поведения и структуры системы; • описательные – предназначенные только для восприятия человеком, или исполняемые, позволяющие исследовать их поведение и использовать полученные результаты для выводов об исходной системе. Качественные и описательные модели • текстовые, использующие либо одну из формальных грамматик (пример – так называемые формы Бэкуса), либо обычный текст; • визуальные модели, представляемые в виде диаграмм с определенной нотацией. Наиболее популярным языком для описания таких моделей программных систем в последнее время стал UML. – Заметим, что, вообще говоря, даже эскизное изображение структуры или хода процесса, не обязательно соответствующее какому-либо стандарту, также может рассматриваться как модель – лишь бы оно могло быть использовано в нужном контексте для анализа или обсуждения проблемы. Количественные модели • математические модели, которые могут быть описаны системами уравнений. Решение уравнений может быть в простейшем случае найдено в аналитической форме, в более сложных случаях применяются различные численные методы. – Достаточно часто применяются электронные таблицы, с помощью которых могут быть проведены исследования типа "что – если". В зависимости от используемых средств эти модели могут быть исполняемыми или чисто описательными; • динамические исполняемые модели, которые строятся с использованием специализированных программных или программно-технических средств и позволяют исследовать поведение описываемых ими объектов в различных внешних условиях. Модель архитектуры ИС предприятия • Разработка архитектуры ИС помогает достичь две взаимосвязанные цели: обеспечивает понимание структур, объектов и связей между ними в достаточно неоднородном и обширном наборе информационных систем предприятия, а также поставляет сведения, необходимые для обеспечения интеграции процессов, систем и информации. • Процесс создания моделей и моделирования ИС можно рассматривать с двух точек зрения: моделирование с целью обеспечить понимание и моделирование для интеграции. Динамическая концептуальная модель процесса закупки товара Статическая модель процесса закупки товара в магазине Выводы • В результате у разработчика системы, который использует соответствующие средства, имеется возможность одновременно видеть модели системы и код, который их реализует. • Между ними всегда обеспечивается соответствие. При этом то, что раньше было "необязательной" работой (создание моделей), становится просто неотъемлемой частью процесса разработки. ИС в управлении персоналом Лекция 6. Элементы Архитектуры предприятия Элементы архитектуры предприятия • Бизнес-архитектура. Описывает деятельность организации с точки зрения ее ключевых бизнес-процессов. • Архитектура информации (данных). Определяет, какие данные необходимы для поддержания бизнес-процессов (например, модель данных), а также для обеспечения стабильности и возможности долговременного использования этих данных в прикладных системах. • Архитектура приложений. Определяет, какие приложения используются и должны использоваться для управления данными и поддержки бизнес-функций (например, модели приложений). • Технологическая архитектура (инфраструктура или системная архитектура). Определяет, какие обеспечивающие технологии (аппаратное и системное программное обеспечение, сети и коммуникации) необходимы для создания среды работы приложений, которые, в свою очередь, управляют данными и обеспечивают бизнес-функции. Эта среда должна обеспечивать работу прикладных систем на заданном уровне предоставления сервисов своим пользователям. 2 Другие представления архитектуры • Архитектура интеграции. Определяет инфраструктуру для интеграции различных приложений и данных. Например, в проектах в области "электронного правительства", когда имеется большое количество государственных информационных систем различных ведомств, возникает настоятельная потребность создания самостоятельной инфраструктуры интеграции (архитектура интеграции), с целью предоставления государством интегрированных услуг гражданам и бизнесу по принципу "одного окна". • Архитектура общих сервисов. Примерами их являются такие сервисы, как электронная почта, каталоги, общие механизмы безопасности (идентификации, аутентификации, авторизации). То есть, это достаточно большое количество прикладных систем, которые носят "горизонтальный характер". • Сетевая архитектура. Определяет описания, правила, стандарты, которые связаны с сетевыми и коммуникационными технологиями, используемыми в организации. • Архитектура безопасности и т.д. 3 Области, входящие в понятие Архитектуры предприятия 4 Модель для описания стратегии и архитектуры информационных технологий 5 Общие принципы, связанные с архитектурой предприятия • • Тематика и список конкретных принципов определяется уровнем развития информационных систем предприятия, существующими приоритетами, и спектр этой тематики очень широкий. Принципы: – Все подразделения (ведомства) должны использовать в своей работе архитектуру, разработанную для организации (правительства) в целом. – Функциональное руководство и руководство в области ИТ должно основываться на общем видении. – Архитектура должна обеспечивать решение вопросов бесперебойного выполнения организациями своих функций, безопасности и восстановления в случае катастрофических событий. – Функциональные (бизнес-) требования должны формировать архитектуру. – Архитектура должна обеспечивать совместимость и взаимодействие. – Архитектура должна быть расширяемой, масштабируемой и адаптивной. – Архитектура должна быть инструментом реализации изменений. – Архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнес-процессов. – Тенденции рынка должны учитываться при проектировании технологической архитектуры. 6 Принципы в области ИТ-инфраструктуры • Инфраструктура должна быть основана на использовании технологий, поддерживающих открытые стандарты. • Инфраструктура (совместно с принципами управления данными и разработки приложений) должна обеспечивать взаимодействие систем. 7 Принципы в области управления данными • Бизнес-структуры (отделы, департаменты, ведомства), являющиеся владельцами данных, отвечают за целостность и распространение данных. • Данные уровня отдельных бизнес-структур (департамента, региона, города) должны быть явно описаны и доступны всем остальным бизнес-структурам (департаментам, ведомствам). • Ведомства собирают только самый необходимый минимум данных и стремятся уменьшить нагрузку на тех, кто должен предоставлять данные. • Данные вводятся в информационные системы один раз, и тут же выполняется проверка их корректности. • Информация является ценным ресурсом, который передан в управление менеджерам (государственным служащим), и этим ресурсом необходимо соответствующим образом управлять. 8 Принципы, связанные с прикладными системами • Прикладные системы разрабатываются на основе стандартной, единой методологии. • Все структурные подразделения (ведомства) используют общие методы представления информации пользователям в своих приложениях и координируют работы по созданию пользовательского интерфейса межфункциональных (межведомственных) систем. • Создание межфункциональных прикладных систем приветствуется. • Руководство заранее планирует процесс замены устаревших прикладных систем. 9 Принципы, связанные с управлением и контролем • Единая архитектура, соответствующие стандарты и руководства используются всеми структурными подразделениями (ведомствами) в процессе принятия решений о своих информационных системах. • Стандарты пересматриваются регулярно не реже одного раза в два года с участием представителей структурных подразделений (ведомств). • Руководство структурных подразделений (ведомств) стремится к кооперации и партнерству с другими структурными подразделениями (ведомствами) в области информационных технологий. 10 Модели и моделирование • Модель содержит конкретные данные, определяющие характеристики системы. Эти данные используются как некоторое представление реальной системы в целях ее концептуального осмысления, описания процессов обмена информацией с этой системой, понимания того, как система работает с точки зрения конечных пользователей. 11 Классификация моделей • формальные (использующие общепринятые правила, нотации и средства) и неформальные ; • количественные – позволяющие производить численные оценки и проверки, и качественные, предназначенные для понимания поведения и структуры системы; • описательные – предназначенные только для восприятия человеком, или исполняемые, позволяющие исследовать их поведение и использовать полученные результаты для выводов об исходной системе. 12 Качественные и описательные модели • текстовые, использующие либо одну из формальных грамматик (пример – так называемые формы Бэкуса), либо обычный текст; • визуальные модели, представляемые в виде диаграмм с определенной нотацией. Наиболее популярным языком для описания таких моделей программных систем в последнее время стал UML. – Заметим, что, вообще говоря, даже эскизное изображение структуры или хода процесса, не обязательно соответствующее какому-либо стандарту, также может рассматриваться как модель – лишь бы оно могло быть использовано в нужном контексте для анализа или обсуждения проблемы. 13 Количественные модели • математические модели, которые могут быть описаны системами уравнений. Решение уравнений может быть в простейшем случае найдено в аналитической форме, в более сложных случаях применяются различные численные методы. – Достаточно часто применяются электронные таблицы, с помощью которых могут быть проведены исследования типа "что – если". В зависимости от используемых средств эти модели могут быть исполняемыми или чисто описательными; • динамические исполняемые модели, которые строятся с использованием специализированных программных или программно-технических средств и позволяют исследовать поведение описываемых ими объектов в различных внешних условиях. 14 Модель архитектуры предприятия • Разработка архитектуры помогает достичь две взаимосвязанные цели: обеспечивает понимание структур, объектов и связей между ними в достаточно неоднородном и обширном наборе информационных систем предприятия, а также поставляет сведения, необходимые для обеспечения интеграции процессов, систем и информации. • Процесс создания моделей и моделирования можно рассматривать с двух точек зрения: моделирование с целью обеспечить понимание и моделирование для интеграции. 15 Динамическая концептуальная модель процесса закупки товара 16 Статическая модель процесса закупки товара в магазине 17 Выводы • В результате у разработчика системы, который использует соответствующие средства, имеется возможность одновременно видеть модели системы и код, который их реализует. • Между ними всегда обеспечивается соответствие. При этом то, что раньше было "необязательной" работой (создание моделей), становится просто неотъемлемой частью процесса разработки. 18 Архитектура предприятия Лекция 7. Технологическая архитектура, стандарты и шаблоны Контекст и основные элементы технологической архитектуры • • Основное назначение технологической архитектуры – это обеспечение надежных ИТ-сервисов, предоставляемых в рамках всего предприятия в целом и координируемых централизованно, как правило, департаментами информационных технологий. Технологическая архитектура определяет набор принципов и стандартов, которые обеспечивают руководства в отношении выбора и использования таких технологий как – – – – – – – – – – аппаратные платформы, операционные системы, системы управления базами данных, средства разработки, языки программирования, ПО промежуточного слоя, сервисы электронной почты, каталоги, системы безопасности, сетевая инфраструктура и т.д. Инфраструктурные сервисы • • • • Инфраструктурные сервисы, в основном, стандартизированы в рамках предприятия и используются сразу несколькими прикладными системами, расположенными над уровнем инфраструктурных сервисов и непосредственно обеспечивающих выполнение бизнес-процессов. При наличии необходимой инфраструктуры новые прикладные системы, которые потребуются предприятию для выполнения новых бизнес-процессов или реализации новых стратегий, могут быть созданы достаточно быстро и эффективно. Одной из частных задач, решаемых в рамках технологической архитектуры, является формирование "списка закупаемых технологий". Инвестиции в инфраструктуру ИТ являются крупными и долговременными, при этом они не имеют определенной ценности для бизнеса с точки зрения получения конечных результатов. Но ценность инфраструктуры заключается в ее способности быстро и экономически эффективно обеспечить реализацию новых прикладных систем в интересах различных подразделений предприятия Уровни размещения инфраструктуры Архитектурные компоненты (сервисы) Gartner • Сервисы данных: системы управления базами данных (технологии баз данных и методы доступа к базам), хранилища данных, системы поддержки принятия решений (Business Intelligence – средства анализа и средства подготовки отчетов). • Прикладные сервисы: языки программирования, средства разработки приложений (средства моделирования баз данных, репозитории, методики разработки приложений, средства обеспечения качества), системы коллективной работы (средства групповой работы и электронной почты, средства управления документами), архитектура приложений (модель компонент, серверы приложений, серверы поддержки тонких клиентов), геоинформационные системы и средства. • Программное обеспечение промежуточного слоя (middleware). Архитектурные компоненты (сервисы) Gartner • Вычислительная инфраструктура: операционные системы и аппаратное обеспечение, среда для webинфраструктуры, системы хранения, средства системного управления (средства сетевого управления, администрирование IP), топологии (топология распределенных приложений). • Сетевые сервисы: локальные сети, глобальные сети, технологии доступа, голосовые технологии, сетевое аппаратное обеспечение. • Сервисы безопасности: авторизация, аутентификация, сетевая безопасность, физическая безопасность центров обработки данных, прочие сервисы безопасности (обнаружение вторжений, защита от вирусов). . Взаимосвязи функциональных и операционных требований с архитектурой приложений Охват и функциональные возможности инфраструктуры Адаптивная технологическая инфраструктура • Основными характеристиками адаптивной системы являются: – самоконфигурирование – организация системы в соответствии с требованиями; – самозащита – предотвращение сбоев в системе в результате нарушения работы компонент системы и потери целостности данных; – самовосстановление – диагностика неисправностей, локализация ошибок и устранение их последствий; – самооптимизация – наиболее рациональное использование имеющихся ресурсов без вмешательства оператора. Инфраструктура реального времени Жизненный цикл систем Использование архитектурных шаблонов • Шаблон – это общее решение некоторой повторяющейся проблемы в определенном контексте • Актуальность интеграции приложений и использования общих компонент информационных систем (сервисов) отражается в существующей тенденции их выделения в отдельные области архитектуры предприятия. Существенную роль при реализации этих областей играют стандартизованные элементы. Проект и реализация здания могут включать в себя элементы ранее созданных конструкций, может использовать уже известные фрагменты программного кода и/или типовые конфигурации оборудования. Это позволяет, с одной стороны, значительно сократить сроки выполнения решения, с другой – уменьшить риски за счет использования фрагментов, проверенных на практике. • • • Шаблон – решение проблемы в контексте Шаблон показывает, что делает некоторую модель хорошим решением и как создать некоторое решение для определенной проблемы. Ключевые понятия в шаблоне • Общее решение. Это означает, что шаблон не дает полного законченного решения. Он, скорее, определяет класс проблемы и то, как эта проблема может быть решена с использованием определенного подхода, с демонстрацией аргументов в пользу этого подхода. Сила шаблона состоит в том, что он сформулирован на достаточно высоком уровне абстракции, чтобы быть использованным в большом количестве ситуаций; • Повторяющаяся проблема. Это означает, что шаблоны используются в тех случаях, когда проблема не является уникальной, и они наиболее полезны для решения часто встречающихся проблем; • Определенный контекст. Это означает, что шаблон обеспечивает решение проблемы, границы которой в общих чертах определены. Понимая условия, в которых предлагаемое решение в форме шаблона является хорошим, вы далее строите свое собственное решение на основе этого шаблона. Важность шаблонов для архитектуры предприятия • если используются корректные шаблоны, то вероятность получения адекватно работающей физической реализации архитектуры возрастает; • разработка и использование шаблонов в рамках предприятия в целом обеспечивает преимущества, связанные с их многократным использованием для решения различных проблем; • использование шаблонов отделяет логический уровень от физического уровня архитектуры. Это позволяет создать долговременно работающие решения и придает гибкость, поскольку на последующем этапе эти достаточно постоянные конструкции могут быть связаны с конкретными технологическими решениями. • Описание шаблонов может выполняться с различной степенью детализации и соответствия реальным условиям. Архитектура, шаблоны и модели От традиционной архитектуры – к архитектуре, использующей инфраструктурные шаблоны Описание бизнес-шаблона • описание поддерживаемой бизнес-функции; • данные, которые требуются для выполнения описанной бизнес-функции; • бизнес-компоненты, которые являются представлением данных и функций бизнеса на языке информационных технологий; • возможно, описание инфраструктуры, которая необходима для поддержки функций, данных и компонент. Стандартизация решений • бизнес-шаблоны (Business pattern) предназначены для описания взаимодействия между участниками процесса; • шаблоны дизайна (Design pattern) отражают внутреннюю компонентную структуру системы; • шаблоны уровня приложений (Application pattern) определяют различные варианты взаимодействия между пользователями, приложениями и данными в системе, а также соответствующий прототип уровня выполнения; • шаблоны уровня выполнения (Runtime pattern) описывают привязку компонент системы к физическим узлам и определяют конкретные возможные продукты и их комбинации. Категоризация архитектурных шаблонов (общих служб) • • • • • • • • • • • преобразование данных (в частности, объединение/разделение, подстановки, округления, перевод c языка на язык, использование XSL для преобразования XML->XML и т п); маршрутизация сообщений (в том числе оптимизация маршрута, мультипликация/демультипликация для доставки один-ко-многим, динамическая маршрутизация в зависимости от содержания и т.п.); гарантированная доставка; репозиторий сообщений и метаданных; управление транзакциями, в том числе распределенными; планирование задач и активностей; журналирование и аудит; управление нагрузкой (в том числе поддержка кластеров, динамическая балансировка, горячая замена и т.п.); управление системами, в том числе обнаружение ошибок, мониторинг параметров; служба каталогов; безопасность, включая шифрование данных. Категоризация архитектурных шаблонов Microsoft Сервис-ориентированная архитектура (SOA) • Под сервис-ориентированной архитектурой понимается подход к проектированию прикладных информационных систем, который руководствуется следующими принципами: – явное отделение бизнес-логики прикладной системы от логики презентации информации; – реализация бизнес-логики прикладной системы в виде некоторого количества программных модулей (сервисов), которые доступны извне (пользователям и другим модулям), чаще всего в режиме "запрос-ответ", через четко определенные формальные интерфейсы доступа; – при этом "потребитель услуги", который может быть прикладной системой или другим сервисом, имеет возможность вызвать сервис через интерфейсы, используя соответствующие коммуникационные механизмы. • • В целом, SOA представляет собой модель взаимодействия компонент, которая связывает различные функциональные модули приложений (сервисы) между собой с помощью четко определяемых интерфейсов. Ориентация на сервисную архитектуру позволяет построить комплексную ссылочную модель архитектуры предприятия Ссылочная модель сервис-ориентированной Архитектуры предприятия Архитектура, управляемая моделями (MDA) • MDA является определенным обобщением идей SOA, с одной стороны, и повторно используемых программных компонент (шаблонов, паттернов) с другой, предназначенным прежде всего для повышения гибкости разрабатываемых приложений масштаба предприятия. • MDA основана на следующих принципах: – основой для разработки приложений масштаба предприятия являются детальные модели с общепринятой нотацией; – построение систем может быть организовано в соответствии с рамочной системой моделей, которые позволяют отделить бизнес-логику приложений от конкретной реализации; – существует формальное описание используемых моделей на основе системы метамоделей; – принятие и широкое использование этого подхода основано на открытости промышленных стандартов и на поддержке со стороны производителей соответствующих средств разработки. Создание прикладных систем в соответствии с подходом MDA Архитектура предприятия Лекция 8. Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF Контекст разработки архитектуры предприятия • Разработка архитектуры предприятия включает в себя компоненты, связанные с функциональной архитектурой (бизнесом), информационными технологиями и управлением архитектурным процессом), которая наглядно отражает, как различные компоненты взаимодействуют и влияют друг на друга. • Существуют различные подходы или методики (frameworks) к описанию архитектуры предприятия, которыезадают классификацию основных областей архитектуры и единые принципы для их описания во взаимной увязке друг с другом, описание используемых правил (политик), стандартов, процессов, моделей, которые используются для определения различных элементов архитектуры на разных уровнях абстракции. Общий контекст разработки Архитектуры предприятия Методики описания архитектуры предприятия • методики, опубликованные аналитическими компаниями Gartner, Giga Group, META Group; • модель Захмана; • методика TOGAF; • методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini. Требования к описанию ИТ-архитектуры • достаточно высокий уровень детализации для практического использования специалистами в области информационных технологий при разработке новых систем; • простоту для понимания бизнес-аудиторией; • динамику рассмотрения ("Архитектура как есть" – "Краткосрочные и среднесрочные задачи" – "Стратегические планы"); • возможность адаптации по новым требованиям бизнеса и учет возможностей реализации незапланированных (ad-hoc) проектов. Модель Захмана • «Модель Захмана» для описания архитектуры предприятия прошла определенную эволюцию в своем развитии и стала основой, на базе которой многие организации создавали свои собственные методики описания информационной инфраструктуры предприятия. • Дж. Захман определил Архитектуру предприятия как "набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)". • Модель преследует две основные цели – логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, – обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции. Модель Захмана Основные правила заполнения таблицы • каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы ("базис"); • порядок следования колонок несущественен; • каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа); • базовые модели для каждой из колонок являются уникальными; • соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы; • заполнение клеток должно проводиться последовательно "сверху вниз", попытка пропуска одного из рядов является, скорее, "шаманством" (в том плане, что нельзя создать хорошо работающую систему, "перепрыгнув" определенные уровни ее описания на этапе проектирования). Основные правила заполнения таблицы • • • • • • Первая строка соответствует уровню планирования бизнеса в целом (бизнесмодель ). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес. Вторая строка ( концептуальная модель ) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов. Третий уровень ( логическая модель ) соответствует рассмотрению с точки зрения Системного Архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем определенных на уровне бизнес-функций. На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Шестой уровень описывает работающую систему. На этом уровне могут быть введены, в том числе, такие объекты, как инструкции для работы c системой, фактические базы данных, работа службы HelpDesk. Основные характеристики модели Захмана • • • • • • простота для понимания как техническими, так и нетехническими специалистами; целостность в отношении предприятия, то есть каждая проблема может быть соотнесена с предприятием в целом; поддержка обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий; возможность применения для планирования, позволяющего лучше принимать решения за счет того, что решение никогда не будет выноситься "в пустоте" (в отрыве от остальных аспектов деятельности предприятия); применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия Предприятия как целого; нейтральность, то есть независимость от каких-либо инструментов; благодаря этому каждый инструмент и методология могут быть отображены на данную модель и могут явно показать, что они делают и чего они не делают. Модель Extended Enterprise Architecture Framework • Существует большое количество модельных схем, которые в той или иной мере используют данный подход, хотя визуальное представление модели в целом может достаточно сильно отличаться. Одним из таких примеров может служить предложенная Институтом разработок архитектуры предприятия модель Extended Enterprise Architecture Framework (E2AF). • Эта модель содержит 4 области рассмотрения (бизнес, информация, информационная система, технологическая инфраструктура) и следующие 6 уровней абстракции: – – – – – – контекстуальный (Зачем?) уровень взаимодействия (с Кем?) концептуальный (Что?) логический (Как?) физический (с помощью Чего?) трансформационный (Когда?) Модель 4-доменной архитектуры • Модель 4-доменной архитектуры (Four Domains architecture, FDA), в которой предлагается провести условное разбиение ячеек исходной модели Захмана на 2 компоненты – архитектуру описания (Architecture-in-Design) – архитектуру исполнения (Architecture-in-Operation). • При этом первая компонента описывает ход, средства и артефакты процесса разработки архитектуры предприятия, а вторая предназначена для описания непосредственно бизнес-процессов и реализации ИТ-систем. Структура и модель описания Gartner • Матричное представление, в котором для каждой из основных областей архитектуры ИТ (данные, приложения, интеграция, общие сервисы, и инфраструктура) последовательно накладывается несколько спецификаций, отличающихся по уровню детализации и конкретизации: – Бизнес-потребности, которые определяют ключевые требования к конкретной технологии для данной индустрии и организации. Другой важный аспект связан с позиционированием ИТ в организации. – Принципы, которые включают в себя основополагающие подходы, которых придерживается руководство. – Процессы и руководства во всех областях жизненного цикла элементов архитектуры. Этот раздел может охватывать такие области как документирование требований пользователей, стили программирования, процессы обеспечения качества или управление конфигурациями устройств и систем. – Раздел Протоколы и Стандарты описывает те промышленные протоколы и стандарты, которые должны поддерживаться используемыми в организации технологиями. – Раздел Используемые продукты и технологии является, утвержденным для организации списком продуктов или технологий., которые закупаются и используются для создания приложений. • Таким образом, данный подход позволяет обеспечить отслеживание логической связи между выбранными технологиями, их ценностью для бизнеса и потребностями бизнеса. Уровни модели архитектуры Gartner • Среда бизнесвзаимодействия (Business Relationship Grid); • Бизнес-процессы и стили бизнес-процессов; • Шаблоны; • Технологические строительные блоки (кирпичики – bricks). Архитектура ИТ в бизнес-контексте Полная модель Gartner • Представляет собой "трехмерную" комбинацию бизнесархитектуры, технической и информационной архитектур. • При этом описанные слои среды бизнес-взаимодействия, стилей бизнес-процессов, шаблонов и строительных блоков пересекаются со слоями Информационной архитектуры (Домен данных, Домен приложений, Домен интеграции, Домен доступа) и Технической архитектуры (Домен инфраструктуры, Домен системного управления и Домен безопасности. • Данный подход Gartner представляет собой пример реализации методологии достаточно высокого уровня. • Он задает только общую рамочную модель описания и фактически не определяет ни форматов, ни какого-либо специализированного языка для описания. Методика META Group • архитектурная методика META Group рассматривает архитектуру предприятия в интеграции с другими ключевыми процессами, в частности, с процессом управления корпоративными ИТ-программами и проектами (EPM – Enterprise Program Management) и процессом выработки стратегии и планирования. В частности, отмечается, что архитектура, собственно говоря, и реализуется на практике через процесс управления ИТ-программами и проектами. • Объединяющим для всех доменов архитектуры META Group является процесс формулировки бизнес-требований к ИТархитектуре: Видения общих требований (CRV – Common requirements Vision) и Принципах концептуальной архитектуры (CA – Conceptual Architecture). Компоненты Архитектуры предприятия META Group Организация рабочего процесса разработки архитектуры • Организация рабочего процесса разработки архитектуры и быстрое создание начальной версии архитектуры предприятия, согласно META Group, состоит в прохождении следующих этапов. – На этапе 1 разрабатывается Видение общих требований. – Этап 2 состоит в разработке Концептуальной архитектуры, которая определяет логически связанный набор принципов, обеспечивающий общее руководство для развития информационных систем предприятия и технологической инфраструктуры. – Этап 3 состоит в разработке плана реализации, обеспечивающего миграцию в сторону желаемого состояния архитектуры. Этап 1. Видение общих требований • Разработка Видения общих требований включает в себя: – анализ тенденций развития внешней для предприятия среды, включая технологические тенденции; – бизнес-стратегии и основные движущие силы с точки зрения бизнеса; – требования к информационным системам со стороны бизнеса; – требования к технологической архитектуре, которая обеспечивает адекватные возможности для информационных систем с точки зрения потребностей бизнеса. Пример компоненты Видения общих требований Тенденция Задержки в предоставлении услуги затрагивают 20% клиентов Бизнес-стратегия предприятия Процесс обслуживания, уменьшающий ожидание клиента, приведет к увеличению доли рынка Требования к информационным системам Требования к архитектуре Информация о ИТ-инфраструктура заказах, независимо от должна обеспечивать канала и места их управляемый доступ и получения, должна своевременную немедленно передачу передаваться в информации, чтобы производство обеспечить операционную эффективность Этап 2. Разработка Концептуальной архитектуры • Концептуальная архитектура разрабатывается еще до создания других архитектурных доменов и основана на принципах: – принципы представляют собой содержательные утверждения, которые касаются архитектурного процесса или содержания архитектуры; – принципы являются ограниченным числом точек стабильности, на которых строится архитектура; – принципы задают систему ценностей для архитектуры в целом. • Результатом разработки принципов концептуальной архитектуры является выделение в технологической архитектуре (EWTA) набора доменов (предметных областей), которые объединяют группы связанных между собой технологий и компонент. Структура описания доменов технологической архитектуры Структура описания доменов • • • • • • • • Документ, описывающий каждый домен технологической архитектуры, включает следующие компоненты: Формулировка миссии домена: стратегические цели домена. Описание компонентов домена: это обеспечивает общее понимание включенных в домен технологий. Принципы проектирования, принятые в домене. Они определяют правила, применяемые в процессе принятия решений в отношении технологий домена, а также обоснования и последствия принятия этих принципов. Стандарты: продукты и технические стандарты, которые обеспечивают требования к технологической архитектуре. Выделяют стратегические (предпочтительные) стандарты, переходные (которые используются временно), устаревшие (которые, возможно, еще используются, но от которых организация отказывается) и исследовательские или новые (которые находятся только на этапе рассмотрения и апробации). Лучшие практики. Конфигурации. Они формулируются в тех случаях, когда нужно уменьшить сложность принятия решений или когда можно уменьшить общую стоимость владения за счет стандартных конфигураций. Несоответствия между существующим состоянием домена технологической архитектуры и желаемым состоянием. Это служит основой для последующих работ группы, которая отвечает за данный домен архитектуры. Технологическая модель предприятия Этап 3. Разработка плана реализации • В полном описании методики META Group приводятся также следующие аспекты: – практическая реализация архитектуры через процесс управления корпоративными ИТпрограммами и проектами; – вопросы управления и контроля архитектурного процесса (governance); – оценка зрелости архитектуры; – анализ технологических тенденций и планирование; – управление портфелем ИТ-активов и проектов. Методика TOGAF