Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Архитектура предприятия вопросы к экзамену.docx
Скачиваний:
0
Добавлен:
01.04.2025
Размер:
2 Мб
Скачать
☆
  1. Текущая модель архитектуры предприятия.

Каждая информационная система представляет собой сложный, комплексный объект, который к тому же динамически изменяется во времени. Для упрощения мы можем выделить его наиболее существенные характеристики, которые и образуют архитектуру системы, понимаемую как компонентный состав системы и связи между ними. Такой подход позволяет с достаточной определенностью оценивать характеристики системы, планировать ее развитие и сравнивать различные системы. В то же время конкретная реализация информационной системы будет, наряду с архитектурой, "включать" все многообразие экземпляров данных, физическое расположение компонент, фактическую реализацию процессов управления и т.п. Таким образом, архитектура будет представлять собой некоторую модель реальной системы, которая динамически изменяется, сохраняя соответствие оригиналу. Второй постулат заключается в том, что выделяются два понятия: собственно архитектура информационной системы – как объективная реальность, включающая существующие компоненты и их связи; описание архитектуры (architecture description) – отражение объективной или планируемой реальности в какой-либо документированной форме. Разделение этих понятий приводит к интересным следствиям. Архитектура системы (внешняя область) по определению является бесконечно сложным, глубоким и неявным понятием. Только часть этого общего понятия, которая в принципе доступна для восприятия архитекторами, может быть переведена в явную документируемую форму – модель или набор моделей с неизбежными упрощениями, ограничениями и субъективными искажениями. Такая проекция и представляет собой "описание архитектуры". Поэтому при использовании подобных описаний при проектировании систем необходимо всегда помнить об их неизбежной неполноте. При этом совершенно уместным является остроумное замечание о том, что "все модели являются, в общем-то, неверными, но некоторые из них при этом являются полезными". Еще одно формальное определение приведено в стандарте IEEE 1471 Института инженеров-электриков и электронщиков, который предоставляет метамодель для определения архитектуры. Этот стандарт определяет такие абстрактные элементы архитектуры, как представления, системы, среды, обоснования, заинтересованные стороны и т.д. в соответствии со схемой.

В соответствии с этим представлением система обладает некоторой архитектурой, которая может быть определенным образом описана с различных точек зрения в зависимости от интереса тех людей (участников), которые рассматривают архитектуру системы. Каждой точке зрения на архитектуру системы соответствует определенное представление, основу которого составляет некоторый набор моделей. Однако этот стандарт не определяет структуру собственно архитектуры предприятия. Например, говорится о том, что необходимо иметь различные представления архитектуры, но при этом не указывается, какие это должны быть представления. В последнем случае понятие разработки системной архитектуры близко по смыслу понятию Системное проектирование. Вообще говоря, Системное проектирование (Systems Engineering – это междисциплинарный подход и средства, предназначенные для создания успешных систем. Он фокусируется на определении нужд потребителя и требуемой функциональности в начале цикла разработки, на документации требований, с переходом к конструкторскому синтезу и комплексной аттестации системы при полном учете таких проблем, как функционирование, производительность, испытания, изготовление, затраты и планирование, обучение и сопровождение, вплоть до вывода из эксплуатации. Системное проектирование интегрирует все нужные

дисциплины и группы специалистов в командные усилия, формируя структурированный процесс разработки, который выполняется от создания концепции до осуществления продуктивной работы системы. В системном проектировании учитываются как нужды бизнеса, так и технические потребности всех клиентов для получения качественного продукта, который отвечает потребностям пользователей.

4. Отслеживание параметров модели архитектуры предприятия.

Описание Архитектуры предприятия связано с большим количеством информации, которая поступает из различных источников и имеет различные форматы: текст, графические модели и пр. Кроме того, с этой информацией должно работать достаточно большое количество людей. Различные модели определенным образом связаны между собой, и эти связи необходимо также отслеживать для того, чтобы имелась возможность достаточно эффективного анализа архитектуры предприятия и влияния принимаемых решений.

Некоторые организации вполне могут обходиться без специализированных средств разработки архитектуры, ограничиваясь использованием графических пакетов типа Microsoft Visio для построения различных типов моделей (благо в этом пакете имеется для этого огромное количество шаблонов, а также использованием текстовых редакторов и электронных таблиц.

Однако по мере того, как количество различных артефактов (документов, моделей), создаваемых в процессе работы над архитектурой, растет, становится понятно, что использование только этих "подручных" средств приводит к потере качества, потере связей между артефактами и целостности описания архитектуры.

Для удовлетворения этих специфических потребностей в обеспечении архитектурного процесса появился целый класс программных продуктов. Перечислим названия некоторых компаний-разработчиков таких систем, многие из которых, за исключением последней, практически неизвестны на российском рынке: Casewise, Computas, Framework Software, Popkin Software, Proforma, Ptech, Rational Software.

Не описывая и не сравнивая различные системы, которые могут использоваться для разработки архитектуры предприятия, опишем основной функционал, который они могут предоставлять.

Различные планы, модели и документы, связанные с архитектурой, должны быть помещены в репозитории (специальной базе данных, созданной для хранения многих типов документов и диаграмм). Между ними должны быть установлены необходимые связи. При этом различные группы пользователей рассматривают различные категории информации и представления одной и той же архитектуры предприятия. Бизнес-менеджеров, например, больше будут интересовать диаграммы с информацией о бизнес-процессах. Менеджеров ИТ будут интересовать прикладные системы, связанные с этими бизнес-процессами, а на более глубоком уровне анализа их могут интересовать диаграммы, описывающие внутреннюю архитектуру этих систем.

Если архитектура документирована с достаточной степенью детализации, появляется возможность отслеживания влияния возможных изменений. Репозиторий может содержать, например, информацию о сотрудниках и затратах. При этом появляется возможность анализировать влияние изменений в бизнес-процессах на стоимость их выполнения. Эти средства должны обеспечивать хранение артефактов в репозитории в соответствии с принятыми методиками описания архитектуры, такими, например, как модель Захмана; и чем большее количество методик выбранное средство поддерживает, тем больше возможностей выбора у пользователей.

При этом многие модели и иная связанная с архитектурой предприятия информация, в любом случае, создается и будет создаваться с использованием других программных продуктов и инструментальных средств, поэтому средства разработки архитектуры предприятия должны иметь возможность использования внешних источников информации.

В идеале, это должен быть двунаправленный процесс. Например, модели бизнес-процессов могут быть уже подготовлены с помощью пакета ARIS, и выбранное средство описания архитектуры предприятия должно иметь возможность обмена с этой системой;

• персонифицированный доступ. Различные пользователи имеют различные области интересов и права по работе с моделями архитектуры.

• печать и публикация. Информирование всех заинтересованных сторон – важный аспект деятельности по разработки архитектуры, поэтому важны возможности как по печати достаточно сложных и больших диаграмм, так и средства доступа к этой информации с использованием, например, браузера;

• географические и организационные кросс-ссылки. Разные организационные структуры могут иметь различный набор систем;

• возможность настройки. Некоторые инструменты обеспечивают возможности адаптации заложенных в них стандартных архитектурных методик и моделей.

В достаточно сложных архитектурных проектах их использование может оказать существенную помощь. Однако при выборе поставщиков таких систем следует иметь в виду, что рынок этих систем сам по себе достаточно молодой и не вполне сформировавшийся, поэтому возможны быстрые изменения в списке компаний-участников и доступности тех или иных инструментальных средств.