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

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

Вопросы

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

7. Лекция: Технологическая архитектура, стандарты и шаблоны

Содержание

• 
  Контекст и основные элементы технологической архитектуры
  
• 
  Оценка состояния и требований к технологической инфраструктуре в контексте бизнес-стратегии
  
• 
  Роль стандартов
  

7.1 Контекст и основные элементы технологической архитектуры

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

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

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

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

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

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

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

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

Реальные преимущества от наличия упорядоченного в рамках технологической архитектуры списка используемых технологий таковы:

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

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

7.2 Состояния и требований к технологической инфраструктуре в контексте бизнес-стратегии

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

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

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

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

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

7.3 Роль стандартов

Применение стандартов играет важную роль в архитектуре информационных систем – прежде всего потому, что стандарты обеспечивают возможность взаимодействия различных компонент между собой. Чем более сложной, распределенной и тиражируемой является система, тем эта определяющая и консолидирующая роль стандартов становится все более актуальной. Стандарты есть общепринятые документы, формализующие лучшие практики. Строго говоря, принято различать стандарты де-юре, т.е. разработанные и поддерживаемые официальными органами по стандартизации, такими как Международная организация по стандартизации – ISO, и стандарты де-факто, основанные на существующем широком распространении технологии, методологии или продукта (например, использование MS Windows в качестве операционной системы для персональных компьютеров).С другой стороны, можно выделять два класса – "технологические" и "рамочные" стандарты. Технологические стандарты определяют особенности реализации тех или иных протоколов, интерфейсов, языков программирования и т.п. Типичным примером являются спецификации WWW консорциума W3C. В составе описания ИТ-архитектуры предприятия обычно приводятся ссылки на используемые стандарты такого типа. Для наших задач, связанных с разработкой архитектуры предприятия, наибольший интерес будут представлять такие "рамочные" стандарты, как уже упоминавшийся ISO 15704, а также ISO 15288 и, частично, ISO 12207. Помимо указанных, при разработке архитектуры предприятия достаточно широко используется порядка 30-ти дополнительных "поддерживающих" стандартов системной и программной инженерии. Например, стандарт ISO 14258 определяет концепции и правила для моделирования Предприятия и т.п. Эти стандарты являются рамочными (Framework) в том плане, что они задают общие требования к реализации процессов, связанных с разработкой и поддержкой жизненного цикла систем. Они обычно используются как методологическая основа для организации этих процессов с необходимой конкретизацией для каждого данного предприятия или области деятельности.

В соответствии со стандартом ISO/IEC 15288 жизненный цикл систем охватывает "дерево" процессов, показанное на рис. 7.2.




Рис. 7.2.  Структура активностей стандарта ISO 15288

Вопросы

1. 
   В чем содержится основное назначение технологической архитектуры?
   
2. 
   Что обеспечивают набор принципов и стандартов, определяемые технологической архитектурой?
   
3. 
   Опишите уровни размещения технологической инфраструктуры.
   
4. 
   Перечислите шесть архитектурных компонентов технологической архитектуры.
   
5. 
   Опишите схему взаимосвязи функциональных и операционных требований с архитектурой приложений и технологической архитектурой.
   
6. 
   На каких критериях основан подход для оценки состояния технологической инфраструктуры?
   
7. 
   Перечислите основные характеристики адаптивной системы.
   
8. 
   Какова основная роль стандартов в архитектуре информационных систем?
   

Литература

1.Васильев Р. Б., Калянов Г. Н., Левочкин Г. А., Лукинова О. В. Стратегическое управление информационными системами; Интернет-университет информационных технологий, Бином. Лаборатория знаний - Москва, 2013. - 512 c.

2. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. Учебное пособие: М.: Финансы и статистика, 2006.

3. Гейтс Б. Бизнес со скоростью мысли. Изд. 2-е, исправленное- М.: Изд-во Эксмо, 2010. – 480 с.

4. Хаммер М., Чампи Д. Реинжиниринг корпорации. Манифест революции в бизнесе. –М.: Манн, Иванов и Фербер, 2011

6. Захман Джон А., «Архитектура предприятия: прошлое и будущее» Статья опубликована в DM Review Magazine. Декабрь 2009.

7. Марка Д., Мак Гоуэн Методология структурного анализа и проектирования. – М.: Весть-МетаТехнология, 2009.

8. Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504) – М.: Книга и бизнес, 2011.

9. .Спицнадель В.Н. Основы системного анализа. – С-Пб.: Бизнес-пресса, 2009.

10. Ян Ван Бон, Пондман Д. ИТ Сервис-менеджмент. – М.: Van Haren Publishing, 2011.

11. А Данилин, А. Слюсаренко. Архитектура и стратегия. "Инь" и "янь" информационных технологий.. – М. Интернет-ун-т Информ. Технологий, 2010. – 504 с.

12. Каменнова М.С., Громов А.И., Ферапонтов М.М., Шматалюк А.Е. Моделирование бизнеса. Методология ARIS. – М.: Весть-МетаТехнология, 2011. С. 36-115

13. Шеер, А. -В. ARIS - моделирование бизнес-процессов = ARIS-Business Process Modelling / А.-В. Шеер ; [пер. с англ. и ред. А. А. Рыбянец] .— 3-е изд. — Москва [и др.] : Вильямс, 2009 .— 223 с

14. Андерсен, Б. Бизнес-процессы. Инструменты совершенствования / Б. Андерсен ; пер. с англ. С. В. Ариничева; под науч. ред. Ю. П. Адлера .— Изд-е 5-е .— М. : Стандарты и качество, 2008 .— 272 с

15. Маклаков, С. В. Моделирование бизнес-процессов с ALLFusion PM / С. В. Маклаков .— Изд. 2- е испр. и доп. — М. : Диалог-МИФИ, 2008 .— 224 с.