Файл: Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое.pdf

•Два сервера выполняющих одну и туже роль (два контролера домена)
•Два сервера выполняющих разные роли в штатном режиме, но могут принять роли
соседа в случае отказа (Файловый сервер и сервер печати. В случае отказа можно установить роль на соседний сервер).
•Географически разнесенные устройства в пределах сайта. Расположение пары устройств в разных стойках, помещениях или зданиях в пределах одного сайта.
•Географически разнесенные устройства на уровне сайтов. Расположение пары устройств на разных сайтах.
Определение уровня резервирования зависит от критичности бизнеса к отказу или простою. Анализируется в процессе Управления Рисками, формализуется в документах по стандартах оборудования.
Стратегия по системам резервирования и архивирования
К системам резервирования и архивирования ИТ инфраструктуры можно определить следующие требования:
•Компоненты систем должны быть установлены на выделенных физических элементах
(серверах, СХД и т п)
•Возможно совмещение систем резервирования и архивирования на одних компонентах.
•Права доступов для учетных записей (автоматического) резервного копирования по возможности не должны предоставлять возможность удаления данных или же их перезапись.
Стратегия построения резервного сайта
Наличие компонента резервного сайта, один из важных элементов при построении ИТ архитектуры. Он имеет отношение к концепции информационной безопасности, отказоустойчивости и восстановления. Различают следующие виды отказоустойчивости:
•Отказоустойчивость на уровне избыточности компонентов
•Отказоустойчивость на уровне дублирования элементов
•Отказоустойчивость в пределах сайта
•Отказоустойчивость с географически распределённым сайтом
Подходы по внедрению Архитектуры Предприятия
При разработке архитектуры вашей компании необязательно начинать с разработки стратегической архитектуры. Безусловно, подход «Сверху – Вниз» (Стратегическая архитектура – > Архитектура сегмента – > Архитектура решений) самый распространенный и имеет множество преимуществ:
•Будет понятен общий вектор развития организации.
•На уровне сегментов и решений будет меньше разброда и шатаний.
•Общие правила и подходы на уровне организации, а затем их трансляция на уровень сегментов и решений.
•Общие для компании информационные системы и сервисы, повторно используемые на уровне сегментов и решений.
Основная идея движение от «общего к конкретному» (Generic- to – specific), а также непрерывное совершенствование ИТ архитектуры на основе требований бизнеса. Но вы можете использовать и другие подходы:
«Снизу – Вверх» (Архитектура решений – > Архитектура сегмента – >
Стратегическая архитектура).
От архитектуры конкретных проектных решений к стратегической архитектуре. Компания начинает с архитектуры решения. До старта проекта решение прорабатывается и описывается. Затем – более высокие уровни

Архитектуры Предприятия. Этот метод позволяет быстро получить ценность от методов
Архитектуры Предприятия. Но есть вероятность, что без стратегической архитектуры, как основы, архитектуры различных решений «разъедутся». Придется потратить время и ресурсы на приведение их к общему знаменателю.
«От Сегмента»
(Архитектура
Сегмента –
>
Архитектура решений и стратегическая архитектура) Когда компании важно решить проблемы в конкретном подразделении, запустить новое направление бизнеса, либо если компания не готова к крупномасштабным внедрениям Архитектуры Предприятия и хочет «потренироваться на кошечках». Обкатать идеи на одном подразделении или направлении бизнеса.
В зависимости от целей и сроков их достижения вам нужно выбрать подход для вашей компании.
Информационные системы вашей компании возможно далеки от идеала. Но выбросить их и переделать будет стоить очень дорого и займет много времени. Ценность такой инициативы сильно ниже нуля. Опытный архитектор «полечит» проблемы с интеграцией, информационной безопасностью, инфраструктурой, заплатками, а саму систему заставит давать большую ценность вашей компании. Реализация будет идти небольшими, точно выверенными доработками. Он будет решать конкретные проблемы, а не «делать все по уму». Замена системы – это серьезное изменение для компании, и для него должны быть веские аргументы.
Следующий важный вопрос при внедрении проекта построения Архитектуры
Предприятия: Стоит ли привлекать консультантов или делать все самим (MAKE or BUY)?
Однозначного ответа на него нет. Все зависит от конкретной организации, целей и возможностей. Для примера, представим ситуацию:
Мы заключаем контракт с уважаемой компанией «СУПЕР ПУПЕР КОНСУЛЬТАНТЫ и Ко». Через несколько месяцев получаем набор документов под названием «Архитектура компании БАНАНАС и Ко», в котором расписана правильная система, множество схем, описаний и т п. Так сказать решение «под ключ». Заманчиво? Да скорее всего дорого, но быстро, профессионально, не один «комар» (читаем «аудитор») носу не подточит.
Возможно.
Конечно, использование внешних ресурсов, чужого опыта и знаний – это один из самых быстрых способов достижения результатов. но есть несколько минусов:
•План перехода будет подозрительно похож на список товаров и услуг этой уважаемой компании. Любой внешний исполнитель в рамках проекта будет продавать другие свои товары и услуги. Это общая практика и один из главных законов продаж.
•Вы получите только набор документов, а не архитектурную практику. У вас останется только описание. Процессы, люди и управление уйдут вместе с консультантами.
•Ваши люди так и не понюхают пороху, консультанты сделают всю работу. А опыт и знания будут использовать у нового заказчика. Ваши специалисты будут архитекторами только на бумаге. У них не будет ключевого навыка – умения принимать технические решения.
На мой взгляд, чтобы выстроить процессы в организации, нужны сильные и грамотные менеджеры, знакомый с культурой компании, имеющие теоретические и практические навыки, умеющие и заинтересованные в передаче опыта и знания коллегам и сотрудникам.
Они должны играть главную роль и являться движущей силой организации.
Я бы рекомендовал привлечение внешних консультантов, но не отдавал бы архитектурную работу внешним исполнителям на 100%. В компании должны оставаться не только результаты проектов, но и люди, знания и опыт. Поэтому большую часть работы должны выполнять сотрудники вашей организации. Но под присмотром эксперта и с его помощью. Обязательно в проект внедрения должны быть включены ресурсы по обучению сотрудников. Как гласит народная мудрость «практика без теории слепа, теория без практики мертва».

