Архитектура предприятия

1 Федеральное агентство связи Федеральное государственное образовательное бюджетное учреждение высшего профессионального образования «Поволжский государственный университет телекоммуникаций и информатики» ____________________________________________________________________________ Кафедра «Экономические и информационные системы» «УТВЕРЖДАЮ» Зав. кафедрой профессор « » августа ЭИС Маслов О.Н. 2013 г. КОНСПЕКТ ЛЕКЦИЙ ПО УЧЕБНОЙ ДИСЦИПЛИНЕ «АРХИТЕКТУРА ПРЕДПРИЯТИЯ» для специальности 080500 «Бизнес-информатика» Обсуждено на заседании кафедры « » августа протокол № 1 Самара 2013 2013 г. 2 УДК а004.41 Диязитдинова А.Р. Архитектура предприятия. Конспект лекций. – Самара.: ФГОБУ ВПО ПГУТИ, 2013. – 80 с. Целью дисциплины «Архитектура предприятия» является Формирование у студента профессиональных знаний по теоретическим основам построения архитектур предприятия включающих миссию и стратегию предприятия, бизнес-архитектуру и системную архитектуру; умение использовать современные методологии и средства проектирования и построения архитектур предприятия. Конспект лекций предназначен для студентов, обучающихся по специальности 080500 «Бизнес-информатика». Также конспект лекций может быть полезен студентам смежных специальностей, изучающим методологические принципы и методические приемы планирования и фактического создания архитектуры предприятия. Рецензент: Федеральное государственное образовательное бюджетное учреждение высшего профессионального образования «Поволжский государственный университет телекоммуникаций и информатики» © Диязитдинова А.Р., 2013 3 СОДЕРЖАНИЕ ВВЕДЕНИЕ ............................................................................................................. 5 1 ОБЩИЕ ПОНЯТИЯ ДИСЦИПЛИНЫ «АРХИТЕКТУРА ПРЕДПРИЯТИЯ»................................................................................................... 7 1.1 1.2 1.3 ПОНЯТИЕ И ОБЩЕЕ ПРЕДСТАВЛЕНИЕ ОБ АРХИТЕКТУРЕ ПРЕДПРИЯТИЯ ........... 7 ЭВОЛЮЦИЯ ПРЕДСТАВЛЕНИЙ ОБ АРХИТЕКТУРЕ ПРЕДПРИЯТИЯ...................... 9 ОБЩИЕ МЕТОДИЧЕСКИЕ ПРИНЦИПЫ СОЗДАНИЯ АРХИТЕКТУРЫ. .................. 14 1.3.1 Принципы создания архитектуры предприятия .................................................. 14 1.3.2 Компоненты архитектуры предприятия. ............................................................ 14 МЕТОДОЛОГИИ ОПИСАНИЯ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ 16 2 МОДЕЛЬ ЗАХМАНА...................................................................................... 16 МЕТОДОЛОГИЯ TOGAF (THE OPEN GROUP ARCHITECTURE FRAMEWORK) .. 23 МОДЕЛИ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ, ОРИЕНТИРОВАННЫЕ НА ГОСУДАРСТВЕННЫЕ ОРГАНИЗАЦИИ .......................................................................... 28 2.1 2.2 2.3 2.3.1 Схема FEAF (Federal Enterprise Architecture Framework) ................................... 28 2.3.2 Архитектура федеральной организации (FEA) .................................................... 35 2.4 СРЕДЕ МОДЕЛИ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ, РАЗРАБОТАННЫЕ В КОРПОРАТИВНОЙ 44 2.4.1 Взгляды компании Microsoft .................................................................................... 44 2.4.2 Взгляды компании IBM ............................................................................................ 50 2.4.3 Взгляды компании Gartner ...................................................................................... 53 3 ЛЕКЦИЯ: ПРОЦЕСС РАЗРАБОТКИ АРХИТЕКТУР: ЦЕЛИ И ЗАДАЧИ, ОБЩАЯ СХЕМА ............................................................................... 55 3.1 3.2 ЦЕЛИ И ЗАДАЧИ........................................................................................... 55 ОБЩАЯ СХЕМА АРХИТЕКТУРНОГО ПРОЦЕССА.............................................. 58 3.2.1 Модель процесса разработки и использования архитектуры ............................ 58 3.2.2 Направления разработки архитектуры: «сверху-вниз» или «снизу-вверх» ....... 63 3.3 С ЧЕГО НАЧАТЬ?.......................................................................................... 65 3.3.1 влияния 3.3.2 3.3.3 Обоснование необходимости проекта разработки архитектуры и факторы 65 Формирование команды проекта ........................................................................... 66 Определение границ архитектуры и используемых методик ............................. 67 4 ЛЕКЦИЯ: ПРОЦЕСС РАЗРАБОТКИ АРХИТЕКТУР: УПРАВЛЕНИЕ И КОНТРОЛЬ, GAP-АНАЛИЗ, ВНЕДРЕНИЕ ................... 69 4.1 УПРАВЛЕНИЕ И КОНТРОЛЬ АРХИТЕКТУРНОГО ПРОЦЕССА (GOVERNANCE) .... 69 4.1.1 Методы управления и контроля ............................................................................. 69 4.1.2 Организационные структуры, связанные с разработкой архитектуры .......... 71 4.1.3 Обеспечение соответствия проектов архитектуре........................................... 74 4.1.4 Оценка затрат на разработку и сопровождение архитектуры предприятия 76 4.2 GAP-АНАЛИЗ (АНАЛИЗ НЕСООТВЕТСТВИЙ) И МОДЕЛЬ РАЗВИТИЯ ЭЛЕМЕНТОВ ИТ-АРХИТЕКТУРЫ .................................................................................................... 76 4 КАК ОБЕСПЕЧИТЬ ВНЕДРЕНИЕ РЕЗУЛЬТАТОВ ПРОЕКТА РАЗРАБОТКИ АРХИТЕКТУРЫ .......................................................................................................... 79 4.3 ИСПОЛЬЗОВАННЫЕ ИСТОЧНИКИ ............................................................. 81 5 ВВЕДЕНИЕ Архитектура предприятия выделилась в отдельную дисциплину чуть более 20 лет тому назад и в настоящее время является одной из ключевых функций как корпоративного, так и проектного менеджмента, основным средством достижения и поддержания конкурентоспособности любого предприятия или организации, особенно в сфере ИТ. Сегодня все больше руководителей и аналитиков начинают испытывать потребность в комплексном описании и планировании развития своей организации. Это им нужно как минимум для того, чтобы знать, что их организация представляет собой в реальности, поддерживать рациональный порядок ее устройства, а затем – приступить к ее планомерному развитию или трансформации с учетом всех важных обстоятельств. Таким целям служит «Архитектура предприятия» (АП, Enterprise Architecture) – важнейшая комплексная дисциплина нового времени. В мире наблюдается настоящий бум работ в этой области, в штатных расписаниях позиция «Enterprise Architect» заняла устойчивое положение, ведущие университеты разработали углубленные курсы и выпускают квалифицированных специалистов данного профиля. При построении архитектуры предприятия, в частности, системной архитектуры, возникает немало традиционных вопросов. Все они имеют ответ, но любой ответ становится знанием предприятия только в том случае, если он задокументирован. Практически все известные методологии и стандарты (от отечественных ГОСТов и SADT до RUP) и инструменты (начиная с IDEF Designer, System Architect и BPwin/Erwin и заканчивая продуктами семейства Rational) предоставляют возможности для документирования только части из перечисленных знаний, поскольку ориентируются в значительной степени на разработку программных систем. Многие же из перечисленных выше вопросов лежат в слое бизнес-архитектуры. Отсюда цель дисциплины «Архитектура предприятия» – изучение способов улучшения деятельности организации на основе применения современных методов и методологий построения как отдельных доменов архитектуры, так и полной архитектуры предприятия, а также освоение студентами основных методологических принципов и методических приемов планирования и фактического создания архитектуры предприятия. Задачи курса «Архитектура предприятия»: − изучить основные модели и методы управления организацией на основе архитектурных подходов; − дать методологические основы выбора и применения методов повышения эффективности деятельности путем применения инструмента архитектуры предприятия. 6 − освоить основные принципы построения архитектуры предприятия и ее отдельных доменов; − уметь пользоваться основными методическими приемами различных архитектурных подходов (модель FEAF, TOGAF, FEA, методики IBM и Microsoft и т.д.); − получить навыки разработки архитектуры предприятия на основе построения ее «снизу-вверх» от бизнес-архитектуры до технологической архитектуры. Дисциплина «Архитектура предприятия» охватывает широкий круг проблем и потому связана практически со всеми дисциплинами, входящими в учебный план по направлению подготовки 080500 «Бизнес-информатика». 7 1 ОБЩИЕ ПОНЯТИЯ ДИСЦИПЛИНЫ «АРХИТЕКТУРА ПРЕДПРИЯТИЯ» 1.1 ПОНЯТИЕ И ОБЩЕЕ ПРЕДСТАВЛЕНИЕ ОБ АРХИТЕКТУРЕ ПРЕДПРИЯТИЯ Существует несколько определений и моделей архитектуры, предлагаемых в различных национальных и международных стандартах. Приведем одно из них, дополнив комментариями из других, которые расширяют и уточняют понятие архитектуры. Архитектура системы (предприятия) представляет стратегическую информационную основу, которая определяет: − структуру бизнеса; − информацию, необходимую для проведения этого бизнеса; − технологии, применяемые для поддержания деловых операций; − переходные процессы преобразования, развития, которые необходимы для реализации новых технологий в ответ на появление новых изменяющихся бизнес - потребностей. Таким образом, архитектура системы (предприятия) представляет модель основного расположения и взаимосвязей внутренних частей системы (физического либо концептуального объекта или сущности). Эта модель должна отвечать определенным требованиям полезности. Поэтому качество описательных представлений должно быть настолько конструктивным, чтобы на их основе можно было создать (продуцировать) описанный объект и поддерживать его на дальнейшем протяжении жизненного цикла. Предприятие является гибридной системой, определяемой свойствами людей и машин. Люди как объекты модели или ресурсы характеризуются поведением (они обучаются, решают различные задачи). Машины осуществляют действия или реагируют на другие действия. В этой связи подчеркнем, что эти объекты системы нуждаются в различных видах информации. Приведенное определение качественно описывает базовое понятие архитектуры. Для представления общей архитектуры предприятия используются модели, содержащие слои отдельных архитектурных представлений. Как правило, в верхнем слое отражены функциональные требования к предприятию, связанные с его деятельностью. В нижних слоях отражаются технические особенности используемых информационных систем и технологий. В качестве исходной для представления базовой схемы можно использовать модель архитектуры предприятия (Enterprise Architecture Model), предложенную национальным институтом стандартов и технологий США (National Institute of Standards and Technology - NIST), представленную на Рис. 1. 8 Бизнес-архитектура Управляет Обратная связь Информацион ная архитектура Предписывает Архитектура информационных систем Идентифицирует Архитектура данных Поддерживается посредством Архитектура систем доставки HW, SW, коммуникации Рис. 1. Схема архитектуры компьютеризированного предприятия по NIST (HW-hardware-аппаратное обеспечение, SW-software-программное обеспечение) Архитектура предприятия (Enterprise Architecture, EA) является одним из инструментов организационных изменений как для всего предприятия в целом (в том числе с использованием ИТ), и так и той части организации, которая отвечает за информационные технологии. Гуру в области бизнеса отмечают, что, к организационным изменениям можно подойти с двух сторон. Во-первых, можно произвести реорганизацию, реинжиниринг процессов, то есть, перестроить то, как организация «работает», а во-вторых, можно и нужно управлять знаниями. Рассматривая построение архитектуры предприятия как элемент организационных изменений, следует отметить, что имеют место оба подхода. Конечно, архитектура предприятия - это прежде всего управление знаниями, т.е. процесс сбора и распространения информации о том, как организация использует и должна использовать ИТ в своей деятельности. Включение же в нее представлений о бизнес-архитектуре обеспечивает связь с возможностями оптимизации бизнес-процессов. 9 Архитектура предприятия частично затрагивает и процессы управления ИТ в организации. В процессе проведения аудита информационных технологий, построение EA может дополнить достаточно эффективные методики организации и реорганизации процессов внутри ИТ-службы, такие как ITIL, COBIT и другие. 1.2 ЭВОЛЮЦИЯ ПРЕДСТАВЛЕНИЙ ОБ АРХИТЕКТУРЕ ПРЕДПРИЯТИЯ Для того чтобы разобраться, какой должна быть архитектура предприятия, а также того, как именно она связана с информационными системами, имеющимися на предприятии, попробуем вначале определить самые общие рамки данного понятия. «Корпоративная архитектура» или «архитектура предприятия» являются терминами, которые специалисты очень часто используют, но при этом редко бывает ясно, что имеется в виду на практике. В реальности профессионалы в области информационных технологий, понимают под архитектурой ИТ достаточно большой спектр понятий – структурированное семейство технических руководств, включая концепции, принципы, правила, шаблоны и интерфейсы, а также взаимосвязи между ними, которые используются при создании новых информационных систем и развитии существующих систем. В отличие от них, профессионалы в области бизнеса не рассматривают этот вопрос как вопрос исключительно технологий. Наоборот, они разговаривают в терминах бизнесмоделей, бизнес-процессов и иногда – бизнес-архитектуры (она как раз и является одним из представлений архитектуры предприятия). В результате эволюции указанных выше понятий и анализ взаимосвязей между ними прошел множество этапов. Каждый из них был связан с расширением охвата разрабатываемых моделей, что приводило к более комплексному и всеобъемлющему (а значит более реалистичному) подходу к описанию деятельности организации, в том числе и в сфере ИТ. В литературе, посвященной данной проблематике [(А. Данилин, 2005)] приводится следующая общая схема эволюции данных понятий (Рис. 2). В ранних работах ИТ-архитектура понималась в основном как технологическая архитектура или архитектура, определяющая инфраструктуру информационной системы. Работы по описанию архитектуры сводились к рассмотрению исключительно технических аспектов, то есть формированию технологических стандартов и принципов, включая проведение инвентаризации различных технологий, используемых в организации. Такой подход хоть и позволяет добиться определенных преимуществ например, снизить стоимость закупок и эксплуатации информационных систем и уменьшить затраты на разработку приложений и обучение персонала. Однако он является заведомо ограниченным, так как не подразумевает ориентацию на решение бизнес-задач, которые, как известно, могут меняться весьма кардинально, требуя от организации большой гибкости в части архитектуры (в том числе и в сфере информационных технологий). 10 Рис. 2. Эволюция понятия «архитектура предприятия» Следующей ступенью развития оказалось понятие корпоративной информационнотехнологоческой архитектуры масштаба предприятия (EWITA Enterprise-Wide Information Technology Architecture). Даже название уже указывает на то, что она сочетает в себе как технологические, так и аспекты, связанные с данными. Основное направление работ при этом состоит в совместном использовании общих данных, исключении дублирования бизнес-функций, координации управления пользователями, ресурсами, информационной безопасностью за счет улучшений в управлении портфелем прикладных систем. Архитектура данного этапа эволюции описывает то, как компоненты информационной системы связаны между собой; точно так же бизнес-архитектура описывает то, как элементы бизнеса связаны между собой. Такой подход, конечно, обеспечивает более эффективное взаимодействие различных структурных подразделений организации за счет совместного доступа к информации различных подразделений, а также внешних организаций (клиентов, партнеров, поставщиков, т.н. «микросреды бизнеса»), уменьшения дублирования с точки зрения параллельной реализации близких по функционалу прикладных систем для различных бизнес-подразделений и решения проблем, которые затрагивают интересы нескольких подразделений, например, вопросы интеграции и взаимодействия информационных систем. Получаемые преимущества относятся прежде всего к оперативной деятельности организации. 11 Очевидным логическим продолжением данной траектории развития явилось добавление к технологическим и информационным аспектам описания бизнеса организации. В результате появилось понятие архитектуры предприятия, которая объединяет корпоративную ИТ-архитектуру масштаба предприятия с бизнес-архитектурой и позволяет обеспечить переход на стратегический уровень управления. В реальности все три аспекта представляют собой лишь взгляды с разных точек зрения на одну и ту же организацию, при этом они связаны между собой неразрывно. Значит совершенно логично, что они должны быть объединены в одну модель, которая бы учитывала и вполне понятно показывала, как связаны друг с другом все элементы ведения бизнеса, в том числе и связанные с информационными технологиями. Особенно стоит отметить, что с точки зрения современных архитектурных подходов, нет особой разницы, какую именно организацию рассматривать, коммерческую или нет. Это достигается за счет того, что бизнес-архитектура обеспечивает гибкость моделирования, поскольку включает в себя описание миссии и целей рассматриваемой организации. Поэтому за рубежом для описания деятельности и функций государственных организаций очень часто используется термин «бизнес государственных организаций», что пока не принято в условиях российской действительности. Более того существуют уже проработанные готовые модели архитектуры предприятия, описывающие деятельность именно государственных агентств и ведомств (например, Архитектура федеральной организации (Federal Enterprise Architecture, FEA)). Рассмотрим более подробно, что именно дает такой архитектурный подход к описанию организации? Несомненно, преимуществами такого включения бизнес-архитектуры в контекст рассмотрения целостной модели предприятия являются большая способность организации к изменениям или динамичность и синхронизация возможностей информационных технологий с бизнесстратегией. Во-первых, изменение в бизнес-стратегии приводит к изменениям в обеспечивающих процессах и технологических решениях, что не приводит к потере целостности модели. Во-вторых, сами информационные технологии могут оказывать непосредственное влияние на формирование бизнес-стратегии. То есть такое трехкомпонентное моделирование позволяет учесть внутренние взаимосвязи и наиболее реалистично их смоделировать. Сама концепция архитектуры предприятия явилась результатом поиска некоторого целостного подхода, который обеспечил бы «взгляд на организацию в целом», с учетом всех возможных измерений, хотя учет большего количества измерений предполагает и рост сложности представлений об архитектуре [(J.Schekkerman, 2004)]. В графическом виде связь таких понятий, как бизнес-архитектура, корпоративная ИТ-архитектура и «архитектура предприятия», а также преимущества, которые обеспечивает каждый вид моделирования показана на Рис. 3. 12 Рис. 3. Развитие представлений об архитектуре предприятия Эволюция понятия «архитектура предприятия» связана с теми изменениями, которые происходили и происходят во взглядах на принципы организации деятельности предприятия как такового. Говоря точнее, прежде всего, имеется в виду использование следующих организационных механизмов, которые условно показаны на Рис. 4 (А. Данилин, 2005): − функциональная специализация; − реинжиниринг бизнес-процессов; − корпоративная архитектура. Одной из самых простейших структур управления является функциональная, для которой характерно создание структурных подразделений, каждое из которых имеет свою четко определенную, конкретную задачу и обязанности. Следовательно, в условиях данной структуры каждый орган управления, а также исполнитель специализирован на выполнении отдельных видов управленческой деятельности (функций). Создается аппарат специалистов, отвечающих только за определенный участок работы. В основе такой структуры управления лежит принцип полного распорядительства: выполнение указаний функционального органа в пределах его компетенции обязательно для подразделений. Такой подход, несмотря на свою простоту, предполагает наличие ряда преимуществ, одним из самых явных из них является достижение определенного уровня эффективности в выполнении специализированных для данных организационных единиц функций и процессов. Но при этом неизбежно возникает фрагментация в общих управлении и процессах, что обычно требует огромных усилий по налаживанию интерфейсов взаимодействия между организационными структурами. В то же время реализация 13 интегрированных и ориентированных на клиентов процессов требует достаточно высокого уровня межфункционального взаимодействия. Рис. 4. Изменение организационных принципов предприятия Подход, связанный с реинжинирингом бизнес-процессов, изначально признает тот факт, что процессы «пересекают линии» функционального разделения. Основное внимание уделяется межфункциональным процессам с целью достижения кардинальных улучшений. Общее управление деловыми действиями (бизнес-процессами) называют инжинирингом бизнеса, подразумевая постоянное улучшение процессов. Реинжиниринг нацелен на то, чтобы не только каждое звено бизнеса действовало продуктивно, но и на то, чтобы вся система их взаимодействия была нацелена на получение максимального эффекта мультипликации, т.е. того эффекта, который невозможно получить каждому в отдельности, но реально достичь за счет совместных усилий, организованных оптимальным образом. Концепция архитектуры предприятия является вершиной современного развития представлений об организационных принципах работы предприятия, как бы точкой слияния подходов по организационным изменениям и изменениям во взглядах на роль и использование информационных технологий. Это, в частности, предполагает осознание того факта, что, с одной стороны нельзя игнорировать технологии при проектировании бизнес-процессов, а с другой стороны, нельзя игнорировать характер и специфику бизнеса и бизнеспроцессов при выборе и проектировании технологических решений. Т.е. архитектура предприятия – это архитектура возможностей и потенциала бизнеса, основанных на комбинации таких работающих совместно факторов, как люди, процессы и технологии. 14 1.3 ОБЩИЕ МЕТОДИЧЕСКИЕ ПРИНЦИПЫ СОЗДАНИЯ АРХИТЕКТУРЫ. Основные цели создания и использования архитектуры предприятия и его систем позволяют осуществить: − выбор рационального (реализуемого, достигающего цели) решения за- дач основной деятельности бизнеса предприятия; − сохранение взгляда на целое в стратегической перспективе; − исключение провалов в устройстве системы и при ее эксплуатации; − создание основы и критериев для оценки частных архитектур; − оптимальное планирование инвестиций предприятия. 1.3.1 Принципы создания архитектуры предприятия К общим методическим принципам создания архитектуры предприятия можно отнести целый ряд принципов. 1) Принцип согласованности слоев. Архитектурные слои связаны так, как это представлено на Рис. 1. Качество связи слоев должно быть таким, чтобы бизнес-потребности и ИТ-решения оставались согласованными на стратегическую перспективу. 2) Принцип независимости слоев. С учетом первого принципа согласованности слои должны быть независимы в том смысле, что изменения, производимые в том или ином слое, требовали бы минимально возможной степени изменений в других слоях. 3) Принцип свободы выбора. Все решения по выбору своей архитектуры и стандартов своего предприятия осуществляет само предприятие и несет ответственность за решение своих задач. 4) Принцип постепенной детализации архитектуры. Архитектурные продукты концептуального значения создаются постепенно по шагам. На каждом шаге свои продукты с постоянной проверкой на удовлетворение требований. 5) Принцип постоянной трансформации архитектуры предприятия. С учетом изложенных выше принципов архитектура предприятия и его система должна находиться в постоянно актуализируемом состоянии, чтобы отвечать на новые требования внешней среды: новые потребности клиентов, новые возможности информационных технологий (ИТ), новые угрозы со стороны внешней среды. 1.3.2 Компоненты архитектуры предприятия. Выделяют следующий набор компонентов архитектуры. Двигатели архитектуры (Architecture Drivers) отражают внешние стимулы изменения архитектуры: бизнес-стимулы и технические стимулы. 15 В качестве бизнес-стимулов может выступать новое законодательство, новые инициативы администрации, ассигнования для ускорения развития отдельных сфер, рыночные силы. В роли технических двигателей могут выступать новое и улучшенное программное обеспечение, аппаратные средства ЭВМ и их комбинации. Стратегическое направление (Strategic Direction) - руководство для разработки целевой архитектуры, которое содержит видение миссии предприятия, принципы его построения, цели и объекты предприятия. Текущая архитектура (Carrent Architecture) определяет архитектуры предприятия "как есть" и состоит из двух частей: текущая бизнес-архитектура и техническая архитектура (данные, приложения и технологии). Она отражает текущие возможности и технологии, а также служит объектом для дальнейшего расширения. Целевая архитектура (Target Architecture) определяет архитектуру предприятия "как должно быть построено" и состоит из двух частей: целевая бизнес-архитектура и техническая архитектура (т.е. данные, приложения и технологии). Она представляет будущие возможности и технологии, которые являются результатом улучшения проекта поддержки изменяющихся бизнес - потребностей. Переходные процессы (Transitional Processes) поддерживают переход от текущей архитектуры к целевой архитектуре. Критические переходные процессы для предприятия включают планирование инвестиций в сферу ИТ, планирование перехода, управление конфигурацией, контроль и управление проектом. Архитектурные сегменты (Architectural Segments) отражают ориентацию отдельных частей общей архитектуры на главные бизнес - области. Архитектурные модели (Architectural Models) определяют бизнес - модели и конструкторские (технические) модели, которые отражают все необходимые сегменты для полного описания предприятия. Стандарты (Standards) включают все стандарты, руководящие принципы (руководящие материалы), а также передовой опыт. Примерами стандартов являются: − стандарты безопасности; − стандарты данных относятся к данным, метаданным и другим связан- ным структурам; − стандарты приложений относятся к прикладному ПО; − стандарты технологий относятся к операционным системам и аппарат- ным платформам. 16 2 МЕТОДОЛОГИИ ЯТИЯ ОПИСАНИЯ АРХИТЕКТУРЫ ПРЕДПРИ- 2.1 МОДЕЛЬ ЗАХМАНА Значительный вклад в развитие концепции архитектуры предприятия был сделан Дж. Захманом (John A. Zachman). С 1987 года, когда была предложена первая версия этой модели, расширенная впоследствии в работах 1992-96 гг., она была использована достаточно большим количеством крупных компаний, входящих в список 2000 крупнейших корпораций мира, такими, например, как General Motors, Bank of America и др. Модель Захмана также послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия, таких как Федеральная Архитектура США (FEAF – Federal Enterprise Architecture Framework), Методика описания архитектуры Open Group (TOGAF – The Open Group Architecture Framework), Методика описания архитектуры министерства обороны США (DoDAF – Department of Defence Architecture Framework). Модель Захмана не навязывает конкретных инструментальных особенностей при формировании моделей. Благодаря этому схема архитектуры предприятия Дж. Захмана может использоваться в качестве референсной модели для разработки адаптированных методических материалов для конкретных предприятий. Здесь под референсной понимается ссылочная, рамочная эталонная модель. Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур (framework), для описания современных сложных корпоративных систем. В своей работе Дж. Захман определил архитектуру предприятия как «набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)». Модель преследует две основные цели – с одной стороны, логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции. Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Для любой достаточно сложной системы общее число связей, условий и правил обычно превосходит возможности для одновременного рассмотрения. В то же время отдельное, в отрыве от других, рассмотрение каждого аспекта системы чаще всего приводит к неоптимальным решениям, как в плане производительности, так и стоимости реализации. Собственно модель представляется в виде таблицы, имеющей пять строк и шесть столбцов (Рис. 5). Заметим, что в модели именно пять строк, просто ото- 17 браженная на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом. Рис. 5. Модель Захмана Перспективы (строки в таблице) могут, в частном случае, соответствовать различному уровню управления предприятием, если речь идет об архитектуре предприятия или использования информационной системы. Две верхние строки соответствуют наиболее общим представлениям и достаточно широко описывают существующее окружение, планы и цели. Если проводить аналогию со строительством, то эти уровни содержат сведения о местонахождении и назначении постройки («особняк» для отдыха в престижном коттеджном поселке в элитной зоне), а также диаграммы, планы и картинки, которые архитектор обсуждает с хозяином будущего дома. Следующий уровень «логической модели» уже является более конкретным, но все равно еще достаточно абстрактным. Это схемы, которые архитектор дома должен показывать подрядчикам. Аналогично, в применении к деятельности предприятия верхняя строка «Контекст» соответствует уровню интересов высшего руководства и собрания акционеров. Второй уровень соответствует интересам бизнес-менеджеров и 18 владельцев процессов. Третий уровень – тот, на котором бизнес-менеджеры, бизнес-аналитики и менеджеры, отвечающие за ИТ, должны работать вместе. Уровни с четвертого и далее описывают детали, которые представляют интерес для ИТ-менеджеров, проектировщиков, разработчиков. На каждом из этих уровней участники, вообще говоря, рассматривают одни и те же категории вопросов, соответствующих столбцам в таблице, – только с различным уровнем абстракции и детализации. В содержание этих колонок входят: − используемые данные (что?) − процессы и функции (как?) − места выполнения этих процессов (где?) − организации и персоналии–участники (кто?) − управляющие события (когда?) − цели и ограничения, определяющие работу системы (зачем?). Основные правила заполнения таблицы следующие: − каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы («базис»); − порядок следования колонок несущественен; − каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа); − базовые модели для каждой из колонок являются уникальными; − соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы; − заполнение клеток должно проводиться последовательно «сверху вниз». Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес – например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – мотивация). Фактически, данная строка определяет контекст всех последующих строк. Вторая строка (концептуальная модель предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов. Третий уровень (логическая модель) соответствует рассмотрению с точки зрения Системного Архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила 19 их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций. На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектноориентированной среды. Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками. Последний, шестой уровень описывает работающую систему. На этом уровне могут быть введены, в том числе, такие объекты, как инструкции для работы c системой, фактические базы данных, работа службы HelpDesk. Рассмотрим теперь, как осуществляется последовательная детализация отдельных аспектов описания системы, для чего обратим внимание на различные колонки таблицы. Напомним, что порядок расположения колонок в таблице, вообще говоря, произволен. Так, первая колонка отвечает на вопрос «ЧТО?» и определяет используемые в системе данные. На верхнем уровне достаточным будет простое перечисление основных объектов, используемых в бизнесе. На втором уровне данные объекты объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы «сущности-связи» (ER-диаграммы) с отражением основных связей и наиболее существенных бизнес-ограничений. На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе – иерархию классов). Следующий уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. Наконец, последний уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистику обращений и т.п. Конечно, можно отметить определенное несовершенство данной модели при использовании объектно-ориентированного подхода – фактически модель предписывает раздельное рассмотрение данных (свойств) и функций (методов) классов. Колонка функций (ответ на вопрос «КАК?») предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. В частности, на первом уровне достаточным будет простое перечисление бизнес-процессов. Второй уровень будет содержать модель бизнес-процессов, которая впоследствии детализируется в операции над данными и архитектуру приложений (уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец, исполняемые модули. При этом, на- 20 чиная с 4-го уровня, рассмотрение ведется уже не в рамках Предприятия в целом, а по отдельным подсистемам или приложениям. Следующая колонка (вопрос «ГДЕ?») определяет пространственное распределение компонент системы и сетевую организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех производственных объектов. На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой, – будь то обмен информацией или поставки товаров. На третьем уровне системной архитектуры осуществляется привязка компонент информационной системы к узлам сети. Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ, системного программного обеспечения, а также средств промежуточного уровня (так называемое «middleware»), используемых для интеграции различных компонент информационной системы между собой. Типичным примером могут являться брокеры запросов или средства обмена сообщениями. На пятом уровне определяются используемые протоколы и спецификации каналов связи. Последний уровень описывает функционирование реализованной сети. Колонка таблицы, отвечающая на вопрос «КТО?», определяет участников процесса. На уровне планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими функции. На следующем уровне приводится полная организационная диаграмма, а также могут быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли (в RUP используются диаграммы событий и описание вариантов использования), требования к интерфейсам пользователя и правила доступа к отдельным объектам, физическая их реализация на уровне кода или операторов определения доступа к таблицам в СУБД. Последний уровень описывает обученных пользователей системы. Пятая колонка отвечает на вопрос «КОГДА?» и определяет временные характеристики бизнес-процессов и работы системы. Опять-таки детализация осуществляется сверху вниз, начиная от календарного плана (уровень 1) и основных параметров, характеризующих выполнение бизнес-процессов, – например, требование ко времени оформления сделки (уровень 2). На третьем уровне определяются события, вызывающие изменение состояния информационных объектов и инициацию операций над ними. На следующем уровне эти события транслируются в программные вызовы (триггеры) или передаваемые сообщения. Пятый уровень определяет физическую реализацию обработки таких событий. Наконец, на 6-м уровне – фактическая история функционирования системы. Последняя колонка («ПОЧЕМУ?» или «ЗАЧЕМ?») служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем. Исходной точкой является бизнесстратегия, которая затем последовательно транслируется в бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 – в со- 21 ответствующие приложения, необходимые для включения в состав информационных систем и, в дальнейшем, в их физическую реализацию. Такая модель описания в целом полезна для идентификации возможных ограничений. Эти ограничения могут «распространяться» как от верхних уровней к нижним (например, указание руководства компании о выборе тех или иных средств, продуктов или принципов работы), так и в обратном направлении – например, возможности существующих технологий беспроводной связи в значительной степени определяют спектр предлагаемых услуг и организацию бизнес-процессов у провайдеров этих услуг. Важным принципом предложенной модели является необходимость последовательного перехода при углублении детализации рассмотрения. Пропуск отдельных элементов, например, прямой переход от описания модели бизнеспроцесса к физической реализации системы требует "привлечения магии" и почти всегда приводит к неудаче. На практике это часто случается при попытке разработки программы на основании только устного описания требований пользователя. Основными характеристиками данной модели Захмана, являются следующие: − простота для понимания как техническими, так и нетехническими специалистами; − целостность в отношении предприятия, то есть каждая проблема может быть соотнесена с предприятием в целом; − поддержка обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий; − возможность применения для планирования, позволяющего лучше принимать решения за счет того, что решение никогда не будет выноситься «в пустоте» (в отрыве от остальных аспектов деятельности предприятия); − применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия Предприятия как целого; − нейтральность, то есть независимость от каких-либо инструментов; благодаря этому каждый инструмент и методология могут быть отображены на данную модель и могут явно показать, что они делают и чего они не делают. Созданная модель архитектуры служила простым, но мощным инструментом по применению системного подхода для планирования работ по созданию и использованию информационных систем и их стыковки. Захман писал, что схема архитектуры позволяет концентрироваться на отдельных аспектах системы и в то же время не терять ощущения общего контекста или «холистической» перспективы (то есть, взгляда на предприятие в целом). Он подчеркивал, что 22 именно потеря такой перспективы, в частности, разработка систем субподрядчиками, находящимися «вне контекста», уже около пятидесяти лет составляет причину появления неинтегрируемых и не поддерживающих предприятие должным образом систем, которые к тому же весьма дорого заменять. Баланс между сущностью реализации отдельных ячеек и интегрированным взглядом на систему поддерживается моделью Захмана за счет того, что она: − облегчает понимание и общение людей, имеющих разные роли в процессах создания, развития и использования системы; − ясно определяет фокус внимания на (относительно) независимых параметрах для целей анализа; − но в то же время обеспечивает поддержку контекстных взаимосвязей, важных для сохранения целостности системы. Рассмотрим, как может использоваться подход, предложенный Захманом, на практике. Во-первых, данную модель удобно применять для классификации всей информации, описывающей предприятие и информационные системы этого предприятия, выявления «белых пятен» и координации работ. Во-вторых, данную модель можно использовать на метауровне – для сравнения различных реализаций создания архитектур предприятия. Наконец, она может являться удобным средством для использования в отдельных проектах. Например, в проекте по созданию корпоративного информационного портала необходимо определить элементы в строках 3-5 колонки 4 – соответственно, требования пользователей к представлению данных, интерфейсы и спецификацию по разграничению доступа с учетом существующих «унаследованных» компонент информационной системы. Эта существующая технологическая архитектура, в свою очередь, рассматривается в ячейке на пересечении четвертой строки и третьего столбца таблицы. Нельзя, конечно, считать, что данная модель лишена недостатков. Один из них заключается в том, что при применении ее на практике возникают определенные трудности, связанные с отсутствием «встроенного механизма» распространения изменений между элементами таблицы. Действительно, предположим, что изменилась организация процесса поставок в компании (схема логистики). Это потребует отслеживания «вручную» всех взаимосвязей, проверки актуальности и внесения изменений в модели и другие артефакты во всех потенциально «затрагиваемых» ячейках. Другим ограничением модели является отсутствие рассмотрения системы в динамике. Действительно, каждый элемент таблицы может содержать как описание существующего состояния («как есть»), так и целевого, а также всех промежуточных состояний. При этом сама модель не содержит средств для четкого разделения этих различных «временных срезов». 23 2.2 МЕТОДОЛОГИЯ TOGAF (THE OPEN GROUP ARCHITECTURE FRAMEWORK) На основе модели Захмана выстроена методология TOGAF (The Open Group Architecture Framework), разработанная консорциуумом The Open Group) Изначально данная методология не воплощала целостную концепцию архитектуры предприятия. Первоначально (версии с 1 по 7) TOGAF включала только технические аспекты архитектуры, однако недавно в эту инфраструктуру была добавлена предметная область архитектуры бизнеса (версия 8, Enterprise Edition), в результате TOGAF быстро переместилась на передний план современных вариантов инфраструктур архитектуры предприятий. На момент включения в TOGAF бизнес-архитектуры (Рис. 6), эта инфраструктура уже имела солидную технологическую основу в виде своих предметных областей. Включение в TOGAF предметной области архитектуры бизнеса способствовало дальнейшему росту ее популярности, тогда как для других инфраструктур, у которых сначала не было архитектуры технологии, началось трудное время разработки этой предметной области. Захман, Спивак и некоторые другие намеренно поддерживали высокий уровень абстракции, что негативно повлияло на их восприятие, поскольку они не смогли получить поддержку технического сообщества. Рис. 6. Архитектура предприятия в модели TOGAF Архитектура бизнеса – описывает процессы, используемые для достижения бизнес-целей. Архитектура приложений – описывает структуру конкретных приложений и их взаимодействие друг с другом. Архитектура данных – описывает структуру корпоративных хранилищ данных и процедуры доступа к ним. Технологическая архитектура – описывает инфраструктуру оборудования и программного обеспечения, в которой запускаются и взаимодействуют приложения. Кроме собственно структуры самой EA данный подход предлагает и конкретную методику ее построения (Architecture Development Method, метод ADM). В модели TOGAF мир архитектуры предприятия рассматривается как 24 континуум архитектур (Enterprise Continuum) то есть некоторый набор готовых моделей, от максимально обобщенных до максимально специализированных. Процесс создания конкретной архитектуры предприятия, рассматривается как переход от общей архитектуры к специализированной. Методика разработки архитектуры в модели TOGAF представляет собой процесс осуществления такого перехода. В модели TOGAF наиболее обобщенные архитектуры называются фундаментальными. Эти принципы построения архитектуры теоретически могут использоваться практически любой ИТ-организацией в мире. Следующий уровень специализации в модели TOGAF представлен общесистемными архитектурами. Эти принципы прослеживаются во многих - возможно, не во всех типах предприятий. Следующий уровень специализации в модели TOGAF называется отраслевыми архитектурами. Эти принципы характерны для предприятий, занятых в одной сфере деятельности. Самый высокий уровень специализации в модели TOGAF называется архитектурами организаций. Это архитектуры конкретных предприятий. На Рис. 7 структурно показана суть методики подхода TOGAF. Рис. 7. Континуум предприятия и методика разработки TOGAF подразумевает, что континуум предприятия действует как коллекция компоновочных блоков (шаблонов), которая предоставляет коллективам, занимающимся архитектурой предприятия, соответствующие архитектуры, модели и процессы, из которых можно собирать готовые решения, как в детском конструкторе. Континуум предприятия, накопитель таких ресурсов, как модели, шаблоны решений и другие активы, которые могут использоваться как компоновочные блоки на всем процессе реализации и адаптации архитектуры предприятия. Метод разработки архитектуры TOGAF (ADM) предоставляет законченный набор инструкций для реализации и выполнения архитектуры предприятия в организации. Этот процесс состоит из нескольких последовательных фаз, замкнутых в цикл (Рис. 8). 25 Задача предварительной фазы (Preliminary Phase, ее на рисунке нет) - выявление заинтересованных в процессе реализации лиц и обсуждение с ними задач архитектуры предприятия. На этой фазе вырабатываются Руководящие принципы архитектуры (Architecture Guiding Principles), которые основываются на бизнес-принципах организации и описывают процессы и критерии для наблюдения за процессом реализации архитектуры предприятия. Рис. 8. Методика ADM Фаза А этого процесса предназначена для выражения видения архитектуры предприятия. Артефакт Видение архитектуры (Architecture Vision) использует движущие силы бизнеса, чтобы обозначить цель действий по созданию архитектуры предприятия и создать описания первого реза для базовой и целевой среды. Если задачи бизнеса не ясны, то часть задания этой фазы - помочь бизнесу идентифицировать свои главные задачи и соответствующие процессы, которые должна поддерживать архитектура предприятия. Документ Архитектурное задание (Statement of Architectural Work), который также создается в этой фазе, очерчивает область действия и условия архитектуры предприятия и представляет собой план архитектурного задания. 26 Фаза B предназначена для детальной разработки архитектуры предметной области бизнеса. И базовая, и целевая архитектура, которые очерчены в документе Видение архитектуры, детализируются, чтобы получить полезные входные данные для технического анализа. Моделирование бизнес-процессов, моделирование бизнес-объектов и моделирование прецедентов - вот лишь некоторые методики, которые используются для создания архитектуры бизнеса, которая, в свою очередь, включает анализ просчетов желательного состояния. Фаза С связана с созданием архитектуры предметных областей Приложение и Данные (Информация). Эта фаза использует базовую и целевую архитектуры, которые были запущены в фазе А (Архитектурное представление) и результатах анализа просчетов (компонента архитектуры бизнеса), чтобы передать архитектурам данных и приложения информацию о текущей и проектной средах, в пределах области применения и в соответствии с планом, очерченным в Документе «Архитектурное задание». Фаза D завершает работу над детализацией архитектуры цикла метода ADM созданием архитектуры технологии. Как и в предыдущих фазах, в качестве основы используется анализ просчетов и черновые варианты архитектур, так же, как и руководящие принципы архитектуры, выработанные в подготовительной фазе. В этой фазе для создания различных точек зрения активно используется нотация моделирования UML. Цель фазы Е – выяснить возможности, предлагаемые целевой архитектурой, и создать эскиз потенциального решения. Работа в этой фазе концентрируется вокруг применимости и практичности альтернатив реализации. На этой фазе создаются такие артефакты, как Стратегия реализации и миграции, Высокоуровневый план реализации и Список проектов, а также обновленная Архитектура приложения, которая выполняет функции программы, которую следует использовать в проекте реализации. В фазе F расставляются приоритеты проектов реализации и выполняется детализированное планирование и анализ просчетов процесса миграции. В это задание входит оценка зависимостей между проектами и минимизация их итогового влияния на функции предприятия. В этой фазе обновляется Список проектов, детализируется План реализации, а Программа передается коллективам, занимающимся реализацией. После утверждения спецификации проекта фокус перемещается на формулирование более конкретных условий и рекомендаций для каждого из проектов реализации. На протяжении фазы G устанавливается связь между управляющей архитектурой (TOGAF) и разрабатывающей организацией (которая может быть настроена при помощи RUP и Project Management Body of Knowledge (PMBOK), например, или каких-либо еще методологий управления проектом, а выбранные проекты реализуются под управлением формальной архитектуры. На выходе этой фазы мы имеем Архитектурные контракты, которые утверждаются организацией-разработчиком. Конечным выходом фазы G являются решения, совместимые с архитектурой. 27 В фазе H акцент переносится на управление изменением основой архитектуры, которая достигается поставкой реализованных решений. В этой фазе может быть создано Требование к архитектурному заданию, которое устанавливает цели для последующих циклов реализации архитектуры предприятия. Несмотря на большую проработанность данной методологии по сравнению с моделью Захмана, надо понимать, что подход TOGAF имеет и ряд недостатков. Метод ADM не является законченным процессом; это инфраструктура, и, по сути, для каждой конкретной организации, требуется адаптация. Адаптация предполагает глубокое знание модели бизнеса и методологии - специалиста с такими качествами не всегда легко найти. Ситуация осложняется тем, что даже не последняя версия TOGAF версия 8.0, Enterprise Edition (2006) и новая версия 9 (2009)- это сравнительно новый подход с ограниченным количеством практических наработок. Может оказаться непростой задачей уговорить заинтересованных лиц использовать именно TOGAF. Обычно для этого необходимо, чтобы какой-либо сотрудник, пользующийся уважением, уговорил руководство и других сотрудников добавить к знакомым им процессам и моделям TOGAF, или полностью заменить их на модели и процессы новой инфраструктуры. Несмотря на недавние усовершенствования и выход новой версии, инфраструктура TOGAF не так детализирована, как другие методологии, особенно в главной сфере взаимодействия бизнеса и технологии. Например, TOGAF не включает ни функций, подобных Rational Method Composer или MyRUP, ни такой комплексной библиотеки периодических изданий. Зрелые организации, особенно те, которые в повседневной работе используют управление проектами и методологию жизненного цикла программного обеспечения (PMBOK, RUP, Scrum и ITIL) обычно добиваются большего успеха в реализации архитектуры предприятия. Можно порекомендовать сотрудникам организации перед тем, как включить в свой инструментарий TOGAF, хорошо изучить несколько методик, нотаций и методологий жизненного цикла программного обеспечения из тех, что показаны на Рис. 9. Рис. 9. Применение методики TOGAF для «зрелой» организации 28 Среди прочих потенциальных угроз успешной реализации TOGAF - отсутствие стандартного инструмента для фиксации и управления артефактами архитектуры предприятия и отсутствие стандартной нотации. 2.3 МОДЕЛИ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ, ОРИЕНТИРОВАННЫЕ НА ГОСУДАРСТВЕННЫЕ ОРГАНИЗАЦИИ Рассматривая историю развития общепризнанных моделей в сфере разработки архитектуры предприятия следует отметить, что все модели являются логическим продолжением одна другой, более того образуют вполне наблюдаемую траекторию развития (Рис. 10). После выпуска первой статьи Захмана, где он описал суть своего подхода и тем самым дал развитие всей дисциплине под названием «архитектура предприятия» исторически разработки новых методов и моделей разделились на 2 основных направления: первое было сосредоточено на государственных организациях и адаптации архитектурных подходов к ним, второе на развитие концепции «архитектуры предприятия» в корпоративной среде (методики IBM, Microsoft, Giga Group, Gartner и т.д.). Причем оба направления развивались параллельно. Рис. 10. Исторические истоки моделей архитектуры предприятия 2.3.1 Схема FEAF (Federal Enterprise Architecture Framework) Адаптация архитектурных подходов в сфере государственных структур и ведомств началась в 1998 году с создания схемы FEAF (Federal Enterprise Architecture Framework, Рамочной структуры Архитектуры Федеральной организации). Ее специфика связана с ее предназначением – разработка в рамках системы задач государственного масштаба для США. Совет руководителей информационных служб (CIO Council) начал разработку FEAF в апреле 1998 года. В основу был положен Стратегический план деятельности CIO Council, разработанный с учетом приоритетов Закона по реформированию системы управления информационными технологиями в органах государственной власти принятого в 1996 году (Information Technology Management Reform Act или, иначе, закон или акт Клингера-Коэна), который определял направления разработки и использования Федеральной Архитектуры для максимизации отдачи от использования ИКТ в государстве под флагом «эффективности инвестиций денег на- 29 логоплательщиков в ИТ». Этот закон определил в качестве одной из обязанностей руководителей департаментов информационных технологий государственных ведомств разработку архитектуры информационных технологий. Важной особенностью данного проекта является функциональный подход к описанию архитектуры, т.е. подход со стороны бизнес-процессов, а не структуры федерального правительства и госорганов. В то же время следует отметить, что в рамках FEAF модели государственных функций приводятся только для задания контекста, т.е. в рамках FEAF не производится переопределения и детализации функций отдельных агентств. Эти справочные модели служат, по сути дела, определенными руководствами, которые обеспечивают общие архитектурные принципы при реализации межведомственных проектов, а также предоставляют всем государственным организациям единую методологию при разработке собственных архитектур. FEAF – это концептуальная модель описания в координированной, структурированной форме деятельности федерального правительства и государственных организаций с функциональной точки зрения, вне зависимости от организационных структур, реализующих соответствующие функции, с целью улучшения их деятельности за счет использования информационных технологий. По сути дела, это новый способ описания, анализа и улучшения деятельности государства и госорганизаций, а также расширения их возможностей по обслуживанию граждан. Федеральная Архитектура – это стратегический информационный актив, который определяет функции (бизнес) государственных организаций, информацию и технологии, необходимые для реализации функций, а также процессы преобразований, необходимые для внедрения новых информационных технологий в ответ на изменяющиеся бизнес-потребности. Отдельные государственные организации должны использовать эту общую модель для описания своих собственных архитектур. Основной целью Федеральной Архитектуры является обеспечение условий для совместной разработки процессов, стандартов совместимости и обмена информацией между государственными органами и организациями. FEAF состоит из следующих восьми компонент, которые кратко описаны ниже и представлены на Рис. 11. 30 Рис. 11. Структура модели FEAF Двигатели архитектуры (Architecture Drivers). Отражают два типа внешних стимулов или источников изменения архитектуры: бизнес-стимулы и технические стимулы (или «конструкторские»). В качестве бизнес-стимула могут выступать новое законодательство, новые инициативы Президента, бюджетные ассигнования для ускорения развития отдельных сфер, рыночные силы. В роли технических двигателей могут выступать новое и улучшенное программное обеспечение, аппаратные средства, а также их разнообразные комбинации. Двигатели архитектуры являются источниками изменений для архитектуры федерального предприятия и делятся на два типа: − бизнес-стимулы – определяются основными федеральными бизнес- потребностями. Например, реализация процесса электронных торгов требует разработки архитектуры и ряда новых законов, а также пересмотра различных правительственных действий, реализующих электронный доступ и использование электронной подписи. − технические (или системные) стимулы – отражают использование но- вых революционных путей удовлетворения федеральных бизнеспотребностей. Наиболее наглядным примером технического двигателя служит распространение Интернета. Стратегическое направление (Strategic Direction). Руководство для разработки целевой архитектуры (см. ниже), которое содержит видение, принципы, цели и объекты. 31 Стратегическое направление определяет разработку целевой архитектуры. Оно включает в себя видение, сжатое и стратегическое описание поставленной цели развития архитектуры на предстоящие 5 лет, принципы руководства развитием этой архитектуры, а также цели и объекты для управления процессом развития архитектуры. Текущая архитектура (Current Architecture). Определяет архитектуру «как есть» и состоит из двух частей: − текущая бизнес-архитектура – определяет сегодняшние потребности с точки зрения основной деятельности государственных организаций и как они обеспечиваются существующими информационными системами. Отвечает на вопрос о том, какие имеются в распоряжении функции, процессы, ресурсы. − текущая архитектура информационных технологий (т.е. архитектура данных, приложений и технологическая архитектура) – отображает текущее состояние возможностей технологий по обеспечению деятельности организаций и служит объектом для дальнейших изменений. Целевая архитектура (Target Architecture). Определяет архитектуру «как должно быть построено» и состоит также из двух частей: будущая бизнесархитектура и будущая архитектура информационных технологий (т.е., соответственно, архитектура данных, приложений, и технологическая архитектура). Она дает представление о будущих возможностях и технологиях, которые явятся результатом соответствующих изменений. Переходные процессы (Transitional Processes). Поддерживают процесс перехода от текущей архитектуры к целевой архитектуре. Критические переходные процессы для федерального предприятия включают планирование инвестиций в сферу ИТ, планирование изменений, управление конфигурациями, контроль и управление проектами. Основные примеры переходных процессов включают следующие: − планирование и принятие решения по инвестициям и ИТ – при плани- ровании должны учитываться бюджетный план, показатель возврата инвестиций, критерий «затраты-выгоды» и другие критерии; − контроль и анализ инвестиционного управления – для поддержки про- цесса контроля используется информация относительно архитектуры предприятия; − координация сегментов – координирование процесса интеграции архи- тектурных сегментов в единую Федеральную архитектуру; − исследование рынка – проведение периодического анализа рынка с це- лью идентификации новых или усовершенствованных технологий с большими потенциальными преимуществами для реализации функций и процессов или технологий, более эффективных по критерию производительность /стоимость; 32 − управление активами – управление всеми активами, которые связаны с реализацией Федеральной архитектуры; − процессы закупок – согласование процессов закупок с архитектурой и с намеченными переходными процессами; − управление архитектурой – координация усилий по сопровождению и управлению архитектурой. Архитектурные сегменты (Architectural Segments). Отражают разбиение общей архитектуры на отдельные, существенные области деятельности, например: − общие административные системы; − области федеральных программ, таких как внешняя торговля или пре- доставление грантов; − электронная торговля для проведения небольших закупок. Каждый архитектурный сегмент представляет собой часть общей Федеральной архитектуры, должен быть достаточно важным с точки зрения самостоятельного рассмотрения (например, по критерию возврата инвестиций) и должен рассматриваться в рамках этого общего контекста. Каждый сегмент также характеризуется текущей и будущей архитектурой данного конкретного сегмента. Соответствующая информация и модели помещаются в базу данных (репозиторий) единой Федеральной архитектуры. Архитектурные модели (Architectural Models). Определяют бизнес- и технологические модели, которые отражают все необходимые сегменты для полного описания архитектуры. Архитектурные модели задают бизнесархитектуру и архитектуру информационных технологий. При этом рассматриваются бизнес-модели и модели технической среды (данных, прикладных систем, технологий): − бизнес-модели. Это модели, которые отражают появление бизнес- потребностей, инициированных бизнес-двигателями. Моделирование предполагает создание общего набора определений, диаграмм, а также, возможно, использование автоматизированных инструментальных средств, которые облегчают понимание бизнес-функций, применяемой информации, процессов и продуктов; − модели технической среды (Design Models). Модели технической среды включают модели данных, модели прикладных систем и технологические модели, которые требуются для того, чтобы поддержать реализацию бизнес-потребностей. Стандарты (Standards). Включают все стандарты (некоторые из них могут быть обязательными), руководящие принципы, а также передовой опыт. Соответственно, если говорить о том, какие представления (домены) выделяются в методике Федеральной архитектуры США, то они следующие: 33 − бизнес-архитектура (функциональная архитектура деятельности прави- тельства); − архитектура информации (данных); − архитектура приложений; − архитектура инфраструктуры (технологическая или системная архитек- тура): аппаратное и системное программное обеспечение, коммуникации. В США ведется разработка и постоянное уточнение соответствующих взаимосвязанных так называемых Справочных (эталонных) моделей (Reference Models) для каждой из перечисленных областей. В схеме FEAF принято выделять 5 эталонных моделей: − справочная модель эффективности (PRM – Performance Reference Mod- el); − справочная модель описания бизнеса федеральной организации (BRM – Business Reference Model); − справочная модель сервисных компонент (SRM – Service Component Reference Model). Это описание компонент прикладных информационных систем, обеспечивающих реализацию государственных функций; − справочная модель описания данных (DRM – Data Reference Model); − технологическая справочная модель (TRM – Technology Reference Model). Область бизнес-архитектуры покрывается первыми двумя справочными моделями: Справочной моделью эффективности и Справочной моделью описания бизнеса федеральной организации. Эти справочные модели являются, по сути дела, определенными руководствами, которые: − обеспечивают общие архитектурные принципы при реализации межве- домственных проектов; − обеспечивают всем государственным организациям единую методоло- гию при разработке собственных архитектур ИТ (Корпоративных архитектур). Иерархия Справочных Моделей в рамках Федеральной архитектуры показана на Рис. 12. 34 Рис. 12. Эталонные модели в схеме FEAF Основное назначение рамочной структуры FEAF состоит в том, чтобы содействовать разработке общих федеральных процессов, а также обеспечению взаимодействия (интероперабельности) федеральных агентств и ведомств при использовании ими информации. Эта структура, по существу, является таким инструментом, который позволяет федеральному правительству выполнять широкий спектр действий: − создавать и организовывать информацию в общефедеральном масшта- бе; − содействовать совместному (разделяемому) использованию информа- ции федеральными организациями; − оказывать помощь федеральным организациям в разработке их архитек- тур предприятия; − оказывать содействие федеральным организациям в разработке их ин- вестиционных процессов в ИТ; − более качественно, быстрее и рентабельнее обслуживать потребности клиентов. 35 С другой стороны, применение данной рамочной структуры позволяет государственным ведомствам и учреждениям достигнуть таких преимуществ, как: − предоставление агентствам средств совместного использования инфо- ресурсов; − обеспечение для федеральных ведомств и агентств предпосылок для снижения затрат на ИТ; − оказание поддержки федеральным ведомствам и агентствам в их усили- ях по организации инвестиционного планирования капиталовложений в ИТ; − содействие росту интероперабельности между федеральными ведомст- вами и организациями. Основные принципы FEAF, сформулированные советом CIO, опираются на следующие технические, функциональные и организационные решения: − разработка и внедрение федеральных стандартов по обеспечению инте- роперабельности; − координация инвестиций в ИТ в общефедеральном масштабе на базе федеральной архитектуры; − минимизация усилий по сбору данных; − гарантированное предотвращение несанкционированного доступа к фе- деральной информации; − использование преимуществ стандартизации при автоматизации общих для федеральных агентств и ведомств функций; − обеспечение эффективного и равноправного доступа к информации; − применение проверенных жизнью технологий; − выполнение требований закона о секретности от 1974 г. 2.3.2 Архитектура федеральной организации (FEA) Архитектура федеральной организации (FEA) это логическое продолжение разработки FEAF и последняя попытка федерального правительства привести бесчисленное множество агентств к единой и повсеместно используемой архитектуре. FEA по-прежнему находится в самой ранней стадии развития: большинство компонентов этой методологии стали доступны только в 2006 г. Тем не менее, за этой методологией стоит длительная традиция и множество неудачных попыток, из которых были извлечены полезные уроки. FEA является наиболее полной методологией из всех упомянутых. Она включает и всеобъемлющую таксономию, как в методологии Захмана, и архитектурный процесс, как в модели TOGAF. FEA можно рассматривать и как ме- 36 тодологию создания архитектуры предприятия, и как результат применения этой процедуры к конкретной организации - Правительству США. Большинство авторов описывают FEA как набор из пяти эталонных моделей: модель бизнеса, модель обслуживания, модель компонентов, технологическая модель и модель данных. FEA действительно включает эти пять моделей, однако представляет собой нечто намного большее, чем просто набор эталонных моделей. Исчерпывающее описание методологии FEA должно включать следующие пункты: − точка зрения, с которой будут рассматриваться архитектуры предпри- ятия (модель сегмента, которая вкратце будет рассмотрена ниже); − набор эталонных моделей, описывающих различные точки зрения на архитектуру предприятия (пять перечисленных выше моделей); − процесс создания архитектуры предприятия; − процесс перехода от старой парадигмы (до создания архитектуры пред- приятия) к новой (после создания архитектуры предприятия); − таксономия для классификации активов, которые попадают в область действия архитектуры предприятия; − методика, позволяющая оценить успешность использования архитекту- ры предприятия для повышения ценности бизнеса. С точки зрения FEA, архитектура предприятия состоит из отдельных сегментов. Эта идея была впервые изложена в FEAF. Сегмент представляет собой один из основных аспектов бизнеса, например трудовые ресурсы. Сегменты подразделяются на два типа: базовые и служебные. Базовый сегмент представляет собой ключевой аспект деятельности предприятия в границах политико-административного деления. Например, для Министерства здравоохранения и социальных служб США базовым сегментом является здоровье. Служебный сегмент - это сегмент, который является фундаментальным если не для всех, то для большинства политических организаций. Например, управление финансами является служебным сегментом, обязательным для всех федеральных агентств. Другим типом активов в архитектуре предприятия являются службы предприятия. Служба предприятия – это четко определенная функция в границах политико-административного деления. В качестве примера службы предприятия можно привести управление безопасностью. Управление безопасностью – это служба, единообразно реализованная по всему предприятию. Различие между службами предприятия и сегментами, особенно служебными сегментами, неочевидно. И службы, и сегменты охватывают все предприятие. Различие заключается в том, что область действия служебных сегментов 37 распространяется только на одну политическую организацию. Область действия служб предприятия распространяется на все предприятие. Например, и в Министерстве здравоохранения и социальных служб, и в Агентстве по охране окружающей среды федерального правительства США используется служебный сегмент трудовые ресурсы. Однако трудовые ресурсы для Министерства здравоохранения и социальных служб отличаются от трудовых ресурсов для Агентства по охране окружающей среды. И в Министерстве здравоохранения и социальных служб, и в Агентстве по охране окружающей среды используется такая служба предприятия, как управление безопасностью. При этом учетные записи для безопасного доступа, используемые службой управления безопасностью, одинаковы для обоих агентств. Эффективное управление учетными записями для безопасного доступа обеспечивается только в том случае, если оно осуществляется на уровне предприятия. Возникает соблазн приравнять сегменты или службы к службам, используемым в сервис-ориентированных архитектурах. Такой подход небезупречен по двум причинам. Во-первых, службы предприятия, служебные и базовые сегменты намного шире по охвату, чем службы в сервис-ориентированных архитектурах. Во-вторых, сегменты являются организационной единицей для архитектуры предприятия, а службы - организационной единицей для технической реализации. Что касается организационных единиц для архитектуры предприятия, они охватывают не только технологическую архитектуру, но и архитектуры бизнеса и данных. Хотя сегменты функционируют на политическом уровне (то есть на уровне агентств), они определяются на уровне предприятия (то есть на уровне правительства). Службы предприятия, естественно, функционируют и определяются на уровне предприятия. Тот факт, что сегменты определяются глобально, упрощает их повторное использование в границах политико-административного деления. Можно спланировать использование сегментов в границах политико-административного деления предприятия, а затем воспользоваться этим планом для поиска возможностей повторного использования разработанной архитектуры. Например, на Рис. 13 приведена схема сегментов федерального правительства из «Практического руководства по FEA». 38 Рис. 13. Службы и сегменты в соответствии с моделью FEA Из рисунка видно, что многие сегменты (вертикальные столбцы) используются во многих агентствах и все или почти все эти сегменты можно использовать повторно. Сама модель FEA предлагает не только сама структуру организации, но и определенный процесс или методику формирования данной модели. Процесс FEA в основном направлен на создание архитектуры сегмента для подмножества общей архитектуры предприятия (в случае с FEA предприятием является федеральное правительство, а подмножеством - правительственное агентство). Описание процесса приведено в «Практическом руководстве по FEA». Сегменты предприятия в рамках методологии FEA были рассмотрены выше. Общий процесс разработки архитектуры сегмента (на самом верхнем уровне) выглядит следующим образом: − этап 1. Анализ архитектуры: формирование простого и лаконичного представления сегмента с привязкой к плану организации; − этап 2. Архитектурное определение: задание желаемого состояния сег- мента, документация целевых показателей производительности, рассмотрение альтернатив и разработка архитектуры предприятия для сегмента, в том числе архитектуры бизнеса, архитектуры данных, архитектуры служб и технологической архитектуры; − этап 3. Стратегия инвестиций и финансирования: рассмотрение спосо- бов финансирования проекта; − этап 4. План управления программой и реализация проектов: создание плана управления проектом и его реализации, включающего контроль- 39 ные точки и показатели производительности для оценки успешности проекта. Уровень готовности федеральных агентств оценивается по трем категориям: − завершенность архитектуры – уровень готовности собственно архитек- туры; − использование архитектуры – эффективность использования агентством архитектуры при принятии решений; − результаты использования архитектуры – преимущества, достигнутые благодаря использованию архитектуры. Административно-бюджетное управление присваивает каждому агентству рейтинг успеха на основе оценок по каждой категории и совокупному показателю следующим образом: − зеленый – агентство показало хорошие результаты в области завершен- ности (имеет развитую архитектуру предприятия). Агентство также добилось хороших показателей в области использования (эффективно использует архитектуру предприятия для реализации текущей стратегии) и в области результатов (использование архитектуры способствовало увеличению ценности бизнеса); − желтый – агентство показало хорошие результаты в области завершен- ности. Оно также добилось хороших показателей либо в области использования, либо в области результатов; − красный – агентство либо не завершило разработку архитектуры, либо неэффективно использует разработанную архитектуру. Надо отметить, что в отличии от модели Захмана, FEA подразумевает наличие двух состояний: текущего («как есть») и перспективного, или целевого («как должно быть»), состояния. Одна из главных задач FEA состоит в том, чтобы оптимизировать существующее положение дел и создать для него такие ИТ-инфраструктуру и приложения, которые поддерживали бы текущую и перспективную деятельность предприятия. Американский опыт работы федеральных правительственных агентств показал, что попытки определить и построить основные ИТ-системы без ориентации на концепцию FEA, как правило, приводят к дублированию усилий, ресурсов и инвестиций и, что самое главное, сопровождаются трудностями взаимодействия и интеграции различных систем. В случае с FEA, особенно на начальных этапах, какие-либо стандарты или методы, позволяющие проводить оценки текущего состояния и степени продвижения разработки вперед, отсутствовали. Поэтому в феврале 2001 г. была выпущена первая версия документа «Руководство по управлению разработкой архитектуры предприятия» (A Practical Guide to Federal Enterprise Architecture. Chief Information Officer Council. Version 1.0, February 2001), которая и послу- 40 жила таким стандартом. Данное руководство основано на базовых элементах (установленных в упоминавшемся выше руководстве CIO по созданию рамочной структуры FEAF), которые упорядочены по пяти иерархическим стадиям развития (или зрелости) FEA в соответствии с подразумеваемыми или имеющимися зависимостями между этими элементами. Были классифицированы группы атрибутов, необходимые для определения эффективности различных функций управления FEA. Затем все введенные базовые элементы были распределены по группам атрибутов, а среди них выделены четыре следующие группы: − атрибуты, участвующие в демонстрации организационных обяза- тельств, такие, как политика и утверждение решений; − атрибуты, обеспечивающие возможность выполнения обязательств, на- пример распределение организационных обязанностей и ответственности; − атрибуты, которые демонстрируют выполнение обязательств, вклю- чающие планы создания и реальные FEA; − атрибуты, проверяющие выполнение принятых обязательств, в частно- сти использование средств для измерения степени продвижения FEA. Эта классификация (а фактически стандарт) получила название «Пять стадий зрелости архитектуры предприятия» и рекомендована всем федеральным правительственным учреждениям. Она была полностью согласована с другими документами по FEA, в частности с разработанным центральным финансовым управлением (GAO) «Руководством по поддержке и улучшению процесса управления инвестициями в информационные технологии». Поскольку классификация занимает ключевое положение в вопросах оценки развития FEA и особенно в области управления инвестициями в ИТ, поддерживающими FEA, представляется целесообразным ознакомить читателей с обобщенным содержанием каждой из пяти устанавливаемых в этом стандарте стадий зрелости архитектуры. Стадия 1: знакомство с концепцией FEA. Эта стадия характеризуется либо отсутствием конкретных планов по разработке и использованию FEA, либо такие планы не выходят за рамки текущего состояния осведомленности о преимуществах, которые дает применение этой архитектуры. Фактически на первой стадии правительственные агентства проводят только подготовительную работу, которая никак не структурирована и не обеспечивает управления, необходимого для успешного создания FEA. Стадия 2: формирование основы управления разработкой FEA. Эта стадия сосредотачивается на определении ролей, обязанностей и ответственности, а также на утверждении планов выхода компонентов и продуктов FEA. В частности, на второй стадии агентство назначает главного архитектора, открывает офис, ответственный за FEA, и набирает его персонал. Кроме того, формируется управляющий комитет или группа, в задачу которых входит выбор на- 41 правлений проектирования и последующее наблюдение за ним. В состав комитета необходимо включить представителей бизнеса и специалистов по ИТ. На второй стадии агентство уже должно иметь соответствующие планы и даже может начать создание некоторых наиболее ключевых и необходимых элементов FEA. На этой стадии от агентств требуется выбрать концепцию, которая затем станет основой структуры и содержания всех элементов FEA, определенных планом. Наряду с концепцией агентство на этой стадии выбирает автоматизированные инструментальные средства, поддерживающие жизненный цикл FEA. Стадия 3: разработка элементов FEA. Данная стадия посвящена созданию конкретных изделий, которые необходимы для формирования полной FEA. Для этого агентство устанавливает сферу влияния FEA в масштабах всех объектов конкретного учреждения, а также формирует и утверждает политику, определяющую институциональные аспекты выполнения принятых данным агентством обязательств. Хотя на этой стадии элементы архитектуры могут быть еще не полностью оформлены, тем не менее они уже должны использоваться для описания производственной деятельности своего агентства в терминах рода деятельности, структуры и потоков данных, приложений и технологий, поддерживающих создаваемую FEA. Кроме того, предлагаемые элементы FEA должны: − обеспечивать возможности описания текущего (среды «как есть») и бу- дущего (среды «как должно быть») состояния, а также планы перехода от среды текущего к среде будущего состояния; − отвечать требованиям, предъявляемым к ним со стороны процессов конфигурационного управления. Стадии 4: завершение разработки элементов FEA. На этой стадии все элементы FEA получают законченный вид и проходят процесс одобрения на уровне CIO, а затем высшего руководства агентства. От госучреждений требуется использование рекомендуемых элементов для формирования своего портфеля инвестиций в ИТ и управления им. Все элементы должны содержать полное описание деятельности агентства в терминах бизнеса, структуры и потоков данных, применяемых приложений и технологий, а также описывать текущее и будущее состояние архитектуры и деятельности агентства и соответствующие планы перехода от текущего состояния к будущему. Кроме того, на этой стадии руководитель информационной службы агентства окончательно одобряет предлагаемую FEA и, исходя из принятой архитектуры, формирует и утверждает политику выделения инвестиций в ИТ для реализации FEA. Стадия 5: использование FEA для управления изменениями. На этой стадии управляющий комитет, наблюдательный совет по инвестициям или глава агентства одобряет FEA. Правительственное агентство начинает использовать разработанную и утвержденную FEA в своей корпоративной деятельности, а также применяет различные методики измерения эффективности FEA. 42 Преимущества использования FEA для государственных органов с точки зрения правительства государства: 1) Приобретение общефедерального видения. Предоставляя стандартным образом организованную федеральную информацию и содействуя совместному (или разделяемому) ее использованию, FEA будет максимизировать выгоды от применения ИТ федеральными предприятиями. Приобретение общефедерального видения всеми федеральными ведомствами и агентствами гарантируется следующим: − выравнивание миссии (т. е. процесс согласования целей и задач конкретного ведомства с общефедеральными) – FEA является компонентом стратегического планирования, который полностью гарантирует выравнивание ведомственного видения со стратегическим федеральным видением; − межведомственные бизнес-потребности – FEA содействует орга- низации совместного использования информации федеральными предприятиями, организациями и другими объектами (т. е. штатами, местными органами власти, международными организациями, клиентами, акционерами и т. д.); − инициативы по модернизации – FEA устанавливает требования к организации общефедеральной деятельности и специфицирует процессы, необходимые для удовлетворения этих требований и утверждения федеральных инициатив по модернизации методов и средств обмена информацией; − сбор данных и их качество – FEA устанавливает согласованные методы сбора данных, способные повышать качество информации и уменьшать бремя ее сбора и одновременно улучшать показатели рентабельности и результативности деятельности предприятия или агентства; − общественный доступ – FEA устанавливает согласованные мето- ды организации и классификации информации, связанной с общефедеральной архитектурой, которые позволяют представлять федеральную информацию через Интернет. 2) Улучшение качества инвестиционных решений и управления инвестициями. FEA оказывает серьезную помощь правительственным агентствам и иным государственным учреждениям в разработке ими собственных процессов инвестирования в ИТ на основе имеющихся единых федеральных решений. − Планирование инвестиций капитала в ИТ – FEA позволяет по ме- ре необходимости определять целевые направления для будущих ИТ-закупок. Такая информация поможет принятию решений об инвестиции капиталов на федеральном уровне. 43 − Ускорение реакции на изменение бизнес-требований - FEA будет отражать всю информацию (или проекты), относящуюся к среде, в которой используются ИТ. На основе этой информации можно ускорить принятие решений на федеральном уровне, сократить время, необходимое для сбора данных, облегчить интеграцию решений для последующей разработки конкретных техникоэкономических обоснований. − Базы знаний - описания FEA являются доступной базой знаний по решениям в области ИТ, которую можно использовать как ресурс для быстрого и обоснованного принятия решений по инвестированию в ИТ. 3) Создание условий для сокращения затрат ведомств. Сокращение затрат отдельных ведомств достигается использованием помощи федеральных организаций в разработке архитектуры ведомства и в сокращении потребности в перепроектировании общих бизнес-решений. − Экономия на масштабах работ - FEA идентифицирует общие фе- деральные действия организаций, выдвигая на первый план потенциальные области, обеспечивающие благодаря налаживанию сотрудничества экономию за счет повторного использования моделей и диаграмм. − Разделение ресурсов - FEA выдвигает на первый план потенци- альные области, в которых возможно совместное использование федеральных кадровых ресурсов по ИТ и технической поддержке, включая услуги по контрактам и решения по закупкам. − Рыночные исследования - усилия по созданию FEA требуют по- стоянного мониторинга появляющихся технологий для их возможно более широкого использования в деятельности предприятия и анализа последствий их применения. Такие исследования могут проводиться совместно разными федеральными агентствами в пределах общих направлений бизнеса, освобождая каждое из них от дополнительных затрат на самостоятельный сбор и оценку этой информации. Отмечая, что разработка стандарта FEA является одним из ярких примеров последовательных и эффективных проектов по разработке архитектуры предприятия, надо обратить особое внимание, что все вышеперечисленные стандарты ориентированы главным образом на государственные учреждения, которые несомненно обладают рядом особенностей, важнейшим из которых является жесткая регламентация их деятельности. Данным свойством не могут похвастаться большинство существующих организаций, поэтому на пути разработки архитектуры предприятия встают дополнительные барьеры. В связи с этим рассмотрим наиболее общие модели, которые могут применяться любой организацией для разработки архитектуры предприятия. 44 2.4 МОДЕЛИ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ, РАЗРАБОТАННЫЕ В КОРПОРАТИВНОЙ СРЕДЕ 2.4.1 Взгляды компании Microsoft Крупные компании-поставщики инфраструктурных информационных технологий, такие как Microsoft, IBM, SAP и другие могут «позволить себе роскошь» создания собственных методик разработки архитектуры информационных систем предприятия – конечно, с учетом своей области специализации. В то же время – это в какой-то степени и обязанность таких компаний, поскольку спектр предлагаемых ими технологий покрывает существенную часть архитектуры предприятия в целом, и специалистам нужны соответствующие практические рекомендации непосредственно от поставщиков. Взгляды компании Microsoft на архитектуру информационных систем сфокусированы на процессах разработки конкретных программных прикладных систем и создании технологической инфраструктуры, включая центры обработки данных различного масштаба и уровня надежности. Как практически и во всех других методиках, здесь выделяются четыре представления (домена) в архитектуре: бизнес-архитектура, архитектура информации, прикладные системы и технологическая архитектура. Эти представления рассматриваются на различных уровнях абстракции: концептуальном, логическом и физическом. Помимо этого, явно выделяются процессы разработки прикладных систем, организация процессов эксплуатации технологической инфраструктуры и создание соответствующих шаблонов, которые могут использоваться как при разработке архитектуры систем, так и при ее создании. При этом компания Microsoft выработала достаточно подробные методики, покрывающие различные аспекты архитектуры и, прежде всего, процессы разработки систем и создания инфраструктуры и процессы эксплуатации систем и инфраструктуры. В частности, это такие методики, как Microsoft Solutions Framework (MSF), Microsoft Operations Framework (MOF), Microsoft Systems Architecture (MSA) и Microsoft Solutions for Management (МSM), которые будут рассмотрены ниже. Эти четыре взаимодополняющие методики Microsoft дают специалистам рекомендации, касающиеся следующих четырех основных вопросов: − MSF - «Как правильно создавать ИТ-системы?» − MSA - «Как правильно создавать технологическую инфраструктуру?» − MOF - «Как правильно эксплуатировать технологическую инфраструк- туру?» − MSM - «Как правильно строить процессы управления технологической инфраструктурой?» Методики Microsoft сосредоточены, в основном, на системном уровне уровне архитектуры прикладных систем и обеспечивающей инфраструктуры (это не методики описания архитектуры предприятия как таковые). Поэтому в 45 этой более «узкой» области полезными являются приведенные соотношения между различными перспективами описания системы и моделями, используемыми для описания на соответствующем уровне абстракции так, как показано на Рис. 14 [(А. Данилин, 2005)]. Рис. 14. Соотношение между уровня абстракции и различными моделями То есть в идеале для каждой перспективы используется какой-то один тип моделей так, как это показано на рисунке. Но в реальности могут использоваться и несколько различных моделей для описания каждой из перспектив, т.е. концептуальной, логической и физической архитектур системы. Microsoft выделяет два типа руководств и обеспечивающих методик, которые могут помочь системным архитекторам ускорить процессы разработки моделей при минимизации рисков. Первый тип руководств - это архитектурные концепции, такие, например, как сервис-ориентированные подходы к проектированию архитектуры. Эти концепции обеспечивают следующее: − общее понимание и язык описания архитектуры; − общие руководства, рекомендации по использованию специфических концепций; − указания на то, как эти концепции могут быть реализованы на практике в форме конкретных технологий и стандартов. Второй набор руководств, которыми могут пользоваться системные архитекторы - это архитектурные шаблоны, которые основаны на практическом опыте большого количества успешно реализованных проектов создания распределенных прикладных систем; они явились следствием использования описанных выше архитектурных концепций. Эти шаблоны содержат в себе лучшие 46 практики проектирования распределенных приложений и средства по минимизации рисков неудач проектов, поскольку рекомендуют хорошо апробированные модели. Эти два типа руководств - архитектурные концепции и шаблоны - могут присутствовать и использоваться на различных уровнях проектирования архитектуры прикладной системы; − на уровне концептуальной архитектуры в форме концепций построения бизнес-моделей и соответствующих шаблонов; − на уровне логической архитектуры в форме концепций построения мо- делей приложений и соответствующих шаблонов; − на уровне физической архитектуры в форме концепций построения тех- нологических моделей и соответствующих шаблонов. Рис. 15 показывает взаимосвязи между различными перспективами в описании архитектуры, используемыми шаблонами проектирования, а также примерно отображает соответствие между методиками Microsoft и соответствующими элементами архитектуры. Знание и использование этих концепций и шаблонов является важным условием успешного, быстрого и эффективного с точки зрения затрат создания систем и использования информационных технологий организациями. Поэтому помимо самих методик MSF, MOF, MSA и MSM компанией опубликованы подробные руководства по разработке архитектуры систем [(Microsoft Application Architecture Guide, 2nd Edition, 2009)], а также шаблоны, которые могут применяться при проектировании корпоративных информационных систем [(Enterprise Solution Patterns Using Microsoft .NET, 2003)]. Корпорация Microsoft при построении любых информационных систем (не только с использованием архитектур, платформ и продуктов Microsoft) рекомендует применять методику разработки приложений, получившую название Microsoft Solutions Fromework (MSF). Одно из важных достоинств методологии MSF, которая во многом опирается на представления о современной программной архитектуре, состоит в том, что в результате следования дисциплине, принципам и методам, заложенным в ее основу, решения получаются комплексными, интеграционными, работоспособными, с ясно определенными приоритетами. 47 Рис. 15. Архитектурные шаблоны и методики компании Microsoft В таком контексте MSF как методика разработки архитектуры предприятия – это инструмент, который гарантирует, что деятельность подразделений информационных технологий будет ориентирована именно на бизнеспотребности. Компоненты, составляющие основу методики MSF, могут применяться по отдельности или в совокупности для увеличения вероятности успеха в следующих областях: − разработка прикладных программных систем, включая webприложения, системы электронной коммерции, мобильные приложения, n-уровневые системы; − проекты создания ИТ-инфраструктуры, включая развертывание на- стольных систем, обновления операционных систем, развертывание корпоративных систем обмена сообщениями и электронной почты, системы управления инфраструктурой и конфигурациями; − проекты интеграции готовых решений, таких как системы управления ресурсами предприятия (ERP), системы офисной автоматизации, системы управления проектами; 48 − любая сложная комбинация перечисленных выше типов проектов. Если кратко, то MSF содержит руководства по планированию, разработке, тестированию и внедрению решений. Модель архитектуры предприятия в рамках MSF характеризуется четырьмя задачами: − интеграция: сбалансированность внутрикорпоративных интересов, тес- ное взаимодействие бизнес-подразделений и ИТ-службы; − итерационность: архитектура создается посредством последовательного выпуска версий решений; − макетируемость: одна из целей разработки архитектуры – быстро соз- дать промежуточный, но вполне работоспособный макет; − учет приоритетов: разработка архитектуры всегда учитывает необходи- мость обеспечения поддержки основных бизнес-процессов. Компонентами MSF являются: − Базовые принципы. Они служат основой MSF и выражают основные ценности и стандарты, применимые ко всем элементам методики. − Модели MSF. Это в какой-то степени карты организации проектных групп и процессов работы. Две модели являются основными в методике MSF: Модель команд и Модель процессов. − Дисциплины MS . Это предметные области, которые используют спе- цифический набор методов, терминов и подходов. В настоящий момент MSF включает в себя три дисциплины: управление рисками (risk management), управление подготовкой (readiness management) и управление проектами (project management). − Проверенные практические методики (практики) MSF. Они являются плодотворными не только в сфере информационных технологий, но также и в широком спектре других отраслей. Зачастую эти методики применимы к использованию и сопровождению ИТ-систем и иных бизнес-процессов в той же степени, что и к разработке ИТ-проектов. Примерами таких практик являются анализ результатов после контрольной точки, определение и контроль факторов риска и т.д. − Рекомендации MSF. Это не обязательные, но рекомендуемые практики и руководства, связанные с применением моделей и дисциплин MSF. Разработка информационных систем с помощью MSF ведется в соответствии с концепцией «приоритета архитектуры», впервые предложенной в книге Уолкера Ройса «Управление программными проектами: унифицированный метод» («Software Project Management: A Unified Framework» // Addison-Wesley, 1998). Она означает, что все три составляющие ИТ-проектов – планирование, создание и сопровождение системы – базируются на четко определенной высокоуровневой, что эта архитектура сформирована до того, как начата разработка, и, наконец, что именно эта архитектура и определяет направление работы. 49 Прежде чем применять подобный подход к конкретным приложениям, необходимо полностью определить архитектуру на уровне предприятия. Методика Microsoft Systems Architecture (MSA) относится к той части архитектуры предприятия, которая называется Технологической архитектурой. Задачей методики является стандартизация подходов к строительству центров обработки данных (Data Centers), которые лежат в основе любой корпоративной информационной системы. Методика MSA призвана помочь ИТподразделениям предприятий создать такие решения, которые отвечали бы шести основным требованиям: безопасности, надежности, доступности, быстродействию, управляемости и простоте технической поддержки. Залогом эффективности применения MSA на практике служит то, что все входящие в состав этого решения рекомендации появились на свет в результате тщательного тестирования описываемых конфигураций программного и аппаратного обеспечения в лабораторных условиях, моделировавших самые непростые ситуации из числа возможных в повседневной практике эксплуатации информационных систем. Разумеется, масштабы вновь создаваемых центров обработки данных зависят, в первую очередь, от спектра возлагаемых на них задач. Если внутри структурных подразделений предприятия их роль сводится к обеспечению совместной работы ограниченного числа пользователей, то система электронной коммерции, использующая глобальную сеть для связи с многочисленными клиентами и партнерами, будет строиться на более серьезной базе. Соответственно те рекомендации, которые помогут сотрудникам ИТ-службы разработать проект системы и воплотить ее в жизнь в первом случае, окажутся малопригодными во втором. По этой причине MSA подразделяется на несколько направлений, каждое из которых включает в себя сценарии, отвечающие масштабу создаваемого решения и стоящим перед ним задачам. MSA описывает следующие конфигурации инфраструктуры: − Вычислительный центр уровня подразделения (DDC – Departmental Data Center). − Вычислительный центр уровня предприятия (EDC – Enterprise Data Center). − Вычислительный центр Интернет-систем (IDC – Internet Data Center). − Вычислительный центр для высокомасштабируемых сервисов (HSSDS – Highly Scalable Services Data Center). MSA детально описывает логическую и физическую технологические архитектуры, включает все необходимые технологии: сети, серверы, системы хранения и программное обеспечение. Использование этих протестированных методик существенно снижает трудозатраты по проектированию, построению, тестированию и эксплуатации технологической инфраструктуры. 50 MSA предоставляет следующие документы для специалистов, решивших воспользоваться этой методикой: − Справочные (эталонные или референсные) описания архитектуры. − Предписывающие руководства: руководство по архитектуре, руково- дство по тестированию, руководство по созданию, руководство по эксплуатации. Все они содержат протестированные в лабораторных условиях фрагменты технологической архитектуры. − Руководство по службам. − Руководство по поддержке Делая вывод по архитектурным методикам, разработанным компанией Microsoft, следует отметить, что они не предполагают создание единой модели всего предприятия, то есть не предлагают готового решения для создания архитектуры предприятия как таковой, но тем не менее они представляют особый интерес, поскольку имеют четкую практическую обоснованность и направленность. 2.4.2 Взгляды компании IBM В процессе исследования и накопления практического опыта специалисты компании IBM сделали немало интересных открытий. Прежде всего в исследовании Технологической академии IBM архитектура EA определяется следующим образом: «Дисциплина EA определяет и обслуживает архитектурные модели, механизм управление и инициативы по переходу (от текущего состояния к целевому), необходимые для эффективной координации частично автономных групп для решения бизнес- и/или ИТ-задач». Это определение было разработано специально для того, чтобы подчеркнуть, что EA – это не просто архитектура, а именно дисциплина. Кроме того, его цель - отразить потребность EA в связывании бизнес-стратегии предприятия с его программой изменений через определение следующих моментов: − архитектурных моделей, предназначенных для документирования спе- циальной структуры бизнеса (через архитектуру бизнеса) и предоставления четкой спецификации способов использования информационной технологии несколькими проектами и программами (через общие и явно обозначенные архитектуры информационных систем (ИС) и информационных технологий (ИТ); − механизмов, таких как управление архитектурой и планирование пере- хода, которые будут способствовать лучшему планированию, координации и управлению всеми компонентами бизнеса, обеспечивая их движение в одном направлении. Архитектура предприятия развивается циклично. При разработке стратегии развития предприятия выявляются изменения в бизнес-архитектуре пред- 51 приятия, позволяющие оптимизировать его бизнес-процессы, а изменение бизнес-процессов предприятия влечет изменение ИТ-архитектуры. Следующие шаги - разработка плана миграции и переход из текущего состояния в планируемое. Процесс миграции является лишь очередным шагом на пути преобразования предприятия, и его окончание означает переход предприятия на новый виток развития, вновь начинающийся с разработки стратегии. На Рис. 16 изображена инфраструктура, разработанная в ходе исследования Технологической Академии IBM в области EA; она использует все концепции объединения бизнес-стратегии предприятия с его программой изменений, т.е. демонстрирует позиционирование EA как связующего звена между стратегией предприятия (в области бизнеса и информационных технологий), рабочей средой бизнеса и инфраструктурой ИТ. 52 Рис. 16. Инфраструктура EA, разработанная компанией IBM Однако по мнение экспертов IBM архитектура - это всего лишь один из компонентов понятия EA. Если говорить более конкретно, EA состоит из архитектуры, механизма управления и плана-графика. Принципиальным вопросом также является не столько трактовка самого понятия, как разработанная в рамках каждого подхода структура или состав EA. На Рис. 17 показаны эти компо- 53 новочные блоки EA и их влияние на проекты, разрабатываемые для достижения бизнес-целей. Рис. 17. Структура понятия архитектура предприятия (модель IBM) Представленная на Рис. 17 концепция может помочь предприятиям в разработке самой EA, отвечая на вопросы, приведенные на нем разрабатываются блоки архитектуры предприятия (или предметные области): − бизнес-архитектура; − архитектура приложений; − архитектура информации; − архитектура технологии. Механизм руководства (управления архитектурой) представляет собой структуру организации и процессы, которые необходимо внедрить для формирования соответствующих нормам процедур одобрения, коммуникаций, а также достижения жизнеспособности архитектуры. 2.4.3 Взгляды компании Gartner Несмотря на существование разработок крупных компаний, которые сами не только предлагают некоторые концепции «архитектуры предприятия», но и собственно сами задают тон в некоторых ее доменах, корпоративная среда предлагает больше архитектурных подходов. Крупные аналитические агентства, которые специализируются на сфере ИТ, также предложили свои модели. Например, Gartner - исследовательская и консалтинговая компания, специализирующаяся на рынках информационных технологий. Ее подход стоит несколько особняком, поскольку представляет собой прежде всего набор практических рекомендаций. 54 Компания Gartner уверена, что архитектура предприятия призвана объединить три группы профессионалов: владельцев бизнеса, ИТ-специалистов и специалистов по внедрению технологий. Если это объединение удается и возможно сформировать у них единое представление о факторах, влияющих на ценность бизнеса, то проект точно будет успешным, в противном случае - нет. Успех оценивается чисто прагматически, например по доходности бизнеса, а не по количеству отмеченных элементов в матрице процесса. Компания Gartner считает, что архитектура предприятия должна начинаться с того, что организация собирается достичь, а не с текущего положения дел. Если цель известна, можно сопоставить текущее положение дел с этой целью. Компания Gartner рекомендует начать работу с написания рассказа о стратегическом направлении развития организации и бизнес-факторах, на которые необходимо реагировать. Рассказ должен быть написан простым языком (соблюдать стандарты документации необязательно), без использования аббревиатур, специальной терминологии и технических рассуждений. Рассказ должен быть всем понятен и направлен на формирование у всех единого представления. Большинство организаций сталкиваются с необходимостью внесения в бизнес-процессы существенных изменений. Процесс формирования представления об архитектуре предприятия дает сотрудникам организации шанс собраться вместе, отвлечься от повседневной текучки и убедиться в том, что все понимают природу, область действия и последствия ожидаемых изменений. После того как в организации будет сформировано единое представление о будущем, можно будет рассмотреть влияние этого представления на архитектуру бизнеса, технологическую архитектуру, информационную архитектуру и архитектуру решений. Общее представление о будущем определяет изменения, которые необходимо внести во все перечисленные выше архитектуры, приоритеты этих изменений и привязку этих изменений к ценности бизнеса. Архитектура предприятия, согласно представлению Gartner, связана со стратегией, а не с технической реализацией. Она направлена на достижение цели. Два самых важных вопроса, которыми задается компания Gartner, - это куда организация стремится и как она туда попадет. Любое действие, не связанное напрямую с этими вопросами, считается неуместным. Аналитики Gartner любят употреблять следующую фразу: «Ровно столько архитектуры, сколько необходимо, и точно в срок». Аналитики Gartner выделили четыре группы процессов, которые выполняются различными командами специалистов. Тактическая архитектура (Tactical Architecture) - включает в себя архитектуру локальных проектов, выполняющихся в соответствии с конкретным планом развития информационных систем и бизнес-процессов. Специалисты, занимающиеся такими проектами, как правило, являются профессионалами в 55 конкретных областях, они занимаются главным образом решением текущих задач и часто не могут оценить их влияние на предприятие в целом. Тактическая архитектура предприятия (Enterprise Tactical Architecture) координирует все проекты предприятия, обеспечивает интеграцию различных приложений в единое целое. Аналитики, работающие в такой команде, имеют широкое представление о существующих проблемах, могут влиять на выбор того или иного решения. При этом разработка архитектуры происходит только с точки зрения технологий и не затрагивает бизнес. Стратегическая архитектура (Strategic Architecture) - обеспечивает планирование проектов в масштабах всего предприятия и соответствие между стратегией развития предприятия и изменениями в его архитектуре. При этом работы по стратегическому планированию, как правило, затрагивают исключительно высокоуровневые задачи. Зрелая архитектура предприятия (Mature Enterprise Architecture) - должна объединять всю основную активность, направленную на разработку архитектуры предприятия, в единое целое, планируя и определяя будущую архитектуру предприятия. Архитектурная команда становится неотъемлемой частью бизнеса, планирует управление финансовой деятельностью и действия по управлению портфелем приложений, консультирует другие рабочие группы по вопросам дальнейшего технологического развития и бизнес-стратегии. Основным недостатком существующих абстрактных архитектурных методик является в первую очередь отсутствие связей с реально функционирующей организацией. Необходимо обеспечить контроль за принятием правильных технических решений и оценивать, насколько эти решения соответствуют стратегии развития информационных систем, технологическим стандартам, существующим в компании, современным тенденциям в отрасли. Необходим архитектурный процесс, который неразрывно связан с существующим и функционирующим ИТ-подразделением. По мнению Gartner, многие усилия по управлению архитектурой окончились провалом, потому что были они сфокусированы на техническиориентированные модели, вместо того, чтобы концентрироваться на разработке стратегических направлений развития, которые могут использоваться для анализа архитектуры и принятия инвестиционных решений. Успешные примеры обусловлены повторяемым процессом управления и согласования изменений. Управление архитектурой невозможно без теснейшей увязки со стратегическим планированием и портфельным управлением. 3 ЛЕКЦИЯ: ПРОЦЕСС РАЗРАБОТКИ АРХИТЕКТУР: ЦЕЛИ И ЗАДАЧИ, ОБЩАЯ СХЕМА 3.1 ЦЕЛИ И ЗАДАЧИ Не надо питать иллюзий насчет того, что работа архитектора заканчивается строительством видения великолепной архитектуры предприятия. Архитек- 56 тура информационных технологий – это только на 10% видение, а на 90% – кропотливая работа по реализации. Реализация архитектуры предприятия не является проектом в строгом смысле этого слова. Дело в том, что за фазой разработки неизбежно должна последовать деятельность по поддержанию и постоянному развитию архитектуры предприятия. Проект работы над созданием архитектуры обычно включает решение следующих задач: 1) Определение и обоснование цели – ответы на вопросы Почему? и Что? 2) Выполнение ряда шагов, связанных с инициацией процесса разработки архитектуры (см. ниже). 3) Определение существующего состояния архитектуры («as is») для каждой выбранной области (домена) – отправная точка ответа на вопрос Где? 4) Определение целевой архитектуры – конечная точка ответа на вопрос Где? 5) Анализ расхождений между текущим и желаемым состоянием. 6) Разработка плана перехода – ответы на вопросы Когда? и Как? 7) Подтверждение (проверка) достижимости – можно ли на самом деле достичь конечного состояния из данного начального состояния с учетом существующих ограничений? 8) Выполнение намеченного плана. Начальные действия по инициации самого проекта разработки архитектуры включают следующие шаги: − определение «устава» (основных правил) и границ проекта; − бизнес-обоснование реализации проекта разработки архитектуры предприятия; − получение поддержки высшего руководства; − определение состава рабочей группы (организационная структура и участники); − проведение рабочей встречи, посвященной началу проекта разработки архитектуры и определения других высокоуровневых документов, которые необходимы для более детальных работ по разработке архитектуры; − создание рабочих групп, которые будут разрабатывать различные фокусные области или домены в рамках общего проекта (например, бизнес-архитектура, архитектура информации, прикладных систем, инфраструктуры). 57 Общая блок-схема процесса в итоге выглядит, как показано на Рис. 18. Рис. 18. Основные элементы архитектурного процесса В принципе, существуют три возможных подхода к организации процесса разработки архитектуры: − Традиционный обычный подход. Он требует существенных начальных затрат времени и ресурсов для достижения первых ощутимых результатов. В этом подходе в первую очередь разрабатывается регламент для будущего описания архитектуры. Затем должно быть определено текущее базовое состояние архитектуры и только после этого представлена целевая архитектура. Лишь когда все эти действия закончены, начинается детальное проектирование и разработка необходимой архитектуры предприятия. − Сегментный подход. Суть этого подхода состоит в постепенной поступательной разработке сегментов архитектуры в рамках общей структуры, описывающей принципы архитектуры ИТ. Этот подход сосредоточивается на главных бизнес-сферах и областях архитектуры и имеет больше шансов на успех, поскольку усилия ограничены пределами об- 58 щих выполняемых функций, а также сфер специфической деятельности предприятия. − Подход статус-кво или «оставить все как есть». Но, как мы уже говорили, результатом этого будут провалы в попытках наладить информационный обмен, невозможность реакции на быстроменяющееся окружение. Этот подход также означает постоянную переделку бизнесфункций, снижение производительности, потерянные или упущенные возможности. Традиционный, обычный подход при всей кажущейся его правильности связан с риском «паралича анализа», который особенно неконструктивен в российских условиях переходной экономики и процессов реформирования государства. Чтобы сократить возможные риски неудач, обеспечить снижение начальных затрат и добиться быстрой отдачи от проекта разработки архитектуры ИТ, рекомендуется второй, т.е. сегментный подход. 3.2 ОБЩАЯ СХЕМА АРХИТЕКТУРНОГО ПРОЦЕССА 3.2.1 Модель процесса разработки и использования архитектуры Общими для всех методик описания архитектуры является систематическое и рекурсивное применение таких принципов, как: − декомпозиция на различные представления архитектуры (предметные области): область прикладных систем, технологическая архитектура и т.д.; − различные уровни детализации и абстракции для описания каждой из этих областей. Схема процесса разработки в самом общем виде представлена на Рис. 19 59 Рис. 19. Схема процесса разработки архитектуры и стратегии ИТ Эта схема состоит из следующих шагов: − Общим фоном для этого процесса является мониторинг существующих тенденций в области деятельности организации и тенденций в области развития информационных технологий. − Анализ на бизнес-уровне. На первом этапе проводится анализ движущих сил, которые влияют на необходимость использования ИТ с точки зрения основных функций и бизнеса организации. Определяются требования бизнеса и технологии на текущем этапе и на перспективу, которые задают требования к информационным системам. Учитываются тенденции в развитии информационных технологий и мировых аналогов с учетом перспектив развития бизнеса. − На основе этого анализа формулируются в самом общем виде требования к информационным технологиям с точки зрения информации (данных) и архитектуры ИТ. − Принимаются общие для организации стандарты и понятия о том, что такое Архитектура предприятия: принципы, общие методы описания архитектуры и ее разделы, стандарты, конкретные продукты и технологии. − Параллельно с этими процессами выполняется анализ на «системном уровне»: аудит используемых информационных технологий и программно-технических средств, аудит организации процессов управления ИТ, внедрения технологий и приложений. 60 − Результаты вышеперечисленных этапов являются основой для выполнения «Gap-анализа», т.е. выявления расхождений и различий между существующей ИТ-инфраструктурой и желаемой архитектурой предприятия. − Результаты Gap-анализа ложатся в основу Плана миграции: определяются цели создания (модернизации) информационных систем и решаемых ими задач, согласовывается стратегия разработки и внедрения информационных технологий (перечень критических процессов, подлежащих автоматизации в первую очередь и т. д.), обсуждается план детального анализа. − После этого начинается фаза реализации конкретных проектов в рамках выработанной на данный момент архитектуры предприятия. С практической точки зрения, реализация инициативы в области разработки архитектуры предприятия разделяется на несколько фаз или этапов. На каждом этапе готовится совершенно определенный набор документов и иных материалов, которые создают основу архитектуры и которые позволяют предъявлять видимые результаты деятельности рабочей группы, ответственной за всю инициативу разработки архитектуры в целом. Основой работы на этих этапах является эволюционный, итеративный процесс, связанный с определением и описанием текущего и желаемого состояния архитектуры, совмещенный с процессом анализа результатов, идентификацией направлений и планов развития (Gap-анализ), который обеспечит синхронизацию архитектуры с изменениями в функциях подразделений, с изменениями в бизнес-требованиях и изменениями в технологиях. Этот процесс условно показан на Рис. 20. 61 Рис. 20. Общая схема процесса разработки архитектуры Таким образом, мы можем сказать, что архитектура является одновременно как постоянным организационным процессом, так и результатом, который материализуется в форме моделей и документов, описывающих существующее и будущее состояние архитектуры. Процесс разработки и обновления архитектуры должен идти параллельно и одновременно с практической реализацией информационных систем предприятия. Это два взаимосвязанных процесса, которые, однако, имеют различные «скорости протекания». Архитектурный процесс по своей природе является концептуальным, имеет длительный временной горизонт, в то время как реализация систем ориентирована на внедрение конкретных решений и реализацию проектов с существенно более коротким временным горизонтом. Архитектура задает цели для отдельных проектов и инициатив, но важна и обратная связь: систематический анализ опыта реализации отдельных проектов и систем является неотъемлемой частью всего процесса планирования и разработки архитектуры. Ниже описаны этапы каждой итерации процесса разработки и обновления архитектуры, которые следуют, в основном, рекомендациям META Group. Характерными для этого подхода элементами описания архитектуры являются та- 62 кие документы, как Общее видение и Концептуальная архитектура. Каждая итерация включает: Этап 1: Разработка Общего видения архитектуры Общее видение обеспечивает единое понимание проблемы между функциональным (бизнес-) руководством и людьми, отвечающими за информационно-коммуникационные технологии. Оно задает контекст для всей последующей разработки элементов архитектуры. Основными элементами Общего видения являются: − описание технологических тенденций, важных для предприятия; − идентификация бизнес-требований и стратегий; − идентификация основных требований к информации и технологиям, ко- торые важны с точки зрения реализации бизнес-стратегий; − идентификация требований к архитектуре предприятия в целом. Этап 2: Параллельная разработка Концептуальной архитектуры и частных Архитектур предметных областей На этом этапе ведется параллельная разработка Концептуальной архитектуры, основанной на ранее определенных принципах и лучших практиках, а также более детальная проработка Архитектур отдельных предметных областей. Описание архитектуры как минимум включает модели таких областей, как Бизнес-архитектура, Архитектура информации, Архитектура прикладных систем и Технологическая архитектура. Необходимо определить те предметные области, архитектура которых предполагает первоочередную разработку на первой итерации процесса. Заметим, что основой разработки архитектур отдельных предметных областей (доменов) служит Концептуальная архитектура. Концептуальная архитектура обеспечивает общий анализ всех доменов архитектуры с точки зрения идентифицированных на этапе разработки общего видения принципов и факторов влияния. Целью Концептуальной архитектуры является перевод требований, сформулированных в Общем видении, в набор конкретных принципов, которые будут использоваться на этапе разработки архитектуры отдельных предметных областей. Этап 3: Разработка Плана реализации. Включает следующие шаги: − Стратегия миграции и планирование реализации. Целью данного шага является определение альтернатив, взаимозависимостей и усилий, необходимых для того, чтобы обеспечить выполнение технологических требований, идентифицированных на предыдущих этапах. Результатом этого шага станет набор проектов, рекомендуемых к реализации с точки 63 зрения достижения желаемого состояния Архитектуры предприятия и Архитектуры отдельных предметных областей. − Расстановка приоритетов в плане разработки и уточнения архитек- тур отдельных предметных областей. На этом шаге определяются стратегические потребности и необходимые усилия для проработки архитектур отдельных предметных областей, которые либо требуют уточнения, либо не были разработаны на предыдущих итерациях архитектурного процесса. 3.2.2 Направления разработки архитектуры: «сверху-вниз» или «снизу-вверх» В общем виде можно сказать, что существуют два принципиально различных подхода в разработке архитектуры предприятия: − Подход «сверху-вниз» предполагает достаточно широкий охват про- блем и точное следование формальному процессу. Основу этому подходу положили методики Захмана и Спивака. Он начинается со сбора информации, требующейся для описания различных доменов архитектуры «как есть». Далее следует этап, связанный с описанием и реинжинирингом бизнес-процессов, консолидации прикладных систем, выстраивание архитектуры данных и, наконец, стандартизация технологической архитектуры. Например, многие государственные проекты ориентированы на этот подход (например, в США в рамках Федеральной архитектуры FEAF). − Подход «снизу-вверх», когда процесс начинается со стандартизации инфраструктурных технологий (технологическая архитектура), а затем развивается в направлении решения проблем более высокого уровня и, в конечном итоге, решает вопросы, связанные с бизнес-архитектурой. Этот подход, видимо, имеет более широкое распространение в бизнесе и в частном секторе. В зависимости от ряда факторов, предпочтение отдается тому или иному подходу. Например, когда проект разработки архитектуры должен быстро показать отдачу, включая финансовую, или если разнообразие используемых в организации технологий явно приводит к падению качества ИТ-сервисов, то предпочтительным является подход «снизу-вверх». Организации, которым нужно решить с помощью архитектуры существенные проблемы, связанные с неэффективностью или большим количеством излишних бизнес-процессов или с наличием перегруженного набора прикладных систем, и которые готовы ждать как минимум год получения видимых результатов от разработки архитектуры, должны использовать подход «сверху-вниз». Наилучшим вариантом, однако, может стать гибридный подход. В любом случае, выбранная стратегия должна отвечать конкретным потребностям организации, и в любом случае, требуется поддержка со стороны высшего руководства и понимание того, что создание архитектуры – это долговременный процесс изменений. 64 Табл. 1. Положительные и отрицательные аспекты различных подходов к разработке Архитектуры предприятия Сверху-вниз Положительные аспекты − С самого начала создается ясное видение существующей ситуации в целом − С самого начала сформулированы бизнес-потребности и проблемы − С самого начала задаются широкие рамки процесса с необходимой поддержкой высшего руководства − − − − − − Снизу-вверх − Программа разработки архи− − − − − − тектуры быстро начинает давать видимые результаты Быстрый успех повышает авторитет и доверие к процессу Самые "горячие", приоритетные проблемы решаются в первую очередь Масштаб и сложность проекта растет постепенно Отсутствует необходимость иметь сразу большую команду, участвующую в процессе разработки архитектуры Ориентация на решение в первую очередь технологических задач соответствует ключевой области экспертизы ИТслужбы Результирующая экономия затрат позволяет обосновать необходимость новых организационных структур и процессов, связанных с архитектурой − − − − Отрицательные аспекты Процесс может носить весьма абстрактный характер (выбор методик, типов моделей и пр.) Маловероятно, что будут получены явные, видимые результаты в течение первого года работ Может сложиться впечатление, что результатом проекта являются никому не нужные документы Процесс сбора информации приводит к задержкам в построении структур управления архитектурным процессом Использование формальных методологий требует обучения Использование многих формальных методик требует наличия навыков и опыта в реинжиниринге бизнеспроцессов Первоначальная техническая направленность проекта затрудняет его распространение на более широкие области, связанные с бизнесом Основанный на внедрении технических стандартов подход создает структуры управления архитектурным процессом, нацеленные на контрольные, "полицейские" функции Первоначальный технологический фокус воспринимается как игнорирование бизнесаспектов Некоторые области, требующие улучшений, должны "ждать" своей очереди (например, архитектура данных) 65 3.3 С ЧЕГО НАЧАТЬ? В самом начале проекта (процесса) разработки архитектуры организации очень часто стремятся как можно скорее выбрать одну из известных на рынке методик или создать на их основе свою собственную. Однако в действительности есть несколько «более первоочередных» моментов, важных для успеха проекта в целом: − обоснование необходимости проекта и факторов, влияющих на разра- ботку архитектуры; − формирование команды проекта разработки архитектуры; − определение границ архитектуры и используемых методик; − формирование структур и процессов управления (governance) (этому посвящен особый раздел). и контроля 3.3.1 Обоснование необходимости проекта разработки архитектуры и факторы влияния Прежде всего необходимо понять, какие факторы подталкивают предприятие к рассмотрению вопросов разработки архитектуры. Это могут быть, например, макроэкономические факторы, требующие переосмысления вклада ИТ в бизнес, или конкурентная ситуация, требующая новых прикладных систем и обеспечивающей инфраструктуры (например, децентрализации процесса приема заказов). Факторы могут быть связаны с изменениями в бизнес-стратегиях, например, с принятием решения об организации более индивидуализированной работы с клиентами, что потребует внедрения целого ряда новых информационных систем. Важно понимать, как эти факторы могут быть использованы при обосновании проекта разработки архитектуры перед высшим руководством. Основная сложность обоснования необходимости архитектурного проекта и выделения соответствующих инвестиций связана с тем, что прогнозируемые результаты обычно предполагают косвенное улучшение бизнеса организации, то есть являются, как правило, качественными и редко могут быть связаны с конкретными финансовыми выгодами. С точки зрения обоснования цифр экономии практически невозможно дать какие-то общие, применимые на все случаи, оценки затрат, связанных с отсутствием архитектуры ИТ. Это зависит от уникальности ситуации в каждой конкретной организации. Экономия может быть достигнута, в частности, за счет сокращения расходов, связанных с повторным использованием оборудования или программного обеспечения, за счет сокращения времени разработки, оптимизации расходов на ведение проектов, снижения стоимости технической поддержки, приобретения новых активов или экономии за счет более простой адаптируемости системы, построенной на базе единой архитектуры, к изменению требований бизнеса. Важно иметь в виду, что учет только прямых финансовых выгод зачастую оказывается недостаточным для оправдания инвестиций, так что приходится использовать более сложные методики, чтобы включить в обоснование проекта 66 косвенные выгоды для бизнеса организации. С другой стороны, еще одним существенным аспектом, который необходимо принимать во внимание при переходе к новой архитектуре, является увеличение рисков, связанное с тем, что ко всем рискам, постоянно присутствующим в ИТ-системе (такими, как выход из строя оборудования или ошибка персонала), добавляются еще и риски, связанные с изменениями. 3.3.2 Формирование команды проекта Точно так же, как в строительстве существует должность главного архитектора города или проекта, так и в организации кто-то должен быть ответственным за развитие архитектуры информационных систем предприятия в целом. С учетом отмеченной ранее тесной связи между архитектурой информационных технологий и бизнес-архитектурой, один и тот же человек может отвечать за обе эти области. Интересным является вопрос об оптимальном составе команды проекта по разработке архитектуры. Обычно выделение отдельных структур считается целесообразным для достаточно больших по размеру ИТ-служб, насчитывающих порядка 100 и более сотрудников. Даже для больших организаций рекомендуется ограничивать состав основной команды 7-8 сотрудниками, а для более детальной проработки доменов архитектуры (частных архитектур данных, приложений и пр.) создавать отдельные проектные группы. В меньших организациях чаще используется матричный метод, когда в команду проекта входят представители различных подразделений. Оптимальный состав команды, по мнению META, должен включать специалистов со следующими ролями: 1) Стратег, который взаимодействует с руководством организации и формулирует на понятном специалистам по информационным технологиям языке те бизнес-требования, которые должны найти отражение в архитектуре предприятия. 2) Проектировщик, ответственный за определение общих архитектурных принципов. 3) Тренер, который специализируется на объяснении высшему руководству и бизнес-пользователям необходимости и преимуществ архитектуры предприятия. 4) Советники, которые обеспечивают взаимодействие с командами, реализующими отдельные программы и проекты, а также отслеживают перспективные технологии и изменения в окружении. 5) Контролер, отвечающий за постоянное сравнение всех проходящих ключевых преобразований с планом, а также за необходимые изменения в плане в соответствии с потребностями организации. Помимо собственно команды проекта, в организации должны существовать некоторые формальные структуры, каждая из которых выполняет опреде- 67 ленные руководящие и контролирующие функции. Обычно создаются такие структуры, как Управляющий или Информационный комитет, утверждающий общий ИТ-бюджет и ИТ-стратегию компании, и Совет по архитектуре (или Технический комитет), который следит за организацией процесса разработки архитектуры, а также рассматривает и санкционирует отклонения от утвержденной архитектуры. Важно подчеркнуть, что, хотя команда проекта разработки архитектуры и выполняет основную работу, она, как правило, не является собственником этого процесса и результатов. Целесообразно, чтобы ее результаты были сформированы в виде рекомендаций, подлежащих утверждению высшим руководством организации для придания определенной значимости и легитимности. Более того, команда проекта или служба Главного архитектора не должна сама выполнять «полицейские» функции в случае несоответствия проектов утвержденным архитектурным стандартам. 3.3.3 Определение границ архитектуры и используемых методик Следующий важный элемент, с которым необходимо определиться, – это границы архитектуры. Например, если вы отвечаете за разработку архитектуры электронного правительства на региональном, городском уровне, то, возможно, вы сознательно сосредоточите основные усилия в разработке архитектуры на вопросах, связанных с межведомственным информационным взаимодействием. Если вы решили, что архитектура предприятия должна затрагивать ваших партнеров и поставщиков, то, следовательно, это потребует определенного участия их представителей в работе. Или наоборот, вы сознательно выберете некую часть предприятия, наиболее важную в каком-то смысле, и только часть бизнеспроцессов организации. Предположим, что команда проекта разработки архитектуры сформирована и готова начать свою работу. Как и для традиционных проектов, прежде всего следует обеспечить формализацию этого процесса путем составления и утверждения устава проекта. Такой устав определяет задачи проекта, график выполнения, используемый подход и процедуры, а также фиксирует тот факт, что эта деятельность поддержана руководством организации. Соответственно, такой устав должен будет периодически, обычно раз в год, пересматриваться и утверждаться Управляющим комитетом организации. При переходе к практической реализации очевидно, что для достижения конечной цели необходимо предварительно определить некоторую согласованную основу. В качестве такой основы может выступить набор архитектурных моделей высокого уровня. Сформированный набор моделей документируется в произвольном формате, например, в виде обычного файла текстового редактора. Поскольку его основным назначением является использование для широкого обсуждения не только внутри команды проекта, но и с представителями различных подразделений, то применение специализированных средств моделирования на данном этапе может затруднить взаимодействие из-за отсутствия у 68 всех участников необходимой подготовки и установленных специализированных средств. Еще раз стоит подчеркнуть, что на данном этапе не следует углубляться в излишнюю детализацию. Напротив, более важным является "расширение" области охвата. При этом временные рамки этапа также должны быть четко определены и ограничены – так, что даже для больших компаний срок реализации этапа с учетом обсуждений и согласований не должен превышать трех месяцев, а для мелких и средних – значительно меньше. Другой важной задачей начального этапа будет выбор и согласование внутри команды наиболее подходящей методики или модели (framework) для детального описания архитектуры. Какой-либо одной, обязательной к применению методики не существует – каждая организация вправе выбирать ту, которая наиболее для нее удобна. Самым целесообразным будет выбор одной из методик в качестве основной с дополнением элементов других методик. Необходимым шагом будет документирование выбранного решения (или точнее, выбранного подмножества) с тем, чтобы это краткое, не более чем на 10 страниц, описание могло быть использовано командой проекта в качестве методологической основы. Другими важными документами, которые будут использоваться в качестве основы, являются: − стратегия коммуникации, то есть распространения информации по про- екту внутри организации с учетом потребностей в информации всех заинтересованных участников – то есть, с самого начала проекта необходимо предусматривать шаги для обеспечения внедрения его результатов; − процедуры рассмотрения и разбора исключительных ситуаций и откло- нений от стандартов архитектуры. В целом, для успеха архитектурного проекта необходимы следующие пять элементов: − тщательное планирование; − адекватное финансирование и обеспечение ресурсами (участники, вре- мя); − мотивация и реализация («кнут и пряник»); − талант и квалификация команды; − видение цели. Реальный эффект достигается за счет синергетического сочетания всех этих элементов, так что отсутствие или недостаточность отдельных частей может приводить к следующим вариантам неудач: − недостаточное финансирование и нехватка ресурсов, как правило, при- водит к тому, что проект ограничивается решением тактических задач 69 на уровне ИТ-службы, типа выбора версии того или иного продукта без учета реальных бизнес-потребностей. Будущая архитектура будет нечетко определена и не позволит получить реальную отдачу при практической реализации; − недостаточная мотивация персонала команды может быть связана с ощущением «работы на полку» – если разработанные архитектурные решения не будут поддержаны соответствующими организационными мерами и политикой реализации на практике; − страх перед изменениями – предлагаемые решения не должны воспри- ниматься как невозможные. Предлагаемые изменения должны быть поддержаны соответствующим развитием квалификации; − распыленность – изменения, как правило, являются достаточно болез- ненными и поэтому будут объективно затягиваться под различными предлогами без принятия соответствующих мер. Важным является четкое фокусирование на конечной, определяемой видением, цели, – иначе многие реализуемые инициативы могут быть проведены впустую. 4 ЛЕКЦИЯ: ПРОЦЕСС РАЗРАБОТКИ АРХИТЕКТУР: УПРАВЛЕНИЕ И КОНТРОЛЬ, GAP-АНАЛИЗ, ВНЕДРЕНИЕ 4.1 УПРАВЛЕНИЕ И КОНТРОЛЬ АРХИТЕКТУРНОГО ПРОЦЕССА (GOVERNANCE) 4.1.1 Методы управления и контроля Создание организационных структур и выстраивание процесса управления разработкой, практическим использованием и обеспечением соответствия принятой архитектуре является одним из ключевых факторов успеха. Эта функция управления и контроля включает два аспекта: − обеспечение того, что архитектура предприятия становится правилом или «законом», которому все подразделения организации, специалисты по ИТ следуют в своей работе. Нужен адекватный организационный механизм, который бы делал результаты работы группы, отвечающей за разработку архитектуры, законом для всего предприятия; − организация процесса, который бы обеспечил выполнение принятых правил (или «закона»). Это включает процессы рассмотрения проектов и инициатив на соответствие архитектуре, процессы рассмотрения неизбежных исключений и конфликтов – фактически, обеспечение контроля и надзора. Реализация управления и контроля естественно предполагает участие представителей бизнес-подразделений в работе над архитектурой. То есть управление и контроль архитектурного процесса включает такие аспекты, как персонал, правила (политики) и процессы, которые должны обеспечивать средства обеспечения свободы действий и принятия решений без нарушения общих правил, установленных архитектурой. Это предполагает принятие правил и вы- 70 работку руководств, которые бы задавали стандарты поведения по отношению к архитектуре предприятия. А за этим следует определение способов выполнения правил, т.е. процессов, обеспечивающих исполнение этих правил и руководств (включая методы контроля, список контролируемых параметров, информирование и применение санкций, связанных с несоблюдением правил). Наиболее общими подходами обеспечения управления и контроля архитектуры являются следующие: − Публикации и распространение информации и документов описа- ния архитектуры. Публикация архитектурных документов является очень важным аспектом всего процесса управления архитектурой, но сам по себе этот инструмент не будет работать без других механизмов. С разработкой и реализацией архитектуры предприятия связаны интересы большого количества сторон, поэтому информация об архитектуре должна распространяться внутри организации на различных уровнях, в том числе с использованием визуальных, графических средств представления или специализированных языков. Для высшего руководства архитектура должна демонстрировать, как она обеспечивает достижение бизнес-целей и какие преимущества будут получены. Областью интереса бизнес-пользователей являются их специфические предметные области и функциональные потребности. Руководители в области ИТ и технический персонал больше сфокусированы на технических компонентах, включая то, как впоследствии будет обеспечиваться поддержка и сопровождение разрабатываемых решений. Архитекторов отдельных проектов волнуют такие вопросы, как стандарты, шаблоны и правила, пригодные для повторного использования либо накладывающие ограничения на дизайн отдельных решений. Публикуя информацию об архитектуре, нужно стремиться удовлетворить все перечисленные категории заинтересованных сторон. Более того, чем более открытой является эта информация внутри предприятия (за исключением, возможно, определенных аспектов архитектуры безопасности), тем больший эффект это принесет. − Создание формальных структур, таких как Совет по архитектуре. На регулярных заседаниях таких формальных структур должны рассматриваться, в частности, архитектурные вопросы новых систем и инициатив. Эти структуры должны утверждать или отвергать проекты, в зависимости от того, насколько соблюдены принятые в архитектуре принципы, модели и стандарты. Большим преимуществом является ситуация, когда методики разработки систем и процессов управления проектами широко известны и используются в организации и когда рассмотрение проекта Советом по архитектуре является стандартным этапом процесса. Недостатками этого метода управления могут оказаться: дополнительный уровень бюрократии, отсутствие у комитета реальных рычагов изменения проектировочных решений, возможность задержек в 71 рассмотрении вопросов в ситуации, когда требуется быстрое принятие решений. − Контроль процесса закупок. Предполагается такое выстраивание про- цесса, когда закупка продуктов и технологий, соответствующих архитектуре, выполняется легко и просто, а покупка нестандартных с точки зрения принятой архитектуры продуктов существенно затруднена. − Обеспечение консультирования по вопросам архитектуры. Это наи- более эффективный, имеющий минимальный уровень бюрократии процесс управления архитектурой. Он состоит в использовании ресурсов внутренних консультантов по вопросам архитектуры на самых ранних этапах проектов; они дают рекомендации, касающиеся выбора технологий и общих принципов проектирования системы. В отличие от формальных методов контроля, рассмотрения на комитетах и т.д., модель, предполагающая консультирование, является проактивной и упреждающей. Конечно, и у этого способа есть свои ограничения, поскольку есть опасность, что ограниченные ресурсы группы, отвечающей за разработку архитектуры, станут чрезмерно распыляться на работу по отдельным проектам. 4.1.2 Организационные структуры, связанные с разработкой архитектуры Рис. 21 отражает наиболее важные организационные структуры и связи между ними. Важно понимать функции и характеристики каждой представленной здесь организационной структуры. При этом точное название подразделений и количество людей в них не несут принципиального значения. На самом деле, большинство департаментов ИТ уже имеют многие из этих организационных структур в той или иной форме. Все эти организационные структуры вовлечены как в процессы разработки архитектуры, так и в процессы контроля и надзора. 72 Рис. 21. Организационные структуры, связанные с управлением и контролем архитектуры Управляющий исполнительный комитет является авторитетным органом, который стоит за всей работой, связанной с архитектурой. В идеале он должен включать представителей бизнеса и руководителей ИТ. Он задает общую стратегию и обеспечивает то, что архитектура принимает «силу закона» в организации. Важный аспект заключается в том, что придавать архитектуре силу закона (т.е. выполнять «полицейские» функции) те люди, которые разрабатывают архитектуру (команда разработки архитектуры предприятия), не должны: они только дают рекомендации. Архитектуру как «закон» реализует внешний по отношению к команде разработчиков орган, которым и является Управляющий исполнительный комитет. Он не занимается детальными вопросами, но оставляет за собой право принятия решений, касающихся стратегических моментов, крупных проектов и закупок. Он также делегирует своих членов для работы в Архитектурном комитете, который принимает решения более низкого уровня. В крупных организациях могут создаваться подкомитеты и рабочие группы по отдельным проблемам, связанным с архитектурой. Группа управления корпоративными проектами отвечает за контроль ведения проектов, использование ресурсов, обоснование инвестиционных расходов, контроль за расходованием бюджета и за зависимости между проектами. Группа управления проектами помогает Управляющему исполнительному комитету в расстановке приоритетов и распределении ресурсов между различными проектами. Она также играет ключевую роль в обеспечении рассмотрения и утверждения проектов, в том числе на соответствие архитектуре. 73 Команда разработки архитектуры предприятия отвечает за весь процесс в целом: подготовку всех документов, связанных с описанием архитектуры, контроль инфраструктурных проектов. Она должна представлять ключевые документы, такие как описание общего видения архитектуры и концептуальная архитектура, на рассмотрение и утверждение Управляющего исполнительного комитета и Совету по архитектуре. Она также создает отдельные команды, отвечающие за разработку архитектуры отдельных доменов. Эта группа должна эффективно информировать и консультировать подразделения организации по вопросам, связанным с архитектурой предприятия. Следует отметить, что существенные изменения в архитектуре предприятия происходят примерно каждые два года (в то время как небольшие изменения – каждые полгода). Команда разработки архитектуры отвечает за реализацию этих изменений и, возможно, за создание специальных рабочих групп по внесению таких существенных изменений (либо это делегируется командам, отвечающим за отдельные домены архитектуры). Совет по архитектуре отвечает за предоставление вводной информации, рассмотрение и утверждение концептуальной архитектуры и других компонент архитектуры, включая стандарты на продукты. Команды разработки архитектуры отдельных доменов отвечают за формулирование архитектурных принципов, стандартов на продукты, конфигурации и обсуждение вопросов, связанных с отдельными доменами архитектуры (бизнес-архитектура, архитектура информации и т.д.), планирование и выполнение проектов, имеющих отношение к соответствующим частям архитектуры. Таким образом, постоянная работа непосредственно над архитектурой с организационной точки зрения ведется как бы на трех уровнях: − стратегический уровень, на котором принимаются общие решения, ка- сающиеся принципов использования архитектуры, основных направлений ее развития, достижения соглашений в организации о целесообразности этих усилий; − уровень внесения существенных изменений в архитектуру; − повседневная работа над созданием документов и моделей, описываю- щих архитектуру, информирование подразделений организации, обучение, демонстрация и т.д. С практической точки зрения, архитектура реализуется постепенно и поступательно через выполнение отдельных проектов. Типичная ситуация выглядит так: − команда, отвечающая за разработку архитектуры, описывает архитекту- ру отдельных доменов, информирует о результатах этой работы остальные заинтересованные подразделения, получает замечания и предложения, обеспечивает возрастание уровня понимания; 74 − идентифицируется некоторый проект, который требует использования новых инструментов и концепций, сформулированных в архитектуре. Команда, отвечающая за этот проект, получает необходимую поддержку со стороны группы, отвечающей за архитектуру в целом, и в проекте реализуются заложенные архитектурные принципы; − делаются определенные изменения в архитектуре с учетом накопленно- го опыта; − идентифицируется следующий проект, который может быть основан на использовании тех же архитектурных компонент; − процесс повторяется, и в ходе этого процесса происходит как накопле- ние и уточнение, так и передача необходимых знаний об архитектуре. 4.1.3 Обеспечение соответствия проектов архитектуре Отдельные программы и проекты должны соответствовать принятой архитектуре предприятия для того, во-первых, чтобы были реализованы желаемые преимущества с точки зрения бизнеса, а во-вторых, для того, чтобы системы и процесс разработки программных решений использовали преимущества от ранее выполненного анализа. Более того, как и любая архитектура, архитектура предприятия требует постоянного сопровождения, особенно в тех областях, которые связаны с физическими областями, такими как технологические стандарты. Благодаря этому, архитектура предприятия остается актуальной и продолжает соответствовать требованиям бизнеса по мере его изменения. Очевидно, что разработка архитектуры предприятия не будет иметь эффекта, если организация не сможет обеспечить контроль за ее реализацией. Развернутые рекомендации по контролю соответствия содержатся в модели TOGAF, где описаны два основных процесса: − формализованная проверка проекта на соответствие архитектуре; − оценка влияния архитектуры на проекты. Ключевым термином в обоих случаях будет являться само понятие «соответствие». На практике возможны следующие варианты, показанные на Рис. 22. 75 Рис. 22. Варианты соответствия реализации и описания архитектуры по TOGAF Проверка проекта на соответствие архитектуре производится, как правило, на достаточно глубоком уровне детализации в рамках предварительно определенной формальной процедуры. Ее основными целями являются: − уменьшение проектных рисков за счет идентификации ошибок и «узких мест» в архитектуре разрабатываемой системы; − использование преимуществ известных методов лучшей практики, су- ществующих архитектурных прототипов или технологических инноваций; − оценка технического уровня и степени готовности разрабатываемой системы для независимой оценки и доклада руководству; − идентификация областей, где сама архитектура (профили стандартов) может требовать модернизации. Очевидно, что момент времени, выбранный для проведения такой проверки, должен являться определенным компромиссом. С одной стороны, должна быть достигнута определенная степень проработки проектных решений, и 76 сформирован набор проектных артефактов для проверки, с другой – необходимо иметь запас времени для корректировки возможных ошибок. Как правило, проведение такой процедуры должно предусматриваться в календарном плане проекта. Если для небольших проектов эта процедура может быть выполнена одним из членов Службы Главного архитектора, то для крупных может потребоваться активное привлечение всей службы, экспертов в бизнес-областях, спонсора проекта и предварительное планирование отдельных этапов всей процедуры.. 4.1.4 Оценка затрат на разработку и сопровождение архитектуры предприятия Безусловно, возникают два вопроса, касающиеся финансовых затрат, связанных непосредственно с разработкой и последующим сопровождением архитектуры предприятия (обновлением и поддержанием ее в актуальном состоянии). Сколько средств необходимо выделять на это? Как оценивать уровень затрат на архитектуру? Размеры и характер деятельности организации, а также масштабы преобразований и модернизации диктуют глубину и степень детализации проработки архитектуры и ее поддержания в актуальном состоянии. Соответственно этому определяются и те ресурсы, которые необходимы для инвестиций в архитектуру. При этом здесь мы говорим только о затратах, связанных с разработкой самой архитектуры. Это не включает затраты на ее реализацию, такие как закупка и разработка программного обеспечения, закупка аппаратного обеспечения и т.д. На самом деле, на этот счет отсутствуют детальные и точные данные. Кроме затрат на персонал, дополнительные расходы связаны с приобретением средств моделирования и созданием репозитория для хранения артефактов (документов, моделей и пр.), описывающих архитектуру предприятия. Текущие затраты на сопровождение архитектуры включают: − обеспечение поддержки архитектуры со стороны сотрудников ИТ- службы и бизнес-подразделений; − создание, документирование и публикация информации об архитектуре; − проведение анализа и контроль соответствия архитектурных решений отдельных проектов; − обучение и оценка результатов; − подготовка планов технологического развития, связанных с новыми технологиями. 4.2 GAP-АНАЛИЗ (АНАЛИЗ НЕСООТВЕТСТВИЙ) И МОДЕЛЬ РАЗВИТИЯ ЭЛЕМЕНТОВ ИТ-АРХИТЕКТУРЫ Существенным элементом рассмотренного нами ранее процесса создания архитектуры предприятия является идентификация и анализ несоответствия между существующим и желаемым состоянием архитектуры предприятия и от- 77 дельных его доменов – так называемый gap-анализ. Этот анализ является критически важным с точки зрения определения ключевых шагов и необходимых изменений в направлении целевой архитектуры. На этом этапе необходимо категоризировать идентифицированные несоответствия и собрать вместе бизнестребования, технологические потребности, требования к информации и приложениям – для того, чтобы начать решение соответствующих проблем. При этом несоответствия могут быть связаны с вопросами культуры организации, структурными проблемами, функциональными или же процедурными вопросами. При этом под структурными несоответствиями понимаются несоответствия между существующим и целевым состоянием, связанные с вопросами инфраструктуры. Основное внимание здесь связано с архитектурными принципами и архитектурой отдельных доменов. Функциональные несоответствия связаны с возможностями систем по поддержке новых бизнес-процессов, которые необходимы для реализации новых бизнес-стратегий. Основное внимание должно быть уделено реализации необходимых приложений и систем, требующихся для обеспечения улучшенных или новых бизнес-процессов. Культурные несоответствия – это несоответствия между сегодняшним состоянием ИТ-департамента организации (набор навыков, компетенция и структура) и требующимися навыками, компетенциями и структурами, которые необходимы для решения проблем в первых двух областях. Процедурные несоответствия – это несоответствия между существующими и желаемыми методами управления, стратегиями сорсинга, процессами эксплуатации ИТ-сервисов и организационными процедурами. Таким образом, условно можно сказать, что существует два типа несоответствий: − «жесткие» несоответствия, которые связаны, например, с необходимо- стью замены ряда технологий или внедрения новых; − «мягкие» несоответствия, например, несоответствие архитектурным принципам или несоответствия между имеющейся и требуемой квалификацией персонала. Процесс анализа на несоответствия включает следующие шаги: − идентификация различий между существующей и целевой архитекту- рой; − составление списка идентифицированных несоответствий с разбивкой по категориям и составление списка требуемых изменений; − идентификация уже имеющихся возможностей ИТ-систем, которые мо- гут быть использованы для удовлетворения идентифицированных проблемных мест, и обновление списка несоответствий с учетом этого фактора; 78 − группировка идентифицированных несоответствий по типу их влияния на деятельность предприятия (уровень предприятия в целом, уровень нескольких подразделений и функций, уровень отдельного подразделения и функции, особые случаи). Необходимым элементом в проекте развития ИТ-архитектуры является оценка существующего состояния и перспективности использования имеющихся компонент. Рассмотрение элементов ИТ-архитектуры ведется обычно в двух аспектах: а) планирование и управление ИТ-системами, и б) стандарты и общие службы (компоненты). Аспект планирования и управления включает: − направление развития ИТ – определяет среднесрочные и перспективные роли ИТ в компании с учетом требований бизнеса и выделенных приоритетов; − принципы реализации – определяют «правила» рассмотрения, внедре- ния и последующего управления технологиями; − динамичность – планирование внедрения технологий должно прово- диться с учетом их постоянного совершенствования и появления новых технологий, а также с учетом возможного изменения требований бизнеса. Аспект стандартизации включает: − Общие ИТ-службы. Сюда относятся кросс-функциональные и служеб- ные приложения, такие как электронная почта. − Вычислительная инфраструктура. Корпоративные стандарты на техно- логии и средства инфраструктуры должны базироваться на применении общепризнанных ИТ-стандартов. − Элементы архитектуры системы. Эти элементы определяются как для среднесрочных, так и для перспективных стандартов. Каждый такой элемент оценивается с учетом ситуации в отрасли, степени использования в организации, целесообразности исключения из системы в течение перспективного срока (старение) или временного сохранения, целесообразности развития, целесообразности проведения переоценки его роли в будущем для обеспечения динамичности. При определении стратегии обычно выделяются среднесрочный (9-18 месяцев) и перспективный (18-36 месяцев) периоды, хотя на основании результатов аудита могут быть сформулированы и срочные задачи, требующие решения в течение недель и месяцев. Оценка перспективности развития проводится с учетом: − стратегии развития, перспективности расширения бизнеса, изменения отношений с клиентами и поставщиками; − общемировых тенденций развития информационных технологий; 79 − выбранного направления развития ИТ-технологий в организации и стратегии реализации (срочные, среднесрочные и перспективные этапы). 4.3 КАК ОБЕСПЕЧИТЬ ВНЕДРЕНИЕ РЕЗУЛЬТАТОВ ПРОЕКТА РАЗРАБОТКИ АРХИТЕКТУРЫ Предположим, что совместная команда энтузиастов, включающая специалистов ИТ-службы и бизнес-подразделений, завершила основной этап проекта разработки архитектуры предприятия. Теперь возникает задача – добиться принятия предлагаемых решений во всех подразделениях компании. Достаточно типичной ситуацией является такая, что, с одной стороны, у многих руководителей может быть общее понимание актуальности рассматриваемых вопросов, а с другой, будет явное противодействие накладываемым ограничениям и устанавливаемым стандартам. Обеспечение поддержки усилий по разработке архитектуры предприятия предполагает знания того, что действительно важно для людей, которые могут способствовать или «блокировать» процесс принятия соответствующих решений. Этих людей можно условно разделить на три группы: − руководство организации и руководители бизнес-направлений; − среднее звено управления бизнесом; − различный технический персонал, а также «продвинутые и влиятель- ные» пользователи. В частности, высших руководителей в отношении архитектуры, как правило, интересуют три основные цели: сохранение своей автономии, минимизация затрат на ИТ и отсутствие препятствий со стороны ИТ в плане гибкости или надежности. Для обеспечения поддержки этой категории людей важны такие вещи, как примеры удачного опыта (case studies), сравнение с другими передовыми организациями (benchmarking), улучшение финансовых показателей и продуктивности. Бизнес-руководство среднего звена волнуют такие вещи как защита своей сферы влияния от «вторжения» со стороны информационных систем, улучшение надежности и применимости технологий, от которых зависит их успех, и достижение запланированных высшим руководством показателей эффективности. Поскольку они ближе к реальной практической работе и в большей степени зависят от эффективности технологий, эта категория людей настроена более скептически к утверждениям представителей департаментов ИТ. Стоит отметить, что именно «повышение способности к взаимодействию» компонент информационных систем предприятия рассматривается как главное преимущество архитектуры, которое актуально для всех рассмотренных категорий сотрудников организации. В более общем плане, информационные системы в целом приобретают расширенные способности к взаимодействию с сис- 80 темами поставщиков и клиентов, что, в свою очередь, способствует развитию взаимосвязей предприятия. Очень часто в крупных организациях можно насчитать несколько сотен различных процессов, связанных с управлением ИТ-инфраструктурой. Надежность и масштабируемость всех этих процессов определяется тем, как эти процессы справляются с тем большим количеством «мелочей», включающих серверы, рабочие станции, устройства хранения данных, сети, разнообразные программы и т.п., которые и составляют суть ИТ-инфраструктуры. Это является ключевой причиной, по которой нужна архитектура, – для того, чтобы справиться со всеми этими факторами сложности и обусловленными ими затратами. Напрямую связано с этими вопросами сложности обеспечение гибкости и скорости реакции организации на изменения. С этой точки зрения базовой функцией архитектуры является уменьшение сложности за счет деления на функциональные части, уменьшение количества элементов, которые фигурируют в формуле «перемножения сложностей» и улучшения способности организации в целом воспринимать будущие изменения. Потенциальная настороженность бизнес-руководителей понятна и предсказуема. Менее очевидным фактом является то, что и в рамках собственно ИТслужбы возможна дифференциация по отношению к предлагаемым нововведениям как со стороны разработчиков компонент, так и со стороны эксплуатирующего персонала. Причины сдержанного отношения или даже активного неприятия предлагаемых решений, вплоть до откровенного саботажа, в общем-то достаточно стандартны и могут быть связаны как с нежеланием менять что-то в привычном порядке своей деятельности, так и с опасениями насчет изменений персональной значимости в организации. Поэтому в ходе проекта необходимо, как правило, предусматривать специальные меры, например, превентивное переобучение персонала на новые технологии, изменение мотивационных схем, установка корреляции оплаты труда с показателями работы информационных систем и т.п. 81 ИСПОЛЬЗОВАННЫЕ ИСТОЧНИКИ 1. Курс лекций «Архитектура предприятия». Авторы: А.В. Данилин, А.И. Слюсаренко. www.intuit.ru 2. Роджер Сешнс Сравнение четырех ведущих методологий построения архитектуры предприятии // http://msdn.microsoft.com/ru-ru/library/ee914379.aspx