Контрольная работа по «Архитектура предприятия»

Информационная архитектура (Enterprise Information Architecture, EIA), или архитектура  информации, – это (с точки зрения аналитиков компании Meta Group) управляемый набор методик, описывающий информационную модель предприятия и включающий:

• базы данных и хранилища данных;

• информационные потоки (как внутри организации, так и связи с внешним миром).

Информационную архитектуру предприятия  условно можно назвать уровнем  потоков данных. Но при построении информационной архитектуры предприятия  нет необходимости создавать  модели всех видов данных, используемых на предприятии. Достаточно обеспечить выбор наиболее важных (критичных  для предприятия) данных и моделировать их на высоком уровне абстракции.

Архитектура прикладных решений (Enterprise Solution Architecture, ESA), или, другими словами, архитектура приложений, включает совокупность программных продуктов и интерфейсов  между ними.

Архитектуру прикладных решений разделяют  на два направления:

• область разработки прикладных систем;

• портфель прикладных систем.

Область разработки прикладных систем описывает технологическую часть  архитектуры прикладных решений  и включает программные продукты; модели данных; интерфейсы; пользовательские интерфейсы.

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

• компоненты и структура системы – внутренняя структура системы, включающая информацию о программных модулях и базах данных;

• взаимодействие с другими системами (интерфейсы) – описывает взаимодействие приложения с внешними объектами (программными продуктами, пользователями).

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

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

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

Ответ:

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

Основная сложность обоснования  необходимости архитектурного проекта  и выделения соответствующих  инвестиций связана с тем, что  прогнозируемые результаты обычно предполагают косвенное улучшение бизнеса  организации, то есть являются, как  правило, качественными и редко  могут быть связаны с конкретными  финансовыми выгодами. Даже в том  случае, когда бизнес-показатели типа "увеличение стоимости акций компании" или "доля на рынке" измеримы, конкретные связи между ними и проведенным  реформированием архитектуры предприятия  обычно бывают трудно доказуемы. Доля таких компаний не превышает величины порядка 5%. При этом аналитики МЕТА отмечают, что в настоящее время  более чем в 70% компаний ИТ-служба все еще является центром затрат, а более 90% ИТ-служб не имеют согласованных с бизнес-руководством финансовых моделей, позволяющих количественно измерить эффект от внедрения ИТ для бизнеса.

С точки зрения обоснования цифр экономии практически невозможно дать какие-то общие, применимые на все случаи, оценки затрат, связанных с отсутствием  архитектуры ИТ. Это зависит от уникальности ситуации в каждой конкретной организации. Экономия может быть достигнута, в частности, за счет сокращения расходов, связанных с повторным использованием оборудования или программного обеспечения, за счет сокращения времени разработки, оптимизации расходов на ведение  проектов, снижения стоимости технической  поддержки, приобретения новых активов  или экономии за счет более простой  адаптируемости системы, построенной  на базе единой архитектуры, к изменению требований бизнеса. Последняя составляющая выгоды обычно становится заметной при сравнении затраченных усилий, средств и времени для проведения изменений в различных подразделениях организации с отличающимися исходными архитектурами. В целом, по данным опроса META, снижение величины расходов на ИТ в расчете на одного сотрудника в случае реализации единой корпоративной архитектуры может достигать величины порядка 30%. По оценке Gartner отсутствие архитектуры приводит к 12-18% дополнительных затрат, связанных только с эксплуатацией ИТ-инфраструктуры.

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

Во многих организациях информационные технологии уже исчерпали возможности  по повышению продуктивности в таких  областях, как скорость выполнения транзакций и бизнес-процессов. Поэтому  традиционное обоснование инвестиций в информационные технологии, заключающееся  в подсчете возврата на инвестиции (ROI – Return on Investment), может не обеспечить должного результата. Показатель ROI требует возврата инвестиций в рамках рассматриваемого проекта, поэтому этот показатель является тактическим по своей природе и не адекватным для задачи обоснования инвестиций в архитектуру информационных технологий.

