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

 
Среда бизнес-взаимодействия (Business Relationship Grid);

 
Бизнес-процессы и стили бизнес-процессов;

 
Шаблоны;

 
Технологические строительные блоки (кирпичики  – bricks).

 
 
 
Рисунок 3. Уровни модели архитектуры Gartner 
 
 
При этом уровни ИТ-архитектуры соответствуют различным уровням выполнения операций реального бизнеса так, как показано на рис. 8.4. 
 
 
 
Рисунок 4. Архитектура ИТ в бизнес-контексте

 
В этой схеме верхние два уровня ориентированы на совместное обсуждение с бизнес-руководителями и ИТ-специалистами  и в какой-то степени соответствуют  тому, что мы называли бизнес-архитектурой, а нижние два уровня входят во внутреннюю компетенцию ИТ-службы:

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

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

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

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

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

7. Стратегическая модель архитектуры SAM.

Ответ:

Методика Стратегическая модель архитектуры SAM (Strategic Architecture Model) является интересным инструментом анализа и документирования архитектуры предприятия и связанных  с ней доменов. Краткое описание этой методики в контексте ее применения для создания бизнес-шаблонов архитектуры  можно найти в [5.20], а более подробную информацию – на сайте http://www.systems-advisors.com или в [5.21]. Мы сочли необходимым включить ее в наш обзор, поскольку она содержит ряд оригинальных моментов, которые отличают ее от того, что мы встречали в остальных подходах. Кроме того, эта методика активно и успешно применяется, в частности, консультантами Microsoft во внутренних и внешних проектах и помогает в создании документов, которые передаются заказчикам и партнерам в ходе работы. Сама методика была разработана английской консалтинговой компанией Systems Advisers Ltd.

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

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

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

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

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

 
Рис. 9.2.  Типичные сферы интересов SAM

Внутри каждой области интересов  сохраняется информация о какой-то определенной предметной области, что  обеспечивает простоту сопровождения  и извлечения этой информации. Обычно применяется одна или более иерархическая  структура, которые напоминают ящик с файлами. Минимальный объем  информации, относящейся к какой-либо сфере, называется элементом (member). Например, элементами сферы "Местоположение" могут быть "Головной офис", "Офис продаж в санкт-Петербурге", "Завод  в Волоколамске" и т.д. Другими  примерами элементов различных  сфер являются:

Конкретные подразделения, например, "Отдел продаж" в сфере "Организация".

Конкретные бизнес-процессы, например, "Прием заказа" в сфере "Бизнес-процессы".

Конкретные информационные объекты, такие как "Клиент" в сфере "Данные".

В принципе, наименования сфер говорят  сами за себя. Отметим только, что  под бизнес-компонентами понимается совокупность данных и тех бизнес-функций, которые создают, читают, обновляют  и удаляют эти данные. Группировка  всех функций, создающих и обновляющих  одни и те же элементы данных с помощью  процесса под названием "коммутативная  кластеризация" позволяет определить неизбыточное количество "строительных блоков" – компонент – которые  могут использоваться для построения систем и приложений, поддерживающих определенные бизнес-процессы. Компоненты являются важными конструкциями  в современных подходах к разработке систем. Достаточно вспомнить про  сервис-ориентированную архитектуру SOA и архитектуру MDA, основанную на моделях. Объединение (инкапсуляция) функциональности и данных позволяет на практике добиться повторного и многократного использования  элементов систем и дает возможность  замены одних элементов другими. Компоненты предлагают "сервисы", которые могут использоваться в  совокупности с другими сервисами, предлагаемыми другими компонентами в рамках сервис-ориентированной  архитектуры.

Важное замечание, отраженное на нашем  рисунке, состоит в том, что можно  выделить три категории сфер:

Стабильные. Эти сферы описывают  достаточно стабильные элементы бизнеса  и представляют фундаментальные  структуры: бизнес-функции, данные, бизнес-компоненты и инфраструктуру.

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

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

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

 

8. Эталонная и отраслевая модель построения архитектуры предприятия.

Ответ:

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

Эталонная модель компонентов (CRM) —  термин FEA, обозначающий ИТ-представление  систем, поддерживающих бизнес.

TOGAF — этоаббревиатураот The Open Group Architecture Framework ( структураархитектуры The Open Group). Методология TOGAF принадлежит  консорциуму The Open Group .

Как показано на рисунке, в модели TOGAF архитектура предприятия подразделяется на четыре категории:

Архитектура бизнеса — описывает  процессы, используемые для достижения бизнес-целей

Архитектура приложений — описывает  структуру конкретных приложений и  их взаимодействие друг с другом

Архитектура данных — описывает  структуру корпоративных хранилищ данных и процедуры доступа к  ним

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

Модель TOGAF позиционируется как  «структура», однако наиболее важным ее компонентом является методика разработки архитектуры (ADM). Эта методика представляет собой рецепт по созданию архитектуры. Рецепт можно классифицировать как  процесс. С учетом того, что методика разработки архитектуры является наиболее значимой составляющей модели TOGAF, я  рассматриваю TOGAF в целом как архитектурный  процесс, а не как архитектурную  структуру (как позиционирует TOGAF консорциум The Open Group) или методологию (как позиционируется  методика разработки архитектуры).

Как архитектурный процесс модель TOGAF дополняет модель Захмана —  которая, напомню, классифицируется в  данной статье как архитектурная  таксономия. Захман показывает, как  следует классифицировать артефакты. Модель TOGAF описывает процесс создания артефактов.

В модели TOGAF мир архитектуры предприятия  рассматривается как континуум  архитектур, от максимально обобщенных до максимально специализированных. Этот континуум называется континуумом  предприятия. Процесс создания конкретной архитектуры предприятия, например MAM-EA, рассматривается как переход  от общей архитектуры к специализированной. Методика разработки архитектуры в  модели TOGAF представляет собой процесс  осуществления такого перехода.

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

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

Следующий уровень специализации  в модели TOGAF называется отраслевыми  архитектурами. Эти принципы характерны для предприятий, занятых в одной  сфере деятельности, например в случае с MedAMore — для всех фармацевтических компаний.

Самый высокий уровень специализации  в модели TOGAF называется архитектурами  организаций. Это архитектуры конкретных предприятий, например MedAMore.

На рис. 6 показано соотношение между  континуумом предприятия и методикой  разработки архитектуры (ADM).

Рис. 6. Континуум предприятия в  модели TOGAF

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

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

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