3.1. Федеральная архитектура
3.1. Федеральная архитектура
3.1.1. Предпосылки
Архитектура любого предприятия (в том числе и федерального ведомства) является необходимым инструментальным средством для того, чтобы повысить результативность и эффективность существующих в организации бизнес-процессов (действий в зоне своей функциональной ответственности), а также для разработки и реализации поддерживающих их технических систем обеспечения. В наиболее простой интерпретации организация, учреждение, предприятие и т.д. представляют собой совокупность целенаправленных операционных действий, а архитектура предприятия дает структуру (или структурное описание) этого действия. Если более определенно, то архитектура предприятия систематизирует и дает фиксированное описание в виде работоспособных моделей, диаграмм и функциональных комментариев всех режимов деятельности данного объекта. В роли такого объекта может выступать либо отдельная автономная организация, либо функциональная или предметная область, которая охватывает несколько организационных границ (например, финансовое управление, управление сбором данных, управление материального обеспечения и т.п.).
Архитектура предприятия описывает деятельность предприятия с двух позиций:
1. с позиции логических терминов, таких как взаимодействующие бизнес-процессы и бизнес-правила, необходимая информация, структура и потоки информации, места расположения работы и пользователей;
2. с позиции технических понятий, таких как аппаратные и компьютерные средства, программное обеспечение, коммуникация данных, защита и безопасность, а также используемые стандарты.
При этом обе группы понятий охватывают с одной стороны текущее состояние "как существует" и перспективное (или целевое) состояние "как должно быть". Одна из главных задач архитектуры предприятия состоит в том, чтобы оптимизировать взаимные зависимости и существующие взаимоотношения и создать для этого соответствующую ИТ-инфраструктуру и приложения, которые поддерживали бы все эти действия. Опыт работы с федеральными правительственными агентствами показал, что попытки определить и построить основные ИТ-системы без ориентации на концепцию архитектуры предприятия, как правило, приводят к дублированию усилий и, что самое главное, сопровождается трудностями взаимодействия по интерфейсам и как следствие препятствует интеграции различных систем.
Начало научных разработок концепции архитектуры предприятия относится к середине 1980-х годов. В это время Джон Захман (John Zachman), широко известный специалист в области разработки моделей организационной деятельности, констатировал назревшую потребность в использовании логических универсальных конструкций (или, как он ее назвал, архитектуры) для определения и управления интеграцией систем и их компонент, поддерживающих функционирование предприятий (J. A. Zachman, “A Framework for Information Systems Architecture,” IBM Systems Journal, vol. 26(3), 1987). После этого Дж. Захман разработал "рамочный каркас или структуру для логического определения и фиксации архитектуры предприятия". Используя принципы, применяемые в классической архитектуре, а впоследствии и методы проектирования, применяемые в самолетостроении, в которых различные виды работ (например, архитектурные планы, планы подрядчика, торговые планы и другие, представляют различные позиции планируемого строения или проектируемого самолета), "рамочная структура" Дж. Захмана позволила идентифицировать все виды работ, которые должны быть предусмотрены для организации деятельности предприятия и которые позволяют сформировать его полную организационную и техническую структуру. "Рамочная структура" (или модель архитектуры) Дж. Захмана в своей основе опирается на шесть перспектив (или окон), каждое из которых отражает определенную позицию, связанную с производственной деятельностью предприятия. Эти перспективы (окна) отражают следующие позиции:
1. планировщик стратегии;
2. пользователь системы;
3. проектировщик системы;
4. разработчик системы;
5. субподрядчик и
6. сама система непосредственно.
В соответствии с этими перспективами Дж. Захман предложил шесть атрибутов или моделей объекта, которые охватывают следующие аспекты деятельности:
1. как объект функционирует;
2. что объект использует для своей работы;
3. где объект работает;
4. кто использует объект;
5. когда происходит деятельность объекта и
6. для чего объект работает.
Модель Дж. Захмана предоставляет удобные средства и способы идентификации и описания существующих и планируемых к разработке компонентов, а также и взаимоотношений между этими компонентами. Основное достоинство этих средств заключается в том, что они требуют значительно меньше времени и усилий на начальные периоды разработки или модернизации объекта.
3.1.2. Архитектура федеральных ведомств. История вопроса
Интерес к использованию научных механизмов при построении и модернизации информационно-технологических систем и ведомств в целом возник в американском Правительстве давно.
Начиная с конца 1980-х годов документы, описывающие архитектуру ведомства в федеральных учреждениях начали разрабатываться и распространяться в различных ведомствах федерального Правительства США. Одной из первых таких публикаций была работа Национального Института Стандартов и Технологии в 1989 году (National Institute of Standards and Technology, Information Management Directions: The Integration Challenge, Special Publication 500-167 (September 1989)). Впоследствии было выпущено руководство по архитектуре ведомства (Strategic Information Planning: Framework for Designing and Developing System Architectures (GAO/IMTEC-92-51, June 1992)), а также исследование конкретных примеров ее успешного использования в общественном и частном секторе (Executive Guide: Improving Mission Performance through Strategic Information Management and Technology (GAO/AIMD-94-15, May 1994). Главный вывод, сформулированный в последнем исследовании состоит в том, что архитектура ведомства является одним из критических факторов успеха рассматриваемых предприятий.
Следует подчеркнуть, что в 1996 году необходимость разработки и использования архитектуры ведомства была зафиксирована в Законе Клинджера-Коэна (Clinger-Cohen Act of 1996, Public Law 104-106, section 5125, 110 Stat.684 (1996)). Этот Закон, наряду с другими содержащимися в нем требованиями, обязывает начальников управлений по информатизации федеральных ведомств разрабатывать, поддерживать и обеспечивать реализацию архитектуры информационных технологий, как основного средства интегрирования функциональных процессов и ИТ-целей агентств.
Во исполнение этого Закона Административно-бюджетное управление, в сотрудничество с Управлением общей бухгалтерской (финансовой) отчетности (General Accounting Office - GAO), выпустил руководство по разработке и реализации архитектуры ведомства (Information Technology Architectures, Office of Management and Budget Memorandum M-97-16 (June 18, 1997), rescinded with the update of OMB Circular A-130, November 30, 2000).
Некоторое время назад Административно-бюджетное управление выпустило дополнительное руководство (Management of Federal Information Resources, Office of Management and Budget, Circular No. A-130 (November 30, 2000)), согласно которому инвестиции федеральных ведомств в информационные технологии должны ориентироваться на формирование архитектуры ведомства. Аналогично Совет начальников управлений по информатизации, в дополнение к выпущенному в 2000 году Руководству по принципам организации архитектуры федерального ведомства в сотрудничестве с Управлением общей бухгалтерской (финансовой) отчетности выпустил два дополнительных Руководства по архитектуре ведомства. Первое руководство определяет порядок и условия проведения инвестиций в ИТ в соответствии с требованиями формирования архитектуры ведомства (Chief Information Officers Council, Architecture Alignment and Assessment Guide, October 2000). Второе руководство ориентировано на разработку, техническое обслуживание и реализацию архитектуры ведомства, описывая в практических определениях все необходимые и последовательные шаги по управлению программой перехода к архитектуре ведомства (Chief Information Officers Council, A Practical Guide to Federal Enterprise Architecture, Version 1.0, February 2001). Последнее Руководство объясняет, каким образом следует начать и организовать процесс перехода к архитектуре ведомства, какие необходимы средства управления этим процессом, какие факторы следует учитывать при формулировании разработки архитектуры ведомства, каким образом продвигаться от текущего состояния архитектуры к целевой архитектуре ведомства и как гарантировать, что реализованный проект архитектуры ведомства обеспечивает выполнение всех предъявляемых требований и потребностей клиентов (потребителей услуг).
Вслед за этим несколько других федеральных ведомств выпустили собственные регламенты по архитектуре ведомства (в числе этих ведомств, например, Министерство обороны (DOD C4ISR Architecture Framework, Version 2.0, December 18, 1997), Министерство финансов (Treasury Enterprise Architecture Framework, Version 1.0, July 3, 2000) и ряд других. Хотя каждый из этих регламентов использует различную терминологию и несколько отличающиеся структуры, они в принципе являются непротиворечивыми в отношении своих целей и содержания и поэтому с успехом могут быть использованы большинством федеральных ведомств.
3.1.1. Предпосылки
Архитектура любого предприятия (в том числе и федерального ведомства) является необходимым инструментальным средством для того, чтобы повысить результативность и эффективность существующих в организации бизнес-процессов (действий в зоне своей функциональной ответственности), а также для разработки и реализации поддерживающих их технических систем обеспечения. В наиболее простой интерпретации организация, учреждение, предприятие и т.д. представляют собой совокупность целенаправленных операционных действий, а архитектура предприятия дает структуру (или структурное описание) этого действия. Если более определенно, то архитектура предприятия систематизирует и дает фиксированное описание в виде работоспособных моделей, диаграмм и функциональных комментариев всех режимов деятельности данного объекта. В роли такого объекта может выступать либо отдельная автономная организация, либо функциональная или предметная область, которая охватывает несколько организационных границ (например, финансовое управление, управление сбором данных, управление материального обеспечения и т.п.).
Архитектура предприятия описывает деятельность предприятия с двух позиций:
1. с позиции логических терминов, таких как взаимодействующие бизнес-процессы и бизнес-правила, необходимая информация, структура и потоки информации, места расположения работы и пользователей;
2. с позиции технических понятий, таких как аппаратные и компьютерные средства, программное обеспечение, коммуникация данных, защита и безопасность, а также используемые стандарты.
При этом обе группы понятий охватывают с одной стороны текущее состояние "как существует" и перспективное (или целевое) состояние "как должно быть". Одна из главных задач архитектуры предприятия состоит в том, чтобы оптимизировать взаимные зависимости и существующие взаимоотношения и создать для этого соответствующую ИТ-инфраструктуру и приложения, которые поддерживали бы все эти действия. Опыт работы с федеральными правительственными агентствами показал, что попытки определить и построить основные ИТ-системы без ориентации на концепцию архитектуры предприятия, как правило, приводят к дублированию усилий и, что самое главное, сопровождается трудностями взаимодействия по интерфейсам и как следствие препятствует интеграции различных систем.
Начало научных разработок концепции архитектуры предприятия относится к середине 1980-х годов. В это время Джон Захман (John Zachman), широко известный специалист в области разработки моделей организационной деятельности, констатировал назревшую потребность в использовании логических универсальных конструкций (или, как он ее назвал, архитектуры) для определения и управления интеграцией систем и их компонент, поддерживающих функционирование предприятий (J. A. Zachman, “A Framework for Information Systems Architecture,” IBM Systems Journal, vol. 26(3), 1987). После этого Дж. Захман разработал "рамочный каркас или структуру для логического определения и фиксации архитектуры предприятия". Используя принципы, применяемые в классической архитектуре, а впоследствии и методы проектирования, применяемые в самолетостроении, в которых различные виды работ (например, архитектурные планы, планы подрядчика, торговые планы и другие, представляют различные позиции планируемого строения или проектируемого самолета), "рамочная структура" Дж. Захмана позволила идентифицировать все виды работ, которые должны быть предусмотрены для организации деятельности предприятия и которые позволяют сформировать его полную организационную и техническую структуру. "Рамочная структура" (или модель архитектуры) Дж. Захмана в своей основе опирается на шесть перспектив (или окон), каждое из которых отражает определенную позицию, связанную с производственной деятельностью предприятия. Эти перспективы (окна) отражают следующие позиции:
1. планировщик стратегии;
2. пользователь системы;
3. проектировщик системы;
4. разработчик системы;
5. субподрядчик и
6. сама система непосредственно.
В соответствии с этими перспективами Дж. Захман предложил шесть атрибутов или моделей объекта, которые охватывают следующие аспекты деятельности:
1. как объект функционирует;
2. что объект использует для своей работы;
3. где объект работает;
4. кто использует объект;
5. когда происходит деятельность объекта и
6. для чего объект работает.
Модель Дж. Захмана предоставляет удобные средства и способы идентификации и описания существующих и планируемых к разработке компонентов, а также и взаимоотношений между этими компонентами. Основное достоинство этих средств заключается в том, что они требуют значительно меньше времени и усилий на начальные периоды разработки или модернизации объекта.
3.1.2. Архитектура федеральных ведомств. История вопроса
Интерес к использованию научных механизмов при построении и модернизации информационно-технологических систем и ведомств в целом возник в американском Правительстве давно.
Начиная с конца 1980-х годов документы, описывающие архитектуру ведомства в федеральных учреждениях начали разрабатываться и распространяться в различных ведомствах федерального Правительства США. Одной из первых таких публикаций была работа Национального Института Стандартов и Технологии в 1989 году (National Institute of Standards and Technology, Information Management Directions: The Integration Challenge, Special Publication 500-167 (September 1989)). Впоследствии было выпущено руководство по архитектуре ведомства (Strategic Information Planning: Framework for Designing and Developing System Architectures (GAO/IMTEC-92-51, June 1992)), а также исследование конкретных примеров ее успешного использования в общественном и частном секторе (Executive Guide: Improving Mission Performance through Strategic Information Management and Technology (GAO/AIMD-94-15, May 1994). Главный вывод, сформулированный в последнем исследовании состоит в том, что архитектура ведомства является одним из критических факторов успеха рассматриваемых предприятий.
Следует подчеркнуть, что в 1996 году необходимость разработки и использования архитектуры ведомства была зафиксирована в Законе Клинджера-Коэна (Clinger-Cohen Act of 1996, Public Law 104-106, section 5125, 110 Stat.684 (1996)). Этот Закон, наряду с другими содержащимися в нем требованиями, обязывает начальников управлений по информатизации федеральных ведомств разрабатывать, поддерживать и обеспечивать реализацию архитектуры информационных технологий, как основного средства интегрирования функциональных процессов и ИТ-целей агентств.
Во исполнение этого Закона Административно-бюджетное управление, в сотрудничество с Управлением общей бухгалтерской (финансовой) отчетности (General Accounting Office - GAO), выпустил руководство по разработке и реализации архитектуры ведомства (Information Technology Architectures, Office of Management and Budget Memorandum M-97-16 (June 18, 1997), rescinded with the update of OMB Circular A-130, November 30, 2000).
Некоторое время назад Административно-бюджетное управление выпустило дополнительное руководство (Management of Federal Information Resources, Office of Management and Budget, Circular No. A-130 (November 30, 2000)), согласно которому инвестиции федеральных ведомств в информационные технологии должны ориентироваться на формирование архитектуры ведомства. Аналогично Совет начальников управлений по информатизации, в дополнение к выпущенному в 2000 году Руководству по принципам организации архитектуры федерального ведомства в сотрудничестве с Управлением общей бухгалтерской (финансовой) отчетности выпустил два дополнительных Руководства по архитектуре ведомства. Первое руководство определяет порядок и условия проведения инвестиций в ИТ в соответствии с требованиями формирования архитектуры ведомства (Chief Information Officers Council, Architecture Alignment and Assessment Guide, October 2000). Второе руководство ориентировано на разработку, техническое обслуживание и реализацию архитектуры ведомства, описывая в практических определениях все необходимые и последовательные шаги по управлению программой перехода к архитектуре ведомства (Chief Information Officers Council, A Practical Guide to Federal Enterprise Architecture, Version 1.0, February 2001). Последнее Руководство объясняет, каким образом следует начать и организовать процесс перехода к архитектуре ведомства, какие необходимы средства управления этим процессом, какие факторы следует учитывать при формулировании разработки архитектуры ведомства, каким образом продвигаться от текущего состояния архитектуры к целевой архитектуре ведомства и как гарантировать, что реализованный проект архитектуры ведомства обеспечивает выполнение всех предъявляемых требований и потребностей клиентов (потребителей услуг).
Вслед за этим несколько других федеральных ведомств выпустили собственные регламенты по архитектуре ведомства (в числе этих ведомств, например, Министерство обороны (DOD C4ISR Architecture Framework, Version 2.0, December 18, 1997), Министерство финансов (Treasury Enterprise Architecture Framework, Version 1.0, July 3, 2000) и ряд других. Хотя каждый из этих регламентов использует различную терминологию и несколько отличающиеся структуры, они в принципе являются непротиворечивыми в отношении своих целей и содержания и поэтому с успехом могут быть использованы большинством федеральных ведомств.