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

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

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

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

После завершения работы над первым сегментом Фред принимает решение  оценить эффективность использования  методологии MEA в других группах  в компании MedAMore. Ему необходим  критерий оценки эффективности различных  групп в компании MedAMore. Для этого  Фред поручает MEAPMO разработать эквивалент «Структуры оценки архитектуры предприятия  по программе FEA» [35]. Этот критерий будет  для Кэт основным индикатором  того, что обе группы воспринимают методологию MEA всерьез, а деньги потрачены  не зря.

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

9. Сервисно – ориентированная архитектура SOA.

Ответ:

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

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

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

нуждами предприятия. В настоящий  момент в рамках SOA выработан про-мышленный  стандарт для архитектуры, управляемой  мо-делями (Model Driven Architecture, MDA). Ее появление  обусловлено существованием ряда уже  апробированных технологий, стандартов и спецификаций, а реальное фи-зическое воплощение стало возможно благодаря  реали-

зации принципиально новых технологий программирова-ния. MDA является новой  ступенью развития технологий программирования благодаря описанному в ней про-цессу  разработки приложений, использующему  различ-ные современные средства визуализации, что позволяет автоматизировать создание программных продуктов. В  составе современных инструментов моделирования чаще всего рассматриваются  следующие группы: объект-но-ориентированный  анализ и разработки, инструменты  архитектуры предприятия, анализ бизнес-процессов.Большие  возможности построения архитектуры  предприятия открывает использование  другого подхода, рассматриваемого как продолжение развития методики SOA. Это архитектура, управляемая  событиями (Event Driven Architecture, EDA), она является распределенной и построена на очень слабых связях. Архитектура предприятия реального времени объединяет возможности

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

10. Создание гибкой архитектуры.

Ответ:

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

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

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

¦ формирование команды проекта  разработки бизнес-архитектуры;

¦ определение границ моделирования  бизнес-архитектуры;

¦ формирование структур и процессов  управления и контроля (governance) модели бизнес-архитектуры.

Одним из условий эффективной организации  проекта является позиционирование на таких работах, которые в ближайшие  сроки могут дать отдачу. Необходимо исходить из понимания того факта, что  значительное количество ценной информации может быть получено без выполнения анализа бизнес-процессов с «парализующей» степенью детализации. В этой ситуации целесообразно руководствоваться  правилом «80/20», а именно достаточно знать 80 % необходимых деталей о процессах – и эта информация может быть получена 20 % возможных усилий на анализ этих процессов. Это же правило применимо и к бизнес-архитектуре предприятия в целом.

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

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

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

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

Порядок и специфика исполнения организации по бизнес-моделированию  во многом определяются типами реализуемых  проектов. Выделяют следующие основные типы проектов по моделированию.

1. Описание (документирование) деятельности организации (процессы, производственные и информационные ресурсы, документы и данные, персонал и т. д.).

2. Анализ и совершенствование бизнес-процессов и деятельности организации в целом.

3. Описание деятельности организации при построении систем менеджмента качества.

4. Подготовка к внедрению систем управления предприятием.

5. Подготовка к внедрению систем класса Workflow.

6. Построение системы стратегического управления на основе сбалансированных показателей.

7. Проведение организационных изменений.

8. Управление операционными рисками и др.

Вне зависимости от типа проект по моделированию бизнес-архитектуры  состоит из следующих основных этапов.

1. Подготовительный этап. На данном этапе определяются и утверждаются цели проекта моделирования и приоритеты, проблемные области организации, выбираются методология и средство моделирования. Также прикидывается общая архитектура процессов, выделяются ключевые бизнес-процессы и их взаимосвязи. Формируются план проекта, проектная команда, подготавливается документ «Соглашение о моделировании».

2. Описание и анализ процессов «как есть». На этом этапе осуществляются описание процессов «как есть» в выбранном средстве моделирования, выбор критериев оценки процессов, выявление и оценка «узких» мест и потенциала для совершенствования. Уточняется план работ по дальнейшим этапам.

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

4. Подготовка к переходу к оптимизированной модели. На этом этапе разрабатывается план перехода от текущего состояния к целевому:

– создание новых должностных инструкций;

– разработка тренинг-курсов и выработка показателей (метрик) уровня квалификации исполнителей;

– описание временных решений и т. п.

5. Реализация. На этом этапе реализуются и/или автоматизируются необходимые процессы с помощью заказного или стандартного ПО, осуществляются перестройка организационной структуры, переквалификация персонала, а также мониторинг.

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

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