Имени Александра Григорьевича и Николая Григорьевича Столетовых»
(ВлГУ)
Институт экономики и менеджмента
Кафедра Бизнес-информатика и экономика
Составитель: Куликова И.Ю.
Конспект лекций по дисциплине
«Архитектура предприятия»
Конспект лекций
По дисциплине «Архитетура предприятия»
для студентов ВлГУ,
обучающихся по направлению 38.04.05» Бизнес-информатика»,
программа «Предпринимательство и организация бизнеса в сфере информационных технологий»
Владимир – 20__ г.
Оглавление
| Введение…………………………………………………………………………………… | 3 |
| Тема 1. Архитектура предприятия: понятийный аппарат …………………………….. | 5 |
| Тема 2. Современные методики описания архитектуры предприятия ……………… | 25 |
| Тема 3. Процесс разработки архитектур ……………………………………………….. | 86 |
| Заключение………………………………………………………………………………... | 129 |
| Список литературы……………………………………………………………………….. | 130 |
Введение
Изучение дисциплины обеспечивает формирование у студентов практических навыков работы с архитектурой предприятия, необходимых в дальнейшей профессиональной деятельности.
Знания, полученные в рамках изучения данной дисциплины, могут быть применены при прохождении практик, выполнении научно-исследовательских работ, подготовке к научно-исследовательскому семинару и выпускной квалификационной работы (магистерской диссертации).
Целями освоения дисциплины «Архитектура предприятия» являются:
1. Формирование навыков, необходимых для полноценного участия в стратегических процессах организации, реализации возможности повышения эффективности бизнеса на основе информационных и коммуникационных технологий.
2. Формирование у магистрантов необходимых практических навыков для работы с современными методиками, моделями и программным обеспечением в рамках решения практических задач по созданию архитектуры.
3. Формирование целостного представления у магистрантов о месте и роли архитектуры предприятия в процессе исследования и разработки современных сложных систем, моделирующих проблемную ситуацию в предметной области.
Процесс изучения дисциплины «Архитектура предприятия» направлен на формирование следующих профессиональных компетенций:
- способность разрабатывать стратегию развития архитектуры предприятия (ПК-4);
- способность управлять внедрением инноваций для развития архитектуры предприятия (ПК-17).
В результате освоения дисциплины обучающий должен демонстрировать следующие результаты образования:
1) Знать:
- понятие и уровни архитектуры предприятия (ПК-4);
- понятие и уровни архитектуры предприятия, основные подходы к проектированию архитектуры предприятия (ПК-17).
2) Уметь:
- управлять архитектурой предприятия (ПК-4);
- ставить цели и формулировать задачи, связанные с внедрением инноваций для развития архитектуры предприятия (ПК-17);
3) Владеть:
- базовыми навыками работы по созданию архитектуры предприятия в целях его стратегического развития (ПК-4);
- навыками управления внедрением инноваций для развития архитектуры предприятия (ПК-17).
Конспект лекций составлен на основании разработок ведущих мировых компаний, в том числе и российских, ведущих свою деятельность в области информационных технологий и систем, ученых-исследователей и преподавателей технических и экономических дисциплин.
Представленный конспект является важным элементом самостоятельной работы студентов.
Самостоятельная работа предполагает изучение тем дисциплины вне аудитории и включает в себя выполнение различного рода заданий, которые ориентированы на более глубокое усвоение материала.
Самостоятельное освоение учебной дисциплины требует систематического и последовательного накопления знаний.
Поэтому студент должен
- постоянно обращаться к материалам рабочей программы дисциплины (РПД) при подготовке к занятиям;
- уяснить цели и задачи дисциплины, ее место в общей системе обучения, а также связи с другими дисциплинами образовательной программы;
- ознакомиться с графиком консультаций преподавателей кафедры, ведущих лекционные и практические занятия;
- взять в библиотеке, найти в интернет-источниках или приобрести рекомендованные в перечне основной литературы учебники и учебные пособия;
- перед каждой лекцией восстановить в памяти материал предыдущих занятий, воспользовавшись конспектом, а также просмотреть РПД по пройденной теме и ее основные вопросы;
- при затруднениях в понимании материала дисциплины следует обратиться к лектору по его графику консультаций или к преподавателю, ведущему практические занятия.
Самостоятельная работа должна выполняться самим студентом и в установленный срок.
Знание лекционного материала позволяет понять основы изучаемой темы курса, терминологию, закономерности и зависимости, проследить взаимосвязь разных тем, осваивать курс от простого к сложному. Лекционный материал помогает подготовиться к выполнению разного рода заданий, пройти рейтинговые испытания. Поэтому посещение лекций является обязательным, конспектирование лекций - необходимым и обращение к лекционному материалу - очень важным. Итоговый рейтинг включает баллы за посещение лекционных занятий. Промежуточный контроль по результатам семестра по дисциплине проходит в форме экзамена, который включает в себя знания теоретических вопросов, полученных, в том числе, в ходе посещения лекционных занятий и освоения их материалов самостоятельно.
Содержание (предмет) Архитектуры предприятия
Определения архитектуры
Описания систем
Модель Захмана
Значительный вклад в развитие концепции архитектуры предприятия был сделан Дж. Захманом (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" как "методики".
Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур (framework), для описания современных сложных корпоративных систем. По большому счету, приведенное выше описание Архитектуры предприятия следовало, как будет видно далее, принципам, заложенным в модели Захмана. Мы построили некоторую "матрицу" со строками в виде различных уровней абстракции (перспективами) и набором столбцов в виде представлений (областей) архитектуры, которая в какой-то степени является частью более сложной матрицы, используемой для описания архитектуры в Модели Захмана.
Итак, в своей работе Дж. Захман определил Архитектуру предприятия как "набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)". Термин "архитектура" здесь не случаен, он подчеркивает существующую аналогию между внутренней структурой абстрактного объекта – предприятия и сложного искусственного объекта, такого как здание или орбитальная международная космическая станция (МКС).
Для удобства описания Захман предложил так называемую Модель архитектуры предприятия (Zachman Framework for Enterprise Architecture). Модель преследует две основные цели – с одной стороны, логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции.
В то время, когда были опубликованы работы Захмана, традиционным подходом при формировании описания системы являлось использование концепции "жизненного цикла", включающего такие этапы, как планирование, анализ, проектирование, разработка, документирование, внедрение и промышленная эксплуатация. На каждом из этих этапов рассматриваются вопросы, связанные как с функциями системы, так и с данными. Захман предложил вместо традиционного подхода, связанного с рассмотрением отдельных аспектов работы системы как бы в различные моменты времени, использовать рассмотрение системы с различных перспектив.
Исторически модель Захмана впервые была создана именно для ИТ-систем. Этот подход в последующей работе был обобщен для рассмотрения не только ИТ-систем, но и для описания предприятия в целом, так что предложенная модель, вообще говоря, может использоваться как средство для описания архитектур сложных производственных систем любого типа.
Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Для любой достаточно сложной системы общее число связей, условий и правил обычно превосходит возможности для одновременного рассмотрения. В то же время отдельное, в отрыве от других, рассмотрение каждого аспекта системы чаще всего приводит к неоптимальным решениям, как в плане производительности, так и стоимости реализации.
Собственно модель представляется в виде таблицы, имеющей пять строк и шесть столбцов, которая приведена на рисунке 2.2. Заметим, что в модели именно пять строк, просто отображенная на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.
Рис. 2.2. Модель Захмана
Перспективы (строки в таблице) могут, в частном случае, соответствовать различному уровню управления предприятием, если речь идет об архитектуре предприятия или использования информационной системы.
Две верхние строки соответствуют наиболее общим представлениям и достаточно широко описывают существующее окружение, планы и цели. Если проводить аналогию со строительством, то эти уровни содержат сведения о местонахождении и назначении постройки ("особняк" для отдыха в престижном коттеджном поселке в элитной зоне), а также диаграммы, планы и картинки, которые архитектор обсуждает с хозяином будущего дома. Следующий уровень "логической модели" уже является более конкретным, но все равно еще достаточно абстрактным. Это схемы, которые архитектор дома должен показывать подрядчикам.
Аналогично, в применении к деятельности предприятия верхняя строка "Контекст" соответствует уровню интересов высшего руководства и собрания акционеров. Второй уровень соответствует интересам бизнес-менеджеров и владельцев процессов. Третий уровень – тот, на котором бизнес-менеджеры, бизнес-аналитики и менеджеры, отвечающие за ИТ, должны работать вместе. Уровни с четвертого и далее описывают детали, которые представляют интерес для ИТ-менеджеров, проектировщиков, разработчиков.
На каждом из этих уровней участники, вообще говоря, рассматривают одни и те же категории вопросов, соответствующих столбцам в таблице, – только с различным уровнем абстракции и детализации. В содержание этих колонок входят:
· используемые данные (что?)
· процессы и функции (как?)
· места выполнения этих процессов (где?)
· организации и персоналии–участники (кто?)
· управляющие события (когда?)
· цели и ограничения, определяющие работу системы (зачем?)
Сам Захман в своем интервью он-лайновому журналу "Enterprise Architect Online" без ложной скромности сравнил свою модель с периодической таблицей элементов Менделеева и назвал ее "периодической таблицей описательных представлений предприятия или двумерной системой, схемой классификации". Это действительно ко многому обязывающее сравнение, но Захман привел следующие аргументы в его пользу: "Вопросы что, как, где, кто, когда и зачем существуют тысячи лет. И они будут существовать еще тысячи лет. Требования к системам, процесс проектирования, производства или концептуальный, логический и физический уровень описания также существуют в течение тысяч лет и будут существовать еще тысячи лет. Логическая структура классификации, схема – неизменны".
В конце концов, как отмечает Захман, коммерческие предприятия и государственные организации должны понимать, что путь к эффективным информационным системам требует систематических подходов в проектировании (engineering). Если вы, например, занимаетесь большими проектами, связанными с интеграцией государственных информационных систем, то "...назначить одного ответственного человека – это еще не решение проблемы. Никакого чуда просто так не произойдет. В какой-то момент вы поймете, что настоящий процесс проектирования должен быть реализован для того, чтобы интегрировать эти объекты".
Основные правила заполнения таблицы следующие:
· каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы ("базис");
· порядок следования колонок несущественен;
· каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);
· базовые модели для каждой из колонок являются уникальными;
· соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы;
· заполнение клеток должно проводиться последовательно "сверху вниз", попытка пропуска одного из рядов является, скорее, "шаманством" (в том плане, что нельзя создать хорошо работающую систему, "перепрыгнув" определенные уровни ее описания на этапе проектирования).
Первая строка соответствует уровню планирования бизнеса в целом ( бизнес-модель ). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес – например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – мотивация). Фактически, данная строка определяет контекст всех последующих строк.
Вторая строка (концептуальная модель ) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов.
Третий уровень (логическая модель ) соответствует рассмотрению с точки зрения Системного Архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций.
На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.
Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.
Последний, шестой уровень описывает работающую систему. На этом уровне могут быть введены, в том числе, такие объекты, как инструкции для работы c системой, фактические базы данных, работа службы HelpDesk. Надо заметить, что в исходной работе Захмана содержание этого уровня не детализируется. При развитии модели, как будет показано ниже, отмечены возможности рассмотрения аспектов функционирования работающей системы с точки зрения, например, конечного пользователя или эксплуатирующих служб.
Рассмотрим теперь, как осуществляется последовательная детализация отдельных аспектов описания системы, для чего обратим внимание на различные колонки таблицы. Напомним, что порядок расположения колонок в таблице, вообще говоря, произволен.
Так, первая колонка отвечает на вопрос "ЧТО?" и определяет используемые в системе данные. На верхнем уровне достаточным будет простое перечисление основных объектов, используемых в бизнесе. На втором уровне данные объекты объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы "сущности-связи" (E-R диаграммы) с отражением основных связей и наиболее существенных бизнес-ограничений. На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе – иерархию классов). Следующий уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. Наконец, последний уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистику обращений и т.п. Конечно, можно отметить определенное несовершенство данной модели при использовании объектно-ориентированного подхода – фактически модель предписывает раздельное рассмотрение данных (свойств) и функций (методов) классов.
Колонка функций (ответ на вопрос "КАК?") предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. В частности, на первом уровне достаточным будет простое перечисление бизнес-процессов. Второй уровень будет содержать модель бизнес-процессов, которая впоследствии детализируется в операции над данными и архитектуру приложений (уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец, исполняемые модули. При этом, начиная с 4-го уровня, рассмотрение ведется уже не в рамках Предприятия в целом, а по отдельным подсистемам или приложениям.
Следующая колонка (вопрос "ГДЕ?") определяет пространственное распределение компонент системы и сетевую организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех производственных объектов. На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой, – будь то обмен информацией или поставки товаров. На третьем уровне системной архитектуры осуществляется привязка компонент информационной системы к узлам сети. Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ, системного программного обеспечения, а также средств промежуточного уровня (так называемое "middleware"), используемых для интеграции различных компонент информационной системы между собой. Типичным примером могут являться брокеры запросов или средства обмена сообщениями. На пятом уровне определяются используемые протоколы и спецификации каналов связи. Последний уровень описывает функционирование реализованной сети.
Колонка таблицы, отвечающая на вопрос "КТО?", определяет участников процесса. На уровне планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими функции. На следующем уровне приводится полная организационная диаграмма, а также могут быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли (в RUP используются диаграммы событий и описание вариантов использования), требования к интерфейсам пользователя и правила доступа к отдельным объектам, физическая их реализация на уровне кода или операторов определения доступа к таблицам в СУБД. Последний уровень описывает обученных пользователей системы.
Пятая колонка отвечает на вопрос "КОГДА?" и определяет временные характеристики бизнес-процессов и работы системы. Опять-таки детализация осуществляется сверху вниз, начиная от календарного плана (уровень 1) и основных параметров, характеризующих выполнение бизнес-процессов, – например, требование ко времени оформления сделки (уровень 2). На третьем уровне определяются события, вызывающие изменение состояния информационных объектов и инициацию операций над ними. На следующем уровне эти события транслируются в программные вызовы (триггеры) или передаваемые сообщения. Пятый уровень определяет физическую реализацию обработки таких событий. Наконец, на 6-м уровне – фактическая история функционирования системы.
Последняя колонка ("ПОЧЕМУ?" или "ЗАЧЕМ?") служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем. Исходной точкой является бизнес-стратегия, которая затем последовательно транслируется в бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 – в соответствующие приложения, необходимые для включения в состав информационных систем и, в дальнейшем, в их физическую реализацию.
Такая модель описания в целом полезна для идентификации возможных ограничений. Эти ограничения могут "распространяться" как от верхних уровней к нижним (например, указание руководства компании о выборе тех или иных средств, продуктов или принципов работы), так и в обратном направлении – например, возможности существующих технологий беспроводной связи в значительной степени определяют спектр предлагаемых услуг и организацию бизнес-процессов у провайдеров этих услуг.
Важным принципом предложенной модели является необходимость последовательного перехода при углублении детализации рассмотрения. Пропуск отдельных элементов, например, прямой переход от описания модели бизнес-процесса к физической реализации системы требует "привлечения магии" и почти всегда приводит к неудаче. На практике это часто случается при попытке разработки программы на основании только устного описания требований пользователя.
Основными характеристиками данной модели Захмана, являются следующие:
· простота для понимания как техническими, так и нетехническими специалистами;
· целостность в отношении предприятия, то есть каждая проблема может быть соотнесена с предприятием в целом;
· поддержка обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий;
· возможность применения для планирования, позволяющего лучше принимать решения за счет того, что решение никогда не будет выноситься "в пустоте" (в отрыве от остальных аспектов деятельности предприятия);
· применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия Предприятия как целого;
· нейтральность, то есть независимость от каких-либо инструментов; благодаря этому каждый инструмент и методология могут быть отображены на данную модель и могут явно показать, что они делают и чего они не делают.
Созданная модель архитектуры служила простым, но мощным инструментом по применению системного подхода для планирования работ по созданию и использованию информационных систем и их стыковки. Захман писал, что схема архитектуры позволяет концентрироваться на отдельных аспектах системы и в то же время не терять ощущения общего контекста или "холистической" перспективы (то есть, взгляда на предприятие в целом). Он подчеркивал, что именно потеря такой перспективы, в частности, разработка систем субподрядчиками, находящимися "вне контекста", уже около пятидесяти лет составляет причину появления неинтегрируемых и не поддерживающих предприятие должным образом систем, которые к тому же весьма дорого заменять.
Баланс между сущностью реализации отдельных ячеек и интегрированным взглядом на систему поддерживается моделью Захмана за счет того, что она:
· облегчает понимание и общение людей, имеющих разные роли в процессах создания, развития и использования системы;
· ясно определяет фокус внимания на (относительно) независимых параметрах для целей анализа;
· но в то же время обеспечивает поддержку контекстных взаимосвязей, важных для сохранения целостности системы.
Рассмотрим, как может использоваться подход, предложенный Захманом, на практике. Во-первых, данную модель удобно применять для классификации всей информации, описывающей предприятие и информационные системы этого предприятия, выявления "белых пятен" и координации работ. Во-вторых, данную модель можно использовать на метауровне – для сравнения различных реализаций создания архитектур предприятия. Наконец, она может являться удобным средством для использования в отдельных проектах. Например, в проекте по созданию корпоративного информационного портала необходимо определить элементы в строках 3-5 колонки 4 – соответственно, требования пользователей к представлению данных, интерфейсы и спецификацию по разграничению доступа с учетом существующих "унаследованных" компонент информационной системы. Эта существующая технологическая архитектура, в свою очередь, рассматривается в ячейке на пересечении четвертой строки и третьего столбца таблицы.
Нельзя, конечно, считать, что данная модель лишена недостатков. Один из них заключается в том, что при применении ее на практике возникают определенные трудности, связанные с отсутствием "встроенного механизма" распространения изменений между элементами таблицы. Действительно, предположим, что изменилась организация процесса поставок в компании (схема логистики). Это потребует отслеживания "вручную" всех взаимосвязей, проверки актуальности и внесения изменений в модели и другие артефакты во всех потенциально "затрагиваемых" ячейках.
Другим ограничением модели является отсутствие рассмотрения системы в динамике. Действительно, каждый элемент таблицы может содержать как описание существующего состояния ("как есть"), так и целевого, а также всех промежуточных состояний. При этом сама модель не содержит средств для четкого разделения этих различных "временных срезов".
Тем не менее, существуют специализированные продукты, такие как Popkin Software Architect, которые фактически основаны на модели Захмана и позволяют достаточно эффективно управлять созданием моделей и артефактов описания архитектуры предприятия.
Соответствующее обобщение подхода Захмана было предложено в работах Е.Б. Зиндера. Основная идея заключается в обеспечении возможностей отражения постоянного развития предприятия (и его информационных систем) как непрерывной последовательности трансформаций.
Вместо традиционной двумерной таблицы было предложено ввести трехмерную схему, добавив к плоским схемам ось стратегического времени. На этой оси располагаются отрезки времени осуществления различных проектов и стадий развития информационных систем и всего предприятия.
Таким образом, была создана "объемная" схема архитектуры предприятия или модель "3D-предприятие", которая строится в трех измерениях с учетом временного пространства.
При этом, по предложению автора данной работы, первые два измерения аналогичны тем, которые использовал Захманом, но не совпадают с оригиналом полностью по содержанию и трактовке. Третья ось позволяет явно определять те изменения, которые происходили и будут происходить с предприятием, его существующими информационными системами, а также с различными проектами развития и трансформации.
Стоит отметить, что предложенный вариант развития исходного подхода Захмана не является единственно возможным. Существует большое количество модельных схем, которые в той или иной мере используют данный подход, хотя визуальное представление модели в целом может достаточно сильно отличаться. Одним из таких примеров может служить предложенная Институтом разработок архитектуры предприятия модель Extended Enterprise Architecture Framework (E2AF). Эта модель содержит 4 области рассмотрения (бизнес, информация, информационная система, технологическая инфраструктура) и следующие 6 уровней абстракции:
· контекстуальный (Зачем?)
· уровень взаимодействия (с Кем?)
· концептуальный (Что?)
· логический (Как?)
· физический (с помощью Чего?)
· трансформационный (Когда?)
Другой пример – это так называемая модель 4-доменной архитектуры (Four Domains architecture, FDA), в которой предлагается, в частности, провести как бы условное разбиение ячеек исходной модели Захмана на 2 компоненты – архитектуру описания (Architecture-in-Design) и архитектуру исполнения (Architecture-in-Operation). При этом первая компонента описывает ход, средства и артефакты процесса разработки архитектуры предприятия, в то время как вторая предназначена для описания непосредственно бизнес-процессов и реализации ИТ-систем.
Методика META Group
Подробное описание методики разработки архитектуры предприятия META Group содержится в документе Enterprise Architecture Desk Reference объемом около 380 страниц, который предоставлялся клиентам компании. Остановимся на самых главных моментах этой безусловно интересной методики, доступных в открытых материалах.
По мнению META Group, "архитектура является одновременно некоторым структурированным описанием информационных технологий предприятия и его информационных технологий (т.е. конечным результатом, включающим определенные артефакты- стандарты, утверждения, касающиеся общего видения, архитектурные документы), процессом создания и обновления артефактов архитектуры и группами людей, вовлеченных в этот процесс". Соответственно этим представлениям методика компании уделяет достаточно подробное внимание всем трем составляющим архитектуры. При этом отличительной особенностью методики META является более детальное и формализованное описание именно процесса разработки архитектуры и всех его составляющих.
Исторически архитектурная методика META Group оперировала таким понятием, как Технологическая архитектура масштаба предприятия (EWTA – Enterprisewide Technical Architecture). Однако по мере того, как в индустрии происходило понимание более тесной связи между бизнесом и информационными технологиями, в представления (домены или предметные области) архитектуры предприятия META Group были добавлены такие домены, как Бизнес-архитектура (EBA – Enterprise Business Architecture), Архитектура информации (EAI – Enterprise Information Architecture) и Портфель прикладных систем предприятия (EAP – Enterprise Application Portfolio).
Кроме того, расширяя многие другие представления, архитектурная методика META Group рассматривает архитектуру предприятия в интеграции с другими ключевыми процессами, в частности, с процессом управления корпоративными ИТ-программами и проектами (EPM – Enterprise Program Management) и процессом выработки стратегии и планирования. В частности, отмечается, что архитектура, собственно говоря, и реализуется на практике через процесс управления ИТ-программами и проектами.
Объединяющим для всех доменов архитектуры META Group является процесс формулировки бизнес-требований к ИТ-архитектуре, что оформляется в виде двух документов: Видения общих требований (CRV – Common requirements Vision) и Принципах концептуальной архитектуры (CA – Conceptual Architecture).
Рис. 2.5. Аналитическая работа и компоненты Архитектуры предприятия
Организация рабочего процесса разработки архитектуры и быстрое создание начальной версии архитектуры предприятия, согласно META Group, состоит в прохождении следующих этапов.
На этапе 1 разрабатывается Видение общих требований. Разработка Видения общих требований включает в себя:
· анализ тенденций развития внешней для предприятия среды, включая технологические тенденции;
· бизнес-стратегии и основные движущие силы с точки зрения бизнеса;
· требования к информационным системам со стороны бизнеса;
· требования к технологической архитектуре, которая обеспечивает адекватные возможности для информационных систем с точки зрения потребностей бизнеса.
Этап 2 состоит в разработке Концептуальной архитектуры, которая определяет логически связанный набор принципов, обеспечивающий общее руководство для развития информационных систем предприятия и технологической инфраструктуры. На этом же этапе параллельно ведется разработка наиболее приоритетных доменов архитектуры. Здесь же выполняется анализ на несоответствие (gap-анализ) между текущим и желаемым состоянием архитектуры.
Этап 3 состоит в разработке плана реализации, обеспечивающего миграцию в сторону желаемого состояния архитектуры.
При этом данная методика предлагает формализованные шаблоны, обеспечивающие разработку Видения общих требований и Концептуальной архитектуры.
Рекомендация относительно Видения общих требований состоит в том, что этот документ не должен обязательно быть исключительно точным и всеобъемлющим с точки зрения анализа бизнес-стратегии. Главное – это совместное участие представителей бизнес-подразделений и ИТ в выработке общего понимания набора требований, согласованных со стратегическим направлением развития компании. Размер этого документа может быть 10-15 страниц. Основное содержание документа может состоять из четких утверждений, которые тематически связаны между собой, например, так, как показано в таблице 2.2.
Таблица 2.2. Пример компоненты Видения общих требований
| Тенденция | Бизнес-стратегия предприятия | Требования к информационным системам | Требования к архитектуре |
| Задержки в предоставлении услуги затрагивают 20% клиентов | Процесс обслуживания, уменьшающий ожидание клиента, приведет к увеличению доли рынка | Информация о заказах, независимо от канала и места их получения, должна немедленно передаваться в производство | ИТ-инфраструктура должна обеспечивать управляемый доступ и своевременную передачу информации, чтобы обеспечить операционную эффективность |
Важный аспект заключается в документировании явных связей между бизнес-стратегией (потребностями бизнеса) и требованиями к информационным системам и, в конечном итоге, установления логических связей с требованиями к технологической архитектуре. Для этого рекомендуется использовать простые матрицы так, как это показано на рис. 2.6. Документированные связи послужат основой для будущих решений об инвестициях.
Рис. 2.6. Матрица связей между бизнес-стратегиями, требованиями к информационным системам и технологической архитектуре
Таким образом, результатом первого этапа работ могут быть четыре документа:
· список ключевых технологических тенденций;
· список бизнес-стратегий;
· список требований к информационным системам;
· список требований к технологической архитектуре.
Видение общих требований агрегирует все требования к технологической архитектуре, и это служит основой для формулировки принципов Концептуальной архитектуры. В свою очередь, эти принципы обеспечивают общие руководства в использовании, разработке различных информационных систем и инфраструктуры в различных технологических областях.
Концептуальная архитектура разрабатывается еще до создания других архитектурных доменов и основана на принципах, которые имеют несколько общих характеристик:
· принципы представляют собой содержательные утверждения, которые касаются архитектурного процесса или содержания архитектуры;
· принципы являются ограниченным числом точек стабильности, на которых строится архитектура;
· принципы должны быть утверждениями, чья справедливость для организации носит "вечный" характер, поскольку они задают систему ценностей для архитектуры в целом.
Мы уже отмечали, что в соответствии с методикой META Group результатом разработки принципов концептуальной архитектуры является выделение в технологической архитектуре (EWTA) набора доменов (предметных областей), которые объединяют группы связанных между собой технологий и компонент. При этом, как отмечалось в лекции 7, можно выделить два различных типа доменов технологической архитектуры: базовые (технологии, которые используются практически каждой информационной системой: сети, аппаратное обеспечение, операционные системы, системы хранения, программное обеспечение промежуточного слоя, системы управления базами данных, технологии системного управления ИТ-ресурсами в распределенной среде, архитектура безопасности) и прикладные (более специфические с точки зрения использования бизнесом технологии: системы коллективной работы, электронной почты и управления потоками работ (workflow), Интранет, Интернет-приложения, системы электронной коммерции, архитектура хранилищ данных, специализированное аппаратное обеспечение).
Каждый домен технологической архитектуры включает описание принципов, технологий, стандартов, продуктов, конфигураций, лучших практик, которые являются многократно используемыми строительными блоками при построении ИТ-систем.
На рисунке 2.7 приведена структура описания каждого домена технологической архитектуры предприятия, согласно META Group.
Рис. 2.7. Структура описания доменов технологической архитектуры
Таким образом, документ, описывающий каждый домен технологической архитектуры, включает следующие компоненты:
· Формулировка миссии домена: стратегические цели домена.
· Описание компонентов домена: это обеспечивает общее понимание включенных в домен технологий.
· Принципы проектирования, принятые в домене. Они определяют правила, применяемые в процессе принятия решений в отношении технологий домена, а также обоснования и последствия принятия этих принципов. Здесь могут быть построены матрицы соответствия между требованиями к технологической архитектуре (RTA), сформулированные в процессе создания Видения общих требований, и принципов проектирования, принятых для конкретного домена.
· Стандарты: продукты и технические стандарты, которые обеспечивают требования к технологической архитектуре. Выделяют стратегические (предпочтительные) стандарты, переходные (которые используются временно), устаревшие (которые, возможно, еще используются, но от которых организация отказывается) и исследовательские или новые (которые находятся только на этапе рассмотрения и апробации).
· Лучшие практики.
· Конфигурации. Они формулируются в тех случаях, когда нужно уменьшить сложность принятия решений или когда можно уменьшить общую стоимость владения за счет стандартных конфигураций.
· Несоответствия между существующим состоянием домена технологической архитектуры и желаемым состоянием. Это служит основой для последующих работ группы, которая отвечает за данный домен архитектуры.
Взгляд на технологическую архитектуру с точки зрения предоставляемых ею инфраструктурных сервисов обусловлен распространением принципов сервис-ориентированной архитектуры. Это связано с описанием, например, сервисов презентации информации (порталы, настольные системы и пр.), сетевыми сервисами (LAN, WAN, удаленный доступ), сервисами безопасности (управление пользователями, доступ), сервисами хранения данных (SAN – Storage Area Network, файловые системы), сервисами баз данных (OLTP), интеграционными сервисами, платформенными сервисами, которые используются прикладными системами.
При этом архитектурные домены, шаблоны и сервисы обеспечивают наращивание уровней адаптируемости технологий предприятия:
· Домены архитектуры – первый уровень адаптируемости технологий. Категоризация помогает предприятиям обнаруживать излишние технологии, продукты и конфигурации, а также позволяет идентифицировать возможности многократного использования элементов технологической архитектуры.
· Шаблоны – второй уровень адаптируемости технологий. Позволяют разработчикам использовать одни и те же конфигурации технологий для решения похожих задач.
· Сервисы – третий уровень адаптируемости технологий. Они обеспечивают общие интерфейсы для разработчиков прикладных систем и интеграторов приложений в рамках всей инфраструктуры предприятия.
При этом выделяется четыре группы сервисов по мере повышения уровня абстракции:
· Базовые инфраструктурные сервисы: общие, стандартные технологии, широко используемые в рамках всех ИТ-систем предприятия. Они ориентированы не на разработчиков прикладных систем, а на специалистов по инфраструктуре. Примерами являются ПО пересылки сообщений промежуточного слоя, мониторы транзакций, сервисы каталогов.
· Общие (framework) инфраструктурные сервисы: общие, совместно используемые технологии, которые не содержат готовой бизнес-логики (хотя она и может быть запрограммирована), ориентированы на разработчиков и могут быть не полностью стандартизированы. Примерами таких сервисов являются управление контентом, серверы приложений, серверы выполнения бизнес-правил.
· Общие (framework) бизнес-сервисы: могут быть использованы в рамках различных бизнес-процессов, поскольку они содержат готовую, предопределенную бизнес-логику. Примерами таких сервисов являются модули определения цены товара, модули персонализации информации, модули оценки кредитного рейтинга.
· Прикладные бизнес-сервисы: специфические для отдельных бизнес-процессов, содержат высокоуровневую бизнес-логику. Например, сервисы CRM-систем или систем управления поставками.
В результате получается технологическая модель предприятия, представленная на рис. 8.8.
Рис. 2.8. Технологическая модель предприятия
В полном описании методики META Group приводятся также следующие аспекты:
· практическая реализация архитектуры через процесс управления корпоративными ИТ-программами и проектами;
· вопросы управления и контроля архитектурного процесса (governance);
· оценка зрелости архитектуры;
· анализ технологических тенденций и планирование;
· управление портфелем ИТ-активов и проектов.
Методика TOGAF
Методика описания архитектуры TOGAF (сокращение от The Open Group Architecture Framework) была предложена некоммерческим объединением The Open Group, в которое входит ряд ведущих производителей информационных технологий, а также компаний из списка Fortune 1000. TOGAF позиционируется ее авторами не как некоторая эталонная модель, а как "средство для разработки архитектур информационных систем". Основное назначение – ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития. В декабре 2003 года была опубликована версия 8.1 этой модели.
Основным полем для применения TOGAF является, прежде всего, программная инфраструктура информационной системы (в противоположность таким типам архитектур, как бизнес-архитектура, архитектура данных и приложений). Таким образом, она в наилучшей мере подходит для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего, критичных для бизнеса (mission-critical). Поскольку эта интеграционная архитектура сильно зависит от принимаемых решений в остальных областях, то в рамках TOGAF в необходимой степени рассматриваются и эти смежные области.
В состав модели TOGAF входят две основные компоненты – методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Заметим, что в описании TOGAF добавлен специальный документ, поясняющий соответствие между понятиями TOGAF и моделью Захмана.
Общая структура TOGAF показана на рис. 2.9.
Рис. 2.9. Структура TOGAF
Важно отметить, что TOGAF распространяется свободно и может быть использована бесплатно любой организацией для разработки внутренних проектов. Лицензируется только коммерческое использование.
В соответствии с методикой ADM, процесс разработки архитектуры включает следующие фазы:
· Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта.
· Фаза A: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством.
· Фаза B: разработка бизнес-архитектуры предприятия.
· Фаза C: разработка архитектуры данных и архитектуры приложений.
· Фаза D: разработка технологической архитектуры.
· Фаза E: проверка возможности реализации предложенных решений.
· Фаза F: планирование перехода к новой системе.
· Фаза G: формирование системы управления преобразованиями.
· Фаза H: управление изменением архитектуры.
Каждая фаза, в свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее. Например, фаза D включает следующие основные подпроцессы:
· Описание существующей технологической архитектуры.
o Обзор бизнес-архитектуры, архитектуры данных и приложений для определения начальных данных и необходимой степени детализации.
o Описание существующей системы с необходимой степенью детализации, которая выбирается для того, чтобы можно было выявить необходимые изменения при формировании целевой архитектуры. Формирование реестра используемых платформ программного и аппаратного обеспечения.
o Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах.
o Разработка черновика технического отчета, резюмирующего основные результаты изучения существующего состояния и возможности использования типовых блоков.
o Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок.
· Формирование целевой технологической архитектуры.
o Описание существующей системы в терминах TOGAF.
o Определение перспектив (представлений) архитектуры.
o Формирование модели целевой архитектуры.
o Определение ИТ-служб (сервисов).
o Подтверждение учета бизнес-требований.
o Определение архитектуры и используемых блоков (шаблонов).
o Проведение анализа расхождений (gap analysis).
Для каждого такого подпроцесса определяются решаемые в его ходе задачи, входные и выходные документы. Важно отметить, что процесс предусматривает не обязательную, но возможную адаптацию самого метода к условиям конкретного предприятия, которая осуществляется на предварительной фазе. Это может быть вызвано как необходимостью учета других существующих стандартов предприятия, так и привлечением аутсорсинговых компаний к разработке архитектуры. Интересным примером может являться проект внедрения корпоративной ERP-системы. В этом случае необходимо определенное изменение порядка разработки – так, бизнес-архитектура в этом случае может определяться возможностями, поддерживаемыми в выбранном продукте, поэтому фазы B и С в данном случае будут выполняться не до, а после фазы D!
Процесс разработки не заканчивается после выбора оптимальной архитектуры и разработки плана миграции. Необходимыми элементами являются задачи, выполняемые на фазах G и H. В частности, для обеспечения практического принятия архитектуры в организации и успеха проекта обязательным является формирование Системы управления реализацией архитектуры (Implementation Governance). Так, фаза G предусматривает следующие задачи:
· Организация Совета по архитектуре, включающего представителей всех бизнес-подразделений и руководства. Этот Совет должен выполнять наблюдательную и координирующую роль.
· Разработка конкретной реализации достаточно полного набора Архитектурных принципов на основе существующего шаблона (см. ниже).
· Формирование Стратегии Соответствия Архитектуре, определяющей правила и рекомендации для оценки и выбора проектов в части их соответствия или несоответствия согласованной архитектуре, а также формальную процедуру проверки такого соответствия. Это похоже на жизненный цикл технологических стандартов германской архитектуры электронного правительства SAGA, и на правила использования стандартов: проект, который не полностью удовлетворяет всем обязательным стандартам, не может получить бюджетного финансирования.
Базовая Архитектура, в свою очередь, включает:
· набор наиболее общих служб и функций, объединенных в Техническую Эталонную Модель (Technical reference model – TRM);
· набор элементарных архитектурных элементов, которые используются как "строительные блоки" при построении конкретных решений;
· база данных стандартов (Standards Information Base).
Концепция использования Базовой архитектуры определяется в соответствии с иерархией архитектур (см рис. 2.10) входящих в общий континуум определений.
В этом смысле компонента Базовой Архитектуры, содержащая набор служб и стандартов, является некоторой абстрактной реализацией ИТ-системы в целом. Архитектура Общих Систем реализуется путем выбора и интеграции определенных служб для формирования выделенных блоков, которые могут (возможно, повторно или в различных комбинациях) использоваться в различных функциональных областях, таких как архитектура безопасности, сетевая архитектура и т.п.
Следующая степень детализации реализуется на уровне Отраслевой Архитектуры, которая добавляет специфичные для каждой индустрии модели данных, приложения, стандарты, бизнес-правила, а также, при необходимости, процедуры взаимодействия различных отраслевых систем между собой. Наконец, на последнем уровне Архитектуры Организации формируется архитектура ИТ-систем конкретного предприятия, учитывающая все его особенности, в том числе наличие унаследованных систем, планы и возможности реализации, организацию данных на физическом уровне и т.п.
Рис. 2.10. Иерархия описаний архитектур
В состав Эталонной Модели, в свою очередь, входит система (таксономия) общих служб, включающая такие службы, как Обмен и преобразование данных, Управление данными, Поддержка интернационализации, Службы Каталогов и т.п.
Для всех используемых в архитектуре служб, наряду с функциональным назначением, необходимо определить и уровень качества реализации, то есть такие характеристики как управляемость, гибкость, гарантированность, удобство использования и т.п. При этом следует учитывать, что некоторые службы являются в этом плане взаимозависимыми. Например, для обеспечения заданного качества службы интернационализации могут потребоваться специализированные компоненты службы разработки программного обеспечения для создания и тестирования соответствующих программных продуктов.
Архитектурные принципы представляют собой как бы фундаментальные "аксиомы", которые используются в качестве "отправных точек" как для оценки существующей системы, так и для разработки отдельных архитектурных решений. Вообще говоря, архитектурные принципы являются подмножеством более общего понятия ИТ-принципов, которые определяют основные аспекты всей деятельности, связанной с применением информационных технологий. ИТ-принципы, в свою очередь, являются детализацией еще "более общих" принципов, определяющих деятельность предприятия в целом.
В состав набора принципов могут входить обоснования для формирования системы требований или критериев оценки тех или иных решений. Например, такой принцип, как "минимизация числа поставщиков программного обеспечения", может быть в дальнейшем конкретизирован в зависимости от особенностей предприятия, как требование "единой СУБД для всех критичных для бизнеса приложений" или же как "использование той же СУБД, что и уже применяемая". Архитектурные принципы могут также использоваться для обоснования значимости самого понятия Архитектуры и необходимости ее разработки для бизнеса предприятия, а также для выбора вариантов реализации этого процесса.
Принципы являются взаимозависимыми и должны применяться в целостном наборе. "Хороший" набор принципов должен удовлетворять таким естественным критериям, как доступность для понимания, точность формулировок, полнота, последовательность и стабильность (не нужно путать с неизменяемостью!) Обычно число принципов не превышает 20, чтобы не ограничивать гибкость архитектуры или чтобы избежать чисто формального определения принципов, которые неработоспособны на практике.
Примерный набор принципов может включать, в частности, следующие:
Таблица 2.3.
Примеры принципов, используемых при создании архитектуры (TOGAF)
| Название | Содержание |
| Примат использования | Сформулированные принципы управления ИТ применимы для всех случаев и подразделений организации |
| Максимальная польза | Решения в области ИТ принимаются исходя из максимума пользы для организации в целом |
| Привлечение всех | Управление информацией есть дело каждого |
| Непрерывность бизнеса | Деятельность предприятия должна обеспечиваться, несмотря на возможные помехи в работе ИТ |
| Общее использование | Предпочтение должно отдаваться разработке или внедрению приложений, применимых в масштабах всего предприятия, а не отдельных его подразделений |
| Соответствие законодательству | Управление ИТ не должно противоречить применяемому законодательству и принятым регламентам, однако это не есть препятствие к улучшению бизнес-процессов, влекущему за собой изменение этих регламентов |
| Ответственность ИТ-службы | ИТ-служба является ответственным владельцем ИТ-ресурсов и исполнителем процессов для удовлетворения требований бизнеса |
| Защита интеллектуальной собственности | Обеспечение защиты интеллектуальной собственности организации должно быть реализовано на уровне архитектуры, процессов эксплуатации и управления ИТ |
| Данные являются активом | Данные в ИТ-системе предприятия имеют определенную ценность и должны соответственно управляться, быть общими и доступными для пользователей с учетом их прав доступа |
| Обеспечение качества | Каждый элемент данных должен иметь ответственного за качество |
| Общие метаданные | Метаданные должны быть едиными в рамках предприятия и доступными для всех пользователей |
| Безопасность данных | Данные должны быть защищены от неавторизованного использования и распространения |
| Технологическая независимость | Прикладное ПО не должно зависеть от специфичных моделей оборудования и системного ПО |
| Простота использования | Приложения позволяют сконцентрироваться на выполнении бизнес-задач за счет единого интерфейса, минимизации специфики работы, интеграции систем, снижения вероятности неправильного использования |
| Обоснованность и своевременность изменений | Изменения в информационной системе и приложениях производятся только в соответствии с запросами бизнеса, но в случае появления такой необходимости – в нужное время |
| Взаимодействие | Компоненты программного и аппаратного обеспечения должны обеспечивать интеграцию между собой в соответствии с общими стандартами |
| Минимизация разнообразия | Уменьшение числа различных вариантов применяемых платформ, продуктов и версий |
Набор шаблонов IT Architecture Toolkit, разработанный американской ассоциацией CIO, первоначально позиционировался как специализированное средство для документирования ИТ-архитектуры организации. Основное преимущество его использования заключается в построении иерархической системы описаний элементов, удобной для поддержания жизненного цикла документа, т.е. в форме, предполагающей его возможные изменения в будущем по мере изменения требований бизнеса и совершенствования технологий. Однако в версии 3.0, опубликованной в октябре 2004 года, предмет его рассмотрения уже охватывает и область бизнес-архитектуры, так что он может рассматриваться наряду с другими универсальными рамочными моделями. Другим весьма полезным обстоятельством является большое количество реальных примеров из практики отдельных американских штатов и федеральных организаций.
Для наших целей сравнительного анализа интересно проследить эволюцию данного подхода, поэтому вначале мы рассмотрим основные идеи, заложенные в версию 2.0. В этой версии структурная схема этой методики включала в себя пять уровней:
· области или домены (Domains) ИТ-архитектуры;
· дисциплины;
· технологические дисциплины;
· продуктовые компоненты;
· документы соответствия.
Области (домены) являются логическими блоками технологической архитектуры. Каждая Область может включать одну и более дисциплин. Вся ИТ-архитектура подразделялась на набор областей верхнего уровня (доменов), описывающих отдельные аспекты ИТ-систем. В составе списка доменов предлагалось выделять такие области, как:
· управление приложениями;
· управление данными;
· управление информацией;
· интеграция;
· управление пользователями и доступ;
· сети и коммуникации;
· платформы;
· управление системами;
· информационная безопасность и т.п.
Дисциплины обеспечивают логическое деление доменов на разделы, которыми уже проще управлять, т.е. домены включают в себя несколько функциональных дисциплин. Дисциплины представляют собой достаточно связанные единицы в рамках соответствующей предметной области. Каждая дисциплина содержит одну и более Технологических дисциплин.
Например, в домен Управление системами входят, в том числе, следующие дисциплины:
· Управление активами (Asset management).
· Управление изменениями (Change management).
· Управление событиями (Event Management).
· Поддержка пользователей (HelpDesk).
· Обеспечение непрерывности бизнеса (Business continuity) и др.
Технологические дисциплины – это технические дисциплины, которые поддерживают функциональные технологические разделы архитектуры. В качестве примера (см. табл. 2.3 ниже) можно привести Дисциплину "Управление данными" (Data Management), которая является частью Области "Информация". Дисциплина "Управление Данными" может включать в себя такие Технологические Области, как:
· реляционные СУБД;
· плоские файловые системы;
· настольные базы данных;
· модели данных.
Каждая из этих технологических областей включает свои продукты, протоколы и связанные с ними конфигурации. Это детализируется на уровне "Продуктовые компоненты". С указанного уровня начинаются технические детали технологической архитектуры.
Продуктовые компоненты включают протоколы, продукты (семейства продуктов) и конфигурации, которые специфичны для каждой технологической области. Примерами Продуктовых Компонент, которые могут быть идентифицированы в рамках технологической области "Модели Данных", являются такие продукты, как ERWin, Visio и Designer 2000. Документация для каждой компоненты включает оценочные критерии, которые были использованы для включения продуктовой компоненты в общую технологическую архитектуру.
Документы Соответствия определяют руководства, стандарты и регулирующие документы, которые связаны с Дисциплинами, Технологическими дисциплинами и/или Продуктовыми компонентами. Они предписывают необходимость соблюдения тех или иных международных рекомендаций (RFC), стандартов, законодательных актов – например, по применению сертифицированных средств ЭЦП, внутренних инструкций и т.п.
Документы соответствия могут присутствовать на каждом из этих уровней и обеспечивают основу для принятия важных решений о новых продуктах, протоколах, конфигурациях и т.д.
Для элементов описания архитектуры в документе определяется следующее:
Таблица 2.1
Элементы описания архитектуры
| Область (домен) | Описание, область охвата, входящие функциональные области, принципы, лучшие практики, тренды |
| Дисциплина | Описание, область охвата, ссылка на Домен, кросс-ссылки на другие функциональные области, методологии, Технологические Области, требования к документированию |
| Технологическая дисциплина | Описание, ссылка на функциональную область, обоснование выбора единственного или множественных продуктов (вендоров, приложений) |
| Продукты/приложения | Описание, ссылка на Технологическую область, информация о вендоре, классификация, условия использования, политика миграции |
Важным преимуществом такого подхода является возможность представления всего описания архитектуры в виде единой (гипертекстовой) базы данных, что позволяет эффективно организовать процессы управления жизненным циклом отдельных документов (см. ниже), а также эффективно разграничить права доступа к отдельным разделам (например, документам, описывающим применяемые средства защиты информации) при сохранении целостности и единства описания. Пример приведен в табл. 2.2.
Таблица 2.2.
Пример иерархии описания архитектуры в соответствии с рекомендациями NASCIO
| Область (Домен) | Дисциплина | Технологическая дисциплина | Продуктовые компоненты | Документы Соответствия |
| Информация | Управление Данными | реляционные СУБД | MS SQL Oracle DB2 | стандарты предприятия на именование хранимых процедур |
| плоские файловые системы | квоты на использование общего дискового пространства | |||
| настольные БД | MS Access | стандарты предприятия по защите БД Access | ||
| модели Данных | ERWin MS Visio Designer 2000 | нормализация данных стандарты предприятия на именования таблиц и атрибутов |
В таблице 2.3 дан пример модели технологической архитектуры, включающей в себя девять Областей, которые, в свою очередь, разбиты на 26 технических функциональных элементов или Дисциплин. Каждая организация должна определять свой набор технических дисциплин в зависимости от потребностей, но приведенный пример может служить отправной точкой.
Таблица 2.3.
Области и Дисциплины
| Область | Дисциплины |
| Информация |
|
| Приложения |
|
| Интеграция |
|
| Доступ |
|
| Сеть |
|
| Платформа |
|
| Системное Управление |
|
| Частная информация |
|
| Безопасность |
|
В версии 3.0 набор включает в себя как процесс управления ИТ (IT Governance), так и следующие 4 взаимосвязанные архитектуры:
· бизнес-архитектуру;
· архитектуру информации;
· технологическую архитектуру (практически соответствует всей ИТ-архитектуре, рассмотренной в версии 2);
· архитектуру решений (Solution Architecture), поэтому структура модели частично изменилась.
В частности, в составе собственно бизнес-архитектуры предлагается выделить несколько бизнес-областей (доменов). Это разделение может производиться как по функциональному (например, образование /здравоохранение /социальное обеспечение), так и по некоторому "тематическому" признаку (например; услуги гражданам/взаимодействие с другими органами власти/внутренние процессы) или географическому признаку. В составе этих бизнес-доменов выделяются отдельные архитектурные компоненты, рассмотрение которых может вестись с различных "перспектив", соответствующих столбцам в модели Захмана и с фокусом на двух верхних уровнях (строках) этой модели. В руководстве указывается на возможную целесообразность объединения таких перспектив, как "Кто?" и "Зачем?", вообще говоря, различных с точки зрения модели Захмана, в одну общую – "Стратегический бизнес". Важно отметить, что одни и те же выбранные перспективы должны будут применяться ко всем бизнес-областям.
Для каждой бизнес-области в описании определяются существенные принципы, лучшие практики и существующие тенденции. Далее, в составе бизнес-области формируются подчиненные документы, описывающие ее компоненты, которые фактически соответствуют отдельным ячейкам в верхних двух уровнях модели Захмана. Таким образом, в состав компонент могут входить, например, описание ролей (должностей) и их ответственности в организации, важные с точки зрения предприятия события и циклы деятельности, расположения офисов и т.п. Важным атрибутом описания является индикация типа состояния компоненты, т.е. относится ли это описание к существующему или целевому состоянию. Здесь прослеживается некая аналогия с подходом группы Зиндера и выделением "стратегического времени", хотя и в ограниченной интерпретации из всего двух состояний.
Специальным типом компоненты являет так называемая Gap-компонента, которая описывает существующие расхождения между текущим и целевым состоянием. Эти компоненты не случайно выделены в отдельный тип, поскольку одна и та же "причина", такая, например, как используемая устаревшая технология доступа к данным, может оказывать влияние на целый ряд основных компонент, в том числе из различных функциональных или тематических бизнес-областей. Описания этих основных компонент и описания gap-компоненты дополняются соответствующими кросс-ссылками, позволяющими осуществлять необходимую навигацию.
Представленный ранее в предыдущей версии руководства в рамках общей ИТ-архитектуры домен "Информация" в новой версии выделен в отдельную архитектуру информации. В ее составе определяются следующие элементы:
· основные информационные сущности (information subject areas), такие как, например, Гражданин/Услуга/Платеж, которые специфичны для деятельности данной организации;
· процессы обработки информации, описывающие, в частности, каким образом, кем и в каком порядке используется, например, сущность "Гражданин";
· метаданные, определяющие, какова логическая и физическая структуры данных, существующие или целевые бизнес-правила, уровень конфиденциальности, кто является владельцем/ответственным за качество и т.п. для данной сущности.
Кроме того, как и в случае бизнес-архитектуры, здесь явно выделяются Gap-компоненты.
Новым понятием, которое требует некоторого комментария, является архитектура решений. В данном контексте под ней понимается "процесс в рамках общей архитектуры предприятия, который фокусируется на создании сервиса или решения в интересах всей организации". Фактически эта область во многом соответствует понятию слоя шаблонов из модели Gartner, которая рассматривалась выше.
В отличие от остальных архитектур, описания элементов архитектуры решений не содержат такого признака, как "существующий" или "целевой". Фактически, все эти "решения" относятся как раз к стадии перехода от существующего состояния к целевому , так что по завершении соответствующего проекта они сохраняются со статусом "архивный".
Для описания конкретного решения используются три типа шаблонов:
· "обзор" (scope) – определяет область проекта, цели и подход;
· "требования" – содержит формализованные требования к решению, сгруппированные по типу, т.е. бизнес-требования, функциональные, по безопасности и т.п. В этой части организация шаблона схожа с разделом отечественного стандарта ГОСТ 34.698-90 "Техническое задание на АС";
· "дизайн" – документирует существенные элементы предложенного решения, включая явные ссылки на соответствующие требования и другие существующие элементы бизнес-архитектуры, архитектуры информации или технологической архитектуры.
Как уже отмечалось выше, наряду с описанием элементов архитектуры, в ходе процесса разработки определяется реализация применительно к конкретным особенностям предприятия стандартных процессов поддержки жизненного цикла архитектуры. К этим процессам относятся, в частности, такие:
· документирование;
· рецензирование;
· информирование;
· изменение;
· проверка соответствия;
· поддержка актуальности;
· организация и управление разработкой архитектуры, включая построение системы "IT Governance".
Диаграммы процессов строятся применительно к набору типовых предопределенных ролей (например, Рецензент, Документатор, Лидер и т.п.), которые присваиваются отдельным сотрудникам, должностям или подразделениям. Эти роли определяют права и ответственность данных участников процесса.
Модель "4+1" представления архитектуры
Достаточно важную роль в развитии подходов к описанию архитектуры предприятия сыграла модель "4+1" (точнее "The 4+1 View Model of Architecture"), которая была предложена Филиппом Кручтеном (Philippe Kruchten) из компании Rational еще в 1995 году. Данная методика позиционировалась, прежде всего, как способ описания архитектуры систем, основанных на активном использовании программного обеспечения, хотя идеи, заложенные в эту методику, могут использоваться и в более широком контексте архитектуры предприятия – что, собственно, и произошло на практике.
Рис. 2.11. Модель "4+1"
Модель предлагает простой и понятный способ описания архитектуры сложных систем, который состоит в использовании пяти различных категорий или представлений (views). Четырьмя основными представлениями в этой методике являются следующие:
· Логическое представление. Является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования).
· Процессное представление. Описывает вопросы параллельного исполнения и синхронизации процессов.
· Физическое представление. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы.
· Представление уровня разработки. Описывает статическую организацию программной системы в среде разработки.
Описание архитектуры системы на основе этих четырех представлений иллюстрируется и проходит проверку путем использования еще одного представления, которое содержит некоторые отобранные сценарии использования (use cases). Архитектура системы во многом определяется этими сценариями. Каждое представление отражает специфические аспекты моделируемой системы.
Основной целью логического представления в данной методике является описание функциональных требований: что система должна выполнять в терминах конечных пользователей. Для этого представления используются различные абстрактные конструкции, такие как объекты и классы объектов. Для их иллюстрирования могут применяться диаграммы классов (в нотации языка UML) либо, например, диаграммы "сущность-связь", если в разработке приложения доминируют данные.
Процессное представление учитывает некоторые нефункциональные требования к системе, включая производительность и доступность. С помощью этого представления рассматриваются такие аспекты, как одновременное выполнение и распределение процессов, интеграция системы, устойчивость к сбоям, а также то, как основные объекты абстракции, рассмотренные на уровне логического представления, соответствуют архитектуре процессов. Архитектура процессов может быть представлена на различных уровнях абстракции. На самом высоком уровне система рассматривается как набор независимо выполняемых сетей взаимодействующих между собой программ. На более низких уровнях рассматриваются процессы и задачи.
Представление уровня разработки описывает фактическую организацию модулей системы, разделение ее на подсистемы, которые могут разрабатываться независимо.
Физическое представление, в основном, рассматривает нефункциональные требования, такие как доступность, надежность, устойчивость, производительность, масштабируемость. Этот уровень описывает распределение различных элементов – сетей, процессов, задач и объектов – по различным узлам (элементам аппаратного обеспечения, объединенным в сеть).
Сценарии объединяют все представления вместе. Сценарии использования описываются как последовательность взаимодействия объектов и процессов. Они отражают наиболее важные требования, которым должна удовлетворять система. Это представление в каком-то смысле является избыточным и пересекается с четырьмя предыдущими, но оно важно по следующим причинам:
· Сценарии использования позволяют идентифицировать элементы архитектуры, которые требуются для эффективно работающей системы.
· С помощью сценариев можно выполнять проверку и иллюстрацию того, что архитектура является работоспособной и полной. Это также является основой для проведения тестирования архитектурного прототипа.
Рекомендации, касающиеся использования методик
В данном разделе мы приводим заключительные рекомендации, которые являются определенной компиляцией идей из рассмотренных выше описаний отдельных методик.
Во-первых, следует использовать доступные вам методики для создания собственной. Поскольку в области архитектуры предприятия пока отсутствует единый источник индустриальных стандартов, то можно использовать доступную информацию по остальным методикам для создания на их основе собственной. Хотя обратной стороной медали этого подхода является то, что результат будет уникальным для вашей организации, но при этом более существенными станут следующие положительные моменты:
· концепции и структуры описания архитектуры будут общими для многих других распространенных методик. Если вы решите использовать имеющиеся информационные ресурсы и распространенные в индустрии методики, то практически наверняка ваша концепция архитектуры, терминология, структуры и процессы будут в существенной степени повторять лучшие практики, содержащиеся в этих методиках. Это уменьшит время на обучение и облегчит взаимопонимание с другими специалистами;
· результат адаптации методики под нужды конкретной организации будет отражать характерные именно для вас моменты, связанные с культурой, уровнем поддержки работ над архитектурой со стороны руководства, уровнем финансирования и наличия необходимых людских ресурсов и поставленных сроков. В любом случае, процесс адаптации методик под специфичные нужды организации неизбежен и будет способствовать осознанному их применению.
Следующая рекомендация состоит в интеграции всего того лучшего, что имеется в методиках относительно управления и надзора за архитектурой (governance), выстраиванием процессов, принятием принципов и документов (моделей), описывающих архитектуру. Особенно важно изучить примеры моделей и документов (артефактов), описывающих архитектуру, поскольку именно они должны предъявляться в качестве практических результатов работы. Не следует рассматривать предлагаемый набор артефактов как догму, напротив, он может быть адаптирован под конкретные особенности. То есть приоритеты должны быть расставлены в соответствии с практическими потребностями в тех или иных элементах описания архитектуры, а не исходя из академической точности. Здесь более важна связь этих отобранных вами элементов описания архитектуры между собой, с методикой в целом, с процессами управления и контроля над архитектурой и процессом разработки прикладных систем.
Последнее замечание состоит в том, что не надо пытаться включить в ваш проект описания архитектуры больше, чем вы в реальности сможете реализовать. Даже краткое перечисление доступных методик, имеющееся в этом курсе, показывает, что проблема состоит скорее не в отсутствии информации на тему "Архитектура предприятия", а в ее переизбытке. Всегда возникает искушение задать слишком широкие рамки работы над созданием архитектуры – они превысят реальный уровень готовности организации и способность использовать результаты работы эффективно. Следует устоять против этого искушения и заняться определением только тех областей архитектуры, которые вы сможете использовать на практике по принципу "маленьких реальных побед".
Этап 3: Разработка Плана реализации
Этап 3 включает в себя следующие два шага:
· Стратегия миграции и планирование реализации. Целью данного шага является определение альтернатив, взаимозависимостей и усилий, необходимых для того, чтобы обеспечить выполнение технологических требований, идентифицированных на предыдущих этапах. Результатом этого шага станет набор проектов, рекомендуемых к реализации с точки зрения достижения желаемого состояния Архитектуры предприятия и Архитектуры отдельных предметных областей.
· Расстановка приоритетов в плане разработки и уточнения архитектур отдельных предметных областей. На этом шаге определяются стратегические потребности и необходимые усилия для проработки архитектур отдельных предметных областей, которые либо требуют уточнения, либо не были разработаны на предыдущих итерациях архитектурного процесса.
В крупной организации или, например, в региональном или городском масштабе государственного управления работа по разработке архитектуры должна выполняться на нескольких уровнях. На уровне предприятия или регионального (городского) правительства должны приниматься общие решения, обеспечивающие совместимость и взаимодействие информационных систем, а также вырабатываться другие общие требования и стандарты. На уровне отдельных крупных бизнес-подразделений или департаментов должны разрабатываться архитектуры информационных систем соответствующих структурных подразделений, оптимизированные с учетом их функций, но в рамках общих принципов, определенных в масштабе предприятия (региона, города) в целом.
Одним из результатов совместных усилий по разработке архитектур различных уровней должен быть список информационных подсистем и сервисов, которые носят общий, "горизонтальный" характер, таких как управление общими для предприятия информационными ресурсами и системами, общие системы идентификации и авторизации, общие системы контроля доступа к информационным ресурсам и т.д.
При организации архитектурного процесса может оказаться полезным использование упоминавшегося ранее стандарта IEEE 1471. Этот стандарт определяет рамочную модель, ориентированную на разработку комплексов с гарантированной надежностью, требуемой, например, в военных, космических и авиационных системах. Такая модель включает в рассмотрение понятия "участника" (stakeholder) и его представлений о целевой системе. На первый взгляд это может показаться тривиальным – ведь создание любой системы, в том числе и с использованием классических подходов, начинается со сбора, описания и анализа требований. Принципиальным в данном случае является признание того факта, что в подавляющем числе случаев на практике совокупность требований является, с одной стороны, неполной, а с другой – противоречивой.
Направления разработки архитектуры: "сверху-вниз" или "снизу-вверх"
В общем виде можно сказать, что существуют два принципиально различных подхода в разработке архитектуры предприятия:
· Подход "сверху-вниз" предполагает достаточно широкий охват проблем и точное следование формальному процессу. Основу этому подходу положили методики Захмана и Спивака. Он начинается со сбора информации, требующейся для описания различных доменов архитектуры "как есть". Далее следует этап, связанный с описанием и реинжинирингом бизнес-процессов, консолидации прикладных систем, выстраивание архитектуры данных и, наконец, стандартизация технологической архитектуры. Например, многие государственные проекты ориентированы на этот подход (например, в США в рамках Федеральной архитектуры FEAF).
· Подход "снизу-вверх", когда процесс начинается со стандартизации инфраструктурных технологий (технологическая архитектура), а затем развивается в направлении решения проблем более высокого уровня и, в конечном итоге, решает вопросы, связанные с бизнес-архитектурой. Этот подход, видимо, имеет более широкое распространение в бизнесе и в частном секторе.
Таблица 3.1.
Положительные и отрицательные аспекты различных подходов к разработке архитектуры предприятия
| Положительные аспекты | Отрицательные аспекты | |
| Сверху-вниз |
|
|
| Снизу-вверх |
|
|
В зависимости от ряда факторов, предпочтение отдается тому или иному подходу. Например, когда проект разработки архитектуры должен быстро показать отдачу, включая финансовую, или если разнообразие используемых в организации технологий явно приводит к падению качества ИТ-сервисов, то предпочтительным является подход "снизу-вверх". Организации, которым нужно решить с помощью архитектуры существенные проблемы, связанные с неэффективностью или большим количеством излишних бизнес-процессов или с наличием перегруженного набора прикладных систем, и которые готовы ждать как минимум год получения видимых результатов от разработки архитектуры, должны использовать подход "сверху-вниз". Наилучшим вариантом, однако, может стать гибридный подход. В любом случае, выбранная стратегия должна отвечать конкретным потребностям организации, и в любом случае, требуется поддержка со стороны высшего руководства и понимание того, что создание архитектуры – это долговременный процесс изменений.
Как всегда, в каждом варианте есть свои плюсы и минусы, которые кратко просуммированы в табл. 3.1.
Архитектура предприятия как планирование города
Большое количество авторов указывает на поразительную аналогию архитектурного процесса, связанного с использованием информационных технологий на достаточно крупном предприятии или в области государственного управления, и процесса архитектурного планирования города,. Мы думаем, что эта метафора будет небезынтересна читателям так же, как и предыдущее сравнение двух подходов "сверху-вниз" и "снизу-вверх" при организации работ над архитектурой.
Независимо от того, отвечаете ли вы за проект архитектуры предприятия в целом, или за внедрение отдельной CRM-системы, или за проект консолидации серверов – многому можно научиться, анализируя то, как современные города приспосабливаются под потребности своих жителей и потребности бизнеса. (Альтернативный взгляд: мы, как жители, приспосабливаемся под возможности города так же, как иногда приходится приспосабливаться под устаревший интерфейс прикладных систем). Заметим, что эта аналогия не оканчивается прямыми сравнениями типа город – совокупность ИТ-систем предприятия, здания – прикладные системы, городская инфраструктура – ИТ-инфраструктура. Много аналогий прослеживается в процессах планирования и развития города и планирования и развития ИТ-архитектуры.
Следует отметить, что сами концепции проектирования, управления и технологии, используемые при планировании города в целом и эксплуатации его инфраструктуры, отличаются от тех, которые используются при разработке архитектуры отдельного здания или комплекса зданий. Аналогично, принципы проектирования и технологии, которые используются для создания архитектуры информационных технологий предприятия в целом, их интеграции и эксплуатации, отличаются от тех, которые используются для создания отдельно работающей прикладной системы. Успех или неудача проекта разработки Архитектуры предприятия зависит от понимания этих отличий.
Если вы пройдетесь по Москве или Санкт-Петербургу, то увидите удивительное разнообразие зданий, построенных в разные эпохи: древние монастыри и Кремль Москвы, классический стиль зданий, построенных после пожара в Москве 1812 года или дворцов в Санкт-Петербурге, ампир и, наконец, современные бизнес-центры, не говоря уже о скучных спальных районах застройки 60-80-х годов прошлого века. Очевидно, что хотя подавляющее большинство зданий было построено в течение последних ста лет, но, тем не менее, заложенная веками ранее инфраструктура – основные улицы и мосты, некоторые архитектурные доминанты – до сих пор определяют то, как развиваются два этих города. Москва, например, не потеряла своей радиальной структуры, точно так же как и Санкт-Петербург – свои прямые проспекты. Очевидно, что люди, которые занимались все эти годы городским управлением, старались сохранять и в какой-то степени развивать оставленное им наследство и добавлять новые необходимые элементы.
Аналогично, на предприятии можно встретить информационные системы, о которых пользователи думают, что они были инсталлированы еще в средние века. Однако часто они работают и решают достаточно важные для предприятия задачи. В то же время департаменты ИТ всегда находятся под прессом необходимости – на основе сложившейся инфраструктуры и с учетом имеющегося набора прикладных систем создавать новые системы и интегрировать их между собой. Это непрерывное развитие ИТ-систем предприятия делает практически невозможной замену всех старых систем полностью – точно так же, как никому не придет в голову заменить радиальную структуру Москвы на параллельные и перпендикулярные проспекты, хотя при этом, возможно, в городе было бы меньше транспортных пробок. Таким образом, задача всегда состоит в том, чтобы сочетать жизненные циклы различных компонент ИТ-архитектуры предприятия так, чтобы архитектура в целом решала свои основные задачи.
В любом крупном городе одновременно воплощается большое количество проектов: строительство жилых и офисных зданий, дорог, другой инфраструктуры. При этом невозможно централизованно контролировать абсолютно все в мельчайших деталях. Поэтому возникает необходимость в наличии некоторого общего или генерального плана, который задает общее направление развития города, приоритеты, основные зоны городской застройки, требования коммунальных служб, оставляя принятие решений по поводу многих деталей, включая внутреннее устройство микрорайонов или зданий, на более низкий уровень управления. Однако ключевые городские ресурсы и системы при этом все равно планируются централизованно: основные магистрали, электростанции и пр.
Точно также при разработке архитектуры предприятия и его информационных систем часть общих систем и ресурсов (например, центры обработки данных, сетевая инфраструктура и многое другое) практически всегда планируется и эксплуатируется централизованно, но часть прикладных систем создается в рамках отдельных департаментов и отделов.
Генеральный план развития города – это всегда политический процесс. При его разработке и реализации затрагиваются интересы большого количества людей и организаций. План может накладывать определенные ограничения на возможности отдельных жителей и предприятий. План должен быть основан на общем видении развития города: стремится ли город интенсивно расти и быть центром деловой активности или, наоборот, необходимо ограничить рост (другой вопрос, есть ли ресурсы и предпосылки для роста). Но, так или иначе, в результате сложного политического процесса мы, чаще всего, имеем более или менее разумную и функционирующую городскую среду.
Аналогичным образом процесс планирования архитектуры информационных систем предприятия, а также реализация этой архитектуры являются во многом политическим процессом: всегда есть различные мнения по поводу приоритета проектов или необходимости использования тех или иных технологий. И надо заметить, что процесс управления и контроля развития информационных технологий предприятия (то, что по-английски называется governance) остается менее развитой и зрелой дисциплиной, чем планирование города.
Кроме того, прикладные системы, используемые в типичной организации, как правило, стали результатом работы различных групп разработчиков, приобретались у различных поставщиков и в разное время. Очень часто при создании этих систем разработчики не имели практически никакого представления об архитектуре других систем предприятия. Системы неизбежно различаются по своей внутренней архитектуре, форматам используемых данных; и, тем не менее, многие эти системы должны в какой-то степени работать совместно.
Такая ситуация аналогична проблемам городского планирования или организации работ, связанных с городской инфраструктурой. Общегородской план устанавливает некоторые общие правила на расположение, устройство и внешний вид микрорайонов и зданий: стандарты (размеры труб, напряжение в электросети, ширина дорог), сертификация (участие в строительстве только специально авторизованных компаний или использование сертифицированных материалов), управление (правила получения разрешений и пр.). Кроме того, городской план включает принципы использования общих ресурсов и сервисов, к которым отдельные здания могут быть подключены: водоснабжение и электричество, канализация и сбор мусора, телефоны, Интернет и кабельное телевидение.
Точно также при реализации информационных систем предприятия требуются как меры регулирования архитектуры отдельных систем (используемые технологии, протоколы, стандарты и т.д.), так и правила создания и использования общих сервисов, таких как электронная почта.
Планирование и обеспечение жизнедеятельности города требует четкого разделения труда: уровень города в целом, уровень отдельных городских зон и местные эксплуатирующие организации. Аналогично задача проектирования архитектуры предприятия в целом отличается от проектирования архитектуры отдельных систем, и отдельный вопрос – это эксплуатация систем.
Какие уроки можно извлечь из этой аналогии архитектуры информационных систем предприятия и городского планирования?
Первое: необходимость в наличии на предприятии единой архитектуры ИТ. В противном случае, ваш "электронный город" будет похож на хаотичную застройку Бангкока, где супер-небоскребы соседствуют буквально с курятниками.
Второе: помните о том, что разнообразие систем и платформ – это неизбежность для предприятия, так что интеграции нельзя достичь выбором единой платформы и технологии. У вас будет много "зданий" разных цветов и архитектуры. Думайте об архитектуре интеграции, которая основана не на единстве платформ, а на принципах сервис-ориентированной архитектуры.
Третье: при разработке архитектуры предприятия необходимо сбалансированно сочетать централизованные и децентрализованные методы планирования и управления. Неразумно и невозможно контролировать расположение комнат в каждой квартире или стоимость кусочка мыла в магазинчике за углом. Вы должны использовать принципы ограниченной автономии, характерные для управления городом, и дать возможность владельцам бизнес-процессов оптимизировать свои информационные системы при наличии разумного количества общих для предприятия ограничений.
Четвертое: важность стабильной инфраструктуры. Инфраструктура ИТ должна обслуживать текущие потребности и в какой-то степени предвосхищать будущие потребности в системах.
Пятое: планирование "различных зон ИТ", так же как планирование различных городских зон. Мы уже говорили, что различные типы бизнес-процессов и приложений (транзакционные, аналитические и т.д.), требуют различных технологий. Поэтому один из возможных путей развития ИТ на предприятии – это идентификация таких "зон" и возможность их относительно независимого развития.
Шестой вывод заключается в максимальном использовании того, что есть. Любой город старается по максимуму использовать ресурсы существующей инфраструктуры, прежде чем запускать новые дорогостоящие проекты ее обновления. Точно также большое количество имеющихся на предприятии унаследованных систем – это, скорее, актив, чем пассив, и его можно и нужно эффективно использовать. Функционал этих систем можно, в частности, "открыть" для интеграции с новыми прикладными системами, используя адаптеры и технологии web-сервисов.
Наверное, этот список аналогий и уроков можно продолжать достаточно долго. Надеемся, что читатели самостоятельно найдут много параллелей, навеянных этой аналогией между планированием города и развитием информационных систем своего предприятия.
С чего начать?
В самом начале проекта (процесса) разработки архитектуры организации очень часто стремятся как можно скорее выбрать одну из известных на рынке методик или создать на их основе свою собственную. Однако в действительности есть несколько "более первоочередных" моментов, важных для успеха проекта в целом:
· обоснование необходимости проекта и факторов, влияющих на разработку архитектуры;
· формирование команды проекта разработки архитектуры;
· определение границ архитектуры и используемых методик;
· формирование структур и процессов управления и контроля (governance) (этому посвящен особый раздел).
Примерная структура описания ИТ-архитектуры
Конечно, важно с самого начала определить формат и структуру описания архитектуры. Приведенный ниже в качестве примера формат документа может быть наиболее полезным, прежде всего, для малых и средних компаний и относительно несложных информационных систем.
Таблица 3.3
| Раздел | Описание |
| Резюме | Краткое содержание документа в бизнес-терминах, понятных руководству компании, включая обоснование необходимости проекта разработки архитектуры, примененный подход и основные результаты |
| Организация проекта | Цели и задачи проекта, участники разработки, планирование и состав работ. Критические факторы успеха проекта. Выбранная методология и средства описания архитектуры |
| Бизнес-требования и информация | На основании стратегии развития бизнеса формулируется список бизнес-требований, а также необходимая информация. Каждое из требований должно быть конкретным, измеримым и принципиально выполнимым |
| Связь бизнес- и ИТ-контекстов | Приводится список функций (сервисов) информационной системы и матрица соответствия между бизнес-требованиями и данными ИТ-сервисами |
| Существующее состояние | Приводится краткое описание существующего состояния архитектуры в целом и по доменам, формулируются существующие проблемы в обеспечении бизнес-функций, оценивается уровень подготовки пользователей и персонала |
| Целевое состояние системы | Краткое описание предполагаемого результата и вариантов реализации основных бизнес-процессов в будущем состоянии (так называемое видение архитектуры) |
| Концептуальная архитектура | Архитектурные (включая ИТ- и бизнес-архитектуру) требования и принципы, в том числе возможности использования технологических инноваций. Для каждого принципа приводится обоснование важности и прогнозируемые следствия применения. Формируется матрица корреляции между данными принципами и бизнес-требованиями, которая позволяет оценить относительную важность принципов |
| Описание доменов архитектуры | Приводится описание будущего состояния для доменов (областей), включая Данные, Приложения, Доступ, Инфраструктуру, Безопасность и т.п. Структура описания (число доменов), формат и степень детализации выбираются на основании компромисса между полнотой описания и доступными ресурсами проекта с учетом динамичности бизнеса организации |
| Анализ расхождений | На основании сравнения существующего и целевого состояния элементов архитектуры по доменам и с учетом рассмотренных в разделе концептуальной архитектуры общих и отраслевых тенденций делаются заключения о необходимости развития (сохранения, модификации, замены) тех или иных компонент архитектуры |
| Структурные преобразования | На основании сравнения существующей и целевой организации бизнеса делаются заключения о необходимости изменений в организационной структуре, ответственности и т.п. |
| Планирование преобразований | Приводятся бизнес-приоритеты, существующие ограничения по бюджетам и срокам реализации преобразований. Определяются используемые метрики и целевые показатели. Приводится анализ рисков при реализации или при отказе от реализации преобразований. Отмечаются специфические аспекты преобразований, связанные, например, с обучением персонала или конверсией данных |
| Управление архитектурным процессом | Здесь определяются необходимые организационные структуры и регламентные документы для управления жизненным циклом архитектуры |
| Приложения | В приложениях могут приводиться разработанные дополнительные документы, архитектурные модели верхнего уровня, схемы организации процессов поддержки жизненного цикла архитектуры, технико-экономические расчеты, описание перспективных технологий |
Для более крупных организаций можно использовать рекомендации из выбранной методики с учетом доработок под особенности предприятия.
Оценка зрелости архитектуры
Как и для всякого проекта, при разработке и внедрении архитектуры предприятия нужно уметь оценивать уровень полученного результата. Для этого META Group рекомендовала использовать шкалу зрелости, аналогичную той, которая применяется в методике Capability Maturity Model (CMM), предложенной Институтом системного инжиниринга (SEI) при Университете Карнеги-Меллона CMM. Аналогичный подход был предложен для оценки архитектур ИС федеральных органов в США.
Мы неоднократно будем сталкиваться с аналогичными моделями оценки зрелости тех или иных процессов, например, процесса организации инвестиций в ИТ. В основе всех таких моделей, по большому счету, лежит новаторская работа Филиппа Кросби (Philip Crosby) "Quality is Free" (дословно, "Качество – это бесплатно") 1979 года. Эти идеи легли в основу концепции и теории Тотального управления качеством TQM (Total Quality Management), созданной В. Деммингом, Дж. Мураном и Ф. Кросби.
Кросби разработал методику, которая включает в себя пять стадий или уровней развития процессов, связанных с качеством. Он назвал эти стадии следующим образом:
· неопределенность;
· пробуждение;
· осведомленность или обучение;
· мудрость;
· определенность.
В отношении архитектуры предлагаемая модель относит зрелость архитектуры предприятия также к одному из пяти уровней:
Уровень 1. Начальный.
Уровень 2. Повторяемый.
Уровень 3. Определенный или регламентируемый.
Уровень 4. Управляемый.
Уровень 5. Оптимизирующий.
В табл. 3.4 приведены общие характеристики уровней организационной зрелости.
Таблица 3.4.
Характеристики уровней организационной зрелости
| Уровень | Основные характеристики |
| 1. Начальный | Спонтанные информационные связи. Хаотичность, непоследовательность |
| 2. Повторяемый | Базовые процессы. Повторяемые операции |
| 3. Определенный | Стандартизация процессов. Интеграция, наличие процедур |
| 4. Управляемый | Контроль качества. Использование обратной связи |
| 5. Оптимизирующий | Постоянное развитие. Самоадаптация системы |
Таблица 3.5 подробнее расшифровывает критерии, которым архитектура должна удовлетворять на различных уровнях своего развития.
Таблица 3.5
Шкала уровней зрелости архитектуры предприятия
| Уровень 1 начальный | Уровень 2 повторяемый | Уровень 3 определенный | Уровень 4 управляемый | Уровень 5 оптимизированный | |
| Связь с миссией организации | Отсутствует или неявная | Явная связь с миссией. | Явная связь с ключевыми параметрами миссии | Периодическая переоценка актуальности связи. Контролируемый интервал времени между изменением требований и изменением архитектуры | Процессы постоянно улучшаются на основании измеряемых требований |
| Вовлеченность высшего руководства | "Что такое корпоративная архитектура?" "Зачем она нам вообще нужна?" "Нет, это у нас работать не будет" | Руководство что-то слышало о проекте по разработке архитектуры. Усердное кивание головами. Некоторое сопротивление в связи с ожидаемыми результатами | Руководство в курсе проекта и поддерживает его. Руководство поддерживает наличие стандартов | Высшее руководство участвует в обсуждении результатов проекта | Руководство активно участвует в оптимизации бизнес-процессов в рамках архитектурного проекта. |
| Участие бизнес-подразделений | "Мы поддерживаем данный проект, пока он рекомендует те стандарты, которые мы уже сами раньше выбрали". "Стандарты только помешают нам реализовать миссию предприятия" | Признание факта, что поддержка слишком большого числа разных технологий накладна. Возможно разочарование от внедрения инновационных приложений "в пустоте" | Признание факта, что стандарты архитектуры помогут облегчить интеграцию и повысят шансы компании на реализацию миссии. Большинство бизнес-подразделений активно участвуют в разработке архитектуры | Все бизнес-подразделения активно участвуют в разработке архитектуры | Рекомендации бизнес-подразделений используются для улучшения самого процесса разработки архитектуры |
| Описание самого процесса разработки архитектуры | Отсутствует или сохраняется в том виде, как осталось к моменту завершения прошлого провального проекта | Активно разрабатывается внутри ИТ-службы. Недостаточно широко известно в организации | Процесс хорошо определен и известен ИТ-специалистам и бизнес-подразделениям | Процесс является частью корпоративной культуры, он сильно связан с другими процессами, такими как финансовое планирование, реинжиниринг, разработка новых продуктов и др. | Спланированные усилия по оптимизации процесса. Моделирование предлагаемых изменений процесса перед реализацией |
| Разработка профилей стандартов | Нет никакой архитектуры – просто не о чем говорить. Несколько стандартов, выбранных случайным образом | Стандарты существуют, но не объединены в систему | Разработка профилей стандартов связана с бизнес-требованиями посредством концептуальной архитектуры, определенных принципов и лучших практик | Архитектура компонент ИС определена вплоть до уровня стандартов. Эксплуатируемые системы проверяются на соответствие стандартам | То же, что и на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса разработки aрхитектуры |
| Распространение описания архитектуры в организации | Вроде бы описание находится в папке, которую недавно видели где-то в службе ИТ. Новые сотрудники ИТ-службы, вероятнее всего, даже не знают о существовании этой папки | Папка с описанием архитектуры периодически обновляется, или результаты размещаются на web-сайте. Для документирования используется MS Word и картинки. Совещания и обсуждения архитектуры иногда имеют место | Документы регулярно обновляются и уточняются. Актуальная на каждый момент версия доступна на web-сайте, в БД коллективного доступа и т.п. Для управления документацией используются специализированные средства. Периодические презентации по ходу процесса для ИТ-службы. Вероятно, они входят в курс начального обучения новых сотрудников | Документы регулярно обновляются и уточняются с контролируемыми сроками. Проводится мониторинг обучения и ознакомления | То же, что на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса распространения архитектуры |
| Контроль за применением стандартов | Явные процедуры отсутствуют | Некоторые стандарты контролируются (напр., ПО рабочих станций). Отклонения на стадиях проектирования и внедрения могут остаться незамеченными | Явный контроль основной части стандартов. Формализованный процесс рассмотрения отклонений | Явный контроль всех инвестиций в ИТ. Формализованный процесс использования выявленных отклонений для коррекции архитектуры | То же, что на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса контроля |
| Управление проектом разработки архитектуры | Стандарты и средства отсутствуют или случайные. Формальный механизм определения приоритетов отсутствует | Используются средства планирования и управления. Оценка рисков производится командой проекта | Целевая архитектура определяет требования к квалификации персонала. Процедуры управления изменениями определены и связаны с процессом рецензирования архитектуры | Инициация проекта и определение ключевых требований производится совместно руководителями организации и ИТ-службы. Управление вендорами – одна из ключевых компетенций. Требования непрерывности производства заложены в цикл планирования проекта | Действует программа обеспечения результативности. Контракты с вендорами продлеваются на основе измеряемых показателей производительности и соответствия корпоративным стандартам. Ключевая компетенция – непрерывность бизнеса |
| Корпоративная архитектура масштаба предприятия | Миссия, требования к данным и приложениям определены только в принципе. Данные о процессах, приложениях, информационных ресурсах, а также их модели неполны или отсутствуют вообще | Большинство приложений перечислены в реестре. Для части бизнес-процессов существуют модели | Все приложения классифицированы в реестре в соответствии с их позиционированием для бизнеса и состоянием. Модели бизнес-процессов существуют и используются для проектирования разработки решений | Моделирование процессов и выбор приложений производится в соответствии с архитектурой. Методы и средства моделирования периодически проверяются. Оцениваются затраты времени на моделирование и фактическое использование моделей | Метрики, определяемые на уровне 4, используются для улучшения процессов. Происходит переход от использования отдельных приложений к использованию решений. Бизнес-моделирование является постоянным и обязательным, актуальные модели сохраняются в общем репозитории |
| Организация закупок ИТ | Стратегия закупок отсутствует. Персонал, участвующий в закупках, не принимает заметного участия в процессе разработки архитектуры | Декларируется следование процедурам и стандартам. Контроль заявок и фактических закупок на соответствие архитектуре неполный или отсутствует | Стратегия закупок определена и предусматривает соответствие стандартам архитектуры. Требования запросов на закупку формируются с учетом стандартов. Персонал, осуществляющий закупки, участвует в контроле за соблюдением стандартов | Все закупки планируются и управляются в соответствии с определенной архитектурой. Оценка предложений поставщиков интегрирована в процесс планирования архитектуры. Существуют процедуры по учету и утилизации устаревающих компонент ИС | Незапланированные закупки отсутствуют |
Аналогичная модель, правда, с разбиением уровня 1 на два – "начальный" и "отсутствующий", предложена Институтом разработок архитектуры предприятия (Institute for Enterprise Architecture Developments).
Интересное распределение организаций из группы Global 2000 по степени зрелости архитектуры приведено, в таблице 3.6.
Таблица 3.6
Распределение организаций из списка Global 2000 по степени зрелости архитектуры
| Уровень | 2004 | 2007 (прогноз) |
| 1 | 30% | 15% |
| 2 | 45% | 40% |
| 3 | 20% | 35% |
| 4 | <5% | 10% |
| 5 | нет | <1% |
Достижимость стандартов
Как же на практике реализуется "самый нижний" уровень ИТ-архитектуры предприятия, связанный непосредственно с определением инфраструктуры ИТ? Принимая во внимание наличие детально разработанных стандартов открытых систем, их "привлекательность" и "обоснованность" со стороны многих международных, национальных и некоммерческих организаций по стандартизации, можно было бы ожидать, что за прошедшие с их появления примерно 10 лет большая часть окружающих нас информационных систем должна бы полностью соответствовать их принципам.
Увы, в действительности этого не наблюдается. Основные причины заключаются в том, что, с одной стороны, эти стандарты не являются необходимо полными, а с другой – производители программных и аппаратных средств реально далеко не всегда выпускают взаимозаменяемые продукты, даже когда они (частично) соответствуют одним и тем же стандартам. Дополнительным фактором может являться значительное время, которое требуется для согласования и утверждения стандартов. Поэтому многим предприятиям приходится выбирать ограниченное количество вендоров и в дальнейшем руководствоваться совместимостью с данными технологиями.
Следствием такого выбора становится тот факт, что принцип "единства архитектуры" перестает быть абсолютным. В ряде случаев оказывается, что определенное отклонение от установленных принципов может быть обосновано. Например, предприятие могло бы выбрать СУБД Oracle и UNIX-платформу для ведения основных производственных баз данных, требующих высокой производительности и надежности. Но для реализации решаемой в течение одного месяца задачи ввода данных из архивов вновь приобретенной компании вполне могут использоваться более простые и дешевые средства. Другим примером может служить применение готового, существующего на рынке, приложения для решения частной задачи одного из бизнес-подразделений. Даже если это приложение будет использовать другую СУБД, отличную от той, которая определена в стандарте предприятия, практически во всех случаях стандарт будет либо проигнорирован, либо пересмотрен. В любом случае, нужно также учитывать и факторы инвестиций и времени, необходимых для перехода к единой архитектуре в масштабе предприятия. При этом, как правило, чем более жесткие ограничения накладывает архитектура предприятия, тем менее она становится полезной на практике.
Означает ли это, что на самом деле все приводимые ранее аргументы в пользу наличия архитектуры бесполезны? Ни в коей мере. Потенциально преимущества всегда могут быть достигнуты, вопрос только в нахождении оптимального компромисса между преимуществами и усилиями, потраченными на определение и достижение целевой "идеальной" архитектуры.
Таким образом, главной целью проекта должно являться создание не "абстрактной, совершенной" архитектуры, а, скорее, "достаточно хорошей". Одним из основных параметров такой архитектуры будет являться гибкость, позволяющая относительно быстро подстраиваться под меняющиеся внешние условия.
Минималистский подход и "достаточно хорошая" архитектура
Выше мы уже говорили о том, что архитектура предприятия неизбежно является упрощенной моделью бесконечно сложной реальности под названием "организация". Это означает, что нужен компромисс в степени детализации такого описания.
Основная рекомендация, которая существует на этот счет, состоит в том, что следует придерживаться минималистского подхода в проектировании архитектуры, т.е. определять требования к архитектуре самого высокого приоритета и затем делать минимально возможное и не более того, чтобы удовлетворить этим требованиям. Это позволяет иметь ограниченный и контролируемый набор архитектурных решений, но в то же время оставляет необходимую степень свободы для технических специалистов по реализации функционала тех или иных систем.
Принцип состоит в том, что если достижение некоторого требования может быть реализовано за счет делегирования принятия решения на более низком уровне, то соответствующее решение не является важным с архитектурной точки зрения (по крайней мере, для данного уровня).
Это требует от нас более четкого осознания того, какие же все-таки решения являются архитектурными. Однозначно под эту категорию решений подпадают те, которые связаны с идентификацией структурных элементов систем или проектированием интерфейсов между элементами, включая спецификации и описание видимого поведения и свойств системы.
Очевидно, что архитектура предприятия должна скорее быть гибкой, чем идеальной. Это нашло отражение в принципе, который был сформулирован как "достаточно хорошая" архитектура. При этом принцип "достаточно хорошей" архитектуры противостоит стремлению создания "идеальной" архитектуры. Философия заключается в том, чтобы создать достаточно гибкую и восприимчивую архитектуру, которая может модернизироваться в процессе своего жизненного цикла в ответ на изменения в моделях бизнеса и технологиях, и это гораздо важнее, чем создание теоретически правильной, идеальной архитектуры, представляющей полное и конечное видение.
Для реализации этого подхода рекомендуется следовать следующим трем принципам:
· Быть гибким и разграничивать уровни архитектуры. Гибкость может, в частности, достигаться за счет разделения архитектуры на предметные области (Бизнес-архитектура, Архитектура прикладных систем и т.д.). Это позволяет ограничивать необходимость внесения изменений, понимать влияние изменений в одной предметной области на другие и не переделывать всю архитектуру целиком. Например, если в прикладной системе было принято решение о смене используемой системы управления базами данных, то, если вы четко придерживались принципов создания систем "клиент/сервер", такая смена не потребует изменений в логической архитектуре и в моделях.
· Концентрация на наиболее важных частях архитектуры. Используйте правило 80/20 при определении того, над какими частями архитектуры работать. Концентрируйтесь на вопросах, которые действительно важны для организации. Например, если самым высоким приоритетом является интеграция и взаимодействие систем или простота доступа пользователей к данным, то концентрируйте работу именно в этой области. При этом, конечно, важно сохранять общий взгляд на архитектуру в целом, но такой подход к приоритетной проработке определенных частей архитектуры позволяет добиться в краткосрочном плане позитивных результатов.
· Создавайте архитектуру, которая может развиваться итеративно. Основной предпосылкой должно быть то, что архитектура будет достаточно часто изменяться. Поэтому надо изначально предусмотреть такие механизмы, организационные структуры и методы управления и надзора за архитектурой, которые бы позволили вносить изменения так часто, как это требуется.
При этом имеются и другие элементы, определяющие "достаточно хорошую" архитектуру.
Временные интервалы, которые должна охватывать "достаточно хорошая" архитектура
При рассмотрении архитектуры необходимо рассматривать три промежутка времени: сегодня, ближайшее будущее, отдаленная перспектива.
Gartner рекомендует 15% усилий и внимания уделять существующей сегодня в организации архитектуре, 70% – архитектуре, которую предполагается реализовать в ближайшем будущем, и еще 15% усилий – архитектуре, как она видится в отдаленной перспективе.
Работы, относящиеся к существующей сегодня архитектуре, связаны с анализом и документированием имеющейся архитектуры, т.е. созданием моделей имеющихся систем, описанием связей между системами, моделированием используемых данных и потоков работ. И хотя эти работы имеют важное значение с точки зрения каталогизации существующих связей, их ценность не очень велика с точки зрения обеспечения динамичности и гибкости организации. Обычно результатом излишних усилий по описанию сегодняшней архитектуры являются альбомы и папки с документами, которые большую часть времени стоят на полках без дела. Поэтому, признавая ценность определенных усилий по каталогизации (они позволяют оценивать влияние рассматриваемых к внедрению новых систем), время, инвестируемое в сегодняшнюю архитектуру, должно быть минимизировано.
Целью проектирования будущей архитектуры является обеспечение синхронизации долгосрочной ИТ-стратегии с долгосрочной бизнес-стратегией, как правило, во временном диапазоне трех лет и более. И, несмотря на то, что это важно, предполагаемая к реализации в отдаленном будущем архитектура, как правило, носит достаточно общий, недетализированный характер, поскольку будущее по своей природе неизвестно как с точки зрения бизнеса, так и с точки зрения информационных технологий. Например, на уровне бизнеса при описании долгосрочной стратегии могут использоваться утверждения типа "мы хотим быть самой крупной сетью магазинов в городе N". И хотя такого рода утверждения могут быть великолепным долгосрочным ориентиром для компании, они дают немного с точки зрения направления развития ИТ. Они слишком для этого абстрактны.
Поэтому "достаточно хорошая" архитектура должна описывать архитектуру предприятия завтрашнего дня, ближайшего будущего и обеспечивать руководства, модели, интерфейсы, определения и протоколы для непосредственного использования в процессе проектирования и интеграции новых систем.
Рис. 3.5 Стратегическое окно возможностей для "достаточно хорошей" архитектуры
Действительно, ведь когда вы съезжаете с горы на лыжах по выбранной (черной, красной, синей, зеленой) трассе, вы не думаете о том, где находится подножье горы, а прогнозируете для себя прежде всего то, как и где вы сделаете несколько ближайших поворотов. И после очередного поворота вы снова оцениваете свое положение и возможные маневры на некоторое расстояние вперед.
Аналогично, "архитектура завтрашнего дня" обеспечивает такой взгляд в будущее на достаточно короткую перспективу. Если архитектура создается, в первую очередь, для обеспечения динамичности предприятия, она должна постоянно настраиваться на новые возможности, которые открываются в бизнесе и информационных технологиях. Принятие правильных решений на уровне непосредственных, ближайших шагов гораздо важнее, чем определение конечной цели – спуска к подножью горы.
Необходимо также учитывать еще один временной горизонт, который называется "стратегическое окно возможностей":
· Тактическое окно – 9 месяцев.
· Скользящее окно оперативных возможностей – 18 месяцев.
· Стратегическое окно – 30 месяцев.
Интересно отметить, что за прошедшие между двумя публикациями Gartner 4 года рекомендуемая продолжительность среднесрочного горизонта планирования сократилась с 2-3 лет до 18 месяцев, а стратегического горизонта – с 3-5 лет до 30 месяцев. Очевидно, что это связано с влиянием происходящего глобального ускорения бизнес-процессов и постоянного развития информационных технологий.
Архитектура должна приносить пользу, прежде всего, с точки зрения достаточно короткого, 9-месячного промежутка времени. Окно оперативных возможностей должно постоянно перемещаться и соответствовать интервалу примерно в 18 месяцев. Это тот период времени, который связан с нашим понятием "архитектура завтрашнего дня". Стратегическое окно должно быть не более 30 месяцев и соответствовать принятому в компании горизонту стратегического планирования.
Третья метрика связана с распределением усилий на различных фазах жизненного цикла архитектуры. Управление, руководство и надзор над процессом создания архитектуры должны занимать примерно 40% всех усилий по созданию архитектуры. Вторым по "значимости" аспектом проекта – порядка 30% усилий – является собственно разработка моделей, стратегий, решений и их документирование, то, что обычно понимается под понятием "построение, разработка архитектуры". Примерно по 15% усилий рекомендуется сосредоточить на обеспечении восприятия предложенных решений со стороны руководства и бизнес-подразделений – то есть "продаже" идеи внутри организации, а также на проведение оценки и сравнительного анализа с лучшими практиками или доступными аналогами.
Действительно, хотя отдельные ошибки в выборе конкретной технологии могут иногда привести к неудаче всей архитектуры в целом, все-таки большинство проблем при создании архитектуры являются следствием плохого управления и контроля.
Многие архитекторы считают, что основной фокус усилий по созданию архитектуры должен лежать в области технологий. Однако даже достаточно хорошо проработанная с технологической точки зрения архитектура может потерпеть неудачу при реализации, если не организовать правильно процесс управления.
Таким образом, наиболее важными вопросами, на которые необходимо обращать внимание при управлении архитектурным процессом, являются следующие:
· изучение, осознание и коммуницирование бизнес-стратегии;
· определение и анализ уровня зрелости архитектуры;
· решение вопросов комплектования и организации работы команды архитекторов;
· вовлечение конечных пользователей архитектуры в процесс;
· реализация философии "постоянных изменений";
· поиск архитекторов с нужным уровнем знаний.
При этом ключевым элементом для решения первой из задач является максимальная конкретность, которая достигается прежде всего за счет наличия явной связи между каждым архитектурным элементом и бизнес-целью. Эти шаги обеспечивают создание необходимой среды для использования в организации архитектуры и обоснование необходимости инвестиций в разработку архитектуры. Обоснование инвестиций в архитектуру должно быть основано на использовании конкретной информации, связанной со специфическими целями и задачами бизнеса организации. Общие слова в этом плане могут быть врагом архитектуры. Каждый элемент архитектуры должен поддерживать достижение определенной бизнес-цели.
Проведение же периодических измерений, сравнений и оценок позволяет проводить необходимые корректировки уже в ходе реализации проектов, основываясь на измеряемых объективных показателях. Это помогает увидеть результаты работы по созданию архитектуры, обеспечивает возможность внесения необходимых изменений и создает обратную связь для всего процесса.
Заключение
Уважаемые студенты. Вы познакомились с основным содержанием тем курса «Архитектура предприятия».
Архитектура предприятия — это наиболее общее и всестороннее представление предприятия, как хозяйствующего субъекта, имеющего краткосрочные и долгосрочные цели ведения своей основной деятельности, определенные миссией на региональном и мировом рынке, и стратегией развития, внешние и внутренние ресурсы, необходимые для выполнения миссии и достижения поставленных целей, а также сложившиеся правила ведения основной деятельности (бизнеса).
В данном курсе лекций рассматриваются вопросы разработки и использования архитектуры предприятия.
Следует отметить, что, концепция Архитектуры предприятия, которая включает в себя такие аспекты, как Бизнес-архитектура, Архитектура информации, Архитектура прикладных систем и Технологическая архитектура, является способом объединения и синхронизации функциональных и бизнес-потребностей организаций с возможностями информационных технологий в условиях их экспоненциальной сложности. В лекционном курсе на основе обширного материала и опыта зарубежных компаний-поставщиков информационных технологий, аналитических и консалтинговых компаний, а также публичных материалов Интернет дается систематичное введение и описание современного состояние этой предметной области. Приводятся основные модели и подходы к описанию элементов Архитектуры предприятия, связанные с ними принципы, стандарты и руководства, обеспечивающие целостность описания архитектуры. Рассматриваются и организационные аспекты, связанные с управлением архитектурным процессом на предприятии.
Список литературы
а) основная литература (имеется в наличии в библиотеки ВлГУ):
1. Управление архитектурой предприятия: Учебное пособие. Пакет мультимедийных приложений/Кондратьев В. В. - М.: НИЦ ИНФРА-М, 2015. - 358 с. - ISBN 978-5-16-010401-0. – Режим доступа: http://znanium.com/bookread2.php?book=486883
2. Лукьянов Б.В. Архитектура предприятия [Электронный ресурс]: учебное пособие/ Лукьянов Б.В., Лукьянов П.Б.— Электрон. текстовые данные.— М.: Русайнс, 2015.— 134 c. - Режим доступа: http://www.iprbookshop.ru/48872
3. Архитектура корпоративных информационных систем / Астапчук В.А., Терещенко П.В. - Новосиб.: НГТУ, 2015. - 75 с.: ISBN 978-5-7782-2698-2– Режим доступа: http://znanium.com/bookread2.php?book=546624
б) дополнительная литература (имеется в наличии в библиотеки ВлГУ):
1. Гриценко Ю.Б. Архитектура предприятия [Электронный ресурс]: учебное пособие/ Гриценко Ю.Б.— Электрон. текстовые данные.— Томск: Томский государственный университет систем управления и радиоэлектроники, 2011.— 264 c. - Режим доступа: Режим доступа: http://www.iprbookshop.ru/14005. — ЭБС «IPRbooks»
2. Информационные технологии и управление предприятием [Электронный ресурс] / Баронов В. В., Калянов Г. Н., Попов Ю. Н., Титовский И. Н. - М.: ДМК Пресс, 2009 (Серия "БизнесПРО")." - http://www.studentlibrary.ru/book/ISBN5984530090.html
3. Финансовая архитектура компаний. Сравнительные исслед. на развитых и развив. рынках: Моногр./ И.В. Ивашковская и др.; Под науч. ред. И.В. Ивашковской. - М.: ИНФРА-М, 2014. - 238 с.: 60x90 1/16. - (Научная мысль). (п) ISBN 978-5-16-009847-0, 500 экз. – Режим доступа: http://znanium.com/bookread2.php?book=459546
в) периодические издания
1. http://www.compress.ru – Журнал «КомпьютерПресс».
2. http://www.osp.ru/cw – Журнал «ComputerWorld Россия».
3. http://www.osp.ru/cio/#/home – Журнал «Директор информационной службы».
4. http://www.pcweek.ru – Журнал «PC Week / RE (Компьютерная неделя)».
5. http://www.infosoc.iis.ru –Журнал «Информационное общество».
6. http://www.crn.ru – Журнал «CRN / RE (ИТ-бизнес)».
7. http://www.cnews.ru – Издание о высоких технологиях.
г) интернет-ресурсы
1. www.akm.ru (Информационное агентство)
2. http://economics.edu.ru (Образовательный портал)
3. www.economy.gov.ru (Министерство экономического развития и торговли)
4. www.gks.ru (Госкомстат)
5. www.inme.ru (Институт национальной модели экономики)
6. www.iet.ru (Институт экономики переходного периода)
7. www.imf.ru (МВФ)
8. www.rbc.ru (Информационное агентство РБК)
9. http://www.osp.ru/Официальный сайт журнала "Директор информационной службы"
10. http://expert.ru/expert/.Официальный сайт журнала "Эксперт" -
11. ProjectExpert. http://www.expert-systems.com Консалтинговая компания «Эксперт Системс». Официальный сайт компании «Эксперт Системс»: сайт по программному продукту
12. http://www.unido.org. UNIDO. Официальный сайт комитета организации объединенных наций по промышленному развитию: сайт по программному продукту COMFAR:
13. Архитектура предприятия. [Электронный ресурс]. URL: http://www.intuit.ru/department/itmngt/entarc/. Загл. с экрана. яз. русск. Режим доступа: свободный
14. Gartner: Gartner Identifies the Top 10 Strategic Technologies for 2011/ URL: http://www.gartner.com/it/page.jsp?id=1454221.
15. Introducing The Open Group Architecture Framework (TOGAF), http://www.ibm.com.
16. The Zachman Framework™: A Concise Definition, http://zachmaninternational.com.
17. http://www.studentlibrary.ru/
18. http://znanium.com/
19. http://www.iprbookshop.ru/
20. http://e.lib.vlsu.ru/
имени Александра Григорьевича и Николая Григорьевича Столетовых»
(ВлГУ)
Институт экономики и менеджмента
Кафедра Бизнес-информатика и экономика
Составитель: Куликова И.Ю.
Конспект лекций по дисциплине
«Архитектура предприятия»
Конспект лекций
По дисциплине «Архитетура предприятия»
для студентов ВлГУ,
обучающихся по направлению 38.04.05» Бизнес-информатика»,
программа «Предпринимательство и организация бизнеса в сфере информационных технологий»
Владимир – 20__ г.
Оглавление
| Введение…………………………………………………………………………………… | 3 |
| Тема 1. Архитектура предприятия: понятийный аппарат …………………………….. | 5 |
| Тема 2. Современные методики описания архитектуры предприятия ……………… | 25 |
| Тема 3. Процесс разработки архитектур ……………………………………………….. | 86 |
| Заключение………………………………………………………………………………... | 129 |
| Список литературы……………………………………………………………………….. | 130 |
Введение
Изучение дисциплины обеспечивает формирование у студентов практических навыков работы с архитектурой предприятия, необходимых в дальнейшей профессиональной деятельности.
Знания, полученные в рамках изучения данной дисциплины, могут быть применены при прохождении практик, выполнении научно-исследовательских работ, подготовке к научно-исследовательскому семинару и выпускной квалификационной работы (магистерской диссертации).
Целями освоения дисциплины «Архитектура предприятия» являются:
1. Формирование навыков, необходимых для полноценного участия в стратегических процессах организации, реализации возможности повышения эффективности бизнеса на основе информационных и коммуникационных технологий.
2. Формирование у магистрантов необходимых практических навыков для работы с современными методиками, моделями и программным обеспечением в рамках решения практических задач по созданию архитектуры.
3. Формирование целостного представления у магистрантов о месте и роли архитектуры предприятия в процессе исследования и разработки современных сложных систем, моделирующих проблемную ситуацию в предметной области.
Процесс изучения дисциплины «Архитектура предприятия» направлен на формирование следующих профессиональных компетенций:
- способность разрабатывать стратегию развития архитектуры предприятия (ПК-4);
- способность управлять внедрением инноваций для развития архитектуры предприятия (ПК-17).
В результате освоения дисциплины обучающий должен демонстрировать следующие результаты образования:
1) Знать:
- понятие и уровни архитектуры предприятия (ПК-4);
- понятие и уровни архитектуры предприятия, основные подходы к проектированию архитектуры предприятия (ПК-17).
2) Уметь:
- управлять архитектурой предприятия (ПК-4);
- ставить цели и формулировать задачи, связанные с внедрением инноваций для развития архитектуры предприятия (ПК-17);
3) Владеть:
- базовыми навыками работы по созданию архитектуры предприятия в целях его стратегического развития (ПК-4);
- навыками управления внедрением инноваций для развития архитектуры предприятия (ПК-17).
Конспект лекций составлен на основании разработок ведущих мировых компаний, в том числе и российских, ведущих свою деятельность в области информационных технологий и систем, ученых-исследователей и преподавателей технических и экономических дисциплин.
Представленный конспект является важным элементом самостоятельной работы студентов.
Самостоятельная работа предполагает изучение тем дисциплины вне аудитории и включает в себя выполнение различного рода заданий, которые ориентированы на более глубокое усвоение материала.
Самостоятельное освоение учебной дисциплины требует систематического и последовательного накопления знаний.
Поэтому студент должен
- постоянно обращаться к материалам рабочей программы дисциплины (РПД) при подготовке к занятиям;
- уяснить цели и задачи дисциплины, ее место в общей системе обучения, а также связи с другими дисциплинами образовательной программы;
- ознакомиться с графиком консультаций преподавателей кафедры, ведущих лекционные и практические занятия;
- взять в библиотеке, найти в интернет-источниках или приобрести рекомендованные в перечне основной литературы учебники и учебные пособия;
- перед каждой лекцией восстановить в памяти материал предыдущих занятий, воспользовавшись конспектом, а также просмотреть РПД по пройденной теме и ее основные вопросы;
- при затруднениях в понимании материала дисциплины следует обратиться к лектору по его графику консультаций или к преподавателю, ведущему практические занятия.
Самостоятельная работа должна выполняться самим студентом и в установленный срок.
Знание лекционного материала позволяет понять основы изучаемой темы курса, терминологию, закономерности и зависимости, проследить взаимосвязь разных тем, осваивать курс от простого к сложному. Лекционный материал помогает подготовиться к выполнению разного рода заданий, пройти рейтинговые испытания. Поэтому посещение лекций является обязательным, конспектирование лекций - необходимым и обращение к лекционному материалу - очень важным. Итоговый рейтинг включает баллы за посещение лекционных занятий. Промежуточный контроль по результатам семестра по дисциплине проходит в форме экзамена, который включает в себя знания теоретических вопросов, полученных, в том числе, в ходе посещения лекционных занятий и освоения их материалов самостоятельно.
Дата: 2019-02-02, просмотров: 7434.
