Этап 2. Параллельная разработка Концептуальной архитектуры и частных Архитектур предметных областей 2 страница

· будут разработаны и поддерживаться стандарты и правила (политики).

· соответствие стандартам и правилам будет контролироваться.

· архитектура будет неотъемлемой частью всего процесса управления ИТ на предприятии.

· технологическая архитектура будет контролироваться на уровне предпри-ятия в целом.

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

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

Публикации и распространение информации и документов описания архитектуры. На самом деле, публикация архи-тектурных документов является очень важным аспектом всего процесса управления архитектурой, но сам по себе этот инструмент не будет рабо-тать без других механизмов. С разработкой и реализацией архитектуры предприятия связаны интересы большого количества сторон, поэтому ин формация об архитектуре должна распространяться внутри организации на различных уровнях, в том числе с использованием визуальных, графи-ческих средств представления или специализированных языков. Для выс-шего руководства архитектура должна демонстрировать, как она обеспечи-вает достижение бизнес-целей и какие преимущества будут получены. Об-ластью интереса бизнес-пользователей являются их специфические пред-метные области и функциональные потребности. Руководители в области ИТ и технический персонал больше сфокусированы на технических компо-нентах, включая то, как впоследствии будет обеспечиваться поддержка и сопровождение разрабатываемых решений. Архитекторов отдельных про-ектов волнуют такие вопросы, как стандарты, шаблоны и правила, пригод-ные для повторного использования либо накладывающие ограничения на дизайн отдельных решений. Публикуя информацию об архитектуре, нужно стреииться удовлетворить все перечисленные категории заинтересован-ных сторон. Более того, чем более открытой является эта информация вну-три предприятия (эа исключением, возможно, определенных аспектов ар-хитектуры безопасности), тем больший эффект это принесет.

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

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

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

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

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

Рис. 1.10. Управление и контроль на разных этапах разработки архитектуры предприятия

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

Интересными являются данные о том, какие механизмы - жестко контро-лируемое выполнение правил или информирование и общие рекомендации организации чаще применяют на практике для обеспечения соответствия техни-ческих решений архитектуре. В частности, опрос, проведенный в 2003 году ком-панией Gartner среди финансовых организаций, показал, что примерно 50-60% организаций реализуют механизмы жесткого контроля за соблюдением предпи-саний архитектуры. Примерно 20-25% используют такие механизмы как общие рекомендации, при этом подразделения несут дополнительные затраты, связан-ные с несоответствием проектов утвержденной архитектуре. Только в 15-25% организаций архитектура носит рекомендательный характер, и невыполнение рекомендаций не имеет никаких явных организационных последствий.

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

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

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

Рис. 1.11. Организационная структура управления разработкой архитектуры предприятия

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

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

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

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

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

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

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

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

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

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

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

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

С практической точки зрения, архитектура реализуется постепенно и по-ступательно через выполнение отдельных проектов. Типичная ситуация выгля-дит так:

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

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

· делаются определенные изменения в архитектуре с учетом накопленного опыта;

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

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

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

Очевидно, что разработка архитектуры предприятия не будет иметь эффек-та, если организация не сможет обеспечить контроль за ее реализацией - с уче-том, однако, возможных обоснованных отклонений, как это отмечалось выше. Для этого можно применить подход, предложенный в публикациях Giga Group, где предлагается модель, которая обеспечивает классификацию архитектурных решений в соответствии со стратегическим позиционированием каждого решения так, как это показано на рис. 1.12.

Рис. 1.12. Модель рассмотрения архитектуры от Giga Group

Ядро архитектуры (центральная зона) - это те архитектурные решения, технологии, стандарты, которые в данный момент времени приняты организаци-ей в качестве стратегических.

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

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

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

· инвестиции в достаточной мере соответствуют архитектуре и могут быть рекомендованы;

· новые инвестиции отклонены из-за плохого соответствия архитектуре; инвестиции признаны необходимыми даже в условиях несоответствия Ар-хитектуре, и в Архитектуру вносятся изменения, чтобы отразить это несо-ответствие, описать новые функции, объекты данных и необходимые при-ложения;

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

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

Более развернутые рекомендации по контролю соответствия содержатся в модели TOGAF, где описаны два основных процесса:

· формализованная проверка проекта на соответствие архитектуре;

· оценка влияния архитектуры на проекты.

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

· соответствие развития системы утвержденной стратегии;

· обеспечение необходимой функциональности;

· приверженность стандартам и архитектурным принципам.

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

Рис. 1.13. Возсможные соотношения между реализацией и описанием архитектуры по TOGAF

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

· уменьшение проектных рисков за счет идентификации ошибок и «узких мест» в архитектуре разрабатываемой системы;

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

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

· идентификация областей, где сама архитектура (профили стандартов) мо-жет требовать модернизации.

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

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

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

Безусловно, возникают два вопроса, касающиеся финансовых затрат, свя-занных непосредственно с разработкой и последующим сопровождением Архи-тектуры предприятия (обновлением и поддержанием ее в актуальном состоя-нии). Сколько средств необходимо выделять на это? Как оценивать уровень за-трат на архитектуру?

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

На самом деле, на этот счет отсутствуют детальные и точные данные. По оцен-ке Gartner, в большинстве организаций вопросами разработки архитекту-ры и стратегического планирования в области ИТ занимаются обычно 2-4% пер-сонала ИТ-служб.Кроме затрат на персонал, дополнительные расходы связаны с приобретением средств моделирования и созданием репозитария для хранения артефактов (документов, моделей и пр.), описывающих Архитектуру предприятия.

Во-первых, необходимо учесть размеры первоначальных затрат, связанных с инициированием архитектурного процесса: обучение, подготовка обоснова-ния необходимости создания архитектуры предприятия, создание структур уп-равления и контроля. Эти траты вряд ли будут превышать примерно 50%. после-дующих ежегодных затрат на поддержку Архитектуры.

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

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

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

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

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

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

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

Дата добавления: 2015-04-25