Применение архитектурных подходов в сфере информационных технологий

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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