Инструменты внедрения Архитектуры Предприятия
Как и какие выбрать инструменты для разработки Архитектуры Предприятия.
На рынке представлены десятки инструментов. От бесплатных до дорогих. Внедрение некоторых из них может стоить сотни тысяч долларов. Я рекомендую использовать по возможности бесплатные или дешевые инструменты (если не имеются в наличие) по следующим причинам:
•На старте архитектурной практике ещё предстоит доказать свою эффективность, поэтому значительные инвестиции и упущенное время будут серьезным препятствием на пути ее создания.
•На начальном этапе лучше использовать простые и знакомые инструменты, не требующие дополнительного внедрения и обучения. Скорость внедрения определяет успех.
•Нужно наработать опыт и получить первые результаты, чтобы сформировать адекватные требования к дорогой системе.
•Только после того, как практика запущена, получены опыт и первые результаты, время переходить на специализированные продукты.
Какие минимальные требования к инструментам? Что они должны помогать вам делать?
•Писать и редактировать тексты, составлять схемы, вести таблицы, делать презентации и т. д.
•Размещать их на общедоступном ресурсе, регулировать права доступа к информации, обсуждать эти материалы.
Набор инструментов:
•Для составления документов, схем, таблиц и презентаций можно использовать стандартный офисный пакет, например, MS Office. Для него есть готовые шаблоны для документов. Есть расширения для Visio, при помощи которых можно нарисовать все нужные схемы.
•Для совместной работы можно использовать корпоративный портал, систему управления документами, корпоративную почтовую систему, корпоративную систему передачи сообщений или выделенный файловый ресурс в корпоративной сети организации.
Выбор решения будет зависеть от того, что уже есть у вашей компании.

