пособие по архитектуре предприятия. пособие по архитектуре предприятия2. Пособие по дисциплине Архитектура предприятия Д. Р. Богданова, В. А. Котельников, Л. У. Минибаева Уфа 2015. 89с

• Название: Пособие по дисциплине Архитектура предприятия Д. Р. Богданова, В. А. Котельников, Л. У. Минибаева Уфа 2015. 89с
• Анкор: пособие по архитектуре предприятия
• Дата: 12.01.2021
• Размер: 1.76 Mb.
• Имя файла: пособие по архитектуре предприятия2.doc
• Тип: Пособие; #167343
• страница: 4 из 8

Вопросы

1. 
   В каких отраслях в мировом аспекте сосредоточены основные затраты на внедрение ИТ?
   
2. 
   Как распределяются статьи расходов на ИТ в частном секторе?
   
3. 
   В чем состоит суть первой модели Gartner «Кривой технологического ажиотажа»?
   
4. 
   В чем состоит суть второй модели Gartner «магических квадрантов Gartner»?
   
5. 
   В чем заключается важность архитектуры предприятия?
   
6. 
   Основные факторы эффективности эксплуатации ИТ-систем и соответствующих операций?
   
7. 
   Почему архитектура является средством снижения рисков и увеличения отдачи от инвестиций в ИТ?
   
8. 
   Когда стоит вкладывать средства в разработку архитектуры?
   
9. 
   Какие инвестиции необходимы для разработки архитектуры предприятия и архитектуры ИТ предприятия?
   
10. 
    При каких условиях наступает реальная отдача от инвестиций времени и средств в архитектуру?
    

3. Лекция: Архитектура предприятия: основные определения

Содержание

• 
  Архитектура: основные определения
  
• 
  Эволюция представлений об архитектуре предприятия
  
• 
  Контекст Архитектуры предприятия
  

3.1 Архитектура: основные определения

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

Архитектура информационных технологий и архитектура предприятия в целом как раз и является основным механизмом интерпретации и реализации целей организации через адекватные ИТ-инфраструктуру и системы. Это достигается через создание определенного количества взаимосвязанных архитектурных представлений. Имеется множество методик описания архитектуры, и все они разбивают архитектуру предприятия на различное количество моделей и определений, которые относятся к таким областям, как бизнес, информация, прикладные системы, технологическая инфраструктура.

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

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

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

"Архитектурный взгляд" на системы (как ИТ-системы, так и бизнес-системы) определен в стандарте ANSI/IEEE 1471-2000 как "фундаментальная организация системы, состоящая из совокупности компонент, их связей между собой и внешней средой, и принципы, которыми руководствуются при их создании и развитии".



Рис. 3.1.  Элементы архитектуры предприятия
В самом общем виде, в соответствии с определениями Gartner архитектура – это:

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

Обратите внимание, что первое определение сфокусировано на описании существующих и будущих систем, второе – на процессе их построения.

Еще несколько определений:

• 
  "Архитектура – это инвестиция в стандарты процессов, технологий и интерфейсов в целях улучшения возможностей организаций и уменьшения стоимости разработки и сопровождения информационных систем. Преимущества инвестиций в архитектуру распространяются на несколько проектов сразу, но не все эти проекты могут быть известны в момент разработки архитектуры";
  
• 
  "Корпоративная архитектура ИТ – это видение, принципы и стандарты, которыми организации руководствуются при разработке и внедрении технологий" (Giga Group)
  

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

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

Таким образом, ИТ-архитектура существует независимо от предпринимаемых в организации проектов по ее описанию, упорядочиванию и развитию. Более того, так как сама система неизбежно претерпевает изменения, то и ИТ-архитектура может со временем меняться даже без целенаправленной деятельности предприятия и его ИТ-службы. Еще одно формальное определение приведено в стандарте IEEE 1471 Института инженеров-электриков и электронщиков, который предоставляет метамодель для определения архитектуры. Этот стандарт определяет такие абстрактные элементы архитектуры, как представления, системы, среды, обоснования, заинтересованные стороны и т.д. в соответствии со схемой, показанной на рис. 3.2.



