Автор работы: Пользователь скрыл имя, 02 Июля 2015 в 12:25, реферат
Архитектура предприятия выделилась в отдельную дисциплину чуть более 20 лет тому назад и в настоящее время является одной из ключевых функций как корпоративного, так и проектного менеджмента, основным средством достижения и поддержания конкурентоспособности любого предприятия или организации, особенно в сфере ИТ.
Наилучшим вариантом, однако, может стать гибридный подход. В любом случае, выбранная стратегия должна отвечать конкретным потребностям организации, и в любом случае, требуется поддержка со стороны высшего руководства и понимание того, что создание архитектурыэто долговременный процесс изменений.
Как мы уже отмечали, зачастую используется смешанный или гибридный вариант процесса, сочетающий черты обоих подходов.
В самом начале проекта (процесса) разработки архитектуры организации очень часто стремятся как можно скорее выбрать одну из известных на рынке методик или создать на их основе свою собственную. Однако в действительности есть несколько «более первоочередных» моментов, важных для успеха проекта в целом:
Рассмотрим каждый из этих аспектов более подробно. Прежде всего необходимо понять, какие факторы подталкивают предприятие к рассмотрению вопросов разработки архитектуры. Это могут быть, например, макроэкономические факторы, требующие переосмысления вклада ИТ в бизнес, или конкурентная ситуация, требующая новых прикладных систем и обеспечивающей инфраструктуры (например, децентрализации процесса приема заказов). Факторы могут быть связаны с изменениями в бизнес-стратегиях, например, с принятием решения об организации более индивидуализированной работы с клиентами, что потребует внедрения целого ряда новых информационных систем. Важно понимать, как эти факторы могут быть использованы при обосновании проекта разработки архитектуры перед высшим руководством.
Основная сложность обоснования необходимости архитектурного проекта и выделения соответствующих инвестиций связана с тем, что прогнозируемые результаты обычно предполагают косвенное улучшение бизнеса организации, то есть являются, как правило, качественными и редко могут быть связаны с конкретными финансовыми выгодами. Даже в том случае, когда бизнес-показатели типа «увеличение стоимости акций компании» или «доля на рынке» измеримы, конкретные связи между ними и проведенным реформированием архитектуры предприятия обычно бывают трудно доказуемы. При этом аналитики МЕТА отмечают, что в настоящее время более чем в 70% компаний ИТ-служба все еще является центром затрат, а более 90% ИТ-служб не имеют согласованных с бизнес-руководством финансовых моделей, позволяющих количественно измерить эффект от внедрения ИТ для бизнеса.
С точки зрения обоснования цифр экономии практически невозможно дать какие-то общие, применимые на все случаи, оценки затрат, связанных с отсутствием архитектуры ИТ. Это зависит от уникальности ситуации в каждой конкретной организации. Экономия может быть достигнута, в частности, за счет сокращения расходов, связанных с повторным использованием оборудования или программного обеспечения, за счет сокращения времени разработки, оптимизации расходов на ведение проектов, снижения стоимости технической поддержки, приобретения новых активов или экономии за счет более простой адаптируемости системы, построенной на базе единой архитектуры, к изменению требований бизнеса. Последняя составляющая выгоды обычно становится заметной при сравнении затраченных усилий, средств и времени для проведения изменений в различных подразделениях организации с отличающимися исходными архитектурами. В целом, по данным опроса МЕТА, снижение величины расходов на ИТ в расчете на одного сотрудника в случае реализации единой корпоративной архитектуры может достигать величины порядка 30%. По оценке Gartner отсутствие архитектуры приводит к 12-18% дополнительных затрат, связанных только с эксплуатацией ИТ-инфраструктуры.
Важно иметь в виду, что учет только прямых финансовых выгод зачастую оказывается недостаточным для оправдания инвестиций, так что приходится использовать более сложные методики, чтобы включить в обоснование проекта косвенные выгоды для бизнеса организации. С другой стороны, еще одним существенным аспектом, который необходимо принимать во внимание при переходе к новой архитектуре, является увеличение рисков, связанное с тем, что ко всем рискам, постоянно присутствующим в ИТ-системе (такими, как выход из строя оборудования или ошибка персонала), добавляются еще и риски, связанные с изменениями.
Во многих организациях информационные технологии уже исчерпали возможности по повышению продуктивности в таких областях, как скорость выполнения транзакций и бизнес-процессов. Поэтому традиционное обоснование инвестиций в информационные технологии, заключающееся в подсчете возврата на инвестиции (ROI - Return on Investment), может не обеспечить должного результата. Показатель ROI требует возврата инвестиций в рамках рассматриваемого проекта, поэтому этот показатель является тактическим по своей природе и не адекватным для задачи обоснования инвестиций в архитектуру информационных технологий.
Инвестиции в архитектуру предприятия, эффект от использования которой может быть не столь очевиден в течение трех-пяти лет, требуют иных мер оценки эффективности, Возможной стратегической альтернативой является величина «Возврата на основные фонды» (ROA - Return on Assets), которая будет стимулировать компанию оценивать архитектуру ИТ с точки зрения повышения эффективности своих основных фондов. Другим полезным показателем может быть «Возврат на возможность» (Return on opportunity). Он не является формальной финансовой метрикой, но описывает влияние инвестиций на бизнес.
По оценкам Gartner, именно продуктивность информационных технологий как основных фондов в среднесрочной перспективе (2007 год) будет определять рыночную капитализацию компаний. Поэтому рыночная ценность органиэаций, которые обеспечивают эффективность использования ИТ как основных фондов и тем самым получают более высокую прибыль на единицу инвестированного капитала, будет возрастать. По тем же прогнозам, к 2007 году корпоративная архитектура будет критическим фактором в области управления рисками. Скорость реагирования, динамичность (agihty) и гибкость организации, а также прозрачность отчетности будет оцениваться через наличие архитектуры предприятия. Именно архитектура будет задавать уровень риска, которым организация должна управлять. При этом управление рисками осуществляется как на микро-уровне, то есть уровне отдельных проектов, где основной фокус связан с выработкой конкретных мер для снижения определенного риска или с противодействием ему, так и на макро-уровне портфеля ИТ-проектов в целом. На этом макро-уровне должен достигаться определенный компромисс между инвестициями в связанные с высоким риском инновационные проекты и традиционными стандартными решениями, у которых как отдача, так и риск невысоки. Общей задачей будет являться формирование такого портфеля, когда эффекты от ИТ в целом превысят риски потерь.
Если бизнес-руководители (которые, в конце концов, выделяют все необходимые финансовые ресурсы) не поддержат усилия по выработке архитектуры ИТ, то им стоит готовить себя к еще большим затратам в будущем, поскольку они неизбежно окажутся в ситуации, когда они зададут себе вопрос: «Почему же мы тратим так много средств для получения таких посредственных услуг от ИТ-службы?»
Следует иметь в виду, что при принятии решения о необходимости разработки архитектуры предприятия - пока эффект от нее не доказан практикой,- следует избегать отнесения расходов по ее разработке на бизнес-подразделения организации или на бюджет конкретного ИТ-проекта.
Точно так же, как в строительстве существует должность главного архитектора города или проекта так и в организации кто-то должен быть ответственным за развитие архитектуры предприятия в целом, а информационных систем в частности. С учетом отмеченной ранее тесной связи между архитектурой информационных технологий и бизнес-архитектурой, один и тот же человек может отвечать за обе эти области.
По оценкам МЕТА Group, должность «Главного архитектора» введена примерно в 30% компаний. Собственно название этой должности, вообще говоря, может быть любым, так что за разработку архитектуры могут быть ответственными, например, «Заместитель руководителя ИТ-службы» или «Директор по ИТ-стратегии». Гораздо более важным является статус данной должноспги в организации. Существует большое количество примеров, когда такое «громкое название» должности на самом деле используется одним из рядовых аналитиков в составе ИТ-службы, у которого нет реальных прав и возможностей влияния на ситуацию. В этом случае ответственность на практике размазывается (со всеми вытекающими из этого последствиями) по всей команде проекта, а то и по всем руководителям подразделений в ИТ-службе организации. Еще большую актуальность эти вопросы могут иметь для государственных организаций и разработки архитектуры «электронного правительства».
Интересным является вопрос об оптимальном составе команды проекта по разработке архитектуры. Обычно выделение отдельных структур считается целесообразным для достаточно больших по размеру ИТ-служб, насчитывающих порядка 100 и более сотрудников. Даже для больших организаций рекомендуется ограничивать состав основной команды 7-8 сотрудниками, а для более детальной проработки доменов архитектуры (частных архитектур данных, приложений и пр.) создавать отдельные проектные группы.
В меньших организациях чаще используется матричный метод когда в команду проекта входят представители различных подразделений. Однако в любом случае принципиальным скорее является не наличие или отсутствие формальной кадровой структуры, а применение соответствующих методологий для формирования архитектуры и управления всем процессом.
Для Главного архитектора такие качества, как положительная харизма,уверенность при общении с высшим руководством, системный подход и осведомленность в бизнесе, умение распределять работу между подчиненными могут явиться более критичными, чем знание конкретных технологий.
Оптимальный состав команды, по мнению МЕТА, должен включать специалистов со следующими ролями:
Помимо собственно команды проекта, в организации должны существовать некоторые формальные структуры, каждая из которых выполняет определенные руководящие и контролирующие функции. Обычно создаются такие структуры, как Управляющий или Информационный комитет, утверждающий общий ИТ-бюджет и ИТ-стратегию коипании, и Совет по архитектуре (или Технический комитет), который следит за организацией процесса разработки архитектуры, а также рассматривает и санкционирует отклонения от утвержденной архитектуры.
Важно подчеркнуть, что, хотя команда проекта разработки архитектуры и выполняет основную работу, она, как правило, не является собственником этого процесса и результатов. Целесообразно, чтобы ее результаты были сформированы в виде рекомендаций, подлежащих утверждению высшим руководством организации для придания определенной значимости и легитимности. Более того, команда проекта или служба Главного Архитектора не должна сама выполнять «полицейские» функции в случае несоответствия проектов утвержденным архитектурным стандартам. Если вы решили, что Архитектура предприятия должна затрагивать еще партнеров и поставщиков, то, следовательно, это потребует определенного участия их представителей в работе. Или наоборот, вы сознательно выберете некую часть предприятия, наиболее важную, и только часть бизнес-процессов организации.
Предположим, что команда проекта разработки архитектуры сформирована и готова начать свою работу. Как и для традиционных проектов, прежде всего следует обеспечить формализацию этого процесса путем составления и утверждения устава проекта. Такой устав определяет задачи проекта, график выполнения, используемый подход и процедуры, а также фиксирует тот факт, что эта деятельность поддержана руководством организации. Соответственно, такой устав должен будет периодически, обычно раз в год пересматриваться и утверждаться Управляющим комитетом организации.
При переходе к практической реализации очевидно, что для достижения конечной цели необходимо предварительно определить некоторую согласованную основу. В качестве такой основы может выступить набор архитектурных моделей высокого уровня.
Сформированный таким образом набор моделей документируется в произвольном формате, например, в виде обычного файла текстового редактора. Поскольку его основным назначением является использование для широкого обсуждения не только внутри команды проекта, но и с представителями различных подразделений,то применение специализированных средств моделирования на данном этапе может затруднить взаииодействие из-за отсутствия у всех участников необходимой подготовки и установленных специализированных средств. Например, даже применение UML-диаграмм может быть избыточно сложным для обсуждения со специалистами бизнес-подразделений.
Еще раз стоит подчеркнуть, что на данном этапе не следует углубляться в излишнюю детализацию. Напротив, более важным является «расширение» области охвата. При этом временные рамки этапа также должны быть четко определены и ограничены - так что даже для больших компаний срок реализации этапа с учетом обсуждений и согласований не должен превышать трех месяцев, а для мелких и средних - значительно меньше.
Информация о работе Применение архитектурных подходов в сфере информационных технологий