Инвестиции в архитектуру предприятия, эффект от использования которой  может быть не столь очевиден в  течение трех-пяти лет, требуют иных мер оценки эффективности. Возможной  стратегической альтернативой является величина "Возврата на основные фонды" (ROA – Return on Assets), которая будет стимулировать  компанию оценивать архитектуру  ИТ с точки зрения повышения эффективности  своих основных фондов. Другим полезным показателем может быть "Возврат  на возможность" (Return on opportunity). Он не является формальной финансовой метрикой, но описывает влияние инвестиций на бизнес. Подробнее обсуждение возможных  финансовых инструментов содержится в курсе "ИТ-стратегия".

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

Если бизнес-руководители (которые, в конце концов, выделяют все необходимые  финансовые ресурсы) не поддержат усилия по выработке архитектуры ИТ, то им стоит готовить себя к еще большим  затратам в будущем, поскольку они  неизбежно окажутся в ситуации, когда  они зададут себе вопрос: "Почему же мы тратим так много средств  для получения таких посредственных услуг от ИТ-службы?"

При обосновании проекта разработки архитектуры полезными может  быть перечисление тех преимуществ, которые были приведены в лекции 2.

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

5. Модель Захмана.

Ответ:

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

В схеме Захмана строке соответствует  точка зрения какого-либо участника  проекта по созданию системы. Аспекты  представлены в схеме колонками. 
 
Архитектурное представление - это ячейка таблицы, соответствующая пересечению выбранного столбца и выбранной строки. Например, с точки зрения разработчика (технологическая модель) информационное архитектурное представление (данные) - это проект структуры данных. Взгляд какого-либо лица - это совокупность ячеек в пределах одной строки (точки зрения), то есть совокупность архитектурных представлений с выбранной точки зрения, соответствующая выбранным аспектам системы. 
 
Захман определяет архитектуру как представление конечного продукта (в данном случае информационной системы) с точки зрения одного из заинтересованных лиц. Таким образом, существует не одна архитектура, а некое множество архитектур. В зависимости от того, кем Вы являетесь и на каком аспекте фокусируете внимание, Вы видите архитектуру системы по-разному.  
 
Это не в чистом виде методология описания архитектуры, а скорее некоторая практика или способ классификации архитектурных описаний некой системы или приложения, позволяющий взглянуть на архитектуру под разными углами зрения и получить максимально полную картину. Описание архитектуры по Захману представляет собой матрицу или таблицу Захмана. В строках таблицы расположены основные представления (или точки зрения) на архитектуру, а в столбцах архитектурные аспекты выраженные простыми вопросами, почему, как, что, кто, где, когда и т.п. Каждая ячейка таблицы представляет собой уникальное, не пересекающееся с остальными, описание архитектурного аспекта на заданном уровне представления, выраженное при помощи соответствующей модели.  
 
Расшифровка строк таблицы:  
 
Planner's View (Scope, Contextual level) - общее, высокоуровневое видение архитектуры решения с точки зрения инвестора или заказчика. 
Owner's View (Enterprise or Business Model, Conceptual level) - уровень бизнеса, бизнес-сущностей и бизнес-процессов, то есть взгляд с точки зрения пользователей данного решения. 
Designer's View (Information Systems Model, Logical level) - представление системного аналитика о решении на уровне информационных моделей, функциональных требований к решению и потоков данных. 
Builder's View (Technology Model, Physical level) - представление архитектора, нацеленное на использование конкретных технологий, языков программирования, устройств и платформ. 
Subcontractor View (Detailed Specifications, Detailed level) - уровень детализированного представления о внутреннем устройстве всех компонентов решения, нацеленный на разработчиков и программистов. 
 
Расшифровка столбцов таблицы:  
 
What - описание данных 
How - описание поведения и функциональности 
Where - описание компонентов и их размещения 
Who - описание участников и ролей 
When - описание временных аспектов 
Why - описание поведенческих аспектов 
 
Формализация данной модели базируется на наборе следующих правил:  
 
