Рамки Захмана описывают архитектуру предприятия по двум аспектам заинтересованных сторон и перспективам предприятия. Структура - это схема классификации, которую утверждает Захман, полная, поскольку она содержит все существующие ячейки. В структуре есть 36 ячеек. В текущей форме архитектуры строки представляют различные заинтересованные стороны. Заинтересованные стороны сверху вниз:

1. Первая строка, SCOPE, устанавливает контекст для любого проекта системы предприятия.

2. Второй ряд, ENTERPRISE MODEL, представляет вид владельца бизнеса, который определяет в бизнес-условиях характер бизнеса, включая его структуру, функции, организацию и т. Д.

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

4. Четвертая строка, ТЕХНОЛОГИЧЕСКАЯ МОДЕЛЬ, представляет собой представление строителя, технологическое представление, описывающее, как функционируют функции системы, информация, организация и т. Д.

5. Пятая строка, COMPONENTS, представляет код, который реализует приложение. Человек, выполняющий эту функцию, является исполнителем.

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

1. Первый столбец DATA - это «Какие» вещи, которые участвуют в предметной области. Данные состоят из списка вещей.

2. Второй столбец FUNCTION - это «Как» делаются. Это состоит из списка процессов, которые выполняются.

3. Третий столбец NETWORK - это «Где» делаются. Это может быть список местоположений или сетевых узлов, которые необходимо поддерживать, чтобы обеспечить возможность захвата и использования знаний в предметной области

4. Четвертый столбец «ЛЮДИ» - это «Кто», который является частью предприятия. Он содержит модели о людях и организациях в рамках бизнеса

5. Пятая колонка TIME - это «Когда» что-то сделано. Это может быть фиксированное время, которое запускает процесс, время события, которое запускает другой процесс, или последовательность времени, в которой говорится, что этот процесс должен быть выполнен до последующего процесса

6. Шестая колонка «МОТИВАЦИЯ» - это «Почему». Здесь перечислены бизнес-цели и стратегии. Эти цели и стратегии могут быть выражены в виде предложений на естественном языке

 Вопрос №26. Фреймворк TOGAF.

Методология TOGAF (The Open Group Architecture Framework) представляет собой инфраструктуру архитектуры предприятия, которая появилась 20 лет назад для разработки стандарта архитектуры предприятия. Фреймворк разработан независимым консорциумом The Open Group, для установки открытых стандартов в области информационных технологий.

TOGAF включает в себя 7 частей:

1. Введение. Описание ключевых концепций.

2. Методы разработки архитектуры.

3. Руководящие принципы и методы.

4. Содержимое фреймворка архитектуры.

5. Континуум предприятия и инструменты.

6. Эталонная модель TOGAF.

7. Архитектурная возможность фреймворка.

Бизнес-архитектура – описывает процессы, которые бизнес использует для достижения своих целей. Это связывает разработку стратегии с реализацией стратегии.

Архитектура приложения – описывает, как разрабатываются конкретные приложения и как они взаимодействуют друг с другом.

Архитектура данных – описывает ресурсы логических и физических данных предприятия и как они управляются.

Техническая архитектура – описывает аппаратную и программную инфраструктуру, которая поддерживает бизнес-процессы, приложения и их взаимодействия. В TOGAF процессы реализации архитектурных решений описаны в цикле ADM. ADM можно нужно изменять и адаптировать под нужды компании. Нет необходимости делать все документы или погружаться во все детали. На каждом последующем этапе ADM предлагает готовый набор инструментов и шаблонов, так называемый конструктор. Ниже на приведена схема ADM (рис. 2)

Вопрос №27. Фреймворк ARIS.

Методология ARIS рассматривает предприятие как совокупность пяти взглядов: взгляд на организационную структуру (Organizational View), взгляд на структуру функций (Function View), взгляд на структуру данных (Data View), взгляд на структуру процессов (Control View) и взгляд на структуру конечных продуктов и услуг и обмена информацией с потребителем (Product / Service View). При этом каждый из этих взглядов разделяется еще на три подуровня: формулировка требований, описание спецификации, описание реализации. Таким образом, ARIS предлагает рассматривать организацию с позиции 15 аспектов, отображающих разные взгляды на предприятие, а также разную глубину этих взглядов. Для описания бизнес-процессов предлагается использовать более 100 типов моделей, каждая из которых принадлежит тому или иному аспекту. Среди большого количества возможных методов описания можно выделить следующие: EPC (event-driven process chain) - метод описания процессов, нашедший применение для описания процессов системы SAP R/3; ERM (Entity Relationship Model – диаграмма связи сущностей) – модель сущностей-связей для описания структуры данных; UML (Unified Modeling Language) – объектно-ориентированный язык моделирования, Organizational Chart – диаграмма для описания организационной структуры.

На уровне формулировки требований (Requirements Definition) необходимо описать программное решение (прикладную информационную систему) для рассматриваемой проблемы бизнеса. Оно должно поддерживаться формализованным описанием требований с целью последующего использования в качестве стартовой точки для трансляции сформулированных требований в программную систему. Этот процесс также очень близок к семантическому (смысловому) моделированию. Формулировка требований тесно связана с описанием проблем бизнеса.

Уровень спецификации проекта (Design Specification) достигается, как только концептуальные понятия проблем бизнеса, сформулированные на уровне формулировки требований, трансформируются в категории, связанные с информационными технологиями. На данном уровне описываются уже не функции, а пользовательские или модульные транзакции, которые выполняют функции, как это было определено ранее. Это может рассматриваться как отображение сформулированных требований в категории и методы описания, связанные непосредственно с ИС и выраженные в терминах информационных технологий. Таким образом, уровни формулировки требований и спецификации проекта связаны достаточно тесно.

На уровне описания реализации (Implementation) спецификация проекта трансформируется в конкретные аппаратные и программные компоненты. Таким образом, осуществляется физическая связь с информационной системой. Отдельные уровни описания имеют различные циклы корректировки. Частота корректировок выше всего на уровне описания реализации и ниже всего на уровне формулировки требований. Уровень описания реализации очень тесно связан с разработкой информационной системы: на этом уровне производится многократная корректировка функционирования системы по результатам коротких циклов (тестов) ее работы. В архитектуре ARIS, как было показано, каждый взгляд подвергается разложению на три уровня: формулировку требований, спецификацию проекта и описание реализации.

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

Несмотря на все преимущества методологии ARIS, часто можно услышать упреки в ее адрес, связанные с излишней «академической» сложностью правил построения диаграмм. Как показывает практика, подобные особенности способны оттолкнуть заинтересованную сторону, которая, несмотря на огромное количество очевидных преимуществ, заставляют использовать их собственное, более понятное и удобное, представление для моделирования, при этом, как правило, используется достаточно примитивный и неудобный для описания крупных организаций инструмент MS Visio.