Материал: Ответы на экзамен АП

Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней.

← УРОВНИ

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

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

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

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

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

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

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

26. Методики разработки архитектуры предприятия «сверху-вниз» и «снизу-вверх».

В общем виде можно сказать, что существуют два принципиально различных подхода в разработке архитектуры предприятия:

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

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

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

27. Организационные структуры, связанные с разработкой архитектуры.

← Организационные структуры, связанные с управлением и контролем архитектуры.

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

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

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

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

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

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

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

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

• уровень внесения существенных изменений в архитектуру;

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

28. Оценка затрат на разработку и сопровождение архитектуры предприятия

Текущие затраты на сопровождение архитектуры включают:

• обеспечение поддержки архитектуры со стороны сотрудников ИТ-службы и бизнес-подразделений;

• создание, документирование и публикация информации об архитектуре;

• проведение анализа и контроль соответствия архитектурных решений отдельных проектов;

• обучение и оценка результатов;

• подготовка планов технологического развития, связанных с новыми технологиями.

Все это имеет отношение как к коммерческим, так и к государственным организациям.

Затраты на разработку архитектуры примерно:

• от $100 тыс. для таких относительно небольших агентств (пр:Администрация Международной Торговли )

• до $18-20 млн. для таких крупных агентств с очень сложной ИТ-инфраструктурой и широким спектром прикладных систем (по:Министерство по налогам)

Соответственно, ежегодные затраты на поддержание архитектуры составляют порядка 10% от стоимости разработки, т.е. примерно от $10 тыс. до $1,5 млн. Можно попробовать "спроецировать" эти суммы на российскую действительность с учетом разницы в стоимости оплаты труда ИТ-персонала в двух странах.

29.Gap-анализ (анализ несоответствий) и модель развития элементов ит-архитектуры

Gap-анализ — это способ идентификации и анализа несоответствий между существующим и желаемым состоянием архитектуры предприятия и отдельными его доменами

Процесс анализа на несоответствия включает следующие шаги:

• идентификация различий между существующей и целевой архитектурой;

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

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

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

Для категоризации несоответствий можно использовать матрицу,

• Структурными несоответствиями понимаются несоответствия связанные с вопросами инфраструктуры.

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

• Культурные несоответствия – это несоответствия между сегодняшним состоянием ИТ-департамента организации и требующимися навыками, компетенциями и структурами, которые необходимы для решения проблем в первых двух областях.

• Процедурные несоответствия – это несоответствия между существующими и желаемыми методами управления, стратегиями сорсинга, процессами эксплуатации ИТ-сервисов и организационными процедурами.

• существует два типа несоответствий:

• "жесткие" несоответствия, которые связаны с необходимостью замены ряда технологий или внедрения новых;

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

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

Аспект планирования и управления включает:

• направление развития ИТ – определяет среднесрочные и перспективные роли ИТ в компании с учетом требований бизнеса и выделенных приоритетов;

• принципы реализации – определяют "правила" рассмотрения, внедрения и последующего управления технологиями;

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

• Аспект стандартизации включает:

• Общие ИТ-службы.

• Вычислительная инфраструктура.

• Элементы архитектуры системы.

Оценка перспективности развития проводится с учетом:

• стратегии развития, перспективности расширения бизнеса, изменения отношений с клиентами и поставщиками;

• общемировых тенденций развития информационных технологий;

• выбранного направления развития ИТ-технологий в организации и стратегии реализации (срочные, среднесрочные и перспективные этапы).

31.Оценка зрелости архитектуры

Характеристики уровней организационной зрелости.

32. модель Портера не кручёные элементы и ее соответствие для построения АП

Анализ микросреды может делаться с помощью анализа пяти сил Пор- тера (Porter five forces analysis) — методики для анализа отраслей и выра- ботки стратегии бизнеса, разработанной Майклом Портером в Гарвард- ской школе бизнеса в 1979 г. Пять сил Портера включают:

— угрозы появления продуктов-заменителей;

— угрозы появления новых игроков;

— рыночную власть поставщиков;

— рыночную власть потребителей;

— действия конкурентов внутри отрасли.

33.Бизнес-модель

Бизнес-модель компании определяет, как она получает прибыль, обращается к своему рынку, представляет свои предложения и развертывает бизнес отношения.

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

• потребительские сегменты (кто является потребителями, на кого ориентирован бизнес?);

• ценностное предложение (что уникального мы предоставляем нашим клиентам, каковы наши отличительные особенности?);

• каналы сбыта (каким образом мы доставляем наше предложение клиентам?);

• взаимоотношения с клиентами (как мы осуществляем коммуникации с клиентами и поддержку?);

• доходы / структура доходов (какие основные каналы поступления доходов?);

• ключевые ресурсы (какими ключевыми ресурсами необходимо обладать, чтобы предоставить ценностное предложение ключевым потребителям?);

• ключевая деятельность (какая деятельность является ключевой, для того чтобы все остальное работало?);

• ключевые партнеры (кто является ключевыми партнерами?);

• издержки / структура издержек (на что направлены основные издержки?).

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