Столбцы таблицы равнозначны и их положение взаимозаменяемо. Количество столбцов не может быть увеличено или уменьшено. 
Каждый столбец определяет простую общую модель и обладает собственной метамоделью. 
Базовая модель для каждого столбца должна быть уникальна. 
Каждая строка описывает уникальное представление архитектуры и бизнес группу, которой это представление интересно. Описанные представления присутствуют в большинстве иерархически организованных бизнесах. 
Каждая ячейка таблицы уникальна и описывает конкретный кейс. 
Полный набор моделей из всех ячеек одной строки формируют полную модель архитектуры с данной точки зрения.

6. Использование методики Gartner для построения архитектуры государственных структур.

Ответ:

 
     Одним из возможных, достаточно простых форматов описания архитектуры является простое матричное представление, которое для каждой из основных областей архитектуры ИТ, таких как данные, приложения, интеграция, общие сервисы, и инфраструктура, "последовательно накладывает" несколько спецификаций, отличающихся по уровню детализации и конкретизации: 
 
 
Бизнес-потребности, которые определяют ключевые требования к конкретной технологии для данной индустрии и организации. Фактически здесь определяется индивидуальность архитектуры. Другой важный аспект связан с позиционированием ИТ в организации – либо ИТ-архитектура формируется для максимального уменьшения издержек, либо она должна обеспечивать возможности быстрых изменений и высокую гибкость. Другие примеры могут включать быстрое распространение информации, высокую безопасность, простоту использования и требуемую степень надежности. 
 
Принципы, которые включают в себя те основополагающие подходы, которых придерживается руководство. Например, это может быть принцип максимального использования стандартных приложений вместо заказных разработок, правила относительно того, кто владеет данными и пр. Большинство организаций могут иметь от 20 до 30 таких базовых принципов. 
 
Процессы и руководства во всех областях жизненного цикла элементов архитектуры. Этот раздел может охватывать такие области как документирование требований пользователей, стили программирования, процессы обеспечения качества или управление конфигурациями устройств и систем. Здесь также могут быть определены "эталонные модели" для организации пользовательского интерфейса, доступа к данным, управления содержанием. 
 
Раздел Протоколы и Стандарты описывает те промышленные протоколы и стандарты, которые должны поддерживаться используемыми в организации технологиями. 
 
Раздел Используемые продукты и технологии является, по сути дела, утвержденным для организации списком продуктов или технологий. Они закупаются и используются как для создания приложений, так и для формирования инфраструктуры и обеспечения интеграции с внешними системами. Эта часть содержит взвешенную оценку всех "за" и "против" о конкретных поставщиках. 
 
Таким образом, данный подход позволяет обеспечить отслеживание логической связи между выбранными технологиями, их ценностью для бизнеса и потребностями бизнеса. Выбор не должен быть сделан просто по той причине, что это "крутая" технология или что эта технология уже фактически используется. 
 
В 2002 году Gartner сформулировала новую концепцию архитектуры предприятия, которая стала определенным обобщением рассмотренной ранее модели ИТ-архитектуры на уровень Бизнес-архитектуры, косвенным отражением растущей важности вопросов взаимодействия предприятий между собой, влияния концепций сервис-ориентированной архитектуры, осознания того факта, что существуют различные стили архитектуры информационных систем, соответствующие различным стилям бизнес-процессов. Мы уже отмечали выше, что типичными стилями бизнес-процессов являются массовая обработка транзакций, операции в реальном времени, аналитические процессы и бизнес-анализ, совместная работа. 
 
Эта модель в какой-то степени расширяет рассмотренные выше представления, а также подчеркивает взаимосвязь между понятиями "Электронной нервной системы" предприятия, которые были сформулированы в свое время Биллом Гейтсом, основателем, а ныне Председателем и Главным архитектором программного обеспечения компании Microsoft, и практической реализации этих идей в рамках современных подходов к проектированию архитектуры ИТ предприятия. Кстати, обратите внимание, как называется должность Билла Гейтса. Не является ли это еще одним подтверждением важности вопросов систематического построения и описания архитектуры? 
 
Билл Гейтс в своей книге "Бизнес со скоростью мысли" [5.12] дал следующее определение: "электронная нервная система есть совокупность электронных процессов, с помощью которых организации воспринимают мир и адекватно реагируют на изменения, происходящие в нем". 
 
Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней: