Процесс разработки архитектур: управление и контроль, Gap-анализ, внедрение

Обеспечение соответствия проектов архитектуре

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

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

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

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

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

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

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

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

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

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

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

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

Ключевым термином в обоих случаях будет являться само понятие "соответствие". На практике возможны следующие варианты, показанные на рис. 11.4.

Рис. 11.4. Варианты соответствия реализации и описания архитектуры по TOGAF

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

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

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

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

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

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

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

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