Архитектура интеграции. Определяет инфраструктуру для интеграции различных приложений и данных. Например, в проектах в области "электронного правительства", когда имеется большое количество государственных информационных систем различных ведомств, возникает настоятельная потребность создания самостоятельной инфраструктуры интеграции (архитектура интеграции), с целью предоставления государством интегрированных услуг гражданам и бизнесу по принципу "одного окна".
Архитектура общих сервисов. Примерами их являются такие сервисы, как электронная почта, каталоги, общие механизмы безопасности (идентификации, аутентификации, авторизации). То есть, это достаточно большое количество прикладных систем, которые носят "горизонтальный характер".
Сетевая архитектура. Определяет описания, правила, стандарты, которые связаны с сетевыми и коммуникационными технологиями, используемыми в организации.
Архитектура безопасности и т.д.
Бизнес - архитектура предприятия (EBA-EnterpriseBusinessArchitecture) – это целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес - целями. В ходе построения бизнес - архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура
Модели:
Классическая или, другими словами, эталонная архитектура предприятия является идеальной моделью построения организации.
Специализированная архитектура – включает в себя модели, ориентированные на предприятия определенных отраслей или определенные фазы производства. В основе специализированных методологических моделей, как правило, лежат исторически сложившиеся алгоритмы управления в данных отраслях (например: банки, химическая промышленность, телекоммуникации).
Специфическая архитектура - так обычно называют исторически сложившуюся на данном предприятии модель бизнес - процессов.
Элементы:
Миссия и видение.
Руководящие принципы.
Цели, задачи и стратегии.
Архитектура информационных технологий.
Политики (правила).
ИТ-стандарты.
Процедуры. Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе.
Руководства или рекомендации (guidelines).
Реализация целей, задач и стратегий достигается через соответствующие ИТ-проекты, которые формулируются в планах на очередной период деятельности.
Инструменты моделирования
Декомпозиция бизнес-процессов
Анализ бизнес – событий
позволяет построить зависимость бизнес-процессов и бизнес – событий, понять какие события, что инициируют. Анализ бизнес - событий позволяет перейти к анализу данных, используемых предприятием.
Модель местоположения
описывает географическое расположение выполняющихся бизнес-функций. Модель местоположения позволяет провести визуализацию организационных единиц и определение мест выполнения бизнес-процессов.
Модель интеграции
определяет связь бизнес-процессов и бизнес - событий.
Ниже приведены примеры общих принципов, связанных с архитектурой в целом:
Все подразделения (ведомства) должны использовать в своей работе архитектуру, разработанную для организации (правительства) в целом.
Функциональное руководство и руководство в области ИТ должно основываться на общем видении.
Архитектура должна обеспечивать решение вопросов бесперебойного выполнения организациями своих функций, безопасности и восстановления в случае катастрофических событий.
Функциональные (бизнес-) требования должны формировать архитектуру.
Архитектура должна обеспечивать совместимость и взаимодействие.
Архитектура должна быть расширяемой, масштабируемой и адаптивной.
Архитектура должна быть инструментом реализации изменений.
Архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнес-процессов.
Тенденции рынка должны учитываться при проектировании технологической архитектуры.
Еще раз отметим, что эти принципы могут показаться слишком общими. Проще всего "списать" набор таких утверждений с чужих документов. Но дело в том, что принципы начинают работать только тогда, когда они являются результатом широкого и вдумчивого обсуждения с участием представителей различных структурных подразделений как со стороны бизнеса, так и сотрудников, отвечающих за ИТ, когда причины и последствия их принятия всеми хорошо осознаются и задокументированы и когда реализация этих принципов закреплена в конкретных процедурах.
В ходе разработки архитектуры информации решаются следующие задачи:
идентификация и инвентаризация существующих данных, включая определение их источников, процедур изменения и использования, ответственность, оценка качества;
сокращение избыточности и фрагментарности данных с целью уменьшения затрат на устройства хранения, стоимости их обслуживания, а также повышение качества данных за счет исключения неоднозначности и противоречивости различных экземпляров;
исключение ненужных перемещений или копирования данных, особенно связанных с наличием большого количества унаследованных или устаревших приложений;
формирование интегрированных представлений данных, таких как витрины и хранилища; обеспечение доступности данных в режиме, приближенном к режиму реального времени, за счет использования средств обмена сообщениями, интеграционных брокеров и шлюзов;
интеграция метаданных, что позволит обеспечить целостное представление данных из различных источников;
сокращение числа используемых технологий и продуктов, что позволяет снизить расходы на обслуживание, а также получить дополнительные, объемные скидки от поставщиков применяемых продуктов;
улучшение качества данных, прежде всего, за счет привлечения бизнес-пользователей к управлению и определению данных;
улучшение защиты данных на основе использования последовательных и согласованных мер, обеспечивающих, с одной стороны, защиту от несанкционированного доступа, а с другой – доступность данных для их использования на практике.
Критическими факторами для обеспечения успеха процесса разработки архитектуры информации являются тщательное планирование и привязка к бизнес-целям предприятия. Обычно рекомендуется проводить анализ данных последовательно для каждого бизнес-процесса, выбирая их в порядке приоритета по важности.
Принципы архитектуры информации.
• Принцип объектов. Принцип предписывает рассматривать контент как развивающуюся сущность, которая имеет собственный жизненный цикл. Разный контент будет иметь разные атрибуты и поведение, и это нужно учесть при проектировании дизайна.
• Принцип выбора. Принцип означает, что вы должны предлагать вашим пользователям осмысленный выбор. Тем не менее, вы должны убедиться, что выбор будет сосредоточен на чем-то конкретном: слишком много вариантов может дезориентировать пользователя. Информацию тоже стоит подавать в виде иерархии, категорий и суб-категорий вместо того, чтобы приводить ее просто длинным списком.
• Принцип раскрытия. Важно дать пользователю необходимую ему информацию. Однако стоит убедиться, что это действительно то, что ему нужно, а не то, что вам захотелось дать. Принцип говорит также о том, что нужно сразу давать пользователю информацию, необходимую для понимания: что он сможет найти на других страницах сайта, а что нет. Информацию нужно подавать постепенно, от страницы к странице, а не пытаться вывалить все и сразу.
• Принцип примеров. Использование принципа существенно улучшает пользовательский опыт. Например, когда вы заходите в определенную категорию товаров на Amazon, на сайте выводятся примеры товаров, которые попадают в эту категорию. Это помогает пользователю быстрее сориентироваться, особенно, если он не до конца понимает, что значит название категории.
• Принцип парадного входа. Половина посетителей попадают на ваш сайт не через главную страницу. Это значит, что любая страница должна содержать необходимый минимум текстовой информации — чтобы пользователи поняли, где они находятся. Также это лишний раз подтверждает пункт 3, не нужно пытаться уместить всю информацию на домашней странице сайта.
• Принцип множественной классификации. Этот принцип говорит о том, что разные пользователи используют ваш сайт по-разному, у них могут быть разные методы для нахождения одной и той же информации. Например, одни будут пользоваться поиском, другие предпочтут поблуждать по сайту. Контент нужно адаптировать к различнымсценариям пользовательского поведения.
методика Gartner представляет собой реализацию методологии достаточно высокого уровня, но задает только общую рамочную модель описания и фактически не определяет ни форматов, ни какого-либо специализированного языка. В данной методике сформулированы важные и полезные рекомендации в виде последовательности шагов и задач участников, которые, однако, не детализированы до уровня моделей процесса разработки архитектуры.
Gartner рекомендует начать построение бизнес архитектуры с построения высокоуровневых моделей бизнес-процессов предприятия. Начальным этапом для этого является определение классов бизнес-процессов. Под классом бизнес-процессов понимается группа процессов, которые состоят из большого числа одинаковых бизнес-активностей. Далее рекомендуется выполнить следующие шаги:
Шаг 1. ИДЕНТИФИКАЦИЯ КРИТИЧЕСКИ ВАЖНЫХ ДЛЯ ПРЕДПРИЯТИЯ ПРОЦЕССОВ. Шаг 2. ОТСЛЕДИТЬ СВЯЗИ МЕЖДУ ЭТИМИ ПРОЦЕССАМИ И БИЗНЕС-СТРАТЕГИЯМИ, ДВИЖУЩИМИ СИЛАМИ И КРИТИЧЕСКИ ВАЖНЫМИ ФАКТОРАМИ УСПЕХА. Шаг 3. ПОСТРОИТЬ МОДЕЛИ ВЫСОКОГО УРОВНЯ ДЛЯ КЛЮЧЕВЫХ БИЗНЕС-ПРОЦЕССОВ. Шаг 4. ДЛЯ КАЖДОГО ШАГА ПРОЦЕССОВ, ИДЕНТИФИЦИРОВАННЫХ НА ЭТАПЕ 3, ОПРЕДЕЛИТЬ ОТВЕТСТВЕННЫХ ЗА ВЫПОЛНЕНИЕ ШАГА. Шаг 5. ИДЕНТИФИЦИРОВАТЬ И ДОКУМЕНТИРОВАТЬ ОСНОВНЫЕ КАТЕГОРИИ ИНФОРМАЦИОННЫХ ОБЪЕКТОВ
Декомпозиция бизнес-процессов– методика, описания бизнес-процессов в виде последовательной их детализации. Декомпозиция - это процесс создания диаграммы, детализирующей определенный блок и связанные с ним дуги. Результатом ее является описание, которое представляет собой "разламывание" родительского блока на меньшие и более частные функции. Декомпозиция бизнес-процессов обеспечивает их последовательную детализацию, определение границ основных организационных единиц. Декомпозиция позволяет определить вклад каждого из них в цепочку добавленной стоимости.
В ходе проведения декомпозиции бизнес процессов необходимо выполнить следующие шаги:
определить границы анализа за счет рассмотрения основных функций предприятия;
выделить ключевые бизнес-процессы;
выделить дублирующие бизнес-процессы и точки их пересечения.
Архитектура информации включает в себя модели, которые описывают процессы обработки информации (information value chain), основные информационные объекты, связанные с бизнес-событиями, информационные потоки, принципы управления информацией.
Таким образом, мы можем сказать, что архитектура информации включает в себя, в частности, такие области (а также связанные с ними стандарты, руководства и пр.), как:
федеративные данные (метаданные);
моделирование данных;
системы управления базами данных;
программное обеспечение промежуточного слоя (middleware) для доступа к данным;
механизмы доступа к данным;
безопасность данных.
Однако окончательный набор дисциплин, связанных с архитектурой информации, определяется, в итоге, потребностями предприятия.
Информационная архитектура (EIA Enterprise Information Architecture) – это управляемый набор
• Принцип целенаправленной навигации. Не так важно, где находится меню, важно то, что на нем написано. Постарайтесь, чтобы ваше меню и панель навигации показывали, где находится пользователь сейчас и куда он может попасть с текущей страницы.
• Принцип роста. На подавляющем большинстве сайтов контент — текучая, изменчивая сущность. Количество контента у вас на сайте сегодня может быть лишь малой долей того, чтобы там может быть завтра. Организуйте контент таким образом, чтобы позволять ему расти в будущем. Причем не только в плане расширения какого-то блока с текстом: контент может добавляться совершенно разных типов.
Одним из способов моделирования данных на логическом уровне является построение моделей "Сущности-Отношения"
19. Архитектура приложений. Основные элементы архитектуры приложений. Модели и инструменты управления портфелем приложений.
Архитектура приложений покрывает достаточно широкую область, которая начинается с идентификации того, какие прикладные системы нужны предприятию для выполнения бизнес-процессов, и включает такие аспекты, как проектирование, разработка (или приобретение) и интеграция прикладных систем. Хорошая архитектура приложений должна эффективно использовать технологическую архитектуру, чтобы обеспечить должный уровень соответствия всем операционным требованиям.