ЛЕКЦИЯ 8 23 страница

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. МЕТОДОЛОГИИ ОПИСАНИЯ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ

2.1. Модели архитектуры предприятия, ориентированные на государственные организации

2007 год ознаменовался 20-летним юбилеем методологий построения архитектуры предприятия. За это время было разработано множество методологий. Сегодня доминирующее положение занимают четыре методологии: структура Захмана для архитектуры предприятий, методология TOGAF (The Open Group Architecture Framework), архитектура федеральной организации (FEA) и методология Gartner (ранее именуемая Meta Framework).

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

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