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

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

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

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

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

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

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

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

Тот факт, что сегменты определяются глобально, упрощает их повторное использование  в границах политико-административного  деления. Можно спланировать использование  сегментов в границах политико-административного  деления предприятия, а затем  воспользоваться этим планом для  поиска возможностей повторного использования  разработанной архитектуры. Например, на рис. 8 приведена схема сегментов  федерального правительства из «Практического руководства по FEA» [27]. Из рисунка  видно, что многие сегменты (вертикальные столбцы) используются во многих агентствах и все или почти все эти  сегменты можно использовать повторно.

Рис. 8. Схема сегментов федерального правительства 

Эталонные модели FEA

Все пять эталонных моделей FEA предназначены  для формирования единого языка. Цель — упростить взаимодействие, сотрудничество и совместную работу, минуя границы политико-административного  деления. Согласно заявлению управления по реализации программы FEA (FEAPMO):

«Методология FEA включает в себя набор  взаимосвязанных "эталонных моделей", предназначенных для упрощения  анализа деятельности агентств и  выявления дублирующих инвестиций, несоответствий и возможностей для  совместной работы внутри агентств и  между ними. Совместно эталонные  модели [образуют] структуру для  единообразного описания важных элементов  методологии FEA». [28]

Зачем нужен общий язык? Рассмотрим следующий диалог:

Джеймс: «Не дашь мне на время  лампу?»

Роджер: «У меня ее нет».

Джеймс: «А где ее можно купить?»

Роджер: «В магазине бытовой техники».

Итак, Джеймс отправляется в магазин  и покупает то, что хотел. Он возвращается к Роджеру.

Роджер: «Ну что, купил лампу?»

Джеймс: «Да, вот она».

Роджер: «Это же не лампа! Это фонарик. Почему ты сразу не сказал? Я бы дал  тебе на время свой».

Джеймс: «А почему ты не сказал, что  он у тебя есть?»

Проблема заключается в том, что Джеймс приехал из Англии, где  фонарь (англ. flashlight) называют лампой (англ. torch). Когда же я слышу слово  лампа (англ. torch), я представляю паяльнуюлампу(англ. blowtorch). Хотя мы оба говорим по-английски, это не значит, что мы говорим  на одном и том же языке. В результате Джеймс зря сходил в магазин и  потратил деньги на то, что мог бы позаимствовать у меня.

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

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

В итоге Налоговое управление разрабатывает  систему с нуля вместо того, чтобы  просто изменить уже готовую (и оплаченную) систему, используемую в Управлении правительственной печати. При этом Налоговое управление выбрасывает  на ветер гораздо больше денег, чем  потратил Джеймс на ненужный фонарь.

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

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

Эталонная модель компонентов (CRM) дает ИТ-представление систем, поддерживающих бизнес. Например, в эталонной модели компонентов определяется аналитическая  система, упомянутая выше в гипотетическом описании взаимодействия между Налоговым  управлением и Управлением правительственной  печати. [30]

В Технической эталонной модели (TRM) определяются различные технологии и стандарты, используемые при построении ИТ-систем. Например, в этой модели HTTP определяется как протокол, который  является подмножеством служебного транспорта, который, в свою очередь, является подмножеством служебного доступа и доставки. [31]

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

В эталонной модели производительности (PRM) определяются стандартные способы  описания полезности, обеспечиваемой архитектурами предприятий. Например, качество в этой модели определяется как область измерений, которая, в свою очередь, определяется как  «степень соответствия технологии требованиям  к функциональности или возможностям». [33]

Процесс FEA

Процесс FEA в основном направлен  на создание архитектуры сегмента для  подмножества общей архитектуры  предприятия (в случае с FEA предприятием является федеральное правительство, а подмножеством — правительственное  агентство). Описание процесса приведено  в «Практическом руководстве  по FEA» [34]. Сегменты предприятия в  рамках методологии FEA были рассмотрены  выше. Общий процесс разработки архитектуры  сегмента (на самом верхнем уровне) выглядит следующим образом.

Этап 1. Анализ архитектуры: формирование простого и лаконичного представления  сегмента с привязкой к плану  организации.

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

Этап 3. Стратегия инвестиций и финансирования: рассмотрение способов финансирования проекта.

Этап 4. План управления программой и  реализация проектов: создание плана  управления проектом и его реализации, включающего контрольные точки  и показатели производительности для  оценки успешности проекта.

Оценка успешности в методологии FEA

Структура FEA для оценки успеха в  использовании архитектуры предприятия  описана в документе «Структура оценки архитектуры предприятия  по программе FEA 2.1» [35]. Уровень готовности федеральных агентств оценивается  по трем категориям:

·          Завершенность архитектуры — уровень готовности собственно архитектуры

·          Использование архитектуры — эффективность использования агентством архитектуры при принятии решений

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

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

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

Желтый — агентство показало хорошие результаты в области  завершенности. Оно также добилось хороших показателей либо в области  использования, либо в области результатов.

Красный — агентство либо не завершило  разработку архитектуры, либо неэффективно использует разработанную архитектуру.

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

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

Применение методологии FEA к компании MedAMore

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

Кэт обращается к Фреду, эксперту по FEA (предположим, что такие эксперты существуют, хотя на момент написания  этой статьи методологии FEA еще не исполнилось  и года!). Задача Фреда заключается  в том, чтобы показать компании MedAMore, как можно применить методологию FEA — конечно, не в чистом виде, а  в том виде, в каком она применима  к частному сектору экономики. Кэт  знакомит Фреда с Бретом (вице-президентом  по бизнесу) и Ирмой (директором по информационным технологиям) и ставит им задачу разработать anMEA — методологию FEA, адаптированную для компании MedAMore.

Помните, что Кэт довольно сильно рискует. На сегодняшний день ни одна компания не пыталась применить методологию FEA в частном секторе экономики, а опыт использования FEA в государственном  секторе можно назвать в лучшем случае номинальным.

Первое, что собирается сделать  Фред, — это заставить сотрудников  поверить в методологию MEA. Помните, что он пришел в организацию, в  которой сотрудники бизнес-подразделения  практически не разговаривают с  ИТ-специалистами. Для успешного  применения методологии MEA необходимо изменить не только процессы, но и самих  сотрудников. Фред собирается провести несколько семинаров, посвященных  преимуществам разрабатываемой  методологии MEA, на которых он хочет  показать, что MEA принесет пользу не только компании MedAMore в целом, но и ее отдельным подразделениям.

Далее Фред займется построением в MedAMore управляющей структуры, эквивалентной FEAPMO. Эта структура будет называться MEAPMO. Методология MEA, включая процессы, модели и собственно архитектуру, будет  находиться в ведении MEAPMO.

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