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

Рис. 7. Методика разработки архитектуры (ADM) в модели TOGAF

Как показано на рис. 7, методика разработки архитектуры в модели TOGAF состоит  из восьми этапов, которые циклически повторяются после первой «накачки». Далее эти этапы будут рассмотрены  на примере MedAMore. Однако перед тем  как компания MedAMore сможет приступить к использованию методики разработки архитектуры, ей необходимо изучить  модель TOGAF. Изучить модель TOGAF можно  двумя способами.

Во-первых, компания MedAMore может изучить  модель TOGAF самостоятельно. Компания MedAMore может загрузить документацию по TOGAF [20] — в ней достаточно подробно описаны все возможности TOGAF, в  том числе методика разработки архитектуры. Также можно приобрести книги  по TOGAF [21]. О модели TOGAF доступно больше информации (как бесплатной, так  и за умеренную цену), чем обо  всех остальных методологиях построения архитектуры вместе взятых.

Во-вторых, компания MedAMore может обратиться к экспертам по TOGAF. На рынке работает множество консультантов по TOGAF, обладающих сертификатами Open Group [22]. Поскольку  руководство компании MedAMore хочет  свести все риски к минимуму, оно  принимает решение обратиться к  консультанту по TOGAF. Компания MedAMore обратилась к Тэри, которая является архитектором TOGAF с сертификатом Open Group. Напомним, что другими игроками в компании MedAMore являются Кэт, исполнительный директор MedAMore, Брет, вице-президент по бизнесу, и Ирма, директор по информационным технологиям.

На подготовительном этапе Тэри встречается с основными игроками в компании MedAMore и рассказывает им о процессе TOGAF. Она преследует три  основные цели:

Убедиться в том, что процесс  устраивает всех игроков

Если необходимо, изменить процесс TOGAF в соответствии с корпоративной  культурой MedAMore

Разработать систему управления для  надзора за последующей разработкой  архитектуры в MedAMore

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

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

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

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

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

Основным документом, создаваемым  на этапе А, является «Постановление о разработке архитектуры», которое  должно быть утверждено всеми заинтересованными  лицами. После этого можно переходить к следующему этапу. В конце этого  этапа формируется архитектурное  представление для первой итерации цикла разработки архитектуры. Тэри поможет компании MedAMore выбрать проект, проверить проект на соответствие архитектурным  принципам, сформулированным на подготовительном этапе, и убедиться в том, что  были определены все заинтересованные лица, а обозначенные этими лицами проблемы были устранены.

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

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

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

Разработка описания базовой архитектуры  данных

Просмотр и проверка принципов, эталонных моделей, точек зрения и средств

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

Выбор компонентов архитектуры  данных

Формальный анализ контрольных  точек модели архитектуры и ее компонентов вместе с заинтересованными  лицами

Анализ качественных критериев (например, производительности, надежности, безопасности и целостности)

Завершение архитектуры данных

Анализ контрольных точек и  последствий

Анализ различий

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

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

На этапе Д выполняется оценка различных возможностей реализации, определяются основные проекты по внедрению, которые необходимо выполнить, а  также связанные с каждым проектом возможности для бизнеса. Стандартом TOGAF на этапе Д рекомендуется «сосредоточиться на проектах, которые дадут результаты в краткосрочной перспективе  и позволят реализовать долгосрочные проекты».

Это хороший совет для любой  методологии построения архитектуры. Таким образом, Тэри следует выделить проекты, которые можно реализовать  с минимальными затратами и максимальной отдачей. Для поиска таких проектов рекомендуется изучить «болевые точки» организации, изначально обозначенные Кэт (исполнительным директором MedAMore). Это позволит принять стратегию развития предприятия на базе архитектуры. Описанные выше «болевые точки» включают трудности в обеспечении поддержки специализации на уровне регионов и складов и ненадежный обмен данными.

Этап Е тесно связан с этапом Д. На этом этапе Тэри работает с  руководством компании MedAMore's, чтобы  упорядочить по приоритетам проекты, выбранные на этапе Д, с учетом не только затрат и выхода (определенных на этапе Д), но и факторов риска.

