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

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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

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

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

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

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

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

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

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

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

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

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

Возвращаясь к истории развития общепризнанных моделей в сфере разработки архитектуры предприятия следует отметить, что все рассмотренные в данном пособии модели являются логическим продолжением одна другой, более того образуют вполне наблюдаемую траекторию развития (рис. 2.1). Причем после выпуска первой статьи Захмана, где он описал суть своего подхода и тем самым дал развитие всей дисциплине под названием «архитектура предприятия» исторически разработки новых методов и моделей разделились на 2 основных направления: первое было сосредоточено на государственных организациях и адаптации архитектурных подходов к ним, второе на развитие концепции «архитектуры предприятия» в корпоративной среде (методики IBM, Microsoft, Giga Group, Gartner и т.д.). Причем оба направления развивались параллельно.

Рис. 2.1. Исторические истоки моделей архитектуры предприятия

Адаптация архитектурных подходов в сфере государственных структур и ведомств началась в 1998 году с создания схемы FEAF (Federal Enterprise Architecture Framework, Рамочной структуры Архитектуры Федеральной организации). Ее специфика связана с ее предназначением – разработка в рамках системы задач государственного масштаба для США. Совет руководителей информационных служб (CIO Council) начал разработку FEAF в апреле 1998 года. В основу был положен Стратегический план деятельности CIO Council, разработанный с учетом приоритетов Закона по реформированию системы управления информационными технологиями в органах государственной власти принятого в 1996 году (Information Technology Management Reform Act или, иначе, закон или акт Клингера-Коэна), который определял направления разработки и использования Федеральной Архитектуры для максимизации отдачи от использования ИКТ в государстве под флагом "эффективности инвестиций денег налогоплательщиков в ИТ". Этот закон определил в качестве одной из обязанностей руководителей департаментов информационных технологий государственных ведомств разработку архитектуры информационных технологий.

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

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

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

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

 

Рис. 2.2. Структура модели FEAF

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

Двигатели архитектуры являются источниками изменений для архитектуры федерального предприятия и делятся на два типа:

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

Стратегическое направление (Strategic Direction). Руководство для разработки целевой архитектуры (см. ниже), которое содержит видение, принципы, цели и объекты.

Стратегическое направление определяет разработку целевой архитектуры. Оно включает в себя видение, сжатое и стратегическое описание поставленной цели развития архитектуры на предстоящие 5 лет, принципы руководства развитием этой архитектуры, а также цели и объекты для управления процессом развития архитектуры.

Текущая архитектура (Current Architecture). Определяет архитектуру "как есть" и состоит из двух частей:

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

Целевая архитектура (Target Architecture). Определяет архитектуру "как должно быть построено" и состоит также из двух частей: будущая бизнес-архитектура и будущая архитектура информационных технологий (т.е., соответственно, архитектура данных, приложений, и технологическая архитектура). Она дает представление о будущих возможностях и технологиях, которые явятся результатом соответствующих изменений.

Переходные процессы (Transitional Processes). Поддерживают процесс перехода от текущей архитектуры к целевой архитектуре. Критические переходные процессы для федерального предприятия включают планирование инвестиций в сферу ИТ, планирование изменений, управление конфигурациями, контроль и управление проектами.

Основные примеры переходных процессов включают следующие: