Лекция 5 (4 часа). Раздел 3. Архитектура предприятия.
3.1. Понятие и общее представление об архитектуре предприятия.
Существует несколько определений и моделей архитектуры, предлагаемых в различных национальных и международных стандартах. Приведем одно из них, дополнив комментариями из других, которые расширяют и уточняют понятие архитектуры.
Архитектура системы (предприятия) представляет стратегическую информационную основу, которая определяет:
Структуру бизнеса;
Информацию, необходимую для проведения этого бизнеса;
Технологии, применяемые для поддержания деловых операций;
Переходные процессы преобразования, развития, которые необходимы для реализации новых технологий в ответ на появление новых изменяющихся бизнес - потребностей.
Таким образом, архитектура системы (предприятия) представляет модель основного расположения и взаимосвязей внутренних частей системы (физического либо концептуального объекта или сущности).
Эта модель должна отвечать определенным требованиям полезности. Поэтому качество описательных представлений должно быть настолько конструктивным, чтобы на их основе можно было создать (продуцировать) описанный объект и поддерживать его на дальнейшем протяжении жизненного цикла.
Предприятие является гибридной системой, определяемой свойствами людей и машин. Люди как объекты модели или ресурсы характеризуются поведением (они обучаются, решают различные задачи). Машины осуществляют действия или реагируют на другие действия. В этой связи подчеркнем, что эти объекты системы нуждаются в различных видах информации.
Приведенное определение качественно описывает базовое понятие архитектуры.
Для представления общей архитектуры предприятия используются модели, содержащие слои отдельных архитектурных представлений. Как правило, в верхнем слое отражены функциональные требования к предприятию, связанные с его деятельностью. В нижних слоях отражаются технические особенности используемых информационных систем и технологий.
В качестве исходной для представления базовой схемы можно использовать модель архитектуры предприятия (Enterprise Architecture Model), предложенную национальным институтом стандартов и технологий США (National Institute of Standards and Technology - NIST), представленную на рис.3.1.
3.2. Основные цели создания архитектуры предприятия.
Основные цели создания и использования архитектуры предприятия и его систем позволяют осуществить:
Выбор рационального (реализуемого, достигающего цели) решения задач основной деятельности бизнеса предприятия;
Сохранение взгляда на целое в стратегической перспективе;
Исключение провалов в устройстве системы и при ее эксплуатации;
Создание основы и критериев для оценки частных архитектур;
Рис. 3.1. Схема архитектуры компьютеризированного предприятия по NIST (HW-hardware-аппаратное обеспечение, SW-software-программное обеспечение).
3.3. Общие методические принципы создания архитектуры.
К общим методическим принципам создания архитектуры предприятия можно отнести целый ряд принципов.
1. Принцип согласованности слоев. Архитектурные слои связаны так, как это представлено на рис. 3.1. Качество связи слоев должно быть таким, чтобы бизнес-потребности и ИТ-решения оставались согласованными на стратегическую перспективу.
2. Принцип независимости слоев. С учетом первого принципа согласованности слои должны быть независимы в том смысле, что изменения, производимые в том или ином слое, требовали бы минимально возможной степени изменений в других слоях.
3. Принцип свободы выбора. Все решения по выбору своей архитектуры и стандартов своего предприятия осуществляет само предприятие и несет ответственность за решение своих задач.
4. Принцип постепенной детализации архитектуры. Архитектурные продукты концептуального значения создаются постепенно по шагам. На каждом шаге свои продукты с постоянной проверкой на удовлетворение требований.
5. Принцип постоянной трансформации архитектуры предприятия. С учетом изложенных выше принципов архитектура предприятия и его система должна находиться в постоянно актуализируемом состоянии, чтобы отвечать на новые требования внешней среды: новые потребности клиентов, новые возможности информационных технологий (ИТ), новые угрозы со стороны внешней среды.
3.4. Формирование архитектуры в процессе детализации.
Разработка концептуальной архитектуры предприятия на перспективу осуществляется как пошаговый процесс формирования целевой архитектуры, отталкиваясь от текущей архитектуры и двигателей ее преобразования. В этот пошаговый процесс входит использование сегментного подхода к архитектуре и принципа постепенной (пошаговой) детализации архитектуры.
3.4.1. Подходы при построении архитектуры.
Вообще говоря, известны три возможных подхода построения архитектуры.
Стандартный подход. В этом подходе вначале разрабатывается общая схема и правила для будущего описания архитектуры. Затем описывается вся текущая база, и после этого представляется вся целевая архитектура. Только после этого начинается конструирование, приобретение, реализация систем.
Этот подход требует существенных начальных инвестиций - финансовых и временных, с одной стороны. С другой стороны, этот подход может привести к тому, что называется "паралич из-за анализа".
Подход "статус-кво" . Разработка рассматривается как реакция на те или иные возникающие затруднения.
Сегментный подход. Этот подход опирается на модель разработки сегментов архитектуры в рамках общей структурированной схемы. Он сосредотачивается на главных областях бизнеса (например, система управления финансами, кадрами, служба документационного обеспечения управления и т. п.).
Для того, чтобы сократить возможные риски, обеспечить снижение начальных затрат и добиться быстрой отдачи от проекта используется сегментный подход.
3.4.2. Компоненты архитектуры предприятия.
Выделяют следующий набор компонентов архитектуры.
Двигатели архитектуры (Architecture Drivers) отражают внешние стимулы изменения архитектуры: бизнес-стимулы и технические стимулы.
В качестве бизнес - стимулов может выступать новое законодательство, новые инициативы администрации, ассигнования для ускорения развития отдельных сфер, рыночные силы.
В роли технических двигателей могут выступать новое и улучшенное программное обеспечение , аппаратные средства ЭВМ и их комбинации.
Стратегическое направление (Strategic Direction) - руководство для разработки целевой архитектуры, которое содержит видение миссии предприятия, принципы его построения, цели и объекты предприятия.
Текущая архитектура (Carrent Architecture) определяет архитектуры предприятия "как есть" и состоит из двух частей: текущая бизнес-архитектура и техническая архитектура (данные, приложения и технологии). Она отражает текущие возможности и технологии, а также служит объектом для дальнейшего расширения.
Целевая архитектура (Target Architecture) определяет архитектуру предприятия "как должно быть построено" и состоит из двух частей: целевая бизнес-архитектура и техническая архитектура (т. е. данные, приложения и технологии). Она представляет будущие возможности и технологии, которые являются результатом улучшения проекта поддержки изменяющихся бизнес - потребностей.
Переходные процессы (Transitional Processes) поддерживают переход от текущей архитектуры к целевой архитектуре. Критические переходные процессы для предприятия включают планирование инвестиций в сферу ИТ, планирование перехода, управление конфигурацией, контроль и управление проектом.
Архитектурные сегменты (Architectural Segments) отражают ориентацию отдельных частей общей архитектуры на главные бизнес - области.
Архитектурные модели (Architectural Models) определяют бизнес - модели и конструкторские (технические) модели, которые отражают все необходимые сегменты для полного описания предприятия.
Стандарты (Standards) включают все стандарты, руководящие принципы (руководящие материалы), а также передовой опыт. Примерами стандартов являются:
Стандарты безопасности;
Стандарты данных относятся к данным, метаданным и другим связанным структурам;
Стандарты приложений относятся к прикладному ПО;
Стандарты технологий относятся к операционным системам и аппаратным платформам.
3.5. Комплексная архитектура предприятия. Модельные и организационные подходы.
С целью дальнейшей проработки архитектурных слоев целесообразно переходить на другое, более детальное, представление архитектуры. В качестве такого представления предлагается использовать схему архитектуры предприятия Дж. Захмана, которая в 90-х годах стала стандартом де-факто.
Схема Дж. Захмана версии 1987, 1992, 2000 гг. отличается более гармоничным и комплексным учетом архитектурно существенных факторов, начиная со слоев бизнес - архитектуры.
В то же время она не навязывает конкретных инструментальных особенностей при формировании моделей.
Благодаря этому схема архитектуры предприятия Дж. Захмана может использоваться в качестве референсной модели для разработки адаптированных методических материалов для конкретных предприятий. Здесь под референсной понимается ссылочная, рамочная эталонная модель.
Свойство моделей, описаний, проектов, имеющих статус стандартизованного образца, характеризует их как шаблоны, которые могут быть использованы в разработках различных конкретных систем.
Однако эта схема, как и изложенные выше схемы архитектурных слоев, обладает недостатками с точки зрения представления динамики развития предприятия и его ИС. Этот недостаток преодолевается расширенной схемой Захмана – схема и подход «3Д-предприятие» (опубликована в 2000 году).
При описании процесса разработки и использовании архитектуры конкретного предприятия рассматривается схема движения от архитектуры «как есть» к архитектуре «как должно быть».
Вышесказанное имеет особое значение для предприятия, включенного в программу трансформации.
3.5.1. Матрица согласованных моделей в архитектурах.
Сложные системы характеризуются выполняемыми процессами (функциями), структурой и поведением во времени. Для адекватного моделирования этих аспектов в автоматизированных информационных системах различают организационные, функциональные, информационные и поведенческие модели пересекающиеся друг с другом.
Функциональная модель системы описывает совокупность выполняемых системой функций, характеризует морфологию системы (ее построение)- состав функциональных подсистем, их взаимосвязи.
Информационная модель отражает отношения между элементами системы в виде структур данных (состав и взаимосвязи).
Поведенческая (событийная) модель описывает информационные процессы (динамику функционирования). В ней фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий.
Организационная модель описывает подразделения из которых состоит предприятие.
Все эти модели должны быть соединены в единую систему понятным и непротиворечивым образом. Поэтому даже вопросов «простого» согласования компонентов системы достаточно для того, чтобы прилагать специальные усилия на уровне формирования архитектуры.
Идея такого согласования состоит в том, что его надо начинать с самых главных характеристик предприятия, рассматривая важнейшие содержательные аспекты. В идеальном случае согласование начинают с конструирования системы управления предприятием, а именно с создания сбалансированной системы целей и планов. В эту сбалансированную систему целей и планов входят: миссия предприятия, стратегические цели, индикаторы достижения целей и их целевые значения; мероприятия по достижению целей, включая архитектуру информационной системы и информационно-технологическую платформу, а также обновленные бизнес – процессы и оргструктуры; система мотивации работников и планы их профессионального обучения и т. д. Согласование проводят на явно изложенных описаниях предприятия, которые позволяют видеть все существенные взаимосвязи, т. е. на его моделях.
Суть этого метода сводится к формализованному представлению предприятия в виде матрицы (Таблица 3.1).
Строки таблицы отражают уровни представления системы , к ним относятся уровни моделирования, уровни решения проектных задач. Более детально это следующие представления:
· бизнес среда системы,
· концептуальная модель,
· логическая модель,
· технологическая, «физическая модель»,
· детальная реализация (часто поблочная),
· представление пользователя (эксплуатация).
Выделенные аспекты, столбцы таблицы, фактически отражают разделы обеспечения системы :
· функциональное обеспечение (функции),
· коммуникационное обеспечение (сеть),
· организационное обеспечение (структура организации) и т. д.
Описанные разделы обеспечения и уровни представления схемы Захмана являются классификацией сущностей предприятия и его информационной системы.
В строках этой матрицы описываются модели предметной (проблемной) области с позиции различных категорий участников процесса проектирования, к которым относятся представители будущих пользователей системы (заказчиков), проектировщики (консультанты), участвующие в процессе получения и формирования знаний о проблемной области и формулирующие требования к ИС; разработчики и эксплуатационщики ИС.
Проектировщики вместе с заказчиками должны формировать модели предметной (проблемной) области, отражающие содержательную сторону функционирования системы, при этом проектировщики закладывают технологические требования к реализации системы, скрытые от взгляда пользователей.
Таблица 3.1. Матрица согласованных моделей в архитектурах.
|
Виды моделей и их реализация |
Цели (почему?) Дерево целей |
Люди (кто?) Архитектура организации |
Функции (как?) Архитек-тура прило-жений |
Объекты-данные (что?) Архитек- тура данных |
Коммуникации (где?) Архитек- тура технологи-ческая |
Время события (когда? ) |
|
|
Укрупненная модель организации (планировщик, пользователь) |
Список целей и задач |
Список организаций (подразделе- |
Список процесс-сов |
Список сущностей |
Список основных событий |
||
|
Концептуальная модель организации (проектировщик, пользователь) |
Стратегичес-кая модель: цель – стратегия. |
Структурные модели: подразделе-ния – работа |
Функцио-нальные модели: процесс – ресурс. |
Информацион-но-логические модели: ER-диаг-раммы |
Модель топологии узлов |
Модель корпоратив-ных событий |
|
|
Системная модель ИС (консультант-проектировщик) |
Критерии достижения целей |
Роли персонала |
Диаграммы потоков данных |
Логическая модель данных |
Логическая модель сетей организации |
Модель системных событий |
|
|
Технологическая модель (разработчик ИС) |
Модель «состояние-действие» |
Модель интерфейса |
Модель приложе- |
Модель внутреннего представления |
Физическая модель коммуникаций |
Модель технических событий |
|
|
Компоненты (разработчик ИС, субподрядчик) |
Шаг/задача |
Пользователь – транзакция |
Програм - мные модули |
Протоколы |
Компонент-ные события |
||
|
Функционирую-щая система (эксплуатацион-щики) |
Варианты исполнения |
Сеансы работы |
Проце - дуры |
Ограничения целостности |
Клиент – сервер |
Операцион-ные события |
На основе модели требований разработчики ИС проводят технологическую детализацию проекта и его последующую реализацию. На основе сформированной рабочей документации и полученного конечного продукта системы эксплуатационщики осуществляют поддержку функционирования системы в новых условиях.
Архитектуры рассматривают систему в разрезе одних и тех же аспектов, но под разными углами зрения.
В качестве основных аспектов построения архитектур рассматриваются следующие:
– цели, бизнес-правила (мотивация того, почему функционирует система);
– объекты (что проходит преобразования);
– функции (как осуществляется преобразование в процессе);
– участники (субъекты) процесса (кто осуществляет процесс);
– место (где выполняется процесс);
– время (временные требования к выполнению процесса, событиям).
В двух первых строках представлены модели, относящиеся к точке зрения будущих пользователей системы, третья строка соответствует взгляду консультанта-проектировщика, четвертая и пятая строки – точке зрения разработчика ИС, шестая строка – точке зрения эксплуатационных служб.
Подход на основе архитектур не определяет собственно методы построения моделей проблемной области, тем не менее, развитые методологии моделирования предметных областей предполагают реализацию принципов последовательной детализации абстрактных категорий: целей, объектов, функций, организационных единиц и т. д. на уровнях определения требований к системе, их спецификации и реализации.
3.5.2. Примеры заполнения ячеек схемы Захмана.
Приведем примеры того, как может быть раскрыт содержательный смысл каждой ячейки матрицы, который представляет собой конкретный план действий по реализации архитектуры предприятия.
Начнем пояснения с первого столбца матрицы: цели (почему?).
Позиция планировщика. Приводится список главных целей, объектов, стратегий и критических факторов успеха бизнеса предприятия, определяющих мотивации его деятельности. Перечень имеет достаточно высокий уровень агрегирования и определяет границы модели предприятия.
Позиция пользователя (собственника). Цель и стратегия предприятия, которые составляют основную мотивацию для деятельности предприятия и принятия решений. Создание бизнес-плана. Бизнес-план в основном ориентирован на проблемы управления, но в нем также должно уделяться внимание вопросам мотивации деятельности.
Позиция проектировщика. Логическая модель реализации бизнес-правил предприятия в терминах намерений и ограничений.
Позиция разработчика. Правила проекта являются физической реализацией спецификации бизнес-правил. Эти правила, представленные в виде входящих элементов, отражаются в моделях данных, в процедурных кодах и в спецификациях технических требований.
Второй столбец матрицы: люди (кто?)
Позиция планировщика. Список организаций, за которые данное предприятие несет определенную ответственность. Перечень имеет высокий уровень агрегирования и определяет границы модели предприятия.
Позиция собственника. Модель потока работ определяет обязанности и спецификации работ, выполняемых на данном предприятии. Обычно организационная диаграмма отражает распределение обязанностей, а сопутствующие документы описывают процессы производства изделий. Организационная диаграмма должна дополняться процессами по производству изделий, включая управление работами, координацию работы и проведение работ.
Позиция проектировщика. Архитектура человеческого интерфейса. Логические системы отражают поток работ, который, включает спецификации ролей и ответственность участников: менеджмент, администрацию, работников высокой квалификации, разработчиков, специалистов по маркетингу и т. д. Сюда относятся также спецификации процессов разработки изделий (например, текст, графика, видео и т. д.).
Позиция разработчика. Представление архитектуры интерфейса. Данный документ является физическим выражением потока работ, осуществляемых на предприятии конкретными служащими, а также их эргономические требования и форматы представления результатов работы.
Третий столбец: функции (архитектура приложений).
Позиция планировщика. Описывается перечень процессов или бизнес-функций, осуществляемый данным предприятием. Этот перечень определяет возможности, границы или модели процессов, которые характеризуют бизнес-деятельность предприятия.
Позиция владельца (модель предприятия). Модель предприятия представляется моделью действующих бизнес-процессов, которые осуществляет предприятие вне зависимости от каких-либо системных или иных соображений и организационных ограничений. Модель может быть представлена как структурированная модель методов, которая отражает бизнес-преобразования (бизнес-процессы), происходящие на предприятии, а также их входы и выходы.
Позиция проектировщика (модель информационной системы). Содержит логическую модель реализации систем, поддерживающих ручным или автоматизированным способом бизнес-процессы предприятия. В модели отражаются сферы действия, как человека, так и машин. Модель может включать средства и механизмы управления, а также входные и выходные данные для логических систем, которые отражают систему функций/процессов предприятия.
Позиция разработчика (технологическая модель). Приводится конструкция системы. С технической точки зрения это техническая конструкция. На высоком уровне абстракции это может быть структурная схема. При большей детализации она представляется диаграммами действий, которые впоследствии будут переходить в реализацию логических систем или в архитектуру приложений. В случае объектно-ориентированных нотаций это будут различные методы и их реализации.
Позиция субподрядчиков (детализированные спецификации). Представляются программы (поддержка компонентов программного обеспечения, например, операционные системы). Программы, полученные на основе диаграмм действий или объектно-ориентированных спецификаций. Эти программы могут основываться на ранее разработанных компонентах путем их компоновки в требуемом сочетании.
Четвертый столбец: объекты-данные (архитектура данных).
Позиция планировщика. Объекты/сфера действия. Приводится перечень бизнес - объектов. Перечень объектов (изделий или активов), в которых заинтересовано данное предприятие. Модель представляет сферу влияния и границы, которые определяют круг интересов данного предприятия (подробнее это отражается в последующих строках таблицы).
Позиция владельца (модель предприятия). Представляется семантическая модель. Модель фактических объектов бизнес - деятельности предприятия (т. е. изделия или активы), которые являются наиболее существенными для предприятия. Обычно семантическая модель представляется как модель «сущность-связь» и отражает на уровне концептуальных определений (т. е. терминов и фактов) наиболее существенные цели и стратегии бизнеса. Впоследствии эта сущностная модель преображается в бизнес-правила.
Позиция проектировщика (модель ИС). Описывается логическая модель данных. Она представляет собой объекты и цели предприятия, отражаемые в соответствующих записях или отчетах в автоматизированной и в неавтоматизированной форме.
Модель представляется как атрибутивная и нормализованная модель «сущность-связь», отражающая все намерения, которые были ранее представлены в семантической модели.
Позиция разработчика (технологическая модель). Описывается физическая модель данных. Модель отражает технологические ограничения или физическое представление объектов и целей предприятия. Стиль модели зависит от технологии реализации. Если выбрана реляционная технология, модель данных имеет табличную структуру, чтобы поддерживать реляционные модели. В случае объектно-ориентированных нотаций это будет иерархическая/ассоциативная модель.
Позиция субподрядчиков (детализированные спецификации). Приводятся описания данных (библиотека). Определение всех объектных данных, специфицированных физической моделью данных и включающих все описания данных в соответствии с языком описания. Описания данных необходимы для реализации программы.
3.5.3. Схема «3Д-предприятие».
Плоские схемы моделей архитектуры – это средство для организации знаний предприятия, которые важны в условиях приспособления к изменениям предприятия во времени. Для управления проектами развития ИС и трансформации предприятия вводится трехмерная схема, которая образуется путем введения оси стратегического времени.
Модель «3Д-предприятие» строится в трех измерениях.
1. Ось уровня проектирования и использования предприятия. На рисунке (Рис.3.2.) шесть «горизонтальных» уровней:
– потребности и планы,
Бизнес-модель,
Логическая модель,
Техническая конструкция,
Детальная реализация,
Практика использования.
Рис. 3.2. Модель « 3-Д предприятие ».
2. Ось раздела обеспечения и аспекта работы предприятия/АС; шесть вертикальных разделов: цели, люди, функции, объекты, коммуникации, время.
3. Ось времени, в котором развивается предприятие и его АИС стадии на «верхней грани» модели, соответствующих возможным стадиям жизненного цикла системы: анализ (стратегический может отделяться от детального анализа), проектирование (конструирование), реализация и ввод в действие (могут рассматриваться отдельно), совершенствование.
Первые две оси аналогичны (но не обязательно строго совпадают) тем, что использованы в плоской модели Захмана для схемы архитектуры предприятия. Третья ось позволяет явно определить те изменения, которые происходили или будут происходить с предприятием, его информационной системой и проектами создания ИС в процессах их развития и трансформации.
3.5.4. Требования к «3Д-модели».
Описание, создаваемое в указанных осях, становится 3Д-моделью после того, как в элементарных ячейках («кубиках») будут приведены согласованные описания, частные модели. К этим описаниям предъявляются определенные требования. При построении 3Д-модели не следует использовать формализованные нотации и узкопрофессиональные жаргоны.
Модель 3Д-предприятия должна отвечать следующим требованиям:
– простота и доступность для (технических и нетехнических) руководителей и специалистов;
– целостность, каждая проблема рассматривается в рамках предприятия в целом, как в данное время, так и в будущем;
– открытость, каждая проблема или проект могут быть включены в контекст событий будущего;
– использование инструментов планирования, благодаря чему решение не будет приниматься в «пустоте»;
– независимость от каких-либо инструментов (программных, математических), для того чтобы любой инструмент или методология могли быть отображены в модели 3Д-предприятия.
Описание каждой частной модели должно содержать оценку состояния дел с точки зрения данной модели как компонента системы.
Создаваемые в ячейках частные модели должны быть согласованы в своих взаимосвязях.
Правилом описания взаимосвязей частных моделей является явное выделение и описание связей каждой модели-ячейки с ближайшими ячейками более высокого и более низкого уровней представления архитектуры предприятия и ИС; связей каждой модели-ячейки с ближайшими ячейками, отражающими предшествующее и будущее состояния компонента архитектуры; связей каждой модели-ячейки с другими типами моделей данного уровня.
– необходимость компонента и формальные требования к нему;
– качество и степень готовности компонента;
– соответствие плановому графику работ и согласованности различных графиков;
– обоснованность графиков инвестиций и их окупаемости;
– возможность изменений (прогноз) наиболее близкого по времени изменения потребностей, требований и обеспеченности этих изменений ресурсами;
– смысловая целостность модели одного уровня.
Сущности на оси стратегического времени в конкретных 3Д-моделях могут представлять проекты или работы не только по развитию ИС, но и по развитию бизнеса предприятия (как, впрочем, и сущности плоских схем). В ряде случаев не требуется обязательного оформления всех работ на оси стратегического времени в виде проектов (в частности, для того, чтобы не вступать в непродуктивный конфликт с обычаями предприятия).
Например, работами по развитию бизнеса предприятия могут быть фазы управления предприятием:
– ситуационный и диагностический анализ;
– выдвижение целей и выбор стратегий;
– планирование оперативных действий, выполнение подготовительных и запускающих мероприятий;
– тактический и оперативный мониторинг;
– стратегический мониторинг, возобновление анализа и совершенствование стратегий.
Эти фазы тоже могут быть элементами базовой классификации сущностей на оси времени развития предприятия, как и элементы проектного цикла, указанные ранее.
Поскольку ИС должна отвечать конкретным потребностям предприятия, результатом осуществления этого развития могут быть проекты создания новых компонентов ИС. Проект развития ИС вычленяется и оформляется как подпроект проекта развития предприятия.
Заключение.
Рассмотрение концептуального уровня схем архитектуры предприятия показывает:
Архитектура предприятия определяется как базовое свойство и важнейший информационный инструмент предприятий всех типов, что отражается и в международных стандартах;
Важнейшим компонентом архитектуры предприятия являются люди; не учет этого является методической ошибкой;
Архитектура получает свое информационное воплощение в виде архитектурных продуктов, описаний и моделей разных типов;
Согласование архитектур рассматривается как согласование архитектурных продуктов (бизнес - моделей с техническими моделями);
Согласование архитектур рассматривается как процесс, позволяющий получить многократную экономию средств на создание и развитие ИС;
Для использования архитектурных продуктов (как стратегического информационного ресурса) необходимы комплексы организационных решений и инструментальных средств согласования и интеграции архитектур;
Определены принципы, позволяющие выбирать и оценивать архитектурные решения и строить процессы формирования архитектуры, "пошаговость" детализации при построении архитектуры и др.
Эти принципы имеют конструктивное описание, позволяющее использовать их как "руководство к действию":
Главным движущим слоем является бизнес-архитектура;
Кроме указанной бизнес - архитектуры предусмотрены слои архитектуры данных (или данных и информации), приложений, технологий (имеются в виду базовые ИТ);
Рассмотрены бизнес - модели, модели данных, концептуальная модель, а именно (модель процессов, модели интероперабельности (поддержки взаимодействия), технические модели, референсная модель взаимодействия, открытые стандарты (для технологической архитектуры)).
Литература
1. Методический материал «Методология и практические рекомендации по построению автоматизированных систем трансформирующихся государственных предприятий »/ Под общ. ред. , Фонд ФОСТАС, 2003 год.
2. Тельнов бизнес – процессов. - М.: Финансы и статистика, 2003. – 256 с.: ил.
Контрольные вопросы
Лекция 5. Раздел 3. Архитектура предприятия.
3.1. Понятие и общее представление об архитектуре предприятия.
3.2. Основные цели создания предприятия.
3.3. Общие методические принципы создания предприятия.
3.4. Формирование архитектуры в процессе детализации.
3.4.1. Подходы при построении архитектуры.
3.4.2. Компоненты архитектуры предприятия.
3.5. Комплексная архитектура предприятия. Модельные и организационные подходы.
Архитектура предприятия какинформационная основа корпоративной структуры
телекоммуникационной компании
А.Р. Диязитдинова ,
доц. каф. ЭИС, к.т.н., доц. dijazitdinova @ mail . ru ,
Е.А. Матвеева,
проф. каф. ЭИС, к.т.н., доц. helen _ matveev а @ mail . ru ,
О.Н. Ольховая,
доц. каф. ЭИС, к.э.н ., olkhovaya @ inbox . ru ,
ПГУТИ, г. Самара
В статье рассматривается место системы поддержки архитектуры предприятия в контуре управления компанией. Приводится алгоритм работы данной системы и взаимосвязь ее основных компонентов.
The article describes a place of enterprise architecture supporting system in a company management cycle. An algorithm of operating this system is provided, and an interconnection of its main components is described.
В ходе своего развития информационные технологии (ИТ ) заняли прочное место в управлении любым предприятием. Сегодня невозможно достичь эффективности бизнеса без применения ИТ-инструментов , обеспечивающих автоматизацию различных сложных операций.
В то же время новые возможности порождают и новые проблемы, значительная часть которых связана с трудностью разработки системы управления разнородной инфраструктурой. Сложность решения данной задачи связана с двумя аспектами. Во-первых, на предприятиях, как правило, функционирует несколько информационных систем, созданных и внедренных в разное время различными производителями. Во-вторых, жизненный цикл продуктов и ритм постоянных изменений, происходящих на рынке и вызывающих необходимость адаптации структуры предприятий, становится все более коротким.
Телекоммуникационные компании имеют ряд особенностей [
\\* MERGEFORMAT "">6 ], обуславливающих объективную необходимость развития и концепции поддержки архитектуры предприятия:
- непрерывность предоставления услуги;
- высокая технологичность и зависимость от сетевой и ИТ-инфрастуктуры .
Одним из эффективных инструментов осуществления организационных изменений с использованием ИТ в компаниях различных отраслей, способным обеспечить непрерывность бизнеса, стала архитектура предприятия. Поддержка архитектурного подхода в высокотехнологичной телекоммуникационной отрасли должна стать неотъемлемым элементом управления всей деятельностью компании – как операционной,такистратегической.
Архитектура предприятия (АП) должна давать возможность корректировать бизнес-процессы «на лету» таким образом, чтобы изменения сразу же отражались в работе управляющей системы. В докладе предлагается схема адаптации архитектуры предприятия к внешним изменениям.
Архитектура предприятия становится информационной основой корпоративной структуры компании. Она преследует две цели: во-первых, дать подробное системное описание самой организации для поддержания порядка ее функционирования, а, во-вторых, иметь стратегический план развития компании, учитывающий существующее внешнее окружение компании и ее техническую и технологическую оснащенность.
Архитектура предприятия представляет собой процесс сбора и распространения информации о том, как организация использует и должна использовать ИТ в своей деятельности . По сути, архитектура предприятия представляет собой информационную основу корпоративной структуры компании. Непосредственно архитектура предприятия не описывает конкретные технические решения отдельных информационных систем, но позволяет получить существенную выгоду для бизнеса организации в целом, что связано с повышением степени использования и эффективности информационных систем и программных продуктов, стандартизацией и повторным использованием ИТ-ресурсов , а такжеснижением рисков инвестиций в ИТ-сфере .
В настоящее время существует несколько широко применяемых определений данного понятия (подробно можно посмотреть в ). В качестве рабочего предлагается использовать следующее определение : архитектура предприятия – это всестороннее описание (модель) всех его ключевых элементов и связей между ними (включая бизнес-процессы, технологии и информационные системы), а также процесс поддержки изменения бизнес-процессов предприятия со стороны информационных технологий.
В литературе широко освещены следующие методологии построения АП: модель Захмана , метод EAP (Enterprise Architecture Planning ) С. Спивака ,TOGAF, методика META Group , методология Gartner , FEAF; DoDAF и т.д. Специфика отрасли связиобусловила развитие концепции NGOSS, которую можно рассматривать как референтную модель архитектуры телекоммуникационной компании. Несмотря на наличие значительного числа методик по созданию АП, ни одна из них не имеет доминирующего положения на рынке.
Независимо от выбранной методики построения архитектуры предприятия необходимо понимать, что построение архитектуры – это циклический процесс. Управление меняющимися бизнес-процессами и адаптацией к ним корпоративной системы предприятия должно превратиться в «рутинную» деятельность, поскольку фактически управление предприятием – это есть управление архитектурой предприятия в контексте достижения наибольшей эффективности его функционирования.
С точки зрения системного подхода в структуре организации следует выделить контур управления, где объектом управления выступает собственно архитектура предприятия, а субъектом – некоторая специально создаваемая система поддержки архитектуры предприятия, центральной задачей которой является отслеживание текущего состояния архитектуры (для оценки состояния возможно использование совокупности показателей бизнес-процесса) для дальнейшей выдачи рекомендаций по возврату на желаемую траекторию.
К основным компонентам системы поддержки архитектуры предприятия следует отнести: блок бизнес-процессов, блок анализа бизнес-процессов, блок моделей и блок управленческих решений.
Блок бизнес-процессов представляет собой блок поддержки бизнес-процессов предприятия. Все бизнес-процессы предприятия должны быть задокументированы , и за каждым бизнес-процессом должны быть закреплены его владельцы.
Блок анализа бизнес-процессов предназначен для отслеживания динамики изменения. Каждый бизнес-процесс оценивается с точки зрения различных показателей, а также происходит мониторинг динамики изменения данных показателей. Мониторинг должен осуществляться отдельным подразделением в организации.
Блок моделей включает в себя блок прогноза и блок моделирования взаимного влияния бизнес-процессов.
Блок управленческих решений, по сути, представляет собой некоторую систему управления знаниями, в которой хранятся различные альтернативы развития архитектуры предприятия.
Обобщенный алгоритм представлен на рисунке.
Центральным блоком системы является блок анализа бизнес-процессов. Анализ параметров работы современного предприятия является ключевым компонентом. Традиционная система финансовых показателей не может полностью описать существующую ситуацию в компании.
Телекоммуникационные компании как объекты управления характеризуются не только большим количеством составляющих элементов, но и многообразием функций, выполняемых этими элементами. Например, весьма специфичной задачей является управление качеством предоставления услуг. Другой особенностью компании связи является высокая технологичность и инновационность . Важной особенностью ИТ в телекоммуникациях является участие информационных технологий в создании добавленной стоимости. Если в большинстве отраслей ИТ рассматриваются сугубо как затратная часть технологической инфраструктуры, то в современной телекоммуникационной компании ИТ непосредственно участвуют в создании и предоставлении услуг.
рис.Обобщенный алгоритм работы системы поддержки архитектуры предприятия
Авторамипредлагаетсяввестиряд дополнительных специфическихпоказателей,отражающих особенности деятельности телекоммуникационной компании. В качестве таких показателейестественнорассмотреть (1)зонупокрытия (км² / %); (2)охват населения (чел. / %); (3) общую мощность передатчиков (Вт, кВт); (4) скорость передачи (мощность) радиорелейных линий (РРЛ) (Мбит/с); (5)количество ретранслируемых каналов; (6)времявещанияканалов (час); (7)количествоивысотумачтибашен, предназначенныхдляразмещенияпередатчиков (шт.,метров); (8)количество передатчиков,спутниковыхприемников; (9)протяженностьРРЛ; (10)количествочасовпростояпередатчиков (час).
Положительнуютенденциюразвитиякомпаниибудетхарактеризовать увеличение значений показателей (1) – (7) и уменьшение показателей (8) – (10).
Существенноеотличиеданныхпоказателейот традиционноиспользуемых выражается в том, что они измеряются в абсолютных единицах.
Технологии, используемые в работе телекоммуникационной компании, меняются чрезвычайно динамично. Обновление услуг и технологий естественным образом влечет изменение компонентов управляющих информационных систем оператора, а также собственно бизнес-процессов. В данных условиях использование системы поддержки архитектуры предприятия дает возможность оценивать и в дальнейшем адаптировать сформированную архитектуру предприятия к меняющимся внешним условиям.
1. Архитектура предприятия: основные определения [Электронный ресурс] / Данилин А.В., Слюсаренко А.И. / – Интернет-университет информационных технологий. – Режим доступа: http://citforum.ru/consulting/articles/enterprise_arch/2.shtml.-Загл . с экрана.
2. Калянов Г.Н. Управление развитием информационных систем [Электронный ресурс] / Васильев Р.Б., Калянов Г.Н., Левочкина Г.А. – Интернет-университет информационных технологий. – Режим доступа: http://www.intuit.ru/department/itmngt/mandevisys. - Загл . с экрана.
3. Краснов С.В., Диязитдинова А.Р. Концепция системы поддержки архитектуры предприятия [Текст] // Вестник Волжского университета им. В.Н. Татищева №2 (19) 2012, с. 60 – 65.
4. Самуйлов К.Е. Бизнес-процессы и информационные технологии в управлении телекоммуникационными копаниями / К.Е. Самуйлов , А.В. Чукарин , Н.В.Яркина . – М.: Альпина Паблишерз , 2009. – 442 с.
ВВЕДЕНИЕ
Информационные технологии сегодня являются неотъемлемой составляющей актива любого предприятия. В то же время затраты на их поддержку и развитие неизменно растут, и их доля в общей структуре расходов предприятий неизменно увеличивается. Значительная часть этих расходов приходится не собственно на приобретение конечных решений, но на создание и поддержание инфраструктуры, необходимой для надежного и эффективного функционирования этих решений.
Сложность информационно-технологической инфраструктуры, необходимой для обеспечения функционирования на должном уровне современных корпоративных информационных систем и других комплексных решений требует реализации не менее сложных и комплексных стратегий управления ИТ-инфраструктурой. Сложность решения такой задачи состоит в том, что для этого нужно достаточно радикально пересматривать общее позиционирование сервисных ИТ-служб в структуре предприятия.
ITSM (IT Service Management, управление ИТ-услугами) - подход к управлению и организации ИТ-услуг, направленный на удовлетворение потребностей бизнеса. Для содействия реализации подхода к управлению ИТ-услугами используется серия документов ITIL. ITIL не является конкретным алгоритмом или руководством к действию, но она описывает передовой опыт (good practices) и предлагает рекомендации по организации процессного подхода и управления качеством предоставления услуг. Это позволяет оторваться от особенностей данного конкретного предприятия в данной конкретной отрасли. Вместе с тем, несмотря на определённую абстрактность, ITIL всячески нацелено на практическое использование.
Целью данной работы является изучения теоретических и практических методов управления сервисами информационной системы (ITIL/ITSM).
В работе использована учебно-методическая литература и Интернет-ресурсы.
АРХИТЕКТУРА ПРЕДПРИЯТИЯ В УСЛОВИЯХ СОВРЕМЕННОГО МИРА
Под архитектурой предприятия (EA - Enterprise Architecture), обычно понимается полное описание (модель) структуры предприятия, как системы, включающее описание ключевых элементов этой системы, связей между ними.
Архитектура предприятия определяет общую структуру и функции систем (бизнес и ИТ) в рамках всей организации в целом (включая партнеров и другие организации, формирующие так называемое «предприятие реального времени») и обеспечивает общую рамочную модель (framework), стандарты и руководства для архитектуры уровня отдельных проектов. Общее видение, обеспечиваемое архитектурой предприятия, создает возможность единого проектирования систем, адекватных, с точки зрения обеспечения потребностей организации, и способных к взаимодействию и интеграции там, где это необходимо.
В основе архитектуры предприятия заложен «Архитектурный взгляд» на системы, определенный в стандарте ANSI/IEEE 1471, как «фундаментальная организация системы, состоящая из совокупности компонент, их связей между собой и внешней средой, и принципы, которыми руководствуются при их создании и развитии».
ИТ - архитектура предприятия
ИТ - архитектура предприятия или, другими словами, архитектура информационных технологий представляет собой совокупность технических и технологических решений для обеспечения эффективного функционирования бизнес - процессов предприятия в соответствии с правилами и концепциями, определяемыми бизнес - архитектурой.
Архитектура информационных технологий описывает основные информационные системы, их взаимосвязи и включает в себя их принципы развития, совершенствования и поддержки. Таким образом, мы можем говорить о том, что «архитектура является самодостаточной и полной динамической моделью системы».
Обобщенная ИТ - архитектура должна включать в себя как логические, так и технические компоненты. Логическая архитектура предоставляет высокоуровневое описание миссии предприятия, его функциональных и информационных требований, системных компонентов и информационных потоков между этими компонентами. Техническая архитектура определяет конкретные стандарты и правила, которые будут использоваться для реализации логической архитектуры.
Традиционно ИТ - архитектуру предприятия представляют в виде трех взаимосвязанных компонентов:
· Enterprise Information Architecture (EIA) – информационная архитектура.
· Enterprise Solution Architecture (ESA) – архитектура прикладных решений.
· Enterprise Technical Architecture (ETA) – техническая архитектура.
В ходе разработки архитектуры предприятия создается модель, включающая информацию о его производственных процессах, информационных и материальных потоках, ресурсах и организационных единицах. При этом модель ИТ - архитектуры непосредственно зависит от роли, которую выполняют информационные системы на предприятии: стратегическая (ориентированная на выполнение сложившихся стратегий и операций), сдвигающая (инструмент для увеличения эффективности бизнеса), поддерживающая (ИС не играют особой роли в функционировании предприятия), заводская (ИС являются обязательным элементом, обеспечивающим функционирование бизнеса). Модель предприятия (соответствующая ее роли) позволяет не только давать лучшее представление о структуре предприятия, но и является эффективным инструментом для анализа экономических, организационных и многих других аспектов его функционирования.
ИТ - архитектура предприятия определяет правила формирования всех компонентов ИТ, взаимосвязи между ними и бизнес - архитектурой предприятия. Это связано с тем, что документирование ИТ - архитектуры без ее увязки с бизнес - архитектурой предприятия быстро утрачивает практическую ценность.
Информационная архитектура (EIA - Enterprise Information Architecture) или, другими словами, архитектура информации – это (с точки зрения аналитиков компании Meta Group) управляемый набор методик, описывающий информационную модель предприятия и включающий в себя:
· Базы данных и хранилища данных.
· Информационные потоки (как внутри организации, так и связи с внешним миром).
Информационную архитектуру предприятия условно можно назвать уровнем потоков данных. Но, при построении информационной архитектуры предприятия нет необходимости создавать модели всех видов данных, используемых на предприятии. Достаточно обеспечить выбор наиболее важных (критичных для предприятия) данных и моделировать их на высоком уровне абстракции.
Архитектура распределяет массы и объемы.Недавно столкнулся со следующей ситуацией, одна крупная ИТ компания подбирала для себя архитектора, с целью доработки компьютерной платформы «собственного исполнения». Такая работа, естественно, требовала привлечения специалиста высокой квалификации. А как это сделать дешево и сердито, чтобы призванный варяг был «и чтец и жнец и на дуде игрец»? Решили без всяких излишеств разработчика ПО, поименовать архитектором, и заполучить помимо кодировщика, еще и профессионала, способного разобраться с чужими решениями, до проектировать их на свое усмотрение, принимать самостоятельные решения и т.п…
Вдохновение превращает инертный камень в драму.
Ле Корбюзье.
Когда стали выяснять, а как же в организации вообще обстоит дело с архитектурой, обозначились следующие тенденции. Есть ряд высококвалифицированных разработчиков, позиционируемых как архитекторы. Помимо непосредственно создания кода, они выполняют достаточно низкоуровневое проектирование различных технологических систем и задают вектор и горизонт их развития. Решения представлены ими в основном в виде текстовых описаний, разбавленных небольшим количеством схем, в основном производных от диаграмм компонентов. Каждый из архитекторов представляется уникальным и эксклюзивным носителем знаний, а по сути - является узким местом в процессе производства программных продуктов. Ведь на практике без его постоянных уточняющих консультаций, воспользоваться результатом евонной деятельности практически невозможно. Полная, логически выстроенная, структурированная картинка сложного решения есть лишь в его голове.
И документации вроде бы много, но она разрознена по репозиториям проектов, Вики системам и т.п. Найти логически целостное описание решения и рекомендации по его использованию крайне сложно, а уж проследить ответвляющиеся частные технические решения по цепочке: от потребностей пользователя, до конечной поставки заказчику, вообще не реально, И это несмотря на то, что для заказчика обычно готовится некая версия на базе типового продукта, доработанного в соответствии с его специфическими потребностями. А ведь иногда бывает так необходимо отследить, например, с кем связан компонент, который предполагается использовать при проектировании нового модуля. С кем он, так сказать, разделен шестью рукопожатиями, и какое пагубное влияние могут оказать все эти неучтенные связи на стабильность его поведения.
Подобная ситуация царит во многих крупных ИТ компаниях. Вроде есть архитекторы и архитектурные советы и прочие атрибуты «высокой» архитектуры, а порядка в этом царстве не наблюдается. По вышеперечисленным симптомам, выходит, что на предприятии свирепствует – «острая архитектурная недостаточность».
Мне стало интересно разобраться со всеми аспектами архитектуры, собрав в данной статье структурированно и последовательно информацию о том, что же такое ИТ архитектура, кто такие ИТ архитекторы, и «с чем их едят».
А что можно думать об архитектуре?Давайте для начала пройдемся по определениям.
Она, как солнце: большая, блестящая и она рядом.
Роджер Желязны. (Мастер сновидений)
Архитектура системы - принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию.Очень скупая формулировка и развернуть ее, проиллюстрировав в полной мере смысл, сложно. Поэтому постараемся сузить проблематику и оттолкнемся от чего-то меньшего, например, составной части этой системы:
Архитектура программного обеспечения (англ. software architecture) - совокупность важнейших решений об организации программной системы. Архитектура включает:Довольно лаконичное определение, дополнив которое можно приблизится к пониманию, что же принято ассоциировать с явлением - ИТ Архитектура.
- выбор структурных элементов и их интерфейсов, с помощью которых составлена система, а также их поведения в рамках сотрудничества структурных элементов;
- соединение выбранных элементов структуры и поведения, во всё более крупные системы;
- архитектурный стиль, который направляет всю организацию - все элементы, их интерфейсы, их сотрудничество и их соединение (1)
Во-вторых, место «совокупности этих элементов», как части, в более крупных системах, включая поведение, точки взаимодействия и т.п. То есть возможность абстрагирования рассматриваемой архитектуры на более высокий уровень, и соответственно детализация архитектуры в наборы составных архитектур нижнего уровня.
В-третьих, использование всеми участниками - единого подхода для организации решений в процессе производства информационных систем.
Раз уж речь зашла о едином подходе, давайте внесем ясность и в этот вопрос:
Архитектурный подход (англ. architectural framework) - соглашения, принципы и практики для описания архитектуры, установленные для конкретной области применения и/или конкретным сообществом заинтересованных лиц (2).Ведь в ходе проектирования, разработки, развития и модернизации программной системы, «совокупность решений о ее организации» (Архитектура), требует постоянного обсуждения со всеми заинтересованными лицами проекта, включая бизнес. Опять же принципиально, чтобы все при этом выстраивали перед собой одну и туже картинку, в том числе учитывающую текущее актуальное состояние архитектуры.
Итак, размявшись на общих положениях и задав направление для исследования понятия Архитектура, продолжим углубляться в суть этого явления.
1) Информационная архитектура (Enterprise Information Architecture, сокр. EIA), набор методик и инструментов, описывающий информационную модель предприятия. Включает:
4) Бизнес-архитектура предприятия (Enterprise Business Architecture, ЕВА) - целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес-целями. В ходе построения бизнес-архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура.
Соответственно для работы с каждым из вышеперечисленных разделов, требуется своя группа заинтересованных лиц, имеющих различную квалификацию и предпочтения, а возможно и цели. Поэтому многочисленные этапы ведения проекта порождают артефакты, описывающие аспекты архитектуры в разных стилях и жанрах. В добавок, они создаются чаще всего разнородными инструментами, используя разнообразные нотации, приемы, представления и т.п.
Стало быть, каждому разделу архитектуры соответствует как минимум одна группа стейкхолдеров, имеющая свои взгляды на представления и методы описания архитектуры. Подыщем определение для этой реалии.
Архитектурная группа описаний (англ. architectural view) - представление системы в целом с точки зрения связанного набора интересов. Каждая группа описаний относится к одному или более стейкхолдеру. Термин «группа описаний» употребляется для выражения архитектуры системы при некотором методе описания (2).Разобравшись вкратце с концепцией, направлениями и разделами архитектуры, а также выявив несовпадения в представлениях архитектуры разными группами заинтересованных лиц, перейдем к разбору непосредственно самих этих представлений (артефактов), отражающих архитектуру.
По всей вероятности нужна была какая-то подводка. А очень может быть, сначала надо было открыть людям целый новый мир, и только потом, в его свете, доносить эту свою идею. Это сродни тому, как иностранцу, не владеющему твоим родным языком, объяснять на нем теорию относительности Эйнштейна. Особенно если ты ее сам как-то не очень…
Очевидно, что и для эффективного представления архитектурных решений всем заинтересованным лицам, требуется некий способ, позволяющий доступно, но достаточно развернуто донести их суть до максимально широкого круга лиц. Таким способом может служить принятый в организации стандарт - Архитектурное описание и соответствующие методы их поддержания. Для более точного осмысления этого явления, пустим в ход и их определение:
Архитектурное описание (англ. architectural description) - рабочий продукт, использующийся для выражения архитектуры (2).
Архитектурный метод описания (англ. architectural viewpoint) - спецификация соглашений для конструирования и применения группы описаний. Шаблон или образец, по которому разрабатываются отдельные группы описаний посредством установления назначений и аудитории для группы описаний, а также приемы их создания и анализа. Метод описания устанавливает соглашения, по которым группа описаний создается, отображается и анализируется. Тем самым метод описания определяет языки (включая нотации, описания или типы продуктов), применяемые для определения группы описаний, а также все связанные методы моделирования или приемы анализа, применяемые к данным представлениям группы описаний. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам (2).Тем самым, выделенные архитектурные группы, используя единые архитектурные методы описания, значительно повышают эффективность своей работы, достигая максимально согласованного и целостного восприятия обсуждаемых проблем.
Но можно ли загнать специалистов разных направлений, имеющих разную квалификацию, а возможно и образ мышления, в единые рамки, и действительно ли это так необходимо?
Например, диаграмма, описывающая формирование целей и показателей на основании выявления стекхолдеров, вызовов и их проблематики см. рис.1, по своей природе очень сильно отличается от диаграмм со схемой прокладки сети, а также диаграмм в нотации UML и прочих.
Рисунок 1. Модель выработки целей и показателей
На практике использование разнородных артефактов является большой проблемой, поскольку теряется возможность сквозной трассировки архитектурных решений от целей и стратегий к потребностям, далее к описанию бизнес-процессов и функций системы, от них к структуре данных и поведенческим моделям, от моделей к макетам экранов и т.д. по цепочке. Ведь создают все эти артефакты специалисты разных архитектурных групп, которые формировались сами по себе, подбирая годами под себя оптимальные инструменты и методики.
Фиксируя все эти разнообразные описания и представления, возникает резонный вопрос: Как же их объединить в некий всеобъемлющий контекст?
Например, для разработки больших информационных систем еще в конце прошлого века использовали модель Закмана (3), в качестве схемы организации архитектурных артефактов.
Модель Закмана основана на дисциплине классической архитектуры и призвана обеспечить общее толкование архитектурных аспектов и предоставить набор перспектив, или структур (framework), для описания сложных корпоративных систем.
Сама модель представляется в виде матрицы - таблицы, имеющей пять строк и шесть столбцов, см. рис. 2. Каждая ячейка таблицы – презентует набор артефактов, раскрывающих один из насущных аспектов архитектуры.
Рисунок 2. Представление модели Закмана
Примечательно, что основная идея матрицы помимо того, чтобы вынудить заполнить все ячейки, не пропустив важные характеристики системы, состоит и в определении последовательности заполнения. Ведь только заполнив одни ячейки, открывается возможность на основании их заполнить следующие, пока пазлы не сложатся в цельную картинку. Таким образом, различные по своему представлению архитектурные описания ложатся в разные ячейки матрицы и ею же увязываются в единое архитектурное полотно.
Стоит отметить, что на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.
Модель Закмана со временем дорабатывалась и послужила прародителем для многих архитектурных каркасов и спецификаций.
Одной из таких актуальных спецификаций является например, графический язык ArchiMate, содержащий набор понятий для описания архитектуры предприятия и фреймворк, представляющий логическую структуру для классификации этой информации Последняя версия стандарта 3.0 вышла в июне 2016 года.
В ArchiMate, при создании моделей, используются базовые понятия «элемент» и «отношение» см. рис.3. На основе элементов и отношений строятся модели предприятия или его отдельных частей.
Рисунок 3. Основные понятия ArchiMate 3.0
Вся прелесть подхода состоит в том, что элементами могут быть проекции самых разнообразных реальных сущностей и явлений, встречающихся в жизни. Например, мотивационные элементы (стейкхолдеры, драйвер мотивации, цель, результат, ценность и т.д.), элементы организации и поведения (исполнители, роли, процессы, функции, события, взаимодействие и т.д.), бизнес элементы (информационный актив, соглашение, продукт/услуга, компонент приложения, интерфейс приложения, автоматизируемая функция и т.д.), технологические элементы (узел/ресурс, устройство, коммуникационная сеть, технологический процесс и т.д.). Каждый вид элемента представлен на диаграммах своим уникальным обозначением. Таким образом в одном информационном пространстве могут сочетаться столь разные отражения сущностей, явлений, событий, действий и т.д., образующих архитектуру предприятия.
Сами модели располагают в одной из ячеек каркаса на пересечении Слоя (уровень представления) и Аспекта. Схематично структура фреймворка представлена на рис. 4.
Рисунок 4. Слои фреймворка ArchiMate 3.0
В качестве Слоев рассматриваются конструктивные субсистемы предприятия, образующие некое самодостаточное представление (срез) организации. А Аспекты в свою очередь относят элементы, к одному из трех основных типов:
1) Активный структурный элемент (active structure element) позиционирует его, как некую сущность, которая способна выполнять определенные действия
2) Пассивный структурный элемент (passive structure element) позиционирует его, как некоторый объект, над котором выполняются действия.
3) Элемент поведения (behavior element) определяется как некоторая единица действия, выполняемая одним или несколькими активными структурными элементами.
Более подробно ознакомится со спецификацией можно в обзоре ArchiMate (4).
Такого рода инструменты позволяют объединить в единое информационное пространство разнородные аспекты архитектуры, используя унифицированное архитектурное описание и методы, обеспечивая трассировку между диаграммами и элементами.
Погрузившись во все эту «карусель» сложностей и разнообразия возникает один немаловажный вопрос: А всегда ли необходимо выполнять такой сложный и ресурсоемкий процесс описания архитектуры? На самом деле существует несколько подходов к ее построению, например:
1) Стандартный подход, заключается в разработке или выборе на начальном этапе общей схемы и правил для описания архитектуры. На основании выработанных стандартов, описывается базовая (текущая) архитектура, и отталкиваясь от нее, проектируется целевая (новая). Определив разницу, формируют мероприятия по переходу от базовой архитектуры к целевой. Только после этого начинается конструирование, приобретение и разработка компонентов системы. В качестве недостатков, можно выделить: существенные начальные инвестиций, как финансовые, так и временные. Также этот подход может привести к тому, что называется «паралич из-за анализа».
2) Подход «статус-кво». Разработка рассматривается как реакция на те или иные возникающие затруднения или воздействия.
3) Сегментный подход, опирается на модель разработки сегментов архитектуры в рамках общей структурированной схемы. Он сосредотачивается на главных областях бизнеса. Позволяет сократить возможные риски, обеспечить снижение начальных затрат и добиться быстрой отдачи от проекта. Могут возникнуть проблемы на этапе интеграции сегментов.
Со следующей частью статьи можно ознакомиться, перейдя по
Не надо питать иллюзий насчет того, что работа архитектора заканчивает-ся строительством видения великолепной архитектуры предприятия. Архитек-тура информационных технологий - это только на 10% видение, а на 90%- кропотливая работа по реализации.
Реализация архитектуры предприятия не является проектом в строгом смысле этого слова. Дело в том, что за фазой разработки неизбежно должна по-следовать деятельность по поддержанию и постоянному развитию архитектуры предприятия, а это более удобно описывать в рамках процессной модели. Одна-ко на практике часто встречаются следующие два случая, когда целесообразно организовать выполнение специального архитектурного проекта.
С учетом существующего реального состояния дел большинство организаций либо не имеют формализованной определенной архи-тектуры, либо эти определения неполны и недостаточно четко связаны с требова-ниями бизнеса. В таких случаях имеет смысл организовать работу в рамках специ-ального проекта с определенными сроками и результатами, основной целью кото-рого будет являться создание первоначального описания архитектуры организа-ции и создание механизмов для ее последующего поддержания и развития.
Первоочередными задачами такого проекта являются:
· организация необходимых структур с привлечением руководства предпри-ятия, бизнес-подразделений и планирование работ;
· понимание стратегии развития бизнеса организации;
· формирование общих для бизнеса и ИТ требований к целевой архитектуре;
· разработка концептуальной архитектуры в виде согласованного и полного набора принципов, в соответствии с которыми будет проводиться разра-ботка архитектуры отдельных доменов (предметных областей или частных архитектур).
Для многих организаций отправной точкой в создании общей архитектуры предприятия может стать существующая ИТ-архитектура.
Другим возможным вариантом выделения такой деятельности в отдельный проект может явиться потребность в проведении эволюционного скачка в архи-тектуре. Например, открытие нового бизнес-направления или внедрение новой ERR-системы потребует значительных изменений в вычислительной и сетевой инфраструктуре, реорганизации ИТ-службы и т.п. Возможностей существующей группы поддержки архитектурного процесса окажется недостаточна для реше-ния таких задач, и потребуется привлечение дополнительных внутренних и внешних ресурсов, что опять-таки удобнее выполнять в рамках четка опреде-ленного проекта.
Какую бы архитектурную методику вы ни выбрали, при всех расхождениях в деталях проект работы над созданием архитектуры обычно включает решение следующих задач:
· Определение и обоснование цели - ответы на вопросы Почему? и Что?
· Выполнение ряда шагов, связанных с инициацией процесса разработки ар-хитектуры (см. ниже).
· Определение существующего состояния архитектуры («as-is») для каждой выбранной области (домена) - отправная точка ответа на вопрос где?
· Определение целевой архитектуры - конечная точка ответа на вопрос где ?
· Анализ расхождений между текущим и желаемым состоянием.
· Разработка плана перехода - ответы на вопросы Когда? и Как?
· Подтверждение (проверка) достижимости - можно ли на самом деле до-стичь конечного состояния из данного начального состояния с учетом су-ществующих ограничений?
· Выполнение намеченного плана.
Здесь стоит особенно отметить важность усилий для решения третьей за-дачи. С одной стороны, формирование целостного описания существующей ар-хитектуры может потребовать проведения настоящих «археологических раско-пок» в ранее существовавшей документации, изучения существующих преданий и посвящения в «тайные знания» о годами работающих системах. С другой сто-роны, здесь важно определить набор целевых метрик (надежность, стоимость эксплуатации и т.п.) и их начальных значений - иначе потом будет очень труд-но объективно оценить, достигнуты ли цели проекта.
Начальные действия по инициации самого проекта разработки архитекту-ры включают следующие шаги:
· определение «устава» (основных правил) и границ проекта;
· бизнес-обоснование реализации проекта разработки архитектуры пред-приятия;
· получение поддержки высшего руководства;
· определение состава рабочей группы (организационная структура и уча-стники);
· проведение рабочей встречи, посвященной началу проекта разработки архитектуры и определения других высокоуровневых документов, которые необходимы для более детальных работ по разработке архитектуры;
· создание рабочих групп, которые будут разрабатывать различные фокусные области или домены в рамках общего проекта (например, бизнес-архитек-тура, архитектура информации, прикладных систем, инфраструктуры).
Высокоуровневые документы, которые должны быть результатом первооче-редных шагов, являются ключевыми для дальнейшей, более детальной проработ-ки архитектуры. Они создают некоторый культурный контекст всех усилий и обес-печивают связь работы по созданию архитектуры с бизнес-стратегиями и приори-тетами предприятия. Список этих высокоуровневых документов может включать:
· бизнес-факторы, влияющие на деятельность предприятия;
· внутренние и внешние технологические факторы;
· формулировку общего видения Архитектуры предприятия;
· высокоуровневые принципы.
Важной составляющей всего проекта является создание структур управле-ния и контроля архитектурного процесса (governance), который должен обеспе-чить то, что сообщество специалистов на практике использует результаты этих работ; вторая серьезная задача - обеспечение связей процесса разработки ар-хитектуры с процессами бизнес-планирования и выработки ИТ-стратегии.
Общая блок-схема процесса в итоге выглядит, как показано на рис. 1.7.
Рис. 1.7. Общая схема построения архитектуры предприятия
В принципе, существуют три возможных подхода к организации процесса разработки архитектуры:
· Традиционный обычный подход. Он требует существенных начальных за-трат времени и ресурсов для достижения первых ощутимых результатов. В этом подходе в первую очередь разрабатывается регламент для будущего описания архитектуры. Затем должно быть определено текущее базовое состояние архитектуры и только после этого представлена целевая архи-тектура. Лишь когда все зги действия закончены, начинается детальное проектирование и разработка необходимой Архитектуры предприятия.
· Сегментный подход. Суть этого подхода состоит в постепенной поступа-тельной разработке сегментов архитектуры в рамках общей структуры, описывающей принципы Архитектуры ИТ. Этот подход сосредоточивается на главных бизнес-сферах и областях архитектуры и имеет больше шансов на успех, поскольку усилия ограничены пределами общих выполняемых функций, а также сфер специфической деятельности предприятия.
· Подход статус-кво или «оставить все как есть». Результатом этого будут провалы в попытках наладить информационный обмен, невозможность реакции на быстроменяющееся окружение. Этот подход также означает постоянную переделку бизнес-функций, снижение производительности, потерянные или упущенные возможности.
Традиционный, обычный подход при всей кажущейся его правильности связан с риском «паралича анализа», который особенно неконструктивен в рос-сийских условиях переходной экономики и процессов реформирования госу-дарства. Чтобы сократить возможные риски неудач, обеспечить снижение на-чальных затрат и добиться быстрой отдачи от проекта разработки Архитектуры ИТ, рекомендуется второй, т.е. сегментный подход.
Один из признанных авторитетов в области корпоративной архитектуры Стивен Спивак (Steven Spewak) предложил удачную модель планирования Ар-хитектуры предприятия, которая называется ЕАР (Entrerprise Architecture Planning - Планирование архитектуры предприятия). Модель EAP соответствует описанному нами выше принципу сегментного подхода к разработке архи-тектуры и включает 7 шагов, определяющих эту архитектуру и соответствующий план ее реализации (миграции). Эти 7 компонент, условно изображенных на рис. 1.8 в виде «свадебного торта», обозначают смещение фокуса приложе-ния сил на каждом из шагов.
Рис. 1.8. Методика Спивака
Подход Спивака уже помог очень многим компаниям и государственным ведомствам в организации процесса моделирования, стратегического бизнес-планирования, реорганизации деловых процессов, проектировании различных систем, выработки стандартов на данные, управления проектами. В частности, этой методикой пользовались такие организации, как Federal Express, Министер-ство энергетики США, Штаб Военно-воздушных сил США и другие. Например, в Министерстве энергетики США основная фаза процесса разработки архитектуры («проект») заняла примерно б месяцев.
Методика ЕАР обеспечивает высокоуровневый взгляд на предприятие с точки зрения его бизнес-функций и требований в области информации. Это ин-струмент планирования, а не детального проектирования архитектуры. Резуль-таты планирования используются в качестве основы для интегрированной раз-работки прикладных систем и технологий, которые обеспечивают потребности бизнеса. Отличительными характеристиками этого подхода к планированию ар-хитектуры являются следующие:
· в основе - потребности бизнеса, а не технологические факторы;
· основное внимание сосредоточено более на данных и потребностях в ин-формации, чем на процессах;
· ответственность за процесс в большей степени несут представители биз-нес-подразделений,чем специалисты по ИТ.
Если «наложить» методику ЕАР Спивака на модель архитектуры Захмана (см. пункт 2.2),то можно сказать, что методика ЕАР является руководством по заполнению первых двух строк таблицы Захмана, которые описывают контекст архитектуры и концептуальную модель бизнеса предприятия, т.е. зто перспекти-вы, соответствующие представлениям об архитектуре бизнес-руководителей: «планировщика» и «владельца». Проектирование систем, которое начинается с третьей строки таблицы Захмана, остается за рамками методики Спивака.
Это замечание ничуть не умаляет достоинств методики Спивака, но ниже мы рассмотрим более подробно и остальные элементы архитектурного процесса.
Какое бы определение Архитектуры предприятия мы, в конечном итоге, ни выбрали, общими для всех методик описания архитектуры является системати-ческое и рекурсивное применение таких принципов, как:
· декомпозиция на различные представления архитектуры (предметные об-ласти): область прикладных систем, технологическая архитектура и т.д.;
· различные уровни детализации и абстракции для описания каждой из этих областей.
Схема процесса разработки в самом общем виде представлена на рис. 1.9. Об-ратим внимание на то, что фактически здесь идет речь о параллельных активностях по определению как целевой архитектуры, так и стратегии ее достижения. 
Рис. 1.9. Общая схема процесса разработки архитектуры
Эта схема состоит из следующих шагов:
· Общим фоном для этого процесса является мониторинг существующих тен-денций в области деятельности организации и тенденций в области разви-тия информационных технологий.
· Анализ на бизнес-уровне. На первом этапе проводится анализ движущих сил, которые влияют на необходимость использования ИТ с точки зрения основных функций и бизнеса организации. Определяются требования биз-неса и технологии на текущем этапе и на перспективу, которые задают тре-бования к информационным системам. Учитываются тенденции в развитии информационных технологий и мировых аналогов с учетом перспектив развития бизнеса.
· На основе этого анализа формулируются в самом общем виде требования к информационным технологиям с точки зрения информации (данных) и архитектуры ИТ.
· Принимаются общие для организации стандарты и понятия о том, что такое архитектура предприятия: принципы, общие методы описания архитекту-ры и ее разделы, стандарты, конкретные продукты и технологии.
Параллельно с этими процессами выполняется анализ на «системном уровне»: аудит используемых информационных технологий и программно-технических средств, аудит организации процессов управления ИТ, внед-рения технологий и приложений.
Результаты вышеперечисленных этапов являются основой для выполнения «GAP-анализа», т.е. выявления расхождений и различий между существу-ющей ИТ-инфраструктурой и желаемой архитектурой предприятия. Результаты Gap-анализа ложатся в основу Плана миграции: определяются цели создания (модернизации) информационных систем и решаемых ими задач, согласовывается стратегия разработки и внедрения информацион-ных технологий (перечень критических процессов, подлежащих автомати-зации в первую очередь и т. д.), обсуждается план детального анализа.
После этого начинается фаза реорганизации конкретных проектов в рамках выработанной на данный момент архитектуры предприятия.
С практической точки зрения, реализация инициативы в области разработ-ки архитектуры предприятия разделяется на несколько фаз или этапов. На каж-дом этапе готовится совершенно определенный набор документов и иных мате-риалов, которые создают основу архитектуры и которые позволяют предъявлять видимые результаты деятельности рабочей группы, ответственной за всю иници-ативу разработки архитектуры в целом.
Основой работы на этих этапах является эволюционный, итеративный про-цесс, связанный с определением и описанием текущего и желаемого состояния архитектуры, совмещенный с процессом анализа результатов, идентификацией направлений и планов развития ((GAP-анализ), который обеспечит синхрониза-цию архитектуры с изменениями в функциях подразделений, с изменениями в бизнес-требованиях и изменениями в технологиях.
Архитектура, в результате, является одновременно как постоянным организационным процессом, так и результатом,который мате-риализуется в форме моделей и документов, описывающих существующее и бу-дущее состояние архитектуры.
Разработка архитектуры является сложным процессом, который обеспечи-вает движение от описания общего положения с имеющимися информационны-ми системами и инфраструктурой к практической реализации информационных систем, их эксплуатации и оценке результатов. Процесс носит нелинейный, цик-лический характер, и было бы ошибкой считать, что разработка архитектуры- это одноразовая кампания, которая обеспечивает простое перемещение инфор-мационных систем предприятия из состояния «А» в состояние «Б». Архитектура - это постоянный процесс, который нацелен на обеспечение постоянных улуч-шений в той области, которая связана с отдачей от использования информаци-онных технологий для реализации бизнес-функций предприятия и его соответ-ствующих подразделений.
Процесс разработки и обновления архитектуры должен идти параллельно и одновременно с практической реализацией информационных систем пред-приятия. Это два взаимосвязанных процесса, которые, однако, имеют различные «скоростные характеристики». Архитектурный процесс по своей природе является концептуальным, имеетдлительный временной горизонт, в та время как реали-зация систем ориентирована на внедрение конкретных решений и реализацию проектов с более коротким временным горизонтом.
Архитектура задает цели для отдельных проектов и инициатив, но важна и обратная связь: систематический анализ опыта реализации отдельных проектов и систем является неотъемлемой частью всего процесса планирования и разра-ботки архитектуры.
Ниже описаны этапы каждой итерации процесса разработки и обновления архитектуры, которые следуют, в основном, рекомендациям МЕТА Group. Харак-терными для этого подхода элементами описания архитектуры являются такие документы, как Общее видение и Концептуальная архитектура. Заметим, что, да-же в случае выбора какой-то другой методики, скорее всего придется созда-вать аналоги этих документов. Каждая итерация включает:
· Этап 1: Описание или уточнение Общего видения (видение общих требова-ний к архитектуре).
· Этап 2: Описание или уточнение Концептуальной архитектуры, а также разработка и уточнение архитектуры отдельных представлений (или предметных областей, доменов): бизнес-архитектура, архитектура инфор-мации, архитектура приложений, технологическая архитектура и пр.
· Этап 3: Разработка или уточнение Плана реализации.
При первой итерации этого процесса разрабатываются только те пред-ставления (view) архитектуры (предметные области, или домены, архитектуры), которые идентифицированы как наиболее приоритетные (2-3 области). Напри-мер, если будет принято решение, что наиболее острой проблемой является ин-вентаризация существующих на предприятии прикладных систем и составление плана изменения их портфеля (вывод из эксплуатации ряда прикладных систем, обновление или разработка новых), то такая область, как Архитектура прикладных систем,должна разрабатываться в приоритетном порядке.
После завершения всех трех этапов первой итерации рабочая группа, от-вечающая за разработку архитектуры, продолжает разработку архитектур ос-тальных доменов (предметных областей), не проработанных ранее, с учетом на-копленного опыта и информации на предыдущих итерациях.
Итого пересматривая состав этапов можно заметить следующее:
Этап 1: Разработка Общего видения архитектуры
Общее видение обеспечивает единое понимание проблемы между функци-ональным (бизнес-) руководством и людьми, отвечающими за информационн--коммуникационные технологии. Оно задает контекст для всей последующей разработки элементов архитектуры.
Основными элементами Общего видения являются:
· описание технологических тенденций, важных для предприятия;
· идентификация бизнес-требований и стратегий;
· идентификация основных требований к информации и технологиям, кото-рые важны с точки зрения реализации бизнес-стратегий;
· идентификация требований к Архитектуре предприятия в целом.
