Опубликован: 07.05.2007 | Уровень: специалист | Доступ: платный
Лекция 11:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Грета Березовская
Грета Березовская
Александр Медов
Александр Медов

Здравствуйте,при покупке печатной формы сертификата,будут ли выданы обе печатные сторны?

Артур Гатин
Артур Гатин
Россия, Казань, Казанский государственный энергетический университет, 2001
Николай Байбородин
Николай Байбородин
Россия, г. Хабаровск