Рис. 3.2.  Рамочная модель разработки архитектуры по IEEE 1471
В соответствии с этим представлением система обладает некоторой архитектурой, которая может быть определенным образом описана с различных точек зрения в зависимости от интереса тех людей (участников), которые рассматривают архитектуру системы. Каждой точке зрения на архитектуру системы соответствует определенное представление, основу которого составляет некоторый набор моделей.

Однако этот стандарт не определяет структуру собственно архитектуры предприятия. Например, говорится о том, что необходимо иметь различные представления архитектуры, но при этом не указывается, какие это должны быть представления. Возвращаясь к предмету нашего обсуждения, можно рассмотреть различные аспекты понятия архитектуры ИТ. В частности, можно выделять такие подмножества, как системная архитектура (архитектура систем – System Architecture) и программная архитектура (архитектура программного обеспечения – Software Architecture.

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

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

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

3.2 Эволюция представлений об архитектуре предприятия

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

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

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




Рис. 3.3.  Эволюция термина "Архитектура предприятия
Следующей ступенью явилось понятие Корпоративной информационно-технологической архитектуры масштаба предприятия (EWITA – Enterprise-wide information technology architecture). Стало понятно, что усилия по описанию архитектуры предприятия должны включать в себя описание архитектуры информации и архитектуры прикладных систем, а не только технологический уровень. Основное направление работ при этом состоит в совместном использовании общих данных, исключении дублирования бизнес-функций, координации управления пользователями, ресурсами, информационной безопасностью за счет улучшений в управлении портфелем прикладных систем.

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

Такой подход обеспечивает более эффективное взаимодействие различных структурных подразделений организации:

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

Получаемые преимущества носят, в основном, тактический характер.

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

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

В графическом виде связь таких понятий, как бизнес-архитектура, корпоративная ИТ-архитектура и "архитектура предприятия", показана на рис. 3.4.




Рис. 3.4.  Позиционирование понятия "архитектура предприятия"
Эволюция представлений об архитектуре предприятия и получаемая на каждом этапе расширения соответствующих представлений дополнительная ценность условно показаны на рис. 3.5.

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

Если давать самое простое определение, то архитектура предприятия описывает, как организация выполняет свою работу, используя такие ресурсы, как Люди, Бизнес-процессы, Данные и Технологии. Еще одно определение заключается в том, что "...концепция архитектуры предприятия – это план реализации миссии организации через оптимальное выполнение своих ключевых бизнес-процессов в условиях формирования эффективной инфраструктуры информационных технологий".




Рис. 3.5.  Расширение представлений об "архитектуре предприятия" и дополнительные преимущества

Таким образом, архитектуру предприятия можно рассматривать как процесс трансформации новых бизнес-стратегий в основанные на информационных технологиях и реализуемые в масштабах всей организации решения, которые подкреплены принятыми принципами управления. Формальное описание архитектуры предприятия впервые было сформулировано в стандарте ISO 15704, который был предложен рабочей группой IFAC/IFIP (International Federation of Automatic Control / International Federation for Information Processing). Идея состояла в том, чтобы разработать максимально общую, так называемую эталонную (reference) модель архитектуры предприятия, которая охватывала бы дополнительно процесс развития предприятия во времени как проект, а также учитывала бы роль человеческого фактора. Архитектуры отдельных подсистем, в том числе ИТ-системы предприятия, могут быть тогда разработаны как специфические уточнения такой общей модели. Разработанная как приложение к данному стандарту, такая общая эталонная модель архитектуры получила название GERAM (Generalized Enterprise Reference Architecture and Methodology). Фактически GERAM представляет собой абстрактное описание архитектуры общего уровня, которая может быть использована для "привязки" и сравнения между собой различных практических моделей архитектур. В частности, в ее рамках определяются такие понятия, как "роль персонала в системе", "продукт", "жизненный цикл", "моделирование процессов" применительно к задачам описания функционирования предприятия.

Рис. 3.6.  В поисках интегрированной концепции Архитектуры предприятия

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

"Архитектура предприятия описывает деятельность предприятия с двух позиций:

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

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

Следует заметить, что эволюция понятия "архитектуры предприятия" связана с той эволюцией, которая происходила и происходит во взглядах на принципы организации деятельности предприятия как такового. Имеется в виду использование следующих организационных механизмов, которые условно показаны на рис. 3.7:

• 
  функциональная специализация;
  
• 
  реинжиниринг бизнес-процессов;
  
• 
  корпоративная архитектура.
  

Рис. 3.7.  Эволюция организационных принципов
Создание вертикальных организационных структур основано на иерархии управления в целях реализации механизмов контроля и распространения информации. Такой подход предполагает функциональную специализацию организационных единиц, так что достигается определенный уровень эффективности в выполнении специализированных для данных организационных единиц функций и процессов. Но при этом неизбежно возникает фрагментация в управлении и процессах, что обычно требует "героических" усилий по налаживанию интерфейсов взаимодействия между организационными структурами. В то же время реализация интегрированных и ориентированных на клиентов процессов требует достаточно высокого уровня межфункционального взаимодействия.

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

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

3.3 Контекст Архитектуры предприятия

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

• 
  бизнес, включая движущие силы (ключевые факторы), видение и стратегию;
  
• 
  организационные структуры и сервисы, которые требуются для реализации этого видения и стратегии;
  
• 
  информация, системы и технологии, которые требуются для эффективной реализации этих сервисов.
  

Разработка архитектуры предприятия позволяет решить одну из существенных проблем взаимодействия бизнеса и ИТ, которая получила на английском языке название "alignment", что на русский наиболее точно переводится фразой "синхронизация возможностей и потребностей бизнеса и ИТ". Это решение достигается за счет следующего:

• 
  автоматизации процессов – там, где видится положительный возврат от инвестиций в технологии (ROI);
  
• 
  уточнения понимания и формализации описания бизнес-процессов путем формального их моделирования.
  

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

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

Рис. 3.8.  Синхронизация потребностей бизнеса и возможностей ИТ

Одной из концепций, ключевой для понимания роли архитектуры предприятия, является концепция расширенной цепочки добавочной стоимости (value chain) ключевых бизнес-процессов. Идея "цепочки добавочной стоимости" привлекла к себе внимание в середине 1980-х годов, когда Майкл Портер (Michael E. Porter) из Гарвардской бизнес-школы опубликовал книгу "Конкурентное Преимущество" (Competitive Advantage, 1985). Большое количество специалистов в области корпоративной стратегии и управления активно используют на практике предложенные Портером модели, такие как "модель пяти факторов влияния", для анализа конкурентной среды и связанных с этим и возможностей угроз. При анализе деятельности организации Портер предложил сконцентрироваться на бизнес-процессах или цепочках создания добавочной стоимости, которые пересекают организационные границы, границы департаментов и функциональных образований. Цепочка создания добавочной стоимости включает все бизнес-процессы, которые должны быть выполнены от момента получения заказа от потребителя до поставки окончательного продукта. Портер рекомендовал прекратить мыслить в терминах организационного деления и вместо этого рассматривать все процессы и связанные с ними активности систематически и целостно. Он также высказал идею о том, что специфические активности в рамках процессов либо создают дополнительную стоимость в конечном продукте, либо нет, и предлагал компаниям фокусироваться на тех активностях, которые создают добавочную стоимость. Все эти идеи были в начале 1990-х годов подхвачены гуру в области реинжиниринга бизнес-процессов.




Рис. 3.9.  Связь требований бизнеса и различных областей

архитектуры ИТ

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




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