Автор работы: Пользователь скрыл имя, 02 Июля 2015 в 12:25, реферат
Архитектура предприятия выделилась в отдельную дисциплину чуть более 20 лет тому назад и в настоящее время является одной из ключевых функций как корпоративного, так и проектного менеджмента, основным средством достижения и поддержания конкурентоспособности любого предприятия или организации, особенно в сфере ИТ.
После этого начинается фаза реорганизации конкретных проектов в рамках выработанной на данный момент архитектуры предприятия.
С практической точки зрения, реализация инициативы в области разработки архитектуры предприятия разделяется на несколько фаз или этапов. На каждом этапе готовится совершенно определенный набор документов и иных материалов, которые создают основу архитектуры и которые позволяют предъявлять видимые результаты деятельности рабочей группы, ответственной за всю инициативу разработки архитектуры в целом.
Основой работы на этих этапах является эволюционный, итеративный процесс, связанный с определением и описанием текущего и желаемого состояния архитектуры, совмещенный с процессом анализа результатов, идентификацией направлений и планов развития ((GAP-анализ), который обеспечит синхронизацию архитектуры с изменениями в функциях подразделений, с изменениями в бизнес-требованиях и изменениями в технологиях.
Архитектура, в результате, является одновременно как постоянным организационным процессом, так и результатом, который материализуется в форме моделей и документов, описывающих существующее и будущее состояние архитектуры.
Разработка архитектуры является сложным процессом, который обеспечивает движение от описания общего положения с имеющимися информационными системами и инфраструктурой к практической реализации информационных систем, их эксплуатации и оценке результатов. Процесс носит нелинейный, циклический характер, и было бы ошибкой считать, что разработка архитектуры- это одноразовая кампания, которая обеспечивает простое перемещение информационных систем предприятия из состояния «А» в состояние «Б». Архитектура - это постоянный процесс, который нацелен на обеспечение постоянных улучшений в той области, которая связана с отдачей от использования информационных технологий для реализации бизнес-функций предприятия и его соответствующих подразделений.
Процесс разработки и обновления архитектуры должен идти параллельно и одновременно с практической реализацией информационных систем предприятия. Это два взаимосвязанных процесса, которые, однако, имеют различные «скоростные характеристики». Архитектурный процесс по своей природе является концептуальным, имеет длительный временной горизонт, в та время как реализация систем ориентирована на внедрение конкретных решений и реализацию проектов с более коротким временным горизонтом.
Архитектура задает цели для отдельных проектов и инициатив, но важна и обратная связь: систематический анализ опыта реализации отдельных проектов и систем является неотъемлемой частью всего процесса планирования и разработки архитектуры.
Ниже описаны этапы каждой итерации процесса разработки и обновления архитектуры, которые следуют, в основном, рекомендациям МЕТА Group. Характерными для этого подхода элементами описания архитектуры являются такие документы, как Общее видение и Концептуальная архитектура. Заметим, что, даже в случае выбора какой-то другой методики, скорее всего придется создавать аналоги этих документов. Каждая итерация включает:
При первой итерации этого процесса разрабатываются только те представления (view) архитектуры (предметные области, или домены, архитектуры), которые идентифицированы как наиболее приоритетные (2-3 области). Например, если будет принято решение, что наиболее острой проблемой является инвентаризация существующих на предприятии прикладных систем и составление плана изменения их портфеля (вывод из эксплуатации ряда прикладных систем, обновление или разработка новых), то такая область, как Архитектура прикладных систем, должна разрабатываться в приоритетном порядке.
После завершения всех трех этапов первой итерации рабочая группа, отвечающая за разработку архитектуры, продолжает разработку архитектур остальных доменов (предметных областей), не проработанных ранее, с учетом накопленного опыта и информации на предыдущих итерациях.
Итого пересматривая состав этапов можно заметить следующее:
Этап 1: Разработка Общего видения архитектуры
Общее видение обеспечивает единое понимание проблемы между функциональным (бизнес-) руководством и людьми, отвечающими за информационн-коммуникационные технологии. Оно задает контекст для всей последующей разработки элементов архитектуры.
Основными элементами Общего видения являются:
Этап 2. Параллельная разработка Концептуальной архитектуры и частных Архитектур предметных областей
На этан этапе ведется параллельная разработка Концептуальной архитектуры, основанной на ранее определенных принципах и лучших практиках, а также более детальная проработка Архитектур отдельных предметных областей.
При этом описание архитектуры как минимум включает модели таких областей, как Бизнес-архитектура, Архитектура информации, Архитектура прикладных систем и Технологическая архитектура. Необходимо определить те предметные области, архитектура которых предполагает первоочередную разработку на первой итерации процесса.
Заметим, что основой разработки архитектур отдельных предметных областей (доменов) служит Концептуальная архитектура.
Концептуальная архитектура обеспечивает общий анализ всех даменов архитектуры с точки зрения идентифицированных на этапе разработки общего видения принципов и факторов влияния. Целью Концептуальной архитектуры является перевод требований, сформулированных в Общем видении, в набор конкретных принципов, которые будут использоваться на этапе разработки архитектуры отдельных предметных областей.
Этап 3: Разработка Плана реализации
Этап 3 включает в себя следующие два шага:
В крупной организации или, например, в региональном или городском масштабе государственного управления работа по разработке архитектуры должна выполняться на нескольких уровнях. На уровне предприятия или регионального (городского) правительства должны приниматься общие решения, обеспечивающие совместимость и взаимодействие информационных систем, а также вырабатываться другие общие требования и стандарты. На уровне отдельных крупных бизнес-подразделений или департаментов должны разрабатываться архитектуры информационных систем соответствующих структурных подразделений, оптимизированные с учетом их функций, но в рамках общих принципов, определенных в масштабе предприятия (региона, города) в целом.
Одним из результатов совместных усилий по разработке архитектур различных уровней должен быть список информационных подсистем и сервисов, которые носят общий, «горизонтальный» характер, таких как управление общими для предприятия информационными ресурсами и системами, общие системы идентификации и авторизации, общие системы контроля доступа к информационным ресурсам и т.д.
При организации архитектурного процесса может оказаться полезным использование упоминавшегося ранее стандарта IEEE 1471. Этот стандарт определяет рамочную модель, ориентированную на разработку комплексов с гарантированной надежностью, требуемой, например, в военных, космических и авиационных системах. Такая модель включает в рассмотрение понятия «участника» (stakeholder) и его представлений о целевой системе. На первый взгляд это может показаться тривиальным - ведь создание любой системы, в том числе и с использованием классических подходов, начинается со сбора, описания и анализа требований. Принципиальным в данном случае является признание того факта, что в подавляющем числе случаев на практике совокупность требований является, с одной стороны, неполной, а с другой - противоречивой.
В общем виде можно сказать, что существуют два принципиально различных подхода в разработке Архитектуры предприятия:
подход «сверху-вниз» предполагает достаточно широкий охват проблем и точное следование формальному процессу. Основу этому подходу положили методики Захмана и Спивака. Он начинается со сбора информации, требующейся для описания различных доменов архитектуры «как есть». Далее следует этап, связанный с описанием и реинжинирингом бизнес-процессов, консолидации прикладных систем, выстраивание архитектуры данных и, наконец, стандартизация технологической архитектуры. Например, многие государственные проекты ориентированы на этот подход (например, в США в рамках Федеральной архитектуры FEAF). В таблице 1.1 представлены преимущества и недостатки вышеуказанных подходов.
Таблица 1.1
«Плюсы» и «минусы» разных подходов при разработке архитектуры предприятия
Подход |
Преимущества |
Недостатки |
(1) |
(2) |
(3) |
«сверху-вниз» |
С самого начала создается ясное видение существующей ситуации в целом C самого начала сформулированы бизнес-потребности и проблемы С самого начала задаются широкие рамки процесса с необходииой поддержкой высшего руководства |
Процесс может носить весьма абстрактный характер (выбор методик, типов моделей и пр.) Маловероятно, что будут получены явные, видимые результаты в течение первого года работ Может сложиться впечатление, что результатом проекта являются никому не нужные документы Процесс сбора информации приводит к задержкам в построении структур управления архитектурныи процессом Использование формальных методологий требует обучения Использование многих формальных методик требует наличия навыков и опыта в реинжиниринге бизнес-процессов |
Продолжение таблицы 1.1 | ||
(1) |
(2) |
(3) |
«снизу-вверх» |
Такой подход быстро начинает давать видимые результаты Быстрый успех повышает авторитет и доверие к процессу Самые «горячие», приоритетные проблемы решаются в первую очередь Масштаб и сложность проекта растет постепенно Отсутствует необходимость иметь сразу большую команду, участвующую в процессе разработки архитектуры Ориентация на решение в первую очередь технологических задач соответствует ключевой области экспертизы ИТ-службы Результирующая экономия затрат позволяет обосновать необходимость новых организационных структур и процессов, связанных с архитектурой
|
Первоначальная техническая направленность проекта затрудняет его распространение на более широкие области, связанные с бизнесом Основанный на внедрении технических стандартов подход создает структуры управления архитектурныи процессом, нацеленные на контрольные,«полицейские» функции Первоначальный технологический фокус воспринимается как игнорирование бизнес-аспектов Некоторые области, требующие улучшений, должны «ждать» своей очереди (например, архитектура данных) |
Подход «снизу-вверх», когда процесс начинается со стандартизации инфраструктурных технологий (технологическая архитектура), а затем развивается в направлении решения проблем более высокого уровня и, в конечном итоге, решает вопросы, связанные с бизнес-архитектурой. Этот подход видимо, имеет более широкое распространение в бизнесе и в частном секторе.
В зависимости от ряда факторов, предпочтение отдается тому или иному подходу. Например, когда проект разработки архитектуры должен быстро показать отдачу, включая финансовую, или если разнообразие используемых в организации технологий явно приводит к падению качества ИТ-сервисов, то предпочтительным является подход «снизу-вверх». Организации, которым нужно решить с помощью архитектуры существенные проблемы, связанные с неэффективностью или большим количеством излишних бизнес-процессов или с наличием перегруженного набора прикладных систем, и которые готовы ждать как минимум год получения видимых результатов от разработки архитектуры, должны использовать подход «сверху-вниз».
Информация о работе Применение архитектурных подходов в сфере информационных технологий