безопасности
•Введение единых ИТ политик и процедур в компании для снижения стоимости владения, сложности сопровождения и повышения информационной безопасности
•Автоматизация рутинных ИТ процессов для снижения стоимости владения, сложности сопровождения и повышения информационной безопасности
•Формирование единой политики информационной безопасности в организации
•Формирование проектной команды с высоким уровнем компетенции
Совместимость
Везде где это возможно, необходимо учитывать наличие имеющихся систем и по возможности максимально использовать выгоды данных систем. Это позволит снизить издержки на замену, или внедрению и сопровождению новых систем.
Следование основным принципам
При внедрении новых или промежуточных решений, или же при разворачивании бизнеса (или его расширении), рекомендуется руководствоваться основными требованиями, изложенными в данном документе.
Стоимость решения и сопровождения
ИТ инфраструктуры на прямую зависит от выбора того или иного решения.
Заключение
В заключение можно сказать, что построение Архитектуры Предприятия один из важнейших аспектов построения эффективного механизма корпоративного управления с интеграцией информационных технологий для получения наилучших результатов.
Интегрирование механизмов Управления ИТ сервисами (ITSM), систему Управления
Проектами (PMM) методов аудита и контроля (COBIT) позволит бизнесу добиться исключительных результатов и максимальной отдачи от ИТ.
Концепция Управления Проектами
Общие Положения
Управление проектом рассматривается как метод и набор процедур, основанных на принятых принципах управления, которые используются для планирования, оценки и контроля рабочих заданий, с целью получить желаемый конечный результат в установленные сроки, в рамках выделенных средств и в соответствии с требованиями к проекту. Данный раздел содержит основные принципы управления проектами, которые должны быть приняты во внимание при построении ИТ Архитектуры Предприятия. Любые проекты, в которые вовлечены ИТ (влияют на ИТ или зависят от ИТ), рассматриваются как
ИТ проекты. В процессе планирования, разработки и внедрения различных сервисов ИТ архитектуры необходимо руководствоваться принципами «проектного» подхода.
Управление Проектами очень обширная тема, затрагивающие и тесно переплетающаяся с различными направлениями деятельности, такими как управление качеством, рисками, финансами и т п. В данной главе мы кратко рассмотрим основные аспекты, методы и техники управления проектами.
Проект – это одноразовая, не повторяющаяся деятельность или совокупность действий, за определенное время, направленная на создание уникальных продуктов, услуг, результатов или четко поставленных целей. Признаки проекта:
•Есть конкретная дата начала. Ключевой признак проекта «временная составляющая», т. е. есть начало и конец проекта.
•Есть конкретная дата конца. Дата установить предполагаемый срок окончания

проекта, но зафиксировать условие окончания проекта по получению конечного результата или достижения целей проекта.
•Результат проекта уникален. Это второе отличие проекта от процесса или регулярной деятельности. «Уникальный» не означает абсолютно новый для всех, он может быть уникальным для организатора или команды.
•Ресурсы и бюджет – ограничены.
•Специфический порядок выполнения заданий. Он может предполагать временное изменения в иерархии подчинения и управления от установленного в организации.
Программа – отличается от проекта тем, что она больше по масштабу и может состоять из множества проектов. Так, например, у организации есть программа перехода к централизованной системе управления ИТ, которая может включать в себя несколько отдельных проектов.
Задача или набор рабочих заданий – представляет из себя набор действий, которые могут быть выполнены одним или несколькими лицами с помощью простого списка, задающего последовательность действий.
Ключевые аспекты Управления Проектами
Тройственная ограниченность или Треугольник проекта – описывает баланс между содержанием (объем работ или scope), стоимостью (cost) и временем (time, schedule) проекта, что влияет на конечный результат – качество (quality). Качество – это четвертый элемент проектного треугольника, который находится в центре, и любое изменение сторон влияет на него.
Как говорится в популярном слогане «Сделаем хорошо, быстро, дешево. Нужное подчеркните».
Вывод данного постулата сводится к одному: невозможно изменить один из факторов
(деньги, перечень работ, время или качество) не повлияв по крайней мере на один из других факторов. Как пример:
•Чтобы приблизить дату окончания (время) проекта, вы можете потратить больше ресурсов (деньги) или убрать некоторые задачи (область охвата) из проекта.
•Чтобы сделать проект в рамках бюджета (деньги), вы можете либо сократить некоторые задачи (область охвата), что повлияет на возможности продукта (качество).
•Чтобы добавить в продукт новые возможности (качество), вы можете продлить срок проекта, чтобы выделить время на новые задачи (время), тем самым добавив новые задачи
(область охвата) и привлечь новых людей, чтобы работать быстрее (затраты).
Идея всех методик и подходов сводится к фокусированию внимания на одном или нескольких факторах с контролем воздействия на оставшиеся.
Критерии успешности проекта – чтобы проект считался успешным фактические показатели, должны совпадать с запланированными в плане завершения проекта в срок, в рамках установленного бюджета и в соответствии с требованиями, предъявляемыми к конечному результату. Эти требования могут и должны быть сформулированы и включать в себя измеряемые критерии – показатели успеха проекта.
Цель руководителя проекта – достижения критериев успешности проекта.
Основная задача руководителя проекта – соблюдение баланса треугольника проекта.
Как показывает практика лишь четверть всех проектов достигает критериев успеха.
Поэтому при планировании проекта желательно указывать основные факторы успеха проекта (например, бюджет проекта и неизменность результата), а также возможные допуски – разрешенные отклонения связанных факторов (например, превышение срока реализации проекта, но не более чем на десять процентов и т п).
Для удобства управления проектами, в организации можно ввести классификацию