На этапе Ж Тэри на основе упорядоченного по приоритетам списка проектов создает  спецификации архитектуры для проектов реализации. Эти спецификации включают критерии приемки и списки рисков и проблем.

Последним этапом является этап З. На этом этапе Тэри корректирует процесс  управления архитектурными изменениями  с учетом новых артефактов, созданных  на последней итерации, и новых  данных.

После этого цикл повторяется. Одной  из целей первого цикла является передача информация, поэтому с каждой новой итерацией потребность  в услугах Тэри снижается.

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

«Методология TOGAF — это не только и не столько создаваемые документы; фактически она в меньшей степени  ориентирована на шаблоны документов, а в большей — на то, что  мы получаем на входе и на выходе». [23]

Спецификация TOGAF также позволяет  гибко работать с этапами. В самой  спецификации говорится следующее:

Перед применением методики разработки архитектуры необходимо проверить  компоненты на применимость, а затем  связать их с конкретными обстоятельствами отдельного предприятия. Это позволяет  создать методику разработки архитектуры  для конкретного предприятия. [24]

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

Модель TOGAF обладает еще большей  гибкостью в отношении созданной  архитектуры. Фактически TOGAF, как это  ни удивительно, «ничего не знает» об архитектуре. Окончательная архитектура  может с одинаковым успехом быть хорошей, плохой или неопределенного  качества. В TOGAF описывается, как создать  архитектуру предприятия, но не описывается, как создать хорошую архитектуру. Качество конечного продукта зависит  от опыта персонала компании и  консультанта по TOGAF. Те, кто внедряет TOGAF в надежде получить чудодейственное  средство, будут жестоко разочарованы (впрочем, как и при использовании  любой одной методологии).

Архитектура федеральной организации (FEA)

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

FEA является наиболее полной  методологией из всех упомянутых. Она включает и всеобъемлющую  таксономию, как в методологии  Захмана, и архитектурный процесс,  как в модели TOGAF. FEA можно рассматривать  и как методологию создания  архитектуры предприятия, и как  результат применения этой процедуры  к конкретной организации —  Правительству США. Я буду рассматривать  FEA с точки зрения методологии.  Нас интересует, как можно применить  методологию FEA к коммерческим  организациям.

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

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

Набор эталонных моделей, описывающих  различные точки зрения на архитектуру  предприятия (пять перечисленных выше моделей)

Процесс создания архитектуры предприятия

Процесс перехода от старой парадигмы (до создания архитектуры предприятия) к новой (после создания архитектуры  предприятия)

Таксономия для классификации  активов, которые попадают в область  действия архитектуры предприятия

Методика, позволяющая оценить  успешность использования архитектуры  предприятия для повышения ценности бизнеса

Очевидно, что FEA представляет собой  нечто большее, чем набор моделей. Эта методология включает в себя все необходимое для построения архитектуры предприятия даже для  самой сложной, пожалуй, организации  в мире — Правительства США. По заявлению управления по реализации программы FEA (FEAPMO), методология FEA в  целом обеспечивает:

«...общий язык и структуру для  описания и анализа инвестиций в  ИТ, повышает эффективность совместной работы и позволяет преобразовать  федеральное правительство в  организацию, ориентированную на граждан, направленную на достижение высоких  результатов и отвечающую требованиям  рынка в соответствии с программой президента США». [25].

Хотя на первый взгляд разве что  вмешательство высших сил позволит «преобразовать федеральное правительство  в организацию, ориентированную  на граждан, направленную на достижение высоких результатов и отвечающую требованиям рынка», есть надежда, что  методология FEA может помочь нашей  многострадальной корпорации MedAMore справиться с гораздо менее глобальными  проблемами. Так что же может предложить методология FEA при ближайшем рассмотрении?

Архитектура предприятия с точки  зрения FEA

С точки зрения FEA, архитектура предприятия  состоит из отдельных сегментов. Эта идея была впервые изложена в FEAF [26]. Сегмент представляет собой  один из основных аспектов бизнеса, например трудовые ресурсы. Сегменты подразделяются на два типа: базовые и служебные.

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